WO2017006013A1 - Procédé de gestion de l'authentification d'un client dans un système informatique - Google Patents

Procédé de gestion de l'authentification d'un client dans un système informatique Download PDF

Info

Publication number
WO2017006013A1
WO2017006013A1 PCT/FR2016/051601 FR2016051601W WO2017006013A1 WO 2017006013 A1 WO2017006013 A1 WO 2017006013A1 FR 2016051601 W FR2016051601 W FR 2016051601W WO 2017006013 A1 WO2017006013 A1 WO 2017006013A1
Authority
WO
WIPO (PCT)
Prior art keywords
assertion
client
terminal
terminals
data relating
Prior art date
Application number
PCT/FR2016/051601
Other languages
English (en)
Inventor
Kevin CORRE
Vincent Frey
Original Assignee
Orange
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 filed Critical Orange
Publication of WO2017006013A1 publication Critical patent/WO2017006013A1/fr

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/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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks

Definitions

  • the invention relates to a method for managing the authentication of a client in a computer system.
  • the client can be either a user of a terminal or a terminal.
  • the terminal in question includes any data processing device, that is to say equipped with physical resources and / or software including at least one microprocessor, able to communicate through a communication network.
  • the terminal may be for example a mobile phone, a computer, a PDA, etc.
  • the communication network is any. This one is for example the Internet network.
  • the IdP provider provides Alice with an identity assertion, that is, a document that ensures the customer is identified, and that Alice can provide to another customer to identify with that other customer.
  • This document generally contains Alice's own identity elements known to his supplier. identity, and the means by which this provider has ensured that the user claiming to be Alice has been authenticated as such.
  • BOB After receiving the assertion, suppose Alice wants to connect with a customer (man or machine) called Bob afterwards. Before linking, BOB will authenticate Alice. For this, Alice transmits the assertion received from the identity provider to Bob; Bob then contacts Alice's identity provider to verify that the assertion received from Alice has been issued by this IDP provider. This confirmation allows Bob to ensure that Alice with whom a call is going to be established is the same customer as the one registered with the IdP provider;
  • the invention offers a solution that does not have the drawbacks of the state of the art.
  • the subject of the invention is a method of authentication of a first client by a second client in a communication network including a set of terminals and an identity provider capable of providing data. on an assertion of identity, characterized in that it comprises the following steps on the terminal associated with the second client a. a step of receiving an assertion, received from a first client, obtained from the identity provider, b. a step of searching for data relating to the assertion in a memory of a terminal, c. and in that an authentication of the first client is based on the assertion received from the first client and on data relating to the assertion from said memory of a terminal.
  • data relating to the assertion is stored on one or more terminals separate from the provider of the 'identity.
  • the second client obtains the data relating to an assertion at best locally if it is part of the terminals having received the data relating to the assertion, or in the case opposite by querying a terminal that has received the relevant data. Since the interrogated terminal is distinct from the identity provider, the invention enables a user to verify an assertion without the identity provider being involved in the verification. The identity provider is therefore never aware of the customers who are the origin of a request for access to data relating to the assertion, in this case the proof of the assertion.
  • the relative data can be the assertion itself or a data derived from the assertion. It will be seen later that, for security reasons, this data is derived from the assertion by applying a hash function on the assertion.
  • the decentralized storage system is formed by terminals that constitute a network of nodes storing copies of the proof of the assertion.
  • the method further comprises a step of receiving a memory address where said data is stored in the memory of said terminal.
  • the second client knows where the proof of the assertion is stored in the set composed by the terminals. According to a variant of this mode, if the data relating to the assertion is stored on several terminals, the second client can receive one or more addresses corresponding to the places of storage of the data on these terminals respectively.
  • the terminal associated with the second client is part of a set of terminals storing the data relating to the assertion
  • the search step comprises a step of reading the assertion in a memory of the terminal associated with the second client.
  • the authenticating terminal has proof of assertion in its own memory. This mode prevents the authenticating terminal from interrogating another terminal.
  • the terminal associated with the second client is distinct from a set of terminals storing the data relating to the assertion. namely, proof of the assertion; in addition, the search step comprises a step of transmitting an access request to the assertion to a terminal storing the data.
  • the terminal associated with the second client has limited resources. Indeed, the management of the storage of the data relating to the assertion can involve significant power consumption and therefore have a negative impact on the autonomy of the terminal when the latter is powered with a battery.
  • the terminal which authenticates is distinct from the plurality of terminals on which the proof of the assertion is stored.
  • the method comprises a step of transmission, by a terminal, of the assertion received at other terminals, in particular to that which will authenticate the first client.
  • the terminal which wishes to authenticate the first client obtains without request, therefore spontaneously, the proof of the assertion from a terminal having received proof of the assertion.
  • the assertion is updated on a terminal, the latter transmits the update to d.
  • the data relating to the assertion is associated with an identifier representative of the identity provider at the origin. the taking of evidence; in this configuration, the authentication is further based on this identifier. It is thus possible to ascertain the origin of each data relating to the assertion stored in the terminal network; the identifier makes it possible to know which supplier is at the origin.
  • This identifier is preferably encrypted; the terminal wishing to authenticate having the key for decryption.
  • the encryption method is indifferently a symmetric or asymmetric encryption method.
  • the invention relates to a terminal characterized in that it comprises a. an assertion receiving module, received from a first client, obtained from an identity provider, b. a search module of a proof of the assertion in a memory of a terminal, c. an authentication module of the first client based on the assertion received from the first client and on data relating to the assertion from said memory of a terminal.
  • the invention relates to a computer program capable of being implemented on a terminal, comprising code instructions which, when the program is executed by a processor performs the steps defined above, with reference to the authentication method, namely a. a step of receiving an assertion, received from a first client, obtained from the identity provider, b. a step of searching for a proof of the assertion in a memory of a terminal, c. and in that an authentication of the first client is based on the assertion received from the first client and on data relating to the assertion from said memory of a terminal.
  • the invention relates to a management method by an identity provider of the authentication of a client in a communication network including a set of clients, characterized in that it comprises the following steps : at. a step of receiving an assertion request from a client, said first client, b. a step of transmitting an assertion to the first client; vs. a step of transmitting data relating to the assertion to a plurality of terminals for storage therein.
  • the supply of the data relating to the assertion for example a Hash of an assertion
  • the provision of the assertion data follows a request to obtain an assertion by the first client.
  • the provider transmits the data relating to the assertion without there being necessarily second client having a need to authenticate a first client.
  • the invention relates to an identity provider capable of managing the provision of an identification assertion to at least one client in a communication network, comprising a. a module for receiving an assertion request from a client, said first client, b. a first module for transmitting, to the first client, an assertion of identity; vs. a second module for transmitting data relating to the assertion to a plurality of terminals for storage therein.
  • the first transmission module also transmits, to a second client capable of requiring authentication, at least one address representative of the place of storage of the proof in the set composed by the destination terminals of the proof of the assertion.
  • the invention relates to a computer program capable of being implemented on a terminal, comprising code instructions which, when the program is executed by a processor performs the steps defined above, with reference to the management method namely: a. a first module for transmitting, to a first client, an assertion of identity; b. a second module for transmitting data relating to the assertion to a plurality of terminals for storage therein
  • the programs referred to above may use any programming language. They can be downloaded from a communication network and / or recorded on a computer-readable medium.
  • each of the devices comprises software means such as instructions of the aforementioned computer program, these instructions being executed by physical means such as at least one processor and a working memory.
  • FIGS. 1 and 3 are schematic views of a computer system illustrating embodiments of the invention.
  • FIG. 2 is a variant of the mode described in FIG.
  • Figure 4 is a variant related to the provision of proof to the network of terminals. Detailed description of an exemplary embodiment illustrating the invention
  • Figure 1 shows a computer system comprising a plurality of terminals and an identity provider.
  • the terminals are devices able to process data and are able to communicate with a network. These devices include a CPU processor, a memory MEM capable of storing data, a communication module COM to communicate with a communication network such as an Internet network, etc. All modules (processor, memory, etc.) are connected to each other via a bus.
  • the buses described above have the function of ensuring the transfer of digital data between the various circuits connected to the microprocessor by a bus.
  • the bus in question includes a data bus and a control bus.
  • the memories described above are permanent memories accessible in writing and reading, for example flash type.
  • the terminals also include a respective RAM for unsustainably storing calculation data used in the implementation of a method according to embodiments.
  • the terminals and the identity provider can communicate with each other through a communication network.
  • this network is the Internet network.
  • the example chosen to illustrate the invention is that of an authentication between people, for example in order to establish an audio-video conversation. Customers are therefore in our example two users. To simplify the presentation, these users are named Alice and Bob in the following.
  • the identity provider IDP of Alice which generates an assertion of identity on demand, and transmits according to the invention data relating to an assertion to terminals , namely an assertion or proof of the assertion depending on the requesting client, - a network of terminals RES formed by a set of terminals and forming a decentralized storage system for example Peer-to-Peer P2P mode in which the proof obtained by the identity provider will be distributed; network to which can belong or not the terminal T2 of BOB; we will see in the following variants of the method depending on whether or not the BOB terminal is in this set.
  • an assertion is a set of information about a customer provided by an authority such as an IdP provider for example. Its structure is usually defined by a standard; this is the case for the SAML standard.
  • An assertion can take the following form: "Jean Dupond was authenticated at 11:09 by means of his fingerprint. It has the list of attributes here, etc.
  • Figures 1 to 3 are embodiments of the method of the invention. In each mode described, it is assumed that Alice wants to prove her identity to Bob before establishing an audio-video communication between them.
  • a first mode is described with reference to Figure 1.
  • Alice registered with her identity provider
  • IDP IDP. This means that Alice has declared her identity to her IDP by possibly providing proof of this identity.
  • the identity provider then electronically records Alice's identity information so that she can provide it to a service - or a user - such as BOB to verify the assertion that Bob will receive from Alice.
  • a first ETl (AUT) step Alice authenticates with her IDP identity provider.
  • the identity provider applies a hash function to the assertion ID and obtains a value Hash (ID_A).
  • the value Hash (ID_A) constitutes data relating to the assertion; this value is, in our example, representative of a proof of an assertion.
  • a hash function is a method for characterizing information, data. By subjecting a sequence of reproducible processes to an input, this function generates a fingerprint for identifying the initial data.
  • a function is for example the algorithm MD2, or MD5, or SHA-1 known to those skilled in the art.
  • a hash function therefore takes a message of any size as input, applies a series of transformations and reduces these data.
  • We get at the output a string of hexadecimal characters, the digest, which summarizes somehow the file.
  • This output has a fixed size that varies according to the algorithms (128 bits for MD5 and 160 bits for SHA-1).
  • the invention is not limited to this function for obtaining proof of assertion. Other similar functions can be used instead of the hash function.
  • the IDP provider requires the recording of the resulting value on several terminals of the network RES.
  • the Hash value (ID_A) is at this stage registered on several terminals of the RES network.
  • the identity provider IDP stores a look-up table between the ADR memory address where the value Hash (ID) is stored on the terminals.
  • This address can be imposed by the provider to the terminals, or imposed by the terminals to the supplier. In the latter case, the terminal is able to transmit to the identity provider the address at which the value Hash (ID) has been stored.
  • this address ADR can be useful in the following for BOB to access the value Hash (ID_A).
  • the identity provider IDP provides Alice with an identity assertion ID_A. in our example, the address ADR is included or is a complement of the assertion.
  • the value Hash (ID_A), representative of the proof of the assertion is stored in the third step ET3 on a plurality of terminals of the network RES.
  • the terminal interrogates one or more terminals and requires obtaining the value Hash (ID_A) stored at ADR address.
  • a seventh step ET7 (Hash '(ID_A))
  • a check is made on the terminal of BOB to determine if the assertion ID_A, received from the first terminal of Alice , is the same as received from the RES network terminal. For this, the terminal applies the hash function to the assertion received from the ALICE terminal.
  • the parameters of the hash function used in the third step ET3 above are included in the assertion. If the calculated value is the same as (or corresponds to) the value received from the server, ALICE is considered to be authenticated.
  • the audio-video communication can take place during an eighth step.
  • FIG. 2 illustrates a variant in which the second terminal does not transmit a REQ request.
  • a terminal receiving the value Hash (ID_A), from the provider IDP automatically redirects the assertion to other terminals including the terminal T2.
  • the terminal T2 is one of the receiving terminals of the proof.
  • the BOB terminal is part of the terminals (step ET3bis) in the same way as the other terminals of the network RES, the steps described above are the same unlike the steps ET5 and ET6.
  • the BOB terminal instead of interrogating a terminal, obtains proof of the assertion in its own MEM memory.
  • the BOB terminal can then execute the seventh ET7 step described above.
  • step ET3 is performed without the provider receiving a request from a client wishing to authenticate another client.
  • the result of the calculation, the proof of the assertion is transmitted to predefined terminals.
  • the transmission can be made to a subset of terminals which then take care of propagating the proof of the assertion to other terminals, possibly the terminal T2.
  • the provider transmits the proof Hash (ID_A) to a terminal Ti which then propagates the proof to other terminals Tk and Tj.
  • the terminal Tk is responsible for transmitting the proof to terminals Tl and Tm, and so on.
  • a terminal network manager may be responsible for transmitting information to the provider relating to a use of a proof by a terminal, the information having no mention of the terminals involved by an authentication.
  • This variant can be useful for example for counting purposes while preserving the privacy of the terminals having used the proof stored in the network of terminals RES.
  • the proofs stored in the network of terminals RES are associated with an identifier that can be checked by Bob to authenticate Alice. It is thus possible to ascertain the origin of each record in the terminal network.
  • the nodes are interconnected by agreements and mutual trust.
  • An alternative version of this system relies on a consensus protocol that makes it possible to decide on a common version of the data without prior agreement or trust between the nodes.
  • This alternative version may be based on a terminal system of the type using a BlockChain such as Ethereum. We will not describe such a system in the present text because without interest to describe the invention. Please refer to the document at https://github.com/ethereum/wiki/wiki/White- Paper for more details.
  • each version Bob can be part of the terminal network so as to verify the identity assertion locally without an intermediary.
  • membership in the network according to the first alternative described above requires agreements and trust established with the other nodes.
  • the membership of the network of terminals is inappropriate for some devices (smartphones, tablets, connected objects, ).
  • Bob's terminal verify Alice's identity assertion via a terminal, for example a trusted intermediary. of his choice belonging to the network of terminals.
  • module used in the text may correspond to a software component or a hardware component or a set of hardware and software components, a software component corresponding to one or more programs or subprograms. computer 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 set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.) -

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention a trait à un procédé d'authentification d'un premier client par un deuxième client dans un réseau de communication incluant un ensemble (RES) de terminaux et un fournisseur d'identité (IDP) apte à fournir un donnée relative à une assertion d'identité (ID_A), caractérisé en ce qu'il comprend les étapes suivantes sur le terminal associé au deuxième client : - une étape de réception d'une assertion (ID_A), reçue depuis un premier client, obtenue auprès d'un fournisseur d'identité, - une étape de recherche d'une donnée relative à l'assertion (Hash(ID_A)) dans une mémoire d'un terminal, - et en ce qu'une authentification du premier client se base sur l'assertion (ID_A) reçue du premier client et sur une donnée relative à l'assertion (Hash(ID_A)) issue de ladite mémoire d'un terminal.

