• Aucun résultat trouvé

Partie 2 Contributions

5.3. La solution proposée

5.3.1. Description du schéma proposé

Dans cette section, après avoir formé les clusters et les têtes sont désignées, comme décrit dans le chapitre précédent, nous exposons le régime dans lequel les fonctions des têtes des clusters sont rassemblées dans un seul service, appelé le Conseil de PKI. Chaque nœud du Conseil aura les mêmes fonctionnalités que les autres membres, et il utilise le modèle partagé à seuil (k, n) pour collabore dans l‟opération de gestion des clés. La fonction principale de ce conseil sera de gérer les clés et les certificats. Un certificat sera validé par la participation d‟au moins k éléments parmi les n membres du Conseil. La fonction de gestion des clés par les têtes des clusters va maintenant être capable de fonctionner même lorsque plus qu‟une tête de groupe est compromise (mais limitée à min {k, n-k+1}).

Dans notre système, nous proposons une nouvelle architecture que nous appelons „Conseil à base de clusters‟. Cette architecture utilise une approche de collaboration pour fonctionner comme un conseil à base de clusters fondée sur l'ensemble du réseau, le rendant aussi efficace que possible. Une fois que le conseil à base de clusters est formé, chaque membre du Conseil peut utiliser le régime à seuil (k, n) de manière à ce qu'un minimum de k têtes de clusters parmi n ont besoin de participer ensemble pour exercer les fonctions de l‟autorité de certification. Par exemple, pour la fonctionnalité de distribution de clés, chaque membre du conseil (chacun servant comme AC) servira ses membres du cluster. En ayant plusieurs membres, le réseau sera en mesure de travailler, même si plus d'une tête sont compromises (mais limitée à m = min {k, n-k +1}). Si ce nombre de têtes sont compromises, seuls leurs clusters seront touchés, et le réseau peut continuer à fonctionner.

Schéma de gestion des clés dans le conseil à base de clusters

La gestion des clés est un aspect important de la sécurité des réseaux ad hoc. Pour assurer la sécurité en utilisant la cryptographie à clé publique, chaque nœud dispose d‟une paire de clés publique-privée et d‟un certificat délivré par l‟AC. Comme indiqué précédemment, l'une des fonctionnalités des têtes de clusters est de fonctionner comme l‟AC. Une autorité de certification certifie qu'une clé publique appartient à une entité particulière. Ayant une seule AC centralisée ne convient pas pour les réseaux ad hoc considérablement vulnérables. Grâce à notre système, le processus de certification peut être réparti entre tous les nœuds du conseil.

Nous avons séparé notre étude en deux grandes parties. Dans la première partie, le conseil est formé par des membres désignés à l'avance et qui ne changent pas durant toute la durée de vie du réseau. C‟est ce que nous avons appelé architecture à membres fixes. Et dans la deuxième partie, les membres du conseil sont formés par les têtes des clusters et c'est ce que nous avons appelé, architecture en clusters.

Le conseil émet un certificat pour une clé publique d‟un nœud membre en la signant numériquement avec la clé secrète du cluster. Pour valider le certificat d‟un nœud, au moins k membres parmi n doivent travailler ensemble et combiner leurs contributions.

Partie 2 Contributions

117 Puisqu‟au moins k contributions parmi n sont nécessaires pour valider le certificat d‟un nœud, le système peut fonctionner même si plus d'un membre du conseil sont compromis, mais limités à m = min (k, n-k +1).

Pourquoi la limite de m = min (k, n-k +1) de nœuds compromis

Dans la section ci-dessus, nous avons mentionné que la fonctionnalité du conseil sera en mesure de travailler, même si plus d'un membre sont compromis, mais limitée à m= min {k, n-k +1}. Parlons pourquoi notre système de seuil (k, n) est limité à m = min {k, n-k +1}. Dans le schéma à seuil (k, n), un minimum de k têtes de clusters parmi n‟ont besoin de participer ensemble afin d'exécuter toutes les fonctionnalités du conseil. Si k membres ou plus sont compromis, ils seront en mesure de combiner leurs parts ensemble afin d'exécuter toutes les fonctionnalités de membres compromis.

