<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="fr">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Modélisation et Gestion de la Confiance dans les Réseaux Mobiles Ad hoc</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Abdesselem</forename><surname>Beghriche</surname></persName>
							<email>abdesselem_beghriche@hotmail.com</email>
							<affiliation key="aff0">
								<orgName type="department">Département d&apos;informatique</orgName>
								<orgName type="institution">Université de Batna-Algérie</orgName>
								<address>
									<addrLine>05, avenue Chahid Boukhlouf</addrLine>
									<postCode>05000</postCode>
									<settlement>Batna-Algérie</settlement>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Azeddine</forename><surname>Bilami</surname></persName>
							<email>abilami@yahoo.fr</email>
							<affiliation key="aff0">
								<orgName type="department">Département d&apos;informatique</orgName>
								<orgName type="institution">Université de Batna-Algérie</orgName>
								<address>
									<addrLine>05, avenue Chahid Boukhlouf</addrLine>
									<postCode>05000</postCode>
									<settlement>Batna-Algérie</settlement>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Modélisation et Gestion de la Confiance dans les Réseaux Mobiles Ad hoc</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">ED904A8EE31D2B77EAD6CECCD6923DAD</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T00:19+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Réseaux mobiles Ad hoc</term>
					<term>Sécurité</term>
					<term>Confiance</term>
					<term>Réputation</term>
					<term>Algorithmes distribués</term>
					<term>Infrastructure à clé publique (PKI)</term>
					<term>Mécanisme de surveillance</term>
					<term>IEEE 802.11 et Clustering</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Les réseaux mobiles Ad hoc annoncent les réseaux de communication du futur où la mobilité en est l'idée maîtresse. Ces réseaux devront être capable d'interconnecter des mobiles, à la volée et de bout en bout, pour leur fournir des services de manière omniprésente. Ils sont de ce fait plus vulnérables à de nombreux types d'attaques. Leur succès dépendra sans aucun doute de la confiance qu'ils apporteront à leurs usagers. Les modèles de confiance traditionnels ne répondent pas aux nouvelles exigences de tels réseaux dont les caractéristiques les rapprochent de plus en plus des modèles sociaux. Dans ce papier notre approche consiste à modéliser et gérer la confiance dans une architecture Ad hoc hiérarchique distribuée. La solution envisagée est de faire reposer la prise de décision d'un échange sur la base de la confiance, sachant que chaque noeud ne pourra se protéger d'éventuels voisins malicieux qu'en faisant appel aux informations locales dont il dispose. Notre modèle de gestion de la confiance a donc pour objectif d'intégrer des mécanismes contrant les attaques actives, en forçant la coopération entre les noeuds, et détectant les comportements défaillants.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="fr">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Les réseaux Ad hoc sont des réseaux sans fil sans infrastructure fixe. Les noeuds doivent donc collaborer pour organiser l'échange d'informations de contrôle et permettre l'acheminement du trafic. Ces réseaux doivent posséder la capacité de s'auto-configurer, sans intervention humaine. Suivant la définition de groupe MANET (Mobile Ad hoc NETwork) de l'IETF (Internet Engineering Task Force) <ref type="bibr">[4]</ref>, un réseau Ad hoc mobile, est un système autonome de noeuds mobiles reliés par des liens sans fil dont l'union forme un graphe arbitraire.</p><p>Un réseau MANET possède des exigences spécifiques en terme de sécurité, du fait de ses particularités : liens sans fil, contraintes d'énergie, limitation de la bande passante et de la puissance de calcul, connectivité non permanente d'un noeud avec les autres noeuds. Ces caractéristiques rendent les réseaux Ad hoc mobiles sophistiqués et capables d'opérer dans des conditions difficiles, mais aussi vulnérables aux différents problèmes de sécurité, comme la gestion des clés de chiffrage, distribution des certificats, gestion de confiance entre les noeuds, la coopération, etc. Dans ces réseaux, le problème principal ne se situe pas au niveau du support physique, mais principalement dans le fait que tous les noeuds sont équivalents et potentiellement indispensables (fonction de routage) au fonctionnement du réseau. Les possibilités de La question de la confiance s'est appliquée dans le monde des télécommunications avec des modèles reposant sur la connaissance au préalable des identités. Si aucune information n'est transmise au préalable, la confiance ne s'établit pas, elle n'est pas adaptative <ref type="bibr">[6]</ref>. C'est bien cette condition qui rend ces modèles contraignants et binaires, imposant aux entités communicantes qu'elles soient d'abord connues puis reconnaissables (identifiées et authentifiées) tout au long de l'échange (maintien de la confiance). Si la connaissance préalable des identités est possible pour des réseaux maîtrisés, elle ne peut pas naturellement s'imposer à des réseaux dont les caractéristiques sont tout le contraire : topologie réseaux fortement dynamique, passage à l'échelle incontrôlé et population anonyme.</p><p>Dans ce papier, nous allons concentrer sur notre architecture de sécurité proposée dans <ref type="bibr" target="#b12">[13]</ref>, pour développer les systèmes dynamiques de gestion de clés adaptés aux caractéristiques du réseau Ad hoc. Nous proposons un modèle de confiance probabiliste basé sur le principe de la réputation pour définir la connectivité entre les noeuds de confiance, afin de mettre en place un bon modèle de gestion de la confiance a pour objectif d'évaluer la robustesse de notre nouvelle architecture dans le but de sécuriser les réseaux MANETs.</p><p>Le présent papier est organisé comme suit : nous décrivons dans la section 2, les solutions proposées dans la littérature, qui traitent de la distribution et de la gestion des clés dans l'environnement des réseaux MANETs. Dans la section 3, nous présentons notre architecture de sécurité en expliquant les objectifs de notre modèle de confiance et les modules de surveillance et gestion de groupe. Enfin, et avant de conclure, nous discutons et commentons dans la section 4, les résultats obtenus par simulation de la solution proposée.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Positionnement bibliographique</head><p>Un cadre de gestion de la confiance doit permettre à une entité de prendre une décision en fonction de son expérience et d'une analyse des risques encourus. L'idée principale est d'évaluer le trait prévisible d'une autre entité et d'établir le niveau de confiance qu'il lui est porté, c'est-à-dire paraît-il digne de confiance ? Est-il honnête dans les réponses aux requêtes? Dans <ref type="bibr" target="#b13">[1]</ref> les auteurs montrent qu'un tel cadre de gestion de la confiance peut revêtir trois formes :</p><p>Les systèmes de Credentials (à base de certificats). Les systèmes de réputation et de recommandation. Et les systèmes développés à partir du réseau social de l'utilisateur.</p><p>Les deux premiers systèmes reposent en général sur une infrastructure à clefs publiques et sont aujourd'hui les plus répandus. Ils garantissent l'identité de chaque entité par l'émission d'un certificat. L'autorité peut se répartir suivant deux modèles : centralisé ou distribué. Le modèle distribué offre une meilleure disponibilité du service du fait de la décentralisation des informations de confiance mais se heurte cependant à la difficulté de répartir la clef privée avec cohérence entre chaque membre. Dans le modèle distribué, l'autorité est distribuée en plusieurs entités de certification, La cryptographie à seuil est en charge de la problématique de la distribution des clefs privées.</p><p>Les modèles partagés ne gèrent pas l'identité des entités, et sont statiques. Le secret, distribué au préalable, identifie le groupe et se partage entre l'ensemble des membres. L'authentification s'effectue sur la connaissance du secret partagé. La compromission d'un seul membre met en danger l'ensemble du groupe.</p><p>Les modèles coopératifs ne nécessitent pas la présence du tiers de confiance. Chaque entité contribue au calcul du secret du groupe.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">Le système de Credentials</head><p>Ce cadre repose sur la mise en place d'une ou plusieurs politiques de sécurité et d'un système de certificats : les noeuds utilisent la vérification des certificats pour établir un lien de confiance avec les autre noeuds <ref type="bibr">[2]</ref>. Le principal but de tels systèmes est de permettre le contrôle d'accès. En conséquence, leur concept de gestion de la confiance se limite aux règles de politiques définies par chaque application <ref type="bibr" target="#b2">[3]</ref>.</p><p>Un noeud rendra accessible à un autre noeud un service dont l'accès est normalement restreint seulement si ce dernier peut lui prouver la validité d'un certificat.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Le système de réputation et de recommandation</head><p>Dans ce cadre, la gestion de la confiance repose sur un modèle de réputation et/ou de recommandation. La réputation peut-être vue comme l'espérance portée dans la réalisation d'un objectif fictif. La recommandation serait la qualité supposée d'un noeud qu'il détiendrait d'un tiers et qu'il présenterait à un autre noeud. De tels systèmes fournissent un mécanisme pour lequel un noeud demandant une ressource peut évaluer la confiance qu'il porte au fournisseur à la lui fournir, Chaque noeud établit ainsi des relations de confiance avec les autres noeuds et assigne des valeurs de confiance à ses relations <ref type="bibr">[14]</ref>. La valeur assignée à la relation de confiance est fonction d'une combinaison entre la réputation globale du noeud et l'évaluation de la perception du noeud, c'est-à-dire basée sur son expérience propre.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.3">Confiance à partir d'un réseau social</head><p>Enfin dans ce cadre, le réseau social sous-jacent conditionne le cadre de gestion de la confiance. Les relations sociales sont utilisées pour calculer les valeurs de réputation et de recommandation entre chaque noeud. De tels systèmes analysent le réseau social qui représente les relations existantes dans chaque communauté dans le but de tirer des conclusions sur les niveaux de confiance à accorder aux autres noeuds, Ils reposent sur des mécanismes de réputation, de crédibilité, d'honnêteté et également des procédés de recommandations. Les exemples de tels systèmes de gestion inclus Regret <ref type="bibr">[11]</ref> qui identifie les différents groupes en utilisant directement le réseau social et NodeRanking <ref type="bibr" target="#b9">[10]</ref> qui tente d'identifier des experts par le biais du réseau social.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">Architecture Ad hoc sécurisée</head><p>Pour sécuriser les réseaux Ad hoc, nous envisageons une architecture hiérarchique <ref type="bibr" target="#b12">[13]</ref> pour distribuer le rôle de l'autorité de certification (CA) sur les noeuds qui bénéficient d'un certain niveau de confiance pour la sécurité et d'une certaine stabilité pour optimiser la charge du réseau et augmenter la durée de vie du réseau. Cette architecture est composée d'un modèle de confiance sur lequel la sélection des chefs du groupe (leaders) est basée. Pour atteindre cet objectif nous proposons un algorithme d'élection distribué (AED) <ref type="bibr" target="#b12">[13]</ref> qui consiste à diviser le réseau sous forme de groupes, avec un noeud chef de groupe pour chaque Cluster (groupe). Le rôle de l'autorité de certification est affecté au noeud chef de groupe qui doit disposer d'un certain niveau de confiance et une meilleure stabilité par rapport à ses noeuds voisins.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Description de l'architecture proposée</head><p>Le concept de sécurité proposé dans cette architecture repose sur les idées suivantes : Définir une architecture Ad hoc basée sur la division du réseau avec un seul chef par groupe (Cluster). Crée une atmosphère de confiance entre toutes les entités du groupe, en utilisant un modèle de confiance hybride, distribué et coopératif fondé sur des éléments que nous suggérons, et qui sont nourris par les interactions de l'entité communicante avec son environnement. Dans chaque groupe, élire un noeud chef (Cluster Head), parmi les noeuds qui disposent d'un niveau de confiance plus élevé. Mettre en ouvre la cryptographie à seuil pour sécuriser les interactions inter groupes. Maintenir l'architecture de sécurité le plus longtemps possible.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Modèle de confiance proposé</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2.1">Principe</head><p>Le modèle de confiance proposé consiste à fournir les mécanismes nécessaires pour associer un niveau de confiance à chaque noeud du système via sa table de routage. Un mécanisme basé sur la notion de réputation est mis en place. Toutefois, si un noeud réussi très régulièrement à acheminer un paquet de données avec un même noeud, sa réputation peut devenir importante et donc autoriser des accès à des services plus évolués dans le groupe (notamment le service d'authentification). Dans le type de ces réseaux la notion de réputation est limitée à des interactions de type un à un, et donc n'aura que très peu d'impact sur le réseau. Pour augmenter la portée dans notre modèle, nous proposons d'introduire un autre mécanisme basé sur le principe de recommandation. La confiance locale pour une entité (noeud ou participant) peut donc être transmise, l'acceptation d'une recommandation étant assujettie également au degré de confiance accordé à l'entité qui propose cette recommandation.</p><p>Cependant, la question qui se pose ici, est comment publier la confiance dans notre modèle tout en garantissant sa validité ? Pour cela, on va définir quelques paramètres qui peuvent assurer le déroulement de notre modèle :</p><p>Nous supposons qu'il existe une relation sociale entre les noeuds dans le but d'établir des relations de confiance. Aussi chaque noeud possède une paire de clés privées/publiques. Initialement, les noeuds de confiance se connaissent entre eux (climat de confiance) (l'identité et la clé publique) et ils sont considérés comme des noeuds honnêtes qui ne doivent pas générer des faux certificats.</p><p>Un seuil de confiance Sc (Sc : valeur continue dans l'intervalle : ]0, 1]), et une valeur de réputation (Vr) (Vr : valeur continue dans l'intervalle : [0, 1]). Un noeud (i) possède un seuil de confiance plus élevé (Sc (i) = 1), s'il est connu par d'autres noeuds de confiance et a échangé les clés via un canal sécurisé (rencontre physique par exemple) <ref type="bibr" target="#b12">[13]</ref> avec un ou plusieurs noeuds de confiance. Un seuil de confiance très élevé, existe aussi si le noeud a prouvé sa totale coopération et son bon comportement (Vr = 1) (principe de réputation). Si un nouveau noeud est ajouté à la liste des noeuds de confiance par un ou plusieurs noeuds de confiance, les autres noeuds doivent mettre à jour leurs listes des noeuds de confiance. Chaque noeud dispose dans sa table de routage de deux tables (une table de confiance et une table de réputation), qui seront actualisées à chaque changement de Sc et/ou de Vr. Chaque noeud inconnu commence avec le plus bas seuil de confiance (Sc = 0.1) et le plus bas niveau de réputation (Vr = 0). L'idée de ce principe consiste à obliger les noeuds inconnus à coopérer et bien se comporter <ref type="bibr">[8]</ref>. Pour estimer le chemin de confiance entre deux noeuds, on propose de prendre la valeur minimum entre leurs deux seuils de confiance.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2.2">Fonctionnement :</head><p>Lorsque deux éléments d'un groupe veulent communiquer sans connaissance préalable, ils s'échangent leur liste de certificats et vont essayer de créer une chaîne de confiance entre eux (Figure <ref type="figure" target="#fig_0">1</ref>). Supposons qu'un élément x veuille communiquer avec un autre élément (noeud) z, si x fait confiance en un troisième élément y, et z fait aussi confiance en y, alors une chaîne de confiance entre x et z pourra être établie via y (le principe de recommandation). Dans ce cas, x peut donner physiquement sa clé publique à y (main à main ou par téléphone, etc.) l'élément y connaît x et donc signe sa clé publique. Puis il redonne la clé signée et en garde une copie. Quand x veut communiquer avec z, il lui envoie une copie de la clé que y a signée. Le noeud z, qui a déjà la clé publique de y (il l'a eu à un autre moment) et qui fait confiance à y pour certifier les clefs d'autre noeuds, vérifie sa signature sur la clé de x et l'accepte. De ce fait y a recommandé x à z. Notre modèle de confiance commence par instaurer à la place d'une autorité centrale de certification un climat de confiance entre toutes les entités du groupe. Ensuite le modèle va donner à chaque noeud connecté les deux valeurs (Sc, Vr) selon son état dans le réseau (noeud de confiance, noeud de réputation, noeud visiteur, noeud inconnu, etc.), et qui à partir de ces valeurs, le noeud peut authentifier ou s'authentifier au sein de notre groupe.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Architecture distribuée Clusterisée</head><p>Le réseau dans notre architecture est divisé en plusieurs Clusters afin d'éviter le trafic à longue portée et d'augmenter la disponibilité en fournissant les services locaux, ainsi que d'assurer une tolérance aux pannes. Si une tentative d'intrusion est détectée suffisamment tôt, les réponses de notre peuvent permettre de limiter localement les conséquences d'une attaque. La formation des Clusters est faite automatiquement. Tout Cluster se voit affecté un chef (Cluster-head "CH"). Le noeud CH émet périodiquement la liste des noeuds et des passerelles appartenant au Cluster.</p><p>Les caractéristiques principales de notre architecture sont énumérées comme suit :</p><p>Le système n'a besoin d'aucun tiers de confiance central. Ce système est dynamiquement adapté à tout changement de topologie. La fonction d'authentification est distribuée à chaque groupe. Les noeuds ayant un degré de confiance élevé contrôleront le comportement de chaque noeud ayant un degré de confiance faible au sein du groupe. La stabilité de la gestion des clés publiques dépend de la stabilité du groupe. La couche réseau : les noeuds chargés du contrôle surveillent les activités de transmission de paquets de leurs noeuds voisins, qui ont un degré de confiance faible. Cette idée est basée sur le paramètre de coopération des noeuds dans le réseau. La définition de ce paramètre consiste à calculer pour chaque noeud la proportion de paquets bien retransmis par rapport au nombre total de paquets devant être transmis sur une certaine période. Cette période est la période qui consiste à collecter les informations données par les noeuds pour calculer le niveau de réputation. Soient deux noeuds X et Y avec Sc(X) &gt; Sc(Y), dans ce cas, le noeud X peut contrôler le noeud Y. Le noeud X envoie un certain nombre de paquets de données au noeud Y avec un autre noeud comme destination, et après une période de temps limitée, le noeud X peut calculer le niveau de réputation :</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3.1">Contrôle des noeuds et gestion des groupes</head><formula xml:id="formula_0">) , ( ) , ( ) , ( 2 1 Y X Y X Y X R R R + = R 2 (X, Y) =</formula><p>Comme nous avons déjà expliqué précédemment, chaque noeud inconnu commence avec une valeur de réputation la plus faible (Vr = 0) et ce degré augmente au fur et à mesure que le noeud prouve sa coopération et son bon comportement. Les niveaux de réputation générés par les noeuds sont liés aux degrés de confiance correspondant à chaque noeud. Telle est la tâche du chef de groupe. Le rapport final R(X, Y) concernant la valeur de réputation Vr fourni au noeud Y généré par chaque noeud chargé du contrôle X, est : B) Gestionnaire du groupe : est constitué de l'autorité de certification du groupe (le noeud CA) et d'un ensemble de noeuds ayant des degrés de confiance élevés (les noeuds qui constituer le climat de confiance). Le rôle de gestionnaire du groupe est d'assurer la sécurité du groupe là où le noeud CA génèrera un certificat pour les membres du groupe.</p><p>(2)</p><formula xml:id="formula_1">∑ = = k i i i r y R Sc k y x x R 1 ) , ( * ) ( 1 ) ( (3)</formula><p>Le module gestionnaire du groupe collecte le rapport de réputation des membres du groupe. Les noeuds chargés du contrôle génèrent des rapports évaluant la réputation de leurs voisins sur demande. Le noeud CA exige que les noeuds chargés du contrôle génèrent le rapport de réputation des noeuds. Lorsque le CA reçoit le rapport d'évaluation de réputation envoyé par les noeuds chargés du contrôle, le calcule du rapport de réputation finale de chaque noeud est effectué comme indiquer dans l'équation ci-dessous. Si le CA reçoit k rapports de la part des noeuds chargés du contrôle, pour évaluer le noeud y, alors :</p><p>Lorsque le noeud CA possède les rapports de réputation, la classification des comportements est effectuée pour classer les noeuds. Si le rapport de réputation dépasse un certain seuil, le degré de confiance augmente, sinon, le degré de confiance ne change pas. Cependant, si le rapport est en dessous d'un certain seuil, le degré de confiance diminue et les noeuds se comportant mal seront punis. Dans le cas où les noeuds ont un rapport négatif plusieurs fois (récidivistes), les noeuds se comportant mal seront rejetés du groupe et le CA informe les autres CA de groupes adjacentes de la récidive des noeuds se comportant mal.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3.2">Algorithme d'élection distribué (AED)</head><p>La formation des Cluster dans l'architecture proposée se fait par l'élection des Clusterheads et par la ré-affiliation des noeuds à ces Cluster-heads. Contrairement à beaucoup d'algorithmes dans la littérature, le mécanisme d'élection des Cluster-heads n'est pas synchronisé entre tous les noeuds du réseau. Il n'implique pas que tous les noeuds exécutent en même temps la procédure d'élection. La décision d'être Cluster-head est effectuée par chaque noeud ne détectant pas dans le k-voisinage un Cluster-head à qui s'affilier. Il diffuse alors un message "MES" dans son k-voisinage tout en indiquant son seuil de confiance. Chaque noeud qui reçoit un message "MES" compare le seuil de confiance de son Cluster-head avec le seuil de confiance reçu dans ce message. Si le seuil reçu est supérieur, il peut se joindre à ce nouveau Cluster-head sous certaines conditions. Notons qu'une ré-affiliation peut se produire lorsque : Un noeud membre se déplace d'un Cluster à un autre. Un noeud membre devient un Cluster-head.</p><p>Nous avons opté pour une élection du noeud CH "CA" selon un algorithme de Clustering distribué AED (Algorithme d'Election Distribué). Cet algorithme sera implémenté selon les critères suivants :</p><p>1. Pour chaque Cluster, il existe un seul CH. 2. Seulement les noeuds de confiance qui peuvent être candidats au statut CH "CA". 3. Chaque chef de groupe est le CA d'un seul groupe. 4. Les noeuds qui appartiennent au groupe doivent être à (k) sauts du noeud CA tels que (k) est la taille du groupe à définir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>5.</head><p>Le noeud passerelle Np, sera sélectionné parmi les noeuds de confiance voisins au CA. 6. Les noeuds membres Nm, ce sont les noeuds qui appartiennent au groupe.</p><p>Notre algorithme est basé sur l'émission périodique des paquets balise par les noeuds de confiance vers leurs voisins à chaque période de temps prédéfinie. Chaque paquet balise contient les informations nécessaires pour l'élection d'un noeud CA. La sélection d'un noeud CA est basée sur deux critères principaux : la sécurité et la stabilité.</p><p>Le paramètre de la sécurité dépend de la valeur de confiance, uniquement les noeuds (i) avec (Sc (i) = 1) et au moins un noeud de confiance comme voisin direct qui peuvent se présenter comme candidats pour devenir un CA dans un groupe. Cette condition est nécessaire pour la formation des groupes. Pour renforcer la sécurité, l'algorithme sélectionne le candidat avec un nombre maximum de voisins de confiance, cela indique aussi le degré de confiance dans le groupe.</p><p>Le paramètre de la stabilité est très important pour la formation des groupes, ce paramètre est défini comme la durée de vie d'un groupe. Plusieurs stratégies sont utilisées par des algorithmes proposés dans la littérature, comme Lowest-ID [5] Mobic [9], l'idée consiste à sélectionner le noeud dont l'identité est la plus petite. Dans notre algorithme, nous avons adopté la métrique de mobilité comme paramètre de stabilité.</p><p>La métrique de mobilité est basée sur le niveau de puissance du signal à la réception sur chaque noeud, c'est un indicatif de distance relative entre les noeuds émetteurs et récepteurs.</p><p>Le ratio Rα entre les transmissions de deux paquets successifs, donne une connaissance sur la mobilité relative entre deux noeuds voisins X et Y <ref type="bibr">[8]</ref>.</p><p>Le calcul de la mobilité relative d'un noeud Y par rapport à ses n voisins, consiste à calculer la variance de l'ensemble de mobilité relative Rm y de ses voisins X i : Une faible valeur de Rm y indique que Y est moins mobile par rapport à ses voisins. Par contre, une grande valeur de Rm y montre que le noeud Y est très mobile par rapport à ses voisins.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Evaluation de performances</head><p>Nous avons mené une série de simulations afin d'évaluer les performances du mécanisme de Clustering proposé. Nous avons utilisé pour cela le simulateur NS-2 [12], dans lequel nous avons implémenté notre algorithme décrit précédemment. L'utilitaire « setdest » de NS-2 a été utilisé pour générer les scénarios de mobilité des noeuds selon le modèle de mobilité «Random Waypoint ». Nous avons fait varier la vitesse des noeuds en maintenant les temps de pause constants.</p><p>Dans cette simulation, notre modèle est établi selon les paramètres suivants : Nous remarquons une grande différence au niveau de la portée de transmission à 50 m, cela est dû à notre condition de formation de groupes (Clusters), un noeud de confiance tout seul ne peut pas former son propre groupe, il doit avoir au moins un noeud voisin de confiance. Dans cette simulation, le nombre de groupes formés ne doit pas dépasser 25 groupes. Cependant, avec la portée de transmission entre 50 et 125 m, le nombre de groupes diminue et lorsque la porte de transmission dépasse les 150 m, le réseau devient plus stable et le nombre de groupes devient plus ou moins stable. Avec des groupes de taille égale à 2 sauts (k=2), nous obtenons moins de groupes que dans le cas de Mobic et Lowest-ID. participer à l'élection du noeud CA. Seuls les noeuds de confiance peuvent être candidats au rôle de CA. Si un noeud malicieux tente de s'introduire dans le processus d'élection, cela soit par l'annonce de sa candidature, soit par la manipulation non autorisée de l'information des paquets balises d'élection, les noeuds de confiance le détectent au niveau de la phase d'authentification dans l'algorithme AED. Supposons que les noeuds malicieux ont réussi à former leurs groupes et qu'ils tentent de communiquer avec d'autres groupes, les noeuds CAs des groupes de destination authentifient le noeud CA du groupe source, enfin, selon le résultat de l'authentification et après l'évaluation du seuil de confiance de chaque noeud, les noeuds CAs décident d'accepter ou de rejeter la communication.</p><formula xml:id="formula_2">α α R R Rm</formula><p>L'approche de notre modèle de gestion de la confiance oblige les noeuds à collaborer et à adopter un bon comportement pour l'obtention d'un niveau de confiance plus élevé.</p><p>Dans notre modèle de gestion de la confiance :</p><p>Toutes les communications venant des noeuds ou des groupes malicieux sont ignorées.</p><p>Les attaques de type déni de service (DoS) sont évitées par les noeuds de confiance qui filtrent toutes les requêtes venant des noeuds inconnus.</p><p>Les noeuds malicieux peuvent utiliser l'identité des noeuds légitimes uniquement si leur clé privée est divulguée. Si un attaquant tente de compromettre tout le réseau, il doit compromettre tous les noeuds de confiance. La taille du groupe doit être adaptée au nombre de noeuds de confiance pour bien sécuriser le noeud CA (un compromis entre les noeuds de confiance et les noeuds inconnus doit être trouvé). La présence de deux noeuds de confiance est une configuration minimale pour former un groupe.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Conclusion</head><p>Dans cet article, nous avons proposé un modèle de connectivité de confiance pour étudier la robustesse de la sécurité au sein des groupes. Nous avons proposé une nouvelle architecture distribuée basée sur un modèle de confiance et un algorithme d'élection et de formation de groupes, dans le but de distribuer l'autorité de certification (CA). L'algorithme d'élection de formation des groupes et d'élection de CA est basé sur deux paramètres : la sécurité et la stabilité. La sécurité est un paramètre lié au modèle de confiance proposé, seuls les noeuds de confiance qui peuvent jouer le rôle de CAs. La stabilité est un facteur basé sur la métrique de mobilité pour assurer la stabilité des groupes. Nous avons aussi présenté les différents modules de l'architecture : le modèle de confiance, le processus d'élection, le gestionnaire de groupe et le module chargé du contrôle basé sur le principe de réputation. L'architecture proposée capable d'offrir un niveau de sécurité adapté à l'enjeu de la communication dans un environnement hostile, et dont le niveau pourra évoluer dans le temps en fonction du contexte. Cette architecture est adaptée au changement dynamique de topologie du réseau. Les résultats de la simulation montrent que l'algorithme que nous avons proposé pour la formation des groupes est mieux que les algorithmes proposés dans Mobic et Lowest-ID. Nous avons aussi remarqué que la disponibilité, la robustesse et la stabilité des groupes permet de conserver l'énergie et d'augmenter la durée de vie du réseau.</p><p>Finalement, on peut dire que la conception d'une solution efficace pour sécuriser les réseaux MANETs doit être adaptée aux caractéristiques et spécificités d'un tel environnement, telles que la mobilité et la dynamicité des membres, les ressources limitées en termes d'énergie, de bande passante et de capacités de stockage et de calcul, ainsi que l'absence d'infrastructure fixe au sein du réseau. Les services de sécurité offerts par un protocole de sécurité de groupe dans un réseau Ad hoc, sont également étroitement liés à la nature de l'application à sécuriser et ainsi au niveau de sécurité requis pour les données envoyées par la source pour faire face aux attaques malicieuses qui peuvent le cibler.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Fig. 1 .</head><label>1</label><figDesc>Fig. 1. Création d'une chaîne de confiance</figDesc><graphic coords="6,180.42,138.36,251.52,221.58" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Tableau 1 .</head><label>1</label><figDesc>Paramètres de simulation La (Figure 2) montre la comparaison entre notre algorithme d'élection (AED) et deux autres algorithmes : Mobic [9] et Lowest-ID [5].</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Fig. 2 .</head><label>2</label><figDesc>Fig. 2. Comparaison entre notre algorithme (AED), Mobic et Lowest-ID</figDesc><graphic coords="10,196.20,458.40,200.28,138.36" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head></head><label></label><figDesc>La couche MAC : les noeuds responsables du contrôle surveillent l'occupation du canal de communication par leurs voisins. Cette opération consiste à mesurer la durée de l'occupation du canal par des noeuds. Le but de cette fonction est de détecter les noeuds qui exercent un certain type de comportement égoïste [8], les noeuds égoïstes trichent en choisissant leur backoff, dans le but d'obtenir une bande plus importante et de pénaliser les noeuds qui se comportent bien. Nous supposons que les noeuds chargés du contrôle à ce niveau génèrent un rapport noté R 1 (R 1 correspond l'estimation du confiance d'un noeud de confiance (Sc (i) = 1) sur ses voisins qui ont un degré de confiance faible). (Dans notre contribution, nous ne nous focalisons pas sur le contrôle de la couche MAC).</figDesc><table><row><cell cols="2">A) Contrôle des noeuds : Dans le module de contrôle, chaque noeud ayant un degré de</cell></row><row><cell cols="2">confiance élevé contrôle ses noeuds voisins, c'est à dire ceux qui ont un degré de</cell></row><row><cell cols="2">confiance faible. Dans le cas que nous étudions, le processus de contrôle agit sur deux</cell></row><row><cell>couches différentes du réseau :</cell><cell></cell></row><row><cell>A.</cell><cell></cell></row><row><cell>Nombre des paquets acheminés</cell><cell>(1)</cell></row><row><cell>Nombre total des paquets</cell><cell></cell></row></table></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<title level="m" type="main">A survey of trust management and resource discovery technologies</title>
		<author>
			<persName><forename type="first">G</forename><surname>Suryanarayana</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">N</forename><surname>Taylor</surname></persName>
		</author>
		<imprint/>
	</monogr>
	<note>in peer-to-peer applications</note>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Decentralized trust management</title>
		<author>
			<persName><forename type="first">M</forename><surname>Blaze</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Feigenbaurn</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Lacy</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">IEEE Symposium on Security and Prioacy</title>
				<imprint>
			<publisher>IEEE Computer Society</publisher>
			<date type="published" when="1996">1996</date>
			<biblScope unit="page" from="164" to="173" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">A survey of trust in internet applications</title>
		<author>
			<persName><forename type="first">T</forename><surname>Grandison</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Sloman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">IEEE Communications Surveys and Tutorials</title>
		<imprint>
			<biblScope unit="volume">3</biblScope>
			<biblScope unit="issue">4</biblScope>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">The Quest for security in mobile Ad hoc Networks</title>
		<author>
			<persName><forename type="first">J</forename><forename type="middle">P</forename><surname>Hubaux</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><surname>Buttyan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Capkun</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of ACM symposium on mobile Ad hoc Networking and Computing (Mobihoc)</title>
				<meeting>ACM symposium on mobile Ad hoc Networking and Computing (Mobihoc)<address><addrLine>Long Beach, Canada</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2001">2001</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Multicluster, mobile, multimedia radio network</title>
		<author>
			<persName><forename type="first">M</forename><surname>Gerla</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Tsai</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM-Baltzer Journal of Wireless Networks</title>
		<imprint>
			<biblScope unit="volume">1</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="255" to="265" />
			<date type="published" when="1995">1995</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Etablissement de la confiance et réseaux Ad hocun état de l&apos;art</title>
		<author>
			<persName><forename type="first">V</forename><surname>Legrand</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Abdesselam</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Ubéda</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">SAR&apos;2003</title>
				<imprint>
			<date type="published" when="2003-07">July 2003</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">An Authenticated Routing Protocol for Secure Ad Hoc Networks</title>
		<author>
			<persName><forename type="first">K</forename><surname>Sanzgiri</surname></persName>
		</author>
		<author>
			<persName><forename type="first">B</forename><surname>Dahill</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Laflamme</surname></persName>
		</author>
		<author>
			<persName><forename type="first">B</forename><forename type="middle">N</forename><surname>Levine</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Shields</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><forename type="middle">M</forename><surname>Belding-Royer</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">IEEE Journal on Selected Areas in Communication (JSAC)</title>
		<imprint>
			<biblScope unit="volume">23</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="598" to="610" />
			<date type="published" when="2005">2005</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Architecture Hiérarchique Distribuée pour sécuriser les Réseaux Ad hoc Mobiles</title>
		<author>
			<persName><forename type="first">A</forename><surname>Rachedi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Benslimane</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">8 ème journées Doctorales en Informatique et Réseaux</title>
				<meeting><address><addrLine>Marne la Vallée</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2007-01">Janvier 2007</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">A Mobility Based Metric for Clustering in Mobile Ad Hoc Networks</title>
		<author>
			<persName><forename type="first">P</forename><surname>Basu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Khan</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Thomas</surname></persName>
		</author>
		<author>
			<persName><surname>Little</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">21 st international Conference on Distributed Computing Systems Workshops (TCDCSW 01)</title>
				<imprint>
			<date type="published" when="2001">2001</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<monogr>
		<title level="m" type="main">Extracting reputation in multiagent systems by means of social network topology</title>
		<author>
			<persName><forename type="first">J</forename><surname>Pujol</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Sanguesa</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Delgado</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2002">2002</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<monogr>
		<title level="m" type="main">Regret: A reputation model for gregarious societies</title>
		<author>
			<persName><forename type="first">J</forename><surname>Sabater</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Sierra</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<monogr>
		<author>
			<persName><forename type="first">A</forename><surname>Berkeley</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Usc</forename><surname>Isi</surname></persName>
		</author>
		<ptr target="www.isi.edu/nsnam/ns" />
		<title level="m">The network simulator NS-2</title>
				<imprint>
			<date type="published" when="1998">1998</date>
		</imprint>
	</monogr>
	<note>Part of the VINT project</note>
</biblStruct>

<biblStruct xml:id="b12">
	<monogr>
		<title level="m" type="main">De la Sécurité à la E-Confiance dans les Réseaux sans fil Ad hoc</title>
		<author>
			<persName><forename type="first">A</forename><surname>Beghriche</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Bilami</surname></persName>
		</author>
		<imprint/>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<monogr>
		<title level="m">st Workshop on Next Generation Networks: Mobility (IEEE WNGN 2008)</title>
				<meeting><address><addrLine>Fès Maroc</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2008-07">Juillet 2008</date>
			<biblScope unit="page" from="18" to="19" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b14">
	<analytic>
		<title level="a" type="main">Trust management through reputation mechanisms</title>
		<author>
			<persName><forename type="first">G</forename><surname>Zacharia</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Maes</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Applied Artificial Intelligence</title>
		<imprint>
			<biblScope unit="volume">14</biblScope>
			<biblScope unit="issue">9</biblScope>
			<biblScope unit="page" from="881" to="907" />
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
