RESEAU

Domaine de l'invention

L'invention concerne le domaine de la sécurité dans les réseaux de communication et en particulier 1 ' authentification de nœuds dans les réseaux à faibles ressources .

Etat de la Technique

Actuellement, 1 ' authentification des nœuds dans un réseau à faibles ressources se fait d'une manière individuelle. Soit chaque nœud est authentifié avec son identité réelle ou virtuelle, soit il est authentifié en s ' identifiant comme membre d'un groupe de nœuds .

Une solution bien connue pour authentifier plusieurs nœuds consiste à mener, successivement ou en parallèle, plusieurs authentifications individuelles. La technologie la plus répandue est le protocole « Extensible Authentication Protocol» en anglais ou (EAP) décrit dans le document "Extensible Authentication Protocol (EAP)", IETF RFC 3748, June 2004 de B. Aboba et al. qui définit comment un client s'authentifie à un serveur.

En sérialisant les authentifications individuelles indépendantes le serveur considère chaque procédure d ' authentification comme rigoureusement indépendante, ce qui conduit à une consommation importante en ressources telle que des coûts énergétiques des communications ou une diminution de la bande passante. Une autre limitation est qu'il est impossible au serveur d'utiliser le protocole EAP pour envoyer des paramètres de sécurité vers le fournisseur de service.

Afin de limiter la surcharge sur un serveur d'authentification, des systèmes ont été proposés qui permettent de déléguer la fonctionnalité d'authentification par le serveur à d'autres nœuds du réseau. Ainsi, dans les réseaux cellulaires de troisième génération, le protocole « Authentication and Key Agreement » de B. Aboba et al. ou (AKA) mis en œuvre pour 1 ' authentification et le bootstrapping prévoit en particulier de déléguer la capacité d'authentifier la station mobile et d'être authentifié par elle depuis un « Home Subscriber Server » ou (HSS en anglais) vers une « BootStrapping Function » ou (BSF en anglais) du fournisseur de service. A cette fin, des vecteurs d ' authentification sont remis du HSS à la BSF qui sont ensuite utilisés dans le cadre d'une authentification locale entre la BSF et l'équipement utilisateur « User Equipment» en anglais ou (UE) . Cependant, la remise de ces paramètres n'est pas agrégée lorsque plusieurs utilisateurs distincts souhaitent s'authentifier auprès de la même BSF. De plus, les vecteurs d ' authentification sont strictement relatifs à un unique utilisateur et doivent être générés pour chaque client par le HSS.

Une méthode d ' authentification pour les communications machine-à-machine est proposée dans le document [CN102088668, "Group-based authentication method of machine type communication (MTC) devices", Xidian University, 2011]. Cette méthode permet d'authentifier un groupe de nœuds comme une seule unité. Les nœuds s'enregistrent dans un groupe par un serveur « Machine-Type Communication » ou (MTC en anglais) . En se basant sur un vecteur d'authentification de groupe, les nœuds s'authentifient au serveur d ' authentification (Authentication center, AuC) comme étant membres de ce groupe .

D'une manière similaire, la méthode décrite dans la demande de brevet WO2011131052 de Tian Tian et al. intitulée "Procédé et Système d ' Authentification par Groupes dans les Systèmes de Communication de Machine- à-Machine", permet d'authentifier un groupe de nœuds dans un réseau MTC en se basant sur du matériel cryptographique de groupe généré par un centre d'autorisation et envoyé à une entité de gestion de la sécurité d'accès « Access Security Management Equipment » (ASME) .

Ces deux méthodes d ' authentification par groupe permettent de réduire le trafic au niveau de l'infrastructure, soit entre le MTC server et l'AuC pour la première méthode, soit entre le serveur d'autorisation et l'ASME pour la deuxième méthode. Cependant, elles ne permettent pas de diminuer le nombre de messages échangés au niveau du réseau MTC qui est généralement de faibles ressources. II existe alors le besoin d'une solution qui permette une authentification collective des nœuds d'un groupe où tous les membres du groupe sont authentifiés en un seul échange. La présente invention répond à ce besoin.