Ainsi, le nombre total des nœuds compromis ne peut dépasser k-1. Mieux encore, dans le but d‟assurer les services du conseil, l‟opération nécessitera au moins k membres non compromis ; le système ne pourra pas fonctionner si le nombre des membres compromis est supérieur ou égal à n-k+1. En général, le schéma à seuil (k, n) pourra fonctionner pour n‟importe quels T membres compromis où 1< T < min {k, n-k +1}. Par exemple dans le schéma à seuil (5,12), le système ne peut pas fonctionner si plus que 5 membres sont compromis. Avec le schéma (7,12) le système ne peut pas fonctionner si plus que 6 membres sont compromis, puisqu‟un minimum de 7 membres est nécessaire pour assurer la fonction du conseil.

Valeurs des paramètres k et n

Nous avons également abordé le problème du choix des paramètres de seuil (k, n) convenables. N'étant pas uniformément réparties, l'ensemble du réseau rend difficile le choix de (k, n). Nous trouvons la valeur de n de manière adaptative en fonction de la densité dans le réseau. En fait, le nombre des membres du conseil nous donnera la valeur de n. La valeur de seuil k est un point d'équilibre entre la tolérance aux pannes et la disponibilité du service.

Discutons les cas particuliers de choix de k:

 k = 1: La décision est partagée par les n membres du conseil, et n‟importe lequel d'entre eux peut valider un certificat utilisant seulement une part. Ce schéma est semblable à une autorité unique et donc vulnérable au point de défaillance unique.

 k = n : Le secret est partagé par tous les nœuds n et ils doivent tous participer, avec leurs actions afin d'obtenir la validation. Ce système offre une sécurité maximale, mais nécessite l'accessibilité à tous les nœuds. Pour des réseaux très sûrs, comme les applications militaires, on choisit k = n et on applique le concept du seuil (n, n) au sein du Conseil.

 1 < k < n : le choix du seuil k se fait d'une manière à ce qu'il y ait un équilibre entre la sécurité et la disponibilité.

Chapitre 6 Gestion des clés cryptographiques

118

Description du schéma proposé

Le schéma peut être expliqué par les étapes suivantes:

Scénario de démarrage : au démarrage du réseau, au moins k membres parmi les nœuds présents, doivent se partager en face à face une clé secrète physique de démarrage. Cette clé servira comme clé de session qui sera changée immédiatement après le démarrage du réseau. De cette façon, toute intrusion non souhaitée sera écartée. Les nœuds qui créent le réseau pour la toute première fois, forment les membres permanents du conseil de PKI. Ils ont une métrique de confiance maximale, et se chargeront d'authentifier les autres nœuds qui rejoindront le réseau par la suite. La question de gestion de confiance sera abordée plus tard dans ce manuscrit.

Après le démarrage du réseau, si un nœud arrive pour la toute première fois, il doit impérativement contacter l'un des membres permanents pour avoir un certificat physique en face à face. Ce certificat contient une clé de session qui va permettre au nouveau nœud de se connecter au réseau, et une métrique de confiance inférieure à celle des membres qui ont créé le réseau pour la première fois.

Durant le fonctionnement du réseau, chaque membre du conseil de PKI enregistre l'ensemble des certificats délivrés et le diffuse pour le reste des membres du conseil. Chaque nœud du réseau qui ne fait pas partie du conseil de PKI, doit enregistrer l'ensemble des certificats qu'il a obtenus.

Si un nœud quitte puis rejoint le réseau; ou s'il change de cluster suite à un déplacement, il doit s'authentifier auprès de l'un des membres du conseil qui n‟est autre que la tête du cluster (suivant l'architecture utilisée : architecture à membres fixes ou architecture en clusters) en présentant son premier certificat physique. En se basant sur ce certificat, le membre du conseil diffuse une demande de validation de certificat pour les autres membres du conseil. Si le membre authentificateur reçoit au moins k réponses favorables parmi n, le nœud qui veut s'authentifier sera accepté, et le certificat lui sera délivré. Dans le cas où le nombre de réponses favorables est inférieur à k, le nœud qui veut s'authentifier doit réussir un challenge à la base de son historique en certificats disponibles chez l‟authentificateur.

Pendant la phase de validation d‟un certificat physique, si le membre de conseil reçoit plus que k réponses, il va favoriser les réponses des nœuds qui ont la plus grande métrique de confiance pour s‟assurer que le nœud qui veut s'authentifier est connu pour des membres de confiance dans le conseil.