Description

Procédé de gestion de l'authentification d'un client dans un système informatique
Domaine technique
L'invention se rapporte à un procédé de gestion de l'authentification d'un client dans un système informatique.
Le client peut être soit un utilisateur d'un terminal, soit un terminal.
Le terminal en question englobe tout dispositif de traitement de données, c'est-à-dire équipé de ressources physiques et/ou logicielles dont au moins un microprocesseur, apte à communiquer au travers d'un réseau de communication. Le terminal peut être part exemple un téléphone mobile, un ordinateur, un PDA, etc.
Le réseau de communication est quelconque. Celui-ci est par exemple le réseau Internet.
Etat de la technique Les systèmes de gestion d'identités sont définis par différents organismes de normalisation tels que par l'OpenlD Foundation et la spécification OpenID Connect (basée sur OAuth 2 de l'IETF), ou « OASIS » (qui définit « SAML » pour « Security Assertions Markup Language », « Langage à balise d'assertions de sécurité »). Dans ces systèmes, lors d'une authentification homme à homme ou homme à machine, un premier client (homme ou machine), ci-après désigné par Alice, s'authentifie auprès d'un fournisseur d'identité IdP. Rappelons qu'un fournisseur d'identité a pour fonction notamment d'authentifier un utilisateur ainsi que de récupérer des informations additionnelles associées à son identité. En retour, le fournisseur IdP fournit une assertion d'identité à Alice, c'est à dire un document assurant que le client est identifié, et qu'Alice pourra fournir à un autre client pour s'identifier auprès de cet autre client. Ce document contient en général des éléments d'identité propres à Alice et connus par son fournisseur d'identité, ainsi que les moyens par lesquels ce fournisseur s'est assuré que l'utilisateur se réclamant être Alice a bien été authentifié en tant que tel.
Après réception de l'assertion, supposons que Alice souhaite entrer en relation avec un client (homme ou machine) appelé Bob par la suite. Avant la mise en relation, BOB va authentifier Alice. Pour cela, Alice transmet l'assertion reçue du fournisseur d'identité à Bob ; Bob contacte ensuite le fournisseur d'identité d'Alice afin de vérifier que l'assertion reçue depuis Alice à bien été émise par ce fournisseur IDP. Cette confirmation permet à Bob de s'assurer qu'Alice avec qui une communication va être établie est bien le même client que celui enregistré auprès du fournisseur IdP ;
Ainsi Bob authentifie-t-il Alice en obtenant la preuve de l'assertion auprès du fournisseur d'identité. Pour réaliser l'authentification d'Alice, Bob doit donc contacter le fournisseur IdP d'Alice. En position d'intermédiaire central, le fournisseur IdP a inévitablement connaissance des clients concernés par une demande d'obtention d'une assertion ; dans l'exemple ci-dessus ; le fournisseur sait que Alice veut communiquer avec Bob. Cela pose un problème de respect de la vie privée d'Alice et de Bob.
L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique. L'invention
A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé d'authentification d'un premier client par un deuxième client dans un réseau de communication incluant un ensemble de terminaux et un fournisseur d'identité apte à fournir un donnée relative à une assertion d'identité, caractérisé en ce qu'il comprend les étapes suivantes sur le terminal associé au deuxième client a. une étape de réception d'une assertion, reçue depuis un premier client, obtenue auprès du fournisseur d'identité, b. une étape de recherche d'une donnée relative à l'assertion dans une mémoire d'un terminal, c. et en ce qu'une authentification du premier client se base sur l'assertion reçue du premier client et sur une donnée relative à l'assertion issue de ladite mémoire d'un terminal.
Selon l'invention, une donnée relative à l'assertion, représentative d'une preuve d'une assertion, au lieu d'être stockée et centralisée au niveau du fournisseur d'identité, est stockée sur un voire plusieurs terminaux distincts du fournisseur d'identité. De cette manière, lorsqu'un deuxième client souhaite authentifier un premier client, le deuxième client obtient la donnée relative à une assertion au mieux en local s'il fait partie des terminaux ayant reçus la donnée relative à l'assertion, ou dans le cas contraire en interrogeant un terminal ayant reçu la donnée concernée. Le terminal interrogé étant distinct du fournisseur d'identité, l'invention permet à un utilisateur de vérifier une assertion sans que le fournisseur d'identité ne soit impliqué dans la vérification. Le fournisseur d'identité n'a donc jamais connaissance des clients à l'origine d'une demande d'accès à une donnée relative à l'assertion, en l'espèce la preuve de l'assertion.
A noter que la donnée relative peut être l'assertion elle-même ou une donnée dérivée de l'assertion. On verra, par la suite, que, pour des raisons de sécurité, cette donnée est dérivée de l'assertion par application d'une fonction de hachage sur l'assertion.
Le système de stockage décentralisé est formé par des terminaux qui constituent un réseau de nœuds stockant des copies de la preuve de l'assertion.
Selon un mode de mise en œuvre particulier de l'invention, le procédé comprend en outre une étape de réception d'une adresse mémoire où est stockée ladite donnée dans la mémoire dudit terminal. Dans cette configuration, le deuxième client sait où est stockée la preuve de l'assertion dans l'ensemble composé par les terminaux. Selon une variante de ce mode, si la donnée relative à l'assertion est stockée sur plusieurs terminaux, le deuxième client peut recevoir une voire plusieurs adresses correspondant aux lieux de stockage de la donnée sur ces terminaux respectivement.
Selon un mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le terminal associé au deuxième client fait partie d'un ensemble de terminaux stockant la donnée relative à l'assertion, et l'étape de recherche comprend une étape de lecture de l'assertion dans une mémoire du terminal associé au deuxième client. Dans cette configuration, le terminal qui authentifie dispose de la preuve d'assertion dans sa propre mémoire. Ce mode évite au terminal qui authentifie d'interroger un autre terminal.
Selon encore un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, le terminal associé au deuxième client est distinct d'un ensemble de terminaux stockant la donnée relative à l'assertion, à savoir la preuve de l'assertion ; de plus, l'étape de recherche comprend une étape de transmission d'une requête d'accès à l'assertion à destination d'un terminal stockant la donnée. Cette variante est intéressante lorsque le terminal associé au deuxième client a des ressources limitées. En effet, la gestion du stockage de la donnée relative à l'assertion peut impliquer une consommation électrique importante et donc avoir un impact négatif sur l'autonomie du terminal lorsque ce dernier est alimenté avec une batterie.
Selon encore un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, le terminal qui authentifie est distinct de la pluralité de terminaux sur lesquels sont stockés la preuve de l'assertion. Dans cette configuration, le procédé comprend une étape de transmission, par un terminal, de l'assertion reçue à d'autres terminaux en particulier à celui qui va authentifier le premier client. De cette manière, bien que ne faisant pas partie des terminaux auxquels le fournisseur a transmis la preuve de l'assertion, le terminal qui souhaite authentifier le premier client obtient sans requête, donc spontanément, la preuve de l'assertion depuis un terminal ayant reçu la preuve de l'assertion. Selon encore un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, si l'assertion est mise à jour sur un terminal, ce dernier transmet la mise à jour à d'autres terminaux. De cette manière, lorsqu'une modification d'une preuve d'une assertion est soumise à un terminal, celui-ci la propage aux autres terminaux. Cette caractéristique assure que la preuve de l'assertion mise à jour est disponible quel que soit le terminal interrogé pour réaliser une authentification du premier client. Ce mode présente aussi l'avantage pour un terminal de ne pas influer sur son autonomie électrique car transmettre une requête implique une consommation électrique.
Selon encore un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, la donnée relative à l'assertion est associée à un identifiant représentatif du fournisseur d'identité à l'origine de l'obtention de la preuve ; dans cette configuration, l'authentification se base en outre sur cet identifiant. Il est ainsi possible de s'assurer de l'origine de chaque donnée relative à l'assertion stockée dans le réseau de terminaux ; l'identifiant permet de savoir quel fournisseur en est à l'origine. Cet identifiant est de préférence chiffré ; le terminal souhaitant authentifier disposant de la clé permettant le déchiffrement. La méthode de chiffrement est indifféremment une méthode de chiffrement symétrique ou asymétrique.
Selon un aspect matériel, l'invention se rapporte à un terminal caractérisé en ce qu'il comprend a. un module de réception d'une assertion, reçue depuis un premier client, obtenue auprès d'un fournisseur d'identité, b. un module de recherche d'une preuve de l'assertion dans une mémoire d'un terminal, c. un module d'authentification du premier client se basant sur l'assertion reçue du premier client et sur une donnée relative à l'assertion issue de ladite mémoire d'un terminal. Selon un autre aspect matériel, l'invention se rapporte à un programme d'ordinateur apte à être mis en œuvre sur un terminal, comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies ci-dessus, en référence au procédé d'authentification, à savoir a. une étape de réception d'une assertion, reçue depuis un premier client, obtenue auprès du fournisseur d'identité, b. une étape de recherche d'une preuve de l'assertion dans une mémoire d'un terminal, c. et en ce qu'une authentification du premier client se base sur l'assertion reçue du premier client et sur une donnée relative à l'assertion issue de ladite mémoire d'un terminal.
Selon un autre aspect fonctionnel l'invention se rapporte à un procédé de gestion par un fournisseur d'identité de l'authentification d'un client dans un réseau de communication incluant un ensemble de clients, caractérisé en ce qu'il comprend les étapes suivantes : a. une étape de réception d'une demande d'assertion issue d'un client, dit premier client, b. une étape de transmission d'une assertion à destination du premier client ; c. une étape de transmission d'une donnée relative à l'assertion à destination d'une pluralité des terminaux pour y être stockée.
A la différence de l'état de la technique, où la fourniture de la donnée relative à l'assertion, par exemple un Hash d'une assertion, est réalisée sur demande d'un deuxième client souhaitant authentifier un premier client ; dans l'invention, la fourniture de la donnée relative à l'assertion fait suite à une demande d'obtention d'une assertion par le premier client. En d'autres mots, le fournisseur transmet la donnée relative à l'assertion sans qu'il y ait nécessairement de deuxième client ayant un besoin d'authentifier un premier client.
Selon un autre aspect matériel, l'invention se rapporte à un fournisseur d'identité apte à gérer la fourniture d'une assertion d'identification à au moins un client dans un réseau de communication, comprenant a. un module de réception d'une demande d'assertion issue d'un client, dit premier client, b. un premier module de transmission, au premier client, d'une assertion d'identité ; c. un deuxième module de transmission d'une donnée relative à l'assertion à destination d'une pluralité des terminaux pour y être stocké.
Selon un mode de réalisation, le premier module de transmission transmet en outre à destination d'un deuxième client apte à requérir une authentification, au moins une adresse représentative du lieu de stockage de la preuve dans l'ensemble composé par les terminaux destinataire de la preuve de l'assertion.
Selon un autre aspect matériel, l'invention se rapporte à un programme d'ordinateur apte à être mis en œuvre sur un terminal, comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies ci-dessus, en référence au procédé de gestion à savoir : a. un premier module de transmission, à un premier client, d'une assertion d'identité ; b. un deuxième module de transmission d'une donnée relative à l'assertion à destination d'une pluralité des terminaux pour y être stocké Les programmes visés ci-dessus peuvent utiliser n'importe quel langage de programmation. Ils peuvent être téléchargés depuis un réseau de communication et/ou enregistrés sur un support lisible par ordinateur.
Bien entendu, chacun des équipements (terminaux, fournisseur d'identité) comporte des moyens logiciels tels que des instructions du programme informatique précité, ces instructions étant exécutées par des moyens physiques tels qu'au moins un processeur et une mémoire de travail.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés sur lesquels : Les figures 1 et 3 sont des vues schématiques d'un système informatique illustrant des modes de réalisation de l'invention.
La figure 2 est une variante du mode décrit sur la figure 1.
La figure 4 est une variante liée à la fourniture de la preuve au réseau de terminaux. Description détaillée d'un exemple de réalisation illustrant l'invention
La figure 1 représente un système informatique comprenant plusieurs terminaux et un fournisseur d'identités.
Les terminaux sont des dispositifs aptes à traiter de données et sont aptes à communiquer avec un réseau. Ces dispositifs incluent un processeur CPU, une mémoire MEM apte à stocker des données, un module de communication COM pour communiquer avec un réseau de communication tel qu'un réseau internet, etc. Tous les modules (processeur, mémoire, etc.) sont reliés entre eux par l'intermédiaire d'un bus. A noter que les bus décrits ci-dessus ont pour fonction d'assurer le transfert de données numériques entre les différents circuits reliés au microprocesseur par un bus. Dans notre exemple, le bus en question inclut un bus de données et un bus de contrôle. A noter aussi que, dans notre exemple, les mémoires décrites ci-dessus sont des mémoires permanentes accessibles en écriture et lecture, par exemple de type flash.
Les terminaux incluent également une mémoire vive respective pour stocker de manière non durable des données de calcul utilisées lors de la mise en œuvre d'un procédé selon des modes de réalisation.
Les terminaux et le fournisseur d'identité peuvent communiquer entre eux au travers d'un réseau de communication. Dans notre exemple, ce réseau est le réseau Internet. L'exemple choisi pour illustrer l'invention est celui d'une authentification entre personnes, par exemple afin d'établir une conversation audio-vidéo. Les clients sont donc dans notre exemple deux utilisateurs. Pour simplifier l'exposé, ces utilisateurs sont nommés Alice et Bob dans la suite.
Rappelons qu'une authentification d'un premier client par un deuxième client permet au deuxième client de vérifier que l'identité revendiquée par le premier client est légitime.
Dans notre exemple, on considère les acteurs sont:
- deux terminaux Tl et T2 appartenant à Alice et Bob, respectivement, - le fournisseur d'identité IDP d'Alice qui génère une assertion d'identité sur demande, et transmet conformément à l'invention des données relatives à une assertion à des terminaux, à savoir une assertion ou une preuve de l'assertion en fonction du client demandeur, - un réseau de terminaux RES formé par un ensemble de terminaux et formant un système de stockage décentralisé par exemple en mode Peer-to-Peer P2P dans lequel la preuve obtenue par le fournisseur d'identité sera répartie ; réseau auquel peut appartenir ou non le terminal T2 de BOB ; on verra dans la suite des variantes du procédé selon que le terminal de BOB est ou non dans cet ensemble.
Rappelons qu'une assertion est un ensemble d'informations à propos d'un client fournies par une autorité comme un fournisseur IdP par exemple. Sa structure est généralement définie par une norme ; c'est le cas pour la norme SAML. Une assertion peut prendre la forme suivante : « Jean Dupond a été authentifié à 11 heures 09 au moyen de son empreinte digitale. Il possède la liste d'attributs que voici, etc. » Les figures 1 à 3 sont des modes de réalisation du procédé de l'invention. Dans chaque mode décrit, on fait l'hypothèse qu'Alice souhaite prouver son identité auprès de Bob avant un établissement d'une communication audio-vidéo entre eux.
Un premier mode est décrit en référence à la figure 1. Au préalable, Alice s'est enregistrée auprès de son fournisseur d'identité
IDP. Cela signifie qu'Alice a déclaré son identité auprès de son IDP en fournissant éventuellement des preuves de cette identité. Le fournisseur d'identité a ensuite enregistré électroniquement les informations relatives à l'identité d'Alice, de manière à pouvoir les fournir à un service - ou un utilisateur - par exemple BOB pour vérifier l'assertion que Bob recevra d'Alice.
Suite à cette phase préalable d'enregistrement ENR, en référence à la figure 1, les étapes se réalisent de la manière suivante :
Lors d'une première étape ETl(AUT), Alice s'authentifie auprès de son fournisseur d'identité IDP. Lors d'une deuxième étape ET2(ID_A), le fournisseur d'identité applique une fonction de hachage à l'assertion ID et obtient une valeur Hash(ID_A). La valeur Hash(ID_A) constitue une donnée relative à l'assertion ; cette valeur est, dans notre exemple, représentative d'une preuve d'une assertion. Rappelons qu'une fonction de hachage est une méthode permettant de caractériser une information, une donnée. En faisant subir une suite de traitements reproductibles à une entrée, cette fonction génère une empreinte servant à identifier la donnée initiale. Une telle fonction est par exemple l'algorithme MD2, ou MD5, ou SHA-1 connus de l'homme du métier.
Une fonction de hachage prend donc en entrée un message de taille quelconque, applique une série de transformations et réduit ces données. On obtient à la sortie une chaîne de caractères hexadécimaux, le condensé, qui résume en quelque sorte le fichier. Cette sortie a une taille fixe qui varie selon les algorithmes (128 bits pour MD5 et 160 bits pour SHA-1).
L'invention ne se limite pas à cette fonction pour l'obtention d'une preuve d'assertion. D'autres fonctions similaires peuvent être utilisées en lieu et place de la fonction de hachage. Lors d'une troisième étape ET3, le fournisseur IDP requiert l'enregistrement de la valeur résultante sur plusieurs terminaux du réseau RES. La valeur Hash(ID_A) est à ce stade enregistrée sur plusieurs terminaux du réseau RES.
Dans notre exemple, le fournisseur d'identité IDP stocke une table de correspondance entre l'adresse mémoire ADR où la valeur Hash(ID) est stockée sur les terminaux. Cette adresse peut être imposée par le fournisseur aux terminaux, ou imposée par les terminaux au fournisseur. Dans ce dernier cas, le terminal est apte à transmettre au fournisseur d'identité l'adresse à laquelle la valeur Hash(ID) a été stockée. A noter que cette adresse ADR peut être utile dans la suite pour BOB pour accéder à la valeur Hash(ID_A).
A noter que cette adresse peut être fournie directement par le fournisseur d'identité IDP. Lors d'une quatrième étape, le fournisseur d'identité IDP fournit à Alice une assertion d'identité ID_A. dans notre exemple, l'adresse ADR est incluse ou est un complément de l'assertion.
Plusieurs cas de figure vont être décrits selon que le terminal de BOB fait partie des terminaux destinataires de la preuve de l'assertion ou non. Ces deux cas sont illustrés en référence aux figures 1 et 3 sur lesquelles le terminal T2 ne fait pas partie des terminaux et fait partie des terminaux, respectivement.
Selon un premier cas de figure illustré sur la figure 1, la valeur Hash(ID_A), représentative de la preuve de l'assertion, est stockée à la troisième étape ET3 sur une pluralité de terminaux du réseau RES.
Dans cette configuration, lors d'une cinquième étape ET5(REQ), le terminal interroge un voire plusieurs terminaux et requiert l'obtention de la valeur Hash(ID_A) stockée à l'adresse ADR.
Un terminal, voire plusieurs terminaux, répondent lors d'une sixième étape ET6(Hash(ID_A)).
Après réception de la valeur, lors d'une septième étape ET7 (Hash'(ID_A)), de manière classique, une vérification est faite sur le terminal de BOB pour déterminer si l'assertion ID_A, reçue depuis le premier terminal d'Alice, est la même que celle reçue depuis le terminal du réseau RES. Pour cela, le terminal applique la fonction de hachage à l'assertion reçue du terminal d'ALICE. Les paramètres de la fonction de hachage utilisés à la troisième étape ET3 ci- dessus sont inclues dans l'assertion. Si la valeur calculée est la même que (ou correspond à) la valeur reçue du serveur, on considère que ALICE est authentifiée. La communication audio-vidéo peut avoir lieu lors d'une huitième étape.
La figure 2 illustre une variante dans laquelle le deuxième terminal ne transmet pas de requête REQ. Dans cette variante, un terminal recevant la valeur Hash(ID_A), depuis le fournisseur IDP, redirige automatiquement l'assertion vers d'autres terminaux dont le terminal T2. Selon un deuxième cas de figure, en référence à la figure 3, le terminal T2 fait partie des terminaux destinataires de la preuve. Dans le cas où le terminal de BOB fait partie des terminaux (étape ET3bis) au même titre que les autres terminaux du réseau RES, les étapes décrites ci-dessus sont les mêmes à la différence des étapes ET5 et ET6. Le terminal de BOB, au lieu d'interroger un terminal, obtient la preuve de l'assertion dans sa propre mémoire MEM. Le terminal de BOB peut alors exécuter la septième étape ET7 décrite ci-dessus.
Dans les exemples qui précèdent, l'étape ET3 s'effectue sans que le fournisseur ne reçoive de requête d'un client souhaitant authentifier un autre client. En d'autres mots, suite au calcul de Hash(ID_A), le résultat du calcul, la preuve de l'assertion, est transmis à destination de terminaux prédéfinis.
Aussi, la transmission peut être faite à un sous-ensemble de terminaux qui se chargent ensuite de propager la preuve de l'assertion aux autres terminaux, éventuellement le terminal T2. Par exemple, en référence à la figure 4, le fournisseur transmet la preuve Hash(ID_A) a un terminal Ti qui propage ensuite la preuve à d'autres terminaux Tk et Tj. Sur cette même figure, le terminal Tk se charge de transmettre la preuve à des terminaux Tl et Tm, et ainsi de suite.
Selon une autre variante, un gestionnaire du réseau de terminaux peut être chargé d'émettre une information au fournisseur relative à une utilisation d'une preuve par un terminal, l'information ne comportant aucune mention des terminaux impliqués par une authentification. Cette variante peut être utile par exemple à des fins de comptage tout en préservant la vie privée des terminaux ayant utilisés la preuve stockée dans le réseau de terminaux RES. Selon une autre variante, les preuves stockées dans le réseau de terminaux RES sont associées à un identifiant qui peut être vérifié par Bob pour authentifier Alice. Il est ainsi possible de s'assurer de l'origine de chaque enregistrement dans le réseau de terminaux.
D'une manière générale, deux versions du système de stockage décentralisé sont possibles. Dans une première version, les nœuds sont liés entre eux par des accords et une confiance mutuelle.
Une version alternative de ce système repose sur un protocole de consensus permettant de décider d'une version commune des données sans accord ou confiance préalablement établis entre les nœuds. Cette version alternative peut reposer sur un système de terminaux du type utilisant une BlockChain tel qu'Ethereum. Nous ne décrirons pas un tel système dans le présent texte car sans intérêt pour décrire l'invention. On se reportera au document se trouvant à l'adresse https://github.com/ethereum/wiki/wiki/White- Paper pour plus de détails.
Comme on l'a vu dans l'exemple de réalisation, dans chague version, Bob peut faire partie du réseau des terminaux de manière à vérifier l'assertion d'identité en local sans intermédiaire. Cependant l'appartenance au réseau selon la première alternative décrite ci-dessus nécessite des accords et une confiance établie avec les autres nœuds. Par ailleurs appartenir au réseau de terminaux, quelle que soit l'alternative visée ci-dessus, nécessite de participer à son maintien à jour. Coûteuse en énergie et en mémoire, l'appartenance au réseau de terminaux est inappropriée pour certains appareils (smartphones, tablettes, objets connectés, ...). Dans les deux alternatives, dans le cas où le terminal de BOB est inapproprié pour appartenir au réseau de terminaux, il est préférable gue le terminal de Bob vérifie l'assertion d'identité d'Alice via un terminal, par exemple un intermédiaire de confiance de son choix appartenant au réseau de terminaux.
Précisons gue le terme module utilisé dans le texte peut correspondre aussi bien à un composant logiciel gu'à 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 gue 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.)-

