FR 3058292 A1 20180504 FR 1660566 A 20161031 1 DOMAINE DE L'INVENTION La présente invention concerne un procédé de fourniture d'un service à un utilisateur. ETAT DE LA TECHNIQUE Sont apparues ces dernières années des bases de données appelées - chaines 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 - chaine de blocs » est celle utilisée dans le système de transaction de monnaie électronique Bitcoin0. 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 chaine 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'un 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 3058292 2 é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 5 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 10 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 oeuvre mettre en oeuvre les mêmes étapes que celles mises en oeuvre par l'employeur : utiliser le traitement mis à disposition du public pour générer un hash de 15 diplôme électronique témoin et rechercher si le hash est contenue 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é. 20 EXPOSE DE L'INVENTION Un but de l'invention est de fournir un service à un utilisateur en fonction de l'identité de la personne, 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. 25 Il est dès lors proposé, selon un premier aspect de l'invention, un procédé de fourniture d'un service à un utilisateur en fonction de l'identité de cet utilisateur, comprenant des étapes de : - réception, par un dispositif fournisseur de service, d'une demande de service à fournir à un dispositif client appartenant à un utilisateur demandeur, 30 - 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é de l'utilisateur demandeur et à partir d'au moins une donnée d'aléa propre à l'utilisateur demandeur, - vérification du respect d'une condition sur les données protégées en confidentialité 35 trouvées, 3058292 3 - fourniture, par le dispositif fournisseur de service, du service demandé au dispositif client seulement si la condition est respectée. La base de données utilisée étant publique, les données hachées peuvent être lues par tout tiers. Toutefois, les données hachées dépendent non seulement d'au moins un 5 é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 un utilisateur se voit rendre le service par le dispositif fournisseur. 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 hachées. Il lui faut en effet connaître également la donnée d'aléa. 10 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. Le procédé peut comprendre des étapes de : - génération, par le dispositif fournisseur de service, de données protégées en 15 confidentialité à partir de l'élément d'identité de l'utilisateur demandeur et de la donnée d'aléa propre à l'utilisateur demandeur, - fourniture du service par le dispositif fournisseur de service seulement si le dispositif fournisseur de service 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 20 d'identité et égales aux données protégées en confidentialité générées par le dispositif fournisseur de service. Le procédé peut comprendre des étapes de : - génération, par le dispositif client, de données de preuve qui dépendent de l'élément d'identité de l'utilisateur demandeur et de la donnée d'aléa propre à 25 l'utilisateur demandeur, - mémorisation, dans la 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, les données de preuve étant par ailleurs associées dans la base de données publique à des données protégées en confidentialité préalablement générées par le dispositif 30 attesteur d'identité de façon à indiquer que les données de preuve et les données protégées en confidentialité associées ont été générées à partir d'un même élément d'identité et d'une même donnée d'aléa, - fourniture d'un service demandé par le dispositif client seulement si les conditions suivantes sont remplies : 3058292 4 o le dispositif fournisseur de service trouve, dans la base de données publique, des données de preuve à la fois générées par le dispositif client et associées à des données protégées en confidentialité par le dispositif attesteur d'identité, et 5 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 être obtenues par application d'une fonction de hachage prédéterminée H à des données x0,..., xi.", où : 10 - n est un entier supérieur ou égal à 2, - au moins l'un des x, est une donnée d'aléa propre à l'utilisateur demandeur, et chaque autre x, est un élément d'identité de l'utilisateur demandeur, et dans lequel les données de preuve comprennent : - une donnée c calculée par la formule : c = h(H(A0, ..., An)) 15 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 fo, ...,fn calculées par application des formules Vi E [[0,n]] f, = A, + cx, la relation mathématique détectée par le dispositif fournisseur de service étant en outre H (fo-- fn) =c (H (xo, ...,24'))c 20 Il peut en outre être prévu que : - les données protégées en confidentialité générées par le dispositif attesteur d'identité soient 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é à l'utilisateur demandeur un montant prédéterminé d'une monnaie électronique, 25 - les données de preuve générées par le dispositif client soient associées dans la base de données publique à des deuxièmes données de transaction indiquant que l'utilisateur demandeur a transféré au dispositif fournisseur de service le montant prédéterminé reçu du dispositif attesteur d'identité. Le procédé peut comprendre la génération par le dispositif fournisseur de service et 30 mémorisation, dans la base de données publique, de données de confirmation indiquant que le service a été fourni à l'utilisateur demandeur. 3058292 5 Les données de confirmation générées par le dispositif fournisseur de service peuvent être associées dans la base de données publique à des troisièmes données de transaction indiquant que le dispositif fournisseur de service a transféré au dispositif attesteur d'identité le montant prédéterminé. 5 Le procédé peut comprendre des étapes de : - après que le service a été rendu par le dispositif fournisseur de service à l'utilisateur demandeur, 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 l'utilisateur demandeur et d'au moins une nouvelle donnée d'aléa propre à 10 l'utilisateur demandeur, - 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 oeuvre 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é. 15 La base de données publique peut être une base de données distribuée de type chaine 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 20 formule : i=0 où : - n est un entier supérieur ou égal à 2, - au moins l'un des x, est une donnée d'aléa propre à l'utilisateur demandeur, et chaque autre x, est un élément d'identité de l'utilisateur demandeur, 25 - 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 données protégées en confidentialité peuvent avoir été 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. 30 Le procédé peut comprendre des étapes de : - signature électronique des données de preuve au moyen d'une clé privée propre à l'utilisateur demandeur, avant leur mémorisation dans la base de données publique, 3058292 6 - accès, par le dispositif fournisseur de service, 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 demandeur. Le service peut être fourni par le dispositif fournisseur de service seulement si le 5 dispositif fournisseur de service 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 demandeur 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 10 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 15 fournisseur de service à un utilisateur, le dispositif comprenant : - une interface de communication pour recevoir une demande de service à fournir à un dispositif client appartenant à un utilisateur demandeur, - au moins un processeur configuré pour : o commander la lecture, dans une base de données publique, d'éventuelles 20 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 demandeur et à partir d'au moins une donnée d'aléa propre à l'utilisateur demandeur, o vérifier le respect d'une condition sur les données protégées en 25 confidentialité trouvées, o fournir le service demandé au dispositif client seulement si la preuve est établie. Il est en outre proposé, selon un quatrième aspect de l'invention un système 30 comprenant : - un dispositif fournisseur de service 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. 35 3058292 7 DESCRIPTION DES FIGURES D'autres caractéristiques, buts et avantages de l'invention ressortiront de la 5 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 10 mis en oeuvre 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é 15 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 fournisseur de service 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 un combinaison de tels réseaux. 20 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 25 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 30 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. 3058292 8 Le dispositif fournisseur de service 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 fournisseur de service 3 mémorise une clé publique et une clé privée mutuellement associées et qui lui sont propres. 5 La base de données 4 est distribuée dans le réseau R, c'est-à-dire qu'elle est stockée par une pluralité de noeuds 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 10 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 noeuds de stockage configurés pour valider des données écrite dans la base de données par la mise en oeuvre 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 15 données 4 est ainsi protégé contre des falsifications et ce malgré son caractère distribué. 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. 20 Chacun des trois dispositifs 1, 2, 3 comprend au moins un processeur configure 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 25 ê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 fournisseur de service 3 est, comme son nom 30 l'indique, de fournir un service prédéterminé à un utilisateur agréé par le dispositif 1. Par exemple, le dispositif fournisseur de service 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. 3058292 9 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 fournisseur de service 3. Le dispositif client 2 est par exemple un smartphone ou un ordinateur portable. 5 Procédé de fourniture de service en fonction de l'identité d'un utilisateur Il est 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 10 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é 15 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 20 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 25 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 30 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 : - elements d'identité de niveau 1 : majorité de l'utilisateur U 3058292 10 - elements 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. 5 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 à 10 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. 15 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 20 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 25 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, xo désigne la donnée d'aléa, et x1 à xn sont n éléments d'identité fournis au dispositif attesteur d'identité 1, n étant supérieur ou égal à 1. L'ensemble des 30 éléments d'identités x1 à 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ée 35 n'apparaissent pas en clair dans les données protégées en confidentialité. 3058292 11 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 : H(x0,...,xn). 5 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 10 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)= HG,xi =0 15 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 fournisseur de service 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 20 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 utilisateur agréé pourra se voir un rendre un service par le dispositif fournisseur de service 3 tandis qu'un utilisateur non agréée ne pourra pas avoir accès à un tel service. 25 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 30 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. 3058292 12 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 5 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(xo, ...,xn) 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é 10 pour stocker les données hachées. Plus tard, l'utilisateur U souhaite accéder au service rendu par le dispositif fournisseur de service 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 fournisseur de service 3, via un canal préalablement établi entre les 15 dispositifs 2 et 3 (étape 116). Sur réception de cette demande, le dispositif fournisseur de service 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 20 U. Si de telles données hachées sont trouvées dans la base de données 4, le dispositif fournisseur de service vérifie si une condition sur les données hachées est remplie. Si la condition est remplie, le dispositif fournisseur de service 3 fournit le service demandé au dispositif client 2 (étape 122). Le dispositif fournisseur de service 3 déduit en 25 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 fournisseur de service 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 30 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(xo, ... , xi.") 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. 3058292 13 En d'autres termes, le dispositif fournisseur de service 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 fournisseur de service 3 n'a pas eu à communiquer directement avec le dispositif attesteur d'identité 1 pour décider si le 5 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 fournisseur de service 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). 10 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 15 tel que Bitcoin® ou équivalent est particulièrement aisée à mettre en oeuvre. 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 20 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 25 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 xo propre à 30 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 fo,..., fn, lesquelles sont calculées comme suit : C = h(H(A0, , An)) = h(HG,Ai) i=0 3058292 14 où h est une fonction de hachage prédéterminée (par exemple différente de la fonction H), et Ao, ...,An sont n données tirées aléatoirement ; et Vi E [[0,n]] f,= A,+ cx, Le dispositif client 2 commande la mémorisation, dans la base de données 4, les données de preuve c, fo,..., fn de façon à indiquer que les données de preuve ont été 5 générées par le dispositif client 2 (étape 112). Les données c, fo,...,fn 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é x1, ...,xn et de la même 10 donnée d'aléa xo (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 15 génère des deuxièmes données de transaction T(K,2=>3) indiquant que l'utilisateur demandeur U transfert au dispositif fournisseur de service 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 20 base de données 4 avec la clé publique du dispositif fournisseur de service 3, de sorte à indiquer que le dispositif fournisseur de service 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 25 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 30 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 fournisseur de service 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. 3058292 15 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 oeuvre par le dispositif fournisseur 3 en 5 réponse à la réception de la demande de service émise par le dispositif client 2 au cours de l'étape 114. Le dispositif fournisseur de service 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 10 contenu du champ OP_RETURN des deuxièmes données de transaction T(K,2=>3). Le dispositif fournisseur de service 3 a donc à ce stade connaissance des données de preuve c, fo, ..., fi,. Par ailleurs, comme indiqué plus haut, le dispositif fournisseur de service 3 a également connaissance de la fonction H. Il est également supposé que le dispositif fournisseur de service 3 connaît la fonction h. 15 Le dispositif fournisseur de service 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. 20 Dans le cas où le système Bitcoin® est utilisé, le dispositif fournisseur de service 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 fournisseur de service 3 lit le contenu du champ OP_RETURN desdites données de transaction et considère 25 qu'il s'agit de données hachées générées par le dispositif attesteur d'identité 1. Dans le cas de l'utilisateur U, les K bitcoins transférés par le dispositif client 2 au dispositif fournisseur de service 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 30 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 fournisseur de service connait les données de preuve mais également les données hachées auxquelles les données de preuves sont associées. 3058292 16 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 (fo, fn) _ (H(xo, xi.')) 5 Par exemple, dans le cas où H(x0,...,xn)=1-1r=0G,x1 cette relation mathématique prédéterminée devient : h nr,0G,fi c) = c (Fir=o Glxi) Le dispositif fournisseur de service 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 fournisseur 10 de service 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 fournisseur de service 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 x, (éléments d'identité et donnée d'aléa). Le dispositif fournisseur 3 n'a en effet utilisé que les données 15 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. 20 Deuxième mode de réalisation Dans un deuxième mode de réalisation non illustré, plus simple de mise en oeuvre que le premier mode de réalisation, les valeurs des termes x, (éléments d'identité et donnée d'aléa) sont fournis au dispositif fournisseur de service 3 par l'utilisateur demandeur U. Les 25 valeurs des termes x, sont par exemple transmises par le dispositif client 2 au dispositif fournisseur de service 3. Le dispositif fournisseur de service 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 30 fonction H dont il a connaissance. h 3058292 17 Le dispositif fournisseur de service 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 fournisseur de service 3. 5 Si tel est le cas, le dispositif fournisseur de service 3 fournit le service demandé dans l'étape 122. Sinon, le dispositif fournisseur de service 3 rejette la demande de service. Etapes postérieures à la fourniture du service Après que le service a été rendu par le dispositif fournisseur de service 3 à 10 l'utilisateur demandeur U au cours de l'étape 122, le dispositif fournisseur de service 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 fournisseur de service 3 (étape 126). 15 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 fournisseur de service 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. 20 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 fournisseur de service 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 25 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 fournisseur de service 3 a rendu un service à un utilisateur U qu'il a précédemment agréé, sans pour autant communiquer directement avec le dispositif fournisseur de service 3 puisqu'il suffit au dispositif attesteur d'identité 1 de lire (étape 128) les données de 30 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 fournisseur de service 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 35 l'utiliser plusieurs fois auprès du dispositif fournisseur de service 3. 3058292 18 Par exemple, après que le service a été rendu par le dispositif fournisseur de service 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 5 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 10 clés publique et privée après que le service a été rendu par le dispositif fournisseur de service 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. 15 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é 20 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 fournisseur de service 3 seulement si le dispositif fournisseur de service 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 25 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 30 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 fournisseur de service 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. 3058292 19 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 fournisseur de service 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. 5 Le procédé décrit ci-dessus n'est bien 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 de service à rendre en fonction de l'identité de l'utilisateur demandeur U. 10 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 15 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 20 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é 25 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 30 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. REVENDICATIONS1. Procédé de fourniture d'un service à un utilisateur (U) en fonction de l'identité de cet utilisateur (U), comprenant des étapes de : - réception, par un dispositif fournisseur de service (3), d'une demande de service à fournir à un dispositif client (2) appartenant à un utilisateur demandeur (U), - 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é de l'utilisateur demandeur (U) et à partir d'au moins une donnée d'aléa propre à l'utilisateur demandeur (U), - vérification (120) du respect d'une condition sur les données protégées en confidentialité trouvées, - fourniture (122), par le dispositif fournisseur de service (3), du service demandé au dispositif client (2) seulement si la condition est respectée. 15 2. Procédé selon la revendication 1, comprenant des étapes de: - génération, par le dispositif fournisseur de service (3), de données protégées en confidentialité à 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), 20 - fourniture du service par le dispositif fournisseur de service (3) seulement si le dispositif fournisseur de service (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 données protégées en confidentialité générées par le dispositif fournisseur de service (3). 25 3. Procédé selon la revendication 1, comprenant des étapes de : - génération (110), par le dispositif client (2), de données de preuve qui dépendent de l'élément d'identité de l'utilisateur demandeur (U) et de la donnée d'aléa propre à l'utilisateur demandeur (U), 30 - mémorisation (112), dans la 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), les données de preuve étant par ailleurs associées dans la base de données publique (4) à des données protégées en confidentialité préalablement générées par le dispositif attesteur d'identité (1) de façon à indiquer que les 3058292 21 données de preuve et les données protégées en confidentialité associées ont été générées à partir d'un même élément d'identité et d'une même donnée d'aléa, - fourniture (122) d'un service demandé par le dispositif client (2) seulement si les conditions suivantes sont remplies : 5 o le dispositif fournisseur de service (3) trouve, dans la base de données publique (4), des données de preuve à la fois générées par le dispositif client (2) et associées à des données protégées en confidentialité par le dispositif attesteur d'identité (1), et o les données protégées en confidentialité trouvées et les données de preuve 10 associées aux données protégées en confidentialité trouvées sont liées par une relation mathématique prédéterminée. 4. Procédé selon la revendication précédente, dans lequel les données protégées en confidentialité sont obtenues par application d'une fonction de hachage prédéterminée H à des données x0,...,x', où : - n est un entier supérieur ou égal à 2, - au moins l'un des x, est une donnée d'aléa propre à l'utilisateur demandeur (U), et chaque autre x, est un élément d'identité de l'utilisateur demandeur (U), et dans lequel les données de preuve comprennent : - une donnée c calculée par la formule : c = h(H(A0, ..., An)) 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 fo, ...,fn calculées par application des formules Vi E [[0,n]] f, = A, + cx, la relation mathématique détectée par le dispositif fournisseur de service (3) étant en 25 outre H (fo-- fn) c (H (xo, ,xn))c) 5. Procédé selon l'une des revendications 3 à 4, 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 30 données de transaction indiquant que le dispositif attesteur d'identité (1) a transféré à l'utilisateur demandeur (U) un montant prédéterminé d'une monnaie électronique, 3058292 22 - les données de preuve générées par le dispositif client (2) sont associées dans la base de données publique (4) à des deuxièmes données de transaction indiquant que l'utilisateur demandeur (U) a transféré au dispositif fournisseur de service (3) le montant prédéterminé reçu du dispositif attesteur d'identité (1). 5 6. Procédé selon l'une des revendications précédentes, comprenant par ailleurs une : - génération (124) par le dispositif fournisseur de service (3) 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 demandeur (U). 10 7. Procédé selon les revendications 5 et 6 prises en combinaison, dans lequel : - les données de confirmation générées par le dispositif fournisseur de service (3) sont associées dans la base de données publique (4) à des troisièmes données de transaction indiquant que le dispositif fournisseur de service (3) a transféré au 15 dispositif attesteur d'identité (1) le montant prédéterminé. 8. Procédé selon l'une des revendications précédentes, comprenant en outre des étapes de - après que le service a été rendu par le dispositif fournisseur de service (3) à l'utilisateur demandeur (U), génération (102) par le dispositif attesteur d'identité 20 (1) de nouvelles données protégées en confidentialité à partir de l'élément d'identité de l'utilisateur demandeur (U) et d'au moins une nouvelle donnée d'aléa propre à l'utilisateur demandeur (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 oeuvre 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é. 9. 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 chaine de blocs. 10. 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. 3058292 23 11. 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 i=0 ti où : - n est un entier supérieur ou égal à 2, 5 - au moins l'un des x, est une donnée d'aléa propre à l'utilisateur demandeur (U), et chaque autre x, est un élément d'identité de l'utilisateur demandeur (U), - 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. 10 12. 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). 15 13. 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 demandeur (U), avant leur mémorisation dans la base de données 20 publique (4), - accès, par le dispositif fournisseur de service (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 demandeur (U). 25 14. Procédé selon l'une des revendications précédentes, dans lequel le service est fourni par le dispositif fournisseur de service (3) seulement si le dispositif fournisseur de service (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 demandeur (U) a été révoquée par le dispositif 30 attesteur d'identité (1). 3058292 24 15. 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. 5 16. Dispositif fournisseur de service (3) à un utilisateur (U), le dispositif comprenant : - une interface de communication pour recevoir une demande de service à fournir à un dispositif client (2) appartenant à un utilisateur demandeur (U), - au moins un processeur configuré pour : o commander la lecture, dans une base de données publique (4), d'éventuelles 10 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 demandeur (U) et à partir d'au moins une donnée d'aléa propre à l'utilisateur demandeur (U), o vérifier (120) le respect d'une condition sur les données protégées en 15 confidentialité trouvées, o fournir le service demandé au dispositif client (2) seulement si la preuve est établie. 17. Système comprenant : 20 - un dispositif fournisseur de service (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). 25