Résumé de l'invention Un objet de la présente invention est de fournir une méthode d ' authentification collective en un seul échange d'un groupe de nœuds dans un réseau de communication . Un autre objet de l'invention est de permettre à des nœuds d'un réseau de s'authentifier à un fournisseur de service en utilisant un serveur d'authentification et, selon le résultat de 1 'authentification, d'approvisionner le fournisseur de service en matériels cryptographiques afin de réaliser un contrôle d'accès individualisé aux ressources ou aux services proposés.

Avantageusement, la présente invention s'applique lorsque les membres d'un groupe veulent accéder en même temps à des ressources ou à des services administrés par une infrastructure distante.

Un autre avantage de la présente invention est de consommer moins de ressources en matière de bande passante dans le réseau et moins d'énergie au niveau des nœuds, que dans les méthodes d ' authentification individuelle des nœuds.

Un autre avantage est que le contrôle d'accès aux ressources et services reste individualisé pour chacun des membres du groupe.

Avantageusement, l'invention permet aux messages d'un serveur d ' authentification d'être diffusés vers le groupe dans un arbre de routage multicast et aux messages d ' authentification des nœuds d'être remontés vers le serveur suivant un procédé de reverse multicast, en agrégeant le contenu des messages. Un autre objet de la présente invention est de pouvoir gérer les situations où certains membres d'un groupe sont défaillants ou déconnectés ou bien lorsqu'un nombre limité de nœuds d'un groupe échouent lors de 1 ' authentification agrégée.

Avantageusement, l'invention permet à un serveur d ' authentification d'authentifier et d'exporter pour chacun des nœuds d'un groupe, des paramètres de sécurité, tels que des clés, des droits d'accès, vers le fournisseur de services. Avantageusement, la présente invention s ' implémentera dans le contexte de services de sécurité tels que le « bootstrapping » en authentification initiale, la réauthentification, et l'autorisation.

Toujours avantageusement mais sans limitation, l'invention trouvera des applications dans les domaines industriels de la sécurité des communications machine-à-machine.

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 10 et un produit programme d'ordinateur tel que décrit dans la revendication 12 sont proposés.

En particulier, une méthode pour

authentifier un groupe de nœuds parmi une pluralité de nœuds d'un réseau de communication, la méthode

comprenant les étapes de :

- identifier parmi la pluralité des nœuds, un groupe de nœuds à authentifier;

- générer un défi pour le groupe de nœuds;

- envoyer depuis un serveur d ' authentification le défi vers un premier nœud de la pluralité de nœuds;

- diffuser depuis le premier nœud, le défi vers tous les nœuds du groupe de nœuds selon un arbre de routage multicast;

- agréger au niveau du premier nœud selon un arbre de routage multicast inverse de l'arbre de routage multicast, les réponses au défi des nœuds du groupe;

- envoyer l'agrégé des réponses au serveur

d 'authentification ;

- vérifier l'agrégé des réponses ; et

- générer un message de succès pour le groupe de nœuds si la vérification collective est réussie.

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 étapes opérées par la méthode de la présente invention pour authentifier les nœuds d'un groupe ;

La Figure 3 montre les échanges réalisés entre les nœuds d'un groupe et le serveur d ' authentification dans une implémentation préférentielle de l'invention; La Figure 4 illustre une variante d ' implémentation des échanges de la figure 3.

Description détaillée de l'invention

L'invention s'applique avantageusement dans un réseau formé de nœuds ayant des faibles ressources, et dont certains nœuds doivent accéder à une ressource ou un service associés à une infrastructure distante. Des exemples de réseaux de faibles ressources sont les réseaux de capteurs qui sont de plus en plus déployés dans le domaine industriel et les réseaux véhiculaires .