Claims
Procédé d'authentification d'un premier client par un deuxième client dans un réseau de communication incluant un ensemble (RES) de terminaux et un fournisseur d'identité (IDP) apte à fournir un donnée relative à une assertion d'identité (ID_A), caractérisé en ce qu'il comprend les étapes suivantes sur le terminal associé au deuxième client : a. une étape de réception d'une assertion (ID_A), reçue depuis un premier client, obtenue auprès du fournisseur d'identité, b. une étape de recherche d'une donnée relative à l'assertion (Hash(ID_A)) dans une mémoire d'un terminal, ladite donnée provenant du fournisseur, c. et en ce qu'une authentification du premier client se base sur l'assertion (ID_A) reçue du premier client et sur la donnée relative à l'assertion (Hash(ID_A)) issue de ladite mémoire d'un terminal.
Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de réception d'une adresse mémoire (ADR) où est stockée ladite donnée dans la mémoire dudit terminal.
Procédé d'authentification selon la revendication 1, caractérisé en ce que le terminal associé au deuxième client fait partie d'un ensemble de terminaux stockant la donnée relative à l'assertion, et en ce que l'étape de recherche comprend une étape de lecture de l'assertion dans une mémoire du terminal associé au deuxième client.
Procédé d'authentification selon la revendication 1 ou 2, caractérisé en ce que le terminal associé au deuxième client est distinct d'un ensemble de terminaux stockant la donnée relative à l'assertion, et en ce que l'étape de recherche comprend une étape de transmission d'une requête d'accès à l'assertion à destination d'un terminal stockant la donnée.
Procédé d'authentification selon la revendication 1 ou 2, caractérisé en ce que la donnée relative à l'assertion est associée à un identifiant représentatif du fournisseur d'identité à l'origine de l'obtention preuve et en ce que l'authentification se base en outre sur cet identifiant.
Terminal (T2) caractérisé en ce qu'il comprend a. un module de réception d'une assertion relative à un premier client, délivrée par un fournisseur d'identité, b. un module de recherche d'une donnée relative à l'assertion dans une mémoire d'un terminal, ladite donnée provenant du fournisseur, c. un module d'authentification du premier client se basant sur l'assertion reçue du premier client et sur la donnée relative à l'assertion issue de ladite mémoire d'un terminal. programme d'ordinateur apte à être mis en œuvre sur un terminal, comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans la revendication 1.
Procédé de gestion par un fournisseur d'identité de l'authentification d'un client dans un réseau de communication incluant un ensemble de clients, caractérisé en ce qu'il comprend les étapes suivantes : a. une étape de réception d'une demande d'assertion issue d'un client, dit premier client, b. une étape de transmission d'une assertion à destination du premier client ; c. une étape de transmission d'une donnée relative à l'assertion à destination d'une pluralité de terminaux pour y être stockée.
9. Fournisseur d'identité (IDP) apte à gérer la fourniture d'une assertion d'identification (ID_A) à au moins un client (Alice, Bob) dans un réseau de communication, comprenant a. un module de réception d'une demande d'assertion issue d'un client (Alice), dit premier client, b. un premier module de transmission, au premier client, d'une assertion d'identité (ID_A) ; c. un deuxième module de transmission d'une donnée relative à l'assertion (Hash(ID_A)) à destination d'une pluralité des terminaux pour y être stockée.
10. Fournisseur d'identité (IDP) selon la revendication 9, caractérisé en ce que le premier module de transmission transmet en outre à destination du deuxième client apte à requérir une authentification, au moins une adresse représentative du lieu de stockage de la preuve dans l'ensemble composé par les terminaux.
11. Programme d'ordinateur apte à être mis en œuvre sur un terminal, comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans la revendication 8.
PCT/FR2016/051601 2015-07-03 2016-06-28 Procédé de gestion de l'authentification d'un client dans un système informatique WO2017006013A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1556328A FR3038413A1 (fr) 2015-07-03 2015-07-03 Procede de gestion de l'authentification d'un client dans un systeme informatique
FR1556328 2015-07-03

