FR 2988942 A1 20131004 FR 1252737 A 20120327 2988942 METHODE ET SYSTEME D'ETABLISSEMENT D'UNE CLE DE SESSION Domaine de l'invention L'invention concerne le domaine des communications réseau et en particulier les communications cryptées entre les entités d'un réseau global de communication. Etat de la Technique Dans un réseau de communications cryptées, les entités du réseau en communication sont désignées au moyen d'un identifiant qui est obtenu à partir d'un paramètre cryptographique, tel que par exemple la clé publique d'un algorithme cryptographique asymétrique. Afin de procéder à l'établissement d'une session de communication, un protocole d'échange de clé authentifié « Authenticated Key Exchange (AKE) en anglais » est mis en oeuvre entre une entité source et une entité cible. Ce protocole a pour but de dériver une clé de session, mais aussi d'établir l'authentification mutuelle des deux entités. Dans le cas de communications à identifiants générés cryptographiquement, les différents protocoles AKE de l'état de l'art fondent l'authentification d'une entité sur la preuve de sa connaissance de la totalité du matériel cryptographique, c'est-à-dire la connaissance d'une clé publique et d'une clé privée 2 2988942 dont son identifiant est issu. Plusieurs protocoles d'échange de clé authentifié sont connus tels que ceux listés par exemple ci-après. 5 Le protocole « Host Identity Protocol Base Exchange ou (HIP-BEX) en anglais » décrit dans le papier de [R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, "Host Identity Protocol", IETF RFC 5201, 10 April 2008] propose un système d'échange de clés basé sur le protocole bien connu Diffie-Hellman. Le protocole HIP-BEX fait usage des mécanismes DiffieHellman de génération et d'échange de clés, ce qui le rend coûteux en ressources. 15 Le protocole « Internet Key Exchange Cryptographically Generated Addresses ou (IKE-CGA) en anglais » décrit dans le papier de [J. Laganier, G. Montenegro, A. Kukec, "Using IKE with IPv6 20 Cryptographically Generated Addresses", IETF draft- laganier-ike-ipv6-cga-02, July 2007] est un protocole qui permet d'étendre les mécanismes d'authentification supportés par IKE à l'authentification au moyen d'adresses cryptographiquement générées. Cette 25 solution met en oeuvre des identifiants générés cryptographiquement dans le cadre de la sécurisation d'un échange Diffie-Hellman standard, et reste un choix couteux en ressources. 30 Le brevet EP 2 290 895 Al décrit une solution d'établissement d'association de sécurité entre deux 3 2988942 noeuds d'un réseau possédant des identifiants cryptographiquement générés au moyen d'un échange en deux messages. Cette solution permet un établissement de clé de session plus rapide que dans les mécanismes 5 précédents qui peuvent requérir de trois à six messages. Néanmoins, le gain en performance est limité car à cet échange succède une génération de clé au moyen des valeurs publiques Diffie-Hellman de l'initiateur et du répondeur, échangées respectivement 10 dans le premier et le second messages de cette solution. Une autre approche est définie par Mache et al. dans le papier de J. Mache, C.-Y. Wan, and M. Yarvis, 15 "Exploiting heterogeneity for sensor network security," in Proceedings of IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks, June 2008, pp. 591-593. La solution prévoit la transmission sécurisée de 20 données entre en capteur faible et un serveur plus puissant, au moyen d'une communication à deux segments, où les données sont d'abord transmises du capteur à un noeud de collecte, et ensuite du noeud de collecte au serveur distant. Le premier segment est 25 sécurisé au moyen d'algorithmes symétriques alors que le second segment s'appuie sur de la cryptographie asymétrique. Le noeud de collecte décrypte les données reçues du capteur et les ré-encrypte à destination du serveur, ce qui ne permet pas l'établissement d'une 30 communication sécurisée de bout en bout entre le capteur et le serveur distant. En effet, aucune 4 2988942 confidentialité n'est assurée vis-à-vis du noeud de collecte. Les protocoles et solutions cités bien que 5 répondant à des besoins d'échange de clé authentifié prévoient l'utilisation de primitives cryptographiques complexes afin de prouver l'identité des entités de la session, et nécessitent donc que les entités aient les ressources appropriées. Ces approches ne sont pas 10 conçues pour être économes en énergie. Ainsi, ces protocoles ne sont pas adaptés pour les réseaux où doivent communiquer des entités fortement contraintes en ressources avec des entités plus puissantes. Un tel type de réseau, comme celui 15 connu sous la dénomination de l'Internet des Objets (IDO), comprend des entités (souvent appelées noeuds) à faible énergie et puissance de calcul qui doivent employer des identifiants cryptographiquement générés pour communiquer avec des entités distantes pouvant 20 avoir des ressources puissantes. Le protocole « HIP Diet Exohange ou (HIP-DEX) en anglais» décrit dans le papier de R. Moskowitz, "HIP Diet EXchange (DEX)", IETF work in progress draft25 moskowitz-hip-rg-dex-05, March 2011, vise à être utilisé par des noeuds à faibles ressources. C'est une version allégée du mécanisme d'échange de clés du protocole précité HIP. Les principales modifications introduites par HIP-DEX sont l'emploi de la 30 cryptographie à courbes elliptiques, l'emploi de valeurs Diffie-Hellman statiques, et de primitives 5 2988942 plus légères pour les fonctions de hachage. Malgré les avantages en performances obtenus sur le protocole de base, le protocole HIP-DEX reste exigeant en ressources du fait de son emploi du protocole Diffie- 5 Hellman. Par ailleurs, il utilise un mécanisme de génération de secret partagé qui postule que tous les échanges de secrets partagés menés par un noeud sont conduits à partir de la même valeur publique, générée par le noeud une seule fois et lui servant également à 10 construire son identifiant cryptographiquement généré. Ainsi, même si la phase coûteuse en ressources de génération de la valeur publique disparaît, cette économie énergétique se fait au détriment de la propriété de confidentialité persistante « perfect 15 forward secrecy » en anglais, qui permet d'assurer qu'un secret échangé ne pourra être retrouvé par un attaquant, quand bien même les secrets à long terme des participants seraient divulgués. 20 Il existe alors le besoin d'une solution qui permette une communication cryptée entre entités ayant des contraintes en ressources différentes et assurant le respect de la confidentialité du secret échangé. 25 La présente invention répond à ce besoin. Résumé de l'invention 30 Un objet de la présente invention est d'offrir une méthode d'échange de clés dans le contexte de 6 2988942 communications dont les identifiants sont générés cryptographiquement. Un autre objet de l'invention est de permettre 5 l'emploi d'identifiants cryptographiquement générés par des noeuds fortement contraint en ressources. Avantageusement, une méthode d'échange de clé authentifié s'appuyant sur ces identifiants est proposée. 10 Un autre objet de la présente invention est de permettre la génération d'un secret partagé entre deux noeuds à identifiants cryptographiquement générés au moyen d'opérations de cryptographie asymétrique sans 15 faire usage du protocole Diffie-Hellman. Avantageusement, le mécanisme sur lequel la présente invention s'appuie peut être mis en oeuvre de manière distribuée, en utilisant l'assistance de noeuds 20 voisins auxquels sont déléguées les opérations les plus consommatrices de cryptographie asymétrique. Avantageusement, la présente invention étend à des noeuds fortement contraints en ressources, l'usage 25 d'identifiants cryptographiquement générés pour générer un secret partagé, alors que cet usage leur était jusqu'ici interdit du fait de la complexité des protocoles d'échange de clé faisant intervenir les identifiants générés cryptographiquement. 30 Avantageusement, la présente invention permet de définir, grâce à des identifiants cryptographiquement générés, un même schéma d'identification, indépendamment du niveau de ressources des entités considérées. Un autre objet de la présente invention est de fournir une méthode qui décharge, auprès de noeuds assistants, un noeud fortement contraint en ressources, des opérations cryptographiques les plus exigeantes en ressources, tout en assurant que les noeuds assistants ne puissent prendre connaissance du secret échangé. Un objet supplémentaire de la présente invention est ainsi de créer des contextes sécurisés entre des 15 noeuds d'un réseau identifiés cryptographiquement. Un autre objet de la présente invention est d'augmenter la durée de vie de noeuds fonctionnant sur batterie tels que des capteurs. 20 Avantageusement, la présente invention s'implémentera dans le contexte de l'Internet des objets où coexistent des entités aux ressources fortement hétérogènes, tels que des serveurs, des 25 objets connectés mobiles, des capteurs peu puissants. Toujours avantageusement mais sans limitation, l'invention trouvera des applications dans des domaines industriels où sont utilisés des éléments de 30 pile de protocoles pour des objets à faible ressources participant à un modèle intégré d'Internet des objets. Pour obtenir les résultats recherchés, une méthode telle que décrite dans la revendication indépendante 1, un système tel que décrit dans la revendication indépendante 12 et un produit programme d'ordinateur tel que décrit dans la revendication 14 sont proposés. En particulier, dans un réseau de communication 10 comprenant une pluralité d'entités communicantes, une méthode pour établir une clé de session entre une entité source et une entité cible est revendiquée. La méthode comprend les étapes de: générer un secret x pour l'entité source, le se- 15 cret comprenant n valeurs de secret (xl,xi,xn) ; - assigner chaque valeur de secret (xi) à une entité assistante (Pi) parmi la pluralité d'entités communicantes; - chiffrer et signer par chaque entité assistante 20 la valeur de secret assignée (xi) ; authentifier l'entité source à réception par l'entité cible d'une ou plus valeurs de secret (xl,xi,xn) chiffrées et signées ; générer un secret y chiffré et signé pour 25 l'entité cible ; - authentifier l'entité cible à réception par au moins une des n entités assistantes (P1,Pi,Pn) de la valeur de secret y chiffré et signé ; et - générer une clé de session entre l'entité source 30 et l'entité cible à réception par l'entité source de la valeur de secret authentifiée. Différentes variantes d'implémentations sont décrites dans les revendications dépendantes. Description des figures Différents aspects et avantages de l'invention 10 vont apparaitre en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : La Figure 1 est une représentation topologique d'une 15 infrastructure réseau dans laquelle implémenter avantageusement l'invention ; La Figure 2 montre les procédures exécutées entre les entités source, cible et assistante du réseau de la 20 figure 1 dans une implémentation avantageuse de l'invention; La Figure 3 montre les étapes opérées par la méthode de l'invention pour établir une session ; 25 La Figure 4 montre les procédures exécutées entre les entités source, cible et assistante du réseau de la figure 1 dans une variante d'implémentation de l'invention. 30 2988942 Description détaillée de l'invention La figure 1 illustre un environnement de réseau 5 global (100) dans lequel l'invention est implémentée avantageusement. Pour des raisons de simplicité de description et non de limitation de l'invention, l'exemple de la figure 1 ne montre qu'un nombre fini d'entités et de connexions, mais l'homme du métier 10 étendra les principes décrits à une pluralité et une variété d'entités et de type de connexions (sans fil, mobile, très haut débit). Le réseau global (100) comprend un ensemble d'entités fixes ou mobiles formant un réseau d'objets (102). Le réseau d'objets comprend des entités à fortes contraintes de ressources (102-1, 102-n) et des entités à moindre contrainte de ressources (112-1, 112-m). Les entités à fortes contraintes de ressource 20 peuvent être des capteurs ou actionneurs sans fil, ayant des capacités de calculs et/ou de stockage limitées. Il peut également s'agir de tags actifs. Cependant, une entité qui n'est pas intrinsèquement limitée en ressources peut l'être de façon temporaire 25 dès lors qu'elle emploie une grande part de ses ressources processeur à une autre tâche, ou que son niveau de batterie atteint une valeur seuil critique. Et cette entité peut être amenée à mettre en oeuvre des protocoles moins couteux en énergie comme celui de 30 l'invention. Les entités à contrainte de ressource moindre peuvent être des téléphones portables munis d'une connexion internet et d'un appareil photo. Il peut également s'agir de passerelles d'interconnexion entre un réseau d'entités contraintes et l'Internet. Ces entités offrent une puissance de calcul et une capacité de stockage plus importantes, peuvent disposer d'une réserve d'énergie (batterie, alimentation sur secteur) plus importante et peuvent communiquer sur un réseau, soit directement à un réseau internet (104) comme illustré ou bien au travers de passerelles et serveurs intermédiaires (non montré). Le réseau d'objets (102) peut être basé sur des communications de niveau 2 (par exemple, 802.15.4 ou 802.11) ou de niveau 3 (par exemple, IP) entre les entités qui le composent. Suivant les protocoles sur lesquels il s'appuie, des schémas de communications multicast ou broadcast peuvent y être employés. Le réseau global (100) comprend des entités distantes (106) ne présentant pas de contraintes en ressources, comparativement à celles des entités du réseau d'objets (102). Les entités distantes peuvent être des serveurs (par exemple, serveur de stockage et/ou management d'informations remontées par un ou plusieurs capteurs ou serveur de contrôle d'actionneurs) ayant des capacités de stockage et de puissance de calcul importantes ou toute autre entité présentant des capacités de calcul, de stockage et d'énergie non contraintes. Un tel réseau global forme ce que l'on trouve dénommé comme un internet des objets (Id0). Il couvre deux types de communication : - celles d'objet à personne; celles d'objet à objet, ou machine à machine (M2M). Ces communications peuvent être établies dans un par par contexte limité (un 10 exemple ZigBee et/ou seul protocole employé, un seul scénario ciblé, exemple le Réseau Electrique Intelligent ou Smart Grid) et on parle alors d' «intranet des objets » ou peuvent avoir vocation à rendre possible un grand nombre de services distincts, tout en s'appuyant sur 15 de nombreux protocoles de communications, et on parle alors d' «Internet des objets». Généralement, on entend par Internet des Objets une architecture qui permet l'interconnexion de l'Internet classique avec des objets communicants ou perçus, et qui s'appuie sur 20 des schémas de communication décentralisés, tout en mettant en oeuvre des mécanismes autonomes. La présente invention peut être avantageusement appliquée dans l'environnement de la figure 1 entre 25 une entité fortement contrainte en ressources (102-1) que l'on dénomme 'initiateur' et un serveur distant puissant (106) que l'on dénomme 'répondeur'. Les deux entités ont besoin d'établir une clé de session et ne partagent pas déjà entre elles un secret à long terme. 30 La méthode qui est décrite en référence à la figure 2 prend en compte les contraintes en termes de ressources et utilise des techniques collaboratives distribuées afin de rendre possible l'échange de clé de session entre deux entités hétérogènes lors d'une même communication. La figure 2 montre les procédures exécutées entre un initiateur (202) et un répondeur (206) pour établir une clé de session. Dans une première phase d'initialisation (210), 10 l'initiateur (202) sélectionne des entités assistantes moins contraintes en ressources que l'initiateur, et désignées ci-après proxies (204-1, 204-n). La sélection peut se baser sur les réputations des entités au voisinage de l'initiateur et/ou sur 15 leurs ressources disponibles telles que par exemple leur puissance de calcul ou leur niveau de batterie. Dans le cas où la sélection se base sur les réputations des noeuds au voisinage, ces derniers peuvent être évalués localement ou par un serveur 20 central selon leurs attitudes passées. Une métrique, la réputation, est alors définie qui rend compte des types et proportions d'attitudes positives (par exemple, offrir un service) et négatives (par exemple, refuser d'offrir un service) qu'un noeud a manifesté 25 par le passé. La détermination du nombre de proxies auxquels un initiateur va recourir n'est pas décrit dans la présente invention, et peut être par exemple fonction de la probabilité que ces proxies conduisent contre le 30 noeud une attaque par collusion. Dans le cas où l'initiateur est par exemple un équipement mobile, le processus de sélection comprend une étape de découverte à son voisinage d'entités avec lesquelles il peut disposer d'un secret partagé. Cette découverte peut s'effectuer dynamiquement, et peut être facilitée 5 par le recours à une entité tierce connaissant l'intégralité de la topologie du réseau dans laquelle l'initiateur évolue. Dans une variante, l'initiateur peut contenir une liste prédéfinie de proxies utilisables, et la 10 sélection des proxies à utiliser pour la session est faite sur cette liste. Dans une phase suivante (220), un échange d'informations relatives à la sécurité supportée par 15 l'initiateur (202) et par le répondeur (206) est opéré. L'initiateur (202) envoie un message (222) pour informer le répondeur (206) de son identité ID(I), indiquer les algorithmes cryptographiques qu'il 20 supporte, et la méthode d'établissement de clé qu'il souhaite utiliser. Si le répondeur (206) accepte la technique d'établissement de clé proposée, il répond à l'initiateur par un message (224) qui peut contenir son identité ID(R) ainsi que le choix de l'algorithme 25 cryptographique choisi parmi ceux proposés par l'initiateur. En effet, la méthode d'établissement de clé négociée peut par exemple être basée sur RSA, ECC les algorithmes cryptographiques peuvent inclure les algorithmes de chiffrement : RC4, RC2, DES, AES, 3DES 30 et/ou les fonctions de hachage MD5 et SHA-1. A l'issue de la phase 220, l'initiateur et le répondeur ont établi les paramètres de connexion pour leur session. Dans une phase suivante (230), l'initiateur 5 informe les proxies de l'identité du répondeur, et un message (232) contenant l'identité du répondeur ID(R) est envoyé à chaque proxy sélectionné en phase 210. Dans une variante d'implémentation, chaque message (232) peut aussi contenir aussi une 10 information PR(Kpi) qui va permettre à chaque proxy de prouver sa représentativité auprès du répondeur. Dans une première variante de l'invention, les proxies, munis d'une paire clé publique / clé privée, 15 reçoivent directement de l'initiateur la preuve qu'ils sont autorisés à agir en son nom. Cette preuve peut être, par exemple, un certificat associant la clé publique du proxy au droit « habilité à signer au nom de l'initiateur », le tout étant signé par la clé 20 privée de l'initiateur. Ce certificat peut inclure d'autres paramètres ajoutés par l'initiateur dans le but de restreindre la capacité des proxies à signer en son nom, tels que l'identité du répondeur ou une date d'expiration. Dans le cas d'un certificat n'incluant 25 que l'identité du proxy et son statut d'entité habilitée à signer au nom de l'initiateur, ce certificat peut avoir été envoyé par l'initiateur au proxy en dehors de la session active. Alternativement, dans le cas d'un certificat faisant figurer l'identité 30 du répondeur ou comportant une date d'expiration, le certificat est envoyé au proxy pendant la session active. Dans une seconde variante de l'invention, l'autorisation des proxies à agir au nom de l'initiateur est gérée par une entité de confiance tierce. L'initiateur fournit à l'entité de confiance T un certificat associant des droits permettant de donner à des entités du réseau, des droits de signer au nom de l'initiateur, l'identité de T, le tout étant signé par une clé privée correspondant à l'identifiant généré cryptographiquement. Avantageusement, l'entité de confiance T peut être une entité physique unique, ou peut être une entité logique physiquement instanciée sous la forme de différentes entités physiques, mettant en oeuvre un système de redondance de manière à assurer une continuité de service en cas de crash. L'initiateur transmet la liste des proxies à l'entité de confiance qui à réception transmet à chaque proxy l'ensemble des informations cryptographiques nécessaire pour authentifier le message que chaque proxy envoie au répondeur. Dans la réalisation préférentielle de cette seconde variante de l'invention, les informations cryptographiques comprennent une paire clé publique / clé privée d'un système de signature. Avantageusement, un tel système de signature à usage unique peut être le système dit « HORS » décrit dans le papier de L. Reyzin et al. "Better than BiBa: Short One-Time Signatures with Fast Signing and Verifying", LNCS 2384, pp. 144-153, 2002. L'entité de confiance fournit également à chaque proxy un moyen qui autorise ce dernier à signer des messages d'échange du protocole au nom de l'initiateur, c'est-à-dire de prouver son habilitation 5 à agir au nom de l'initiateur. Ce moyen peut prendre la forme d'un message associant cryptographiquement le droit assigné au proxy de signer au nom de l'initiateur, le certificat envoyé antérieurement par l'initiateur à l'entité de confiance, la partie 10 publique du matériel cryptographique remis par l'entité de confiance au proxy, le tout étant signé par la clé privée de l'entité de confiance. Après l'envoi du message 232 contenant l'identité 15 du répondeur et éventuellement la preuve de représentativité, chaque proxy établit une connexion avec le répondeur et éventuellement envoie un message (234) contenant la preuve de représentativité qu'il a reçu de l'initiateur ou d'une entité de confiance. 20 A l'issue de la phase 230, le répondeur et les proxies ont établi les paramètres de connexion pour leur session. L'étape suivante va consister à préparer et échanger des modèles initiaux de la clé de session 25 entre l'initiateur et le répondeur (aussi appelés « premaster secrets x et y » en anglais) afin de calculer plus tard la clé de session partagée. L'initiateur remet au répondeur un secret x généré aléatoirement et le répondeur remet à l'initiateur un 30 secret y. La clé de session sera calculée ensuite à partir de ces deux valeurs secrètes. Dans la phase suivante (240), l'initiateur (202) décompose (242) son secret x en n fragments de secret, n étant le nombre de proxies sélectionnés pour supporter la session. Chaque valeur de secret est assignée à un proxy. Avantageusement, une procédure de correction d'erreurs peut être appliquée sur le secret x original avant de le décomposer, de manière à lui rajouter de la redondance. Ceci permet au répondeur d'être en mesure de reconstituer le secret envoyé, par l'initiateur à condition qu'un nombre suffisant de paquets soient reçus de la part des noeuds assistants, mais sans requérir la réception de l'ensemble des 15 messages provenant de la totalité des noeuds assistants. Ce système protège notre solution contre la compromission ou le refus de collaborer des noeuds assistants. En outre, il permet de ne pas imposer une livraison fiable pour chaque connexion entre un proxy 20 et le répondeur. L'initiateur transmet (244) à chaque proxy le fragment de secret qui lui est assigné. Avantageusement, chaque message est envoyé de façon 25 sécurisée, en utilisant une association de sécurité basée sur une clé symétrique (kl_pi) entre l'initiateur et chaque proxy. A la réception de son fragment de secret, le proxy chiffre le fragment et signe le résultat en 30 utilisant sa clé privée. Le proxy avantageusement chiffre son fragment en utilisant la clé publique du serveur qui correspond à son identifiant cryptographiquement généré, tel que communiqué par l'initiateur dans une phase précédente. Puis, chaque proxy transmet (246) au répondeur un message signé contenant le fragment de secret qui lui a été assigné, et chiffré. Après avoir reçu un nombre suffisant de 10 fragments, le répondeur peut retrouver le secret x original et reconstruire le secret x de l'initiateur. Le répondeur génère aléatoirement (248) à son tour un secret y et le transmet (249) dans un message 15 aux proxies. Le message est également construit à partir du secret x reconstruit par le répondeur. Les proxies supportent la charge de calcul nécessaire pour vérifier le message reçu de la part du répondeur et pour le transmettre (250) ensuite à l'initiateur. 20 Avantageusement, chaque proxy transmet à l'initiateur un message protégé au moyen de clés symétriques kI_pi partagées entre l'initiateur et chaque proxy. Afin de préserver la confidentialité de y, ce 25 dernier est chiffré avec le secret x préalablement transmis au répondeur par l'initiateur. Avantageusement, afin d'assurer à l'initiateur que le secret x a bien été reçu, le secret y chiffré 30 par x est muni d'un « Message Authentication Code ou (MAC) en anglais » calculé avec x comme clé. Ce message MAC assure à l'initiateur que le message chiffré reçu a bien été envoyé par une entité ayant connaissance de la valeur x. Dans une variante de l'invention, le récepteur envoie à tous les proxies un message contenant y encrypté par x, muni d'un MAC calculé à partir de x, le tout étant signé au moyen de la clé privée du récepteur. A réception de ce message, les proxies vérifient la validité de la signature du récepteur et, en cas de message valide, font suivre à l'initiateur le message reçu sans sa signature, c'est-à-dire : y encrypté par x, muni d'un MAC calculé à partir de x, ce message étant encrypté au moyen de la clé symétrique Dans une autre variante de l'invention, le récepteur envoie à un ou plusieurs proxies le message contenant y encrypté par x, muni d'un MAC calculé à 20 partir de x, le tout étant signé au moyen de la clé privée du récepteur. Le ou les proxies auxquels le récepteur a envoyé le message vérifient la validité de la signature du récepteur et, en cas de message valide, font suivre à l'initiateur le message reçu 25 sans sa signature, c'est-à-dire : y encrypté par x, muni d'un MAC calculé à partir de x, ce message étant encrypté au moyen de la clé symétrique Dans une phase suivante (260), la méthode procède 30 au calcul de la clé de session. Les deux entités initiateur (202) et répondeur (206) calculent la clé finale en fonction des deux secrets x et y échangés et de paramètres additionnels. Avantageusement à la fin de l'échange, le 5 répondeur retourne un message à l'initiateur contenant les proxies qui ont réellement et de manière fiable coopéré durant l'échange des secrets, afin de lui permettre d'affiner sa future sélection des participants et de révoquer les noeuds malicieux. 10 Dans une variante d'implémentation, les messages (232) de l'initiateur aux proxies contenant l'identité du répondeur et la preuve de représentativité sont regroupés avec les messages (244) respectifs n aux 15 proxies contenant les valeurs des fragments de secret (xl, xn). La figure 3 déroule les étapes (300) opérées par la méthode de l'invention pour établir une session 20 dans une implémentation préférentielle. A l'étape (302), une requête pour établir une connexion sécurisée entre une entité source et une entité cible est émise. La requête peut être à l'initiative de l'entité contrainte en ressources ou à 25 l'initiative d'un serveur distant vers une entité contrainte en ressource. L'émission de la requête déclenche la phase (220) précédemment décrite afin que l'initiateur et le répondeur établissent les paramètres de connexion pour leur session. 30 A l'étape (304), le modèle initial de secret x est décomposé en une pluralité n de valeurs (x1, , xn). A l'étape (306), les n valeurs de secret (xl, , xn) sont assignées à n proxies (P1, Pn) sélectionnés. Chaque proxy reçoit la valeur de secret qui lui est assignée de manière encryptée avec une clé symétrique. Les proxies sont informés de l'identité du 10 répondeur soit à l'étape (306), soit comme décrit plus haut dans une étape initiale (230) où ils reçoivent la preuve de leur représentativité auprès du répondeur. A l'étape suivante (308), les n valeurs de secret 15 sont chiffrées et signées par les proxies. Chaque valeur chiffrée/signée est transmise au répondeur à l'étape suivante (310). 20 L'étape (312) consiste à reconstruire le secret x à partir des valeurs de secret reçues des proxies. Le procédé attend de recevoir suffisamment de valeurs pour récupérer la valeur de secret initiale x et passer à l'étape suivante. 25 A l'étape (314), un secret y est généré aléatoirement par le répondeur et est chiffré et signé pour le transmettre aux proxies avec le secret x. 30 A l'étape (316), si la signature reçue par les proxies est vérifiée et validée, le secret y est transmis à l'initiateur (étape 318), sinon le procédé s'arrête. L'étape (320) consiste à calculer la clé de 5 session finale en fonction des deux secrets (x,y) échangés. La Figure 4 montre les procédures exécutées entre les entités source, cible et assistante du réseau de 10 la figure 1 dans une variante d'implémentation de l'invention appliquée au protocole « HIP BEX ». Le mécanisme connu de puzzle spécifié dans le protocole HIP BEX est maintenu afin de protéger le répondeur contre les attaques d'épuisement de ressources lors de 15 l'exécution du protocole. Dans une première phase 420 similaire à la phase 220 décrite en référence à la figure 2, l'initiateur (402) envoie un premier message 422 au répondeur (406) 20 pour obtenir l'association HIP et l'informer de la technique de coopération supportée pour l'échange de clé. Le répondeur répond par un message 424 pour commencer l'échange du protocole. Le message 424 du répondeur contient l'identifiant du répondeur, c'est-25 à-dire sa clé publique KR, et un puzzle composé d'un défi cryptographique que l'initiateur doit résoudre avant de continuer le protocole d'échange. Le niveau de difficulté du puzzle peut être ajusté en fonction du niveau de confiance de l'initiateur et ses 30 capacités actuelles en termes de ressources. L'échange de puzzle dans le protocole HIP est un moyen de défense pour protéger le répondeur contre les attaques par déni de service. Ce dernier demeure passif jusqu'à la réception d'une réponse valide de la part de l'initiateur. L'initiateur calcule la solution du puzzle reçu. Puis, l'initiateur transmet (426) la solution aux n proxies (404-1, 404-n) dans des messages 1211 ... I21n. Ces messages sont également utilisés pour transmettre les n fragments du secret x aux n proxies. Chaque connexion entre l'initiateur et un proxy est une connexion sécurisée par une clé symétrique Chaque proxy à réception de son message respectif, le crypte au moyen de la clé publique KR du récepteur et le transmet (428) au répondeur dans un 15 message I22i. A la réception d'un message I22i, le répondeur vérifie la validité de la solution de puzzle. En l'absence d'une solution correcte, le message correspondant est rejeté. Si une solution correcte 20 s'y trouve, le répondeur poursuit l'échange du protocole. Il envoie (430) un message R2li à chaque proxy contenant son secret y encrypté avec la clé secrète x, en y joignant une valeur d'authentification « Message Authentication Code 25 (MAC) » calculée sur le message avec la clé x. Cette valeur d'authentification permet à l'initiateur de s'assurer que la valeur reçue provient bien du répondeur, et aussi que le répondeur a bien reçu la clé x initialement transmise. 30 En réception du message (430) du répondeur, le proxy vérifie son intégrité et transmet (432) d'une façon sécurisée le contenu à l'initiateur dans un message R22i. Dès qu'un nombre approprié, typiquement supérieur à n/2, du même contenu est reçu de la part des différents proxies, l'initiateur s'assure de la validité du message transmis par le répondeur. Consécutivement, il vérifie le MAC afin de s'assurer que le répondeur a obtenu le même secret x et de vérifier l'intégrité du message. Une fois cette intégrité validée, l'initiateur déchiffre le secret y afin de finaliser la mise en place de la clé de session principale. Avantageusement, la clé finale « Master Key ou (MK) en anglais » établie entre l'initiateur et le répondeur est calculée comme suit: MK: = H ((P I HIT-I I HIT-R I x I y) où : - H () est une fonction de hachage cryptographique unidirectionnelle ; - P est un paramètre du puzzle, inclus afin d'assurer la fraîcheur de la clé de session ; - HIT-I est le Host Identity Tag de l'initiateur, c'est-à-dire un hash tronqué de son identifiant cryptographiquement généré ; - HIT-R est le Host Identity Tag du répondeur ; et - x et y sont les valeurs secrètes respectives de l'initiateur et du répondeur. L'homme de l'art appréciera que des variations peuvent être apportées sur la méthode telle que décrite de manière préférentielle, tout en maintenant les principes de l'invention. Ainsi, il est possible que l'établissement de la connexion entre une entité contrainte en ressources et un serveur non contraint soit à l'initiative de ce dernier. Le premier message envoyé (222, 422) est par le serveur, et ensuite la méthode suit les étapes décrites précédemment. Dans une variante où les entités contraintes sont dans le contexte de l'Internet des Objets, les identités des noeuds devant faire office de proxies peuvent être fournies de façon sécurisée par une infrastructure de résolution de confiance. Ils 15 rendent également possible la mise en relation simple de noeuds basés sur des technologies différentes, telles que des tags actifs, des noeuds IP, des noeuds non-IP, dès lors que les identifiants cryptographiques sont utilisés à un niveau supérieur à la couche IP. 20 La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut 25 être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tells supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des 30 disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read/Write (CD-R/W) and DVD). Ainsi la présente description illustre une implémentation préférentielle de l'invention, mais 5 n'est pas limitative. Un exemple a été choisi pour permettre une bonne compréhension des principes de l'invention, et une application concrète, mais il n'est en rien exhaustif et doit permettre à l'homme du métier d'apporter des modifications et variantes 10 d'implémentation en gardant les mêmes principes. REVENDICATIONS1. Dans un réseau de communication comprenant une pluralité d'entités communicantes, une méthode pour éta- blir une clé de session entre une entité source et une entité cible, la méthode comprenant les étapes de: - générer (304) un secret x pour l'entité source, le secret comprenant n valeurs de secret (xl,xi,xn) ; assigner (306) chaque valeur de secret (xi) à une entité assistante (Pi) parmi la pluralité d'entités communicantes; - chiffrer et signer (308) par chaque entité assistante la valeur de secret assignée (xi) ; authentifier (312) l'entité source à réception par l'entité cible d'une ou plus valeurs de secret (xl,xi,xn) chiffrées et signées ; - générer (314) un secret y chiffré et signé pour l'entité cible ; authentifier (316) l'entité cible à réception par au moins une des n entités assistantes (P1,Pi,Pn) de la valeur de secret y chiffré et signé ; et générer (320) une clé de session entre l'entité source et l'entité cible à réception par l'entité source de la valeur de secret authentifiée. 2. La méthode selon la revendication 1 comprenant après l'étape (308) l'étape de transmettre (246,310) à l'entité cible les valeurs de secret chiffrées et signées. 3. La méthode selon la revendication 1 ou 2 comprenant après l'étape (314) l'étape de transmettre (249) à la pluralité d'entités assistantes les valeurs de secret x et y chiffrées et signées. 4.La méthode selon l'une quelconque des revendications 1 à 3 comprenant après l'étape d'authentification (316) l'étape de transmettre (250,318) la valeur de secret y à l'entité source. 5. La méthode selon l'une quelconque des revendications 1 à 4 comprenant avant l'étape (304) de générer un secret x, l'étape de détecter (302) une requête pour établir une connexion sécurisée entre l'entité source et l'entité cible. 6.La méthode selon la revendication 5 comprenant après l'étape (302) de détection de requête, l'étape (220) de définir un protocole d'échange de données cryptographique entre l'entité source et l'entité cible. 7. La méthode selon la revendication 6 dans laquelle l'étape (220) de définir un protocole d'échange de données cryptographique comprend des étapes d'échange de messages entre les entités source et cible, les messages comprenant au moins des informations relatives à la sécurité supportée par chaque entité source et cible, à l'identité des en- tités source et cible, aux algorithmes cryptogra- phiques supportés par les entités source et cible, et aux méthodes d'établissement de clé. 8.La méthode selon l'une quelconque des revendications 1 à 7 comprenant avant l'étape (306) d'assigner, l'étape de sélectionner n entités as- sistantes (P1,Pi,Pn), chaque entité assistante (Pi) étant moins contrainte en ressources que l'entité source. 9. La méthode selon l'une quelconque des revendica- Lions 1 à 8 comprenant après l'étape (306) d'assigner, l'étape (232) de transmettre aux entités assistantes, des éléments de preuve de leur représentativité de l'entité source. 10. La methode selon la revendication 9 comprenant avant l'étape (312) d'authentification, l'étape (234) de transmettre à l'entité cible lesdits éléments de preuve. 11. La méthode selon l'une quelconque des revendica- tions 7 à 10 dans laquelle le système d'établissement de clé est appliqué au protocole HIP BEX (Base Exchange). 12. Un système pour établir une clé de session entre une entité source et une entité cible dans un réseau de communication comprenant une pluralité d'entités communicantes, le système comprenant des moyens pour mettre en oeuvre les étapes de la mé- thode selon l'une quelconque des revendications 1 à 11. 13. Le système selon la revendication 12 où l'entité source est contrainte en ressource et l'entité cible est un serveur distant non contraint en ressource. 14. Un produit programme d'ordinateur, ledit pro- gramme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes de la méthode selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un or- dinateur.