Première solution : Secure OLSR [82]

Ce mécanisme de sécurité se base sur la signature de chaque paquet de contrôle OLSR pour authentifier les messages. La signature numérique est basée sur des clés symétriques.

3.1.2.1. Aperçu

Tout le trafic de contrôle OLSR est signé pour chaque saut. Ce qui veut dire que les champs variables dans les messages comme le nombre de sauts et le TTL ne sont pas considérés. Aussi, une seule signature est utilisée puisque plusieurs messages OLSR sont empilés dans un seul paquet. L‟utilisation de l‟approche saut par saut ne permet pas des signatures de bout en bout, ce qui signifie aussi que le digest ne représente pas une signature de confiance provenant de la source, mais seulement une signature à partir de l‟expéditeur en supposant que celui-ci a confiance en la source du message vers le saut précédent.

Un nœud ne disposant pas de la clé secrète partagée ne peut pas produire le bon digest. Tous les récepteurs qui fonctionnent avec « Secure OLSR » ignorent les messages avec des digests incorrects. Les signatures sont transmises dans leurs propres messages. Ceci pour assurer la compatibilité avec les nœuds qui ne fonctionnent pas avec « Secure OLSR », mais aussi parce que le Timestamp est transmis avec la signature.

Quatre messages différents sont définis. Le premier, qui est le message signature représenté dans la figure 3.4, et trois autres messages (figures 3.5, 3.6, et 3.7) utilisés dans l‟échange du Timestamp. Tous les messages sont envoyés dans le corps d‟un paquet OLSR

Pour prévenir les attaques de rejeux, les Timestamps sont utilisés dans cette extension de sécurité pour OLSR. Pour échanger ces Timestamps sur une connexion initiale entre deux nœuds, un mécanisme d‟échange de Timestamp à deux directions est utilisé. La solution ne repose pas sur la synchronisation du temps entre les nœuds du réseau.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

0 1 2 3

Scheme Algorithms Reserved

Timestamp Signature (160 bits)

Figure 3. 4 -le message de signature élémentaire (Secure OLSR)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

0 1 2 3

Destination

Random Value ‘’chalange’’ Signature (160 bits)

Partie 2 Contributions

77

3.1.2.2. Signature

Le message de signature illustré dans la figure 3.4 est attaché à tous les paquets OLSR sortants. Ce message est le dernier à mettre dans le paquet. L‟en-tête du paquet OLSR est ajusté pour inclure la taille du message de signature dans le champ « size ».

Les champs scheme et algorithms dans l‟en-tête du message signature, informent la destination sur la nature du schéma de signature et l‟algorithme utilisés. Le champ Timestamp est utilisé pour prévenir les attaques de rejeux. Le digest utilisé comme signature est un haché créé en utilisant l‟algorithme de hachage SHA-1, qui produit un digest de 160 bits irréversible. Le haché est basé sur :

 L‟en-tête du paquet OLSR (avec sa taille ajustée).

 Tous les messages OLSR dans le paquet sans le message de signature.

 L‟en-tête du message OLSR, le sous en-tête et le Timestamp du message de signature.  La clé secrète partagée.

Aucune considération n‟est apportée sur les champs variables des différents en-têtes (comme le TTL ou le hop count) puisque la signature est faite saut par saut. L‟approche du Timestamp nécessite une autre étude, particulièrement concernant les problèmes de synchronisation, les délais de la couche MAC, etc.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

0 1 2 3

Destination

Signature (160 bits) Timestamp

Response Signature (160 bits)

Figure 3. 7 - le message response -response pour l‟échange du timestamp (Secure OLSR)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

0 1 2 3

Destination

Signature (160 bits) Response Signature (160 bits)

Random Value ‘’chalange’’ Timestamp

Chapitre 4 Signature des messages de contrôle

78

Secure OLSR est conçu pour être aussi flexible que possible quant aux algorithmes de cryptage et de hachage utilisés. Dans la solution implémentée les hachés créés par l‟algorithme de hachage SHA-1 du message et de la clé secrète partagée sont utilisés pour assurer l‟intégrité.

Un schéma différent pourrait inclure une signature pour chaque message tenant compte de la signature de bout en bout ou le cryptage asynchrone ou synchrone pourrait être aussi bien utilisé pour assurer la confidentialité. Ces schémas peuvent aussi utiliser différents algorithmes de hachage et de cryptage tous définis par l‟en-tête du message de signature.

3.1.2.3. Timestamp et fraicheur

Un attaquant peut enregistrer le trafic signé pour le jouer ultérieurement (attaques rejeu). Ceci peut être empêché à un certain degré par les numéros de séquences qui sont déjà utilisés dans OLSR. Pourtant pour le trafic qui est envoyé seulement à un saut, comme les messages HELLO, cela n‟aura pas d‟effet. Un attaquant peut simplement enregistrer les messages transmis par un nœud, se déplacer dans un autre espace du réseau où les messages HELLO enregistrés ne sont jamais reçus. Ainsi, l‟attaquant peut commencer l‟attaque de rejeu en transmettant les messages déjà enregistrés. Les numéros de séquences OLSR sont, eux aussi fragiles à cause de leur longueur. Ils ont une longueur de 16 bits seulement et le problème de bouclage peut arriver assez fréquemment.

