FR 3157593 A1 20250627 FR 2314767 A 20231221 L’invention concerne un procédé d’attestation à distance décentralisé, attestant l’authenticité d’un pair Attester (20) au sein d’un réseau de pairs partageant un registre (50), impliquant un pair Verifier (30) et un dispositif Oracle (40) comportant une enclave sécurisée et un générateur de nombres aléatoires. L’Attester (30) publie une clé publique dans le registre (50). L’Oracle (40) génère un nombre aléatoire unique et une clé de chiffrement, puis chiffre le nombre aléatoire et l’envoi via un canal sécurisé au Verifier. L’oracle (40) publie le nombre aléatoire chiffré dans le registre (50). Le Verifier (30), génère un challenge en utilisant le nombre aléatoire et la clé publique et publie le challenge dans le registre. L’Attester (20), résout le challenge grâce à la clé privée et publie une preuve dans le registre (50). Après la publication de la preuve dans le registre (50), l’Oracle (40) publie la clé de chiffrement. Figure pour l’abrégé : [Fig. 1] Procédé d’attestation à distance décentralisé Domaine technique de l’invention L’invention a pour objet un procédé d’attestation à distance décentralisé. L’invention concerne en particulier l’attestation à distance de dispositifs, appelé pairs dans le présent texte, connectés dans un réseau décentralisé. L’invention concerne également un procédé de vérification de l’authenticité d’un pair. L'attestation à distance « Remote Attestation » est un service de sécurité dans lequel un dispositif, appelé « verifier », vérifie l'intégrité et l'authenticité d'un autre dispositif, appelé « attester » à distance. L'objectif est de s'assurer que le système distant n'a pas été compromis par des logiciels malveillants ou des modifications non autorisées. Ce service de sécurité implique généralement de la part du dispositif verifier, la création d’un challenge cryptographique contenant un secret (généralement un nombre aléatoire). Le dispositif attester résout ensuite ce challenge pour démontrer son authenticité et son intégrité. Une attestation à distance implique donc nécessairement l’utilisation de ressource de calcul et de mémoire de la part des dispositifs attester et verifier. Un réseau de pairs, aussi appelé réseau pair-à-pair (P2P) décentralisé est un modèle de réseau informatique où chaque dispositif participant, appelé pair agit à la fois comme client et serveur, partageant ses ressources (comme la bande passante, l'espace de stockage ou la puissance de calcul) directement avec les autres pairs sans nécessiter un serveur central ou une autorité administrative. Dans un réseau de pair, les pairs sont autonomes et prennent des décisions individuelles concernant la façon dont ils partagent les données et avec qui ils communiquent. Également, Les fichiers ou les données sont distribués à travers le réseau, parfois de manière redondante, ce qui augmente la résilience et la disponibilité. L'absence de point central de contrôle ou de défaillance rend le réseau robuste contre les pannes et les attaques ciblées car il n'y a pas de cible unique qui pourrait désactiver le réseau en entier. Un réseau P2P décentralisé a la capacité de s'organiser et de s'optimiser sans intervention externe. Les algorithmes internes gèrent des aspects tels que le routage, la découverte de ressources et la réplication de données. Les réseaux P2P décentralisés sont particulièrement populaires pour des applications comme le partage de fichiers, les systèmes de communication, les systèmes de stockage distribué et les cryptomonnaies. Ils peuvent cependant poser des défis en matière de sécurité, de fiabilité et de performance pour certaines utilisations. L’implémentation d’attestations à distance entre les pairs d’un réseau décentralisé permet donc de répondre à la problématique de sécurité inhérente aux réseaux de pair décentralisé. Cependant, l’attestation à distance telle que pratiquée généralement, nécessite pour qu’un pair i puisse établir que le pair j soit de confiance que les pairs i et j réalisent une attestation à distance avec le pair i dans le rôle de verifier et le pair j dans le rôle d’attester. Un réseau comportant de nombreux pairs nécessitera donc d’importantes ressources informatiques dédiées à la sécurité pour que les pairs puissent s’attester deux à deux. L’art antérieur propose plusieurs protocoles pour adresser cette problématique : L’attestation en « essaim » [Ref. 1] consiste à attester un réseau de dispositifs de telle façon que la vérification soit plus efficace lors de la vérification d’un ensemble de dispositifs « attester », que la vérification de chaque dispositif individuellement. Généralement, les attestations en « essaim » sont utilisées dans de larges réseaux de pairs pour gagner en efficacité. De nombreux travaux basés sur l’usage d’un dispositif « verifier » centralisé, comme SEDA [Ref. 2], LISA [Ref. 3], SHela [Ref. 4], EAPA [Ref. 5], SAP [Ref. 6], WISE [Ref. 7], CoRA [Ref. 8]ou encore FADIA [Ref. 9] collectent les attestations de plusieurs « attester » et les agrègent selon une structure d’arbre pour les acheminer plus efficacement jusqu’au dispositif « verifier ». Les techniques telles que DARPA [Ref. 10], SCAPI [Ref. 11], slimIoT [Ref. 12] ou PROVE [Ref. 13] introduisent en plus un mécanisme visant à garantir la légitimité des dispositifs « attester » et à surveiller leur présence dans l’essaim. D’autres travaux, notamment DIAT [Ref. 14], US-AID [Ref. 15], ESDRA [Ref. 16] ou PASTA [Ref. 17], considèrent que les dispositifs « verifier » sont des pairs du réseau, capables d’attester de façon autonome leurs voisins. Cependant, le résultat de l’attestation n’est pas publiquement vérifiable, conduisant chaque pair agissant comme « verifier » à effectuer intégralement le protocole. Le protocole d'attestation en essaim SANA [Ref. 18] s’appuie sur un schéma multi-signature pour agréger les résultats de l'attestation au sein d'un grand groupe de dispositifs. Dans SANA, chaque appareil est doté d'une paire de clés asymétriques. Chaque « attester » utilise sa clé secrète pour signer son attestation. Les attestations sont ensuite agrégées et peuvent être vérifiées par n’importe quel pair « verifier » connaissant la clé publique des dispositifs « attester ». Cependant, SANA ne donne pas de détail sur la génération du challenge (credential) que le dispositif « attester » (appelé « prover » dans SANA) signe pour attester de sa légitimité. La génération de ce challenge, qui inclut un Nonce secret, est cruciale pour éviter les attaques par rejeu. Par ailleurs, l’agrégation des attestations au sein du réseau rend le réseau peu dynamique et peu évolutif. En outre, il n’est pas indiqué comment les dispositifs sont authentifiés. PERMANENT [Ref. 19] est un protocole qui s'appuie sur la technologie de chaine de blocs « blockchain » pour rendre l’attestation à distance publiquement vérifiable. Le protocole PERMANENT considère un réseau pair-à-pair de dispositifs non fiables où les participants peuvent jouer les rôles d’ « attester » et de « verifier » de manière interchangeable. Mais ce protocole est implémenté au niveau du consensus entre pairs, qui est l’élément qui assure la disponibilité de la chaine de blocs. Dans le cas de PERMANENT, ce consensus est fermé, c’est-à-dire qu’il n’est plus possible d’ajouter un dispositif au consensus une fois que la blockchain est démarrée. Cela rend cette solution difficile à maintenir et ne permet pas de passer à l’échelle (impossible d’ajouter de nouveaux pairs ou d’en retirer). Le protocole PROVE vise l’objectif de fournir une solution permettant la vérifiabilité publique des attestations au sein d’un réseau de dispositifs distribués, grâce à un mécanisme de publication/souscription, sans reposer sur l’usage d’une infrastructure de clé publique « PKI », et sans envoyer de requête d’attestation au pair « attester ». PROVE repose sur l’usage d’un agent « broker » qui transmet aux dispositifs « verifier » abonnés les attestations publiées par les dispositifs « attester ». Déployés dans des réseaux distribués à large échelle, ces protocoles sont délicats à utiliser car ils requièrent la synchronicité des dispositifs. Le protocole SCRAPS [Ref. 20] fonctionne en revanche au sein d’un réseau de dispositifs de façon asynchrone grâce à l’usage d’une chaine de blocs. La vérification de l'attestation est déléguée à un contrat intelligent « smart contract » qui agit comme un pair « verifier » mandataire. Le secret est une valeur horodatée, générée par la chaine de blocs et connue de tous les pairs du réseau. Le dispositif « attester » génère une attestation au sein d’un composant matériel de sécurité et envoie l’attestation à un contrat intelligent sous la forme d’une transaction signée par sa clé privée. Le contrat intelligent exécute le processus de vérification sur la chaine de blocs. Pour que la transaction entrante soit valide, le fabricant du composant de sécurité doit déployer son contrat intelligent dans la chaine de blocs du réseau. Il doit enregistrer la clé publique de chaque composant de sécurité utilisé par les pairs dans la chaine de blocs. Enfin, il doit déployer le schéma d’attestation supporté par les composants au niveau de l’agent. La mise en œuvre de cette solution en devient extrêmement lourde, le fabricant des composants de sécurité devant s’impliquer dans les chaines de blocs de tous les réseaux de pairs utilisant cette solution. Présentation de l’invention La présente invention remédie aux inconvénients précités en proposant, selon un premier aspect, un procédé d’attestation à distance décentralisé, attestant l’authenticité d’un pair « attester » au sein d’un réseau de pairs partageant un registre. Le procédé d’attestation implique un pair « verifier » au sein du réseau de pairs et un dispositif « oracle ». Le dispositif « oracle » comporte une enclave sécurisée et un générateur de nombres aléatoires. Le procédé d’attestation comporte les étapes suivantes : génération, par le pair « attester », d’une paire de clés asymétriques comportant une clé privée et une clé publique, publication, par le pair « attester », de la clé publique dans le registre , génération, par le dispositif « oracle », d’un nombre aléatoire unique et d’une clé de chiffrement, génération, par le dispositif « oracle », d’un nombre aléatoire chiffré à partir du nombre aléatoire unique en utilisant la clé de chiffrement, transmission, par le dispositif « oracle », du nombre aléatoire unique, via un canal de communication sécurisé, au pair « verifier », publication, par le dispositif « oracle », du nombre aléatoire chiffré dans le registre, génération, par le pair « verifier », d’un challenge à partir du nombre aléatoire unique en utilisant la clé publique, publication, par le pair « verifier », du challenge dans le registre, génération, par le pair « attester », d’une preuve contenant le nombre aléatoire en résolvant le challenge grâce à la clé privée, publication, par le pair « attester », de la preuve dans le registre, après la publication de la preuve dans le registre, publication, par le dispositif « oracle », de la clé de chiffrement dans le registre. On entend par un réseau de pairs, plusieurs dispositifs connectés à distance par, par exemple, un réseau internet ou GSM ou une combinaison de plusieurs technologies de connexion à distance. Chaque dispositif, appelé pair, du réseau de pair comporte au moins une unité de traitement, une mémoire et un module de communication. On entend par registre, un registre ou log ou ledger, décentralisé, partagé entre les pairs du réseau de pairs, éventuellement répliqué par chaque pair du réseau de pairs et dans lequel des opérations ou des publications sont enregistrées dans un certain ordre et ne peuvent plus être modifiées une fois enregistrées. Un registre décentralisé peut être réalisé à l’aide d’une technologie comme par exemple une chaine de blocs ou une base de données décentralisée ou un « Directed Acyclic Graph ». Le nombre aléatoire pourra être conservé secret par l’ « oracle » et le pair « verifier » jusqu’à l’étape 11. De telles dispositions permettent une attestation de chaque pair du réseau de pairs qui pourra être facilement vérifiée par chacun des autres pairs du réseau de pairs. Cette attestation ne nécessite ni une implication d’un fabricant de dispositif ni l’utilisation d’un bloc de chaine de blocs en tant que nombre aléatoire, aussi appelé secret ou Nonce, ni l’utilisation d’un contrat intelligent en tant que mandataire « verifier ». Dans des modes particuliers de mise en œuvre l’invention peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Selon un mode de réalisation, le registre est un registre de chaine de blocs. L’utilisation d’un registre de chaine de blocs, aussi appelé ledger, permet de facilement rendre le registre décentralisé, c’est-à-dire partagé et répliqué, ce qui le rend très difficilement falsifiable. Selon un mode de réalisation, les étapes 2 à 6 et 9 à 11 sont déclenchées par des pairs du réseau de pairs via l’envoi d’une transaction vers un contrat intelligent déployé dans la chaine de blocs. L’utilisation d’un contrat intelligent pour déclencher ces étapes permet de décentraliser l’orchestration du procédé d’attestation et évite ainsi des communications supplémentaires entre le pair « attester », le pair « verifier » et le dispositif « oracle » lors de la réalisation du procédé d’attestation. Selon un mode de réalisation, le pair « attester » comporte un composant matériel de sécurité et l’étape 1 utilise le composant matériel de sécurité. L’utilisation d’un composant matériel de sécurité pour la génération d’une paire de clés asymétriques par le pair « attester » permet d’augmenter la sécurité du réseau de pairs en réduisant considérablement le risque d’usurpation de l’identité d’un pair ou la corruption d’un pair. Selon un mode de réalisation, le composant matériel de sécurité est un composant TPM ,en anglais, Trusted Platform Module, et l’étape 1 comporte la génération d’une clé d’endossement et d’une clé d’attestation. L’utilisation d’un composant de sécurité TPM, utilisant, par exemple, le protocole TPM 1.2 ou TPM 2.0, permet de disposer d’un composant de sécurité fiable et facilement disponible. Les composants de sécurité TPM permettent également de produire des clés d’endossement dont la certification pourra être vérifiée auprès d’une infrastructure de clé publique ,en anglais, PKI, soit Public Key Infrastructure. Selon un mode de réalisation, le dispositif « oracle » est un pair du réseau de pairs. Un dispositif « oracle » membre du réseau de pairs en tant que dispositif indépendant permet de facilement sécuriser le dispositif « oracle ». Selon un mode de réalisation, le pair « verifier » comporte le dispositif « oracle » dans une application embarquée dans une zone de confiance. Un dispositif « oracle » embarqué dans chaque pair du réseau de pairs permet de décentraliser la fonction du dispositif « oracle » et d’éviter ainsi un point de panne unique. Selon un deuxième aspect, la présente invention propose un procédé de vérification à distance décentralisé, vérifiant l’authenticité d’un pair « attester » au sein d’un réseau de pairs partageant un registre. Le procédé de vérification implique un pair « verifier » et comporte les étapes suivantes : attestation du pair « attester » selon le procédé d’attestation du premier aspect de l’invention, vérification, par le pair « verifier », de la postérité de la publication de la clé de chiffrement dans le registre par rapport à la publication de la preuve dans le registre, calcul du nombre aléatoire, par le pair « verifier », à partir du nombre aléatoire chiffré en utilisant la clé de chiffrement, vérification, par le pair « verifier », de la présence du nombre aléatoire dans la preuve, génération, par le pair « verifier », d’un challenge de contrôle à partir du nombre aléatoire en utilisant la clé publique, vérification, par le pair « verifier », de la correspondance entre le challenge de contrôle et le challenge. Le pair « verifier » impliqué dans le procédé de vérification peut-être le même pair « verifier » que le pair « verifier » du procédé d’attestation ou un autre pair du réseau de pairs. De telles dispositions, permettent de ne réaliser qu’une fois les étapes du procédé d’attestation pour un pair « attester ». Les autres pairs pourront ne réaliser que les étapes du procédé de vérification en tant que pair « verifier » afin de s’assurer de l’authenticité et de l’intégrité du pair « attester ». Selon un troisième aspect, la présente invention propose un procédé de vérification à distance décentralisé, vérifiant l’authenticité d’un pair « attester » au sein d’un réseau de pairs partageant un registre. Le pair « attester » comporte un composant matériel de sécurité TPM. Le procédé de vérification implique un pair « verifier » et comporte les étapes suivantes : attestation du pair « attester » selon le procédé d’attestation du premier aspect de l’invention, vérification, par le pair « verifier », d’une certification de la clé d’endossement auprès d’une infrastructure publique de clé, vérification, par le pair « verifier », de la postérité de la publication de la clé de chiffrement dans le registre par rapport à la publication de la preuve dans le registre, calcul du nombre aléatoire, par le pair « verifier », à partir du nombre aléatoire chiffré en utilisant la clé de chiffrement, vérification, par le pair « verifier », de la présence du nombre aléatoire dans la preuve, génération, par le pair « verifier », d’un challenge de contrôle à partir du nombre aléatoire en utilisant la clé publique, vérification, par le pair « verifier », de la correspondance entre le challenge de contrôle et le challenge. L’étape de vérification de la certification de la clé d’endossement fournie par le dispositif TPM du pair « attester » permet de s’assurer que le composant TPM est certifié par un fabricant du composant TPM. Cela permet d’augmenter de manière supplémentaire la sécurité du réseau de pairs. Présentation des figures L’invention sera mieux comprise à la lecture de la description suivante, donnée à titre d’exemple nullement limitatif, et faite en se référant aux figures : FIG. 1 une représentation schématique d’un exemple du procédé d’attestation selon le premier aspect de l’invention, FIG. 2 une représentation schématique d’un exemple du procédé de vérification selon le troisième aspect de l’invention, FIG. 3 une représentation schématique d’un exemple de réalisation de procédé de vérification selon le troisième aspect de l’invention, FIG. 4 une représentation schématique d’un réseau de pairs dans lequel le dispositif « oracle » est un pair, FIG. 5 une représentation schématique d’un réseau de pairs dans lequel chaque pair comporte un dispositif « oracle ». Dans ces figures, des références identiques d’une figure à une autre désignent des éléments identiques ou analogues. Pour des raisons de clarté, les éléments représentés ne sont pas nécessairement à une même échelle, sauf mention contraire. Description détaillée de modes de réalisation particuliers de l’invention La FIG. 1 est une représentation schématique d’un exemple de procédé d’attestation selon le premier aspect de l’invention. Un pair « attester » 20, un pair « verifier » 30, un dispositif « oracle » 40 et un registre 50 sont représentés. Le pair « attester » 20 et le pair « verifier » 30 sont membres d’un réseau de pairs décentralisés. On entend par pair, par exemple, un dispositif comportant une unité de traitement, une mémoire électronique et un module de communication. Les pairs sont connectés au sein du réseau de pairs par un ou plusieurs moyens de télécommunication. Le réseau de pairs décentralisé pourra par exemple être un réseau IoT « Internet of Things ». On entend par registre 50, un registre distribué entre les pairs membres du réseau de pairs. Le registre 50 conserve des publications des pairs dans l’ordre de publication, le pair émetteur de la publication étant également enregistré. Tout ou partie du registre pourront être éventuellement répliqué par les pairs du réseau de pairs. Le dispositif « oracle » 40 est un dispositif indépendant des autres pairs du réseau de pairs et sécurisé. Le dispositif « oracle » 40 comporte une enclave sécurisée et un générateur de nombres aléatoires unique. Le dispositif « oracle » est connecté aux pairs du réseau de pairs et au registre. Le dispositif « oracle » 40 pourra être par exemple un dispositif comportant une unité de traitement, une mémoire électronique et un module de communication. Le pair « attester » 20 génère 1 une paire de clés comportant une clé A privée et une clé A publique. On entend par paire de clés, une paire de clés cryptographiques asymétriques comportant une clé privée et une clé publique, la clé privée permet de signer un message que seule la clé publique correspondante permet de vérifier. Le pair « verifier » 30 pourra, par exemple, demander au pair « attester » 20 de procéder à une attestation. Le pair « attester » publie 2 dans un registre 50 la clé A publique. Le dispositif « oracle » 40 génère 3 une clé de chiffrement, clé B, et un nombre aléatoire. Le nombre aléatoire aussi appelé Nonce ou secret, est un nombre unique qui ne peut pas être prévu par un tier. Le dispositif « oracle » 40 génère 4 un nombre aléatoire chiffré en chiffrant le nombre aléatoire à l’aide de la clé B. Le dispositif « oracle » 40 transmet 5 le nombre aléatoire au pair « verifier » 30 de manière sécurisée. L’établissement d’un canal de communication sécurisé entre le dispositif « oracle » 40 et le pair « verifier » 30 pourra être réalisé, par exemple, à l’aide du protocole TLS « Transport Layer Security ». Le dispositif « oracle » 40 publie 6 le nombre aléatoire chiffré dans le registre 50. En utilisant la clé A publique, publiée dans le registre par le pair « attester » 20, et le nombre aléatoire, transmis par le dispositif « oracle » 40, le pair « verifier » 30 génère 7 un challenge. On entend par challenge, un challenge cryptographique aussi appelé « credential » contenant de manière chiffrée le nombre aléatoire. Le pair « verifier » publie 8 le challenge dans le registre 50. Ensuite, le pair « attester » pourra générer 9 une preuve à partir du challenge en utilisant la clé A privée. On entend par preuve, un message démontrant que le pair « attester » a résolu le challenge. La preuve comporte le nombre aléatoire en clair. Le pair « attester » publie 10 la preuve dans le registre 50. Une fois la preuve publiée dans le registre 50, le dispositif « oracle » 40 publie la clé de chiffrement, clé B, dans le registre 50. Le dispositif « oracle » ne doit publier la clé de chiffrement qu’après la publication de la preuve par le dispositif « attester ». Sinon, un tier pourrait usurper l’identité du pair « attester » en produisant une preuve contenant le nombre aléatoire sans avoir résolu le challenge, simplement en déchiffrant le nombre aléatoire chiffré déjà publié. Le dispositif « oracle » 40 pourra par exemple être notifié par le registre 50 de la publication de la preuve par le pair « attester », ou être notifié directement par le pair « attester ». Dans un autre exemple, le dispositif « oracle » 40 pourra surveiller le registre et publier la clé lorsqu’il aura observé la publication de la preuve. Une fois le procédé d’attestation réalisé, le registre 50 contient l’ensemble des publications dans l’ordre suivant : publication par le pair « attester » 20 de la clé publique, publication par le dispositif « oracle » 40 du nombre aléatoire, publication par le pair « verifier » 30 du challenge, publication par le pair « attester » 20 de la preuve, publication par le dispositif « oracle » 20 de la clé de chiffrement. Chaque pair du réseau de pairs pourra ensuite consulter le registre 50 et vérifier la validité de l’attestation pour s’assurer de l’authenticité du pair « attester » 20 sans que le pair « attester » 20 ne doive résoudre de nouveaux challenges cryptographiques. De cette manière, la sécurité du réseau de pairs pourra être assurée en nécessitant moins de ressources de calcul qu’en utilisant un procédé d’attestation de l’art antérieur. La FIG. 2 est une représentation schématique d’un exemple de procédé de vérification selon le troisième aspect de l’invention. La FIG. 2 représente également les étapes d’un exemple de procédé de vérification selon le deuxième aspect de l’invention. Le procédé de vérification selon le deuxième aspect de l’invention débute par l’attestation 12 d’un pair « attester » du réseau de pairs. L’attestation 12 se déroule selon le premier aspect de l’invention. Ensuite, un pair « verifier » vérifie 14 que la publication de la clé de chiffrement dans le registre est postérieure à la publication de la preuve. De cette manière, le pair « verifier » s’assure que le pair « attester », lors de son attestation, n’avait pas connaissance du nombre aléatoire lors de la résolution du challenge. Le pair « verifier » du procédé de vérification selon le deuxième ou le troisième aspect de l’invention peut-être le même pair que le pair « verifier » ayant réalisé le procédé d’attestation selon le premier aspect de l’invention. Le pair « verifier » du procédé de vérification selon le deuxième ou troisième aspect de l’invention peut aussi être un autre pair du réseau de pairs que le pair « verifier » du procédé d’attestation. De cette manière, un pair cherchant à s’assurer de l’authenticité et/ou de l’intégrité d’un autre pair du réseau de pairs pourra ne réaliser que le procédé de vérification si le pair dont on cherche à s’assurer de l’authenticité et/ou de l’intégrité a déjà réalisé le procédé d’attestation avec un autre pair « verifier ». Le pair « verifier » calcule 15 le nombre aléatoire en déchiffrant le nombre aléatoire chiffré présent dans le registre 50 à l’aide de la clé de chiffrement également présente dans le registre. Après avoir calculé le nombre aléatoire, le pair « verifier » 30 vérifie 16 que le nombre aléatoire est présent dans la preuve publiée dans le registre par le pair « attester » 20. En utilisant la clé publique et le nombre aléatoire présents dans le registre le pair « verifier » 30 génère 17 un challenge de contrôle. Le pair « verifier » 30 vérifie 18 ensuite que le challenge de contrôle correspond bien au challenge publié par le pair « attester » 20 dans le registre lors de la réalisation du procédé d’attestation. De cette manière, le pair « verifier » 30 s’assure que le pair attester a bien résolu le challenge que seule la possession de la clé privée permettait de résoudre. Selon un mode de réalisation, chaque pair du réseau de pairs comporte un composant matériel de sécurité. Lorsqu’un pair du réseau de pairs doit attester de son authenticité et/ou de son intégrité, le pair prend le rôle de pair « attester ». Il pourra réaliser l’étape 1 de génération d’une paire de clés asymétriques en utilisant son composant matériel de sécurité ce qui permet de protéger la génération de la paire de clés asymétriques de l’intrusion ou de l’observation par un tier. La clé privée pourra également être conservée au sein du composant matériel de sécurité avec un risque de violation de sécurité réduit. Selon un mode de réalisation, le composant matériel de sécurité est un composant TPM « Trusted Platform Module », par exemple, un composant TPM 2.0. Le composant de sécurité TPM pourra générer lors de l’étape 1 deux paires de clés asymétriques une paire de clé d’endossement communément noté EK et EK pub ainsi qu’une paire de clé d’attestation AK et AK pub . Dans ce cas, le procédé de vérification pourra comporter une étape de vérification 13 du certificat de la clé publique d’endossement EK pub auprès d’une infrastructure publique de clé. Une telle infrastructure publique de clé est en général rendue accessible par un fabricant de composant de sécurité. Cette étape permettra de s’assurer que le pair attester 20 comporte un composant de sécurité qui a bien été fournie par un fabricant de confiance. La FIG. 3 est une représentation schématique d’un exemple de réalisation de procédé de vérification selon le troisième aspect de l’invention. Le pair « attester » 20, le pair « verifier » 30, le dispositif « oracle » 40 et le registre 50 sont représentés. Le composant de sécurité TPM du pair « attester » 20 est également représenté. Dans cette représentation schématique le nombre aléatoire est nommé Nonce, la clé de chiffrement, cipherKey, le challenge, Credential et la preuve, decipheredCredential. Les étapes de publications sont indiquées par le terme Register. Dans cet exemple de réalisation, le procédé de vérification comporte une étape supplémentaire de publication par le pair « verifier » 30 du nombre aléatoire dans le registre 50. Cette étape est indiquée par « Register Nonce of Peer j ». Grâce à cette étape supplémentaire, un autre pair cherchant ultérieurement à s’assurer de l’authenticité/intégrité du pair attester pourra réaliser le procédé de vérification selon l’invention sans calculer 15 le nombre aléatoire, le nombre aléatoire déchiffré étant déjà disponible dans le registre. Selon un mode de réalisation le registre 50 est un registre de chaine de blocs, aussi appelé « ledger ». La chaine de blocs permet de décentraliser le registre tout en maintenant un bon niveau de sécurité et de fiabilité. Selon un mode de réalisation, le déclenchement des étapes suivantes du procédé d’attestation pourra être réalisé par un des pairs du réseau de pairs via l’envoi d’une transaction vers un contrat intelligent de la chaine de blocs: publication, par le pair « attester » (30), de la clé publique dans le registre (50), génération, par le dispositif « oracle » (40), d’un nombre aléatoire unique et d’une clé de chiffrement, génération, par le dispositif « oracle » (40), d’un nombre aléatoire chiffré à partir du nombre aléatoire unique en utilisant la clé de chiffrement, transmission, par le dispositif « oracle » (40), du nombre aléatoire unique, via un canal de communication sécurisé, au pair « verifier » (30), publication, par le dispositif « oracle » (40), du nombre aléatoire chiffré dans le registre(50), publication, par le pair « verifier » (30), du challenge dans le registre (50), génération, par le pair « attester » (20), d’une preuve contenant le nombre aléatoire en résolvant le challenge grâce à la clé privée, publication, par le pair « attester » (20), de la preuve dans le registre (50), après la publication de la preuve dans le registre (50), publication, par le dispositif « oracle » (40), de la clé de chiffrement dans le registre(50). L’utilisation d’un contrat intelligent pour déclencher ces étapes, pour éventuellement fournir les instructions de réalisation et pour éventuellement déclencher d’autres étapes du procédé d’attestation ainsi que des étapes du procédé de vérification, permet d’éviter des échanges supplémentaires entre les pairs participants à l’attestation et entre les pairs participants et le dispositif « oracle ». Le contrat intelligent pourra prendre, par exemple, la forme suivante : // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.6.6; contract dd23890 { address creator; // certificat cle EK struct ekParam { uint256 qname; uint256 name; uint crypto; // ECC ou RSA bytes32[2] pub; // cle publique EK(X, Y) chaque coordonnée est de 32 octets bytes32[] pem; // certificat de la cle d endossement TPM signe par PKI (ECC ou RSA) } // parametre AK struct akParam { uint256 qname; uint256 name; // ak_qname = ek_qname | ak_name uint crypto; // ECC or RSA bytes32[2] pub; // cle publique AK(X, Y) chaque coordonnée est de 32 octets } // Structure de l attestation pour l index cipheredNonce struct cipheredNonce { address targetedAttester; // pair attester devant prouver address issuingOracle; // adresse du compte Oracle qui a produit ciphered Nonce bytes32[] credential; // publication par le verifier bytes32[] decipheredCredential; // publication par l ATTESTER uint256 cipherKey; // publication par ORACLE } // role des participants struct role { bool Oracle; bool Verifier; bool Attester; } // cartographie des variables mapping (address => role) public player ; // role qu une adresse de compte peut adopter mapping (address => ekParam) public ek; // EK du pair mapping (address => akParam) public ak; // AK du pair mapping (uint256 => cipheredNonce) public attestation; // elements de l attestation pour l index cipheredNonce publie par l ORACLE mapping (uint256 => address) public usedNonce; // nonce deja utilise // evenement qui permet de recuperer une attestation dans la chaine event hereIsCipheredNonce (uint256 _cipheredNonce); event hereIsCredential (uint256 _cipheredNonce, address _targetedAttester); event hereIsDecipheredCredential (uint256 _cipheredNonce, address _targetedOracle); /** * Constructor function **/ constructor () public { creator = msg.sender; } // CREATOR enregistre le role des participants function registerRole (address _player, bool _oracle, bool _verifier, bool _attester) public returns (bool){ require (msg.sender == creator, "only creator is allowed to register roles"); player [_player].Oracle = _oracle; player [[_player].Verifier = _verifier; player [[_player].Attester = _attester; return true; } // ATTESTER publie sa cle EK function registerEK (uint256 _qname, uint256 _name, uint _crypto, bytes32[2] memory _pub, bytes32[] memory _pem) public returns (bool){ require ( player [msg.sender].Attester == true, "msg.sender must be an Attester device"); ek [msg.sender].qname = _qname; ek [msg.sender].name = _name; ek [msg.sender].crypto = _crypto; ek [msg.sender].pub = _pub; ek [msg.sender].pem = _pem; return true; } // ATTESTER publie sa cle AK function registerAK (uint256 _qname, uint256 _name, uint _crypto, bytes32[2] memory _pub) public returns (bool){ require ( player [msg.sender].Attester == true, "msg.sender must be an Attester device"); ak [msg.sender].qname = _qname; ak [msg.sender].name = _name; ak [msg.sender].crypto = _crypto; ak [msg.sender].pub = _pub; return true; } // ORACLE publie cipheredNonce pour l Attester function registerCipheredNonce (uint256 _cipheredNonce, address _targetedAttester) public returns (bool){ require ( player (msg.sender).Oracle == true, "msg.sender must be an ORACLE"); require ( player (_targetedAttester).Attester == true, "_targetedAttester must be an ATTESTER"); require (msg.sender != _targetedAttester, "msg.sender and _targetedAttester must be independant"); require ( attestation [_cipheredNonce].targetedAttester == address(0x0), "cipheredNonce is already used"); attestation [_cipheredNonce].targetedAttester == _targetedAttester; attestation [_cipheredNonce].issuingOracle == msg.sender emit hereIsCipheredNonce (_cipheredNonce); return true; } // VERIFIER publie Credential pour l Attester function registerCredential (uint256 _cipheredNonce, bytes32[] memory _credential) public returns (bool){ require ( player (msg.sender).Verifier == true, "msg.sender must be a VERIFIER"); require ( attestation [_cipheredNonce].targetedAttester != address(0x0), "a valid targetAttester must be already registered"); require (msg.sender != attestation [_cipheredNonce].targetedAttester, "msg.sender and targetedAttester must be independant"); require ( attestation [_cipheredNonce].credential[0] == bytes32(0), "no credential must already be registered"); attestation [_cipheredNonce].credential = _credential; emit hereIsCredential (_cipheredNonce, attestation[_cipheredNonce].targetedAttester); return true; } // ATTESTER publie decipheredCredential function registerDecipheredCredential (uint256 _cipheredNonce, bytes32[] memory _decipheredCredential, uint256 _nonce) public returns (bool){ require (msg.sender == attestation [_cipheredNonce].targetedAttester, "msg.sender must be targetedAttester"); require ( attestation [_cipheredNonce].credential[0] != bytes32(0), "a credential should be registered"); require ( attestation [_cipheredNonce]. decipheredCredential[0] == bytes32(0), "no decipheredCredential must be registered"); require ( usedNonce [_nonce] == address(0x0), "the nonce must not be already used"); attestation [_cipheredNonce].decipheredCredential = _decipheredCredential; usedNonce [_nonce] = msg.sender; emit hereIsDecipheredCredential (_cipheredNonce, attestation[_cipheredNonce].issuingOracle); return true; } // ORACLE publie cipherKey utilise pour cipheredNonce function registerCipherKey (uint256 _cipheredNonce, uint256 _cipherKey) public returns (bool){ require (msg.sender == attestation [_cipheredNonce].issuingOracle, "cipherKey must be disclosed by ORACLE which issues cipheredNonce"); require ( attestation [_cipheredNonce].decipheredCredential[0] != bytes32(0), "a decipheredCredential must be registered"); require ( attestation [_cipheredNonce].cipherKey == 0, "no cipherKey must be registred"); attestation [_cipheredNonce].cipherKey = _cipherKey; return true; } } Chaque pair et chaque dispositif « oracle » accède au contrat intelligent grâce à son adresse de compte dans la chaine de blocs. Une entité, nommée « CREATOR » dans le contrat intelligent configure l’adresse de compte de chaque pair/dispositif « oracle » et renseigne le rôle que peut adopter chaque adresse de compte. La FIG. 4 est une représentation schématique d’un réseau de pairs dans lequel le dispositif « oracle » 40 est un pair. Chaque pair du réseau de pairs, indiqué « peer » sur la figure pourra adopter le rôle de pair « verifier » 30 ou de pair « attester » 20 lors de la réalisation d’un procédé d’attestation ou de vérification selon l’invention. Afin de conserver une attestation avec deux parties, un pair « attester » 20 ne pourra être le pair « verifier » 30 lors de son attestation ou lors de sa vérification. Le dispositif « oracle » 40 doit pouvoir mettre en place un canal de communication sécurisé avec chaque pair du réseau de pairs afin de pouvoir transmettre le nombre aléatoire de manière confidentielle au pair « verifier » 30 lors de la réalisation du procédé d’attestation. Ce canal de communication sécurisé pourra, par exemple, s’effectuer grâce à une méthode d’échange de clés par contrat intelligent déployé sur une chaine de blocs [Ref. 21]. Plusieurs dispositifs « oracle » pourront intervenir au sein du réseau de pair avec un mécanisme de sélection du dispositif « oracle » responsable de chaque attestation. De cette manière la robustesse du réseau de pairs pourra être augmentée car la panne d’un dispositif « oracle » n’empêchera plus les pairs du réseau de procéder à des attestations. La FIG. 5 est une représentation schématique d’un réseau de pairs dans lequel chaque pair comporte un dispositif « oracle ». Dans ce mode de réalisation le dispositif « oracle » est embarqué dans une zone d’exécution de confiance dans chaque pair du réseau de pairs. Le dispositif « oracle » disposera tout de même d’une identité distincte auprès du registre de celle du pair l’embarquant. Un pair « verifier » sollicitera son dispositif « oracle » embarqué lors de la réalisation d’un procédé d’attestation selon l’invention. Un procédé de monitoring dynamique pourra être mis en place pour garantir l’authenticité du dispositif « oracle » embarqué lors de chaque publication. Procédé d’attestation à distance décentralisé, attestant l’authenticité d’un pair « attester » (20) au sein d’un réseau de pairs partageant un registre (50), impliquant un pair « verifier » (30) au sein du réseau de pairs et impliquant un dispositif « oracle » (40), le dispositif « oracle » (40) comporte une enclave sécurisée et un générateur de nombres aléatoires, le procédé d’attestation comporte les étapes suivantes : 1.génération, par le pair « attester » (20), d’une paire de clés asymétriques comportant une clé privée et une clé publique, 2.publication, par le pair « attester » (30), de la clé publique dans le registre (50), 3.génération, par le dispositif « oracle » (40), d’un nombre aléatoire unique et d’une clé de chiffrement, 4.génération, par le dispositif « oracle » (40), d’un nombre aléatoire chiffré à partir du nombre aléatoire unique en utilisant la clé de chiffrement, 5.transmission, par le dispositif « oracle » (40), du nombre aléatoire unique, via un canal de communication sécurisé, au pair « verifier » (30), 6.publication, par le dispositif « oracle » (40), du nombre aléatoire chiffré dans le registre(50), 7.génération, par le pair « verifier » (30), d’un challenge à partir du nombre aléatoire unique en utilisant la clé publique, 8.publication, par le pair « verifier » (30), du challenge dans le registre (50), 9.génération, par le pair « attester » (20), d’une preuve contenant le nombre aléatoire en résolvant le challenge grâce à la clé privée, 10.publication, par le pair « attester » (20), de la preuve dans le registre (50), 11.après la publication de la preuve dans le registre (50), publication, par le dispositif « oracle » (40), de la clé de chiffrement dans le registre (50). Procédé d’attestation selon la revendication 1 dans lequel le registre (50) est un registre de chaine de blocs. Procédé selon la revendication 2 dans lequel les étapes 2 à 6 et 9 à 11 sont déclenchées par un des pairs du réseau de pairs via l’envoi d’une transaction vers un contrat intelligent déployé dans la chaine de blocs. Procédé d’attestation selon l’une des revendications précédentes dans lequel le pair « attester » (20) comporte un composant matériel de sécurité et dans lequel la génération de la paire de clés asymétrique de l’étape 1 est réalisée en utilisant le composant matériel de sécurité. Procédé selon la revendication 4 dans lequel le composant matériel de sécurité est un composant TPM et dans lequel l’étape 1 comporte la génération d’une clé d’endossement et d’une clé d’attestation en utilisant le composant TPM. Procédé d’attestation selon l’une des revendications précédentes dans lequel le dispositif « oracle » (40) est un pair du réseau de pairs. Procédé d’attestation selon les revendications 1 à 5 dans lequel le pair « verifier » (30) comporte le dispositif « oracle » (40) dans une application embarquée dans une zone de confiance. Procédé de vérification à distance décentralisé, vérifiant l’authenticité d’un pair « attester » (20) au sein d’un réseau de pairs partageant un registre, impliquant un pair « verifier » et comportant les étapes suivantes : 12.attestation du pair « attester » (20) selon le procédé d’attestation de l’une des revendications précédentes, 14.vérification, par le pair « verifier » (30), de la postérité de la publication de la clé de chiffrement dans le registre (50) par rapport à la publication de la preuve dans le registre (50), 15.calcul du nombre aléatoire, par le pair « verifier » (30), à partir du nombre aléatoire chiffré en utilisant la clé de chiffrement, 16.vérification, par le pair « verifier » (30), de la présence du nombre aléatoire dans la preuve, 17.génération, par le pair « verifier » (30), d’un challenge de contrôle à partir du nombre aléatoire en utilisant la clé publique, 18.vérification, par le pair « verifier » (30), de la correspondance entre le challenge de contrôle et le challenge. Procédé de vérification à distance décentralisé, vérifiant l’authenticité d’un pair « attester » (20) au sein d’un réseau de pairs partageant un registre, le pair « attester » (20) comporte un composant matériel de sécurité TPM, le procédé de vérification implique un pair « verifier » (30) et comporte les étapes suivantes : 12.attestation du pair « attester » (20) selon le procédé d’attestation de la revendication 5, 13.vérification, par le pair « verifier » (30), d’une certification de la clé d’endossement auprès d’une infrastructure publique de clé, 14.vérification, par le pair « verifier » (40), de la postérité de la publication de la clé de chiffrement dans le registre par rapport à la publication de la preuve dans le registre, 15.calcul du nombre aléatoire, par le pair « verifier » (30), à partir du nombre aléatoire chiffré en utilisant la clé de chiffrement, 16.vérification, par le pair « verifier » (30), de la présence du nombre aléatoire dans la preuve, 17.génération, par le pair « verifier » (30), d’un challenge de contrôle à partir du nombre aléatoire en utilisant la clé publique, 18.vérification, par le pair « verifier » (30), de la correspondance entre le challenge de contrôle et le challenge.