La figure 1 montre un exemple d'un contexte général 100 dans lequel implémenter avantageusement l'invention. Un groupe de nœuds (102) composé d'équipements de faibles ressources doit accéder à des services ou des ressources associés à un fournisseur de service (104) d'une infrastructure distance. Les services ou les ressources requis peuvent être des besoins en connectivité ou en données. Les nœuds peuvent être mobiles ou statiques et sont connectés au réseau distant au travers d'une passerelle (110) . Le serveur fournisseur de service peut dans une variante d ' implémentation être co-localisé sur la passerelle, comme par exemple pour le cas d'un accès réseau.

Pour avoir accès à ces services ou ressources, les nœuds doivent être authentifiés auprès d'un serveur d ' authentification (106).

L'infrastructure distante peut contenir des entités intermédiaires telles que des routeurs (108).

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 pour la présente invention à une pluralité et une variété de nœuds d'un groupe et de type de serveurs, passerelle ou connexions (sans fil, mobile, très haut débit) .

Le réseau de nœuds (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) . Suivant les protocoles sur lesquels il s'appuie, des schémas de communications multicast ou broadcast peuvent y être employés . 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.

Le serveur d ' authentification (106), responsable de 1 ' authentification des nœuds, stocke les données cryptographiques nécessaires pour 1 ' authentification de chacun des nœuds du groupe (102) . Si 1 'authentification collective, telle que décrite plus loin en référence à la figure 2 est validée, le serveur d ' authentification dérive et envoie les paramètres de sécurité (les clés de session, les droits d'accès) de chacun des nœuds du groupe vers le fournisseur de services (104) . Le fournisseur de service établit par la suite une association de sécurité avec chacun des nœuds.

Le fournisseur de service (104) peut dans une première variante d ' implémentation ne pas être impliqué dans les échanges pour 1 ' authentification des nœuds du groupe (102) . Dans ce cas, le serveur d ' authentification (106) exporte les paramètres de sécurité associés aux nœuds, après une authentification réussie, dans un message séparé d'un message de succès de 1 ' authentification destiné au groupe des nœuds. Alternativement, dans une autre implémentation, les échanges d ' authentification sont relayés par le fournisseur de service (104) . Une telle situation peut se produire lorsque le fournisseur de services fournit l'accès au réseau. Dans ce cas, après une authentification réussie, les paramètres de sécurité sont transférés au fournisseur de services (104), selon deux variantes :

- dans une première variante, les paramètres de sécurité sont transférés dans un message séparé du message de succès de 1 ' authentification destiné au groupe des nœuds ;

dans une seconde variante, les paramètres de sécurité sont transférés avec le message de succès de 1 'authentification destiné au groupe des nœuds. Cette variante d ' implémentation est celle retenue dans la suite de la description. La figure 2 montre le procédé (200) opéré par la méthode de la présente invention pour authentifier les nœuds d'un groupe.

L'étape (202) consiste à former un groupe de nœuds. La formation du groupe des nœuds peut être réalisée d'une manière spontanée ou préalablement à

1 ' authentification .

Pour une formation spontanée du groupe, les nœuds peuvent être groupés sur la base de critères de proximité temporelle et géographique ou d'intérêt commun aux services offerts par le fournisseur de service. Les identités des nœuds sont envoyées pour authentification au serveur d ' authentification qui va constituer un modèle de groupe en réunissant sous un même ensemble toutes les identités des nœuds reçues.

Alternativement, dans le cas d'une formation préalable, le groupe des nœuds est formé en utilisant une adresse de groupe multicast. Avantageusement, dans une variante d ' implémentation, une fois le groupe formé et désigné, un arbre de routage multicast est construit pour permettre la diffusion de messages provenant du serveur d ' authentification au sein du groupe.

Simultanément, un autre arbre de routage en multicast inverse « reverse multicast » est construit. L'arbre de routage inverse considère les membres du groupe comme sources/émetteurs de messages de diffusion et le serveur d ' authentification comme cible/récepteur de ces messages.