3.1.2.3.1. Echange des Timestamps

Le processus d‟échange du Timestamp introduit trois types de messages. Ces messages sont traités sans souci de la validation du message de signature, puisque ce processus est sûrement produit entre les nœuds qui n‟ont pas un Timestamp enregistré entre eux. A cause de ceci, tous ces messages sont signés intérieurement. Ce qui veut dire que tous les messages portent leurs digests.

L‟échange des Timestamps entre deux nœuds voisins A et B peut être décrit comme : 1  A B : ChaD(M,K),

2  B A : ChbTsbD(IPb,CHa,K)D(M,K) 3  A B : TsaD(IPa,CHb,K)D(M,K).

1  Quand A reçoit un message signé d‟un voisin B pour lequel A n‟a pas de valeur du timestamp enregistrée, A initie le processus d‟échange du Timestamp. En premier lieu A envoie un message de challenge (figure 3.5) vers B. Ce message est diffusé en broadcast puisque A peut ne pas avoir une route actuelle vers B. Le message de challenge contient l‟adresse IP de B et un nonce de 32bits (nombre utilisé une seule fois), Ch, C‟est un nombre aléatoire, qui est utilisé pour ajouter des données aléatoires aux données réelles pour prévenir l‟attaque du rejeu. Donc A signe ce message avec un digest D du message entier M et de la clé partagée K : D(M, K).

Partie 2 Contributions

79 2  Maintenant B doit répondre à ce message par un message challenge-response. Premièrement, B génère le digest à partir de son adresse IP, du nonce reçu et de la clé partagée D(IPb, CHa, K). Donc B génère un nonce de 32bits et transmet l‟adresse IP de A, le nonce, le timestamp de B, le digest D(IPb, CHa, K) et le digest du message entier et la clé secrète D(M, K).

3  Quand A reçoit le message challenge-response de B, premièrement, il cherche à valider les données. Si le digest D(IPb, CHa, K) et D(M, K) peut être vérifié, donc le timestamp de B est utilisé pour créer la différence de temps entre A et B. A donc génère un message response-response (figure 3.6) et le diffuse à B. ce message contient l‟adresse IP du récepteur (B), le timestamp de A, le digest de l‟adresse de A (comme reçu de B), le nonce reçu de B, et la clé secrète D(M, K).

Quand B reçoit le message response-response de A, il cherche à vérifier les digests. S‟ils peuvent être vérifiés, donc B utilise le timestamp reçu pour enregistrer sa différence de temps de A.

Ainsi l‟échange du timestamp est terminé.

3.1.2.3.2. Robustesse

Le processus d‟échange du timestamp peut être exploité par un adversaire pour créer une surcharge de traitement et d‟utilisation de réseau, qui peut rendre un nœud incapable de participer dans d‟autres échanges de timestamps voire dans toute communication. Ceci peut être dû à une attaque de déni de service (DoS) typique. Un attaquant ou un nœud mal configuré peut pour l‟instance transmettre des milliers de messages de challenge pour l‟échange de timestamp pendant une très courte période de temps, tous destinés vers le même nœud. Ceci oblige le récepteur à générer et à transmettre des réponses signées pour tous les challenges.

Pour éviter ceci, un compteur est initialisé pour les émetteurs de tous les challenges reçus. Chaque nouveau challenge reçu à partir du même host est ignoré au cas où le compteur n‟a pas encore expiré,. Grâce à la signature des messages de challenge, un attaquant ne peut pas usurper l‟adresse de l‟émetteur des messages de challenge. Pourtant, un attaquant peut enregistrer tous les messages de challenge dirigés vers un nœud pour une longue période de temps et les lancer tous pendant une courte période de temps. Cependant, comme les entrées timestamp sont cachées dans les nœuds, cette quantité de messages ne doit pas être vaste.

3.1.2.4. Discussion

Comme nous venons de le voir, cette solution souffre d‟un certain nombre de faiblesses. Les horloges sont supposées être relativement synchronisées, ce qui veut dire qu‟elles fonctionnent à des fréquences relativement égales. Tout le trafic de contrôle OLSR est signé pour chaque saut. Ce qui veut dire que les champs variables dans les messages comme le nombre de sauts et le TTL ne sont pas considérés. Aussi, une seule signature est utilisée puisque plusieurs messages OLSR sont empilés dans un seul paquet.

Chapitre 4 Signature des messages de contrôle

80

L‟utilisation de l‟approche saut par saut ne permet pas des signatures de bout en bout, ce qui veut dire aussi que le digest ne représente pas une signature de confiance provenant de la source, mais seulement une signature à partir de l‟expéditeur supposant qu‟il a confiance en la source du message vers le saut précédent. Enfin, cette approche ne prévoit aucune solution de distribution de clés, et suppose l‟existence d‟une autorité de gestion des clés.