du réseau.
En ce qui concerne le protocole d’authentification, il doit reposer sur le pro- tocole EAP par la définition d’une méthode d’authentification adéquate. L’inté- gration de cette méthode avec des protocoles AAA existants, comme RADIUS ou Diameter, sera de cette manière possible ainsi que nous l’avons évoqué à la fin de la section 3.2.3.3 du chapitre 3.
D’autre part, cette méthode d’authentification ne doit pas permettre les attaques de type déni de services. Elle doit aussi assurer une authentification mutuelle entre le système fournissant les services AAA et les nœuds arrivants souhaitant accéder aux services souscrits. En effet, alors que, dans le contexte d’un réseau à infrastructure, l’authentification mutuelle n’est pas toujours in- dispensable entre un utilisateur et le serveur AAA de son opérateur, dans un contexte à risque comme celui des réseaux MANETs (cf. section 1.4 du chapitre 1), celle-ci devient impérative.
Enfin, les protocoles conçus doivent pouvoir fonctionner dans un réseau MA- NET utilisant la norme IPv6. Celle-ci apporte non seulement des solutions au problème de pénurie d’adresses IPv4 mais aussi au problème de configuration par les nœuds eux-même de leurs adresses IPv6 (cf. section C.1 de l’annexe C). Il est clair que cette capacité, dotée en plus d’un mécanisme permettant d’éviter le vol d’adresses, ne peut qu’être appréciée dans le cadre des MANETs.
4.2.3
Outils cryptographiques
Les algorithmes cryptographiques nécessaires à la sécurité des opérations d’authentification, d’autorisation et de comptabilité doivent être conçus pour permettre un fonctionnement distribué entre les différents serveurs.
Ils doivent par ailleurs être relativement robustes et peu consommateurs de ressources compte tenu des capacités, souvent limitées des nœuds mobiles, qu’il s’agisse de puissance de calculs, d’espaces mémoires ou d’énergie des batteries (cf. section 1.4.7 du chapitre 1). Les messages obtenus après utilisation de ces outils ont aussi intérêt à être courts afin de limiter l’énergie en émission et en réception.
En plus de garantir l’authentification des différentes parties, la confidentialité de leurs échanges en cas de besoins et l’intégrité de leurs données, les algorithmes et les méthodes cryptographiques choisies doivent parer l’attaque de l’adversaire mobile [76]. Cette dernière consiste à approcher suffisamment de plusieurs nœuds successifs pour obtenir de chacun d’eux des éléments dont l’importance paraît individuellement faible mais dont la conjonction permet une attaque précise contre les outils cryptographiques : la mobilité permet ainsi ce qui est beaucoup plus difficile, voire inaccessible avec les réseaux filaires.
4.3 Architecture proposée
4.3.1
Description et vocabulaire
Deux options se sont présentées à nous pour satisfaire le cahier des charge : distribuer un serveur AAA sur quelques uns des nœuds ad hoc du réseau ou bien le distribuer sur tous les nœuds. Dans la mesure où les protocoles doivent aussi
être distribués amenant plusieurs serveurs, à émettre en même temps, il est clair que le deuxième choix engendre plus de messages que le premier et consomme, donc, une part plus importante de la bande passante du réseau. Nous avons, par conséquent, opté pour la première option : seuls quelques nœuds ad hoc sont désigner pour jouer le rôle de serveurs AAA.
Cependant, en raison de l’organisation sans infrastructure et mobile des MA- NETs, l’entrée des clients dans le réseau n’est pas toujours réalisable à partir d’un point spécifique, par exemple un ou plusieurs nœuds bien identifiés. Il est donc nécessaire d’impliquer tous les nœuds dans les opérations de contrôle d’ac- cès. Donc, tout nœud ad hoc, serveurs AAA compris, doit jouer le rôle d’une entité A2 (cf. les notations de la section 3.3.2 du chapitre 3) capable de vé- rifier le niveau d’autorisation d’un nœud entrant. Il est possible de satisfaire cette contrainte si chaque nœud est conçu comme un client AAA supportant un Enforcement Point (cf. section 3.2.1 du chapitre 3).
Par ailleurs, un nœud qui souhaite accéder au réseau joue classiquement le rôle de client (cf. section 3.2.1 du chapitre 3). Ainsi, dans notre architecture, il jouera, à la fois, le rôle de client et de client AAA, deux rôles à priori différents. Dans le modèle d’architecture AAA décrit à la section 3.2.1 du chapitre 3, le client AAA se trouve entre le client et le serveur AAA. Il transmet les demandes d’accès du premier vers le second. Pour pouvoir confondre les rôles de client et celui de client AAA dans un nœud donné, il suffit, donc, que le client AAA, au sein de ce nœud, génère ses propres demandes d’authentification, opération déjà supportée dans le modèle d’architecture AAA initial. Remarquons que de cette manière il n’est plus nécessaire pour un nœud client de recourir à un client AAA hébergé sur un autre nœud intermédiaire pour envoyer ces demandes d’accès aux serveurs. Ce fonctionnement est appréciable car un nœud intermédiaire serait une cible toute désignée pour un attaquant. D’ailleurs, nous avons déjà cherché à éviter ce type de problème en ce qui concerne l’utilisation du serveur AAA lui-même en le distribuant sur plusieurs nœuds.
Figure 4.1 – Dist-AAA : Architecture AAA destinée à fonctionner dans un MANET
La figure 4.1 montre les différentes entités qui entrent en jeu dans Dist- AAA, l’architecture AAA que nous avons proposée. Il est à remarquer qu’un
4.3 Architecture proposée 81 serveur AAA joue aussi le rôle de client AAA. Nous l’appellerons donc pair AAA ou tout simplement pair. Pour les mêmes raisons de simplification de langage, nous désignerons un client AAA par le nom client. Nous sommes conscients de l’ambiguïté de langage que cela entraîne, c’est pourquoi le tableau 4.1 vient rappeler et résumer ces notations.
notation description
Dist-AAA Nom de l’architecture AAA hiérarchiquement distribuée que nous avons dé- finie
client (AAA) Tout nœud ad hoc du réseau. Il est client AAA au sens du service AAA fonc- tionnant en mode client/serveur. Il est capable d’initier ses propres demandes d’authentification. Par ses fonctions d’EP (Enforcement Point), il renforce aussi les politiques de contrôle d’accès (cf. section 3.2.1 du chapitre 3) en appliquant des règles de filtrage au trafic à relayer
pair (AAA) un nœud ad hoc supportant à la fois les fonctions d’un client AAA et d’un serveur AAA. Il est client AAA quand il s’agit de s’authentifier lui-même pour accéder au réseau et lorsqu’il s’agit de renforcer les politiques de contrôle d’ac- cès. Il est serveur AAA lorsqu’il s’agit d’authentifier un client en collaborant avec d’autres serveurs
Tableau 4.1 – Résumé des notations dans Dist-AAA
Les clients viennent seconder la tâche des pairs en renforçant la politique de contrôle d’accès grâce à leur fonction d’EP. Il apparaît donc que cette ar- chitecture est du type hiérarchique distribué, au sens de la section 3.3.2.4 du chapitre 3 : les pairs sont en haut de l’architecture et les clients sont des entités subordonnées.
4.3.2
Initialisation
Bien que cette thèse ne traite pas du problème de l’initialisation de l’archi- tecture AAA, cette question n’en est pas moins pertinente. On s’en tiendra pour les réponses possibles aux éléments et solutions recensés au chapitre 3.
4.3.2.1 Désignation des pairs AAA
Nous avons vu à la section 3.3.2.2 du chapitre 3 qu’il existe deux procédés de désignation des serveurs :
1. l’élection : des élections sont organisées par tous ou certains nœuds ad hoc du réseau pour sélectionner ceux parmi lesquels le rôle de pairs pourra être joué. Les élections se basent sur un ensemble de critères identiques pour tous les nœuds. Ces critères peuvent porter sur les capacités phy- siques (puissance de calculs du processeur, espace de mémoire, énergie) des terminaux mobiles, sur leur degré de mobilité, sur leur localisation, sur le niveau de confiance qui leur a été accordé par les autres nœuds, etc. Parmi les travaux plus spécifiques traitant de ce problème, on peut citer [77] et [78].
2. la désignation par un tiers de confiance : un tel tiers peut être constitué par un ou plusieurs opérateurs agissant conjointement, un fournisseur de contenus, etc. Lui aussi se base sur un ensemble de critères dans sa sé- lection des serveurs. Certains critères peuvent être communs avec ceux
utilisés pendant les élections tels que les capacités physique ou le degré de confiance qui est, bien entendu, établi par le tiers de confiance et non les nœuds du réseau.
4.3.2.2 Initialisation des bases de données
Éléments d’accréditation Dans les premiers chapitres de cette thèse, nous avons établi que les éléments d’accréditation étaient à la base de la constitution de toute relation de confiance et de tout contrôle d’accès (cf. sections 2.3.3, 2.4.3.1 et 2.5 du chapitre 2 et sections 3.2.3 et 3.3.1.1 du chapitre 3). Dans notre proposition, comme nous sommes dans un cas de MANETs partiellement tributaire, ces éléments sont des certificats publics émis par le tiers de confiance. Ainsi, tout nœud ad hoc est un client qui possède une clé privée associée à une clé publique. Cette dernière est liée à l’identité et à un certain nombre d’informations sur le client, toutes inscrites dans un certificat signé par une autorité placée sous l’administration du tiers de confiance2. Dans notre travail, la forme des certificats utilisés suit la norme X.509 [79]. Nous les désignerons par certificats X.5093.
Bases de données Comme dans la section 3.4.1 du chapitre 3, nous optons pour deux sortes de bases de données installées dans le terminal de chaque nœud :
1. une base des utilisateurs : une base de données contenant l’identifiant, les éléments d’accréditation et le niveau d’autorisation de chaque nœud du réseau. Les identifiants et les niveaux d’autorisation sont initialisés par le tiers de confiance alors que les éléments d’accréditation, c.-à-d. les certificats, sont découverts et ajoutés à la volée au fur et à mesure de l’arrivée des nœuds dans le réseau.
2. une base des utilisateurs autorisés : une base de données contenant les don- nées d’autorisation, notamment des jetons d’accès dans notre proposition (cf. section 4.5.1), et celles de comptabilité où les éléments d’autorisation et les ressources consommées par un client sont renseignées dans une en- trée contenant au départ son identifiant. Les données de comptabilité sont transmises régulièrement aux serveurs AAA.
Il serait possible de penser que de telles bases puissent occuper un volume consé- quent de l’espace disque de chaque nœud. Pourtant dans un réseau d’une cen- taine de nœuds, la taille de chacune des deux bases serait de l’ordre de 100 Ko si l’on utilisait tout simplement un tableau. C’est par exemple la taille d’un tel tableau géré sur le mode d’une feuille de calcul dans un logiciel courant comme Excel de Microsoft ou Numbers d’Apple. Elle serait plus petite encore
2. En effet le tiers de confiance inclut tout un ensemble de services et d’outils qui lui permettent de jouer ce rôle à divers moments du processus AAA (cf. section 3.2.3 du chapitre 3).
3. Un certificat X.509 comporte plusieurs champs, dans l’ordre : le numéro de version de la norme, pour nous la version 2 ; le numéro de série ; l’algorithme de signature de certificat, pour nous RSA ; le nom de domaine de l’autorité de certification, pour nous c’est le même que celui du tiers de confiance ; date limite de validité ; le domaine du détenteur du certificat, il peut être différent de celui du tiers de confiance notamment s’il s’agit de plusieurs opérateurs ; information sur la clé publique, notamment son algorithme, dans notre cas c’est RSA ; d’autres champs optionnels et la signature de l’autorité de certification.
4.3 Architecture proposée 83 en utilisant les outils intégrés dans le système iOS d’un iPhone. Si la taille d’un certificat peut être estimé à 4 Ko, soit 400 Ko pour 100 nœuds, un volume de données d’environ 600 Ko par nœud sera alors à stocker. Sachant que la capa- cité totale du disque d’un iPhone de 3èmegénération est de 7 Go, cela représente
0,0008 %, autant dire que c’est négligeable.
4.3.3
Évolution
Au cours de la vie du réseau, et après la phase d’initialisation, d’autres nœuds peuvent rejoindre le réseau ou le quitter. Le nombre de pairs AAA peut évoluer lui aussi en fonction du nombre total de nœuds dans le réseau. Un nombre insuffisant de pairs peut entraîner l’indisponibilité du service AAA. Au contraire un trop grand nombre entraînerait un gaspillage de la bande passante. Nous donnerons des exemples de tels dis-fonctionnements tout au long de ce chapitre et du chapitre suivant (cf. en particulier la section 7.2 du chapitre 7). Cela étant noté, nous n’effectuerons pas d’études permettant de trouver le nombre adéquat de pairs AAA dans un réseau donné.
Fred,
Le Naufragé du « A » :
découverte du premier A