FR3038413A1 - Procede de gestion de l'authentification d'un client dans un systeme informatique - Google Patents

Procede de gestion de l'authentification d'un client dans un systeme informatique Download PDF

Info

Publication number
FR3038413A1
FR3038413A1 FR1556328A FR1556328A FR3038413A1 FR 3038413 A1 FR3038413 A1 FR 3038413A1 FR 1556328 A FR1556328 A FR 1556328A FR 1556328 A FR1556328 A FR 1556328A FR 3038413 A1 FR3038413 A1 FR 3038413A1
Authority
FR
France
Prior art keywords
assertion
client
terminal
terminals
data relating
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.)
Withdrawn
Application number
FR1556328A
Other languages
English (en)
Inventor
Kevin Corre
Vincent Frey
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
Priority to FR1556328A priority Critical patent/FR3038413A1/fr
Priority to PCT/FR2016/051601 priority patent/WO2017006013A1/fr
Publication of FR3038413A1 publication Critical patent/FR3038413A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/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

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 second client souhaite authentifier un premier client, le second 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 second 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 realtive à l'assertion est stockée sur plusieurs terminaux, le second 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 second 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 second 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 second client est distinct d'un ensemble de terminaux stockant la donnée relative à l'assertion, à savoir la preuve de 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. Cette variante est intéressante lorsque le terminal associé au second 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 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ées relative à l'assertion, par exemple un Hash d'une assertion, est réalisée sur demande d'un second 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 second 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 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 du second client 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 second client permet au second 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 second 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://aithub.com/ethereum/wiki/wiki/White-Paper pour plus de détails.
Comme on l'a vu dans l'exemple de réalisation, dans chaque 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 que 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 que le terme module utilisé dans le texte 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.)·

Claims (11)

  1. Revendications
    1. 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.
  2. 2. 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.
  3. 3. Procédé d'authentification selon la revendication 1, caractérisé en ce que le terminal associé au second client fait partie d'un ensemble de terminaux stockant la données 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 second client.
  4. 4. Procédé d'authentification selon la revendication 1 ou 2, caractérisé en ce que le terminal associé au second 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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 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. 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 premier client (Alice), 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. 10. Fournisseur d'identité (IDP) selon la revendication 9, caractérisé en ce que le premier module de transmission transmet en outre à destination du second client au moins une adresse représentative du lieu de stockage de la preuve dans l'ensemble composé par les terminaux.
  11. 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.
FR1556328A 2015-07-03 2015-07-03 Procede de gestion de l'authentification d'un client dans un systeme informatique Withdrawn FR3038413A1 (fr)

Priority Applications (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
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

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
FR3038413A1 true FR3038413A1 (fr) 2017-01-06

Family

ID=54608667

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1556328A Withdrawn FR3038413A1 (fr) 2015-07-03 2015-07-03 Procede de gestion de l'authentification d'un client dans un systeme 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
WO2017006013A1 (fr) 2017-01-12

Similar Documents

Publication Publication Date Title
CN107483509A (zh) 一种身份验证方法、服务器及可读存储介质
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
FR3044499A1 (fr) Methode d'etablissement d'une communication securisee de bout en bout entre le terminal d'un utilisateur et un objet connecte
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
FR3029665A1 (fr) Procede mis en œuvre dans un document d'identite et document d'identite associe
Alizadeh et al. Comparative analysis of decentralized identity approaches
US20180191698A1 (en) Controlling access to electronic resources based on a user's sociometric identification document
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
WO2020257123A1 (fr) Systèmes et procédés d'authentification reposant sur une chaîne de blocs
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
FR2900523A1 (fr) Identification de noeuds dans un reseau
WO2022096824A1 (fr) Procede de delegation d'acces a une chaine de blocs
EP4128700A1 (fr) Procede et dispositif d'authentification d'un utilisateur aupres d'une application
FR3129504A1 (fr) Procédés, terminal et serveur de gestion de données personnelles
CN114117357A (zh) 基于区块链的内容授权分发方法及装置和电子设备
EP3672193A1 (fr) Procédé et système d'authentification d'un terminal client par un serveur cible, par triangulation via un serveur d'authentification
FR3105696A1 (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

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20170106

ST Notification of lapse

Effective date: 20170331