B ILEN SOM SAMFUNNSFENOMEN

Les protocoles de routage ad hoc présentés dans le chapitre 2 sont spécifiés sans aucune mesure de sécurité, cependant la sécurité de ce service est identifiée comme essentielle pour assurer un large déploiement de ces réseaux et susciter leurs intérêts dans la sécurité routière. Dans cette section, nous présentons certains protocoles de routage sécurisés qui sont en effet des protocoles de routages existants renforcés par des mécanismes de sécurité supplémentaires.

63 Figure 20: Protocoles de routage sécurisés

IV.2.1 ARIADNE

Le protocole Ariadne a été proposé par Hu et al. [7] comme extension au protocole DSR en se basant sur la cryptographie symétrique utilisée par la technique d’authentification TESLA (Timed Efficient Stream Loss-tolerant Authentication).

Dans Ariadne un émetteur ajoute un (HMAC) avec des clés généré selon des intervalles de temps. Le récepteur peut vérifier le message lorsque la clé est envoyée dans un intervalle de temps futur sur la base d'un intervalle de divulgation de clé. La divulgation de clé temporisée est fondée sur le détachement, mais la synchronisation d'horloge est bornée entre les deux nœuds impliqués.

L'objectif principal d'Ariadne est de fournir l'authentification et l'intégrité des messages de signalisation DSR. Dans la découverte de route, à chaque saut les nouvelles informations du RREQ sont authentifiées. L'état de la sécurité Tesla est vérifiée à la destination, et un HMAC est inclue dans la réponse de route RREP pour certifier que les conditions de sécurité ont été vérifié.

ARIADNE protège aussi l'entretien de route de DSR, par l’authentification des messages RERR.

Selon ses auteurs, le protocole peut également être facilement adapté à deux autres schémas, à savoir les clés partagées entre chaque paire de nœuds et la signature numérique. L’inconvénient de la première variante est l’utilisation de TESLA qu’elle procure des délais

64 supplémentaire dans le processus de découverte de route; par conséquent, ARIADNE basé sur TESLA n’est pas recommandé pour les réseaux à forte mobilité comme les VANETs .

L’autre variante ARIADNE basée sur la signature numérique n’est pas adaptée pour un environnement véhiculaire à cause de la difficulté de distribution des clés public qui nécessite un serveur central.

IV.2.2 Secure Routing Protocol

Le protocole SRP (Secure Routing Protocol) [4] est conçu comme une extension sécurisée de protocole de routage réactif DSR en se basant sur la cryptographie symétrique. SRP ne suppose pas que tous les nœuds intermédiaires dans une route, partagent une clé secrète avec le nœud source ou destinataire. Par conséquent, seuls les deux nœuds communicants (nœud source et nœud destination) partagent une clé secrète. De ceci résulte que la vérification et l’authentification de paquets de contrôle échangés ne sont effectuées qu’au niveau des nœuds communicants.

Au début, un nœud source S diffuse à ses voisins à un saut un paquet RREQ contenant un MAC calculé sur les différents champs avec la clé qu’il partage avec le nœud destinataire D. Ensuite chaque nœud intermédiaire recevant ce paquet ajoute son identifiant au descriptif de ce dernier. Dés que le nœud destinataire D intercepte le paquet contenant la route spécifiée dans le descriptif du paquet, il vérifie le MAC généré par S et ensuite envoie un paquet RREP à S via la route inverse; ce paquet contient le descriptif de la route trouvée et un MAC (calculé avec la clé secrète partagée avec S).

Les opérations du protocole SRP sont très optimisées en termes de bande passante et de traitement. Cependant, cet avantage disparait en présence d’un attaquant qui peut ajouter des paquets RREQ falsifiés (par exemple contenant un identifiant d’un destinataire inexistant) ou altérer le descriptif d’une route en cours de construction. Ainsi, l’authentification et la vérification d’intégrité de ces paquets ne sont pas effectuées par les nœuds intermédiaires, ce qui provoque une consommation de ressources supplémentaires en présence d’attaquants.

65 IV.2.3 Secure Ad-Hoc On demand Distance Vector

SAODV [5,6] est une extension du protocole AODV pour assurer l’authenticité et l’intégrité des messages de routage, et pour éviter les manipulations de la valeur de nombre de sauts (HOP-COUNT).

Dans AODV les messages de routage (Route_Reply et Route_Request) ont une partie non modifiable et une autre modifiable. La partie non modifiable est protégée par une signature numérique et elle inclut les champs suivants: le numéro de séquence, les adresses des nœuds source et destinataire et l’identifiant de requête. Tandis que la partie modifiable qui inclut le compteur de sauts est protégée par une technique basée sur les chaînes de hachage, qui permet aux nœuds intermédiaires (selon les concepteurs de ce protocole) de vérifier que sa valeur n’a pas été décrémentée abusivement.

Cette dernière technique de protection n’est toutefois pas totalement sûre et la valeur de compteur du nombre de sauts peut être rendue par un nœud malveillant supérieure ou inférieure à sa valeur réelle. Donc, le nœud malveillant peut faire apparaitre les routes plus courtes. Ce protocole présente l’inconvénient que les nœuds doivent utiliser un serveur en ligne afin de vérifier les signatures numériques.

IV.2.4 Secure Optimized Link State Routing

SOLSR [8,9] une extension du protocole OLSR qui utilise un HMAC à chaque saut, et l’horodatage des échanges (time-stamp) afin d’authentifier les paquets de signalisation et pour prévenir les attaques de rejeux (reply attacks).

SOLSR suppose aussi que tous les nœuds ont accès à la même clé partagée pour signer et vérifier l'intégrité de chaque message.

L’horodatage des échanges est réalisé par un système de défi-réponse (challenge-response). Quand un message signé est reçu une certaine marge de différence d'horodatage calculée est autorisée. Cette différence est recalculée chaque fois qu'un message reçu est vérifié, de sorte que tout défaut d'inclinaison entre les horloges peut être rapidement compensé.

Cette étude nous permis de déduire que ces primitives de sécurité ne sont pas adaptées aux cas des réseaux VANETs, car d’une part ils sont toujours vulnérables à des attaques telles que : (1) l’usurpation d’identité (l’attaques sybil), (2) la création des boucles de routage, (3)

66 l’attaque Route cache poisoning qui consiste à injecter de fausses informations dans le cache de routage des nœuds honnêtes. D’autre part, ces solutions nécessitent un temps de synchronisations supplémentaire des horloges des nœuds, utilisé pour la détermination des intervalles de temps de validité des clés cryptographique et certificats. Ce qui rend ces solutions inadaptées pour les VANETs.