L'homme de l'art pourra se référer aux techniques connues de construction d'arbre de routage multicast, comme le protocole « RPL » décrit par T. Winter et al., dans "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", IETF Internet Draft in progress, draft-ietf-roll-rpl-19 , March 13, 2011.. Ce protocole qui est dédié aux réseaux à faibles ressources peut avantageusement être utilisé dans le contexte de l'invention. Cependant, tout protocole de routage supportant des moyens de diffusion d'un point unique vers des points multiples pour la construction du premier arbre de routage multicast et des points multiples vers un point unique pour la construction de l'arbre de routage en reverse multicast peut être utilisé. Une variante pour construire l'arbre de routage en reverse multicast se base sur le premier arbre de routage multicast, en faisant en sorte que chaque nœud fils dans l'arbre envoie le message à son nœud père tel qu'identifié par l'arbre de routage multicast .

Des entités intermédiaires, comme par exemple la passerelle (110), des « cluster-heads » ou des nœuds intermédiaires du réseau, appartenant ou non au groupe de nœuds se chargent de la diffusion des messages en provenance du serveur d ' authentification vers ces nœuds et de l'agrégation des messages des nœuds destinés en retour au serveur. A l'étape (204), le processus d ' authentification collective est initié, et une requête d'identification est émise. La requête est envoyée du serveur d ' authentification vers les nœuds.

Si le groupe de nœuds a été formé de manière spontanée selon des critères de regroupement déterminés, chaque nœud répond à réception de la requête par son identité. L'identité de chaque nœud peut prendre la forme par exemple, d'un « Network Access Identifier » en anglais ou (NAI) tel que décrit dans le document « The Network Access Identifier », IETF RFC 4282 de B. Aboba et al., December 2005. Le serveur d ' authentification reçoit les identités des nœuds soit dans des messages séparés ou concaténées dans un seul message.

Si le groupe de nœuds a été formé de manière préalable, chaque nœud répond dès la réception de la requête d'identification par l'identité du groupe (adresse multicast). Le message contenant l'identité du groupe est agrégé tout le long de l'arbre de routage en « reverse multicast ».

Alternativement, la requête d'identification peut ne pas être diffusée au sein du groupe de nœuds mais seulement envoyée à une entité intermédiaire dans le réseau, comme par exemple la passerelle, un routeur ou un « cluster-head ». L'entité intermédiaire se charge de répondre à la requête d'identification par l'identité du groupe.

Dans une variante d ' implémentation où le serveur d ' authentification a connaissance de l'identité des nœuds d'une manière implicite dans le message reçu comme réponse à son défi d ' authentification, l'étape d'identification peut alors être omise.

A l'étape (206), un échange de message « défi- réponse » se déroule entre les nœuds du groupe et le serveur d ' authentification . Avantageusement, l'invention permet d'authentifier un groupe de nœuds en un seul échange. Le serveur d ' authentification envoie une requête vers les nœuds. La provenance de la requête est authentifiée par les nœuds au moyen d'un procédé connu d ' authentification . L ' authentification du serveur peut être faite par une signature MAC avec une clé générée selon par exemple le protocole « TESLA » décrit par A. Perrig et al., dans "The TESLA Broadcast Authentication Protocol", UC Berkeley and IBM Research, 5(2), 2002.

Au niveau du groupe de nœuds, les réponses des nœuds sont agrégées en utilisant des fonctions d'agrégation de messages d ' authentification qui permettent de garantir d'une part l'intégrité de l'agrégé des réponses et d'autre part la vérification des identités des émetteurs. L'homme de l'art trouvera à appliquer des fonctions connues d'agrégation commutâtives , comme par exemple les schémas d'agrégation de MAC décrits par J. Katz et al., dans "Aggregate message authentication codes", In Proceedings of the 2008 The Cryptopgraphers ' Track at the RSA conférence on Topics in cryptology, Tal Malkin (Ed.). Springer-Verlag, Berlin, Heidelberg, 155-169. Alternativement, des fonctions quasi-commutatives peuvent être appliquées, comme par exemple les fonctions à sens unique accumulative décrites par J. Benaloh et al., dans "One-way accumulators : a decentralized alternative to digital signatures", Advances in Cryptology—Eurocrypt ' 93 , LNCS, vol. 765, Springer-Verlag, 1993, pp. 274-285.

Avantageusement, des schémas basés sur des algorithmes de chiffrement ou de signatures homomorphiques , comme celui décrit par C. Castellucia et al., dans "Efficient aggregation of encrypted data in wireless sensor networks", In Mobile and Ubiquitous Systems: Networking and Services, 2005, peuvent être aussi envisagés.

Dans une variante d ' implémentation, si une authentification mutuelle n'est pas requise, 1 'authentification du serveur d'authentification par les nœuds peut être omise.

Dans une implémentation préférentielle où le groupe de nœuds est identifié par une adresse multicast, le défi envoyé par le serveur d'authentification est diffusé à tous les nœuds du groupe suivant l'arbre de routage multicast préalablement construit. Les réponses des nœuds sont agrégées par un nœud parent au fur et à mesure qu'elles sont transportées sur l'arbre de routage en « reverse multicast ».

Lorsque les réponses sont reçues, le nœud agrégateur les agrège et l'agrégé des réponses est transmis en « reverse multicast ».

Comme il sera détaillé plus loin, si des nœuds n'ont pas répondu au défi après un temps d'attente prédéfini, le routeur ajoute à l'agrégé des réponses l'identité des nœuds défaillants dans un message ^y NACK'. Le serveur d ' authentification peut identifier chaque nœud défaillant ou déconnecté dans l'arborescence de l'arbre de routage multicast et les authentifier directement au moyen d'un protocole d'authentification individuelle.

Avantageusement, si un routeur appartient au groupe de nœuds déclaré, il calcule sa propre réponse au défi et collecte les réponses des nœuds répondant dans son sous-arbre. Le routeur ajoute sa réponse aux réponses reçues et agrège l'ensemble.

Dans une variante d ' implémentation où un routeur ne dispose pas de fonction d'agrégation, les réponses reçues sont transmises directement à un autre routeur, placé plus haut dans l'arbre de routage inverse, qui peut se charger de les agréger.

L'agrégé des réponses est transmis au serveur d'authentification, et peut être relayé par le fournisseur de service dans une variante d ' implémentation .

L'étape suivante (208) du procédé, consiste pour le serveur d ' authentification à vérifier l'intégrité de l'agrégé des réponses reçu et les identités de ses émetteurs. Le serveur utilise du matériel cryptographique spécifique à chaque membre du groupe, comme par exemple des clés partagées avec chacun des membres du groupe ou des clés publiques associées aux clés privées de chacun des membres du groupe, pour faire la vérification.

Si la vérification échoue, le serveur d'authentification envoie un message d'échec aux nœuds. Le procédé se poursuit par une authentification individuelle (214) .

Si la vérification est entièrement correcte, le serveur d ' authentification envoie un message de succès vers les nœuds du groupe et le procédé continue à l 'étape (210) .

Si la vérification n'est que partiellement réussie, le serveur d ' authentification envoie un message individuel de succès ou d'échec respectivement à chaque nœud selon le résultat de la vérification. Puis, le procédé continue à l'étape (212).

Les étapes suivantes (210 et 212) consistent à approvisionner le fournisseur de service en matériel de sécurité soit complètement (210) soit partiellement (212) . Le message de succès ou d'échec de 1 'authentification envoyé par le serveur d ' authentification aux nœuds est aussi envoyé au fournisseur de service. Alternativement, le fournisseur de service peut aussi être le relais du message de succès ou d'échec vers les nœuds.

