FR 3004041 A1 20141003 FR 1352812 A 20130328 3004041 PROCEDE ET DISPOSITIF D'ETABLISSEMENT DE CLES DE SESSION Domaine de l'invention L'invention concerne le domaine des communications réseau et en particulier celui des communications cryptées entre les entités d'un réseau. Etat de la Technique L'établissement d'une clé de session entre deux entités d'un réseau de communication est un pré-requis fondamental à la mise en oeuvre de la grande majorité des services cryptographiques destinés à sécuriser les échanges entre ces entités. Ainsi, la protection des données échangées contre des attaques visant à les modifier ou simplement à en prendre connaissance s'appuie en général sur des primitives cryptographiques symétriques, dans lesquelles les entités communiquant l'une avec l'autre utilisent la même clé lors de l'envoi (chiffrage, protection d'intégrité) et de la réception (déchiffrement, vérification de l'intégrité) d'un message. L'établissement d'une clé de session est une procédure destinée à intervenir à de nombreuses reprises dans la durée de vie d'une entité communicante. Une nouvelle clé symétrique doit être utilisée pour tout échange sécurisé avec tout nouveau correspondant. Ces correspondants sont d'autant plus nombreux que l'entité participe d'un scénario favorisant les interactions entre membres, par exemple de type réseau de capteurs (Wireless Sensor Network, WSN), Machine à Machine (M2M) ou Internet des Objets (loT). Par ailleurs, une clé de session est caractérisée par une 2 3004041 durée de vie limitée, et doit régulièrement être rafraîchie. Ainsi, la procédure mise en oeuvre pour établir une clé de session est particulièrement importante, et requiert un design soigné. Plusieurs paramètres sont à considérer pour juger de la qualité 5 d'un protocole d'établissement de clé de session. Premièrement, la sécurité du protocole doit être garantie. Ainsi, la confidentialité de la clé établie et l'authentification mutuelle des deux correspondants doivent être assurés. S'ajoutent d'autres paramètres de sécurité, tels que la protection contre les attaques par déni de service qui protège les entités impliquées 10 dans l'exécution du protocole contre des attaques visant à épuiser leurs ressources énergétiques et/ou ressource système. Deuxièmement, le protocole d'établissement de clé de session doit être efficace en termes de bande passante requise et de consommation énergétique, et en particulier du point de vue des calculs cryptographiques mis en oeuvre. 15 Ce deuxième critère est particulièrement important lorsque le protocole d'établissement de clé de session doit être mis en oeuvre par des entités ne disposant que de faibles ressources énergétiques, telle une batterie, ou que d'une faible capacité de calcul et/ou de mémoire. Enfin, le protocole peut offrir des fonctionnalités supplémentaires, telles que 20 l'interopérabilité des mécanismes d'authentification entre deux noeuds le mettant en oeuvre ou la possibilité d'un contrôle centralisé sur l'échange des clés et/ou la possibilité d'une définition centralisée de politiques de sécurité accompagnant les clés établies. 25 Il s'est développé principalement trois approches pour établir des clés de session entre deux noeuds. La première famille est le transport de clé, connu sous l'anglicisme "key transport" qui consiste à transporter de manière sécurisée par encryption, une ou plusieurs valeurs secrètes depuis un des deux participants d'une session jusqu'à l'autre. Ces transports de valeurs secrètes peuvent soit s'effectuer dans une seule direction et ce mode est 3 3004041 connu selon l'anglicisme "one-pass key transport protocol" soit s'effectuer dans les deux directions, et ce mode est connu alors sous l'anglicisme "two-pass key transport protocol". La clé de session est ensuite dérivée à partir de ces valeurs secrètes. 5 La deuxième famille de solutions d'établissement de clés de session est l'agrément de clé, connu sous l'anglicisme "key agreement". Cette approche consiste en un échange de valeurs publiques entre les deux noeuds à partir desquelles une clé de session commune est recouvrée par les deux entités participant à l'échange sans que les 10 valeurs publiques échangées n'aient à être déchiffrées. Le principal protocole connu de « key agreement » est le protocole Diffie-Hellman. Sur le plan des ressources consommées, principalement au niveau de l'énergie consommée en opérations cryptographiques, le « key agreement » est une approche coûteuse. 15 Une troisième famille de solutions d'établissement de clé de session est la distribution de clé, connu sous l'anglicisme "key distribution". Dans cette approche, une troisième entité souvent nommée « tiers de confiance » intervient pour fournir aux deux autres participants soit une valeur secrète qui leur permet de calculer la clé de session, soit 20 la clé de session elle-même. Cependant, la distribution de clé fait également intervenir des échanges directs entre les deux participants. En effet, ceux-ci doivent faire la preuve de leur implication dans le protocole, établir la fraîcheur des messages qu'ils envoient et prouver leur connaissance du secret établi. La distribution de clé bien qu'étant une 25 solution simple à mettre en oeuvre, légère en termes d'opérations cryptographiques requises et d'énergie consommée, présente des inconvénients non encore résolus par les solutions existantes. Des solutions de 'distribution de clé' bien connues sont celles de 30 Needham et Schroeder, ou bien le protocole Kerberos ou encore l'approche MIKEY-Ticket. 4 3004041 Le protocole de transport de clés de Needham et Schroeder, présenté dans le document « Using encryption for authentication in large networks of computers », Communication of the ACM, volume 21, number 12, 1978 contient cinq échanges de messages entre deux entités, un 5 initiateur (I) et un répondeur (R) qui partagent, chacun, une clé de chiffrement avec un tiers de confiance (TC). L'échange des cinq messages est représenté sur la figure 1. Un des problèmes majeurs du protocole de Needham et Schroeder est une attaque par usurpation d'identité par un attaquant se faisant passer pour l'initiateur et rejouant le 10 troisième message (Message3) entre l'initiateur et le répondeur. L'attaquant, qui peut connaitre la clé générée par le tiers de confiance, peut alors déchiffrer le quatrième message et usurper la session en envoyant le dernier message. Le protocole normalisé Kerberos décrit dans le document de Kohl 15 et Neuman « The Kerberos network authentication service », septembre 1993, est illustré sur la figure 2 et se base sur l'échange de quatre messages. Les deux premiers messages sont échangés entre l'initiateur et le tiers de confiance. Les deux derniers messages sont échangés entre l'initiateur et le répondeur. Un inconvénient du protocole Kerberos est qu'il 20 n'est pas symétrique vis-à-vis de l'initiateur et du récepteur. Le tiers de confiance n'a aucune assurance que le récepteur a bien été contacté ou a bien accepté de participer à la transaction sécurisée. De fait, le protocole Kerberos est limité dans ses applications et plutôt destiné à permettre l'accès depuis un client initiateur à une ressource supposée ne pas être 25 sujette à des comportements malicieux, comme par exemple une imprimante ou un serveur de fichiers. Une amélioration connue du protocole de Needham et Schroeder est le protocole d'Otway et Rees illustré en figure 3 et décrit dans le document des auteurs « Efficient and timely mutual authentication », 30 1987. Cependant, ce protocole présente toujours l'inconvénient que le tiers de confiance n'a d'interaction directe qu'avec un seul des deux 5 3004041 participants, ici le répondeur. Le brevet WO 2009/070075 Al de Blom et al. Intitulé « Key management for secure communication » présente un procédé pour établir des clés de session pour des communications sécurisées 5 entre deux entités. Le procédé s'appuie sur le protocole de distribution de clés MIKEY-Ticket spécifié dans la RFC 6043 de Mattsson et Tian, « MIKET-Ticket : Ticket-based modes of key distribution in Multimedia Internet KEYing (MIKEY) ». La gestion de clés est basée sur un service de confiance de gestion de clés centralisé où l'initiateur et le répondeur 10 partagent chacun une clé commune avec un tiers de confiance. Or de par son design, ce protocole peut être la cible d'attaques par déni de service. L'homme du métier connait les différentes formes des attaques par déni de service. Un attaquant peut réaliser un déni de service en exploitant les erreurs d'implémentations dans les protocoles de 15 communication, par exemple, si le protocole utilisé est implémenté de façon à bloquer les noeuds lorsqu'ils reçoivent des données inconnues. Un attaquant pourra alors faire une attaque par déni de services en envoyant des messages contenant des champs erronés au répondeur, sa cible. Une autre manière de réaliser un déni de service est d'entamer une 20 communication avec la cible puis d'arrêter l'envoi de messages aux fins de bloquer la cible dans un état d'attente d'acquittement et de saturer sa pile de réception. Enfin, le déni de service peut être distribué en utilisant plusieurs attaquants au même temps aux fins de saturer la cible le plus rapidement possible et de complexifier le retraçage de l'attaquant. 25 Ainsi, les approches connues bien qu'offrant des solutions alternatives pour établir des clés de session, de par leurs inconvénients ne répondent pas à l'ensemble des besoins de sécurité attendus pour un protocole d'établissement de clés de session. 30 L'invention proposée permet de répondre à ces besoins. 6 3004041 Résumé de l'invention Un objet de la présente invention est de proposer un procédé 5 d'établissement de clés de session sûr et protégé contre les attaques par déni de service. Avantageusement, l'invention offre autant à un noeud initiateur qu'à un noeud répondeur, une protection contre les attaques par déni de service. 10 Un autre objet de la présente invention est de proposer un procédé d'établissement de clés de session efficace en termes de ressources consommées. Ainsi le procédé de l'invention permet l'établissement d'une session en quatre ou cinq échanges de messages et s'appuie sur l'utilisation de primitives cryptographiques symétriques. 15 Avantageusement, la présente invention s'implémentera dans les domaines de la sécurité des communications machine-à-machine (M2M), ou dans le contexte des réseaux de noeuds contraints en ressources comme ceux de capteurs et/ou actionneurs, qui sont parmi les noeuds les plus contraints en ressources et pouvant être amenés à devoir établir 20 dynamiquement des clés de session. Pour obtenir les résultats recherchés, un procédé, un dispositif et un produit programme d'ordinateur sont proposés. 25 En particulier, dans un réseau de communication comprenant une pluralité d'entités communicantes, un procédé pour établir une clé de session entre une entité source (I) et une entité cible ( R), l'entité source partageant avec une entité de confiance tierce (TC) une première clé source Kle pour le chiffrement de données et une deuxième clé source Kia 30 pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une 7 3004041 première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le procédé comprend les étapes de: recevoir à l'entité de confiance tierce, un message de l'entité source pour 5 l'établissement d'une session avec l'entité cible, le message contenant au moins des identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé source Kla ; générer une paire KIR de clés (KiRa , KiRe) pour l'entité source et pour 10 l'entité cible ; encrypter la paire KIR de clés (KiRa , KiRe) par la première clé source Kle et par la première clé cible KRe; envoyer à l'entité cible un message contenant au moins la clé KIR encryptée et un code d'authentification basé sur la deuxième clé cible 15 KRa; recevoir de l'entité cible, un message contenant au moins les identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé cible KRa; et envoyer à l'entité source, un message contenant au moins la clé KIR 20 encryptée et un code d'authentification basé sur la deuxième clé source Kla. Avantageusement, la clé source Kie pour le chiffrement de données et la clé source Kia pour le code d'authentification sont dérivées d'une clé 25 initiale obtenue après une étape d'authentification de l'entité cible auprès de l'entité de confiance tierce. Dans une variante, le message reçu de l'entité source comprend de plus un nonce source (Ni) pour prouver la fraicheur du message de 30 l'entité source. 8 3004041 Dans une autre variante, l'étape de générer la clé KIRa pour l'entité source comprend les étapes de concaténer la clé KIRa aux identifiants de l'entité cible, de l'entité de confiance tierce, et du nonce NI, et de chiffrer l'ensemble concaténé avec la première clé cible KRe. 5 Avantageusement, le message envoyé à l'entité cible comprend de plus le nonce (Ni) et le code d'authentification basé sur la deuxième clé cible KRa est calculé sur le nonce. 10 Avantageusement, le message reçu de l'entité cible comprend de plus le nonce source (Ni) et un nonce cible (NR) pour prouver la fraicheur du message cible. Dans une variante d'implémentation, l'étape de calculer un code 15 d'authentification en utilisant la deuxième clé cible KRa, les identifiants, les nonces source et cible (Ni, NR) et le code d'authentification reçu basé sur la deuxième clé cible KRa et l'étape de vérifier si le code d'authentification calculé est égal au code d'authentification reçu. 20 Avantageusement, le message envoyé à l'entité source comprend de plus les nonces source et cible (Ni, NR). Avantageusement, les identifiants des entités source et cible sont soit des adresses IPv6, des adresses MAC ou des URL. 25 Selon les variantes, le nonce est soit une information d'horodatage, un nombre aléatoire ou un compteur. Dans une autre variante, le message envoyé par l'entité de 30 confiance tierce à l'entité cible contient de plus une clé chiffrée par les clés Kie et Kia et où le message reçu de l'entité cible et le message 9 3004041 envoyé à l'entité source sont un seul message envoyé de l'entité cible à l'entité source. Dans une autre variante, le procédé comprend de plus une étape 5 d'envoyer un message de l'entité source à l'entité cible qui contient les identifiants de l'entité source et de l'entité cible, les nonces source et cible (Ni, NR) et un code d'authentification calculé avec la clé KIRa partagée entre l'entité source et l'entité cible. 10 L'invention concerne de plus un système pour établir une clé de session entre une entité source et une entité cible, l'entité source partageant avec une entité de confiance tierce une première clé source Kle pour le chiffrement de données et une deuxième clé source Kia pour calculer un code d'authentification de message de l'entité source, l'entité 15 cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le système comprenant des moyens pour mettre en oeuvre toutes les étapes du procédé revendiqué. 20 L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer les étapes du procédé revendiqué lorsque le programme est exécuté sur un ordinateur. 25 Description des figures Différents aspects et avantages de l'invention vont apparaitre en 30 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 : 10 3004041 La figure 1 illustre les échanges de messages selon le procédé de Needham et Schroeder ; 5 La figure 2 illustre les échanges de messages selon le procédé de Kerberos ; La figure 3 illustre les échanges de messages selon le procédé d'Otway et Rees ; 10 La figure 4 est une représentation topologique d'une infrastructure réseau dans laquelle implémenter avantageusement l'invention ; La figure 5 montre les procédures exécutées entre les entités initiateur, 15 répondeur et tiers de confiance du réseau de la figure 4 selon le procédé de MIKEY-Ticket; La figure 6 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 4 dans une 20 implémentation avantageuse de l'invention; La figure 7 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 1 dans une variante d'implémentation de l'invention. 25 Description détaillée de l'invention 30 La figure 4 illustre un exemple d'une infrastructure de 11 3004041 communication 100 dans laquelle implémenter avantageusement l'invention. Pour des raisons de simplicité de description et non de limitation de l'invention, l'exemple de la figure 4 ne montre qu'un nombre fini d'entités (ou noeuds) et de connexions, mais l'homme du métier 5 é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 de communication (100) comprend des entités fixes ou mobiles pouvant former un réseau d'objets (102). Les entités peuvent être à fortes contraintes de ressources (102-1, 102-n) ou à moindre contrainte 10 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 15 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 oeuvre des protocoles moins couteux en énergie comme celui de l'invention. 20 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 25 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 de noeuds (102) peut être basé sur des communications 30 de niveau 2 (par exemple, 802.15.4 ou 802.11) et/ou de niveau 3 (par exemple, IP) entre les entités qui le composent. Suivant les protocoles sur 12 3004041 lesquels il s'appuie, des schémas de communications multicast ou broadcast peuvent y être employés. La présente invention peut être avantageusement appliquée dans l'environnement de la figure 4 entre deux noeuds du réseau, une entité 5 source que l'on dénomme 'initiateur' et une entité cible que l'on dénomme 'répondeur'. Les deux entités ont besoin d'établir une association de sécurité entre elles. Un serveur central de distribution de clés (106) que l'on dénomme tiers de confiance est responsable de l'authentification des noeuds. Il peut être distant et accessible via un réseau de communication 10 tierce (104) qui peut être un réseau cellulaire ou le réseau Internet. Le tiers de confiance stocke des données cryptographiques nécessaires pour l'authentification de chacun des noeuds. En opération, chaque noeud initiateur et répondeur s'authentifie auprès du serveur central en utilisant ses crédentiels propres, des 15 modèles d'identités et des méthodes d'authentification indépendantes les plus en accord avec chacun leurs propres spécificités et contraintes. Ainsi, deux noeuds peuvent par exemple établir une clé de session et l'associer à leurs identités respectives alors que ces dernières sont respectivement validées au moyen d'une carte à puce pour l'un et d'une 20 authentification biométrique pour l'autre. Le serveur de confiance distribue une même clé de session à deux noeuds souhaitant établir entre eux une association de sécurité, permettant des authentifications décorrélées pour chaque noeud, ainsi qu'un contrôle centralisé sur l'établissement de clés et/ou sur les politiques qui accompagnent ces dernières. 25 La figure 5 montre les procédures exécutées selon le protocole connu de Mikey-Ticket entre un noeud initiateur (I), un noeud répondeur (R) et un tiers de confiance (TC) du réseau de la figure 4. Pour faciliter la compréhension de l'invention, des notations 30 identiques sont utilisées pour décrire les figures suivantes 5 à 7. Ainsi, par la suite : 13 3004041 - Datai, Data2, ... etc désignent respectivement la concaténation des données dans les messages 1, 2, ... etc. L'homme du métier appréciera que la présente invention ne se limite pas à l'ordre indiqué à titre d'exemple dans la description des messages pour les données 5 concaténées. Ainsi, pour un même message, les transmissions des mêmes données sous la forme (Datai, Data2) et (Data2, Datai) sont équivalentes. - E{K, (Datai, Data2, ...)} désigne le chiffrement des données concaténées (Datai, Data2, ...) avec un algorithme de chiffrement utilisant 10 une clé K. - MAC{K, (Datai, Data2, ...)} désigne le code d'authentification de message « Message Authentication Code » (MAC) sur les données concaténées (Datai, Data2, ...) en utilisant une clé K. 15 Comme il a été expliqué précédemment, le protocole MIKEY-Ticket a été défini pour étendre le protocole MIKEY par l'utilisation d'un tiers de confiance et se base sur l'échange de six messages entre les trois entités initiateur (I), répondeur (R) et tiers de confiance (TC). Un noeud initiateur envoie au tiers de confiance, un premier 20 message sous forme d'une requête d'initialisation « Request_init ». La requête contient un code d'authentification MAC qui est calculé avec sa clé « Kla ». A la réception de ce premier message, TC vérifie la validité du MAC et l'authenticité des données (Datai) envoyées par l'initiateur. Ces données contiennent principalement un identifiant du noeud répondeur 25 avec lequel le noeud initiateur veut établir une session, un nonce et des informations sur les algorithmes de chiffrement et de calcul de MAC supportés par l'initiateur. Le tiers de confiance génère une clé « KIR» et la transmet à l'initiateur dans un message de réponse « Request_resp ». La clé KIR est 30 chiffrée par la clé de chiffrement « Kie » de l'initiateur. Le deuxième message contient de plus un ticket « Ticket,» pour l'initiateur et un MAC 14 3004041 calculé avec la clé Kia. A la réception du message, l'initiateur vérifie la validité du MAC et récupère sa clé KIR qui va lui permettre de dériver avec le répondeur deux clés « KIR.» et « Ki% ». La clé Ki% servira à calculer des MACs alors que 5 la clé KI% permettra d'encrypter des données. L'initiateur envoie ensuite au répondeur un message « Transfert_init » qui contient son ticket « Ticket, ». Ce troisième message contient un MAC calculé avec la clé KiRa. Il est à noter qu'à ce niveau de l'exécution du protocole, le noeud 10 répondeur (R) n'a pas encore reçu la clé KIR et donc pas reçu les clés Ki% et KIRe- Par conséquent, (R) ne peut pas vérifier la validité du MAC qu'il vient de recevoir du noeud initiateur, et doit envoyer au tiers de confiance (TC) un message « Resolve_init » pour lui demander de lui communiquer la clé KIR. 15 A la réception du quatrième message, le tiers de confiance vérifie la validité du MAC du répondeur en utilisant la clé KRa. Si le MAC est valide, il envoie au répondeur la clé KIR chiffrée par la clé KRe , dans un cinquième message « Resolve_resp » . A la réception du cinquième message, le répondeur vérifie le MAC 20 calculé par le tiers de confiance et récupère la clé KIR. Une fois la clé KIR reçue, le répondeur calcule la clé KiRa et vérifie la valeur du MAC calculé par l'initiateur dans le troisième message « Transfert_init ». Si la valeur du MAC est valide, le répondeur envoie un sixième message « Transfert_resp » à l'initiateur pour accuser de la bonne réception de la 25 Clé KIR. Ainsi, comme il a déjà été discuté précédemment, le noeud répondeur ne vérifie le MAC envoyé par l'initiateur dans le troisième message, qu'après avoir échangé les quatrième et cinquième messages avec le tiers de confiance, il peut alors être la cible d'attaque par déni de 30 service. Un noeud attaquant peut bombarder le noeud répondeur avec un nombre illimité de messages de type « Transfer_init » (troisième 15 3004041 message) pour l'obliger à calculer un grand nombre de message « Resolve_init » (quatrième message) et ainsi épuiser toutes les ressources énergétiques et calculatoires du noeud répondeur. 5 La figure 6 montre les procédures exécutées entre des entités Initiateur (I), Répondeur (R) et Tiers de Confiance (TC) du réseau de la figure 4 dans une implémentation avantageuse de l'invention. Un bénéfice important de l'invention réside dans l'efficacité énergétique du procédé mis en oeuvre qui est obtenue au moyen d'un 10 nombre de messages échangés réduits. Le procédé proposé permet d'établir une communication sécurisée entre un noeud initiateur et un noeud répondeur en cinq échanges de messages dans l'implémentation de la figure 6, ou en quatre échanges de message selon l'implémentation de la figure 7. Il est à noter que le dernier message décrit pour les deux 15 exemples est échangé entre l'initiateur et le répondeur et correspond à une confirmation de clé par l'initiateur qui peut être implicite. L'échange sécurisé des données entre l'initiateur et le répondeur pouvant commencer respectivement après le quatrième et le troisième message des figures 6 et 7. 20 L'homme de l'art appréciera que les échanges de messages donnent des rôles équivalents au noeud initiateur (I) et au noeud récepteur (R) vis à vis du tiers de confiance (TC). En effet, les interactions sont du type (l)-(TC), (TC)-(l), (R)-(TC) et (TC)-(R) et offrent ainsi au tiers de confiance un meilleur contrôle de l'établissement de clé de session. 25 L'implémentation illustrée par la figure 6 peut être avantageusement appliquée lors de l'établissement d'une communication sécurisée entre deux noeuds qui ne partagent aucun secret directement, mais qui partagent, chacun, un ou plusieurs secrets avec un tiers de confiance (TC). Le tiers de confiance et l'initiateur partagent initialement 30 deux clés (Kle, Kia) Où Kle est une clé utilisée pour le chiffrement des données, et où Kia est une clé utilisée pour calculer un code 16 3004041 d'authentification de message (MAC). Kle et Kla peuvent être dérivées d'une clé maitresse à la suite d'une authentification de l'initiateur avec le tiers de confiance. De son coté, le répondeur (R) partage également une paire de clé (KRe, KRa) avec le tiers de confiance. 5 L'homme de l'art comprendra que par souci de simplification de la description de la variante de la figure 6, l'initiateur et le répondeur désignent chacun une entité simple, mais que dans un cas plus général, il peut s'agir d'un groupe de noeuds initiateurs et/ou un groupe de noeuds répondeurs utilisant des clés individuelles et/ou des clés de groupe. 10 Afin d'établir un canal de communication sécurisé avec le répondeur (R), l'initiateur (I) contacte le tiers de confiance (TC) pour qu'il leur crée une ou plusieurs clés. Pour simplifier la description du protocole, dans la variante de la figure 6, le tiers de confiance génère une seule clé KIR pour les deux noeuds (I) et (R). Puis, le tiers de confiance envoie la clé 15 KIR encryptée avec la clé Kie à l'initiateur et envoie la clé KIR encryptée avec la clé KRe au répondeur. L'intégrité des messages échangés est assurée par l'ajout de MACs, respectivement calculés au moyen des clés Kia et KRa. De manière plus détaillée en référence à la figure 6, l'initiateur 20 démarre le procédé en envoyant un premier message « Messagel » au tiers de confiance. Ce message contient les identifiants de l'initiateur (IDI), du tiers de confiance (ID-rc) et du répondeur (IDR). Il contient aussi un nonce (NI) qui sert à prouver la fraicheur de la session et à éviter les attaques par rejeu. De plus, l'initiateur rajoute au messagel un MAC 25 (MACH) calculé sur (IDI, ID-rc, IDR et Ni) avec la clé Kia. Le MAC permet de prouver au tiers de confiance l'authenticité des données reçues dans le premier message. Les identifiants (IDI,ID-rc,IDR) peuvent dépendre de la technologie utilisée et du type de réseau déployé. Ces identifiants peuvent être, par 30 exemple, des adresses IPv6, des adresses MAC ou des URL. Dans le cas particulier des réseaux IP, les identifiants IDI et ID-rc peuvent 17 3004041 correspondre respectivement à l'adresse source et à l'adresse destination du paquet IF. Le nonce peut être une information d'horodatage, un nombre aléatoire ou un compteur (numéro de séquence). Ce doit être une 5 information variable et unique dans le temps qui permet de distinguer les différentes exécutions du protocole connu de Menezes, Van Oorschot et Vanstone, décrit dans le document « Handbook of applied cryptography », chapitre 10. Le nonce peut être aussi formé par la combinaison des techniques citées précédemment. Par exemple, un nonce peut être formé 10 par une information d'horodatage et d'un nombre aléatoire. A la réception du premier message, le tiers de confiance vérifie la fraicheur du nonce N1 et utilise la clé Kia pour calculer le MAC (MACTci) sur (IDI, IDTc, IDR et Ni). Ensuite, il vérifie l'égalité entre le MACH reçu de 15 l'initiateur et son propre MAC (MACTci) afin de vérifier l'intégrité du message reçu. Si les deux valeurs sont égales, le tiers de confiance va générer un deuxième message « Message2 » pour l'envoyer au récepteur. Le tiers de confiance commence par générer une clé KIR pour l'initiateur et le répondeur. Puis il envoie au répondeur cette clé KIR 20 chiffrée par la clé de chiffrement KRe. Le message envoyé au répondeur contient de plus un MAC (MACTc2) qui permet au répondeur de vérifier l'intégrité des données reçues. Dans une implémentation préférentielle, le tiers de confiance concatène la clé KIR aux identifiants IDI et IDTc, et le nonce N1 avant de 25 chiffrer le tout avec la clé KRe pour obtenir un chiffrement E{KRe, (KIR,IDTc,IDI,N1)}. Ce deuxième message contient aussi les identifiants (IDI, IDTc, IDR), le nonce NI et le MAC (MACTc2). Le MAC (MACTc2) est calculé avec la clé KRa sur les champs suivants : IDTc, IDR, IDI, NI, et E{KRe, (KIR,IDTc,ID1,4)}. 30 A la réception du deuxième message, le répondeur vérifie l'égalité 18 3004041 entre le MACTc2 reçu et sa propre valeur de MAC (MACR2) qu'il calcule en utilisant la clé KRa. Si la valeur de MACTc2 est bonne, le répondeur déchiffre le contenu de E{KRe, (KIR,IDTc,IDI,N1)} pour récupérer la clé KIR. Le répondeur génère un nonce (NR) et calcule un MAC (MACRI) 5 avec la clé KIR sur les données d'identifiants (IDR, IDTc, ID1) et de nonce (Ni, NR). Le MAC (MACRI) sera transmis par le tiers de confiance à l'initiateur pour lui permettre de vérifier que le répondeur a bien reçu la clé KIR. Dans une première variante, le répondeur utilise les nonces (Ni, 10 NR) et la clé KIR comme entrées à une fonction pseudo-aléatoire pour générer deux clés « KiRa » et « KiRe ». La clé KiRa est utilisée pour calculer les MACs, la clé KiRe sert à chiffrer les données entre l'initiateur et le répondeur. Dans une deuxième variante, le tiers de confiance génère deux 15 clés, « KIRa » et « KIRe » pour l'initiateur et le répondeur. Ces clés seront envoyés par le tiers de confiance à l'initiateur et le répondeur et serviront respectivement à calculer des MACs et à chiffrer les données. Pour simplifier les notations, la notation KIR est par la suite utilisée pour désigner à la fois la clé servant à calculer les MACs et pour le 20 chiffrement, indépendamment des méthodes qui ont permis de générer les clés KiRa et KIRe- Le répondeur génère un troisième message « Message3 » pour le tiers de confiance. Le message contient les identifiants (IDR) et (ID-rc), les nonces (NR) et (N1), le MACRI et un nouveau MAC ( MACR3), calculé avec 25 la clé KRa sur toutes les données précédentes. A la réception du troisième message, le tiers de confiance vérifie la fraicheur du nonce NR et calcule le MACTc3 en utilisant la clé KRa et les données d'identifiants (IDR, IDTc), de nonces (NR, Ni) et de MAC (MACRI). 30 Le tiers de confiance vérifie ensuite que le MACTc3 calculé est bien égal au MACR3 reçu du récepteur. Si la valeur du MACTc3 reçu est valide, 19 3004041 le tiers de confiance génère un message « Message4 » à destination de l'initiateur. Le quatrième message contient les nonces NR et NI, le MACIR et la clé KIR chiffrée par la clé Kie. Dans une implémentation préférentielle, la clé KIR est concaténée 5 aux identifiants du répondeur IDR et du tiers de confiance ID-rc, et aux nonces N1 et NR avant d'être chiffrée avec la clé Kle en un chiffrement EfKle, (KIR,IDR,ID-rc,NI,NR)})- Le message envoyé par le tiers de confiance à l'initiateur contient de plus un MAC (MACTG4) calculé avec la clé Kia qui permet à l'initiateur 10 de vérifier l'intégrité des données reçues. A la réception du quatrième message, l'initiateur calcule son MAC (MAC14) avec sa clé Kia puis le compare au MAC (MACTG4) envoyé par le tiers de confiance. Si les deux MAC sont égaux, l'initiateur déchiffre le 15 contenu de EfKle, (KIR,IDR,IDTc,NI,NR)} avec sa clé Kie pour récupérer la clé KIR. Ensuite, l'initiateur utilise la clé KIR pour vérifier la valeur du MAC (MACR1) qui a été calculée et envoyée par le récepteur dans le troisième message. A cet effet, l'initiateur calcule localement un MAC (MACIR) sur 20 les mêmes champs que ceux qui ont été utilisés par le récepteur lors du calcul du (MACR1), à savoir les identifiants (IDR, ID-rc, ID1) et les nonces (Ni, NR). Puis, l'initiateur compare s'il y a égalité entre son MACIR et le MACRI. Si les deux MAC sont égaux, cela signifie que le répondeur a bien reçu la clé KIR de la part du tiers de confiance. Pour acquitter la bonne 25 réception du quatrième message, l'initiateur génère un message « Message5 » à destination du répondeur. L'initiateur envoie directement au répondeur le cinquième message 5 qui contient les identifiants respectifs de l'initiateur et du répondeur (IDI et IDR), leurs nonces (Ni, NR) et un MAC (MAC15) calculé avec la clé KIR. 30 A la réception du cinquième message, le répondeur vérifie la valeur 20 3004041 du MAC reçu (MAC15) en calculant son propre MAC (MACR5). Si les deux MAC sont égaux, le répondeur R conclut que l'initiateur a bien reçu la clé KIR de la part du tiers de confiance. 5 La figure 7 montre les procédures exécutées entre les entités initiateur, répondeur et tiers de confiance du réseau de la figure 4 dans une variante d'implémentation de l'invention consistant en quatre messages échangés. L'initiateur démarre le procédé en envoyant un premier message 10 « Messagel » au tiers de confiance. Le contenu du premier message est identique à celui décrit en référence à la figure 6. Après la réception du Messagel , le tiers de confiance TC génère un nonce (N-rc), ainsi que la clé KIR pour l'initiateur et le répondeur. Le nonce N-rc est un paramètre optionnel qui permet de rajouter de la 15 fraicheur au deuxième message dans le cas où le répondeur associe la fraicheur du message à la réception d'un nouveau nonce de l'initiateur mais aussi du tiers de confiance. L'ajout du nonce (N-rc) peut se décider lors de l'établissement de la politique de sécurité par l'administrateur du réseau. 20 Le tiers de confiance chiffre, avec la clé KRe, le nonce, la clé KIR, et cette même clé KIR chiffrée et protégée en intégrité par les clés Kle et Kla partagées avec l'initiateur. Le chiffré est envoyé dans un deuxième message « Message2bis » au répondeur. Le message contient de plus un MAC calculé avec la clé KRa, pour permettre au répondeur de vérifier 25 l'intégrité des données reçues. Après la réception du deuxième message, le répondeur vérifie l'intégrité et l'authenticité du message reçu en utilisant sa clé KRa. Si le résultat de la vérification est positif, le répondeur déchiffre le message pour récupérer la clé partagée KIR. 30 Ensuite, le répondeur génère un nonce (NR) puis envoie dans un troisième message « Message3bis », les données reçues du tiers de 21 3004041 confiance dans le deuxième message TC et contenant la clé KIR chiffrée et authentifiée avec les clés Kie et Kla partagées entre le tiers de confiance et l'initiateur. Pour permettre à l'initiateur de vérifier que le répondeur a bien reçu la clé partagée KIR, le répondeur envoie aussi un 5 MAC calculé avec cette clé KIR. A la réception du troisième message, l'initiateur vérifie l'intégrité de la première partie du message générée par le tiers de confiance en utilisant la clé Kia. Si la vérification est réussie, l'initiateur récupère la clé partagée KIR en utilisant sa clé Kle. Puis, il vérifie le MAC envoyé par le 10 répondeur en utilisant la clé KIR. L'initiateur envoie ensuite directement au répondeur un quatrième message qui contient les identifiants de l'initiateur et du répondeur (IDI, IDR), leurs nonces (Ni, NR) et un MAC (MAC15) calculé avec la clé KIR. A la réception du quatrième message, le répondeur vérifie la valeur 15 du MAC15 reçu en calculant son propre MACR5. Si les deux MAC sont égaux, le répondeur conclut que l'initiateur a bien reçu la clé KIR de la part du tiers de confiance. L'homme de l'art appréciera que des variations peuvent être 20 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, les exemples décrits sont basés sur un protocole préférentiel mais il est possible d'utiliser d'autres protocoles d'authentification. La présente invention peut s'implémenter à partir d'éléments 25 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 tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory 30 RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD- 22 3004041 ROM), Compact Disk - Read/VVrite (CD-R/VV) and DVD). 23 REVENDICATIONS1. Dans un réseau de communication comprenant une pluralité d'entités communicantes, un procédé pour établir une clé de session entre une entité source (I) et une entité cible ( R), l'entité source partageant avec une entité de confiance tierce (TC) une première clé source Kie pour le chiffrement de données et une deuxième clé source Kia pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité cible, le procédé comprenant les étapes de: - recevoir (602) à l'entité de confiance tierce, un message de l'entité source pour l'établissement d'une session avec l'entité cible, le message contenant au moins des identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé source Kia ; - générer (604) une paire KIR de clés (KiRa , KiRe) pour l'entité source et pour l'entité cible ; - encrypter (604) la paire KIR de clés (KiRa , KiRe) par la première clé source Kie et par la première clé cible KRe; - envoyer (606) à l'entité cible un message contenant au moins la clé KIR encryptée et un code d'authentification basé sur la deuxième clé cible KRa; - recevoir (608) de l'entité cible, un message contenant au moins les identifiants de l'entité source, de l'entité cible, de ladite entité de confiance tierce et un code d'authentification basé sur la deuxième clé cible KRa ; et 24 3004041 - envoyer (610) à l'entité source, un message contenant au moins la clé KIR encryptée et un code d'authentification basé sur la deuxième clé source Kia. 5 2. Le procédé selon la revendication 1 dans lequel la clé source Kle pour le chiffrement de données et la clé source Kla pour le code d'authentification sont dérivées d'une clé initiale obtenue après une étape d'authentification de l'entité cible auprès de l'entité de confiance tierce. 10 3. Le procédé selon la revendication 1 ou 2 dans lequel le message reçu de l'entité source comprend de plus un nonce source (NI) pour prouver la fraicheur du message de l'entité source. 15 4. Le procédé selon la revendication 3 dans lequel l'étape de générer la clé KIRa pour l'entité source comprend les étapes de concaténer la clé KIRa aux identifiants de l'entité cible, de l'entité de confiance tierce, et du nonce NI, et de chiffrer l'ensemble concaténé avec la première clé cible KRe - 20 5. Le procédé selon la revendication 4 dans lequel le message envoyé à l'entité cible comprend de plus le nonce (Ni) et le code d'authentification basé sur la deuxième clé cible KRa est calculé sur le nonce. 25 6. Le procédé selon la revendication 5 dans lequel le message reçu de l'entité cible comprend de plus le nonce source (Ni) et un nonce cible (NR) pour prouver la fraicheur du message cible. 30 25 3004041 7. Le procédé selon la revendication 6 comprenant une étape de calculer un code d'authentification en utilisant la deuxième clé cible KRa, les identifiants, les nonces source et cible (NI, NR) et le code 5 d'authentification reçu basé sur la deuxième clé cible KRa et une étape de vérifier, si le code d'authentification calculé est égal au code d'authentification reçu. 10 26 3004041 8. Le procédé selon la revendication 7 dans lequel le message envoyé à l'entité source comprend de plus les nonces source et cible (Ni, NR). 5 9. Le procédé selon l'une quelconque des revendications 1 à 8 dans lequel les identifiants des entités source et cible sont soit des adresses IPv6, des adresses MAC ou des URL. 15 20 25 30 27 3004041 101e procédé selon l'une quelconque des revendications 3 à 9 dans lequel le nonce est soit une information d'horodatage, un nombre aléatoire ou un compteur. 11. Le procédé selon l'une quelconque des revendications 1 à 10 dans lequel le message envoyé à l'entité cible contient de plus une clé chiffrée par les clés Kle et Kla et où le message reçu de l'entité cible et le message envoyé à l'entité source sont un seul message (708) 10 envoyé de l'entité cible à l'entité source. 12.Le procédé selon l'une quelconque des revendications 6 à 11 comprenant de plus l'étape d'envoyer (612) un message de l'entité source à l'entité cible qui contient les identifiants de l'entité source et 15 de l'entité cible, les nonces source et cible (NI, NR) et un code d'authentification calculé avec la paire de clés pour l'entité source et l'entité cible. 28 3004041 13. Un système pour établir une clé de session entre une entité source et une entité cible, l'entité source partageant avec une entité de confiance tierce une première clé source Kle pour le chiffrement de 5 données et une deuxième clé source Kla pour calculer un code d'authentification de message de l'entité source, l'entité cible partageant avec ladite entité de confiance tierce une première clé cible KRe pour le chiffrement de données et une deuxième clé cible KRa pour calculer un code d'authentification de message de l'entité 10 cible, le système comprenant des moyens pour mettre en oeuvre les étapes du procédé selon l'une quelconque des revendications 1 à 12. 14. Le système selon la revendication 13 où l'entité source est un 15 groupe de noeuds sources et/ou l'entité cible est un groupe de noeuds cibles utilisant des clés individuelles et/ou des clés de groupe. 15. Un produit programme d'ordinateur, ledit programme d'ordinateur 20 comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur.