FR2990094A1 - Methode et systeme d'authentification des noeuds d'un reseau - Google Patents

Abstract

La présente invention concerne un système et une méthode pour authentifier les noeuds d'un réseau de communication afin d'accéder aux services d'un fournisseur de service. L'invention consiste en une authentification collective des noeuds, effectuée en un seul échange entre les noeuds du réseau déclarés en groupe et un serveur d'authentification. Selon le résultat de l'authentification, le fournisseur de service est approvisionné en matériels cryptographiques afin de réaliser un contrôle d'accès individualisé aux ressources ou aux services proposés pour chaque noeud.

Description

2990094 METHODE ET SYSTEME D'AUTHENTIFICATION DES NOEUDS D'UN RESEAU Domaine de l'invention L'invention concerne le domaine de la sécurité dans les réseaux de communication et en particulier l'authentification de noeuds dans les réseaux à faibles ressources.

Etat de la Technique Actuellement, l'authentification des noeuds dans un réseau à faibles ressources se fait d'une manière individuelle. Soit chaque noeud est authentifié avec son identité réelle ou virtuelle, soit il est authentifié en s'identifiant comme membre d'un groupe de noeuds.

Une solution bien connue pour authentifier plusieurs noeuds 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 2 2990094 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 5 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.

10 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 noeuds du 15 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 oeuvre pour l'authentification et le bootstrapping prévoit en particulier de déléguer la capacité 20 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 25 à 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 30 souhaitent s'authentifier auprès de la même BSF. De plus, les vecteurs d'authentification sont strictement 3 2990094 relatifs à un unique utilisateur et doivent être générés pour chaque client par le HSS. Une méthode d'authentification pour les 5 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 noeuds comme une seule 10 unité. Les noeuds 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 noeuds s'authentifient au serveur d'authentification 15 (Authentication center, AuC) comme étant membres de ce groupe. D'une manière similaire, la méthode décrite dans la demande de brevet W02011131052 de Tian Tian et al. intitulée "Procédé et Système d'Authentification par 20 Groupes dans les Systèmes de Communication de Machineà-Machine", permet d'authentifier un groupe de noeuds 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 25 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 30 pour la première méthode, soit entre le serveur d'autorisation et l'ASME pour la deuxième méthode.

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

5 Il existe alors le besoin d'une solution qui permette une authentification collective des noeuds d'un groupe où tous les membres du groupe sont authentifiés en un seul échange.

10 La présente invention répond à ce besoin. Résumé de l'invention 15 Un objet de la présente invention est de fournir une méthode d'authentification collective en un seul échange d'un groupe de noeuds dans un réseau de communication.

20 Un autre objet de l'invention est de permettre à des noeuds d'un réseau de s'authentifier a un fournisseur de service en utilisant un serveur d'authentification et, selon le résultat de l'authentification, d'approvisionner le fournisseur de 25 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 30 lorsque les membres d'un groupe veulent accéder en même temps à des ressources ou à des services 5 2990094 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 5 passante dans le réseau et moins d'énergie au niveau des noeuds, que dans les méthodes d'authentification individuelle des noeuds. Un autre avantage est que le contrôle d'accès aux 10 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 15 le groupe dans un arbre de routage multicast et aux messages d'authentification des noeuds d'être remontés vers le serveur suivant un procédé de reverse multicast, en agrégeant le contenu des messages.

20 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 noeuds d'un groupe échouent lors de l'authentification agrégée.

25 Avantageusement, l'invention permet à un serveur d'authentification d'authentifier et d'exporter pour chacun des noeuds d'un groupe, des paramètres de sécurité, tels que des clés, des droits d'accès, vers 30 le fournisseur de services.

6 2990094 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 5 l'autorisation. Toujours avantageusement mais sans limitation, l'invention trouvera des applications dans les domaines industriels de la sécurité des communications 10 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 15 revendication indépendante 12 et un produit programme d'ordinateur tel que décrit dans la revendication 14 sont proposés. En particulier, une méthode pour 20 authentifier une pluralité de noeuds dans un réseau de communication comprend les étapes de : créer parmi la pluralité de noeuds, un groupe de noeuds à authentifier; générer un défi pour le groupe de noeuds créé; 25 - diffuser le défi vers les noeuds du groupe; agréger les réponses des noeuds du groupe au défi; vérifier l'agrégé des réponses; et confirmer une authentification collective aux noeuds du groupe ou une authentification individuelle 30 selon le résultat de la vérification.

7 2990094 Différentes variantes d'implémentations sont décrites dans les revendications dépendantes.

5 Description des figures Différents aspects et avantages de l'invention vont apparaitre en appui de la description d'un mode 10 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 15 avantageusement l'invention ; La Figure 2 montre les étapes opérées par la méthode de la présente invention pour authentifier les noeuds d'un groupe ; 20 La Figure 3 montre les échanges réalisés entre les noeuds d'un groupe et le serveur d'authentification dans une implémentation préférentielle de l'invention; 25 La Figure 4 illustre une variante d'implémentation des échanges de la figure 3.

30 Description détaillée de l'invention 8 2990094 L'invention s'applique avantageusement dans un réseau formé de noeuds ayant des faibles ressources, et dont certains noeuds doivent accéder à une ressource ou un service associés à une infrastructure distante. Des 5 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.

10 La figure 1 montre un exemple d'un contexte général 100 dans lequel implémenter avantageusement l'invention. Un groupe de noeuds (102) composé d'équipements de faibles ressources doit accéder à des services ou des ressources associés à un fournisseur 15 de service (104) d'une infrastructure distance. Les services ou les ressources requis peuvent être des besoins en connectivité ou en données. Les noeuds peuvent être mobiles ou statiques et sont connectés au réseau distant au travers d'une passerelle (110). Le 20 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 noeuds doivent être authentifiés auprès d'un 25 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 30 figure 1 ne montre qu'un nombre fini d'entités et de connexions, mais l'homme du métier étendra les 9 2990094 principes décrits pour la présente invention à une pluralité et une variété de noeuds d'un groupe et de type de serveurs, passerelle ou connexions (sans fil, mobile, très haut débit).

5 Le réseau de noeuds (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 10 employés. Un tel réseau global forme ce que l'on trouve dénommé comme un internet des objets (Id0). Il couvre deux types de communication : 15 - celles d'objet a personne; - celles d'objet à objet, ou machine à machine (M2M). Ces communications peuvent être établies dans un contexte limité (un seul protocole employé, par 20 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 25 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 30 des schémas de communication décentralisés, tout en mettant en oeuvre des mécanismes autonomes.

10 2990094 Le serveur d'authentification (106), responsable de l'authentification des noeuds, stocke les données cryptographiques nécessaires pour l'authentification 5 de chacun des noeuds du groupe (102). Si l'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 10 droits d'accès) de chacun des noeuds du groupe vers le fournisseur de services (104). Le fournisseur de service établit par la suite une association de sécurité avec chacun des noeuds.

15 Le fournisseur de service (104) peut dans une première variante d'implémentation ne pas être impliqué dans les échanges pour l'authentification des noeuds du groupe (102). Dans ce cas, le serveur d'authentification (106) exporte les paramètres de 20 sécurité associés aux noeuds, après une authentification réussie, dans un message séparé d'un message de succès de l'authentification destiné au groupe des noeuds.

25 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 30 authentification réussie, les paramètres de sécurité sont transférés au fournisseur de services (104), 11 2990094 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 l'authentification destiné au 5 groupe des noeuds ; - dans une seconde variante, les paramètres de sécurité sont transférés avec le message de succès de l'authentification destiné au groupe des noeuds. Cette variante d'implémentation est celle retenue dans la 10 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 noeuds d'un groupe.

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

20 Pour une formation spontanée du groupe, les noeuds 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 noeuds sont envoyées pour 25 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 noeuds reçues. Alternativement, dans le cas d'une formation 30 préalable, le groupe des noeuds est formé en utilisant une adresse de groupe multicast.

12 2990094 Avantageusement, dans une variante d'implémentation, une fois le groupe formé et désigné, un arbre de routage multicast est construit pour 5 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.

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

15 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, 20 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 25 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 30 routage en reverse multicast se base sur le premier arbre de routage multicast, en faisant en sorte que 13 2990094 chaque noeud fils dans l'arbre envoie le message à son noeud père tel qu'identifié par l'arbre de routage multicast. Des entités intermédiaires, comme par exemple la 5 passerelle (110), des « cluster-heads » ou des noeuds intermédiaires du réseau , appartenant ou non au groupe de noeuds se chargent de la diffusion des messages en provenance du serveur d'authentification vers ces noeuds et de l'agrégation des messages des 10 noeuds 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 15 d'authentification vers les noeuds. Si le groupe de noeuds a été formé de manière spontanée selon des critères de regroupement déterminés, chaque noeud répond à réception de la requête par son identité. L'identité de chaque noeud 20 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 25 identités des noeuds soit dans des messages séparés ou concaténées dans un seul message. Si le groupe de noeuds a été formé de manière préalable, chaque noeud répond dès la réception de la requête d'identification par l'identité du groupe 30 (adresse multicast). Le message contenant l'identité du groupe est agrégé tout le long de l'arbre de 14 2990094 routage en « reverse multicast ». Alternativement, la requête d'identification peut ne pas être diffusée au sein du groupe de noeuds mais 5 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.

10 Dans une variante d'implémentation où le serveur d'authentification a connaissance de l'identité des noeuds d'une manière implicite dans le message reçu comme réponse à son défi d'authentification, l'étape 15 d'identification peut alors être omise. A l'étape (206), un échange de message « défi-réponse » se déroule entre les noeuds du groupe et le serveur d'authentification. Avantageusement, l'invention permet d'authentifier un groupe de noeuds 20 en un seul échange. Le serveur d'authentification envoie une requête vers les noeuds. La provenance de la requête est authentifiée par les noeuds au moyen d'un procédé connu d'authentification. L'authentification du serveur peut être faite par une signature MAC avec 25 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 noeuds, les réponses des 30 noeuds sont agrégées en utilisant des fonctions d'agrégation de messages d'authentification qui 15 2990094 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 5 commutatives, comme par d'agrégation de MAC décrits connues d'agrégation exemple les schémas dans par J. Katz et al., "Aggregate message authentication codes", In Proceedings of the 2008 The Cryptopgraphers' Track at the RSA conference on Topics in cryptology, Tal Malkin 10 (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 15 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 20 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.

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

30 Dans une implémentation préférentielle où le groupe de noeuds est identifié par une adresse 16 2990094 multicast, le défi envoyé par le serveur d'authentification est diffusé à tous les noeuds du groupe suivant l'arbre de routage multicast préalablement construit. Les réponses des noeuds sont 5 agrégées par un noeud 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 noeud 10 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 noeuds n'ont pas répondu au défi après un temps d'attente 15 prédéfini, le routeur ajoute à l'agrégé des réponses l'identité des noeuds défaillants dans un message 'NACK'. Le serveur d'authentification peut identifier chaque noeud défaillant ou déconnecté dans l'arborescence de l'arbre de routage multicast et les 20 authentifier directement au moyen d'un protocole d'authentification individuelle. Avantageusement, si un routeur appartient au groupe de noeuds déclaré, il calcule sa propre réponse 25 au défi et collecte les réponses des noeuds 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 30 ne dispose pas de fonction d'agrégation, les réponses reçues sont transmises directement à un autre routeur, 17 2990094 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 5 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 10 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 15 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 20 noeuds. 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 noeuds du groupe et le procédé continue 25 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 noeud selon le résultat de la vérification.

30 Puis, le procédé continue à l'étape (212).

18 2990094 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 5 l'authentification envoyé par le serveur d'authentification aux noeuds 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 noeuds.

10 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, 15 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 20 chaque noeud ayant été vérifié. Le matériel cryptographique est dérivé à partir de matériel que le serveur d'authentification établit individuellement avec chaque noeud. Avantageusement, le serveur d'authentification 25 peut joindre au message de succès une clé de groupe associée au groupe des noeuds et destiné au fournisseur de service, dans le cas où tous les noeuds du groupe se sont authentifiés.

30 Après l'étape (210) de provisionnement complet de matériel de sécurité, le procédé d'authentification 19 2990094 collective est terminé (216). Après l'étape de vérification (208) ayant conduit à un échec ou à un provisionnement partiel de matériel 5 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 10 individuellement les noeuds non authentifiés à l'issue de l'authentification collective. Puis le procédé d'authentification est terminé (216).

15 La figure 3 montre les échanges réalisés entre les noeuds 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 noeuds est formé et les arbres de routage définis.

20 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 25 requêtes de demande d'enregistrement des noeuds à 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 30 de nouveaux membres ou désabonnement de membres. Cette phase reste indépendante du choix du fournisseur de 20 2990094 service. Les arbres de routage 'multicast' et 'reverse multicast' sont créés avec les membres du groupe, dans lequel certains noeuds sont définis comme routeur 5 agrégateur pour agréger les réponses des noeuds périphériques et diffuser une réponse agrégée vers le serveur d'authentification. La phase suivante (304) consiste en 10 l'authentification collective des noeuds 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 noeuds du groupe. Les noeuds répondent et un message 15 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 20 d'authentification génère un défi qui est commun tous les noeuds du groupe. Le défi est diffusé dans l'arbre de routage multicast vers tous les noeuds. Chaque noeud qui opère comme agrégateur initie un compteur qui va mesurer le temps de réponse des noeuds 25 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 noeud du groupe à la requête 30 d'identification après un temps limite écoulé, calculé à partir du RTT dans son sous-arbre multicast, un 21 2990094 accusé de réception négatif « Negative acknowledgement » ou (NACK) est émis. L'absence de réponse peut être due à un état de veille du noeud ou une inaccessibilité ou une défaillance. L'accusé de 5 réception négatif (NACK) est joint par le noeud 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é 10 en reverse multicast, sinon, le routeur ne répond pas à la requête. Les réponses des noeuds au défi sont renvoyées vers un noeud routeur. Le noeud routeur parent dans 15 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 noeud change suivant sa place dans l'arbre de routage 20 « reverse multicast ». Si un noeud 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 noeud agit en tant que routeur dans l'arbre de routage « reverse multicast », il agrège les réponses reçues.

25 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 30 en 'reverse multicast' pour pouvoir déterminer les membres du groupe qui ne vont pas participer à 22 2990094 l'authentification collective du groupe. Le serveur d'authentification vérifie dans une phase (310) le message agrégé reçu.

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

10 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 15 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 20 groupe. Dans une variante d'implémentation où le fournisseur de services n'est pas impliqué dans les échanges d'authentification, le serveur 25 d'authentification exporte les paramètres de sécurité associés aux noeuds, après une authentification réussie, dans un message séparé du message de succès de l'authentification destiné au groupe des noeuds.

30 Dans une autre variante d'implémentation, les échanges d'authentification sont relayés par le 23 2990094 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 5 l'authentification destiné au groupe des noeuds, soit conjointement avec le message de succès de l'authentification destiné au groupe des noeuds. La figure 4 illustre les échanges intervenant 10 dans une implémentation du procédé d'authentification de la présente invention basée sur le protocole EAPPSK. 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 15 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 20 figure 4 s'appuie sur l'exemple de deux noeuds pour simplifier la description mais n'est en rien limitatif. L'implémentation décrite (400) permet l'authentification des noeuds d'un même groupe en un seul échange entre le serveur d'authentification et le 25 groupe de noeuds, échange représenté par un défi {RAND S, ID S} diffusé depuis le serveur vers le groupe de noeuds, et d'une réponse {MAC P, ID G} du groupe de noeuds reçue par le serveur. Après une phase (non montrée) de formation du 30 groupe de noeuds, une phase d'identification (402) comprenant les identités (ID 1, ID 2) des noeuds du 24 2990094 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.

5 Le serveur (ID S) génère un premier message (RAND S, ID S) envoyé au groupe de noeuds 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 noeud va répondre.

10 Chaque noeud calcule sa réponse au défi. Comme illustré, le noeud périphérique (ID 1) calcule : - MAC P 1 = MAC(AK 1, ID 1, ID S, RANS S) , et le noeud agrégateur ID _2 calcule sa réponse : - MAC P 2 = MAC(AK 2, ID 2, ID S, RANS S) , 15 où AK _1 est la clé partagée entre le noeud ID _1 et le serveur d'authentification et AK _2 est la clé partagée entre le noeud ID _2 et le serveur d'authentification.

20 Le noeud périphérique (ID 1) envoie sa réponse au noeud agrégateur selon l'arbre de routage inverse dans un message (MAC P 1, ID-G). Le noeud agrégateur (ID 2) agrège les réponses 25 reçues, et un agrégé des réponses est généré : - MAC P = 10 { MAC(AK i, ID P i, ID S, RAND S) } où 'MAC P' désigne la somme XOR des MACs calculés par chaque noeud du groupe identifié par ID P i, et où : 30 - AK _i désigne la clé partagée entre le noeud ID P i et le serveur ID S ; et 25 2990094 - ID _G désigne l'identité du groupe de noeuds. Un deuxième message est généré à partir des réponses des noeuds agrégées progressivement tout le 5 long de l'arbre de 'reverse multicast'. L'agrégé des réponses est renvoyé vers le serveur d'authentification. Les noeuds se sont authentifiés au serveur 10 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 15 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 noeuds, et compare le résultat avec la réponse reçue.

20 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 » 25 en anglais, selon la terminologie du protocole (EAP), et correspond à la clé générée par le serveur et le noeud à l'issue d'une authentification réussie. La MSK est transportée du serveur d'authentification vers le fournisseur de service.

30 26 2990094 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.

5 Le fournisseur de service conserve les clés (MSK 1, MSK 2) des noeuds et renvoie un message de validation au groupe de noeuds.

10 L'homme de l'art appréciera que des variations peuvent être apportées sur la méthode telle que décrite de manière préférentielle, tout en maintenant les principes de l'invention. Ainsi, il est possible que l'authentification se fasse au travers d'une 15 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 l'authentification à cette entité en lui fournissant le matériel nécessaire 20 pour l'authentification ainsi que des paramètres relatifs a 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); 25 Generic Bootstrapping Architecture (GBA)", Release 11 v11.1.0, December 2011]. Dans une variante avantageuse, plusieurs groupes peuvent être authentifiés en un seul échange. Les 30 identités des groupes et les réponses agrégées associées à un défi commun peuvent être concaténées 27 2990094 avant d'être transmises au serveur d'authentification pour vérification. Dans une nouvelle variante, l'agrégation peut se 5 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 10 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 noeuds sur les autres parties de l'arbre sont, par contre, correctement authentifiés.

15 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 20 les attaques de pollution par des routeurs malveillants. Dans une variante avantageuse, l'arbre de routage multicast peut consister en un réseau logique 25 « 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 30 d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur 28 2990094 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, 5 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).

10 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 15 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. 29

Claims (14)

1. REVENDICATIONS1. Une méthode pour authentifier une pluralité de noeuds dans un réseau de communication comprenant les étapes de : créer parmi la pluralité de noeuds, un groupe de noeuds à authentifier (302); - générer un défi pour le groupe de noeuds créé (306); - diffuser le défi vers les noeuds du groupe (306); - agréger les réponses des noeuds du groupe au défi (308); - vérifier l'agrégé des réponses (310); et confirmer une authentification collective aux noeuds du groupe ou une authentification individuelle selon le résultat de la vérification (312).
2. 2. La méthode selon la revendication 1 dans laquelle l'étape de créer un groupe de noeuds à authentifier comprend de plus une étape d'enregistrer les identités des noeuds du groupe de noeuds à authentifier.
3. 3. La méthode selon la revendication 1 ou 2 comprenant après l'étape de création du groupe de noeuds, une étape de construire un arbre de routage multicast pour diffusion de messages vers les noeuds du groupe. 30 2990094
4. 4. La méthode selon l'une quelconque des revendications 1 à 3 comprenant après l'étape de création du groupe de noeuds, une étape de construire un arbre de routage multicast inverse pour diffusion de messages à 5 partir des noeuds du groupe.
5. 5. La méthode selon l'une quelconque des revendications 1 à 4 comprenant avant l'étape de générer un défi, une étape d'émettre une requête 10 d'identification des noeuds du groupe de noeuds à authentifier.
6. 6. La méthode selon l'une quelconque des revendications 1 à 5 comprenant de plus une étape 15 d'initier un compteur pour mesurer les temps de réponses des noeuds au défi.
7. 7. La méthode selon l'une quelconque des revendications 1 à 6 dans laquelle l'étape de 20 diffusion de la requête d'identification et/ou de diffusion du défi vers les noeuds du groupe se fait selon un arbre de routage multicast.
8. 8. La méthode selon l'une quelconque des revendica25 tions 1 à 7 dans laquelle l'étape d'agrégation des réponses au défi se fait selon un arbre de routage multicast inverse de l'arbre de routage multicast.
9. 9. La méthode selon l'une quelconque des 30 revendications 1 à 8 comprenant avant l'étape de vérification, une étape de transmettre l'agrégé des 31 2990094 réponses selon l'arbre de routage multicast inverse.
10. 10. La méthode selon la revendication 9 dans laquelle l'étape de confirmation comprend de plus une étape 5 de générer un message de succès d'authentification pour chaque noeud authentifié ou un message d'échec pour chaque noeud non-authentifié.
11. 11. La méthode selon la revendication 9 dans laquelle 10 le message de succès comprend de plus du matériel cryptographique ayant des clés, des droits d'accès ou des certificats.
12. 12. Un système pour authentifier une pluralité de 15 noeuds dans un réseau de communication comprenant des moyens pour mettre en oeuvre les étapes de la méthode selon l'une quelconque des revendications 1 à 11.
13. 13. Le système selon la revendication 12 comprenant 20 un serveur d'authentification (106) distant du groupe de noeuds, le serveur étant en communication avec un fournisseur de services (104) apte à recevoir le matériel cryptographique après une authentification collective réussie du groupe de noeuds. 25
14. 14. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes de la méthode selon l'une quelconque des revendications 1 à 11, 30 lorsque ledit programme est exécuté sur un ordinateur.