Si l'étape de vérification (208) est réussie, le serveur d ' authentification joint au message de succès, du matériel cryptographique destiné au fournisseur de service. Le terme 'matériel cryptographique' s'entend dans la présente description comme toute information, données, pouvant être utilisées pour établir une authentification, telles que des clés, des droits d'accès, des identités ou des certificats par exemple. Le matériel cryptographique permet au fournisseur de service d'établir une association de sécurité avec chaque nœud ayant été vérifié. Le matériel cryptographique est dérivé à partir de matériel que le serveur d ' authentification établit individuellement avec chaque nœud. Avantageusement, le serveur d ' authentification peut joindre au message de succès une clé de groupe associée au groupe des nœuds et destiné au fournisseur de service, dans le cas où tous les nœuds du groupe se sont authentifiés.

Après l'étape (210) de provisionnement complet de matériel de sécurité, le procédé d ' authentification collective est terminé (216) .

Après l'étape de vérification (208) ayant conduit à un échec ou à un provisionnement partiel de matériel de sécurité (212), le procédé se poursuit par une étape d ' authentification individuelle (214).

Si la vérification est partielle, le serveur d'authentification applique un protocole

d ' authentification individuel pour vérifier

individuellement les nœuds non authentifiés à l'issue de 1 ' authentification collective.

Puis le procédé d ' authentification est terminé

(216) .

La figure 3 montre les échanges réalisés entre les nœuds d'un groupe et le serveur d ' authentification dans une implémentation préférentielle de l'invention.

Dans une phase initiale (302), le groupe de nœuds est formé et les arbres de routage définis.

Le serveur d ' authentification prend connaissance du groupe, par exemple depuis un centre de gestion de groupe. Alternativement, le serveur gère lui même le groupe (le centre de gestion de groupe est co-localisé avec le serveur d ' authentification) et gère les requêtes de demande d'enregistrement des nœuds à ce groupe .

La phase de formation de groupe s'effectue ainsi une fois pour un groupe, et s'adapte ensuite au gré de la dynamique du groupe, par exemple par enregistrement de nouveaux membres ou désabonnement de membres. Cette phase reste indépendante du choix du fournisseur de service .

Les arbres de routage 'multicast' et 'reverse multicast' sont créés avec les membres du groupe, dans lequel certains nœuds sont définis comme routeur agrégateur pour agréger les réponses des nœuds périphériques et diffuser une réponse agrégée vers le serveur d ' authentification .

La phase suivante (304) consiste en 1 ' authentification collective des nœuds du groupe, et regroupe les phases intermédiaires 306 à 312.

Dans la phase (306), une requête d'identification est diffusée dans l'arbre de routage multicast vers les nœuds du groupe. Les nœuds répondent et un message contenant l'identité du groupe est diffusé dans l'arbre de routage multicast inverse vers le serveur d ' authentification .

Dans la phase suivante (308) le serveur d ' authentification génère un défi qui est commun à tous les nœuds du groupe. Le défi est diffusé dans l'arbre de routage multicast vers tous les nœuds. Chaque nœud qui opère comme agrégateur initie un compteur qui va mesurer le temps de réponse des nœuds périphériques lui étant rattachés dans l'arbre de routage multicast inverse. Ce temps est connu comme le « Round-Trip Time » ou (RTT) en anglais.

Dans une implémentation préférentielle, en l'absence de réponse d'un nœud du groupe à la requête d'identification après un temps limite écoulé, calculé à partir du RTT dans son sous-arbre multicast, un accusé de réception négatif « Négative acknowledgement » ou (NACK) est émis. L'absence de réponse peut être due à un état de veille du nœud ou une inaccessibilité ou une défaillance. L'accusé de réception négatif (NACK) est joint par le nœud routeur à la réponse dans l'arbre de routage inverse.

Avantageusement, le routeur vérifie que le nombre total des 'NACKs' ne dépasse pas un nombre seuil pour ne pas allonger considérablement le message retourné en reverse multicast, sinon, le routeur ne répond pas à la requête.

Les réponses des nœuds au défi sont renvoyées vers un nœud routeur. Le nœud routeur parent dans l'arbre de routage multicast inverse agrège les réponses reçues et renvoie l'agrégé des réponses vers le serveur d ' authentification .

