Brevet FR3094521A1 — publié le 20201002

Description Titre de l'invention : Procédés et dispositifs permettant de prouver la connaissance d'une donnée par un utilisateur d'une chaîne de blocs Technique antérieure 100011 L'invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »). 100021 Comme indiqué dans le document (https://fr.wikipedia.org/wiki/Blockchain), on rappelle que « la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la hase sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une hase de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les noeuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système réparti». 100031 Les chaînes de blocs sont caractérisées en outre en ce que leurs contenus ne peuvent pas être modifiés ou supprimés : une information publiée dans une chaîne de blocs le reste pour toujours. Nous désignons par information « publiée » dans une chaîne de blocs, une information enregistrée ou sauvegardée dans celle-ci. [0004] Une problématique qui se pose dans le cadre de la technologie des chaines de blocs est de certifier des données des utilisateurs. Notamment, ces données peuvent être relatives à des attributs des utilisateurs tels que leurs noms, prénoms, adresses, numéros de téléphone, compte sur un réseau social, etc. Un mécanisme dit « de preuve » est requis pour assurer que les données des utilisateurs sont des données correctes (vraies). [0005] L'article Al-Bassam, M., "A smart contract-based PKI and identity system", Proc. ACM Workshop on Blockchain, Cryptocurrencies and Contracts. ACM, 2017. pages 35-40, propose un modèle de gestion d'identités des utilisateurs basé sur des contrats intelligents (connus sous le nom de « Smart Contracts » en anglais). Dans ce modèle, un utilisateur public ses attributs de manière à les rendre publiques. Les attributs peuvent alors être signés par un tiers sur la chaîne de blocs afin de garantir leur authenticité. [0006] Cette solution oblige l'utilisateur à divulguer ses données personnelles à tous les uti- lisateurs de la chaîne. 2 100071 11 existe donc un besoin d'une méthode de vérification de la certification de données des utilisateurs qui ne présente pas les inconvénients des méthodes de l'art antérieur. Exposé de l'invention [0008] L'invention vise un procédé de demande d'attestation auprès d'une entité de confiance inscrite à une chaîne de blocs de la connaissance d'une première donnée par un utilisateur inscrit à la chaîne de blocs, le procédé comportant des étapes de : - réception en dehors de la chaîne de blocs, en provenance de l'entité de confiance, d'une deuxième donnée obtenue à partir de ladite première donnée, l'entité de confiance ayant eu connaissance de la première donnée en dehors de la chaîne de blocs ; et - publication, par un terminal de l'utilisateur, de la deuxième donnée dans la chaîne de blocs; ladite entité de confiance étant configurée pour publier la deuxième donnée dans la chaîne de blocs à une date ultérieure à la date de la publication de la deuxième donnée dans la chaîne de blocs par le terminal de l'utilisateur. [0009] Corrélativement, l'invention vise un terminal d'un utilisateur inscrit à une chaîne de blocs, le terminal étant configuré pour demander une attestation auprès d'une entité de confiance inscrite à la chaîne de blocs, de la connaissance d'une première donnée par l'utilisateur, cc terminal comportant : - des moyens de communication configurés pour recevoir en dehors de la chaîne de blocs, en provenance de l'entité de confiance, une deuxième donnée obtenue à partir de la première donnée, l'entité de confiance ayant eu connaissance de la première donnée en dehors de la chaîne de blocs ; et - un module de publication configuré pour publier la deuxième donnée dans la chaîne de blocs ; l'entité de confiance étant configurée pour publier la deuxième donnée dans la chaîne de blocs à unc date ultérieure à la date de la publication de la deuxième donnée dans la chaîne de blocs par le terminal de l'utilisateur. [0010] Les caractéristiques et avantages du procédé de demande d'attestation selon l'invention présentés ci-après s'appliquent de la même façon au terminal selon l'invention et vice versa. [0011] Au sens de l'invention, la première donnée peut être une donnée personnelle de l'utilisateur (ou attribut): nom, prénom, numéro de téléphone, adresse postale, adresse e-mail, âge, profession, etc. La première donnée peut être également un objet multimédia tel qu'une photo, une vidéo, un document de texte, etc. [0012] Dans la description, nous utilisons de façon équivalente, et pour une même signi- fication, les expressions de « utilisateur inscrit à la chaîne de blocs » ou de « terminal (de cet utilisateur) inscrit à la chaîne de blocs ». [0013] Conformément à l'invention, le terminal peut être un téléphone mobile de type 3 smartphonc, un ordinateur, une tablette, ou tout autre dispositif communicant permettant à un utilisateur d'accéder à une chaîne de blocs. [0014] Tel que mentionné précédemment, on désigne par une donnée publiée dans la chaîne de blocs, une donnée enregistrée sur celle-ci. Pour publier une donnée dans la chaîne de blocs, un utilisateur envoie cette donnée à la chainc de blocs. Suite à l'envoi de la donnée, un utilisateur « mineur » ou « valideur » insère cette donnée dans un bloc de la chaîne, puis diffuse (public) le nouveau bloc mis à jour. Au sens de l'invention, on désigne par la date de publication d'une donnée dans la chaîne de blocs, la date d'ajout du bloc à la chainc. [0015] Au sens de l'invention, la publication par un terminal d'un utilisateur (ou par l'entité de confiance) désigne : - soit une publication dans la chaîne de blocs lorsque cet utilisateur (ou l'entité de confiance) est un utilisateur mineur ou validcur, - soit une demande de publication pour qu'un autre utilisateur inscrit à la chaîne de blocs en tant que mineur ou validcur publie la deuxième donnée dans la chaîne de blocs. [0016] Conformément à l'invention, l'entité de confiance peut déployer un service Oracle. On rappelle qu'un Oracle est un service autorisé à entrer une donnée dans la chaîne de blocs à la demande d'un utilisateur. A titre indicatif, l'article « Les Oracles, lien entre la hlockchain et le monde » de Simon Polrot, publié le 13/09/2016 sur le site ethereum-france.com » définit et décrit le fonctionnement d'un Oracle. [0017] L'invention permet à un tiers qui consulte la chaîne de blocs de vérifier que l'utilisateur détenait la première donnée. En effet, le terminal publiant la deuxième donnée (obtenue à partir de la première donnée) avant l'entité de confiance, on s'assure que le terminal n'a pas simplement recopié la deuxième donnée publiée dans la chaîne de blocs par l'Oracle, mais qu'il a effectivement reçu la donnée de l'Oracle par une autre voie. Le fait qu'il a reçu la deuxième donnée de l'Oracle par une autre voie et que cette deuxième donnée a été générée par l'Oracle à partir de la première donnée constitue une preuve que l'utilisateur détenait la donnée avant que l'Oracle ne rende publique la preuve de connaissance de cette donnée par l'utilisateur. [0018] Au sens de l'invention, une « date » peut désigner un instant, une heure, un jour, ou n'importe quelle mesure temporelle. [0019] L'invention permet aussi d'éviter à l'utilisateur de divulguer sa première donnée aux utilisateurs de la chaîne hot-mis Oracle. L'invention permet donc de protéger les données personnelles de l'utilisateur. [0020] Cependant, il est envisageable que l'étape de publication par le terminal comporte en outre une publication de la première donnée. [0021] Dans un mode de réalisation, le procédé de demande d'attestation conforme à l'invention comporte en outre une étape d'envoi par l'utilisateur, en dehors de la chaîne de blocs, de la première donnée à l'entité de confiance. Cette étape d'envoi de la première donnée, en dehors de la chaîne de blocs, peut être mise en oeuvre via un réseau de communication entre le terminal de l'utilisateur et l'entité de confiance. [0022] La première donnée peut être envoyée, par un terminal de l'utilisateur par exemple, sous forme d'un message vocal ou d'un texte. [0023] Dans un mode de réalisation, l'étape de réception de la deuxième donnée est mise en oeuvre par un terminal de l'utilisateur. [0024] Les étapes du procédé de demande d'attestation conforme à l'invention, d'envoi de la première donnée, de réception de la deuxième donnée, et de publication peuvent être mises en oeuvre par un même terminal de l'utilisateur ou par différents terminaux de l'utilisateur. [0025] Dans un mode de réalisation, le procédé de demande d'attestation conforme à l'invention comporte en outre une étape d'envoi à l'entité de confiance, d'une requête de la deuxième donnée. Cette requête peut comprendre la première donnée ou un identifiant permettant à l'entité de confiance d'identifier la première donnée. La deuxième donnée est reçue en provenance de l'entité de confiance en réponse à cette requête. [0026] Dans un autre mode, la deuxième donnée est reçue sans qu'une requête ait été envoyée. Par exemple, la décision d'envoyer la deuxième donnée est prise par l'entité de confiance ou par l'Oracle. [0027] Dans un mode de réalisation, l'étape de publication par le terminal comporte en outre une publication d'une information d'horodatage de cette publication. Cette information d'horodatage peut être utilisée par un tiers qui consulte la chaise de blocs pour comparer des dates de publications. Cependant, le tiers peut retrouver dans la chaîne de blocs cette date de publication ; il n'est pas donc nécessaire que cette date soit publiée explicitement. [0028] Dans un mode de réalisation, la deuxième donnée est publiée avec la première donnée. [0029] Dans un autre mode, la deuxième donnée est publiée en association avec une in- formation permettant d'identifier un type de la première donnée, par exemple une information de type « cette publication est relative à un numéro de téléphone d'Alice ». [0030] Dans un mode de réalisation, ce procédé de demande d'attestation conforme à l'invention comporte en outre une étape d'envoi, en dehors de la chaîne de blocs, à l'entité de confiance : - d'une date dite de publication à laquelle l'étape de publication par le terminal est mise en oeuvre ; et/ou - d'une plage de dates durant laquelle l'entité de confiance doit publier la deuxième donnée dans la chaîne de blocs. [0031] Ce mode permet de garantir que la deuxième donnée est publiée par le terminal de l'utilisateur avant l'entité de confiance. [0032] Dans un mode de réalisation de l'invention, le procédé de demande d'attestation conforme à l'invention comporte en outre une étape de sélection d'une ou de plusieurs entités de confiance inscrite(s) à la chaîne de blocs. [0033] Ce mode permet à l'utilisateur de choisir avec quelle(s) entité(s) de confiance il collabore pour prouver qu'il connaît la première donnée. Ce mode permet aussi à l'utilisateur de choisir le nombre d'entités de confiance. [0034] L'invention vise également un procédé permettant de prouver la connaissance d'une première donnée par un utilisateur inscrit à une chaîne de blocs, ce procédé étant mis en oeuvre par une entité de confiance inscrite à la chaîne de blocs et comportant des étapes de : - obtention de la première donnée en dehors de la chaîne de blocs ; - génération d'une deuxième donnée à partir de la première donnée ; - envoi, en dehors de la chaîne de blocs, de la deuxième donnée à l'utilisateur ; - publication de la deuxième donnée dans la chaîne de blocs après une publication de la deuxième donnée dans la chaîne de blocs par un terminal de l'utilisateur. [0035] Corrélativement, l'invention vise un dispositif de communication, comportant une entité de confiance inscrite à une chaîne de blocs, le dispositif étant configuré pour permettre de prouver la connaissance d'une première donnée par un utilisateur inscrit à la chaîne de blocs, le dispositif comportant : - des moyens de communication configurés pour obtenir la première donnée en dehors de la chaîne de blocs ; - un module de génération configuré pour générer une deuxième donnée à partir de la première donnée ; - les moyens de communication étant configurés en outre pour envoyer, en dehors de la chaîne de blocs, la deuxième donnée à l'utilisateur ; et - un module de publication configuré pour publier la deuxième donnée dans la chaîne de blocs après une publication de la deuxième donnée dans la chaîne de blocs par un terminal de l'utilisateur. [0036] Les caractéristiques et avantages de ce procédé permettant de prouver la connaissance selon l'invention présentés ci-après s'appliquent de la même façon au dispositif selon l'invention et vice versa. [0037] Les caractéristiques et avantages du procédé de demande (et du terminal) selon l'invention déjà présentés s'appliquent de la même façon au procédé permettant de prouver la connaissance et au dispositif selon l'invention et vice versa. [0038] Dans un mode de réalisation, l'étape d'obtention de la première donnée comporte 6 une réception de celle-ci en provenance d'un terminal de l'utilisateur. [0039] Dans un mode de réalisation, le dispositif conforme à l'invention envoie la deuxième donnée à un terminal de l'utilisateur. En particulier, ce terminal peut être différent du terminal en provenance duquel le dispositif a reçu la première donnée. [0040] Dans un mode de réalisation, le dispositif conforme à l'invention met en oeuvre un service Oracle. [0041] Dans un mode de réalisation, la deuxième donnée envoyée au terminal est un mot de passe à usage unique, généré selon une méthode OTP (pour « One-Time Password » en anglais). Ce mot de passe peut être envoyé à un numéro de téléphone ou une adresse email ou postale de l'utilisateur. [0042] Dans un autre mode de réalisation, la deuxième donnée est générée par un hachage ou un chiffrement de la première donnée et/ou d'un aléa généré par l'entité de confiance. [0043] Dans un mode de réalisation, la deuxième donnée est un fichier signé avec une clé privée de l'entité de confiance. [0044] Dans un mode de réalisation, le procédé permettant de prouver la connaissance de la première donnée comporte en outre une étape de détection de la publication de la deuxième donnée dans la chaîne de blocs par un terminal de l'utilisateur. Cette étape de détection comporte une lecture de blocs de la chaîne de blocs pour y détecter la présence de la deuxième donnée. Dans ce mode, le dispositif conforme à l'invention et comportant l'entité de confiance surveille le contenu de la chaîne de données jusqu'à la détection de la deuxième donnée. [0045] Dans un mode de réalisation, le procédé permettant de prouver la connaissance de la première donnée comporte en outre une étape d'attente d'une date de publication précédemment communiquée par l'utilisateur. Cette date de publication peut correspondre soit à la date à laquelle l'utilisateur envisage de publier la deuxième donnée, soit à la date à laquelle il souhaite que l'entité de confiance publie la deuxième donnée. [0046] Dans un mode de réalisation, l'étape de publication est mise en oeuvre par le dispositif conforme à l'invention suite à la détection d'un ajout d'au moins un bloc à la chaîne de blocs. [0047] Dans un autre mode, la deuxième donnée est publiée en association avec une in- formation permettant d'identifier un type de la première donnée, par exemple une information de type « cette publication est relative à un numéro de téléphone d'Alice ». [0048] Dans un mode de réalisation, les étapes de publication, par le terminal et par l'entité de confiance déployée dans le dispositif, sont mises en oeuvre par des méthodes identifiées dans un contrat intelligent déployé par l'utilisateur du terminal, ce contrat intelligent pouvant en outre comporter des adresses des utilisateurs autorisés à invoquer ces méthodes. 7 [0049] A titre d'exemple, une méthode de type « Puhlish Attrihute » permettant de publier la première donnée n'est autorisée à être invoquée que par l'utilisateur. Une méthode de type « Publish Server Attrihute Proof » permettant de publier la deuxième donnée générée par l'entité de confiance n'est autorisée à être invoquée que par l'entité de confiance. Une méthode de type « « Publish User Attrihute Proof » permettant de publier la deuxième donnée après sa réception par l'utilisateur n'est quant à elle autorisée à être invoquée que par l'utilisateur. [0050] On rappelle qu'un contrat intelligent (en anglais « Smart Contract ») est un programme informatique autonome, qui une fois démarré, exécute automatiquement des conditions définies au préalable et inscrites dans la chaîne de blocs (http si/hl oc kc hai nfrance. net/2016/01/28/app I ications-smart-contracts/). A titre d'exemple, les applications décentralisées dApps du projet Ethercum (marque déposée) constituent des contrats intelligents au sens de l'invention. [0051] L'invention vise également un système permettant de prouver la connaissance d'une première donnée par un utilisateur inscrit à une chaîne de blocs. Ce système comporte au moins un terminal de l'utilisateur, ce terminal étant conforme à l'invention, et un dispositif conforme à l'invention comportant une entité de confiance. [0052] L'invention vise également un procédé de vérification de la connaissance d'une première donnée par un utilisateur inscrit à une chaîne de blocs, ce procédé étant mis en oeuvre par un équipement de vérification pouvant consulter la chaîne de blocs et comportant des étapes de : - détection d'une publication dans la chaîne de blocs par un terminal de l'utilisateur d'une deuxième donnée obtenue à partir de la première donnée; - détection d'une publication de la deuxième donnée dans la chaîne de blocs par une entité de confiance inscrite à la chaîne de blocs; et - vérification en fonction desdites publications si la deuxième donnée est publiée dans la chaîne de blocs par le terminal avant d'être publiée par l'entité de confiance, le résultat de ladite vérification permettant de déterminer si l'utilisateur connaissait ou non la première donnée à une date antérieure aux dates des publications. [0053] Corrélativement, l'invention vise un équipement de vérification de la connaissance d'une première donnée par un utilisateur inscrit à une chaîne de blocs, l'équipement de vérification pouvant consulter la chaîne de blocs et comportant: - un module de détection configuré pour détecter dans la chaîne de blocs: une publication par un terminal dudit utilisateur d'une deuxième donnée; et une publication de la deuxième donnée par une entité de confiance inscrite à la chaîne de blocs, la deuxième donnée ayant été générée par l'entité de confiance à partir de ladite première donnée; et - un module de décision configuré pour vérifier en fonction des publications 8 détectées, si la deuxième donnée a été publiée dans la chaîne de blocs par le terminal avant d'avoir été publiée par l'entité de confiance, le résultat de la vérification permettant de déterminer si l'utilisateur connaissait ou non la première donnée à une date antérieure aux dates des publications. [0054] Les caractéristiques et avantages du procédé de demande et du procédé permettant de prouver la connaissance de la première donnée, conformes à l'invention, présentés précédemment s'appliquent de la même façon au procédé et équipement de vérification selon l'invention et vice versa. [0055] Conformément à l'invention, lorsque le résultat de la vérification montre que la deuxième donnée est publiée dans la chaîne de blocs par le terminal de l'utilisateur avant d'avoir été publiée par l'entité de confiance, l'équipement de vérification détermine que l'utilisateur connaissait déjà la première donnée à une date antérieure aux dates des publications (par le terminal et par l'entité de confiance). [0056] Les blocs publiés dans la chaîne de blocs sont immuables. La durée de la vérification n'est donc pas limitée. [0057] L'invention vise également un premier programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou un terminal conforme à l'invention. Ce programme comporte des instructions adaptées à la mise en oeuvre d'un procédé de demande tel que décrit ci-dessus. [0058] L'invention vise également un deuxième programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou un dispositif comportant une entité de confiance conforme à l'invention. Ce programme comporte des instructions adaptées à la mise en oeuvre d'un procédé permettant de prouver la connaissance de la première donnée tel que décrit ci-dessus. [0059] L'invention vise également un troisième programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou un équipement de vérification conforme à l'invention. Ce programme comporte des instructions adaptées à la mise en oeuvre d'un procédé de vérification tel que décrit ci-dessus. [0060] Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0061] L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions du premier ou du deuxième ou du troisième programme d'ordinateur tel que mentionné ci-dessus. [0062] Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité 9 ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur, ou une mémoire flash. [0063] D'autre part, les supports d'information ou d'enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. [0064] Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. [0065] Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés conformes à l' invention. Brève description des dessins [0066] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : [fig.1] la figure I est un organigramme représentant des étapes d'un procédé de demande et d'un procédé permettant de prouver la connaissance d'une première donnée par un uti- lisateur à une date déterminée, les procédés étant mis en oeuvre selon un mode de réa- lisation particulier ; [fig.2,] la figure 2 est un organigramme représentant des étapes d'un procédé de vérification, mis en oeuvre selon un mode de réalisation particulier ; [fig.3] la figure 3 représente des architectures fonctionnelles, selon un mode de réalisation particulier, d'un système, d'un terminal et d'un dispositif ; [fig.4] la figure 4 présente une architecture fonctionnelle d'un équipement de vérification dans un mode de réalisation particulier ; [fig.5] la figure 5 présente une architecture matérielle d'un terminal selon un mode de réa- lisation particulier ; [fig.6] la figure 6 présente une architecture matérielle d'un dispositif selon un mode de réa- lisation particulier ; et. Ifig.71 la figure 7 présente une architecture matérielle d'un équipement de vérification selon un mode de réalisation particulier. Description des modes de réalisation [0067] La figure 1 est un organigramme représentant des étapes d'un procédé de demande d'attestation mis en oeuvre par un terminal TA d'un utilisateur A et des étapes d'un procédé permettant de prouver la connaissance d'une première donnée ID par l'utilisateur A, mis en oeuvre par un dispositif D comportant une entité de confiance O ; les deux procédés étant conformes à l'invention. Le terminal TA et le dispositif D sont conformes à l' invention. L'utilisateur A ainsi que l'entité de confiance O sont inscrits à une chaîne de blocs CB. [0068] Les étapes HO, E20, E60 et E70 décrites ci-après sont des étapes du procédé de demande d'attestation, mis en oeuvre par le terminal TA. [0069] Dans le mode décrit ici, l'entité de confiance O est un Oracle. [0070] Les étapes E30, E40, E50, E80 et E90 décrites ci-après sont des étapes du procédé permettant de prouver la connaissance d'une première donnée, mis en oeuvre par le dispositif D ou par l'entité de confiance O. [0071] Au cours d'une étape E10, le terminal TA déploie un contrat intelligent SC, dans lequel sont identifiées des méthodes de publication dans la chaîne de blocs devant être utilisées par l'utilisateur A et par l'entité de confiance O, ainsi que les adresses des utilisateurs autorisés à invoquer ces méthodes. Nous notons toutefois que le déploiement d'un contrat intelligent ne présente qu'un mode particulier de réalisation. Les procédés de l'invention peuvent s'appliquer dans d'autres contextes, avec d'autres méthodes régissant des publications sur la chaîne de blocs. [0072] Au cours de cette même étape HO, le terminal TA sélectionne l'entité de confiance O. Alternativement, le terminal TA peut sélectionner plusieurs entités de confiance. [0073] Au cours d'une étape E12, le contrat intelligent SC déployé dans la chaîne de blocs envoie un acquittement positif au terminal TA pour lui confirmer la publication de ce contrat SC et lui renvoie l'adresse de ce contrat, @SC. [0074] Le terminal TA reçoit cet acquittement et l'adresse @SC au cours d'une étape E14. [0075] Au cours d'une étape E20, le terminal TA envoie en dehors de la chaîne de blocs CB, la première donnée ID à l'entité de confiance. [0076] Dans le mode décrit ici, la première donnée ID est un attribut identifiant l'utilisateur A, tel que son numéro de téléphone. [0077] L'envoi E20 en dehors de la chaîne de blocs se fait via un réseau de communication entre le terminal TA et le dispositif D déployant l'entité de confiance. A titre 11 d'exemples, cet envoi E20 peut se faire via une communication radio, ou une communication filaire. Aucune limitation n'est apportée au type de communication utilisée pour transmettre la première donnée à l'entité de confiance. [0078] Dans un mode de réalisation particulier, au cours de l'étape E20, le terminal TA envoie également à l'entité de confiance O. l'adresse @SC du contrat intelligent SC, l'entité de confiance O pouvant alors s'en servir pour publier des données sur la chaîne de blocs conformément à des méthodes du contrat SC. [0079] Au cours d'une étape E30, l'entité de confiance O reçoit cette première donnée ID, ainsi que le cas échéant l'adresse @SC du contrat intelligent SC. [0080] Au cours d'une étape E40, l'entité de confiance O génère une deuxième donnée P à partir de la première donnée ID. [0081] La deuxième donnée P peut être associée à la date de sa génération. Elle peut être un code OTP, ou une donnée obtenue par compression de la première donnée ID, ou par chiffrement de la première donnée ID, ou un fichier signé par une clé privée de l'entité de confiance de type Oracle. [0082] Au cours d'une étape E50, l'entité de confiance O envoie en dehors de la chaîne de blocs CB, la deuxième donnée P à l'utilisateur A. [0083] Lorsque la deuxième donnée P est un code OTP, l'envoi E50 peut se faire via un réseau de communication et être destiné à un numéro de téléphone, une adresse c-mail ou une adresse postale de l'utilisateur A. [0084] Dans le mode décrit ici, cet envoi E50 est effectué via un réseau de communication connectant le terminal TA au dispositif D. [0085] Au cours d'une étape E60, le terminal TA reçoit via le réseau de communication (en dehors de la chaîne de blocs CB), la deuxième donnée en provenance de l'entité de confiance O. [0086] Au cours d'une étape E70, le terminal TA publie à une date tl la deuxième donnée P dans la chaîne de blocs CB, en utilisant dans le mode de réalisation décrit la méthode mentionnée dans le contrat intelligent SC. Plus précisément, le terminal TA transmet à destination de la chaîne de blocs une demande de publication de la deuxième donnée P. La demande est signée avec la clé privée de l'utilisateur A. [0087] Alternativement, le terminal TA peut utiliser une méthode classique de publication dans la chaine de blocs CB, sans recours au contrat intelligent SC. [0088] Au cours d'une étape E80, l'entité de confiance O détecte la publication de la deuxième donnée P par le terminal TA, par lecture des blocs émis dans la chaine de blocs CB. [0089] Suite à cette détection, l'entité de confiance O publie à son tour, à une date t2, au cours d'une étape E90, la deuxième donnée P dans la chaîne de blocs CB, selon la méthode mentionnée dans le contrat intelligent SC. 12 [0090] Dans un autre mode de réalisation, suite à la publication E70 de la deuxième donnée P par le terminal TA, ce terminal TA envoie au cours d'une étape E71 une notification au dispositif D pour notifier l'entité de confiance O de la publication E70. Sur réception de cette notification, l'entité de confiance O publie (E90) alors la deuxième donnée P. Plus précisément, lors de l'étape E90, l'entité de confiance O transmet à destination de la chaîne de blocs une demande de publication de la deuxième donnée P. La demande est signée avec la clé privée de l'entité de confiance O. [0091] Dans un autre mode de réalisation, par exemple au cours de l'étape d'envoi E20, le terminal TA envoie au dispositif D une donnée relative à une date de publication (tl) à laquelle le terminal TA compte publier la deuxième donnée P. A la réception de cette donnée, le dispositif D surveille l'occurrence de cette date tl dans le temps (en utilisant un compteur à rebours par exemple) et publie (E90) à son tour la deuxième donnée P après l'occurrence de cette date tl (à l'expiration du compteur à rebours). [0092] Dans un autre mode de réalisation, par exemple au cours de l'étape d'envoi E20, le terminal TA envoie au dispositif D une donnée relative à une date de publication (t2) à laquelle le dispositif D doit publier la deuxième donnée P. A la réception de cette donnée, le dispositif D surveille l'occurrence de cette date t2 dans le temps (en utilisant un compteur à rebours par exemple) et publie (E90) la deuxième donnée P à l'occurrence de cette date t2 (à l'expiration du compteur à rebours). Préférentiellement, le dispositif D vérifie avant cette publication E90 que la deuxième donnée P a bien été publiée (E70) dans la chaîne de blocs CB par le terminal TA. [0093] Dans un autre mode de réalisation, le dispositif D vérifie la publication de la donnée D dans la chaine de blocs par le terminal A, puis attend la publication d'un nombre n prédéterminé de nouveaux blocs ajoutés à la chaine de blocs avant de publier (E90) la deuxième donnée D. Le nombre n peut par exemple être égal ou supérieur à 3. [0094] En cas de bifurcation de la chaîne de blocs CB, le dispositif D peut ne considérer que le nombre de blocs ajoutés à la branche principale de la chaîne CB. [0095] Dans le mode décrit en référence à la figure 1, le même terminal TA de l'utilisateur A met en oeuvre les étapes d'envoi E20 de la première donnée ID, de réception E60 de la deuxième donnée P et de publication E70 de celle-ci. Alternativement, ces étapes E20, E60 et E70 peuvent être mises en oeuvre chacune par un terminal de l'utilisateur A, différent des terminaux mettant en oeuvre les autres étapes. [0096] La figure 2 est un organigramme représentant des étapes d'un procédé de véri- fication de la connaissance de la première donnée ID par l'utilisateur A. Ce procédé est mis en oeuvre par un équipement de vérification TB, le procédé et l'équipement TB étant conformes à l'invention. [0097] Dans ce mode, l'équipement de vérification TB est inscrit à la chaîne de blocs CB. Cet équipement TB peut être un terminal d'un utilisateur B. Cependant, pour mettre en 13 oeuvre le procédé de vérification conforme à l'invention, il est suffisant que l'équipement de vérification soit capable de consulter le contenu de la chaîne CB, sans pour autant être inscrit. [0098] L'équipement TB consulte les publications dans la chaîne de blocs CB. [0099] Au cours d'une étape E72, l'équipement TB détecte la publication par le terminal TA de la deuxième donnée P obtenue (E30) à partir de la première donnée ID. [0100] Au cours d'une étape E92, l'équipement TB détecte la publication par l'entité de confiance O de la deuxième donnée P. [0101] Dans le mode décrit ici, au moins l'une des étapes de publication E70 et E90 comporte, en plus de la publication de la deuxième donnée P, celle d'une information sur le type de la première donnée ID, de sorte à ce que l'équipement TB puisse déterminer que la deuxième donnée P a été obtenue à partir de la première donnée ID. Par exemple, considérant que la première donnée ID comporte un numéro de téléphone de l'utilisateur A, l'une des publications E70 ou E90 comporte aussi une information de type « cette publication est relative au numéro de téléphone de l'utilisateur A ». [0102] En retrouvant la même deuxième donnée P dans les deux publications E70 et E90, l'équipement de vérification TB peut déduire qu'elles sont toutes les deux (E70 et E90) relatives à la même première donnée ID. Préférentiellement, chacune des étapes de publication E70 et E90 comporte la publication de l'information sur le type de la première donnée ID. [0103] Les étapes de détection E72 et E92 peuvent être mises en oeuvre simultanément, ou l'une après l'autre peu importe l'ordre de leurs mises en oeuvre. [0104] Au cours d'une étape E100, l'équipement de vérification TB compare les dates des publications, tl et t2. Dans l'exemple décrit en référence à la figure 1, la date tl est antérieure à la date t2 ; l'équipement TB détermine alors que l'utilisateur A avait connaissance de la deuxième donnée et, en conséquence d'une première donnée utilisée pour générer la première donnée de la première donnée ID à une date nécessairement antérieure à la date tl de la publication E70. [0105] Dans un autre mode de réalisation, au cours de l'étape E100, l'équipement de véri- fication TB détermine que la deuxième donnée P est enregistrée dans deux blocs différents de la chaîne de blocs CB, et que la deuxième donnée P publiée à l'initiative du terminal A a été publiée dans un bloc antérieur (selon l'ordonnancement des blocs dans la chaîne) à celui dans lequel la deuxième donnée P a été publiée à l'initiative de l'entité de confiance. Par exemple la deuxième donnée P publiée à l'initiative de l'entité de confiance est publiée dans un bloc concaténé à la chaîne CB se trouvant après un nombre n de blocs compté à partir du bloc dans lequel figure la deuxième donnée P publiée à l'initiative du terminal A, n étant supérieur ou égal à 3 par exemple. Ainsi, l'équipement de vérification TB détermine que la publication E70 est antérieure 14 à la publication E90 et détermine que l'utilisateur A connaissait la première donnée ID au moment où il a publié la deuxième donnée P. [0106] La figure 3 représente des architectures fonctionnelles, selon un mode de réalisation de l'invention, d'un système SYS, du terminal TA et du dispositif D conformes à l' invention. [0107] Le système SYS comporte le terminal TA et le dispositif D. [0108] L'utilisateur A est inscrit à la chaîne de blocs CB. Le terminal TA comporte des moyens de communication COM configurés pour envoyer (E20), en dehors de la chaîne de blocs CB, la première donnée ID à l'entité de confiance O, déployée par le dispositif D et inscrite à la chaîne de blocs CB ; ces moyens de communication sont configurés en outre pour recevoir (E60), en provenance de l'entité de confiance O et en dehors de la chaîne de blocs CB, la deuxième donnée P. [0109] Le terminal TA comporte également un module de publication PUB-A configuré pour publier, ou plus exactement demander la publication, la deuxième donnée P dans la chaîne de blocs CB. Tel que décrit précédemment, l'entité de confiance O est configure° pour publier (E90) la deuxième donnée P dans la chaîne de blocs à une date ultérieure (t2) à celle (t1) de la publication (E70) par le terminal TA. [0110] Le dispositif D comporte : - des moyens de communication COM configurés pour recevoir (E30) la première donnée ID en provenance du terminal TA en dehors de la chaîne de blocs CB ; - un module de génération P_GEN configuré pour générer (E40) la deuxième donnée P à partir de la première donnée ID ; - lesdits moyens de communication COM étant configurés en outre pour envoyer (E50), en dehors de la chaîne de blocs CB, la deuxième donnée P au terminal TA ; et - un module de publication PUB-0 configuré pour publier (E90) la deuxième donnée P dans la chaîne de blocs CB après une publication (E70) de la deuxième donnée P par un terminal TA de l'utilisateur A. [0111] Dans un mode de réalisation, le dispositif D comporte en outre un module de détection DTC configuré pour détecter (E80) la publication (E70) de la deuxième donnée P dans la chaîne de blocs CB par un terminal TA de l'utilisateur A. Le module de publication PUB-0 est configuré pour publier la deuxième donnée P après la détection (E80). [0112] La figure 4 représente une architecture fonctionnelle, selon un mode de réalisation de l'invention, de l'équipement de vérification TB conforme à l'invention. [0113] Cet équipement TB comporte : - un module de détection DTC-B configuré pour détecter (E72, E92) dans la chaîne de blocs CB: la publication E70 par le terminal TA de la deuxième donnée P; et * la publication de la deuxième donnée P par l'entité de confiance O; et - un module de décision CMPR configure pour vérifier si la deuxième donnée P est publiée par le terminal TA avant l'entité de confiance O, ce module détermine que l'utilisateur A avait la connaissance de la première donnée ID à une date antérieure aux dates des publications. [0114] Dans le mode de réalisation décrit ici, le terminal TA, le dispositif D et l'équipement de vérification TB ont chacun l'architecture matérielle d'un ordinateur, telle qu'illustrée aux figures 5 à 7. [0115] L'architecture de chacun d'entre eux (le terminal TA, le dispositif D et l'équipement de vérification TB) comprend notamment un processeur 7, une mémoire vive 8, unc mémoire morte 9, une mémoire flash non volatile 10 dans un mode particulier de réalisation de l'invention, ainsi que des moyens de communication 11. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. [0116] La mémoire morte 9 du terminal TA constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur ProgA conforme à l'invention. [0117] La mémoire 10 du terminal TA permet d'enregistrer des variables utilisées pour l'exécution des étapes du procédé de demande d'attestation tel que décrit précédemment, telles que la première donnée ID, la deuxième donnée P, éventuellement l'adresse @SC du contrat intelligent SC, éventuellement la date de publication tl et/ou la date de publication t2 . [0118] Le programme d'ordinateur ProgTA définit des modules fonctionnels et logiciels ici, configurés pour demander une attestation de la première donnée ID. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 du terminal TA cités précédemment. [0119] La mémoire morte 9 du dispositif D constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur ProgO conforme à l'invention. [0120] La mémoire 10 du dispositif D permet d'enregistrer des variables utilisées pour l'exécution des étapes du procédé tel que décrit précédemment permettant de prouver la connaissance de la première donnée ID par l'utilisateur A du terminal TA, telles que la première donnée ID, la deuxième donnée P, éventuellement l'adresse eSC du contrat intelligent SC, éventuellement la date de publication tl et/ou la date de publication t2 . [0121] Le programme d'ordinateur ProgO définit des modules fonctionnels et logiciels ici, configurés pour permettre de prouver la connaissance de la première donnée ID par l'utilisateur A. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 du dispositif D cités précédemment. 16 [0122] La mémoire morte 9 de l'équipement TB constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 7 et sur lequel est enregistré ici un programme d'ordinateur ProgTB conforme à l'invention. [0123] La mémoire 10 de l'équipement TB permet d'enregistrer des variables utilisées pour l'exécution des étapes du procédé de vérification tel que décrit précédemment, telles que la deuxième donnée P, la date de publication tl, la date de publication t2. [0124] Le programme d'ordinateur ProgTB définit des modules fonctionnels et logiciels ici, configurés pour vérifier la connaissance de la première donnée ID par l'utilisateur À. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 7-11 de l'équipement TB cités précédemment. 17 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] REVENDICATIONSProcédé permettant de prouver la connaissance d'une première donnée (ID) par un utilisateur (A) inscrit à une chaîne de blocs (CB), ledit procédé étant mis en oeuvre par une entité de confiance (0) inscrite sur ladite chaîne de blocs et comportant des étapes de : - obtention (E30) de ladite première donnée (ID) en dehors de ladite chaîne de blocs (CB) ; - génération (E40) d'unc deuxième donnée (P) à partir de ladite première donnée (ID) ; - envoi (E50), en dehors de ladite chaîne de blocs (CB), de ladite deuxième donnée (P) audit utilisateur (A) ; et - publication (E90) de la dite deuxième donnée (P) sur ladite chaîne de blocs (CB) après une publication (E70) de la deuxième donnée dans la chaîne de blocs par un terminal de l'utilisateur. Procédé selon la revendication 1 comportant en outre une étape de détection de la publication de la deuxième donnée dans la chaîne de blocs par un terminal de l'utilisateur. Procédé selon la revendication 1 comportant en outre une étape d'attente d'une date de publication communiquée par ledit utilisateur ou une étape d'attente de la détection d'un ajout d'au moins un bloc à la chaîne de blocs. Procédé de demande d'attestation auprès d'une entité de confiance inscrite à une chaîne de blocs (CB) de la connaissance d'une première donnée (ID) par un utilisateur (A) inscrit à ladite chaîne de blocs (CB), ledit procédé comportant des étapes de: - réception (E60) en dehors de ladite chaîne de blocs (CB), en provenance de ladite entité de confiance (0), d'une deuxième donnée (P) obtenue à partir de ladite première donnée (ID), ladite entité de confiance (0) ayant eu connaissance de ladite première donnée (ID) en dehors de ladite chaîne de blocs (CB) ; et - publication (E70) par un terminal (TA) dudit utilisateur (A) de la dite deuxième donnée (P) sur ladite chaîne de blocs (CB) ; ladite entité de confiance étant configurée pour publier (E90) ladite deuxième donnée (P) sur la dite chaîne de blocs à une date (t2) ultérieure à la date (ti) de la publication (E70) de la deuxième donnée dans la chaîne de blocs par le terminal de l'utilisateur. Procédé selon la revendication 4 comportant en outre une étape (E22) 18 [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] d'envoi, en dehors de ladite chaîne de blocs (CB) à ladite entité de confiance (0) : - d'une date de publication à laquelle l'étape de publication par ledit terminal est mise en oeuvre ; et/ou - d'une plage de dates durant laquelle ladite entité de confiance doit publier ladite deuxième donnée (P) sur ladite chaîne de blocs (CB). Procédé selon l'une des revendications 4 à 5 comportant en outre une étape de sélection (El 0) d'au moins une dite entité de confiance (0) inscrite sur ladite chaîne de blocs. Procédé selon l'une des revendications 1 à 6 dans lequel les dites étapes de publication (E70, E90) sont mises en oeuvre par des méthodes identifiées dans un contrat intelligent (SC) déployé par ledit utilisateur (A), le contrat pouvant en outre comporter des adresses des utilisateurs autorisés à invoquer ces méthodes. Procédé de vérification de la connaissance d'une première donnée (ID) par un utilisateur (A) inscrit à une chaîne de blocs (CB), ledit procédé étant mis en oeuvre par un équipement de vérification (TB) pouvant consulter ladite chaîne de blocs (CB) et comportant des étapes de : - détection (E72) d'une publication sur ladite chaîne de blocs (CB) par un terminal dudit utilisateur (A) d'une deuxième donnée (P) obtenue à partir de ladite première donnée (ID) ; - détection (E92) d'une publication de ladite deuxième donnée (P) sur ladite chaîne de blocs (CB) par une entité de confiance (0) inscrite sur ladite chaîne de blocs (CB) ; et - vérification (E100), en fonction desdites publications détectées, si la deuxième donnée (P) a été publiée dans la chaîne de blocs par le terminal avant d'avoir été publiée par l'entité de confiance, le résultat de ladite vérification (E100) permettant de déterminer si l'utilisateur connaissait ou non la première donnée (ID) à une date antérieure aux dates des publications (E70, E90). Programme d'ordinateur (ProgTA, ProgO, ProgTB) comportant des instructions pour l'exécution : - des étapes d'un procédé permettant de prouver la connaissance d'une première donnée (ID) par un utilisateur (A) selon l'une quelconque des revendications 1 à 3 ou 7 ; ou - des étapes d'un procédé de demande d'attestation selon l'une des revendications 4 à 7 ; ou - des étapes d'un procédé de vérification selon la revendication 8 19 [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] lorsque ledit programme est exécuté par un ordinateur (TA, D, TB). Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon la revendication 9. Dispositif de communication, comportant une entité de confiance (0) inscrite à une chaîne de blocs (CB), ledit dispositif étant configuré pour permettre de prouver la connaissance d'une première donnée (ID) par un utilisateur (A) inscrit sur ladite chaîne de blocs, ledit dispositif comportant : - des moyens de communication (COM) configurés pour obtenir ladite première donnée (ID) en dehors de ladite chaîne de blocs (CB) ; - un module de génération (P GEN) configure pour générer une deuxième donnée (P) à partir de ladite première donnée (ID) ; - lesdits moyens de communication étant configurés en outre pour envoyer, en dehors de ladite chaîne de blocs (CB), ladite deuxième donnée (P) audit utilisateur (A) ; et - un module de publication (PUB-0) configuré pour publier la dite deuxième donnée (P) sur ladite chaîne de blocs (CB) après une publication de la deuxième donnée dans la chaîne de blocs par un terminal (TA) dudit utilisateur (A). Terminal (TA) d'un utilisateur (A) inscrit à une chaîne de blocs (CB), ledit terminal étant configuré pour demander une attestation auprès d'une entité de confiance inscrite à la chaîne de blocs, de la connaissance d'une première donnée (ID) par l'utilisateur, ledit terminal (TA) comportant : - des moyens de communication (COM) configurés pour recevoir, en provenance de ladite entité de confiance (D), en dehors de ladite chaîne de blocs (CB), d'une deuxième donnée (P) obtenue à partir de ladite première donnée (ID), ladite entité de confiance (0) ayant eu connaissance de ladite première donnée (ID) en dehors de ladite chaîne de blocs (CB) ; et - un module de publication (PUB-A) configuré pour publier la dite deuxième donnée (P) sur ladite chaîne de blocs (CB) ; ladite entité de confiance étant configurée pour publier ladite deuxième donnée (P) sur la dite chaîne de blocs à une date ultérieure (t2) ultérieure à la date (tI) de la publication de la deuxième donnée dans la chaîne de blocs par ledit terminal (TA). Equipement de vérification de la connaissance d'une première donnée (ID) par un utilisateur (A) inscrit à une chaîne de blocs (CB), ledit 20 équipement de vérification pouvant consulter ladite chaîne de blocs (CB) et comportant: - un module de détection (DTC-B) configure pour détecter : - une publication sur ladite chaîne de blocs (CB) par un terminal dudit utilisateur (A) d'une deuxième donnée (P); et - une publication de ladite deuxième donnée (P) sur ladite chaîne de blocs (CB) par une entité de confiance (0) inscrite sur ladite chaîne de blocs (CB), la deuxième donnée ayant été générée par l'entité de confiance à partir de ladite première donnée; et - un module de décision (CMPR) configure pour vérifier en fonction desdites publications, si la deuxième donnée (P) est publiée dans la chaîne de blocs par le terminal avant d'être publiée par l'entité de confiance, le résultat de ladite vérification permettant de déterminer si l'utilisateur connaissait ou non la première donnée (ID) à une date antérieure aux dates des publications (E70, E90).