4.3.1 Le réseau et les outils d’analyse déployés
La deuxième plateforme est un réseau meshé 6LoWPAN. Elle est constituée uniquement de nœuds Wis-mote embarquant la version 2.6 de l’OS Contiki. Il support le protocole 6LoWPAN et implémente RPL comme protocole de routage et nous utilisons UDP pour le transport des données. Les communications sont multi sauts.
Un nœud assurant le rôle de "Border Router" 6BR a été, contrairement aux autres, branché sur secteur et non mis sur piles. Il représente le point d’entrée/sortie du réseau. Il joue le rôle de puits et collecte donc les données lui parvenant des différents nœuds du réseau. Les données brutes reçues par le 6BR peuvent également être récupérées dans un fichier texte qui pourra ensuite être exploité. Pour cela, ce dernier est branché sur un PC. Il joue également le rôle de nœud root et permet la mise en place du réseau et sa configuration. Il fournit également le préfixe utilisé pour la configuration des adresses IPv6 avec le protocole SLAAC.
Les autres nœuds du réseau sont soit des feuilles soit des routeurs. La périodicité du maintien du routage par RPL peut être réglée dans Contiki. Nous avons choisi de garder la valeur par défaut. La durée maximum par défaut entre deux trames RPL est d’environ 17min28s.
Le scénario déployé sur cette plateforme consiste à permettre à chaque nœud du réseau d’envoyer des trames UDP périodiques incluant leur identité mais également les données de leurs accéléromètres.
Pour analyser les communications au sein du réseau 6LoWPAN, un intercepteur Wismote embarquant l’OS Contiki a été développé. Il va permettre de collecter les trames brutes IEEE 802.15.4, en-tête MAC inclus. Des modifications dans l’OS ont été réalisées afin de mettre la radio en mode promiscuité et donc d’éviter le filtrage d’adresses. Seule une carte Wismote et un câble USB sont nécessaire pour la programmation. L’investissement est d’environ 135€ pour le matériel. Pour la programmation, une machine virtuelle open
source comportant le BSP pour les cartes Wismote est fournie. Elle permet de programmer de manière
simple les cartes Wismote. L’un des plus gros investissements concerne la compréhension de Contiki et des fichiers de son noyau. En effet, peu de documentations sont disponibles. Néanmoins, il n’est pas obligatoire de comprendre le fonctionnement complet de Contiki pour déployer l’intercepteur. De plus, dans les versions récentes de Contiki, des exemples de programmes permettant le déploiement d’intercepteurs sont donnés. Il est alors possible de les adapter à la plateforme qui embarquera l’intercepteur. Mis à part la création des programmes des intercepteurs, la programmation de la carte prend environ 3 minutes. Le déploiement reste là encore abordable pour un attaquant.
L’intercepteur Wismote doit permettre deux utilisations.
Soit l’expérience est réalisée puis on analyse après coup les données. On parle alors d’analyse off-line. Les données sont collectées et enregistrées dans un fichier qui devra ensuite être transmis à Wireshark pour analyse.
Soit les données sont analysées au fur et à mesure de l’expérience pour une analyse in-line.
Néanmoins, afin de traiter et d’interpréter les données, Wireshark a besoin que celles-ci respectent le format pcap. Ce format utilise des en-têtes ajoutés aux données utiles permettant l’appel des bons dissecteurs ainsi que la configuration de Wireshark. Pour assurer nos deux types d’analyses, nous avons donc développés des bridges qui permettent de récupérer les trames brutes MAC collectées dans le réseau et d’ajouter les en-têtes nécessaires au fonctionnement avec Wireshark. Plusieurs bridges ont été nécessaires afin d’assurer les différents types d’analyses.
Par la suite, l’intercepteur Wismote est utilisé en mode off-line. De même que pour le réseau ZigBee, nous avons choisi de ne déployer qu’un seul intercepteur et de le placer proche du 6BR.
4.3.2 Exploitation des métadonnées du réseau 6LoWPAN sécurisé
4.3.2.1 Description des expériences
RPL et la couche d’adaptation 6LoWPAN ne permettent pas la mise en place de mécanismes de sécurité efficaces. Le réseau doit alors compter sur les autres couches pour l’activation de la sécurité. Le standard 6LoWPAN prévoit la possibilité de garantir le chiffrement et/ou l’authentification à chaque couche du modèle OSI et donc de moduler la sécurité en fonction du besoin. Il permet la mise en place de la sécurité soit au niveau de la couche transport via l’utilisation de DTLS soit au niveau de la couche réseau grâce à IPsec.
Nous avons donc menés deux expériences. Pour la première expérience, nous avons mis en place DTLS. Les en-têtes jusqu’à la couche transport sont accessibles en clair. Puis dans la seconde nous avons voulu observer les fuites d’information lors de l’utilisation d’IPsec. Contrairement à la première expérience, l’en-tête de la couche transport n’est plus accessible.
Les métadonnées encore disponibles sur le réseau malgré l’utilisation de l’une ou l’autre des sécurités sont étudiées et les vulnérabilités exploitables sont analysées.
Un même cas d’utilisation a été testé.
Lors de la mise en route du WSN, le 6BR est d’abord connecté au PC et alimenté. Les nœuds, déployés dans le bâtiment, sont ensuite mis en route successivement. La portée des Wismote étant faible, un réseau multi sauts est déployé. Dès qu’un nœud a forgé son adresse IP et a rejoint le réseau, il commence à communiquer même si tout le réseau n’est pas encore déployé. L’application est la suivante. Chaque nœud va, toutes les 10s, envoyer au 6BR une trame UDP contenant son identité ainsi que la valeur des trois axes de son accéléromètre. Contrairement au réseau ZigBee, ce n’est pas l’utilisateur qui fait la demande d’une donnée mais les capteurs qui émettent de manière périodique. Ainsi, les deux fonctionnements possibles des WSN sont étudiés.
Pour le réseau 6LoWPAN, les trames interceptées lors de la phase d’échanges de données correspondent donc aux envois périodiques en direction du 6BR. L’intercepteur assiste également à la phase de mise en route du réseau.
Les mêmes techniques d’analyse que celles présentées pour le réseau ZigBee sont utilisées. Néanmoins, avant l’analyse en profondeur des vulnérabilités, une analyse statistique est menée pour identifier le nombre de paquets malformés, ayant un "BAD FCS" ou ne pouvant être analysés. Il est regardé si la sécurité était activée dans les trames collectées. Cette étape permet également d’obtenir la fréquence de chaque type de trames (UDP/ICMP) émises dans le réseau, de les classifier et par conséquence, d’avoir une première vision du fichier et de s’assurer que l’intercepteur a bien collecté les communications.
4.3.2.2 Analyses des fuites d’information et exploitations
Comme pour la plateforme ZigBee, l’intercepteur assiste à la phase d’association des nœuds puis à celle d’échange de trames. Avec RPL, les phases de join et d’association sont regroupées en une seule phase. Dans la première expérience, la solution de sécurité activée est DTLS. Nous allons donc analyser les informations disponibles ainsi que leurs exploitations possibles.
DTLS laisse les données des en-têtes RPL visibles en clair. Il est donc possible d’identifier les différents types de trames et donc les protocoles en cours. Les en-têtes des couches plus basses sont également disponibles pour une analyse.
La phase d’association est réalisée grâce à l’utilisation de trames ICMPv6 RPL. La Figure 4.4 montre un exemple d’association repérée dans les trames collectées.
L’envoi d’une trame DIS RPL (en noir dans la Figure 4.4) indique le début de l’association pour le nouveau nœud ayant une adresse MAC terminant par 804. Les adresses sources MAC et IPv6 du nouvel arrivant sont disponibles en clair. Seuls les nœuds routeurs à proximité et appartenant déjà au réseau ainsi que le 6BR vont alors répondre en envoyant un DIO. Il est possible de connaitre les adresses (MAC et IPv6) des trois nœuds émetteurs. Collecter un DIS permet de déduire qu’un nouveau nœud veut rejoindre le réseau et collecter de l’information sur les nœuds à proximité dans le WSN. Néanmoins, à ce stade, il n’est pas possible de distinguer les nœuds routeurs du 6BR. Seul le rôle de feuille peut être écarté. Le nœud adresse
Figure 4.4 – Protocole d’association 6LoWPAN.
alors à son parent un DAO RPL. Une topologie locale peut ainsi être reconstruite. La procédure d’association par RPL offre de nombreuses informations sur le réseau :
• Un attaquant peut facilement identifier le début d’une phase d’association. Il va récupérer les adresses de tous les nœuds. Il peut alors lancer une attaque par DoS afin d’empêcher un nouveau nœud de rejoindre le réseau et le forcer à joindre un autre WSN mais également afin d’épuiser ses ressources. • Les adresses MAC et IPv6 étudiées avec les DIO émis à la suite d’un DIS permettent de déduire les
relations entre les nœuds. Un attaquant peut reconstruire la topologie locale.
• Enfin, l’identification par un attaquant de la phase d’association permet de connaitre le dynamisme du réseau. En effet, si dans un réseau où les communications semblent établies, un nœud vient réaliser une procédure d’association, cela implique que le réseau évolue et n’est pas statique. Cette information peut être pertinente dans certaines attaques.
Afin de maintenir les tables de routage à jour, RPL définit un protocole périodique utilisant des trames DIO et DAO.
Les informations exploitables grâce à l’observation de l’association sont également présentes dans le pro-tocole de maintien des tables. Un attaquant n’ayant pas assisté à la mise en place du réseau pourra donc obtenir les mêmes informations sur le réseau. Il lui suffira de chercher les trames DIO pour les adresses IPv6 observées dans ses données enregistrées ou d’attendre leur capture si c’est une analyse temps réel puis d’intercepter le DAO en réponse. Il pourra donc reconstruire la topologie, identifier les nœuds présents mais également déduire la périodicité des trames RPL. Il pourra enrichir sa topologie en incluant les nœuds feuilles. En effet, lors de l’association, comme ceux ci ne répondent pas aux DIS, les adresses n’apparaissent pas. Dans le protocole de routage tous les nœuds interviennent. Les nœuds feuilles vont donc participer au maintien du routage en envoyant un DAO à leurs parents. L’attaquant pourra récupérer les adresses et construire la topologie.
Cette périodicité de RPL, utile pour le maintien du routage, offre donc un avantage à un attaquant. Il est assuré, même lorsqu’aucunes applications n’est déployées, d’obtenir du trafic et donc de l’information sur le réseau. De plus, ce protocole lui permet de connaitre le dynamisme du réseau. En effet, si lors d’un maintien périodique, un nœud ne communique plus de DIO/DAO, il pourra alors déduire que celui-ci s’est déplacé dans le réseau ou l’a quitté. En cherchant les trames DIO/DAO liées à l’adresse de ce nœud, il pourra alors le suivre et observer ses mouvements dans le réseau.
La traçabilité mais également l’activité des nœuds sont donc facilement accessibles par écoute passive du protocole RPL.
Lors de l’échange de données, celles-ci sont remontées périodiquement au nœud puits, le 6BR. Cet échange utilise les trames UDP. L’intercepteur peut facilement surveiller le trafic arrivant au 6BR. Si l’adresse IPv6 d’un nœud est présent dans un grand nombre de communications ou possède une activité importante, l’atta-quant peut alors choisir de mener une attaque DoS sur ce nœud identifié afin de perturber voire d’endommager le WSN. En surveillant les communications, il connait toutes les routes actives ce qui lui permet de recons-truire la topologie sans attendre le protocole RPL. En effet, en analysant les adresses MAC et IPv6, il peut connaitre les nœuds intermédiaires mais également les nœuds source et destination.
En revanche, l’attaquant possède peu d’informations sur les communications en dehors de sa portée. En effet, il connait l’adresse IPv6 source de la trame mais ne possède aucune information sur le nombre de sauts qui séparent ce nœud du premier routeur à sa portée. L’écoute prolongée des communications va lui permettre de reconstruire petit à petit la topologie mais des incertitudes peuvent exister sur la topologie réelle en dehors de sa portée.
L’analyse du réseau protégé par DTLS montre que de nombreuses vulnérabilités viennent des informations de RPL disponibles. La mise en place du chiffrement à la couche Réseau permet de chiffrer l’en-tête de la couche transport indiquant le type de trame (UDP ou RPL) reçue. Un grand nombre d’information contenue dans les trames ICMPv6 et UDP sont ainsi cachées. Un attaquant ne peut plus utiliser les informations disponibles pour identifier le type de trames RPL et donc obtenir des informations sur le protocole en cours. Il ne peut plus, par simple analyse du protocole en cours, déduire le dynamisme du réseau. Il ne peut plus identifier le début du protocole d’association afin de mener ses attaques DoS.
En revanche, les métadonnées des couches plus basses sont toujours émises en clair ce qui offre de nom-breuses autres possibilités d’analyses.
La connaissance des adresses déjà présentes dans le réseau combinée à des analyses statistiques (fréquence, temporelle) permet de déduire l’activité des nœuds. Un attaquant peut également découvrir une nouvelle adresse non enregistrée et, par comparaison avec des motifs des communications connus, déduire qu’un nouveau nœud entre dans le réseau. Les trames suivantes sont alors des trames RPL et les adresses collectées correspondent alors aux routeurs ou au 6BR à proximité.
La disparition d’une adresse ou le changement de chemin de routage indique une disparition ou un mouvement de nœud. Enfin, l’auto configuration des adresses par le protocole SLAAC rend les adresses IPv6 fixes même lorsque le nœud se déplace dans le réseau. Cette information peut être utilisée par un attaquant pour déduire le trafic dans le réseau et reconstruire la topologie indépendamment du type de couche transport utilisée (UDP ou ICMPv6), simplement en se basant sur l’en-tête IPv6 qui reste disponible. Il peut déduire l’emplacement dans le WSN des nœuds suivant leurs adresses. Comme l’application consiste à envoyer au nœud puits les données, il peut découvrir l’adresse du 6BR. Il peut ainsi prendre le temps d’agréger des informations sur le réseau et ses nœuds afin de choisir la cible adéquate pour son attaque. Les attaques actives ciblées sont donc plus efficaces et ce malgré la sécurité. Pour conclure, que ce soit avec DTLS ou IPsec, les en-têtes encore visibles offrent de nombreuses informations sur le réseau et ses nœuds. IPsec permet néanmoins de limiter certaines vulnérabilités dues aux informations sur les protocoles disponibles en clair avec DTLS. Toutefois, l’en-tête Réseau contient les adresses IPv6 statiques utilisées pour les communications
end-to-end et nécessaires pour le routage. Un attaquant peut utiliser ces informations pour de l’analyse de trafic
afin de retrouver la topologie du WSN. De plus, l’utilisation de SLAAC, qui permet une auto configuration rapide et simplifiée des adresses IPv6 appropriée aux WSN, facilite le suivi des nœuds lorsque ceux-ci sont en mouvement. Ce fonctionnement facilite également la mise en place d’attaques actives ciblées. Enfin, l’analyse des adresses (MAC et IPv6) combinée à d’autres analyses de vie privée permet de déduire des informations sur le protocole, informations normalement protégées par l’utilisation de la confidentialité à la couche Réseau.