Pour l'agrégation des réponses, le rôle d'un nœud change suivant sa place dans l'arbre de routage « reverse multicast ». Si un nœud occupe une place périphérique, alors il calcule sa réponse et l'envoie directement, dès qu'il reçoit le défi. Si un nœud agit en tant que routeur dans l'arbre de routage « reverse multicast », il agrège les réponses reçues.

L'homme de l'art comprendra que la racine de l'arbre multicast, par exemple le serveur d'authentification ou la passerelle, peut avoir connaissance de l'arborescence de l'arbre de routage en 'reverse multicast' pour pouvoir déterminer les membres du groupe qui ne vont pas participer à 1 'authentification collective du groupe.

Le serveur d ' authentification vérifie dans une phase (310) le message agrégé reçu.

Préfèrentiellement , le serveur d ' authentification comprend des fonctions d'agrégation de messages d'authentification, et peut ainsi authentifier les membres du groupe.

Après une authentification réussie de tous les membres du groupe, le serveur envoie au fournisseur de service dans une phase suivante (312) le matériel cryptographique de sécurité (par exemple des clés cryptographiques), ainsi que d'autres paramètres (par exemple des droits d'accès, des contextes de sécurité) . Ces informations de sécurité qui sont propres à chacun des membres du groupe permettent de créer des associations de sécurité entre le fournisseur de service et chacun des membres du groupe . Dans une variante d ' implémentation où le fournisseur de services n'est pas impliqué dans les échanges d ' authentification, le serveur d'authentification exporte les paramètres de sécurité associés aux nœuds, après une authentification réussie, dans un message séparé du message de succès de 1 ' authentification destiné au groupe des nœuds.

Dans une autre variante d ' implémentation, les échanges d ' authentification sont relayés par le fournisseur de service. Dans ce cas, les paramètres de sécurité peuvent être transférés au fournisseur de services, après une authentification réussie, soit dans un message séparé du message de succès de 1 ' authentification destiné au groupe des nœuds, soit con ointement avec le message de succès de 1 ' authentification destiné au groupe des nœuds.

La figure 4 illustre les échanges intervenant dans une implémentation du procédé d ' authentification de la présente invention basée sur le protocole EAP- PSK. Le protocole EAP-PSK est décrit par F. Bersani et al. dans "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", IETF RFC 4764, 2007.

Seuls les éléments spécifiques à la présente invention sont décrits, et l'homme du métier se reportera à la littérature disponible pour les principes généraux liés au protocole 'EAP-PSK'. La figure 4 s'appuie sur l'exemple de deux nœuds pour simplifier la description mais n'est en rien limitatif. L ' implémentation décrite (400) permet 1 ' authentification des nœuds d'un même groupe en un seul échange entre le serveur d ' authentification et le groupe de nœuds, échange représenté par un défi {RAND_S, ID_S} diffusé depuis le serveur vers le groupe de nœuds, et d'une réponse {MAC_P, ID_G} du groupe de nœuds reçue par le serveur.

Après une phase (non montrée) de formation du groupe de nœuds, une phase d'identification (402) comprenant les identités (ID_1, ID_2) des nœuds du groupe (ID_G) est initiée.

Après la phase d'identification, une phase de génération de défi et agrégation des réponses (404) est opérée.

Le serveur (ID_S) génère un premier message (RAND_S, ID_S) envoyé au groupe de nœuds et diffusé au sein du groupe selon l'arbre de routage multicast défini. Le message contient un défi aléatoire (RAND_S) auquel chaque nœud va répondre.

Chaque nœud calcule sa réponse au défi. Comme illustré, le nœud périphérique (ID_1) calcule :

· MAC_P_1 = MAC(AK_1, ID_1, ID_S, RANS_S) , et le nœud agrégateur ID_2 calcule sa réponse :

• MAC_P_2 = MAC(AK_2, ID_2, ID_S, RANS_S) , où AK_1 est la clé partagée entre le nœud ID_1 et le serveur d ' authentification et

AK_2 est la clé partagée entre le nœud ID_2 et le serveur d ' authentification .

