Solutions utilisant la cryptographie asymétrique

Chapitre 3 La sécurité dans les réseaux mobiles Ad hoc

79 Un modèle de confiance pour la sécurité des communications dans les réseaux mobiles Ad hoc.

l'authentification et intrinsèquement l'intégrité des messages de contrôle. Une telle authentification peut être réalisée soit de saut en saut, soit de bout en bout.

Dans Secure OLSR [79], les auteurs ont proposé une approche d'authentification de saut en saut dans laquelle chaque nœud signe les paquets OLSR au fur et à mesure de leur retransmission. Ainsi, à la réception d'un paquet OLSR (un tel paquet pouvant contenir plusieurs messages OLSR de type HELLO et TC), un nœud intermédiaire vérifie la signature du nœud précèdent, la retire, puis appose sa propre signature. Cette approche permet d'inclure dans le calcul de la signature numérique les champs devant être modifiés en transit, tels que le TTL5 et le nombre de sauts. Cependant, la signature assure seulement que le nœud qui a transmis le trafic est bien celui qui a signé le paquet, mais n'apporte aucune garantie sur l'intégrité du paquet original. Ici, les auteurs suggèrent l'utilisation de clés symétriques et d'une fonction de hachage telle que SHA-16 pour la génération des signatures numériques.

De manière similaire à Secure OLSR, les auteurs de [80] ont proposé une extension de sécurité pour le protocole OLSR basée sur l'utilisation de signatures numériques. Une première différence se situe au niveau du type des données protégées. Dans leur approche, une signature numérique est associée à chaque message de contrôle OLSR (c’est-à-dire, HELLO ou TC) et non plus à chaque paquet OLSR. Ensuite, les auteurs proposent une approche d'authentification de bout en bout selon laquelle un nœud récepteur d'un message de contrôle authentifie le nœud d'origine plutôt qu'un nœud intermédiaire dans son cheminement. Ici, les champs TTL et le nombre de sauts ne sont pas protégés par la signature, car ces derniers doivent être modifiés en transit par chaque nœud intermédiaire. En remplacement au TTL et pour déterminer si un paquet est trop ancien et s'il doit être rejeté, les auteurs proposent d'horodater chaque message OLSR. En outre, cette information temporelle est un indicateur qui sert à détecter les rejeux de messages de contrôle.

L'authentification des messages de contrôle représente une première ligne de défense pour contrecarrer efficacement les attaques externes contre le protocole OLSR. Or à elle seule, l'authentification n'empêche pas l'inoculation de fausses informations de routage par des attaquants internes au réseau. Pour pallier ce problème, d'autres méthodes plus originales ont été proposées (par exemples : AdvSig7 [81, 82], AdvSig+ [83]).

4.2.3 Solutions utilisant la cryptographie asymétrique

Les protocoles détaillés dans cette section supposent généralement l'existence d'un système de gestion et de distribution de clés préétabli. Ils utilisent ensuite les mécanismes de sécurité décrits au section 3 pour assurer l'intégrité et l'authenticité des paquets de contrôle. Pour prévenir les risques d'usurpation dans un réseau, le protocole doit pouvoir être à même de garantir l'authentification des

5 Time To Live.

6 Secure Hash Algorithm.

Chapitre 3 La sécurité dans les réseaux mobiles Ad hoc nœuds. Pour cela, les mécanismes de chiffrement apparaissent comme les plus efficaces. La différence entre les différents protocoles se fait alors sur le choix du procédé cryptographique.

4.2.3.1

M.G. Zapata et N. Asokan ont mis au point un protocole dédié à la sécurisation du protocole AODV, appelé SAODV (Secure Ad hoc On demand Distance Vector) [84]. L’idée principale de SAODV consiste à utiliser des signatures afin d’authentifier la plupart des champs des paquets RREQ et RREP et d’utiliser des chaines de hachage pour protéger l’intégrité du compteur de sauts. Ainsi, SAODV constitue-t-il une extension d’AODV avec des signatures, afin de contrer les attaques de type "usurpation d’identité". SAODV nécessite la présence d’une autorité de certification afin de vérifier les paquets signés, assurant ainsi leur authenticité. Dans SAODV, chaque paquet RREQ inclut une extension de signature simple. L’initiateur du paquet choisit un nombre de sauts maximal en se basant sur une estimation du diamètre du réseau et il génère ensuite une chaîne de hachage à sens unique d’une longueur égale au nombre de sauts, plus un.

A l'instar du protocole SEAD détaillé au section 4.2.4, les chaînes de hachage dans SAODV sont utilisées pour authentifier les métriques présentes dans l'en tête des paquets de signalisation. L'initiateur S du paquet RREQ-SSE inclut le type de message (RREQ), un identifiant (𝑖), l'adresse du nœud source (respectivement, Destination) ainsi qu'un numéro de séquence 𝑆𝑒𝑞_𝑆 (respectivement, 𝑆𝑒𝑞_𝐷). En outre, cet en-tête inclut également un élément de la chaîne de hachage (ℎ₀) basé sur l'estimation du nombre de sauts (N) de l'en-tête RREQ. Cette valeur est appelée l'authentifiant du nombre de sauts. Ainsi, si par exemple les valeurs de la chaîne de hachage ℎ₀, ℎ₁, … , ℎ_𝑁 ont été générées de sorte que ℎ_𝑖 = 𝐻(ℎ_𝑖+1), alors l'authentifiant du nombre de sauts ℎ_𝑖 correspond à un nombre de sauts de valeur (𝑁 − 𝑖). Par la suite, le nœud source signe le tout à l'aide de sa clé privée 𝐾_𝑆, ajoute un compteur de sauts et l'empreinte correspondante. Avant de relayer une requête RREQ-SSE, un nœud commence par vérifier l'authenticité du message afin de s'assurer que chaque champ est valide. Il supprime ensuite les éventuelles duplications (paquet en provenance de plusieurs nœuds). Il incrémente ensuite le compteur de sauts, le hache, ajoute l'empreinte et rediffuse le tout. Lorsque la requête parvient jusqu'à la destination, celle-ci vérifie son authenticité. Si la requête est invalide, elle est simplement supprimée. Autrement, le processus est similaire à AODV : la destination répond par un paquet RREP-SSE très similaire à la requête RREQ-RREP-SSE. La différence se situe dans la présence du champ lifetime qui correspond au nombre de nœuds exact pour renvoyer la réponse. Le paquet est ensuite signé et complété par un compteur de sauts de manière identique.

À l'exception du nombre de sauts et de son authentifiant, les champs contenus dans les en-têtes des paquets RREQ et RREQ-SSE ne sont pas modifiables et peuvent donc être aisément authentifiés en vérifiant la signature dans l'extension RREQ-SSE. Lorsqu'il relaie une requête RREQ, un nœud peut dans SAODV authentifier d'abord le paquet RREQ pour s'assurer que chaque champ est valide. Ensuite, il effectue une suppression des paquets dupliqués afin de ne pas retransmettre plus d'un RREQ pour

Chapitre 3 La sécurité dans les réseaux mobiles Ad hoc

81 Un modèle de confiance pour la sécurité des communications dans les réseaux mobiles Ad hoc.

chaque exploration de route. Le nœud incrémente ensuite le nombre de sauts de l'en-tête RREQ, calcule l'empreinte qui va authentifier le nombre de sauts et rediffuse la requête ainsi que l'extension RREQ-SSE. Lorsque la requête parvient à destination, celle-ci vérifie l'authentifiant dans l'extension. Si la requête est valide, la destination retourne un RREP comme dans AODV. Comme pour le RREQ, le seul champ modifiable des RREP est le nombre de sauts. Par conséquent, la sécurisation se fait exactement de la même manière.

SAODV utilise également les signatures pour protéger les messages RRER lors du mécanisme de maintenance de route (route maintenance). Ainsi, chaque nœud utilisant SAODV signe les messages RRER qu'il émet. En revanche, les nœuds ne changent pas l'information sur le numéro de séquence lorsqu'ils reçoivent un paquet RRER car le nœud destination n'authentifie pas le numéro de séquence.

