SESSION

Domaine de l'invention

L'invention concerne le domaine des communica- tions réseau et en particulier les communications cryptées entre les entités d'un réseau global de corn- munication . 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 œuvre entre une entité source et une entité cible. Ce protocole a pour but de dériver une clé de session, mais aussi d'établir 1 ' 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 1 ' 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 dont son identifiant est issu.

Plusieurs protocoles d'échange de clé authentifié sont connus tels que ceux listés par exemple ci-après.

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, 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 Diffie- Hellman de génération et d'échange de clés, ce qui le rend coûteux en ressources.

Le protocole « Internet Key Exchange Cryptographically Generated Addresses ou (IKE-CGA) en anglais » décrit dans le papier de [J. Laganier, G. Monténégro, A. Kukec, "Using IKE with IPv6 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 à 1 ' authentification au moyen d'adresses cryptographiquement générées. Cette solution met en œuvre des identifiants générés cryptographiquement dans le cadre de la sécurisation d'un échange Diffie-Hellman standard, et reste un choix coûteux en ressources. Le brevet EP 2 290 895 Al décrit une solution d'établissement d'association de sécurité entre deux nœuds 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 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 dans le premier et le second messages de cette solution .

Une autre approche est définie par Mâche et al. dans le papier de J. Mâche, C.-Y. Wan, and M. Yarvis, "Exploiting heterogeneity for sensor network security, " in Proceedings of IEEE Communications Society Conférence on Sensor, Mesh and Ad Hoc Communications and Networks, June 2008, pp. 591-593. La solution prévoit la transmission sécurisée de 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 nœud de collecte, et ensuite du nœud de collecte au serveur distant. Le premier segment est sécurisé au moyen d'algorithmes symétriques alors que le second segment s'appuie sur de la cryptographie asymétrique. Le nœud 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 communication sécurisée de bout en bout entre le capteur et le serveur distant. En effet, aucune confidentialité n'est assurée vis-à-vis du nœud de collecte .

Les protocoles et solutions cités bien que 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 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 connu sous la dénomination de l'Internet des Objets (IDO), comprend des entités (souvent appelées nœuds) à faible énergie et puissance de calcul qui doivent employer des identifiants cryptographiquement générés pour communiquer avec des entités distantes pouvant avoir des ressources puissantes.

Le protocole « HIP Diet Exchange ou (HIP-DEX) en anglais» décrit dans le papier de R. Moskowitz, "HIP Diet EXchange (DEX)", IETF work in progress draft- moskowitz-hip-rg-dex-05, March 2011, vise à être utilisé par des nœuds à 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 cryptographie à courbes elliptiques, l'emploi de valeurs Diffie-Hellman statiques, et de primitives 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- 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 nœud sont conduits à partir de la même valeur publique, générée par le nœud une seule fois et lui servant également à 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 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. II 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é. La présente invention répond à ce besoin.

Résumé de l'invention Un objet de la présente invention est d'offrir une méthode d'échange de clés dans le contexte de communications dont les identifiants sont générés cryptographiquement .

Un autre objet de l'invention est de permettre l'emploi d'identifiants cryptographiquement générés par des nœuds fortement contraint en ressources. Avantageusement, une méthode d'échange de clé authentifié s 'appuyant sur ces identifiants est proposée .

Un autre objet de la présente invention est de permettre la génération d'un secret partagé entre deux nœuds à identifiants cryptographiquement générés au moyen d'opérations de cryptographie asymétrique sans faire usage du protocole Diffie-Hellman .

Avantageusement, le mécanisme sur lequel la présente invention s'appuie peut être mis en œuvre de manière distribuée, en utilisant l'assistance de nœuds voisins auxquels sont déléguées les opérations les plus consommatrices de cryptographie asymétrique.

Avantageusement, la présente invention étend à des nœuds fortement contraints en ressources, l'usage 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.

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 nœuds assistants, un nœud fortement contraint en ressources, des opérations cryptographiques les plus exigeantes en ressources, tout en assurant que les nœuds 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 nœuds d'un réseau identifiés cryptographiquement.

Un autre objet de la présente invention est d'augmenter la durée de vie de nœuds fonctionnant sur batterie tels que des capteurs.

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 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 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 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- cret comprenant n valeurs de secret (χΐ,χί,χη) ;

- assigner chaque valeur de secret (xi) à une enti ^¬ té assistante (Pi) parmi la pluralité d'entités com ^¬ municantes ;

chiffrer et signer par chaque entité assistante la valeur de secret assignée (xi) ;

authentifier l'entité source à réception par l'entité cible d'une ou plus valeurs de secret (χΐ,χί,χη) chiffrées et signées ;

- générer un secret y chiffré et signé pour l'entité cible ;

authentifier l'entité cible à réception par au moins une des n entités assistantes (ΡΙ,Ρί,Ρη) de la valeur de secret y chiffré et signé ; et

- générer 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. 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 vont apparaître 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 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 figure 1 dans une implémentation avantageuse de 1 ' invention;

La Figure 3 montre les étapes opérées par la méthode de l'invention pour établir une session ;

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 1 ' invention . Description détaillée de l'invention

La figure 1 illustre un environnement de réseau 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 é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 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 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 œuvre des protocoles moins coûteux en énergie comme celui de 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 (IdO) . 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 contexte limité (un seul protocole employé, par exemple ZigBee et/ou un seul scénario ciblé, par 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 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 des schémas de communication décentralisés, tout en mettant en œuvre des mécanismes autonomes.

La présente invention peut être avantageusement appliquée dans l'environnement de la figure 1 entre 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. 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), 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 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 nœuds au voisinage, ces derniers peuvent être évalués localement ou par un serveur 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 nœud a manifesté 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 nœud 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 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 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 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 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 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 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 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 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, 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é 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 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é 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 œuvre 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 à 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 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é 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.

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 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 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 nœuds assistants, mais sans requérir la réception de l'ensemble des messages provenant de la totalité des nœuds assistants. Ce système protège notre solution contre la compromission ou le refus de collaborer des nœuds assistants. En outre, il permet de ne pas imposer une livraison fiable pour chaque connexion entre un proxy 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 sécurisée, en utilisant une association de sécurité basée sur une clé symétrique ( k i_ _P i ) 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 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 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 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.

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 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é par x est muni d'un « Message Authent icat ion 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 ^_ _Ρ1 .

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é à 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 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 k i_ _P i .

Dans une phase suivante (260), la méthode procède 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 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 nœuds malicieux.

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 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 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 à 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.

A l'étape (304), le modèle initial de secret x est décomposé en une pluralité n de valeurs (xl, ... , xn) .

A l'étape (306), les n valeurs de secret (xl, ... , xn) sont assignées à n proxies (PI, ... , 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 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 sont chiffrées et signées par les proxies.

Chaque valeur chiffrée/signée est transmise au répondeur à l'étape suivante (310). 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.

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. 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 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 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 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) 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- à-dire sa clé publique K _R , 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 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 I21i ... I21 _n . 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 k];_pi.

Chaque proxy à réception de son message

respectif, le crypte au moyen de la clé publique K _R du récepteur et le transmet (428) au répondeur dans un message 122 ±.

A la réception d'un message 122±, 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 s'y trouve, le répondeur poursuit l'échange du protocole. Il envoie (430) un message R21i à chaque proxy contenant son secret y encrypté avec la clé secrète x, en y joignant une valeur

d'authentification « Message Authent icat ion Code (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. 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 R22±. 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 | HIT-R | x | 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 rendent également possible la mise en relation simple de nœuds basés sur des technologies différentes, telles que des tags actifs, des nœuds IP, des nœuds non-IP, dès lors que les identifiants cryptographiques sont utilisés à un niveau supérieur à la couche IP.

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 ê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 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 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 d ' implémentation en gardant les mêmes principes.