Le nœud périphérique (ID_1) envoie sa réponse au nœud agrégateur selon l'arbre de routage inverse dans un message (MAC_P_1, ID-G) . Le nœud agrégateur (ID_2) agrège les réponses reçues, et un agrégé des réponses est généré :

• MAC_P = Θ { MAC (AK_i , ID_P_i, ID_S, RA D_S ) } où ^y MAC_P' désigne la somme XOR des MACs calculés par chaque nœud du groupe identifié par ID_P_i, et où :

• AK_i désigne la clé partagée entre le nœud ID_P_i et le serveur ID_S ; et

• ID_G désigne l'identité du groupe de nœuds.

Un deuxième message est généré à partir des réponses des nœuds agrégées progressivement tout le long de l'arbre de 'reverse multicast' . L'agrégé des réponses est renvoyé vers le serveur d ' authentification .

Les nœuds se sont authentifiés au serveur d ' authentification en démontrant qu'ils sont capables de calculer des valeurs de MAC à partir de leurs clés partagées avec le serveur.

En recevant le deuxième message, le serveur d ' authentification vérifie l'agrégé des réponses (406) . Il calcule la somme XOR des MACs en utilisant les clés partagées avec les nœuds, et compare le résultat avec la réponse reçue.

Si la comparaison est identique, le serveur d ' authentification dérive (408) le matériel cryptographique pour le fournisseur de service et génère (MSK_1) à partir de (AK_1) et (MSK_2) à partir de (AK_2) . « MSK » désigne la « Master Session Key » en anglais, selon la terminologie du protocole (EAP) , et correspond à la clé générée par le serveur et le nœud à l'issue d'une authentification réussie. La MSK est transportée du serveur d ' authentification vers le fournisseur de service.

Le serveur d ' authentification envoie vers le fournisseur de service un message (Succès, ID_1, MSK_1, ID_2, MSK_2) de validation et les éléments cryptographiques générés.

Le fournisseur de service conserve les clés (MSK_1, MSK_2) des nœuds et renvoie un message de validation au groupe de nœuds.

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 1 ' authentification se fasse au travers d'une entité appartenant au domaine du fournisseur du service ou d'autres entités de l'infrastructure, tel que par exemple la passerelle 110. Le serveur d'authentification délègue alors 1 ' authentification à cette entité en lui fournissant le matériel nécessaire pour 1 ' authentification ainsi que des paramètres relatifs à chaque utilisateur. Le matériel pour l 'authentification peut par exemple être des vecteurs d'authentification comme ceux décrits dans [3GPP TS 33.220, "Generic Authentication Architecture (GAA) ; Generic Bootstrapping Architecture (GBA)", Release 11 vil.1.0, December 2011]. Dans une variante avantageuse, plusieurs groupes peuvent être authentifiés en un seul échange. Les identités des groupes et les réponses agrégées associées à un défi commun peuvent être concaténées avant d'être transmises au serveur d ' authentification pour vérification.

Dans une nouvelle variante, l'agrégation peut se réaliser sur des parties de l'arbre de routage multicast. Pour chaque sous-arbre, un groupe multicast est créé dynamiquement et traité selon les principes de la méthode de la présente invention. Les agrégés des réponses sur chacune des parties de l'arbre sont concaténés et transmis au serveur d ' authentification . L ' authentification échoue seulement sur les parties infectées par une attaque de pollution ou d'autres types d'attaques, les nœuds sur les autres parties de l'arbre sont, par contre, correctement authentifiés.

Avantageusement, des routeurs spécifiques dans l'arbre de routage multicast peuvent être définis pour vérifier les agrégés des réponses reçus avant de les transmettre à d'autres routeurs, afin de limiter les attaques de pollution par des routeurs malveillants .

Dans une variante avantageuse, l'arbre de routage multicast peut consister en un réseau logique « overlay » sécurisé composé seulement des membres du groupe avec des associations de sécurité établies entre eux.

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 conservant les mêmes principes.