Les nœuds de capteurs utilisés

Le deuxième challenge que doit relever le déploiement de réseaux 6LoWPAN concerne le choix du matériel. Contiki supporte un grand nombre de plateformes. Contrairement à certains OS, il ne limite pas la classe d’appareil utilisée.

En effet, l’IETF a publié une catégorisation des différents appareils pouvant être déployés dans l’IoT. Pour classifier les appareils, l’IETF a utilisé la capacité en mémoire, critère important dans le monde du contraint. Trois catégories ont ainsi émergées :

• Classe 0. Dans cette catégorie se trouvent les appareils les plus contraints en mémoire. C’est dans cette catégorie que l’on retrouve principalement les nœuds qui seront utiles pour les WSN. Ils possèdent beaucoup moins de 10 kB RAM et 100 kB de mémoire flash.

• Classe 1. Cette catégorie regroupe les appareils avec des ressources moyennes autour des valeurs précé-dentes. C’est généralement ce type de nœuds qui assure des fonctionnalités telles que le routage. Ils ne peuvent implémenter des protocoles comme HTTP mais peuvent utiliser ceux dédiés contraints comme CoAP.

• Classe 2. Ce sont les appareils les moins contraints par rapport aux précédents. Néanmoins, il reste plus contraint que les appareils tels que les gateway.

Pour la classe 0, l’utilisation d’un OS est très compliquée mais pas impossible. Les OS doivent optimiser au mieux l’espace mémoire et les allocations. Il est très compliqué de faire fonctionner un OS temps réel dans ce type de nœuds. Contiki peut fonctionner avec les trois classes même si, pour les appareils de classe 2, d’autres OS lui seront préférables.

Pour cette thèse, trois types de carte vont être utilisés. En effet, afin d’analyser les fuites d’informations ayant lieu lors de communications sans fil IEEE 802.15.4, il est nécessaire de mener des expériences sur le modèle OSI complet. Nous avons décidé de comparer les failles existantes avec ZigBee mais également avec 6LoWPAN. Ces études nous permettrons de mettre en place la meilleure sécurité mais également d’identifier les failles communes entre les deux standards.

(a) Carte Wasp-mote.

(b) Carte Wismote. (c) Carte Open-mote.

Figure 3.14 – Matériels utilisés.

La première carte utilisée est une Waspmote (Figure 3.14(a)). De la marque Libelium, cette carte open

source possède une RAM de 8 kB et une Flash de 128 kB. Elle appartient à la classe 1. Elle possède

égale-ment 8 entrées/sorties numériques et de nombreux bus (SPI, UART...) ainsi qu’un capteur de température, d’humidité et un accéléromètre. La front end utilisée est une XBee embarquant la version PRO du standard ZigBee permettant les communications sur la bande 2,4 GHz. Cette carte a été utilisée pour l’analyse des fuites d’identité dans un réseau ZigBee. Un Integrated Development Environment (IDE) est nécessaire afin de programmer les cartes. Les trois types de clés de sécurité définies par le standard ZigBee sont déployés. Il est possible de déployer un réseau meshé ainsi que de définir les différents rôles. Néanmoins, le rôle de la

gateway a été réalisé par un Raspberry PI permettant d’adresser les nœuds depuis le web afin d’obtenir un

comportement identique à un réseau 6LoWPAN. C’est une plateforme OSGI (Open Services Gateway Ini-tiative) accessible depuis Internet via une adresse IPv4. Elle inclut un serveur HTTP ainsi qu’une interface RESTful et l’API nécessaire pour le front end XBee.

Pour le réseau de test 6LoWPAN, la carte utilisée est une Wismote d’Arago Systems (Figure 3.14(b)). L’antenne est une antenne CC2520 permettant les communications IEEE 802.15.4. Elle possède une RAM de 16kB et une flash de 128 kB, ce qui la classe en catégorie 1. Le CPU est un MSP430. Un capteur de température, un de luminosité ainsi qu’un accéléromètre sont disponibles sur la carte. Wismote autorise l’implémentation de Contiki comme OS ce qui permet la mise en place d’un réseau 6LoWPAN. Pour cela, une machine virtuelle possédant les Board Support Package (BSP) nécessaires à la programmation des cartes ainsi que le code source de l’OS est fournie sur le site de Contiki. Néanmoins, la dernière version de Contiki (3.0) n’est pas disponible. Or, cette version corrige des problèmes de sécurité, implémente plus de caractéristiques notamment pour la dernière version de IEEE 802.15.4. Après plusieurs essais afin de mettre en place le BSP sur Contiki3.0, et du fait que les caractéristiques semblaient trop contraintes, le choix de changer de carte s’est imposé.

Nous avons donc utilisé une carte OpenMote (Figure 3.14(c)). Munie d’une antenne CC2538, ce System

on Chip (SoC) combine un microcontrôleur Cortex M3 de 32-bit et une radio CC2520. Sa RAM est de 32

Kb et elle possède 512 kB de Flash. Elle est donc plus puissante que les précédentes. La carte se programme grâce à une base et une sonde j-link puis fonctionne sur piles.

3.4 Conclusion