Ce protocole assure une bonne authentification des messages de contrôle ainsi qu’une bonne intégrité. Cependant, l’utilisation de chaînes de hachage ne permet pas d’empêcher à 100% les attaques sur le nombre de sauts. Ainsi, bien que le hachage du nombre de sauts empêche un éventuel nœud malicieux d’annoncer des routes plus courtes qu’en réalité, rien n’empêche un attaquant d’augmenter arbitrairement la longueur des routes, En effet, un tel nœud peut appliquer la fonction de hachage plusieurs fois consécutives avant de relayer un paquet, la route apparait ensuite plus longue qu’elle n’est en réalité.

D’autre part, dans l’éventualité où il y aurait plusieurs attaquants complices, une attaque de type tunnel peut toujours être lancée et le nombre de sauts peut même être décrémenté à l’arrivée, de manière transparente pour les autres nœuds.

4.2.3.2

Les concepteurs du protocole ARAN (A secure Routing protocol for Ad hoc Network) [56] ont également choisi d’utiliser la cryptographie à clés publiques pour sécuriser les routes. ARAN est un protocole à la demande, qui fournit un service d’authentification de saut en saut par le biais d’une infrastructure à clés publiques. Il suppose donc l’existence d’un serveur d’authentification "𝑇", dont le rôle est de gérer les certificats et dont la clé publique est connue de tous les participants. Ainsi, avant d’entrer dans le réseau, chaque nœud doit s’identifier auprès du serveur et solliciter auprès de lui un certificat qui lui servira à signer les messages qu’il enverra. Ce certificat contient l’adresse IP du nœud, sa clé publique, une première estampille qui rend compte de la date de création du certificat, et une seconde qui indique sa date d’expiration. De manière classique, ce certificat est ensuite signé par "𝑇" et doit être mis à jour régulièrement.

Le principe d’ARAN est de sécuriser le mécanisme de découverte de routes de nœuds en nœud. Ainsi lorsqu’un nœud désire envoyer un message, il génère, signe puis diffuse un paquet de type RDP (Route Discover Packet). Par la suite, chaque nœud intermédiaire recevant ce paquet vérifie le certificat du nœud précédent, appose son propre certificat et rediffuse le paquet. Une fois ce paquet arrivé au

Chapitre 3 La sécurité dans les réseaux mobiles Ad hoc nœud destination, celui-ci vérifie à son tour le certificat et répond en unicast, par un message de type REP (REply Packet) qui est à son tour vérifié de nœuds en nœuds.

Le protocole ARAN spécifie également comment protéger le mécanisme de maintenance des routes. Ainsi, lorsqu'un nœud intermédiaire détecte qu'une route est rompue, il envoie un paquet de type route error (ERR) au nœud suivant en amont (en direction de la source). Ce paquet inclut les adresses des nœuds source et destination, le certificat du nœud intermédiaire ainsi qu'un nonce8 et une estampille de temps. Le paquet est ensuite relayé sans être resigné par les nœuds intermédiaires.

Parce que les paquets ne contiennent aucun compteur de sauts et surtout parce que l'authentification est effectuée de nœuds en nœuds, d'éventuels nœuds malicieux ne peuvent pas créer de boucles de routage, ni rediriger le trafic en insérant des adresses non légitimes dans les paquets de découverte de routes. En ce sens, ARAN fait preuve d'une grande robustesse contre ce type d'attaques. En contrepartie, l'utilisation de mécanisme de chiffrement à clé publique ouvre la voie à des attaques de type déni de service.

En effet, dans ce protocole, pour chaque paquet de découverte do route, il faut vérifier le certificat fourni, déchiffrer le paquet, le re-chiffrer avec sa propre clé et apposer son certificat. Lorsque le nombre de paquets devient important, cela peut se révéler extrêmement coûteux. Aussi une attaque par déni de service consistera à inonder le réseau de faux paquets de contrôle, dont la vérification va monopoliser exagérément les ressources des nœuds. D’autre part, si un nœud ne peut effectuer cette vérification en temps réel, il peut dire amené par un attaquant à supprimer certains paquets aléatoirement, y compris des paquets valides.