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 œuvre 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 durée de vie limitée, et doit régulièrement être rafraîchie. Ainsi, la procédure mise en œuvre 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é 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 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 œuvre. Ce deuxième critère est particulièrement important lorsque le protocole d'établissement de clé de session doit être mis en œuvre 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 l'interopérabilité des mécanismes d'authentification entre deux nœuds le mettant en œuvre 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. II s'est développé principalement trois approches pour établir des clés de session entre deux nœuds.

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

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 nœuds à partir desquelles une clé de session commune est recouvrée par les deux entités participant à l'échange sans que les 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.

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 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 solution simple à mettre en œuvre, 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 Needham et Schroeder, ou bien le protocole Kerberos ou encore l'approche MIKEY-Ticket. 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 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 troisième message (Message3) entre l'initiateur et le répondeur. L'attaquant, qui peut connaître 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 Kohi 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 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 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 », 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 participants, ici le répondeur.

Le brevet WO 2009/070075 A1 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 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 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 connaît 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 communication, par exemple, si le protocole utilisé est implémenté de façon à bloquer les nœuds 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 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.

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.

L'invention proposée permet de répondre à ces besoins. Résumé de l'invention

Un objet de la présente invention est de proposer un procédé 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 nœud initiateur qu'à un nœud répondeur, une protection contre les attaques par déni de service.

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.

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 nœuds contraints en ressources comme ceux de capteurs et/ou actionneurs, qui sont parmi les nœuds les plus contraints en ressources et pouvant être amenés à devoir établir 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. 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 K| _e pour le chiffrement de données et une deuxième clé source K| _a 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 K _Re pour le chiffrement de données et une deuxième clé cible K _Ra 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 ré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 K| _a ;

générer une paire K| _R de clés (K| _Ra , K| _Re ) pour l'entité source et pour l'entité cible ;

encrypter la paire K _!R de clés (K| _Ra , K| _Re ) par la première clé source Κ| _θ et par la première clé cible K _Re ;

envoyer à l'entité cible un message contenant au moins la clé K| _R encryptée et un code d'authentification basé sur la deuxième clé cible K _Ra ;

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 K _Ra ; et envoyer à l'entité source, un message contenant au moins la clé K| _R encryptée et un code d'authentification basé sur la deuxième clé source

Kia-

Avantageusement, la clé source K _!e pour le chiffrement de données et la clé source K| _a 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.

Dans une variante, le message reçu de l'entité source comprend de plus un nonce source (Ni) pour prouver la fraîcheur du message de l'entité source. Dans une autre variante, l'étape de générer la clé K| _Ra pour l'entité source comprend les étapes de concaténer la clé K| _Ra 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 K _Re .

Avantageusement, le message envoyé à l'entité cible comprend de plus le nonce (Ni) et le code d'authentificatlon basé sur la deuxième clé cible K _Ra est calculé sur le nonce. Avantageusement, le message reçu de l'entité cible comprend de plus le nonce source (Ni) et un nonce cible (N _R ) pour prouver la fraîcheur du message cible.

Dans une variante d'implémentation, l'étape de calculer un code d'authentificatlon en utilisant la deuxième clé cible K _Ra , les identifiants, les nonces source et cible (Ni, N _R ) et le code d'authentificatlon reçu basé sur la deuxième clé cible K _Ra et l'étape de vérifier si le code d'authentificatlon calculé est égal au code d'authentificatlon reçu. Avantageusement, le message envoyé à l'entité source comprend de plus les nonces source et cible (Ni, N _R ).

Avantageusement, les identifiants des entités source et cible sont soit des adresses IPv6, des adresses MAC ou des URL.

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 confiance tierce à l'entité cible contient de plus une clé chiffrée par les clés K| _e et K| _a et où le message reçu de l'entité cible et le message 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 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, N _R ) et un code d'authentification calculé avec la clé K| _Ra partagée entre l'entité source et l'entité cible. 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 K| _e pour le chiffrement de données et une deuxième clé source K| _a 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 K _Re pour le chiffrement de données et une deuxième clé cible K _Ra pour calculer un code d'authentification de message de l'entité cible, le système comprenant des moyens pour mettre en œuvre toutes les étapes du procédé revendiqué.

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.

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 illustre les échanges de messages selon le procédé de Needham et Schroeder ; 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 ;

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

Description détaillée de l'invention La figure 4 illustre un exemple d'une infrastructure de 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 nœuds) 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 de communication (1 00) 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 de ressources (1 12-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 de noeuds (102) peut être basé sur des communications de niveau 2 (par exemple, 802.1 5.4 ou 802.11 ) et/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.

La présente invention peut être avantageusement appliquée dans l'environnement de la figure 4 entre deux nœuds du réseau, une entité 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 nœuds. Il peut être distant et accessible via un réseau de communication 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 nœuds.

En opération, chaque nœud initiateur et répondeur s'authentifie auprès du serveur central en utilisant ses crédentiels propres, des 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 nœuds 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 authentification biométrique pour l'autre. Le serveur de confiance distribue une même clé de session à deux nœuds souhaitant établir entre eux une association de sécurité, permettant des authentifications décorrélées pour chaque nœud, ainsi qu'un contrôle centralisé sur l'établissement de clés et/ou sur les politiques qui accompagnent ces dernières.

La figure 5 montre les procédures exécutées selon le protocole connu de Mikey- Ticket entre un nœud initiateur (I), un nœud 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 identiques sont utilisées pour décrire les figures suivantes 5 à 7. Ainsi, par la suite : Datai _, Data ₂ , ... 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 concaténées. Ainsi, pour un même message, les transmissions des mêmes données sous la forme (Datai , Data ₂ ) et (Data ₂ , Datai) sont équivalentes.

E{K, (Datai , Data ₂ , ...)} désigne le chiffrement des données concaténées (Datai, Data ₂ , ...) avec un algorithme de chiffrement utilisant une clé K.

MAC{K, (Datai , Data ₂ , ...)} désigne le code d'authentification de message « Message Authentication Code » (MAC) sur les données concaténées (Datai , Data ₂ , ...) en utilisant une clé K. 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 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é « Kia ». 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 nœud répondeur avec lequel le nœud 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é K| _R est chiffrée par la clé de chiffrement « Ki _e » de l'initiateur. Le deuxième message contient de plus un ticket « Ticketi » pour l'initiateur et un MAC calculé avec la clé K _!a .

A la réception du message, l'initiateur vérifie la validité du MAC et récupère sa clé K _!R qui va lui permettre de dériver avec le répondeur deux clés « KiRa >> et « K| _Re ». La clé K| _Ra servira à calculer des MACs alors que la clé KiRe permettra d'encrypter des données.

L'initiateur envoie ensuite au répondeur un message « Transfert_init » qui contient son ticket « Ticketi ». Ce troisième message contient un MAC calculé avec la clé K| _Ra .

Il est à noter qu'à ce niveau de l'exécution du protocole, le nœud répondeur (R) n'a pas encore reçu la clé K| _R et donc pas reçu les clés K| _Ra et K| _Re . Par conséquent, (R) ne peut pas vérifier la validité du MAC qu'il vient de recevoir du nœud initiateur, et doit envoyer au tiers de confiance (TC) un message « Resolve_init » pour lui demander de lui communiquer 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é K _Ra . Si le MAC est valide, il envoie au répondeur la clé K _!R chiffrée par la clé K _Re , dans un cinquième message « Resolve_resp » .

A la réception du cinquième message, le répondeur vérifie le MAC calculé par le tiers de confiance et récupère la clé K| _R . Une fois la clé K| _R reçue, le répondeur calcule la clé K| _Ra 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 clé KIR.

Ainsi, comme il a déjà été discuté précédemment, le nœud 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 service. Un nœud attaquant peut bombarder le nœud répondeur avec un nombre illimité de messages de type « Transfe nit » (troisième 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 nœud répondeur. 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 œuvre qui est obtenue au moyen d'un nombre de messages échangés réduits. Le procédé proposé permet d'établir une communication sécurisée entre un nœud initiateur et un nœud 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 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.

L'homme de l'art appréciera que les échanges de messages donnent des rôles équivalents au nœud initiateur (I) et au nœud récepteur (R) vis à vis du tiers de confiance (TC). En effet, les interactions sont du type (l)e (TC), (TC)el(l), (R)tt(TC) et (TC)âl(R) et offrent ainsi au tiers de confiance un meilleur contrôle de l'établissement de clé de session.

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 nœuds 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 deux clés (K| _e , K| _a ) où K| _e est une clé utilisée pour le chiffrement des données, et où K| _a est une clé utilisée pour calculer un code d'authentification de message (MAC). K _!e et K _!a peuvent être dérivées d'une clé maîtresse à 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é (K _Re , K _Ra ) avec le tiers de confiance.

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 nœuds répondeurs utilisant des clés individuelles et/ou des clés de groupe.

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 nœuds (I) et (R). Puis, le tiers de confiance envoie la clé KIR encryptée avec la clé K| _E à l'initiateur et envoie la clé KIR encryptée avec la clé K _RE 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 K _RA .

De manière plus détaillée en référence à la figure 6, l'initiateur 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 (I D _T c) et du répondeur (ID _R ). Il contient aussi un nonce (Ni) qui sert à prouver la fraîcheur de la session et à éviter les attaques par rejeu. De plus, l'initiateur rajoute au messagel un MAC (MACn) calculé sur (ID,, I D _T c, ID _R et N,) avec la clé K _!a . Le MAC permet de prouver au tiers de confiance l'authenticité des données reçues dans le premier message.

Les identifiants (ID|,ID _T c, ID _R ) peuvent dépendre de la technologie utilisée et du type de réseau déployé. Ces identifiants peuvent être, par exemple, des adresses IPv6, des adresses MAC ou des URL. Dans le cas particulier des réseaux I P, les identifiants ID| et I D _T c peuvent correspondre respectivement à l'adresse source et à l'adresse destination du paquet I P.

Le nonce peut être une information d'horodatage, un nombre aléatoire ou un compteur (numéro de séquence). Ce doit être une 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é 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 fraîcheur du nonce Ni et utilise la clé K _!a pour calculer le MAC (MAC _T ci) sur (ID|, I DJC, I DR et Ni). Ensuite, il vérifie l'égalité entre le MACn reçu de l'initiateur et son propre MAC (MAC _T ci) 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é K| _R pour l'initiateur et le répondeur. Puis il envoie au répondeur cette clé K| _R chiffrée par la clé de chiffrement K _Re . 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é K| _R aux identifiants I D| et ID _T c, et le nonce N| avant de chiffrer le tout avec la clé K _Re pour obtenir un chiffrement E{K _Re , (K| _R ,ID _T c, ID|,N|)}. Ce deuxième message contient aussi les identifiants (IDi, I DTC, I DR), le nonce N, et le MAC (MACTC ₂ ). Le MAC (MACTC ₂ ) est calculé avec la clé K _Ra sur les champs suivants : ID _T c, I DR, I DI, N I, et E{K _Re , (K| _R ,I D _TC ,ID|,N|)}.

A la réception du deuxième message, le répondeur vérifie l'égalité entre le MAC _T c2 reçu et sa propre valeur de MAC (MAC _R2 ) qu'il calcule en utilisant la clé K _RA . Si la valeur de MAC _T C2 est bonne, le répondeur déchiffre le contenu de E{K _Re , (K| _R , ID _T c,I D|, N|)} pour récupérer la clé K| _R .

Le répondeur génère un nonce (N _R ) et calcule un MAC (MAC _R |) avec la clé KIR sur les données d'identifiants (I D _R , I DTC, I DI) et de nonce (Ni, N R). 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

Dans une première variante, le répondeur utilise les nonces (Ni, N _R ) et la clé K _!R comme entrées à une fonction pseudo-aléatoire pour générer deux clés « K| _Ra » et « K| _Re ». La clé K| _Ra est utilisée pour calculer les MACs, la clé KiR _e 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 clés, « K| _Ra » et « K| _Re » 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 K| _R est par la suite utilisée pour désigner à la fois la clé servant à calculer les MACs et pour le chiffrement, indépendamment des méthodes qui ont permis de générer les clés K| _Ra et K| _Re .

Le répondeur génère un troisième message « Message3 » pour le tiers de confiance. Le message contient les identifiants (I D _R ) et (I D _T c), les nonces (N _R ) et (N,), le MAC _R | et un nouveau MAC ( MAC _R3 ), calculé avec la clé K _Ra sur toutes les données précédentes.

A la réception du troisième message, le tiers de confiance vérifie la fraîcheur du nonce N _R et calcule le MAC _T c3 en utilisant la clé K _Ra et les données d'identifiants (I D _R , I D _T c), de nonces (N _R , Ni) et de MAC (MACRI).

Le tiers de confiance vérifie ensuite que le MAC _T c3 calculé est bien égal au MAC _R3 reçu du récepteur. Si la valeur du MAC _T c3 reçu est valide, le tiers de confiance génère un message « Message4 » à destination de l'initiateur. Le quatrième message contient les nonces N _R et N|, le MACIR et la clé K _!R chiffrée par la clé K _!e .

Dans une implémentation préférentielle, la clé KIR est concaténée aux identifiants du répondeur ID _R et du tiers de confiance ID _T c, et aux nonces Ni et N _R avant d'être chiffrée avec la clé K| _e en un chiffrement

E{K|e, (K| _R , I D _R , I DTC, N|, N _R )}) .

Le message envoyé par le tiers de confiance à l'initiateur contient de plus un MAC (MAC _T c ₄ ) calculé avec la clé K _!a qui permet à l'initiateur de vérifier l'intégrité des données reçues.

A la réception du quatrième message, l'initiateur calcule son MAC (MAC| ₄ ) avec sa clé K| _a puis le compare au MAC (MAC _T c ₄ ) envoyé par le tiers de confiance. Si les deux MAC sont égaux, l'initiateur déchiffre le contenu de E{K| _e , (K| _R , ID _R ,ID _T c,N|,N _R )} avec sa clé K| _e pour récupérer la clé KIR.

Ensuite, l'initiateur utilise la clé K| _R pour vérifier la valeur du MAC (MACRI) 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 les mêmes champs que ceux qui ont été utilisés par le récepteur lors du calcul du (MACRI), à savoir les identifiants (ID _R , I D _T c, I D|) et les nonces (Ni, N _R ). Puis, l'initiateur compare s'il y a égalité entre son MACIR et le MAC™. Si les deux MAC sont égaux, cela signifie que le répondeur a bien reçu la clé K| _R de la part du tiers de confiance. Pour acquitter la bonne 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 (I Di et I D _R ), leurs nonces (N|, N _R ) et un MAC (MAC| ₅ ) calculé avec la clé K| _R .

A la réception du cinquième message, le répondeur vérifie la valeur du MAC reçu (MAC| ₅ ) en calculant son propre MAC (MAC _R5 ). 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. 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 « 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 _T c), ainsi que la clé K| _R pour l'initiateur et le répondeur. Le nonce N _T c est un paramètre optionnel qui permet de rajouter de la fraîcheur au deuxième message dans le cas où le répondeur associe la fraîcheur du message à la réception d'un nouveau nonce de l'initiateur mais aussi du tiers de confiance.

L'ajout du nonce (N _T c) peut se décider lors de l'établissement de la politique de sécurité par l'administrateur du réseau.

Le tiers de confiance chiffre, avec la clé K _RE , le nonce, la clé KIR, et cette même clé K| _R chiffrée et protégée en intégrité par les clés K| _e et K _!a 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é K _Ra , pour permettre au répondeur de vérifier 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é K _Ra . 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 K| _R .

Ensuite, le répondeur génère un nonce (N _R ) puis envoie dans un troisième message « Message3bis », les données reçues du tiers de confiance dans le deuxième message TC et contenant la clé K| _R chiffrée et authentifiée avec les clés K| _e et K| _a 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 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é K| _A . Si la vérification est réussie, l'initiateur récupère la clé partagée K _!R en utilisant sa clé K _!E . Puis, il vérifie le MAC envoyé par le répondeur en utilisant la clé K| _R .

L'initiateur envoie ensuite directement au répondeur un quatrième message qui contient les identifiants de l'initiateur et du répondeur (ID|, ID _R ), leurs nonces (N|, N _R ) et un MAC (MAC| ₅ ) calculé avec la clé K| _R .

A la réception du quatrième message, le répondeur vérifie la valeur du MAC| ₅ reçu en calculant son propre MAC _R5 . Si les deux MAC sont égaux, le répondeur conclut que l'initiateur a bien reçu la clé K| _R de la part du tiers de confiance.

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, 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 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 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).