De nombreux standards peuvent être déployés dans l’IoT. Le WiFi et le Bluetooth sont deux de ces standards bien connus du grand public. De ce fait, ils ont également été très étudiés en terme de sécurité mais également pour la protection de la vie privée

De plus, les contraintes fortes des WSN combinées au nouveau modèle de communication (faible portée mais durée de vie importante) font que ces deux standards ne sont pas adaptés aux nouvelles applications des WSN.

Un nouveau standard a donc été publié par l’IETF afin de répondre aux nouveaux besoins de ces en-vironnements. L’IEEE 802.15.4 a été spécialement conçu pour des réseaux à faible débit et portée, où les paquets peuvent être perdus et où la consommation d’énergie doit être maitrisée. Pour cela les couches MAC et Physique ont été étudiées afin de réduire à son strict minimum cette consommation. Des spécifications ont

également été données concernant la capacité à déployer la sécurité couche MAC.

Néanmoins, ce nouveau standard ne définit que les couches basses. Deux modèles OSI basés sur IEEE 802.15.4 ont donc été développés, le ZigBee issu d’un consortium d’entreprises et 6LoWPAN standardisé par l’IETF. Ils permettent de gérer les protocoles d’associations mais également de routage.

Contrairement au ZigBee, 6LoWPAN est prévu pour interconnecter le réseau IP et les WSN grâce à la réutilisation des couches hautes classiques du monde IP et à l’ajout d’une couche d’adaptation entre la couche MAC et la couche Réseau permettant de respecter les contraintes de tailles sur la trame MAC IEEE 802.15.4. Il définit RPL comme protocole de routage adapté aux WSN et utilise SLAAC avec l’adresse MAC des nœuds pour l’auto configuration des adresses IPv6 utilisées dans le réseau.

Etant peu connu du grand public et relativement récent, les métadonnées des en-têtes MAC IEEE 802.15.4 visibles par écoute passive ont été très peu étudiées et leurs exploitations sur la vie privée peu analysées.

Le matériel et l’OS ont été choisis de manière à permettre le déploiement de deux réseaux de tests basés sur le standard IEEE 802.15.4 sur lesquels une écoute passive sera menée. Les informations collectées seront ensuite analysées pour extraire des informations de vie privée sur les nœuds et plus globalement sur le réseau et son environnement. Cette analyse complète permettra de déployer une solution de protection des identifiants adaptée à cet environnement contraint.

Partie 4

Exploitation des métadonnées

collectées par écoute passive

Dans cette partie, notre objectif est de montrer qu’il est possible d’inférer un maximum d’information sur les réseaux de capteurs IEEE 802.15.4 bien que la sécurité soit activée. Pour cela, nous allons exploiter toutes les informations qui transitent en clair sur l’air, notamment celles contenues dans les en-têtes des messages. Nous allons montrer qu’en interceptant les messages sur une période temporelle suffisamment étendue, il est facile de déduire le protocole d’échange, la topologie du réseau ou encore l’identité, la capacité ou le rôle des capteurs et des routeurs. Ces informations collectées de façon passive, sans intrusion et avec très peu de moyens sont très utiles pour lancer ensuite des attaques actives visant précisément une vulnérabilité du système. Aussi bien la technologie ZigBee que la technologie 6LoWPAN seront expérimentées, avec pour chacune la mise en œuvre d’un dispositif d’interception dédié.

4.1 Introduction

De notre point de vue, l’IEEE 802.15.4 représente le standard le mieux adapté aux contraintes des dé-ploiements de réseaux de capteurs sans fil contraints. Nous avons montré que la protection de la vie privée dans les WSN est difficile à assurer. Le chiffrement a permis de résoudre le problème de confidentialité des données échangées. Néanmoins, un attaquant peut encore effectuer une collecte massive des métadonnées des en-têtes et déduire des informations sensibles de ces métadonnées.

Afin de fournir la contre mesure adéquate, il est tout d’abord nécessaire d’identifier quelles sont ces métadonnées ainsi que les possibles utilisations de celles-ci par un attaquant. Nous avons donc voulu analyser les métadonnées disponibles dans les réseaux IEEE 802.15.4 et exploitables pour inférer des informations de vie privée sur le réseau et ses participants.

Dans la partie précédente, deux modèles basés sur le standard IEEE 802.15.4 ont été introduits. Le standard ZigBee qui permet de créer des réseaux de capteurs meshés. C’est un standard utilisé notamment dans le domaine de l’habitat intelligent grâce à des modules plug and play faciles d’utilisation. Et 6LoWPAN qui, quant à lui, permet l’émergence de nouveaux WSN déployés à grande échelle, possédant des nœuds de capteurs pouvant être en mouvement et surveillés depuis un smartphone grâce au protocole IP.

Afin d’analyser les métadonnées disponibles pour un attaquant passif, deux plateformes sécurisées sont donc déployées : une ZigBee et une 6LoWPAN. Des intercepteurs ainsi que des outils d’analyses sont également développés. Nous avons analysé les fuites existantes dans chacun des réseaux indépendamment puis nous avons voulu identifier quelles informations étaient disponibles lorsque la sécurité est activée à la couche MAC.