Publications (1)

Publication Number Publication Date
WO2017006013A1 true WO2017006013A1 (fr) 2017-01-12

Family

ID=54608667

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/051601 WO2017006013A1 (fr) 2015-07-03 2016-06-28 Procédé de gestion de l'authentification d'un client dans un système informatique

Country Status (2)

Country Link
FR (1) FR3038413A1 (fr)
WO (1) WO2017006013A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060200664A1 (en) * 2005-03-07 2006-09-07 Dave Whitehead System and method for securing information accessible using a plurality of software applications
US20080010288A1 (en) * 2006-07-08 2008-01-10 Hinton Heather M Method and system for distributed retrieval of data objects within multi-protocol profiles in federated environments
US20090158394A1 (en) * 2007-12-18 2009-06-18 Electronics And Telecommunication Research Institute Super peer based peer-to-peer network system and peer authentication method thereof
WO2009122162A1 (fr) * 2008-03-31 2009-10-08 British Telecommunications Public Limited Company Gestion d'identité
WO2012129503A1 (fr) * 2011-03-23 2012-09-27 Interdigital Patent Holdings, Inc. Systèmes et procédés pour sécuriser des communications réseau

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060200664A1 (en) * 2005-03-07 2006-09-07 Dave Whitehead System and method for securing information accessible using a plurality of software applications
US20080010288A1 (en) * 2006-07-08 2008-01-10 Hinton Heather M Method and system for distributed retrieval of data objects within multi-protocol profiles in federated environments
US20090158394A1 (en) * 2007-12-18 2009-06-18 Electronics And Telecommunication Research Institute Super peer based peer-to-peer network system and peer authentication method thereof
WO2009122162A1 (fr) * 2008-03-31 2009-10-08 British Telecommunications Public Limited Company Gestion d'identité
WO2012129503A1 (fr) * 2011-03-23 2012-09-27 Interdigital Patent Holdings, Inc. Systèmes et procédés pour sécuriser des communications réseau

