[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

FR3058243A1 - Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique - Google Patents

Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique Download PDF

Info

Publication number
FR3058243A1
FR3058243A1 FR1752724A FR1752724A FR3058243A1 FR 3058243 A1 FR3058243 A1 FR 3058243A1 FR 1752724 A FR1752724 A FR 1752724A FR 1752724 A FR1752724 A FR 1752724A FR 3058243 A1 FR3058243 A1 FR 3058243A1
Authority
FR
France
Prior art keywords
data
identity
user
confidentiality
control device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1752724A
Other languages
English (en)
Other versions
FR3058243B1 (fr
Inventor
Herve Chabanne
Thomas CHENEVIER
Laurent Lambert
Olivier Clemot
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.)
Idemia Identity & Security France Fr
Original Assignee
Safran Identity and Security SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Safran Identity and Security SAS filed Critical Safran Identity and Security SAS
Priority to EP17198045.1A priority Critical patent/EP3316549B1/fr
Priority to US15/798,153 priority patent/US10817967B2/en
Publication of FR3058243A1 publication Critical patent/FR3058243A1/fr
Application granted granted Critical
Publication of FR3058243B1 publication Critical patent/FR3058243B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G06Q50/265—Personal security, identity or safety
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/082—Access security using revocation of authorisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Educational Administration (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • General Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • Finance (AREA)
  • Power Engineering (AREA)
  • Algebra (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé de contrôle d'identité d'un utilisateur (U), comprenant les étapes suivantes mises en œuvre par un dispositif de contrôle d'identité (3) : • lecture dans une base de données publique (4) d'éventuelles données protégées en confidentialité préalablement générées par un dispositif attesteur d'identité (1) à partir d'un élément d'identité d'un utilisateur (U) et à partir d'au moins une donnée d'aléa propre à l'utilisateur (U), • vérification (120) du respect d'une condition sur les données protégées en confidentialité trouvées dans la base de données publique (4), • mise en œuvre d'un traitement prédéterminé pour l'utilisateur (U) seulement si la condition est respectée.

Description

DOMAINE DE L'INVENTION
La présente invention concerne un procédé de contrôle de l’identité d’un utilisateur.
ETAT DE LA TECHNIQUE
Sont apparues ces dernières années des bases de données appelées « chaînes de blocs » (en anglais, « blockchain »).
Une base de données de type chaîne de blocs est distribuée entre plusieurs noeuds de stockage d’un réseau. Les noeuds de stockage sont configurés pour valider des données écrites dans la base de données par la mise en oeuvre d’une méthode de recherche de consensus entre les noeuds de stockage. Une telle méthode est par exemple la méthode connue de « preuve par le travail » (« proof of work » en anglais). Le contenu de la base de données est ainsi protégé contre des falsifications et ce malgré son caractère distribué.
La plus célèbre base de données de type « chaîne de blocs » est celle utilisée dans le système de transaction de monnaie électronique Bitcoin®. La base de données du système Bitcoin® contient un historique de toutes les transactions passées effectuées entre des comptes d’utilisateurs du système. La nécessité d’avoir recours à une entité centralisée telle qu’une banque pour authentifier des transactions est ainsi supprimée.
Il a toutefois été proposé d’utiliser une base de données de type « chaîne de blocs » à d’autres fins que la simple transaction de monnaie électronique.
Le MIT (Massachusetts Institute of Technology) a notamment proposé d’utiliser la base de données de type chaîne de blocs du système Bitcoin® pour prouver qu’une personne est détentrice d’un diplôme du MIT.
A cette fin, un serveur du MIT génère un diplôme électronique du MIT à partir d’au moins un élément d’identité d’une personne, par exemple le nom de la personne, son prénom et sa date de naissance.
Sont mémorisées, dans la base de donnée publique du système Bitcoin®, des données de transaction indiquant que le MIT a transféré un certain montant en Bitcoins à la personne. Les données de transaction comprennent par ailleurs un hash du diplôme électronique, de façon à indiquer que ladite transaction représente la délivrance d’un diplôme du MIT à cette personne. Le traitement permettant de générer le hash du diplôme du MIT à partir de l’élément d’identité est mis à disposition du public.
En effet, pour vérifier si une personne donnée a bien été diplômée du MIT, un potentiel employeur utilise ce traitement pour générer un hash de diplôme électronique témoin, et vérifie, dans la base de données du système Bitcoin®, s’il existe un hash de diplôme électronique non seulement contenu dans une transaction émise par le MIT mais également identique au diplôme électronique témoin généré par le tiers. Si oui, le candidat est bien diplômée du MIT, sinon ce n’est pas le cas.
Par exemple, le traitement en question peut prendre en entrée le ou chaque élément d’identité sous forme de chaînes de caractères respectives. Le traitement qui est fait ici de manière dématérialisée correspond à un remplissage de champs personnalisés dans un modèle de diplôme générique.
Il est entendu que le diplômé donne spontanément son élément d’identité à l’employeur de sorte que ce dernier puisse procéder à la vérification décrite ci-dessus.
Toutefois, certains tiers peuvent parvenir à la conclusion que la personne considérée est bien diplômée du MIT, sans autorisation de la personne.
En effet, une connaissance de la personne est susceptible de connaître les éléments d’identité le concernant (au moins son nom et son prénom). Cette connaissance peut ainsi mettre en œuvre mettre en œuvre les mêmes étapes que celles mises en œuvre par l’employeur : utiliser le traitement mis à disposition du public pour générer un hash de diplôme électronique témoin et rechercher si le hash est contenu dans une transaction émise par le MIT.
Ceci pose un problème de confidentialité lié à la vie privée, car un diplômé du MIT peut très bien ne pas vouloir que n’importe qui ait accès à une telle information d’ordre privé.
EXPOSE DE L'INVENTION
Un but de l’invention est de contrôler l’identité d’un utilisateur, au moyen d’une base de données publique tout en résolvant le problème de confidentialité rencontré dans la solution proposée par le MIT.
Il est dès lors proposé, selon un premier aspect de l’invention, un procédé de contrôle d’identité d’un utilisateur, comprenant les étapes suivantes mises en œuvre par un dispositif de contrôle d’identité :
• lecture dans une base de données publique d’éventuelles données protégées en confidentialité préalablement générées par un dispositif attesteur d’identité à partir d’un élément d’identité d’un utilisateur et à partir d’au moins une donnée d’aléa propre à l’utilisateur, • vérification du respect d’une condition sur les données protégées en confidentialité trouvées dans la base de données publique, • mise en œuvre d’un traitement prédéterminé pour l’utilisateur seulement si la condition est respectée.
La base de données utilisée étant publique, les données protégées en confidentialité peuvent être lues par tout tiers. Toutefois, les données protégées en confidentialité dépendent non seulement d’au moins un élément d’identité d’un utilisateur mais également de la donnée d’aléa.
Un tiers connaissant l’utilisateur ne peut pas savoir si le traitement prédéterminé est mis en oeuvre ou non. En effet, même si ce tiers connaît les éléments d’identité de l’utilisateur utilisés par le dispositif attesteur d’identité pour générer les données protégées en confidentialité. Il lui faut en effet connaître également la donnée d’aléa.
Le procédé selon le premier aspect de l’invention peut en outre comprendre les caractéristiques suivantes prises seules ou en combinaison lorsque cela est techniquement possible.
Dans un mode de réalisation, le procédé selon le premier aspect peut comprendre des étapes de :
• obtention, par le dispositif de contrôle d’identité, de deuxièmes données protégées en confidentialité dépendant de l’élément d’identité et de la donnée d’aléa, dans lequel les deuxièmes données protégées en confidentialité sont reçues d’un dispositif client appartenant à l’utilisateur ou sont générées par le dispositif de contrôle d’identité à partir de l’élément d’identité et de la donnée d’aléa, • mise en oeuvre du traitement prédéterminé seulement si le dispositif de contrôle d’identité trouve, dans la base de données publique, des données protégées en confidentialité à la fois générées par le dispositif attesteur d’identité et égales aux deuxièmes données protégées en confidentialité obtenues.
Dans un autre mode de réalisation, le procédé selon le premier aspect peut comprendre des étapes de :
• obtention, par le dispositif de contrôle d’identité, de données de preuve, les données de preuve ayant été préalablement générées par un dispositif client appartenant à l’utilisateur à partir de l’élément d’identité de l’utilisateur et de la donnée d’aléa propre à l’utilisateur, • mise en oeuvre du traitement prédéterminé seulement les données protégées en confidentialité trouvées et les données de preuve sont liées par une relation mathématique prédéterminée.
Les données de preuve peuvent être reçues par le dispositif de contrôle d’identité via un canal sécurisé établi directement entre le dispositif client et le dispositif de contrôle d’identité.
Alternativement,
• les données de preuve sont obtenues par lecture des données de preuve dans la base de données publique, • le traitement prédéterminé est mis en oeuvre seulement si les conditions suivantes sont remplies :
o les données de preuve lues sont associées, dans la base de données publique, aux données protégées en confidentialité préalablement générées par le dispositif attesteur d’identité, o les données protégées en confidentialité trouvées et les données de preuve associées aux données protégées en confidentialité trouvées sont liées par une relation mathématique prédéterminée.
Les données protégées en confidentialité peuvent avoir été générées par application d’une fonction de hachage prédéterminée H à des données x0,...,xn, où :
• n est un entier supérieur ou égal à 2, • au moins l’un des xt est une donnée d’aléa propre à l’utilisateur, et chaque autre xt est un élément d’identité de l’utilisateur, et dans lequel les données de preuve comprennent :
• une donnée c calculée par la formule : c = h(H(A0, ...,4n)) où h est une fonction prédéterminée, et A0,...,An sont n données tirées aléatoirement, • n données de preuve f0, calculées par application des formules
Vf e [Ο,η] fi = Ai + cXi auquel cas la relation mathématique prédéterminée peut être la suivante :
f H(f0.....fn)
Les données protégées en confidentialité générées par le dispositif attesteur d’identité peuvent être associées dans la base de données publique à des premières données de transaction indiquant que le dispositif attesteur d’identité a transféré un montant prédéterminé d’une monnaie électronique à un bénéficiaire.
Le bénéficiaire peut être l’utilisateur. Dans ce cas, les données de preuve peuvent être associées dans la base de données publique à des deuxièmes données de transaction indiquant que l’utilisateur a transféré au dispositif de contrôle d’identité le montant prédéterminé reçu du dispositif attesteur d’identité.
Le traitement prédéterminé peut être, comprendre ou déclencher un service prédéterminé à fournir à l’utilisateur, le procédé comprenant par ailleurs une génération et mémorisation dans la base de données publique, de données de confirmation indiquant que le service a été fourni à l’utilisateur.
Les données de confirmation générées peuvent être associées dans la base de données publique à des troisièmes données de transaction indiquant qu’un dispositif fournisseur de service ayant fourni le service à l’utilisateur a transféré au dispositif attesteur d’identité le montant prédéterminé.
Le procédé selon le premier aspect peut en outre comprendre des étapes de • après que le traitement prédéterminé a été mis en œuvre par le dispositif de contrôle d’identité, génération par le dispositif attesteur d’identité de nouvelles données protégées en confidentialité à partir de l’élément d’identité de Tutilisateur et d’au moins une nouvelle donnée d’aléa propre à Tutilisateur, • mémorisation des nouvelles données protégées en confidentialité dans la base de données publique de sorte qu’une nouvelle mise en œuvre de l’étape de vérification utilise les nouvelles données protégées en confidentialité à la place des données protégées en confidentialité.
La base de données publique est par exemple une base de données distribuée de type chaîne de blocs.
La génération des données protégées en confidentialité peut comprendre un hachage cryptographique appliqué à l’élément d’identité et à la donnée d’aléa.
Les données protégées en confidentialité peuvent être obtenues par application de la formule :
n fl·” i=0 où :
• n est un entier supérieur ou égal à 2, • au moins l’un des xt est une donnée d’aléa propre à Tutilisateur, et chaque autre xt est un élément d’identité de Tutilisateur, • Gi sont des éléments prédéterminés d’un groupe fini, par exemple des points de courbe elliptique ou des éléments d’un groupe cyclique.
Les données protégées en confidentialité peuvent être signées numériquement au moyen d’une clé privée propre au dispositif attesteur d’identité, avant leur mémorisation dans la base de données publique.
Le procédé peut en outre comprendre des étapes de :
• signature électronique des données de preuve au moyen d’une clé privée propre à l’utilisateur, avant leur mémorisation dans la base de données publique, • accès, par le dispositif de contrôle d’identité, aux données de preuve de service par déchiffrement des données de preuves signées mémorisées dans la base de données publique, au moyen d’une clé publique propre à l’utilisateur.
Le traitement prédéterminé peut être mis en oeuvre par le dispositif de contrôle d’identité seulement si le dispositif de contrôle d’identité ne trouve pas, dans la base de données publique, de données de révocation indiquant que la clé privée de l’utilisateur a été révoquée par le dispositif attesteur d’identité.
Il est en outre proposé, selon un deuxième aspect de l’invention, un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon le premier aspect de l’invention, lorsque ce programme est exécuté par au moins un processeur.
Il est en outre proposé, selon un troisième aspect de l’invention, un dispositif de contrôle d’identité pour contrôler l’identité d’un utilisateur, le dispositif de contrôle d’identité comprenant une interface de communication avec une base de données publique et au moins un processeur configuré pour :
• commander la lecture, dans la base de données publique, d’éventuelles données protégées en confidentialité préalablement générées par un dispositif attesteur d’identité à partir d’un élément d’identité de l’utilisateur et à partir d’au moins une donnée d’aléa propre à l’utilisateur, • vérifier le respect d’une condition sur les données protégées en confidentialité trouvées, • mettre en oeuvre un traitement prédéterminé pour l’utilisateur seulement si la preuve est établie.
Il est en outre proposé, selon un quatrième aspect de l’invention un système comprenant :
• un dispositif de contrôle d’identité selon le troisième aspect de l’invention, • un dispositif attesteur d’identité configuré pour générer les données protégées en confidentialité et commander la mémorisation des données protégées en confidentialité dans la base de données publique.
Il est en outre proposé, selon un cinquième aspect de l’invention, un dispositif client destiné à appartenir à un utilisateur, le dispositif client comprenant une interface de communication avec une base de données publique, et au moins un processeur configuré pour :
• générer des données de preuve à partir d’un l’élément d’identité de l’utilisateur et d’au moins une donnée d’aléa propre à l’utilisateur, • commander une mémorisation, dans une base de données publique, des données de preuve de façon à indiquer que les données de preuve ont été générées par le dispositif client, et en association avec des données protégées en confidentialité préalablement générées par un dispositif attesteur d’identité à partir d’un même élément d’identité et d’une même donnée d’aléa, • mise en œuvre du traitement prédéterminé seulement les données protégées en confidentialité trouvées et les données de preuve sont liées par une relation mathématique prédéterminée.
DESCRIPTION DES FIGURES
D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels :
• La figure 1 représente de manière schématique un système de fourniture d’un service, selon un mode de réalisation.
• La figure 2 est un organigramme d’étapes d’un procédé de fourniture d’un service mis en œuvre par le système représenté en figure 1, selon un mode de réalisation.
Sur l’ensemble des figures, les éléments similaires portent des références identiques.
DESCRIPTION DETAILLEE DE L'INVENTION
Système de fourniture de service en fonction d’un élément d’identité
En référence à la figure 1, un système de fourniture de service comprend un dispositif attesteur d’identité 1, un dispositif client 2 et un dispositif de contrôle d’identité 3.
Les trois dispositifs 1, 2, 3 communiquent entre eux par l’intermédiaire d’au moins un réseau R, par exemple le réseau Internet, un réseau cellulaire, ou une combinaison de tels réseaux.
Les trois dispositifs 1, 2, 3 ont chacun accès en lecture et en écriture à une base de données 4 stockée dans le réseau R.
La base de données 4 est publique, au sens où elle est libre d’accès en lecture non seulement par les dispositifs 1, 2, 3 en présence mais également à tout autre dispositif tiers. Tout dispositif tiers peut en particulier consulter les données écrites par l’un des dispositifs 1,2,3.
Ainsi, le dispositif attesteur d’identité 1 dispose d’un compte d’accès en lecture et en écriture dans la base de données 4. A cet effet, le dispositif attesteur d’identité 1 mémorise deux clés mutuellement associées: une clé privée de signature, propre au dispositif 1 et une clé publique de vérification de signature également propre au dispositif 1. La clé privée permet au dispositif 1 d’écrire des données signées dans la base de données ; elle est destinée à ne pas être communiquée à des tiers. La clé publique permet au dispositif 1 (et à tout autre titulaire d’un compte d’accès à la base de données 4) de vérifier qu’une donnée présente dans la base de données 4 a été écrite dans celle-ci par le dispositif 1.
Le dispositif de contrôle d’identité 3 dispose également d’un compte d’accès en lecture et en écriture dans la base de données 4. Comme pour le dispositif attesteur d’identité 1, le dispositif de contrôle d’identité 3 mémorise une clé publique et une clé privée mutuellement associées et qui lui sont propres.
La base de données 4 est distribuée ou décentralisée dans le réseau R, c’est-à-dire qu’elle est stockée par une pluralité de nœuds du réseau R avec lesquels les dispositifs 1, 2, 3 peuvent communiquer.
La base de données 4 est une base de données de type « chaîne de blocs ». Dans le présent texte, on définit une base de données de type « chaîne de blocs » comme une base de données mémorisée par une pluralité de nœuds de stockage configurés pour valider des données écrite dans la base de données par la mise en œuvre d’une méthode de recherche de consensus entre les nœuds de stockage. Une telle méthode est par exemple la méthode connue de « preuve par le travail » (« proof of work » en anglais). Le contenu de la base de données 4 est ainsi protégé contre des falsifications et ce malgré son caractère distribué / décentralisé.
Dans ce qui suit, on prendra l’exemple d’une base de données 4 conforme à celle utilisée par le système de transaction Bitcoin®. Ainsi, sont susceptible d’être mémorisées dans la base de données 4 des données représentatives d’une transaction, depuis l’un des dispositifs 1, 2, 3 à un autre de ces dispositifs 1, 2, 3, d’un certain montant en Bitcoins.
Chacun des trois dispositifs 1, 2, 3 comprend au moins un processeur configuré pour procéder à des calculs de données et une interface de communication pour communiquer avec les autres dispositifs et la base de données 4.
La fonction principale assurée par le dispositif attesteur d’identité 1 est d’attester du caractère agréé ou non d’un utilisateur. Le dispositif attesteur d’identité 1 pourrait ainsi être utilisé en France par l’Agence Nationale des Titres Sécurisés (ANTS) ou l’Imprimerie Nationale, ces organismes ayant pour objet de répondre à un tel besoin. Le dispositif 1 peut toutefois être géré par une société privée, par exemple une compagnie aérienne (exemple qui sera développé dans ce qui suit).
La fonction principale du dispositif de contrôle d’identité 3 est, comme son nom l’indique, de contrôler l’identité d’un utilisateur.
Le dispositif de contrôle est configuré pour mettre en œuvre ou non un traitement prédéterminé pour le compte d’un utilisateur, en fonction du résultat d’un contrôle d’identité qu’il a mis en œuvre sur cet utilisateur.
Par exemple, le dispositif de contrôle est configuré pour fournir un service prédéterminé à un utilisateur agréé par le dispositif 1. Dans ce cas, le traitement prédéterminé mis en œuvre ou non selon le résultat d’un contrôle de l’identité d’un utilisateur est une fourniture ou non de ce service à cet utilisateur. Par exemple, le dispositif de contrôle d’identité 3 est un dispositif de gestion de comptes de voyageurs de la compagnie aérienne susmentionnée. Ce dispositif 3 est alors par exemple adapté pour attribuer ou retirer des points de voyages à un voyageur donné, et lui attribuer des avantages de voyage.
Alternativement, le dispositif de contrôle 3 est adapté pour communiquer avec un dispositif fournisseur de service distinct. Dans ce cas, le traitement prédéterminé peut comprendre l’envoi au dispositif fournisseur de service d’un message indiquant si un utilisateur venant d’être contrôlé par le dispositif de contrôle a le droit ou non de se voir fournir un service par le dispositif fournisseur de service.
Le traitement prédéterminé peut alternativement ou à titre complémentaire comprendre une augmentation d’un niveau de réputation d’un utilisateur agréé par le dispositif attesteur d’identité 1 auprès d’un organisme tiers. Cette notion de réputation par exemple utilisé par des banques ou des assureurs pour évaluer le profil de leurs clients. Cette augmentation peut typiquement être faite par incrémentation d’une donnée représentative d’un niveau de réputation, mis en œuvre par le dispositif de contrôle 3 et/ou par le dispositif fournisseur
Le dispositif client 2 est par ailleurs un dispositif destiné à être manipulé par un utilisateur U susceptible de demander à se voir rendre un service par le dispositif de contrôle d’identité 3. Le dispositif client 2 est par exemple un smartphone ou un ordinateur portable.
Procédé de fourniture de service en fonction de l’identité d’un utilisateur ίο
Dans ce qui suit, on considérera à titre non limitatif que le dispositif de contrôle 3 est apte à rendre un service à un utilisateur agréé (il est en d’autres termes un dispositif fournisseur de service).
Il est en outre supposé dans ce qui suit qu’est mémorisée par le dispositif client 2 une application de gestion configurée pour établir un canal de communication avec le dispositif 1 et un canal de communication avec le dispositif 3 (par exemple via le réseau R). Une telle application peut être téléchargée à l’initiative de l’utilisateur U.
Les deux canaux de communications sont indépendants la base de données 4, c’est-àdire que des données ou messages qui transitent par l’un quelconque de ces canaux ne sont pas écrites dans la base de données 4.
Dans une étape 100, l’utilisateur U est enrôlé auprès du dispositif attesteur d’identité
1.
Selon une première variante de l’étape d’enrôlement 100, l’utilisateur U s’adresse à un guichet de la compagnie aérienne et fournit oralement au moins un élément d’identité le concernant.
Selon une deuxième variante de l’étape d’enrôlement 100, l’application affiche un message sur un écran du dispositif client 2 invitant l’utilisateur U à saisir au moins un élément d’identité le concernant. Le ou chaque élément d’identité saisi par l’utilisateur U dans son dispositif client 2 est transmis au dispositif attesteur d’identité 1 via le canal de communication établi par l’application entre les dispositifs 1 et 2.
Un ou plusieurs éléments d’identité de l’utilisateur U peuvent être ainsi fourni (s) au dispositif attesteur d’identité 1.
Un élément d’identité de l’utilisateur U peut être un élément d’état civil de l’utilisateur U (nom, prénom, date de naissance, lieu de naissance, etc.). Un élément d’identité peut être en outre une information indiquant si l’utilisateur est majeur ou non. Un élément d’identité peut plus généralement être toute information personnelle de l’utilisateur U (par exemple : numéro de passeport, numéro de carte d’identité, etc.).
On comprend aisément qu’un élément d’identité est plus ou moins porteur d’informations. Il est dès lors possible de définir des ensembles d’éléments d’identités à traiter, lesquels sont associés à des niveaux de confidentialité respectifs :
• éléments d’identité de niveau 1 : majorité de l’utilisateur U • éléments d’identité de niveau 2 : éléments d’identités de niveau 1 + nom de l’utilisateur U • éléments d’identités de niveau 3 : éléments d’identités de niveau 2 + adresse de l’utilisateur U.
u
Par ailleurs, l’enrôlement comprend la création un compte d’accès en lecture et en écriture dans la base de données 4 pour l’utilisateur U. La création du compte comprend l’attribution à l’utilisateur U de deux clés mutuellement associées ayant les mêmes fonctions que celles dont disposent les dispositifs 1 et 3: une clé privée de signature, propre à l’utilisateur U et une clé publique de vérification de signature également propre à l’utilisateur U.
Typiquement, l’application génère elle-même la paire de clés de l’utilisateur U et la clé publique est communiquée de manière privilégiée au dispositif attesteur d’identité 1.
Les deux clés de l’utilisateur U sont mémorisées par dans une mémoire du dispositif client 2 sur commande de l’application.
Dans ce qui suit, toute donnée écrite dans la base de données 4 à la demande d’une entité titulaire d’un compte d’accès à la base de données 4 est implicitement signée avant son écriture au moyen de la clé privée propre à cette entité. En outre, toute donnée signée lue dans la base de données 4 par une tiers titulaire d’un compte d’accès à la base de données 4 est implicitement vérifiée au moyen de la clé publique propre à l’entité, de sorte à obtenir la donnée originellement fournie par l’entité.
Au moins une donnée d’aléa associée à l’élément d’identité fourni par l’utilisateur U est par ailleurs générée (étape 102).
Cette donnée d’aléa peut être générée par le dispositif attesteur d’identité 1 comme illustré en figure 2, auquel cas la donnée d’aléa est transmise du dispositif attesteur d’identité 1 au dispositif client 2 (étape 104). Alternativement, la donnée d’aléa peut être générée par le dispositif client 2 (auquel cas le dispositif client 2 transmet la donnée d’aléa au dispositif attesteur d’identité 1 ).
Dans la suite, x0 désigne la donnée d’aléa, et xr à xn sont n éléments d’identité fournis au dispositif attesteur d’identité 1, n étant supérieur ou égal à 1. L’ensemble des éléments d’identités xr à xn peut par exemple être l’un ou l’autre des ensembles d’identité de niveau 1, 2 ou 3 définis précédemment.
Le dispositif attesteur d’identité 1 génère des données protégées en confidentialité à partir d’au moins un élément d’identité et de la donnée d’aléa (étape 106). « Par protégées en confidentialité » on entend que l’élément d’identité et la donnée d’aléa n’apparaissent pas en clair dans les données protégées en confidentialité.
De façon générale, la génération 106 des données protégées en confidentialité peut être vue comme l’application d’une fonction prédéterminée H aux éléments d’identité et à la donnée d’aléa. Les données protégées en confidentialité peuvent ainsi s’écrire : Η(χ0,...,χη).
Dans ce qui suit, on détaillera un mode de réalisation dans lequel les données protégées en confidentialité sont des données hachées : en d’autres termes, la fonction prédéterminé H est une fonction de hachage. Les données hachées sont également appelées « empreinte » ou « hash » dans la littérature.
La fonction de hachage H présente plusieurs avantages. La valeur du résultat de son application ne peut pas être prédéterminé. En outre, la fonction H est difficile à inverser si bien qu’il est quasiment impossible de remonter aux antécédents de la fonction H à partir des données hachées H(x0, ...,xn), ou de trouver deux antécédents ayant la même image Est développé dans la suite un mode de réalisation particulier de l’invention dans lequel les données hachées sont obtenues par application de la formule suivante :
n
H(x0, ...,xn) = J”[ Gf1 i=0 où les termes G; sont des éléments prédéterminés d’un groupe fini, par exemple des points de courbe elliptique ou des éléments d’un groupe cyclique. Les termes G; sont également connus du dispositif client 2 et du dispositif de contrôle d’identité 3.
Le dispositif attesteur d’identité 1 commande la mémorisation des données hachées H(x0, ...,xn) dans la base de données 4 d’une façon propre à indiquer à tout tiers que les données hachées ont été générées par le dispositif attesteur d’identité 1 (étape 108). Cette indication matérialise le fait que les données hachées ont été générées sur la base d’un utilisateur (ici U) agréé par le dispositif attesteur d’identité 1. Comme on le verra par la suite, un traitement prédéterminé sera mis en œuvre au bénéfice d’un utilisateur seulement si cet utilisateur s’avère avoir été agréé par le dispositif attesteur d’identité 1. Par exemple, un utilisateur agréé pourra se voir rendre un service par le dispositif de contrôle d’identité 3 (ou un dispositif fournisseur de service distinct du dispositif de contrôle d’identité 3) tandis qu’un utilisateur non agréé ne pourra pas avoir accès à un tel service.
Lorsqu’un système de gestion de monnaie électronique telle que Bitcoin® est utilisé, une telle indication peut être obtenue au moyen d’une transaction d’un certain montant de la monnaie électronique depuis le dispositif attesteur d’identité 1 au bénéfice du dispositif client 2.
Le dispositif attesteur d’identité 1 génère par exemple des premières données de transaction T(K,1=>2) propres à indiquer que le dispositif attesteur d’identité 1 transfère à l’utilisateur U un montant K prédéterminé de monnaie électronique, par exemple K Bitcoins. L’utilisateur U bénéficiaire de la transaction est identifié par sa clé publique, qui lui a été fournie lors de la création de son compte d’accès à la base de données 4.
Le dispositif attesteur d’identité 1 commande alors la mémorisation 108, dans la base de données 4, des premières données de transaction et des données hachées. Les premières données de transaction sont mises en association avec la clé publique de l’utilisateur U dans la base de données 4, de sorte à indiquer à un tiers accédant à la base de données 4 que cet utilisateur U est le bénéficiaire des K Bitcoins transféré par le dispositif attesteur d’identité 1.
Cette association est par exemple une inclusion des données hachées H(x0, dans les premières données de transaction. Lorsque le système Bitcoin® est utilisé, les premières données de transaction comprennent un champ OP_RETURN qui peut être utilisé pour stocker les données hachées.
Plus tard, l’utilisateur U souhaite accéder au service rendu par le dispositif de contrôle d’identité 3. A cet effet, l’application génère une demande de service (étape 114), et commande l’envoi de la demande générée par le dispositif client 2 de l’utilisateur U au dispositif de contrôle d’identité 3, via un canal préalablement établi entre les dispositifs 2 et 3 (étape 116).
Sur réception de cette demande, le dispositif de contrôle d’identité 3 accède en lecture à la base de données 4, et y recherche d’éventuelles données hachées préalablement générées par le dispositif attesteur d’identité 1 à partir d’un élément d’identité de l’utilisateur U et à partir d’au moins une donnée d’aléa propre à l’utilisateur U.
Si de telles données hachées sont trouvées dans la base de données 4, le dispositif de contrôle d’identité vérifie si une condition sur les données hachées est remplie.
Si la condition est remplie, le dispositif de contrôle d’identité 3 fournit le service demandé au dispositif client 2 (étape 122). Le dispositif de contrôle d’identité 3 déduit en effet des données hachées que l’utilisateur demandeur a été préalablement agréé par le dispositif attesteur d’identité 1.
Si la condition n’est pas remplie, le dispositif de contrôle d’identité 3 ne fournit pas le service demandé au dispositif client 2. Dans ce cas, le dispositif fournisseur 3 déduit en effet de l’absence de données hachées sur la base d’un élément d’identité de l’utilisateur demandeur que cet utilisateur demandeur U n’a pas été agréé par le dispositif attesteur d’identité 1.
Dans le cas de l’utilisateur U, le service est bien rendu puisque des données hachées H(x0, ...,xn) ont bien été générées par le dispositif attesteur d’identité 1 puis mémorisées à la demande de ce dernier dans la base de données 4.
En d’autres termes, le dispositif de contrôle d’identité 3 ne rend un service à un utilisateur demandeur seulement si cet utilisateur a été agréé par le dispositif attesteur d’identité 1. On peut remarquer que le dispositif de contrôle d’identité 3 n’a pas eu à communiquer directement avec le dispositif attesteur d’identité 1 pour décider si le service est à fournir ou non à l’utilisateur demandeur ; il n’a eu qu’à inspecter le contenu de la base de données 4. Un avantage de cette solution est sa souplesse d’utilisation : le dispositif de contrôle d’identité 3 peut prendre une décision relative à la demande de service formulée même lorsque le dispositif attesteur d’identité n’est pas disponible (éteint, non branché au réseau, ou tout simplement défaillant).
Par ailleurs, l’utilisation de la base de données 4 de type « blockchain » permet un déploiement très simple du procédé. Les dispositifs 1, 2, 3 n’ont besoin que d’une configuration minimale (notamment la création de comptes d’accès à la base de données 4), la sécurité du procédé en termes de protection contre des falsifications étant assurée par la base de données 4. L’utilisation de la base de données d’un système de transaction tel que Bitcoin® ou équivalent est particulièrement aisée à mettre en œuvre.
De plus, aucun élément d’identité n’a été directement écrit en clair dans la base de données 4. Seules les données hachées sont mémorisées dans la base de données 4. Or, comme les données hachées dépendent non seulement d’au moins un élément d’identité mais également d’une donnée d’aléa, il est impossible pour un tiers - connaissant l’élément d’identité de l’utilisateur U - de conclure que l’utilisateur U a été agréé par le dispositif attesteur d’identité 1 sans connaître également l’élément d’aléa, par simple accès à la base de données 4 qui est publique.
Premier mode de réalisation
La figure 2 illustre un premier mode de réalisation, dans lequel le dispositif client 2 détecte que la base de données 4 contient les premières données de transactions indiquant que K Bitcoins ont été transférés à l’utilisateur U.
Suite à cette détection, le dispositif client 2 génère des données de preuve qui dépendent de l’élément d’identité de l’utilisateur U et de la donnée d’aléa x0 propre à l’utilisateur U (étape 110).
Par exemple, les données de preuve comprennent une première donnée de preuve c et n données de preuve f0, lesquelles sont calculées comme suit :
/ n c = h(H(A0.....AJ) = /i \ i=0 où h est une fonction de hachage prédéterminée (par exemple différente de la fonction H), et 40, ...,An sont n données tirées aléatoirement ; et
Vi e JO, n] f = Ai + cXi
Le dispositif client 2 commande la mémorisation, dans la base de données 4, les données de preuve c, f0, de façon à indiquer que les données de preuve ont été générées par le dispositif client 2 (étape 112).
Les données c, f0, de preuve sont par ailleurs associées, dans la base de données 4, aux données hachées H(x0, ...,xn) préalablement générées par le dispositif attesteur d’identité 1, de façon à indiquer que les données de preuve et les données hachées associées ont été générées à partir des même éléments d’identité x-ι,...,Χη et de la même donnée d’aléa x0 (propres à l’utilisateur U).
Lorsqu’un système de gestion de monnaie électronique telle que Bitcoin® est utilisé, une telle indication peut être obtenue au moyen d’au moins une transaction vers le dispositif attesteur d’identité 1 couvrant le montant de monnaie électronique que l’utilisateur U a reçu du dispositif attesteur d’identité 1. A cet effet, le dispositif client 2 génère des deuxièmes données de transaction T(K,2=>3) indiquant que l’utilisateur demandeur U transfert au dispositif de contrôle d’identité 3 le montant prédéterminé K reçu du dispositif attesteur d’identité 1. Le dispositif client 2 commande alors la mémorisation 112, dans la base de données 4, des deuxièmes données de transaction et des données de preuve. Les deuxièmes données de transaction sont mises en association dans la base de données 4 avec la clé publique du dispositif de contrôle d’identité 3, de sorte à indiquer que le dispositif de contrôle d’identité 3 est le bénéficiaire des K Bitcoins transférés par le dispositif client 2.
Cette association est par exemple une inclusion des données de preuve dans les deuxièmes données de transaction. Lorsque le système Bitcoin® est utilisé, les deuxièmes données de transaction comprennent un champ OP_RETURN qui peut être utilisé pour stocker les données de preuve.
Il se peut que les données de preuve soient trop volumineuses pour être mémorisées dans un seul champ OP_RETURN. Dans ce cas, le dispositif client 2 génère puis commande la mémorisation dans la base de données 4 de plusieurs deuxièmes données de transactions, la somme des montants des deuxièmes transactions étant égale à K.
Les étapes 110, 112 qui précèdent sont mises en oeuvre avant l’envoi par le dispositif client 2 de la demande de service au dispositif de contrôle d’identité 3. Par exemple, le dispositif client 2 envoie la demande de service juste après avoir eu confirmation que les deuxièmes données de transactions ont été mémorisées dans la base de données 4.
Le dispositif fournisseur 3 détecte que la base de données 4 contient les deuxièmes données de transactions, indiquant que K Bitcoins lui ont été transférés par le dispositif client 2.
Cette détection est par exemple mise en œuvre par le dispositif fournisseur 3 en réponse à la réception de la demande de service émise par le dispositif client 2 au cours de l’étape 114.
Le dispositif de contrôle d’identité 3 accède en lecture à la base de données 4, et télécharge les données de preuve associées aux deuxièmes données de transactions le désignant comme bénéficiaire de K Bitcoins (étape 118). Il lui suffit pour cela de lire le contenu du champ OP_RETURN des deuxièmes données de transaction T(K,2=>3).
Le dispositif de contrôle d’identité 3 a donc à ce stade connaissance des données de preuve c, f0, Par ailleurs, comme indiqué plus haut, le dispositif de contrôle d’identité 3 a également connaissance de la fonction H. Il est également supposé que le dispositif de contrôle d’identité 3 connaît la fonction h.
Le dispositif de contrôle d’identité 3 vérifie si deux conditions sont cumulativement remplies (étape 120) : une première condition et une deuxième condition.
La première condition à remplir est l’existence, dans la base de données 4, de données de preuve qui ont été d’une part générées par le dispositif client 2 et qui sont d’autre part associées à des données hachées par le dispositif attesteur d’identité 1.
Dans le cas où le système Bitcoin® est utilisé, le dispositif de contrôle d’identité 3 détermine simplement la provenance des K bitcoins qu’il a reçus. S’il existe, dans la base de données 4, des données de transaction indicatives du transfert des K bitcoins du dispositif attesteur d’identité 1 au dispositif client 2, alors le dispositif de contrôle d’identité 3 lit le contenu du champ OP_RETURN desdites données de transaction et considère qu’il s’agit de données hachées générées par le dispositif attesteur d’identité 1.
Dans le cas de Tutilisateur U, les K bitcoins transférés par le dispositif client 2 au dispositif de contrôle d’identité 3 dans les deuxièmes données de transaction T(K,2=>3) avaient été préalablement transférés par le dispositif attesteur d’identité 1 au dispositif client 2 dans les premières données de transaction T(K,1=>2). Le dispositif fournisseur d’accès 3 lit ainsi le contenu du champ OP_RETURN des premières données de transaction pour obtenir les données hachées.
A ce stade, le dispositif de contrôle d’identité connaît les données de preuve mais également les données hachées auxquelles les données de preuves sont associées.
La deuxième condition à remplir est que les données hachées éventuellement trouvées et les données de preuve associées aux données hachées éventuellement trouvées doivent être liées par une relation mathématique prédéterminée.
La relation mathématique prédéterminée est la suivante :
/ H(fofn) \(H(x0.....xn))7 C
Par exemple, dans le cas où H(x0, ...,xn) = ΠΡ=ο GiXi cette relation mathématique prédéterminée devient :
nF.,c/‘ j V(nr=o<Y')9
Le dispositif de contrôle d’identité 3 fournit le service demandé par le dispositif client 2 seulement si les deux conditions sont cumulativement remplies (étape 122).
Si les deux conditions ne sont pas cumulativement remplies, le dispositif de contrôle d’identité 3 ne fournit par le service demandé par le dispositif client 2.
Un avantage de ce premier mode de réalisation est que le dispositif de contrôle d’identité 3 peut déterminer si un utilisateur U a été agréé ou non par le dispositif attesteur d’identité 1, sans avoir eu besoin de connaître les valeurs des termes χέ (éléments d’identité et donnée d’aléa). Le dispositif fournisseur 3 n’a en effet utilisé que les données hachées et les données de preuve mémorisées dans la base de données 4.
Bien entendu, d’autres données de preuves et d’autres relations mathématiques que celles présentées ci-dessus peuvent être utilisées pour conditionner la fourniture du service par le dispositif 3, par exemple celles décrites dans le document « Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy », par Stefan Brands.
Deuxième mode de réalisation
Dans un deuxième mode de réalisation non illustré, plus simple de mise en œuvre que le premier mode de réalisation, les valeurs des termes χέ (éléments d’identité et donnée d’aléa) sont fournis au dispositif de contrôle d’identité 3 par l’utilisateur demandeur U. Les valeurs des termes χέ sont par exemple transmises par le dispositif client 2 au dispositif de contrôle d’identité 3.
Le dispositif de contrôle d’identité 3 génère des données hachées à partir de l’élément d’identité de l’utilisateur demandeur U et de la donnée d’aléa propre à l’utilisateur demandeur U qui lui ont ainsi été fournis. Le dispositif 3 utilise pour cela la fonction H dont il a connaissance.
Le dispositif de contrôle d’identité 3 accède par ailleurs en lecture à la base de données 4, et vérifie par ailleurs si la base de données 4 contient des données hachées à la fois indiquées comme ayant été générées par le dispositif attesteur d’identité 1 et égales aux données hachées générées par le dispositif de contrôle d’identité 3.
Si tel est le cas, le dispositif de contrôle d’identité 3 fournit le service demandé dans l’étape 122. Sinon, le dispositif de contrôle d’identité 3 rejette la demande de service.
Etapes postérieures à la fourniture du service
Après que le service a été rendu par le dispositif de contrôle d’identité 3 à l’utilisateur demandeur U au cours de l’étape 122, le dispositif de contrôle d’identité 3 génère des données de confirmation indiquant que le service a été fourni à l’utilisateur demandeur U (étape 124).
Ces données de confirmation sont mémorisées dans la base de données 4 sur commande du dispositif de contrôle d’identité 3 (étape 126).
Lorsqu’un système de gestion de monnaie électronique telle que Bitcoin® est utilisé, les données de confirmation générées par le dispositif de contrôle d’identité 3 sont associées dans la base de données 4 à des troisièmes données de transaction T(K,3=>1) indiquant que le dispositif fournisseur d’accès 3 a transféré au dispositif attesteur d’identité 1 le montant K reçu du dispositif client 2.
Ainsi le dispositif attesteur d’identité 1 se voit crédité du montant K qu’il avait précédemment dépensé.
Les troisièmes données de transaction sont générées par le dispositif de contrôle d’identité 3 et sont similaires aux première et deuxième données de transaction. Lorsque le système Bitcoin® est utilisé, les troisièmes données de transaction comprennent un champ OP_RETURN qui peut être utilisé pour stocker les données de confirmation.
Le dispositif attesteur d’identité 1 peut ainsi être informé du fait que le dispositif de contrôle d’identité 3 a rendu un service à un utilisateur U qu’il a précédemment agréé, sans pour autant communiquer directement avec le dispositif de contrôle d’identité 3 puisqu’il suffit au dispositif attesteur d’identité 1 de lire (étape 128) les données de confirmation contenues dans la base de données 4 qui sont associées aux troisièmes données de transaction, et de déchiffrer les données de confirmation signées au moyen d’une clé publique propre au dispositif de contrôle d’identité 3.
De préférence, l’élément d’aléa est à usage unique. Ainsi, même si un tiers malveillant devait apprendre l’élément d’aléa propre à l’utilisateur U, il ne pourrait pas l’utiliser plusieurs fois auprès du dispositif de contrôle d’identité 3.
Par exemple, après que le service a été rendu par le dispositif de contrôle d’identité 3 à l’utilisateur U, le dispositif attesteur d’identité 1 tire aléatoirement une nouvelle donnée d’aléa propre à l’utilisateur U (étape 102), puis génère de nouvelles données hachées à partir de l’élément d’identité de l’utilisateur demandeur U et à partir de la nouvelle donnée d’aléa (étape 106), et commande la mémorisation des nouvelles données hachées dans la base de données 4 de sorte qu’une nouvelle mise en oeuvre de l’étape d’établissement de preuve utilise les nouvelles données hachées à la place des données hachées préalablement.
Il peut également être fait en sorte d’attribuer à l’utilisateur U une nouvelle paire de clés publique et privée après que le service a été rendu par le dispositif de contrôle d’identité 3 à l’utilisateur U. La nouvelle paire de clés peut être générée par l’application exécutée par le dispositif client 2 sur requête du dispositif attesteur d’identité 1, ou bien être générée par le dispositif attesteur d’identité 1 puis transmise par ce dernier au dispositif client 2 via le réseau R.
Comme indiqué précédemment, le dispositif client 2 est destiné à être manipulé par l’utilisateur U. En cas de vol du dispositif client 2, un utilisateur U non agréé pourrait tenter d’obtenir un accès au service rendu par le dispositif 3 en se faisant passer pour le possesseur réel du dispositif client 2. Aussi, il est avantageux de mémoriser dans la base de données 4 des données de révocation indiquant que l’utilisateur demandeur U a été révoqué par le dispositif attesteur d’identité 1. Cette mémorisation est typiquement commandée par le dispositif attesteur d’identité 1.
Ainsi, le service sera fourni par le dispositif de contrôle d’identité 3 seulement si le dispositif de contrôle d’identité 3 ne trouve pas, dans la base de données 4, de données de révocation indiquant que la clé privée de l’utilisateur demandeur U a été révoquée par le dispositif attesteur d’identité 1.
Les données de révocation sont par exemple mémorisées dans la base de données 4 au même format que les données hachées. Dans le cas où le système Bitcoin® est utilisé, le dispositif attesteur d’identité 1 génère des quatrièmes données de transaction indiquant le transfert de K bitcoins à l’utilisateur à révoquer (ici U). Le champ OP_RETURN des quatrièmes données de transaction contient les données de révocation. Les données de révocation sont par exemple une chaîne de caractère prédéterminée, par exemple « REVOKED ». Comme indiqué précédemment, le dispositif de contrôle d’identité 3 lit les données hachées dans la base de données 4 avant de fournir le service demandé par l’utilisateur demandeur U.
En plus des conditions énoncées dans le premier mode de réalisation et le deuxième mode de réalisation décrits ci-dessus, le dispositif de contrôle d’identité 3 vérifie si les données se trouvant dans le champ OP_RETURN de données de transaction lui transférant K bitcoins contiennent les données de révocation. Si oui, alors le service n’est pas fourni.
Le procédé décrit ci-dessus n’est bien entendu pas limité à une base de données 4 de gestion de transaction de monnaie électronique, encore moins au système Bitcoin®.
Le procédé est bien évidemment applicable à tout type traitement prédéterminé à accomplir ou non en fonction de l’identité de l’utilisateur demandeur U, que ce soit par le dispositif de contrôle d’identité 3 lui-même ou bien par un autre dispositif avec lequel le dispositif de contrôle d’identité 3 communique.
Le procédé trouve avantageusement application pour augmenter la réputation d’un utilisateur agréé par le dispositif attesteur d’identité 1 auprès de tiers.
Tous les comptes d’accès à la base de données 4 sont anonymes en ce sens que les identités réelles des titulaires des comptes d’accès à la base de données 4 ne sont pas connues des tiers à la simple lecture du contenu de la base de données 4. Un tiers lisant les données de transaction T(K,1=>2), T(K,2=>3) et T(K,3=>1) constate que K bitcoins sont successivement possédés par un premier compte, puis par un deuxième compte, puis par un troisième compte. Pour lire ces données de transaction, tout tiers peut utiliser la clé publique associée à chacun de ces comptes. Toutefois, le tiers ne sait pas l’identité du titulaire de chacun de ces trois comptes. En particulier, le tiers ne sait absolument pas que l’utilisateur U est l’un de ces titulaires.
Toutefois, l’utilisateur U peut vouloir révéler qu’il est bien titulaire de son compte à un tiers, auprès de qui il souhaite accroître sa réputation, par exemple une banque.
Par ailleurs, l’utilisateur U peut être titulaire de différents comptes. L’utilisateur U est par exemple titulaire d’un premier compte utilisé pour la mise en oeuvre du procédé qui précède impliquant les dispositifs 1 et 3, et titulaire d’un deuxième compte utilisé pour la mise en oeuvre du même procédé, mais impliquant un dispositif attesteur d’identité différent du dispositif 1 et un dispositif fournisseur de service différent du dispositif 3. Dans ce cas, l’utilisateur U, peut dévoiler auprès du tiers auprès de qui il souhaite accroître sa réputation seulement qu’il est titulaire d’un des premier et deuxièmes comptes, auquel cas il ne donne à ce tiers que des informations parcellaires le concernant. Alternativement, l’utilisateur peut dévoiler qu’il est titulaire des premier et deuxièmes comptes.
Par ailleurs, on a vu précédemment que les dispositifs 1, 2 et 3 disposent chacun un compte d’accès à la base de données 4. En particulier, il est prévu dans le mode de réalisation illustré en figure 2 qu’un utilisateur U accède au contenu de la base 4 en passant par un compte qu’il aura créé de sa propre initiative moyennant le dispositif client 2.
Dans un autre mode de réalisation, les dispositifs 1 et 3 disposent certes chacun d’un tel compte d’accès, mais aucun compte d’accès à la base de données publique 4 n’a besoin d’être est créé par l’utilisateur U. Dans ce mode de réalisation, le dispositif attesteur d’identité effectue une transaction vers d’un compte tiers prédéterminé, spécialement créé pour l’utilisateur U par le dispositif attesteur d’identité 1, ou bien vers lui-même.
Le dispositif attesteur d’identité 1 transmet alors au dispositif client 2, via un canal sécurisé, un message contenant des données de localisation permettant de localiser dans la base de données publique 4 les données protégées en confidentialité qui y ont été mémorisées sur ordre du dispositif attesteur d’identité 1. Ces données de localisation peuvent être une référence sur la transaction opérée par le dispositif 1, par exemple un ID blockchain. Ces données de localisation peuvent être ensuite transmises par le dispositif client 2 au dispositif de contrôle d’identité 3 pour permettre au dispositif de contrôle 3 de localiser les données protégées en confidentialité préalablement mémorisées sur ordre du dispositif attesteur d’identité 1.

Claims (21)

  1. REVENDICATIONS
    1. Procédé de contrôle d’identité d’un utilisateur (U), comprenant les étapes suivantes mises en œuvre par un dispositif de contrôle d’identité (3) :
    • lecture dans une base de données publique (4) d’éventuelles données protégées en confidentialité préalablement générées par un dispositif attesteur d’identité (1) à partir d’un élément d’identité d’un utilisateur (U) et à partir d’au moins une donnée d’aléa propre à l’utilisateur (U), • vérification (120) du respect d’une condition sur les données protégées en confidentialité trouvées dans la base de données publique (4), • mise en œuvre d’un traitement prédéterminé pour l’utilisateur (U) seulement si la condition est respectée.
  2. 2. Procédé selon la revendication 1, comprenant en outre des étapes de :
    • obtention, par le dispositif de contrôle d’identité (3), de deuxièmes données protégées en confidentialité dépendant de l’élément d’identité et de la donnée d’aléa, dans lequel les deuxièmes données protégées en confidentialité sont reçues d’un dispositif client (2) appartenant à l’utilisateur (U) ou sont générées par le dispositif de contrôle d’identité (3) à partir de l’élément d’identité et de la donnée d’aléa, • mise en œuvre du traitement prédéterminé seulement si le dispositif de contrôle d’identité (3) trouve, dans la base de données publique (4), des données protégées en confidentialité à la fois générées par le dispositif attesteur d’identité (1 ) et égales aux deuxièmes données protégées en confidentialité obtenues.
  3. 3. Procédé selon la revendication 1, comprenant des étapes de :
    • obtention, par le dispositif de contrôle d’identité (3), de données de preuve, les données de preuve ayant été préalablement générées (110) par un dispositif client (2) appartenant à l’utilisateur (U) à partir de l’élément d’identité de l’utilisateur (U) et de la donnée d’aléa propre à l’utilisateur (U), • mise en œuvre du traitement prédéterminé seulement les données protégées en confidentialité trouvées et les données de preuve sont liées par une relation mathématique prédéterminée.
  4. 4. Procédé selon la revendication 3, dans lequel les données de preuve sont reçues par le dispositif de contrôle d’identité (3) via un canal sécurisé établi directement entre le dispositif client (2) et le dispositif de contrôle d’identité (3).
  5. 5. Procédé selon la revendication 3, dans lequel :
    • les données de preuve sont obtenues par lecture des données de preuve dans la base de données publique (4), • le traitement prédéterminé est mis en œuvre seulement si les conditions suivantes sont remplies :
    o les données de preuve lues sont associées, dans la base de données publique (4), aux données protégées en confidentialité préalablement générées par le dispositif attesteur d’identité (1), o les données protégées en confidentialité trouvées et les données de preuve associées aux données protégées en confidentialité trouvées sont liées par une relation mathématique prédéterminée.
  6. 6. Procédé selon l’une des revendications 3 à 5, dans lequel les données protégées en confidentialité ont été générées par application d’une fonction de hachage prédéterminée H à des données x0, ...,xn, où :
    • n est un entier supérieur ou égal à 2, • au moins l’un des xt est une donnée d’aléa propre à l’utilisateur (U), et chaque autre Xi est un élément d’identité de l’utilisateur (U), et dans lequel les données de preuve comprennent :
    • une donnée c calculée par la formule : c = h(H(A0, ...,4n)) où h est une fonction prédéterminée, et A0,...,An sont n données tirées aléatoirement, • n données de preuve f0, calculées par application des formules
    Vi e [Ο,η] fi = Ai + cXi la relation mathématique prédéterminée étant en outre f H(f0.....fn)
  7. 7. Procédé selon l’une des revendications précédentes, dans lequel les données protégées en confidentialité générées par le dispositif attesteur d’identité (1) sont associées dans la base de données publique (4) à des premières données de transaction indiquant que le dispositif attesteur d’identité (1) a transféré un montant prédéterminé d’une monnaie électronique à un bénéficiaire.
  8. 8. Procédé selon la revendication 7 dans sa dépendance à l’une des revendications 3 à 6, dans lequel :
    • le bénéficiaire est l’utilisateur (U), • les données de preuve sont associées dans la base de données publique (4) à des deuxièmes données de transaction indiquant que l’utilisateur (U) a transféré au dispositif de contrôle d’identité (3) le montant prédéterminé reçu du dispositif attesteur d’identité (1 ).
  9. 9. Procédé selon l’une des revendications précédentes, dans lequel le traitement prédéterminé est, comprend ou déclenche un service prédéterminé à fournir à l’utilisateur (U), le procédé comprenant par ailleurs une génération (124) et mémorisation (126) dans la base de données publique (4), de données de confirmation indiquant que le service a été fourni à l’utilisateur (U).
  10. 10. Procédé selon les revendications 8 et 9 prises en combinaison, dans lequel les données de confirmation générées sont associées dans la base de données publique (4) à des troisièmes données de transaction indiquant qu’un dispositif fournisseur de service ayant fourni le service à l’utilisateur (U) a transféré au dispositif attesteur d’identité (1 ) le montant prédéterminé.
  11. 11. Procédé selon l’une des revendications précédentes, comprenant en outre des étapes de • après que le traitement prédéterminé a été mis en œuvre par le dispositif de contrôle d’identité (3), génération (102) par le dispositif attesteur d’identité (1) de nouvelles données protégées en confidentialité à partir de l’élément d’identité de l’utilisateur (U) et d’au moins une nouvelle donnée d’aléa propre à l’utilisateur (U), • mémorisation (108) des nouvelles données protégées en confidentialité dans la base de données publique (4) de sorte qu’une nouvelle mise en œuvre de l’étape de vérification (120) utilise les nouvelles données protégées en confidentialité à la place des données protégées en confidentialité.
  12. 12. Procédé selon l’une des revendications précédentes, dans lequel la base de données publique (4) est une base de données distribuée de type chaîne de blocs.
  13. 13. Procédé selon l’une des revendications précédentes, dans lequel la génération des données protégées en confidentialité comprend un hachage cryptographique appliqué à l’élément d’identité et à la donnée d’aléa.
  14. 14. Procédé selon l’une des revendications précédentes, dans lequel les données protégées en confidentialité sont obtenues par application de la formule :
    n fl·” i=0 où :
    • n est un entier supérieur ou égal à 2, • au moins l’un des xt est une donnée d’aléa propre à l’utilisateur (U), et chaque autre Xi est un élément d’identité de l’utilisateur (U), • Gi sont des éléments prédéterminés d’un groupe fini, par exemple des points de courbe elliptique ou des éléments d’un groupe cyclique.
  15. 15. Procédé selon l’une des revendications précédentes, dans lequel les données protégées en confidentialité ont été signées numériquement au moyen d’une clé privée propre au dispositif attesteur d’identité (1 ), avant leur mémorisation dans la base de données publique (4).
  16. 16. Procédé selon l’une des revendications précédentes, comprenant en outre des étapes de :
    • signature électronique des données de preuve au moyen d’une clé privée propre à l’utilisateur (U), avant leur mémorisation dans la base de données publique (4), • accès, par le dispositif de contrôle d’identité (3), aux données de preuve de service par déchiffrement des données de preuves signées mémorisées dans la base de données publique (4), au moyen d’une clé publique propre à l’utilisateur (U).
  17. 17. Procédé selon la revendication précédente, dans lequel le traitement prédéterminé est mis en œuvre par le dispositif de contrôle d’identité (3) seulement si le dispositif de contrôle d’identité (3) ne trouve pas, dans la base de données publique (4), de données de révocation indiquant que la clé privée de l’utilisateur (U) a été révoquée par le dispositif attesteur d’identité (1).
  18. 18. Produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l’une des revendications précédentes, lorsque ce programme est exécuté par au moins un processeur.
  19. 19. Dispositif de contrôle d’identité (3) pour contrôler l’identité d’un utilisateur (U), le dispositif de contrôle d’identité (3) comprenant une interface de communication avec une base de données publique (4) et au moins un processeur configuré pour :
    • commander la lecture, dans la base de données publique (4), d’éventuelles données protégées en confidentialité préalablement générées par un dispositif attesteur d’identité (1) à partir d’un élément d’identité de l’utilisateur (U) et à partir d’au moins une donnée d’aléa propre à l’utilisateur (U), • vérifier (120) le respect d’une condition sur les données protégées en confidentialité trouvées, • mettre en oeuvre un traitement prédéterminé pour l’utilisateur seulement si la preuve est établie.
  20. 20. Système comprenant :
    • un dispositif de contrôle d’identité (3) selon la revendication précédente, • un dispositif attesteur d’identité (1 ) configuré pour générer les données protégées en confidentialité et commander la mémorisation des données protégées en confidentialité dans la base de données publique (4).
  21. 21. Dispositif client (2) destiné à appartenir à un utilisateur (U), le dispositif client comprenant • une interface de communication avec une base de données publique (4), • au moins un processeur configuré pour :
    o générer des données de preuve à partir d’un l’élément d’identité de l’utilisateur (U) et d’au moins une donnée d’aléa propre à l’utilisateur (U), o commander une mémorisation (112), dans une base de données publique (4), des données de preuve de façon à indiquer que les données de preuve ont été générées par le dispositif client (2), et en association avec des données protégées en confidentialité préalablement générées par un dispositif attesteur d’identité (1 ) à partir d’un même élément d’identité et d’une même donnée d’aléa, o mise en œuvre du traitement prédéterminé seulement les données protégées en confidentialité trouvées et les données de preuve sont liées par une relation mathématique prédéterminée.
    1/2
FR1752724A 2016-10-31 2017-03-30 Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique Active FR3058243B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP17198045.1A EP3316549B1 (fr) 2016-10-31 2017-10-24 Procédé de contrôle d'identité d'un utilisateur au moyen d'une base de données publique
US15/798,153 US10817967B2 (en) 2016-10-31 2017-10-30 Method for controlling the identity of a user by means of a blockchain

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1660566 2016-10-31
FR1660566A FR3058292B1 (fr) 2016-10-31 2016-10-31 Procede de fourniture d'un service a un utilisateur

Publications (2)

Publication Number Publication Date
FR3058243A1 true FR3058243A1 (fr) 2018-05-04
FR3058243B1 FR3058243B1 (fr) 2018-11-23

Family

ID=57963292

Family Applications (2)

Application Number Title Priority Date Filing Date
FR1660566A Active FR3058292B1 (fr) 2016-10-31 2016-10-31 Procede de fourniture d'un service a un utilisateur
FR1752724A Active FR3058243B1 (fr) 2016-10-31 2017-03-30 Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique

Family Applications Before (1)

Application Number Title Priority Date Filing Date
FR1660566A Active FR3058292B1 (fr) 2016-10-31 2016-10-31 Procede de fourniture d'un service a un utilisateur

Country Status (2)

Country Link
US (1) US10817967B2 (fr)
FR (2) FR3058292B1 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
CN107533501A (zh) * 2015-03-20 2018-01-02 里维茨公司 使用区块链自动认证设备完整性
US9667427B2 (en) 2015-10-14 2017-05-30 Cambridge Blockchain, LLC Systems and methods for managing digital identities
US10861019B2 (en) * 2016-03-18 2020-12-08 Visa International Service Association Location verification during dynamic data transactions
US11843597B2 (en) * 2016-05-18 2023-12-12 Vercrio, Inc. Automated scalable identity-proofing and authentication process
US10148649B2 (en) * 2016-05-18 2018-12-04 Vercrio, Inc. Automated scalable identity-proofing and authentication process
ES2869256T3 (es) * 2017-10-23 2021-10-25 Siemens Ag Procedimiento y sistema de control para el control y/o la supervisión de dispositivos
EP3528468B1 (fr) * 2018-02-20 2021-04-07 Nokia Technologies Oy Partage d'informations de profil
SG11202100712PA (en) 2018-07-23 2021-02-25 Cambridge Blockchain Inc Systems and methods for secure custodial service
US11838425B2 (en) * 2019-05-20 2023-12-05 Jpmorgan Chase Bank, N.A. Systems and methods for maintaining decentralized digital identities
FR3099017B1 (fr) * 2019-07-16 2021-08-06 Idemia Identity & Security France Procédé de vérification d’une transaction dans une base de données de type chaîne de blocs
CN111881482B (zh) * 2020-08-05 2023-03-28 黄灿楠 基于区块链技术的用户身份隐私加密方法
US12051066B2 (en) 2022-03-15 2024-07-30 Capital One Services, Llc Systems and methods for validating asset destinations in blockchain networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160105414A1 (en) * 2014-10-13 2016-04-14 Morpho Method for Authenticating a Client Device to a Server Using a Secret Element
WO2016128906A1 (fr) * 2015-02-11 2016-08-18 Visa International Service Association Systèmes et procédés de gestion sécurisée de données biométriques

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9767453B2 (en) * 2012-02-23 2017-09-19 XRomb Inc. System and method for processing payment during an electronic commerce transaction
US9628467B2 (en) * 2013-03-15 2017-04-18 Aerohive Networks, Inc. Wireless device authentication and service access
US9749297B2 (en) * 2014-11-12 2017-08-29 Yaron Gvili Manicoding for communication verification
KR101637854B1 (ko) * 2015-10-16 2016-07-08 주식회사 코인플러그 블록체인을 기반으로 하는 공인인증서 발급시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 발급방법 및 블록체인을 기반으로 하는 공인인증서 인증시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 인증방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160105414A1 (en) * 2014-10-13 2016-04-14 Morpho Method for Authenticating a Client Device to a Server Using a Secret Element
WO2016128906A1 (fr) * 2015-02-11 2016-08-18 Visa International Service Association Systèmes et procédés de gestion sécurisée de données biométriques

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHAUM D ET AL: "CRYPTOGRAPHICALLY STRONG UNDENIABLE SIGNATURES, UNCONDITIONALLY SECURE FOR THE SIGNER", ADVANCES IN CRYPTOLOGY. SANTA BARBARA, AUG. 11 - 15, 1991; [PROCEEDINGS OF THE CONFERENCE ON THEORY AND APPLICATIONS OF CRYPTOGRAPHIC TECHNIQUES (CRYPTO)], BERLIN, SPRINGER, DE, vol. -, 16 April 1992 (1992-04-16), pages 470 - 484, XP000269044 *

Also Published As

Publication number Publication date
FR3058292A1 (fr) 2018-05-04
FR3058292B1 (fr) 2019-01-25
FR3058243B1 (fr) 2018-11-23
US10817967B2 (en) 2020-10-27
US20180122031A1 (en) 2018-05-03

Similar Documents

Publication Publication Date Title
FR3058243A1 (fr) Procede de controle d&#39;identite d&#39;un utilisateur au moyen d&#39;une base de donnees publique
EP3547202B1 (fr) Méthode d&#39;accès à des données anonymisées
EP2819052B1 (fr) Procédé et serveur de traitement d&#39;une requête d&#39;accès d&#39;un terminal à une ressource informatique
EP3547203A1 (fr) Méthode et système de gestion d&#39;accès à des données personnelles au moyen d&#39;un contrat intelligent
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
FR2922702A1 (fr) Securisation de fichiers informatiques telechargeables sur un aeronef basee sur l&#39;identite d&#39;entites, procede d&#39;authenfication, systeme et aeronef associes
CA2895189C (fr) Signature de groupe utilisant un pseudonyme
EP1829280A2 (fr) PROCEDE D&#39;AUTHENTIFICATION SECURISEE POUR LA MISE EN &amp;OElig;UVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES
EP3789901A1 (fr) Méthode d&#39;authentification sélective d&#39;un utilisateur de chaine de blocs auprès d&#39;un contrat intelligent
EP3316549B1 (fr) Procédé de contrôle d&#39;identité d&#39;un utilisateur au moyen d&#39;une base de données publique
FR3107416A1 (fr) Tokenisation aléatoire efficace dans un environnement dématérialisé
EP2742645B1 (fr) Procédé de gestion et de contrôle de données de différents domaines d&#39;identité organisés en ensemble structure
WO2017162930A2 (fr) Dispositif d&#39;authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé
EP3836480A1 (fr) Procede et dispositif permettant de determiner la possibilite d&#39;utilisation d&#39;une clef cryptographique pour effectuer une operation cryptographique
WO2021122186A1 (fr) Procédé et dispositif de contrôle d&#39;accès anonyme à une plateforme collaborative d&#39;anonymisation
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
FR2898423A1 (fr) Procede securise de configuration d&#39;un dispositif de generation de signature electronique.
FR2913551A1 (fr) Methode d&#39;authentification mutuelle et recurrente sur internet.
Gestin Privacy-preserving and fully distributed identity management systems
EP3863219A1 (fr) Procédé et dispositif d&#39;évaluation de correspondance d&#39;ensembles de données structurées protégées par le chiffrement
FR2881591A1 (fr) Mise en oeuvre d&#39;une operation cryptographique a distance d&#39;une pki
EP3063898B1 (fr) Signature à pseudonyme pour carte à puce
WO2021198606A1 (fr) Procede et dispositif d&#39;authentification d&#39;un utilisateur aupres d&#39;une application
FR3150007A3 (fr) Procede d’identification
FR3140184A1 (fr) Procédé et dispositif d’attribution d’un NFT

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180504

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

CA Change of address

Effective date: 20230124

CD Change of name or company name

Owner name: IDEMIA IDENTITY & SECURITY FRANCE, FR

Effective date: 20230124

PLFP Fee payment

Year of fee payment: 8