Brevet FR3076420A1 — publié le 20190705

METHODE D'ECHANGE DE CLES PAR CONTRAT INTELLIGENT DEPLOYE SUR UNE CHAINE DE BLOCS DESCRIPTION DOMAINE TECHNIQUE La presente invention concerne de maniere generale la cryptographie et plus particulierement la generation d'un canal securise entre pairs au moyen d'une cle secrete. Elle concerne egalement la technique des chaines de blocs (blockchain). ETAT DE LA TECHNIQUE ANTERIEURE La generation d'un canal securise en dispositifs distants, egalement denommes dans la suite « pairs », suppose le partage d'une cle secrete entre ces dispositifs. Ce partage peut etre realise par une distribution manuelle des cies, prealablement a toute communication sur le canal, ou bien au moyen d'un protocole d'echange de cies de type Diffie-Hellmann utilisant un cryptosysterne asymetrique. On rappelle que dans un protocole d'echange de cies de type Diffie-Hellman, chaque dispositif distant dispose d'un couple de cies asymetrique (cle privee, cle publique). La cle privee d'un dispositif emetteur est conservee secrete par ce dernier et nest en particulier jamais divulguee au dispositif destinataire. Elle sert a chiffrer ou signer des messages et a identifier le dispositif emetteur. En revanche, la cle publique est connue du dispositif destinataire et sert a dechiffrer des messages ou a verifier la signature du dispositif emetteur. Le but du protocole d'echange de cies est de permettre, a partir d'elements publics d'un cryptosysterne echanges sur un canal non securise, a chaque dispositif distant de calculer independamment une merne cle secrete qui servira a etablir un canal securise entre eux. Lorsque le cryptosysterne est base sur une courbe elliptique E (Fq) definie sur un corps fini Fq et caracterise par les parametres de domaine (q,a,b,G,n,h) ou q est le nombre d'elements du corps, a,b sont les parametres de la courbe elliptique, G est un 2 11 point generateur, n est l'ordre de G dans le groupe additif E(F ), h= E(F) est le q n cofacteur de G dans ce groupe, 1E(Fq)1 est l'ordre du groupe E(Fq). Chaque dispositif distant peut choisir une cle privee sk parmi les entiers[1, n -1], la cle publique correspondante etant donnee par les coordonnees du point Pk = sk.G . On rappelle que 5 rechercher sk a partir de Pk revient a rechercher une solution au probleme ECLDP (Elliptic Curve Discrete Logarithm Problem), actuellement impossible a resoudre dans un temps polynomial. Si Alice et Bob sont les deux pairs correspondant aux deux dispositifs distants, un protocole d'echange de cies de Diffie-Hellmann utilisant un cryptosysterne elliptique 10 (protocole ECDH) peut etre decrit par les etapes suivantes : Alice choisit un nombre entier a qui restera secret, calcule la cle publique ephernere, Pa = a.G , et la transmet a Bob. De maniere similaire, Bob choisit un entier b qui restera secret, calcule la cle publique ephernere,Pb = b.G , et la transmet a Alice. 15 Ala reception de Pb, Alice calcule a.Pb= ab.G . A la reception de Pa, Bob calcule b.P =ba.G. Alice et Bob partagent desormais un element secret consistant en un point de la courbe elliptique, ab.G . Ils peuvent par exemple appliquer une fonction de hachage, prealablement convenue entre eux, a l'une des coordonnees du point en question pour 20 obtenir une cle de session symetrique avec laquelle ils chiffrent les donnees sur le canal. Une limitation importante du protocole d'echange de cies ci-dessus est qu'il nest pas immun contre une attaque de type Man-In-the-Middle. En effet, un attaquant, Eve, peut s'interposer entre Alice et Bob, faire croire a Alice qu'elle echange avec Bob et a Bob qu'il echange avec Alice. En mettant en ceuvre le protocole decrit ci-dessus, Eve choisit un premier entier x et partage un premier element secret axG avec Alice, puis choisit un second entier y et partage un second element secret byG avec Bob. Eve peut ainsi creer un premier canal securise avec Alice et un second canal securise avec Bob. Lorsqu'Alice croit transmettre des donnees de maniere securisee a Bob, elle les fournit en fait a Eve. 3 Reciproquement, lorsque Bob croit transmettre des donnees de maniere securisee a Alice, il les transmet en fait egalement a Eve. Une solution connue pour remedier a ce type d'attaque est d'identifier l'emetteur de chaque cle publique. Ainsi, Alice transmet a Bob non seulement sa cle publique 5 ephernere Pc, = a.G mais aussi une signature numerique de Pa, signee avec sa cle privee (par exemple au moyen d'un algorithme ECDSA). Bob doit alors disposer de la cle publique d'Alice pour verifier la signature en question. Si la verification est positive, cela signifie que la cle publique ephernere a bien ete ernise par Alice et non pas un tiers. Bien entendu, reciproquement, Bob transmet a Alice sa cle publique ephernere Pb = b .G accompagnee 10 de la signature de Pb au moyen de la cle privee de Bob, et Alice procede a la verification de cette signature au moyen de la cle publique de Bob pour authentifier la provenance de la cle publique ephernere. Cette solution nest toutefois que partiellement satisfaisante dans la mesure ou la transmission de la cle publique d'Alice a Bob (ou celle de Bob a Alice) sur un canal non 15 securise est elle-merne susceptible de faire l'objet d'une attaque de type « Man-in-the- Middle ». Afin de lier la cle publique d'un emetteur avec son identite, on utilise un certificat numerique (au format X.509 ou bien certificat implicite, par exemple) delivre par une autorite de certification. II en resulte que le protocole de Diffie-Hellman necessite la presence d'un tiers de confiance pour etre robuste aux attaques de type « Man-in-the- 20 Middle). Afin d'eviter de recourir a un tiers de confiance et en particulier a une autorite de certification centralisee, il a ete propose dans ('article de P. McCorry et al. intitule « Authenticated key exchange over Bitcoin », publie en 2015 dans Chen L., Matsuo S. (eds) Security Standardisation Research. Lecture Notes in Computer Science, vol 9497. Springer, 25 de faire appel a une technique d'identification de pairs fondee sur les proprietes de la chaine de blocs Bitcoin. On rappelle qu'une chaine de blocs est un registre distribue et securise de touter les transactions effectuees depuis le dernarrage de la chaine. Une introduction complete a la chaine de blocs Bitcoin pourra etre trouvee dans l'ouvrage de A.M. Antonopoulos intitule « Mastering Bitcoin » publie en 2015 aux editions O'Reilly. 4 La Fig. 1 represente une methode d'echange de cies authentifie par une chaine de blocs tel que decrit dans ('article precite. Prealablement a l'echange de cies, on suppose qu'Alice et Bob ont chacun genere de maniere independante une cle privee (notee a pour Alice et b pour Bob) et, a partir de 5 la cle publique correspondante (P = aG pour Alice et Pb =bG pour Bob), une adresse de portefeuille ephernere (notee @wallet_a Alice pour Alice et @wallet_b Bob pour Bob). Les adresses epherneres ne seront utilisees dans le cadre des transactions supportant cet echange. Les portefeuilles respectifs de Bob et Alice sont egalement supposes etre credites de cryptomonnaie en quantite suffisante. 10 Alice forme en 110 une transaction T a et celle-ci est diffusee aux nceuds du reseau Bitcoin. Apres avoir ete validee, incorporee dans un bloc et confirmee par minage, celle-ci fait partie du registre distribue (distributed ledger). De merne, Bob forme en 120 une transaction Tb et celle-ci est diffusee de proche en proche aux nceuds du reseau. De maniere generale, une transaction represente un transfert d'unites de 15 cryptomonnaie d'une entrée (ou de plusieurs entrées) vers une sortie (ou vers plusieurs sorties). Une transaction est libellee en termer de UTXO (Unspent Transaction Output), chaque UTXO representant un montant non depense par son proprietaire et etant verrouille par un script de verrouillage. Pour pouvoir depenser un UTXO, le proprietaire doit s'identifier en presentant a l'UTX0 des elements cryptographiques (generalement la 20 cle publique et une signature generee a partir de la cle privee correspondante) sous la forme d'un script de deverrouillage. Si les elements presentes dans le script de deverrouillage satisfont aux conditions specifiees dans le script de verrouillage, la transaction est validee. On notera que dans Bitcoin, le script de deverrouillage le plus communement utilise est Pay-to-Public-Key-Hash (P2PKH) et le script de verrouillage est 25 scriptSig. La transaction T a formee par Alice comprend en entrée une reference a un UTXO detenu a l'adresse de portefeuille @wallet_a Alice ainsi qu'un script de deverrouillage (represente par une cle). Ce script de deverrouillage contient la cle publique ephernere d'Alice, Pa et une signature de cette cle publique (plus precisement de la transaction dans 5 laquelle la cle publique Pc, est substituee au script de deverrouillage, la transaction etant ensuite doublement hachee) au moyen de la cle privee correspondante, a . La transaction T a comprend en sortie I'adresse de portefeuille du destinataire (Bob), soit @wallet_b Bob ainsi qu'un script de verrouillage (represents par un cadenas sur 5 Ia figure) que Bob pourra deverrouiller en fournissant, via un script de deverrouillage, les elements cryptographiques (cle publique et signature) satisfaisant aux conditions fixees dans le script de verrouillage. Cette sortie de transaction cree un UTXO (@wallet_b Bobmontant) a I'adresse de portefeuille ephernere de Bob. On a egalement indique en sortie I'adresse de portefeuille ephernere d'Alice pour que celle-ci puisse recuperer dans son 10 portefeuille le solde de Ia transaction (creation d'un UTXO dans le portefeuille ephernere d'Alice). De la merne facon, la transaction Tb comprend en entrée une reference a un UTXO detenu a I'adresse de portefeuille @wallet_b Bob, ainsi qu'un script de deverrouillage contenant la cle publique ephernere de Bob, Pb, et une signature de cette cle publique au 15 moyen de la cle privee correspondante b . En sortie, la transaction Tb comprend en sortie I'adresse de portefeuille ephernere d'Alice @wallet_a Alice ainsi qu'un script de verrouillage (represents par un cadenas sur la figure) qu'Alice pourra deverrouiller en fournissant les elements cryptographiques satisfaisant aux conditions fixees dans le script de verrouillage. Cette sortie cree un UTXO 20 (@wallet_a Alice-montant) a I'adresse de portefeuille ephernere d'Alice. Une deuxierne sortie est prevue pour recuperer le solde sous forme d'un UTXO a I'adresse de portefeuille ephernere de Bob. Les montants des UTXO @wallet_a Alice-montant et @wallet_b Bob-montant peuvent etre choisis egaux pour equilibrer l'echange. 25 Une foil que les transactions Ta et Tb ont ete validees, enregistrees dans la chaine de blocs et confirmees par minage, Alice (resp. Bob) scanne le registre distribue a la recherche de la transaction ernise par Bob (resp. Alice). Alice recupere dans la partie entrée de Tb la cle publique ephernere Pb de Bob et, reciproquement, Bob recupere dans la partie 6 entrée de Ta la cle publique ephernere Pa d'Alice. Alice calcule alors aPb = abG et Bob bPa =baG : Alice et Bob disposent par consequent de la cle secrete partagee abG . L'auditabilite du registre distribue permet a tour les utilisateurs (nceuds) de verifier que les cies publiques epherneres utilisees dans cet echange n'ont jamais ete 5 utilisees auparavant, que la cle publique Pa appartient bien a Alice (plus precisement est liee a l'adresse de portefeuille ephernere d'Alice) et que la cle publique Pb appartient bien a Bob (plus precisement est liee a l'adresse de portefeuille ephernere de Bob). Ainsi, l'echange de cies entre Alice et Bob peut etre authentifie par la chaine de blocs, sans intervention d'un tiers de confiance. 10 Toutefois, la generation systernatique d'adresses de portefeuille epherneres a chaque echange de cies peut s'averer compliquee a gerer et couteuse en termer de ressources de calcul pour les dispositifs distants hebergeant ces portefeuilles. Un objet de la presente invention est par consequent de proposer une methode d'echange de cies entre pairs, authentifie par chaine de blocs et donc sans recours a un 15 tiers de confiance, et qui ne necessite pas la generation de portefeuilles epherneres. EXPOSE DE L'INVENTION La presente invention est definie par une methode d'echange de cies entre un premier utilisateur et un second utilisateur d'une chaine de blocs de transactions, la chaine de blocs etant adaptee a stocker des contrats intelligents, chaque utilisateur disposant 20 d'une adresse de portefeuille lui permettant d'emettre et de recevoir des transactions, la chaine de blocs stockant un contrat intelligent comprenant : une premiere fonction (Fct A) ayant pour argument au moins une cle publique et qui, lorsqu'elle est appelee par un utilisateur, stocke l'adresse de portefeuille de l'utilisateur qui l'appelle ainsi que la cle publique en argument ; 25 une seconde fonction (Fct B) ayant pour argument au moins une cle publique et qui, lorsqu'elle est appelee par un utilisateur, verifie que l'adresse de portefeuille de l'utilisateur qui l'appelle est celle d'un utilisateur autorise pour l'echange et, dans ce cas, stocke la cle publique en argument ; 7 une troisierne fonction (Fct C) comprenant une premiere instruction verifiant que l'adresse de portefeuille de l'utilisateur qui l'appelle est bien celle stockee par la premiere fonction et retournant dans ce cas a l'utilisateur la cle publique stockee par la seconde fonction, et une seconde instruction verifiant que l'adresse de portefeuille de 5 l'utilisateur qui l'appelle est bien celle stockee par la seconde fonction et retournant dans ce cas a l'utilisateur la cle publique stockee par la premiere fonction ; et que (i) le premier utilisateur genere une premiere cle privee ephernere (a) et une premiere cle publique ephernere (Pa) correspondante au moyen d'un cryptosysterne asymetrique ; 10 (ii) le second utilisateur genere une seconde cle privee ephernere (b ) et une seconde cle publique ephemere ( PB ) correspondante au moyen dudit cryptosysterne asymetrique ; (iii) le premier utilisateur forme une premiere transaction (TA) contenant la premiere cle publique ephernere et la transmet a l'adresse du contrat intelligent, l'adresse 15 du portefeuille du premier utilisateur ainsi que la premiere cle publique ephernere etant alors stockees dans le contrat intelligent, le bloc contenant le contrat intelligent etant ensuite mine ; (iv) le second utilisateur forme une seconde transaction (TB) )contenant la seconde cle publique ephernere et Ia transmet a l'adresse du contrat intelligent, l'adresse du 20 portefeuille du second utilisateur ainsi que Ia seconde cle publique ephernere etant alors stockees dans le contrat intelligent, le bloc contenant le contrat intelligent etant ensuite mine ; (v) le premier utilisateur forme une requete sous la forme d'une troisierne transaction et l'envoie a l'adresse du contrat intelligent, la seconde instruction de la 25 troisierne fonction du contrat intelligent lui retournant alors la seconde cle publique ephernere ; (vi) le second utilisateur forme une requete sous la forme d'une troisierne transaction et l'envoie a l'adresse du contrat intelligent, la seconde instruction de la 8 troisierne fonction du contrat intelligent lui retournant alors la premiere cle publique ephernere ; (vii) le premier utilisateur calcule le produit de la premiere cle privee ephernere (a) avec la seconde cle publique ephernere (Pb) et le second utilisateur calcule (232) le 5 produit de la seconde cle privee ephernere (b ) avec la premiere cle publique ephernere (Pa) pour generer une cle secrete commune (kab ). La premiere fonction du contrat intelligent comprend de preference en second argument l'adresse de portefeuille de ('utilisateur autorise pour l'echange et la premiere transaction transmet l'adresse de portefeuille du second utilisateur comme second 10 argument a la premiere fonction. Avantageusement, pour equilibrer les couts, lorsque le contrat intelligent retourne la premiere cle publique ephernere au second utilisateur ou la seconde cle publique ephernere au premier utilisateur, le contrat intelligent retourne aux premier et second utilisateurs la moitie du montant indique respectivement dans les premiere et 15 seconde transactions. Le contrat intelligent comprend avantageusement une quatrierne fonction (Fct timeout) permettant au premier utilisateur de mettre fin au contrat intelligent si le second utilisateur n'a pas transmis la seconde transaction au contrat intelligent dans un Mai predetermine (timeout) apres que le premier utilisateur a transmis la premiere 20 transaction au contrat intelligent. La chaine de blocs peut etre par exemple Hyperledger ou Ethereum. Dans le cas d'Ethereum, l'une des premiere, deuxierne, troisierne et quatrierne transactions peut comprendre un parametre (STARTGAS) fixant la complexite maximale que ('execution de la transaction est autorisee a consommer ainsi qu'un cout a payer en 25 termer de complexite (GASPRICE). BREVE DESCRIPTION DES DESSINS D'autres caracteristiques et avantages de l'invention apparaitront a la lecture d'un mode de realisation preferentiel de l'invention, fait en reference aux figures jointer parmi lesquelles : 9 La Fig. 1, déjà decrite, represente de maniere schernatique un echange de cies entre pairs, authentifie par une chaine de blocs, selon une methode connue de l'etat de la technique ; La Fig. 2 represente de maniere schernatique un echange de cies entre pairs, 5 authentifie par un contrat intelligent deploye sur une chaine de blocs, selon un mode de realisation de l'invention. EXPOSE DETAILLE DE MODES DE REALISATION PARTICULIERS L'idee a la base de la presente invention est de faire appel a une chaine de blocs dans laquelle il est possible d'enregistrer des contrats intelligents, encore denommes 10 contrats autonomes ou smart contracts. Un exemple d'une telle chaine de blocs est Ethereum. Un autre exemple d'une telle chaine de blocs est Hyperledger. Un contrat intelligent est un programme qui est deploye (c'est-a-dire stocke) dans la chaine de blocs et peut etre execute par n'importe quel nceud du reseau. De maniere generale, un contrat intelligent peut stocker des donnees, envoyer et recevoir des 15 paiements, stocker un montant en cryptomonnaie (ether dans Ethereum), et executer des actions de maniere autonome et decentralisee comme un agent logiciel. De maniere generale, un contrat intelligent verifie si un certain nombre de conditions d'entree sont remplies et, dans ('affirmative, s'execute automatiquement pour fournir un resultat code dans le contrat. 20 Le contrat intelligent dont il est ici question est chargé d'authentifier les parties et de leur fournir les cies publiques en consequence. La Fig. 2 represente de maniere schernatique un echange de cies entre pairs, au moyen d'un contrat intelligent deploye sur une chaine de blocs, selon un mode de 25 realisation de l'invention. On suppose qu'un premier utilisateur (ou premier pair), Alice et un second utilisateur (ou second pair) Bob disposent chacun d'une adresse de portefeuille, soit @wallet_Alice pour Alice et @wallet_Bob pour Bob, et qu'ils se sont communiqués ces adresses par exemple sous la forme de QR code, prealablement a ('execution du contrat 10 intelligent. En outre, Alice aura genere (en 201) une cle privee a et une cle publique ephernere Pc, = aG au moyen d'un cryptosysterne sur courbe elliptique. De merne, Bob aura genere (en 202) une cle privee b et une cle publique ephernere Pb = bG au moyen du merne cryptosysterne. Alice et Bob pourront de maniere plus generale utiliser un 5 cryptosysterne asymetrique pour generer leurs couples de cies privees et publiques. La structure du contrat intelligent a ete representee en 250. II comprend une premiere fonction Fct A, ayant pour argument au moins la cle publique ephernere d'un premier pair (Alice). Elle peut aussi comprendre en argument l'adresse de portefeuille du second pair (Bob). Cette premiere fonction, lorsqu'elle est appelee, stocke l'adresse de 10 portefeuille du pair qui l'appelle ainsi que sa cle publique ephernere. Elle stocke egalement l'adresse de portefeuille du second pair si celle-ci lui est transmise en argument. Le contrat intelligent comprend une seconde fonction Fct B, ayant pour argument au moins la cle publique du second pair (Bob). Elle peut aussi comprendre en argument l'adresse de portefeuille du premier pair (Alice). Cette seconde fonction, 15 lorsqu'elle est appelee, stocke l'adresse du pair qui l'appelle ainsi que sa cle publique ephernere. Elle stocke egalement l'adresse du premier pair si celle-ci est transmise en argument. Afin de definir les parties contractantes, Fct A comprendra en argument l'adresse de portefeuille du second pair ou Fct B comprendra en argument l'adresse du premier 20 pair, ces deux situations n'etant bien entendu pas exclusives l'une de l'autre. Lorsque la premiere fonction Fct A comprend en argument l'adresse de portefeuille du second pair, la fonction Fct B verifie qu'elle est bien appelee par cette adresse de portefeuille avant de stocker la cle publique ephernere qui lui est fournie en argument. 25 Reciproquement, lorsque la seconde fonction Fct B comprend en argument l'adresse de portefeuille du premier pair, la premiere fonction Fct A verifie qu'elle est bien appelee par cette adresse de portefeuille avant de stocker la cle publique qui lui est fournie en argument. Le contrat intelligent comprend une troisierne fonction, Fct C, ayant pour objet 30 de verifier l'identite des parties qui l'appellent et de transmettre les cies publiques suivant 11 les conditions de distribution prevues dans le contrat. Dans le cas present, la fonction Fct C contient une premiere instruction indiquant que, si elle est appelee par l'adresse de portefeuille du premier pair, elle lui retourne la cle publique ephernere du second pair. De maniere similaire, elle contient une seconde instruction indiquant que, si elle est 5 appelee par l'adresse de portefeuille du second pair, elle lui retourne la cle publique ephernere du premier pair. Enfin, avantageusement, le contrat intelligent contient une quatrierne fonction Fct timeout . Si au bout d'un Mai predetermine, timeout, apres que le premier pair (Alice) a enregistre sa cle publique ephernere en appelant la premiere fonction, le second pair 10 (Bob) n'a pas encore appele Ia seconde fonction pour retirer cette cle publique ephernere, le premier pair peut appeler Ia fonction Fct timeout pour mettre fin a ('execution du contrat et, le cas echeant, recuperer sa mise. Reciproquement, si au bout d'un Mai timeout apres que le second pair (Bob) a enregistre sa cle publique ephernere en appelant Ia seconde fonction, le premier pair (Alice) n'a pas encore appele Ia premiere fonction pour 15 retirer cette cle publique ephernere, le second pair peut appeler Ia fonction Fct timeout pour mettre fin a ('execution du contrat et, le cas echeant, recuperer sa mise. Le processus d'echange de cies se deroule alors comme suit : A l'etape 211, Alice forme une premiere transaction, TA, et Ia transmet a l'adresse (de Ia premiere fonction) du contrat intelligent. Cette premiere transaction contient Ia cle 20 publique ephernere d'Alice, Pa, et, dans le cas illustre, l'adresse de portefeuille (encore appelee adresse de compte dans Ethereum) de Bob, @wallet_Bob. La premiere transaction est signee numeriquement par Alice a l'aide de sa cle privee. Lors de ('execution de Ia premiere fonction, Ia signature d'Alice est verifiee par le nceud qui ('execute. Alternativement, Ia signature d'Alice peut etre verifiee par le contrat lui-merne. L'adresse 25 de portefeuille du pair a l'origine de Ia transaction, @wallet_Alice, l'adresse de portefeuille @wallet_Bob, ainsi que Ia cle publique ephernere Pc, sont enregistres dans le contrat intelligent. Le contrat est ensuite « mine » pour valider son changement d'etat. A l'etape 212, Bob forme une seconde transaction, TB, et Ia transmet a l'adresse de Ia seconde fonction du contrat intelligent. Cette seconde transaction contient Ia cle 12 publique ephernere de Bob, Pb, et est signee par Bob au moyen de sa cle privee. Comme precedemment, la signature peut etre verifiee par le nceud qui execute le contrat ou bien par le contrat lui-merne. La seconde fonction compare l'adresse de portefeuille a partir de laquelle la seconde transaction a ete ernise, en ('occurrence @wallet_Bob, avec l'adresse 5 de portefeuille stockee dans le contrat. En cas d'identite, la cle publique ephernere, Pb, est enregistree dans le contrat intelligent. Le changement d'etat du contrat est ensuite valide par le minage du bloc qui le contient. Alice et Bob sont alors en mesure d'envoyer, independamment l'un de l'autre, respectivement en 221 et 222, une requete sous forme d'une transaction a l'adresse du 10 contrat intelligent afin d'executer la troisierne fonction, Fct C, du contrat intelligent. Plus precisement, Alice transmet une transaction T Ac a la fonction Fct C et Bob transmet independamment une transaction TBC a cette merne fonction. La fonction Fct C compare l'adresse de portefeuille a l'origine de la transaction 221 (resp. 222) avec l'adresse de portefeuille stockee dans le contrat, a savoir 15 @wallet_Alice (resp. @Wallet_Bob). En cas d'identite, le contrat intelligent retourne en argument la cle publique ephernere Pb a Alice (resp. la cle publique ephernere Pc, a Bob). Alice calcule alors en 231 la cle secrete aPb =abG a partir de la cle publique ephernere Pb qu'elle vient de recevoir du contrat intelligent. Bob en fait de merne en 232, bPa=baG , a partir de la cle publique ephernere d'Alice qu'il vient de recevoir. Alice et Bob 20 partagent ainsi la cle secrete kab =abG pour securiser un canal de communication hors chaine de blocs, securiser la confidentialite de donnees ou encore ('utiliser a des fins d'authentification. Dans le cas illustre, si Bob n'a pas fourni sa cle publique ephernere Pb dans un Mai predetermine, timeout, dont it a ete prealablement informe par un processus hors 25 chaine, Alice peut transmettre une transaction a la quatrierne fonction Fct timeout pour mettre fin au contrat. De preference, les fonctions Fct A et Fct B sont payantes, autrement dit les transactions 211 et 212 doivent transferer un montant convenu au contrat intelligent pour 13 pouvoir les executer. Cette precaution permet notamment d'ecarter les attaques par deni de service. En outre, cette somme peut etre restituee aux parties lors de ('execution de la fonction Fct C, avec la remise des cies publiques Pa et Pb. Plus precisement, on pourra 5 prevoir que lorsqu'une partie appelle la Fct C avec succes et se fait remettre la cle publique dont elle est le destinataire, le contrat restitue aux parties la moitie de leur mise. Ainsi, chacune des parties est avertie lorsque la cle publique qu'elle a enregistree dans le contrat a ete remise a l'autre partie. La restitution de la moitie de la mise joue le role d'un acquittement pour la partie concernee. 10 De maniere optionnelle, les transactions 211-212, 221-222 peuvent inclure un parametre fixant la complexite maximale (parametre STARTGAS dans Ethereum), en nombre d'etapes ou de cycles d'horloge, que ('execution de la transaction est autorisee a consommer ainsi qu'un cout a payer en termer de complexite (parametre GASPRICE dans Ethereum). L'ajout de ces parametres permet d'exiger de chaque utilisateur qu'il paie les 15 ressources qu'il consomme et donc de !utter contre les attaques de type « deni de service » obtenues en creant des boucles infinies. Le second mode de realisation se generalise sans difficulte a un echange de cies entre une pluralite quelconque de pairs de maniere a ce qu'ils puissent notamment creer entre eux, deux a deux, des canaux securises independants. 20 Pour ce faire, Alice initie le processus et fournit a la fonction Fct A, outre sa cle publique ephernere, Pa, les parties impliquees dans le contrat intelligent sous la forme d'une liste d'adresses de portefeuilles. Chacune des parties enregistrees peut ensuite s'identifier aupres du contrat intelligent et faire executer la fonction Fct B pour stocker dans le contrat sa cle publique 25 ephernere. Enfin, chaque partie enregistree dans le contrat peut executer la fonction Fct C et recuperer la cle publique des autres parties. A partir de sa propre cle privee et des cies publiques ainsi recuperees, chaque partie peut calculer une cle secrete partagee avec une autre partie. 14 Le tableau ci-dessous donne un exemple d'echange de cies, au moyen d'un contrat intelligent, entre quatre parties Alice, Bob, Charlie et Dave. On remarque que le contrat intelligent permet de generer six cies secretes, chaque cle secrete correspondant a un canal de communication entre deux parties au contrat. Alice Bob Charlie Dave cle partagee aPb bPa abG aP cPb acG aPd di'', REVENDICATIONS1. Methode d'echange de cies entre un premier utilisateur et un second utilisateur d'une chaine de blocs de transactions, Ia chaine de blocs etant adaptee a stocker des contrats intelligents, chaque utilisateur disposant d'une adresse de portefeuille lui permettant d'emettre et de recevoir des transactions, caracterisee en ce que Ia chaine de blocs contient un contrat intelligent comprenant : une premiere fonction ( Fct A) ayant pour argument au moins une cle publique et qui, lorsqu'elle est appelee par un utilisateur, stocke l'adresse de portefeuille de l'utilisateur qui l'appelle ainsi que Ia cle publique en argument ; une seconde fonction ( Fct B) ayant pour argument au moins une cle publique et qui, lorsqu'elle est appelee par un utilisateur, verifie que l'adresse de portefeuille de l'utilisateur qui l'appelle est celle d'un utilisateur autorise pour l'echange et, dans ce cas, stocke Ia cle publique en argument ; une troisierne fonction (Fct C) comprenant une premiere instruction verifiant que l'adresse de portefeuille de l'utilisateur qui l'appelle est bien celle stockee par Ia premiere fonction et retournant dans ce cas a l'utilisateur Ia cle publique stockee par Ia seconde fonction, et une seconde instruction verifiant que l'adresse de portefeuille de l'utilisateur qui l'appelle est bien celle stockee par Ia seconde fonction et retournant dans ce cas a l'utilisateur Ia cle publique stockee par Ia premiere fonction ; et que (i) le premier utilisateur genere (201) une premiere cle privee ephernere (a) et une premiere cle publique ephernere ( Pa ) correspondante au moyen d'un cryptosysterne asymetrique ; (ii) le second utilisateur genere (202) une seconde cle privee ephernere (b) et une seconde cle publique ephernere ( Pb ) correspondante au moyen dudit cryptosysterne asymetrique ; (iii) le premier utilisateur forme (211) une premiere transaction (TA) contenant Ia premiere cle publique ephernere et Ia transmet a l'adresse du contrat intelligent, l'adresse du portefeuille du premier utilisateur ainsi que Ia premiere cle publique ephernere etant 16 alors stockees dans le contrat intelligent, le bloc contenant le contrat intelligent etant ensuite mine ; (iv) le second utilisateur forme (212) une seconde transaction (TB) contenant la seconde cle publique ephernere et la transmet a l'adresse du contrat intelligent, l'adresse 5 du portefeuille du second utilisateur ainsi que la seconde cle publique ephernere etant alors stockees dans le contrat intelligent, le bloc contenant le contrat intelligent etant ensuite mine ; (v) le premier utilisateur forme (221) une requete sous la forme d'une troisierne transaction et l'envoie a l'adresse du contrat intelligent, la seconde instruction de la 10 troisierne fonction du contrat intelligent lui retournant alors la seconde cle publique ephernere ; (vi) le second utilisateur forme (222) une requete sous la forme d'une troisierne transaction et l'envoie a l'adresse du contrat intelligent, la seconde instruction de la troisierne fonction du contrat intelligent lui retournant alors la premiere cle publique 15 ephernere ; (vii) le premier utilisateur calcule (231) le produit de la premiere cle privee ephernere (a) avec la seconde cle publique ephernere ( Pb ) et le second utilisateur calcule (232) le produit de la seconde cle privee ephernere (b ) avec la premiere cle publique ephernere (Pa) pour generer une cle secrete commune(c ). 20 2. Methode d'echange de cies selon la revendication 1, caracterisee en ce que la premiere fonction du contrat intelligent comprend en second argument l'adresse de portefeuille de ('utilisateur autorise pour l'echange et que la premiere transaction transmet l'adresse de portefeuille du second utilisateur comme second argument a la premiere 25 fonction. 3. Methode d'echange de cies selon la revendication 1 ou 2, caracterisee en ce que, lorsque le contrat intelligent retourne la premiere cle publique ephernere au second utilisateur ou la seconde cle publique ephernere au premier utilisateur, le contrat 17 intelligent retourne aux premier et second utilisateurs la moitie du montant indique respectivement dans les premiere et seconde transactions. 4. Methode d'echange de cies selon l'une des revendications 1 a 3, caracterisee 5 en ce que le contrat intelligent comprend une quatrierne fonction (Fct timeout) permettant au premier utilisateur de mettre fin au contrat intelligent si le second utilisateur n'a pas transmis la seconde transaction au contrat intelligent dans un Mai predetermine (timeout) apres que le premier utilisateur a transmis la premiere transaction au contrat intelligent. 10 5. Methode d'echange de cies selon l'une des revendications 1 a 4, caracterisee en ce que la chaine de blocs est Hyperledger. 6. Methode d'echange de cies selon l'une des revendications 1 a 4, caracterisee 15 en ce que la chaine de blocs est Ethereum. 7. Methode d'echange de cies selon la revendication 6, caracterisee en ce qu'au moins l'une des premiere, deuxierne, troisierne et quatrierne transactions comprend un parametre (STARTGAS) fixant la complexite maximale que ('execution de la transaction est 20 autorisee a consommer ainsi qu'un cout a payer en termer de complexite (GASPRICE).