Deuxième solution : messages de signatures dans OLSR [83]

Cette solution décrit une approche de sécurisation d‟OLSR qui fait appel à l‟ajout d‟une signature aux messages de contrôle. Elle propose aussi qu‟un digest généré au moyen d‟une clé symétrique partagée, peut aussi bien être utilisé à la place de la signature.

3.1.3.1. Spécifications de la solution

La signature est calculée sur le corps et l‟en-tête du message, et est distribuée sous la forme d‟un type spécial de message, appelé SIGNATURE (Figure 3.8). Un message SIGNATURE est généré et envoyé avec tout autre message de contrôle (HELLO, TC, MID ou HNA). Il n‟est pas possible de signer un paquet entier parce qu‟il peut contenir des HELLOs, qui ne sont pas relayés, et donc la signature du paquet ne serait plus valable au delà du premier saut.

Une solution serait celle de contrôler la signature saut par saut; toutefois, comme les messages sont relayés par inondation MPR, tout nœud qui a relayé un message incorrect pourrait en être l‟émetteur, tandis qu‟une authentification par message permet de déterminer aisément l‟origine des fausses informations

On identifie sans ambiguïté à quel message appartient une signature car les deux doivent se trouver dans un même paquet OLSR et sont consécutifs. Dans une première version, le couplage était identifié grâce au Numéro de Séquence (MSN) du message de contrôle en question et à un champ homologue dans le message de signature; cela permettait d‟envoyer les messages dans un ordre quelconque, et même dans des paquets différents.

Si la taille du paquet dépasse le MTU (Maximum Transfert Unit), le message de contrôle est fragmenté et un message SIGNATURE est associé à chaque fragment. Le message SIGNATURE contient aussi une estampille temporelle, obtenue de l‟horloge interne du nœud, pour éviter les attaques de rejeu; la synchronisation des horloges ne nécessite pas d‟être très précise, puisque les messages qui seraient des doublons peuvent être reconnus aussi par leur Numéro de Séquence.

L‟implantation a recours à la cryptographie asymétrique et une AC en modalité non en ligne pour assigner une paire de clés à chaque nœud participant; chaque nœud diffuse ensuite sa clé publique aux autres nœuds. On utilise les signatures, basées sur l‟identité, pour les clés assignées par l‟AC (clés globales) et qui seront ensuite utilisées pour signer les clés des nœuds (clés locales); pour ces dernières on a choisi les signatures courtes.

Partie 2 Contributions

81 La signature n‟inclut pas les champs TTL et le nombre de sauts (dans l‟en-tête du message). Cela est dû au fait que ces deux champs sont modifiés à chaque saut du message, ce qui interférerait avec la vérification de la signature. Malheureusement, ce fait permettrait à un adversaire de relayer des messages avec un TTL modifié à 0 en restant inaperçu. Cette faille peut être résolue en ignorant le champ TTL et en considérant à sa place la valeur de l‟estampille temporelle.

Cette architecture de sécurité n‟est pas interopérable avec OLSR standard. En effet, un nœud dans lequel tourne OLSR sécurisé n‟accepterait pas des HELLOs non signés de la part des nœuds OLSR standard; en conséquence il ne pourrait pas y avoir de lien symétrique entre les deux, et donc aucune sélection des MPRs qui est le mécanisme principal pour la diffusion des messages dans OLSR.

3.1.3.2. Format du message signature

Le message de signature est encapsulé et transmis comme une portion de données du format standard d‟un paquet OLSR décrit dans la section précédente (1.1.1) de ce chapitre. Le champ « Message Type » est mis à la valeur SIGNATURE ; cette valeur contient aussi des informations sur les primitives cryptographiques et les clés à utiliser. Les champs TTL et Vtime sont mis aux mêmes valeurs que le message auquel est associée la signature.

Figure 3. 8 – format du message signature [83]

3.1.3.3. Extension de la solution de signature (ADVISGN)

Une extension pour cette solution a été proposée pour améliorer les messages de signature OLSR contre les nœuds compromis. Elle consiste à ajouter un nouvel en-tête aux messages de signature OLSR. Le nouvel en-tête contient plusieurs signatures dans le but de permettre à chaque entrée d‟information de lien d‟être confirmée par les deux bouts du lien. Ainsi, ADVSIGN garantit non seulement l‟authentification et l‟intégrité des messages de routage, mais aussi l‟authenticité des informations de routage.

3.1.3.4. Discussion

Dans cette solution, l‟attention est portée sur les messages de contrôles contenus dans le paquet. Ainsi, on propose de signer les messages HELLO, TC, MID et HNA ; mais l‟information contenue dans l‟en-tête du paquet qui représente une sorte de porteuse pour tous ces messages n‟est pas considérée dans la signature. Les attaques sur le paquet OLSR doivent être prises en considération parce qu‟elles peuvent perturber le processus de routage.

Chapitre 4 Signature des messages de contrôle

82

Les champs TTL, et nombre de sauts ne sont pas considérés dans la signature puisqu‟ils changent d‟un saut à l‟autre, et peuvent ainsi constituer une entrée d‟attaque.

L‟extension de signature ADVSIGN engendre un overhead de routage supplémentaire qui consomme les ressources radio du réseau et contribue à l‟épuisement rapide des ressources en énergie des nœuds à cause des signatures multiples contenues dans le message de vérification.

Comme la solution précédente, cette solution ne donne aucune information sur le coût engendré suite aux mécanismes de sécurité. L‟effet provoqué par les mécanismes de sécurité sur les performances du réseau n‟est pas mesuré, ce qui ne permet pas de juger la convenance de la solution aux réseaux ad hoc.