Also Published As

Publication number Publication date
FR3038413A1 (fr) 2017-01-06

Similar Documents

Publication Publication Date Title
EP2819052B1 (fr) Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique
US10693839B2 (en) Digital media content distribution blocking
FR3058243A1 (fr) Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique
FR3082023A1 (fr) Une application logicielle et un serveur informatique pour authentifier l’identite d’un createur de contenu numerique et l’integrite du contenu du createur publie
FR3013541A1 (fr) Procede et dispositif pour la connexion a un service distant
FR2985149A1 (fr) 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
FR3058540A1 (fr) Procede de gestion d'autorisation dans une communaute d'objets connectes
US10333917B2 (en) Controlling access to electronic resources based on a user's sociometric identification document
Alizadeh et al. Comparative analysis of decentralized identity approaches
FR3104870A1 (fr) Plateforme sécurisée, décentralisée, automatisée et multi-acteurs de gestion d’identités d’objets au travers de l’utilisation d’une technologie de chaîne de blocs.
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
FR3015824A1 (fr) Obtention de donnees de connexion a un equipement via un reseau
FR3074592A1 (fr) Procede de partage d'une cle servant a deriver des cles de session pour crypter et authentifier des communications entre un objet et un serveur
WO2017006013A1 (fr) Procédé de gestion de l'authentification d'un client dans un système informatique
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
WO2020201134A1 (fr) Procedes et dispositifs permettant de prouver la connaissance d'une donnee par un utilisateur d'une chaine de blocs
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
EP4128700A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
WO2022096824A1 (fr) Procede de delegation d'acces a une chaine de blocs
EP3672193A1 (fr) Procédé et système d'authentification d'un terminal client par un serveur cible, par triangulation via un serveur d'authentification
FR3129504A1 (fr) Procédés, terminal et serveur de gestion de données personnelles
EP4078922A1 (fr) Procédé d'obtention d'une commande relative à un profil d'accès réseau d'un module de sécurité de type euicc
FR2947686B1 (fr) Systeme et procede evolutif de gestion et d'agregation de plusieurs identifiants autour d'un authentifiant polymorphe
CN114117357A (zh) 基于区块链的内容授权分发方法及装置和电子设备
FR3103072A1 (fr) procédé de configuration d’accès à un service Internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16750897

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16750897

Country of ref document: EP

Kind code of ref document: A1