Brevet FR3048319A1 — publié le 20170901

Méthode de gestion de certificats implicites au moyen d'une infrastructure à clés publiques distribuée DESCRIPTION DOMAINE TECHNIQUE L'objet de la présente invention concerne le domaine de la cryptographie et plus particulièrement celui des infrastructures à clés publiques. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les systèmes de cryptographie asymétrique, dits aussi à clé publique font traditionnellement appel à des autorités de certification ayant pour fonction de délivrer, d'authentifier et, le cas échéant, de révoquer des certificats de clés publiques. Plus précisément, un noeud détenteur d'un couple de clé privée et clé publique selon un cryptosystème asymétrique (tel que le cryptosystème RSA par exemple), peut demander à une autorité de certification de lui établir un certificat permettant de lier sa clé publique à son identité. Un tel certificat est généralement obtenu en effectuant un hachage (par exemple un hachage SHA) d'une information contenant la clé publique et l'identifiant du détenteur, le résultat du hachage ou condensat étant signé par la clé privée de l'autorité de certification. Ainsi tout tiers souhaitant échanger de manière sécurisée avec le noeud en question et faisant confiance à l'autorité de certification ou CA (Certification Authority) peut préalablement s'assurer auprès de cette dernière de l'authenticité de la clé publique du noeud. En pratique, les autorités de certification sont organisées de manière hiérarchique selon leur degré de confiance, une clé publique d'une autorité de certification pouvant être elle-même authentifiée auprès d'une autorité de certification de rang supérieur et ce, jusqu'à une autorité de certification racine. On rappelle que les certificats de clés publiques obéissent à un format normalisé par l'ITU, dit format X.509. Toutefois, les cryptosystèmes asymétriques classiques, tels que RSA, utilisent des clés (privées et publiques) de grande taille (2 ou 4 Kbits) et les certificats X.509 associés sont également très volumineux (plusieurs kilo-octets). Ils sont par conséquent inadaptés au domaine de l'Internet des objets (loT) dans lequel les noeuds ne disposent généralement 3048319 2 que de faibles ressources en mémoire et en calcul. Pour cette raison, on préfère utiliser des cryptosystèmes sur courbes elliptiques avec certificats implicites ou ECQV (Elliptic Curve Qu-Vanstone Implicit Certificate). On rappelle tout d'abord qu'un cryptosystème sur courbe elliptique ou ECC 5 (Elliptic Curve Cryptography) est défini par un ensemble de paramètres, dit paramètres de domaine, à savoir notamment les constantes intervenant dans l'équation elliptique définie sur ZP (où p est premier), le point générateur G et l'ordre n du groupe cyclique engendré par le point générateur. Le chiffrement ECC est basé sur le problème du logarithme discret. Plus précisément, une clé privée c (nombre entier) est liée à la clé 10 publique Q (point de la courbe elliptique E) par cG = Q . Le principe du chiffrement sur courbe elliptique avec certificat implicite est rappelé ci-après. On suppose qu'Alice souhaite générer un couple (clé privée, clé publique) et obtenir un certificat de sa clé publique auprès d'une autorité de certification CA . Alice génère un nombre entier a (qui va servir à obtenir sa clé secrète) et envoie 15 aG à l'autorité de certification CA. L'autorité de certification CA possède une clé privée c et une clé publique correspondante cG . Elle génère un nombre entier k compris dans [1,n-1] et calcule une donnée y, dite donnée de reconstruction de clé publique (public key reconstruction data) au moyen de : 20 y - aG + kG (1) La donnée y appartient par conséquent à la courbe elliptique. L'autorité de certification CA calcule le condensat e = h (rMID A) où IDA est un 25 identifiant d'Alice (par exemple son adresse IPv6), Il est une opération de concaténation et h(.) est une fonction de hachage (telle que SHA-1). L'autorité de certification CA calcule ensuite la donnée de reconstruction de clé privée (private key reconstruction data) par: 3048319 3 s = ek + c mod.n (2) L'autorité de certification envoie à Alice le couple de données de reconstruction de clé privée et de clé publique (s, y) . Cette dernière peut alors calculer sa clé privée, a, 5 et sa clé publique, QA, comme suit : a=ecr+s mod.n (3-1) QA er+QCA (3-2) 10 où QcA est la clé publique de l'autorité de certification. On voit qu'un tiers, Bob, désirant échanger avec Alice de manière sécurisée, peut directement obtenir sa clé publique QA à partir de son certificat implicite y. Cette méthode de chiffrement et de certification est bien adaptée à l'Internet des objets (loT) car les clés ainsi que les certificats implicites sont de taille très faible (128 ou 15 256 bits) Il n'en demeure pas moins que les certificats implicites sont gérés (création, stockage, révocation) de manière centralisée par une autorité de certification. Or, la confiance dans une autorité de certification centralisée peut être sujette à caution ou remise en cause, tout particulièrement dans le domaine de l'Internet des objets où leur 2 0 indépendance n'est pas forcément garantie. Le but de la présente invention est par conséquent de proposer une méthode de gestion de certificats implicites, notamment dans le domaine de l'Internet des objets, qui ne présente pas les inconvénients précités. En particulier, l'invention vise à proposer une méthode de gestion de certificats implicites offrant un degré de sécurité très élevé et 25 indépendante d'une autorité de certification unique. EXPOSÉ DE L'INVENTION La présente invention est définie par une méthode de gestion de certificats implicites de clés publiques pour un réseau de communication, les clés publiques étant 3048319 4 relatives à un cryptosystème sur courbe elliptique, chaque certificat implicite permettant d'identifier une clé publique d'un noeud du réseau et chaque noeud étant identifié par un identifiant, dans laquelle : un premier certificat implicite ( y ) d'un noeud A est calculé par et stocké 5 dans un premier noeud indexeur ( B0 ), le premier noeud indexeur étant déterminé par une table de hachage distribuée, à partir d'un condensat d'identifiant obtenu comme hachage d'une première valeur, contenant l'identifiant du noeud A; une première clé publique (QA0 ) du noeud A est calculée à partir du premier certificat implicite et de la clé publique du premier noeud indexeur (QB0 ); 10 un second certificat implicite ( yA ) du noeud A est calculé par un second noeud indexeur ( B1), le second noeud indexeur étant déterminé par ladite table de hachage distribuée, à partir d'un premier condensat de certificat ( ) obtenu comme hachage d'une seconde valeur, contenant le premier certificat implicite et l'identifiant du noeud A , ledit second certificat implicite étant transmis au premier noeud indexeur pour y être 15 stocké ; une seconde clé publique ( QA ) du noeud A est calculée à partir de la première clé publique (Q )du noeud A et de la clé publique du second noeud indexeur ( QB,)" Le condensat d'identifiant est avantageusement obtenu par h(IDA keyword) où 20 IDA est l'identifiant du noeud A, keyword est un mot de passe connu des noeuds du réseau, II est une opération de concaténation et h est une fonction de hachage. Selon un premier mode de réalisation : la première clé publique du noeud A est calculée par QA0 = e AorAo +QB0 où rAo est le premier certificat implicite, est le premier condensat de certificat et QB0 est 25 la clé publique du premier noeud indexeur ; la seconde clé publique du noeud A est calculée par Q Ai = QA0 ± eAlyAi+ QB1 où 7A. est le second certificat implicite du noeud A, eAi est un second condensat de 3048319 5 certificat obtenu comme hachage d'une seconde valeur, contenant le second certificat implicite du noeud A, et QB1 est la clé publique du second noeud indexeur. Selon un second mode de réalisation de l'invention, on génère une pluralité de certificats implicites pour le noeud A au cours d'une pluralité d'itérations successives, et à 5 l'itération i: un (i +1) ème noeud indexeur (Bi) calcule un (i +1) ème certificat implicite ( yA ) du noeud A, le (i +1) ème noeud indexeur étant déterminé par la table de hachage distribuée, à partir d'un sème condensat de certificat ( ) obtenu comme hachage d'une (i +1) ème valeur contenant le sème certificat implicite du noeud A obtenu à l'itération 10 précédente, et l'identifiant du noeud A (IDA), ledit (i +1) ème certificat implicite du noeud A étant transmis au premier noeud indexeur pour y être stocké ; une (i +1) ème clé publique (QA, ) du noeud A est calculée à partir de la l ème clé publique ( ) du noeud A, obtenue à l'itération précédente, et de la clé publique du (i + 1) ème noeud indexeur (QB1 15 Le (i +1) ème condensat de certificat est avantageusement obtenu par eA -h(yADIDA) ou bien e = h(2, AlrA,_111ID A) où 7A, et yA sont respectivement les (i +1) ème et sème certificats implicites, IDA est l'identifiant du noeud A et II est une opération de concaténation et h est une fonction de hachage. Alternativement, le (i +1) ème condensat de certificat est obtenu par 2 0 eA= h(yA,MIDADA,) ou bien eA= h(2,AVA11IDAIIDA) où yA et 7A sont respectivement les (i +1) ème et sème certificats implicites, IDA est l'identifiant du noeud A , DA, est une date de validité associée au (i +1) ème certificat implicite, II est une opération de concaténation et h est une fonction de hachage. La (i +1) ème clé publique du noeud A peut être calculée par 25 QA=QA,_1+ eAyA+QB où yA est le (i+1) ème certificat implicite du noeud A, eA est le 3048319 6 (i +1) ème condensat de certificat et QB, est la clé publique du (i +1) ème noeud indexeur. L'intervalle entre deux itérations successives peut avoir une durée fixe prédéterminée. Alternativement, au (i +1) ème certificat implicite ( yA, ) calculé à l'itération i, est 5 associée une date de validité (DA) et l'on effectue l'itération suivante lorsque cette date de validité est échue. Alternativement encore, l'intervalle entre deux itérations successives peut avoir une durée pseudo-aléatoire. Dans tous les cas, on pourra prévoir qu'à l'itération i, le premier noeud indexeur 10 stocke, en relation avec le condensat d'identifiant, une liste des certificats implicites j=o,...,i obtenus lors des itérations successives. En outre, à l'itération i, le premier noeud indexeur peut stocker en relation avec le condensat d'identifiant, une liste des dates de validité DA , j = 0,...,i desdits certificats implicites et/ou une liste des taux de confiance et réputation T &RJ, j=0,...,i où T &RJ 15 est le taux de confiance et réputation du (1+1) ème noeud indexeur. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention, en faisant référence aux figures jointes 20 parmi lesquelles : La Fig. 1 représente un exemple de répartition du stockage de certificats implicites dans différents noeuds selon une table de hachage distribuée ; La Fig. 2 représente un ordinogramme de la méthode de gestion de certificats implicites de clés publiques selon un premier mode de réalisation de l'invention ; 25 La Fig. 3 représente un ordinogramme de la méthode de gestion de certificats implicites de clés publiques selon un second mode de réalisation de l'invention. 3048319 7 EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS Nous considérerons dans la suite une pluralité de noeuds d'un réseau, par exemple un réseau 6LoWPAN dans le domaine de l'Internet des objets, relié à Internet IP par une passerelle. L'homme du métier comprendra toutefois que l'invention peut trouver à 5 s'appliquer à un réseau quelconque. Une première idée à la base de l'invention est de ne pas stocker les certificats implicites dans un seul noeud, par exemple au sein d'un serveur dédié, mais au contraire de les stocker de manière distribuée dans une pluralité de noeuds au moyen d'une table de hachage distribuée ou DHT (Distributed Hash Table). 10 On rappelle qu'une table DHT permet de trouver à partir d'une clé, l'adresse d'un noeud (ou les adresses de plusieurs noeuds) où se trouve stockée l'information (encore dénommée valeur dans le contexte d'une DHT) associée à cette clé. On pourra trouver une introduction aux techniques de DHT dans l'article de S. Sarmady intitulé « A Survey on Peerto-Peer and DHT », arXiv preprint arXiv:1006.4708, 2010. 15 Dans la suite, le stockage des certificats implicites sera décrit selon le protocole Chord. L'homme du métier comprendra toutefois que d'autres protocoles de stockage par DHT pourront être alternativement utilisés sans sortir pour autant du cadre de la présente invention. Comme nous l'avons vu plus haut, les certificats implicites sont générés au moyen 20 d'une fonction de hachage h (par exemple un hachage SHA). Si l'on note m le nombre de bits des condensats, la fonction h prend ses valeurs dans l'intervalle [0,2m -11. Cet intervalle peut être rebouclé sur lui-même (la valeur r coïncidant alors avec la valeur 0) et représenté sous forme d'un cercle comme illustré en Fig. 1. Selon un premier exemple de réalisation, l'intervalle [0,2m -11 est divisé en une 25 pluralité de segments consécutifs (portions de couronne dans la Fig. 1), à chaque segment étant associé un noeud représentatif, à savoir un noeud du réseau tel que sa valeur de hachage (condensat) soit comprise dans le segment en question. Autrement dit, à un segment [a , b[ c[0,2m -11 on associe un noeud Bi E {BO,...,BN) tel que h (B t) [a,b[ 3048319 8 On dit alors que le noeud A gère le segment [a,b[ ou les points de ce segment. De préférence, selon un second exemple de réalisation, on effectue un recouvrement de l'intervalle [0,2m -11 par une pluralité de segments, ces segments pouvant se chevaucher avec un degré de chevauchement, K, autrement dit tout point de 5 cet intervalle appartient à au moins K segments distincts. Les noeuds associés aux différents segments sont dénommés noeuds indexeurs et contiennent une copie de la table DHT. La table DHT donne, pour chaque segment, le noeud indexeur chargé de gérer les certificats implicites appartenant à ce segment. Ainsi, pour récupérer le certificat implicite d'une clé publique appartenant à un 10 noeud caractérisé par son identifiant ID, par exemple son adresse IPv6, on calcule la valeur de hachage h(ID) et l'on recherche dans la table DHT un noeud indexeur A chargé de gérer un segment contenant h(ID). Le certificat implicite pourra être récupéré auprès de ce noeud indexeur. Les noeuds indexeurs peuvent le cas échéant être organisés de manière 15 hiérarchique, un niveau grossier d'indexation étant réalisé par des noeuds indexeurs de premier niveau pointant vers des noeuds indexeurs d'un second niveau chargé d'une indexation plus fine (c'est-à-dire d'une segmentation plus fine). Dans le domaine de l'Internet des objets, le noeud indexeur racine peut être la passerelle entre le réseau 6LoWPAN et Internet. 20 En tout état de cause, on comprendra que le second exemple de réalisation présente l'avantage d'offrir une redondance de stockage en raison du chevauchement des segments. Ainsi, si l'un desdits noeuds indexeurs en charge du segment pertinent quitte le réseau ou tombe en panne, le certificat implicite pourra être récupéré alternativement auprès des K -1 autres noeuds. 25 Le cas échéant, chaque segment pourra être géré par plusieurs noeuds indexeurs, chaque noeud indexeur étant alors affecté d'un niveau de priorité. Ainsi, on pourra s'adresser d'abord à un premier noeud indexeur de haute priorité gérant le segment qui contient h(Id) et, en cas de surcharge de ce premier noeud indexeur, à un second noeud de moindre priorité gérant ce même segment. 3048319 9 Le stockage et la gestion des certificats implicites sont ainsi distribués auprès d'une pluralité de noeuds du réseau. Ces noeuds sont avantageusement choisis parmi ceux qui présentent la plus grande capacité mémoire. Pour éviter qu'un noeud indexeur puisse s'attribuer un segment de la DHT, on 5 pourra avantageusement ajouter un mot de passe, keyword , connu par l'ensemble des noeuds du réseau à l'identifiant du noeud, ID, avant de lui appliquer la fonction de hachage. Plus précisément, pour un segment [a,b[ donné, le noeud indexeur de ce segment (et gérant par conséquent les certificats implicites tombant dans ce segment) sera alors choisi parmi les noeuds Bi tel que h(IDB keyword)E [a,b[. 10 Une seconde idée à la base de la présente invention est de chaîner les certificats implicites pour renforcer la sécurité des certificats et l'authentification des clés publiques qu'ils contiennent. 15 La Fig. 2 représente de manière schématique une méthode de gestion de certificats implicites selon un premier mode de réalisation de l'invention. On suppose qu'un noeud A (Alice) souhaite obtenir un certificat implicite pour une clé publique selon un cryptosystème sur courbe elliptique ECC. Le cryptosystème ECC est défini par un ensemble de paramètres de domaine (domain parameters) donnés, à 20 savoir les constantes intervenant dans l'équation elliptique définie sur Zp (où p est premier), le point générateur G et l'ordre n du groupe cyclique engendré par le point générateur. A l'étape 210, le noeud A calcule la valeur de hachage h(IDA), où IDA est un identifiant du noeud A. La valeur h(/dA ) sera dénommée pour cette raison condensat 25 d'identifiant. Le noeud A détermine au moyen de la table DHT un noeud indexeur chargé de la gestion d'un segment contenant h(IDA). Optionnellement, un mot de passe pourra être concaténé à l'identifiant avant d'effectuer le hachage. Dans tous les cas, on note /30 ce noeud indexeur. 3048319 10 A l'étape 220, le noeud A génère un entier ao et transmet aoG au noeud /30. En pratique seule la coordonnée x0 de aoG peut être transmise, le noeud /30 connaissant les paramètres de domaine. Le noeud /30 possède une clé privée b0 et une clé publique correspondante 5 Qi3o = boG - A l'étape 230, le noeud B0 calcule des données de reconstruction de clé privée et de clé publique comme suit : Le noeud B0 génère un entier k0 compris dans l'intervalle [1,n-1] et calcule une donnée de reconstruction de clé publique 2,0 au moyen de : 10 yo = «DG+ koG (4-1) Cette donnée de reconstruction de clé publique constitue le premier certificat implicite (de la clé publique) du noeud A. 15 Le noeud indexeur B0 calcule ensuite le condensat eA0=h(yA011IDA) ou bien encore le condensat eAo =h(y M A DAO) où DA, est la date de validité du certificat implicite du noeud A et II désigne comme précédemment l'opération de concaténation. En tout état de cause, le condensat eA,' dit premier condensat de certificat, est obtenu par le hachage d'une information contenant le premier certificat implicite y et l'identifiant 20 du noeud A. Quelle que soit la forme retenue pour le condensat, le noeud B0 détermine à partir de ce dernier une donnée de reconstruction de clé privée : s =eAo kAo +b0 mod.n Ao (4-2) 25 A l'étape 240, le noeud indexeur B0 envoie au noeud A le couple (sA0,yA0) constitué par la donnée de reconstruction de clé privée et la donnée de reconstruction de 3048319 11 clé publique. En outre, B0 stocke dans sa mémoire locale le certificat implicite y et, le cas échéant, la date de validité DA, de ce certificat, en relation avec le condensat d'identifiant h(/DA). A l'étape 250, le noeud A construit une première clé privée et une première clé 5 publique respectivement au moyen des données de reconstruction des clés privée et publique, à savoir : a = e mod.n (5-1) A, A, 0 QAo = e Aoy Ao + QB0 (5-2) 10 A l'étape 255, on détermine un noeud indexeur B1 gérant le premier certificat implicite dans la DHT. Plus précisément le noeud B1 est un noeud indexeur de la DHT pour un segment contenant le premier condensat de certificat, à savoir e A0 = h(y AollID A) ou 15 l'une des variantes précitées. A l'étape 260, le noeud A génère un entier ai et transmet aiG au noeud B1. Le noeud B1 possède une clé privée bi et une clé publique correspondante QB = biG A l'étape 270, le noeud B1 calcule des données de reconstruction de clé privée et de clé publique. Plus précisément le noeud B1 génère un entier kB compris dans l'intervalle 20 [1,n -1] et calcule une donnée de reconstruction de clé publique y Ai au moyen de : y4 = aiG + kB9 (6-1) Cette donnée de reconstruction de clé publique constitue le second certificat 25 implicite du noeud A. Le noeud indexeur B1 calcule ensuite un second condensat de certificat défini par 3048319 12 e =h(yA IDA) ou eA = h(yAIMIDADDA) ou bien encore, en consolidant les certificats e = IDA) ou e = IDA DA)où D1 est la date de validité du certificat implicite du noeud B1. Le noeud indexeur B1 détermine à partir du second condensat de certificat une 5 donnée de reconstruction de clé privée : sA = eAkB +b1 mod .n (6-2) A l'étape 280, le noeud indexeur B1 envoie au noeud A le couple (sAi ,rAi) 10 constitué par la donnée de reconstruction de clé privée sAi et le second certificat implicite. En outre, le noeud B1 transmet au noeud /30 le second certificat implicite yAi et, le cas échéant, la date de validité DA de ce certificat. Le noeud /30 stocke dans sa mémoire locale le second certificat implicite (ainsi que, éventuellement, la date de validité DA) en relation avec le condensat d'identifiant h(IdA). 15 On comprend ainsi que sont stockés, en relation avec h(IdA), les premier et second certificats implicites yk, , yAi et le cas échéant, leurs dates de validité respectives D D Ao, A" A l'étape 290, le noeud A construit une seconde clé privée à partir de la donnée de reconstruction de clé privée, sAi , et de sa première clé privée, a A, , soit : 20 aAi = aAo + eAoe1+ sA mod .n (7-1) De manière similaire, le noeud A construit une seconde clé publique à partir de la donnée de reconstruction de clé publique, yAi , et de sa première clé publique, QA0: 25 QA1 eA YA+ QB (7-2) 3048319 13 On peut montrer que la relation QA = a AIG est bien vérifiée. La Fig. 3 représente de manière schématique une méthode de gestion de 5 certificats implicites selon un second mode de réalisation de la présente invention. Nous supposerons que le cryptosystème sur courbe elliptique est le même que dans le premier mode de réalisation. Le noeud A souhaite à nouveau obtenir un certificat implicite pour une clé publique relevant de ce cryptosystème. La génération du certificat implicite et des clés du noeud A est initialisée par les 10 étapes 310 à 350. Les étapes 310 à 350 sont respectivement identiques aux étapes 210 à 250 et leur description ne sera donc pas reprise ici. Un certain temps après la phase n'initialisation, pouvant correspondre à la durée de validité du certificat implicite, ou bien encore à l'échéance d'une période de répétition, ou encore une durée obtenue par un tirage pseudo-aléatoire, le certificat implicite est 15 enrichi par un processus de chaînage par récurrence en relation avec les étapes 360 à 390. De manière générale, l'intervalle entre deux itérations successives peut être fixe ou bien dépendre de la durée de validité du certificat ou bien encore être pseudo-aléatoire. Nous supposons ici que la (i -1) ème itération a déjà été effectuée et nous considérons la sème itération. 20 A l'étape 355, le noeud A recherche le noeud B qui gère le condensat eA dans la DHT, autrement dit Bi est un noeud indexeur pour un segment qui contient e . A l'étape 360, le noeud A génère un entier ai et transmet aiG au noeud Bi . Le noeud Bi possède une clé privée bi et une clé publique correspondante QB, =1),G . 25 A l'étape 370, le noeud B calcule des données de reconstruction de clé privée et de clé publique comme suit : Le noeud Bi génère un entier kB compris dans l'intervalle [1,n-1] et calcule une donnée de reconstruction de clé publique yA au moyen de : 3048319 14 yA, = a,G+49 (8-1) Le noeud indexeur Bi calcule le condensat eA,= h(yAIIIDA) ou 5 eA = h(yAIDAD4) ou bien encore, en consolidant les certificats implicites successifs, e A = h(yA,IlyA11IDA) voire le condensat eA= h(yA, 112,, °IDA 11D, ) où DA, est la date de validité du certificat implicite du noeud Bi. Le cas échéant, on pourra ajouter dans l'opérande de la fonction de hachage un taux de confiance et réputation (encore dénommé taux T&R) du noeud Bi. Le taux T&R est une estimation de la confiance et de la réputation 10 du noeud établi à partir des autres noeuds du réseau. La notion de T&R est bien établie dans le domaine des communications P2P (Peer to Peer). On pourra notamment en trouver une description dans l'article de A. Medic. intitulé "Survey of Computer Trust and Reputation Models - The Literature Overview" publié dans Int. J. Inf, 2012, vol. 2, no 3. L'incorporation du taux T&R dans l'opérande de la fonction de hachage permet aux autres 15 noeuds d'avoir une confiance plus élevée dans le lien entre l'identifiant et le certificat implicite. Quelle que soit la forme retenue pour le condensat, le noeud Bi détermine à partir de ce dernier une donnée de reconstruction de clé privée de l'itération i : 20 =e mod.n (8-2) A ki Bi A l'étape 380, le noeud indexeur Bi envoie au noeud A le couple (s constitué par la donnée de reconstruction de clé privée et la donnée de reconstruction de clé publique de l'itération i . 25 En outre, le noeud Bi transmet au noeud B0 le certificat implicite yA, et, le cas échéant, la date de validité DA, de ce certificat. Le noeud B0 stocke dans sa mémoire locale le certificat implicite yA, (ainsi que, éventuellement, D. et T & Ri) en relation avec la 3048319 15 valeur de hachage «/DA ). A l'étape 390, le noeud A construit une nouvelle clé privée à partir de la donnée de reconstruction de clé privée de l'itération courante i et de la clé privée de l'itération 5 précédente, i -1, par: =aA -1 +eA +s mod.n (9-1) De manière similaire, le noeud A construit une nouvelle clé publique à partir de 10 la donnée de reconstruction de clé publique de l'itération i et de la clé publique de l'itération i -1: e Air Ai ± QBi (9-2) 15 On peut montrer par récurrence que QA, = aA9 . En effet, la propriété est bien vérifiée pour i = 0 et si Q = a AG puisque l'on a en vertu de (9-2) et (8-1): Q = a + e (aiG + k'G)+biG = (a +e A, A, + e + ) G (10) 20 et d'après (9-1) et (8-2): aA, = aA, 1+ eA,a, + s = a A, 1+ eA,a, + e',k', On notera que, pour une itération courante i, le noeud B0 qui gère h(IDA) dans la DHT, stocke dans sa mémoire, en relation avec h(IDA), la liste des certificats implicites yA , j =0,...,i et, le cas échéant, la liste des dates de validité DA et/ou les taux de 25 confiance et réputation T &Ri, j =0,...,i . Le noeud A peut quant à lui se contenter de stocker dans sa mémoire sa dernière clé privée aA, ainsi que ses deux derniers certificats implicites yA, yA , voire son dernier certificat implicite yA seulement. 3048319 16 Le dernier certificat implicite du noeud A, yA, suffit pour mettre à jour la clé publique au moyen de (9-2) dès lors que l'on connait la clé publique du noeud QB. Ainsi, un noeud C (Bob) souhaitant initier une communication sécurisée avec le noeud A peut récupérer auprès du noeud B0, gérant h(IDA), le dernier certificat implicite du noeud A, 5 yA, et en déduire sa clé publique courante Réciproquement, le noeud A doit contacter le noeud indexeur, Do, gérant h(/Dc ) dans la DHT pour récupérer le dernier certificat implicite du noeud C et en déduire sa clé publique courante Q. . Les noeuds A et C peuvent alors communiquer entre eux de manière sécurisée. Dans ces conditions, on comprendra qu'une attaque du type «man in the middle» 10 nécessiterait pour réussir d'opérer simultanément entre le noeud A et son indexeur, B0, entre le noeud C et son indexeur Do ainsi qu'entre A et C, ce qui est très difficile à réaliser sauf à contrôler tout le réseau. En outre, chacun des noeuds A et C peut s'assurer de la cohérence de la clé publique de l'autre en vérifiant si le chaînage des certificats implicites est valide. Ainsi, le noeud C pourra s'assurer de la cohérence de la clé publique 15 QA avec le noeud A en vérifiant auprès de B0 que celle-ci a bien été obtenue au moyen de la relation (7-2) à partir des certificats implicites yA, . Selon la présente invention, les certificats ne sont donc pas stockés auprès d'une autorité de certification unique mais auprès de noeuds indexeurs participant à la DHT. Le stockage distribué des certificats implicites ainsi que le chainage de ces 20 certificats pour l'obtention des clés publiques et privées des noeuds rendent le réseau particulièrement résistant aux attaques de type « man in the middle ». REVENDICATIONS1. Méthode de gestion de certificats implicites de clés publiques pour un réseau de communication, les clés publiques étant relatives à un cryptosystème sur courbe elliptique, chaque certificat implicite permettant d'identifier une clé publique d'un noeud du réseau et chaque noeud étant identifié par un identifiant, caractérisée en ce que : un premier certificat implicite ( y ) d'un noeud A est calculé par et stocké dans un premier noeud indexeur ( B0 ), le premier noeud indexeur étant déterminé par une table de hachage distribuée, à partir d'un condensat d'identifiant obtenu comme hachage d'une première valeur, contenant l'identifiant du noeud A; une première clé publique (QA0 ) du noeud A est calculée à partir du premier certificat implicite et de la clé publique du premier noeud indexeur ( QB.) ); un second certificat implicite ( yA ) du noeud A est calculé par un second noeud indexeur ( B1), le second noeud indexeur étant déterminé par ladite table de hachage distribuée, à partir d'un premier condensat de certificat ( ) obtenu comme hachage d'une seconde valeur, contenant le premier certificat implicite et l'identifiant du noeud A , ledit second certificat implicite étant transmis au premier noeud indexeur pour y être stocké ; une seconde clé publique ( QA ) du noeud A est calculée à partir de la première clé publique (Q )du noeud A et de la clé publique du second noeud indexeur ( QB1). 2. Méthode de gestion de certificats implicites selon la revendication 1, caractérisée en ce que le condensat d'identifiant est obtenu par h(IDAIlkeyword) où IDA est l'identifiant du noeud A, keyword est un mot de passe connu des noeuds du réseau, Ilest une opération de concaténation et h est une fonction de hachage. 3048319 18 3. Méthode de gestion de certificats implicites selon la revendication 1 ou 2, caractérisée en ce que : la première clé publique du noeud A est calculée par QA0 eAo + QB, où 5 yAo est le premier certificat implicite, ek est le premier condensat de certificat et QB0 est la clé publique du premier noeud indexeur ; la seconde clé publique du noeud A est calculée par QA = QA0 eAl yAi +QB où yAi est le second certificat implicite du noeud A, eAi est un second condensat de certificat obtenu comme hachage d'une seconde valeur, contenant le second certificat 10 implicite du noeud A, et QB est la clé publique du second noeud indexeur. 4. Méthode de gestion de certificats implicites selon la revendication 1 ou 2, caractérisée en ce que l'on génère une pluralité de certificats implicites pour le noeud A au cours d'une pluralité d'itérations successives, et qu'à l'itération i : 15 un (i+1)ème noeud indexeur (Bi) calcule un (i+1) ème certificat implicite ( yA ) du noeud A, le (i+1)ème noeud indexeur étant déterminé par la table de hachage distribuée, à partir d'un sème condensat de certificat ) obtenu comme hachage d'une (i+1) ème valeur contenant le sème certificat implicite du noeud A obtenu à l'itération précédente, et l'identifiant du noeud A (IDA), ledit (i+1) ème certificat implicite du noeud 2 0 A étant transmis au premier noeud indexeur pour y être stocké ; une (i +1) ème clé publique (QA, ) du noeud A est calculée à partir de la sème clé publique ( Q,4) du noeud A, obtenue à l'itération précédente, et de la clé publique du (i+1) ème noeud indexeur ( QB). 25 5. Méthode de gestion de certificats implicites selon la revendication 4, caractérisée en ce que le (i +1) ème condensat de certificat est obtenu par eA = h (yA MIDA 3048319 19 ou bien eA, - h (y A, IDA) où rA, et r sont respectivement les (i+1) ème et i ème certificats implicites, IDA est l'identifiant du noeud A et II est une opération de concaténation et h est une fonction de hachage. 5 6. Méthode de gestion de certificats implicites selon la revendication 4, caractérisée en ce que le (i +1) ème condensat de certificat est obtenu par eA= h (yA, IDAIIDA,) bien eA = h (7 112,, DIDADD, ) où rA et sont ou respectivement les (i +1) ème et sème certificats implicites, IDA est l'identifiant du noeud A , DA, est une date de validité associée au (i+1)ème certificat implicite, II est une 10 opération de concaténation et h est une fonction de hachage. 7. Méthode de gestion de certificats implicites selon l'une des revendications 4 à 6, caractérisée en ce que la (i+1) ème clé publique du noeud A est calculée par Q A,= Q +e A, y A, + QB, où yA, est le (i+1) ème certificat implicite du noeud A, eA est le 15 (i+1) ème condensat de certificat et QB est la clé publique du (i +1) ème noeud indexeur. 8. Méthode de gestion de certificats implicites selon l'une des revendications 4 à 7, caractérisée en ce que l'intervalle entre deux itérations successives a une durée fixe 20 prédéterminée. 9. Méthode de gestion de certificats implicites selon l'une des revendications 4 à 7, caractérisée en ce qu'au (i +1) ème certificat implicite ( yA ) calculé à l'itération i, est associée une date de validité (DA,) et que l'on effectue l'itération suivante lorsque cette 25 date de validité est échue. 10. Méthode de gestion de certificats implicites selon l'une des revendications 4 à 7, caractérisée en ce que l'intervalle entre deux itérations successives a une durée 3048319 20 pseudo-aléatoire. 11. Méthode de gestion de certificats implicites selon l'une des revendications 4 à 10, caractérisée en ce qu'à l'itération i, le premier noeud indexeur stocke, en relation 5 avec le condensat d'identifiant, une liste des certificats implicites rA , j = o, i obtenus lors des itérations successives. 12. Méthode de gestion de certificats implicites selon la revendication 11, caractérisée en ce que, à l'itération i, le premier noeud indexeur stocke en relation avec le 10 condensat d'identifiant, une liste des dates de validité DA , j = desdits certificats implicites et/ou une liste des taux de confiance et réputation T &Ri, j=0,...,i où T &Ri est le taux de confiance et réputation du (1+1) ème noeud indexeur.