Les expériences menées sur nos deux plateformes montrent, qu’indépendamment du standard, des fuites d’informations persistent même lorsque la sécurité des couches hautes est activée. Ces informations sur les nœuds et le réseau peuvent être exploitées par un attaquant dans le but de mener des attaques ciblées plus puissantes.
Pour le réseau ZigBee, la mise en place de la sécurité couche NTW est inutile pour les phases de join et d’association car les trames échangées sont des trames MAC IEEE 802.15.4. La sécurité des couches plus hautes est donc sans effet. Durant la phase d’échange de données, l’analyse de trafic est faisable même lorsque la sécurité est établie. Pour cela, un attaquant peut utiliser le champ "Radius" combiné aux champs concernant les adresses contenues dans l’en-tête NTW ZigBee. Il peut ainsi reconstruire la topologie et déduire le rôle des nœuds ce qui lui permet de choisir la cible la mieux adaptée pour une attaque active. Une solution consiste à activer la sécurité MAC IEEE 802.15.4. Ainsi, elle permet d’obtenir une phase d’association sécurisée auprès d’un coordinateur légitime car possédant la bonne clé de chiffrement. Les données contenues dans l’en-tête NTW et utilisées pour l’analyse de trafic ne sont alors plus accessibles en clair.
Pour le réseau 6LoWPAN, même si l’utilisation du chiffrement couche Réseau permet de protéger l’asso-ciation, l’analyse de trafic apporte de nombreuses informations de vie privée sur le réseau et ses participants. La couche Réseau IPv6 est notamment une couche porteuse d’un grand nombre d’informations exploitables par un attaquant pour cette analyse de trafic. Il va alors utiliser les adresses IPv6 source et destination conte-nues dans l’en-tête Réseau pour suivre le message et recréer les chemins et la topologie. SLAAC permet aux adresses d’être statiques. Un attaquant peut donc également exploiter cette propriété pour suivre un nœud et son activité. Là encore, une solution consiste à activer la sécurité MAC qui assure ainsi la confidentialité des informations portées par la couche Réseau et les couches au-dessus.
Dans les deux réseaux étudiés, l’une des vulnérabilités communes vient de la possibilité grâce à la couche Réseau (NTW ou IPv6) de réaliser de l’analyse de trafic dévoilant des informations sur le réseau, sa topologie et ses nœuds. L’idée est donc d’assurer la confidentialité des métadonnées de cette couche via l’utilisation de la sécurité au niveau le plus bas, c’est-à-dire au niveau MAC.
Le front-end XBee dans sa version actuelle utilisée sur les nœuds Waspmote et assurant le déploiement du standard ZigBee PRO ne permet pas d’activer la sécurité IEEE 802.15.4 MAC. Il est donc nécessaire de développer une nouvelle puce radio compatible ZigBee incluant les spécifications du standard IEEE 802.15.4e pour la sécurité. En réalisant les calculs cryptographiques au niveau matériel, l’utilisation de la sécurité devient transparente pour les couches hautes du standard ZigBee. Pour le réseau 6LoWPAN, Contiki permet de mettre en place la sécurité MAC grâce à un AES logiciel. Néanmoins, la version 2.6 de Contiki n’offre pas la possibilité d’activer la sécurité de la version 2012.
Sokullu, Korkmaz et al. montrent dans [95] que la sécurité à cette couche permet également d’empêcher ou de limiter un grand nombre d’attaques actives sur la couche MAC comme les attaques par injection de paquets. Néanmoins, il est nécessaire, à chaque saut, de déchiffrer puis de chiffrer à nouveau une trame lorsque celle-ci doit être routée. De plus, afin d’éviter les failles de sécurité, le management des clés doit être fait avec précaution. Nous avons vu dans l’analyse précédente sur le réseau ZigBee que la clé utilisée pour la sécurité NTW pouvait être envoyée en clair lors de la phase d’association. Ce fonctionnement dangereux est à proscrire au prix de casser la sécurité et la protection de la vie privée du WSN. Une manière correcte de procéder consiste à pré installer en priorité la clé nécessaire pour le chiffrement couche MAC. Celle-ci permet de protéger le réseau d’un attaquant passif extérieur. De plus, elle serait active dès la phase de join afin d’authentifier et de chiffrer les échanges. Si le WSN souhaite par la suite mettre en place une sécurité sur les couches plus hautes, les clés pourront être négociées et échangées de manières chiffrées par la clé MAC. Elles peuvent également être pré installées de la même manière que la clé MAC pour éviter qu’elles soient connues de tous les nœuds pré configurés avec la même clé MAC. Néanmoins, cette solution nécessite une réflexion avant déploiement et un travail de configuration par l’utilisateur.
Dans un réseau sécurisé au niveau de la couche MAC, les métadonnées de l’en-tête MAC sont encore exposées à de l’écoute passive. Il est donc nécessaire d’étudier les métadonnées exploitables dans cette couche MAC.
La Figure 4.5 donne les différents champs accessibles à un attaquant lorsque la sécurité est activée à la couche MAC.
Le champ "Frame Control" donne de nombreuses indications à un attaquant concernant le réseau et son dynamisme. Elles lui permettent de choisir l’attaque la mieux adaptée. Notamment, le champ "Security Enabled" (SE) indique si la sécurité est activée. Un attaquant peut utiliser cette information pour choisir un réseau non sécurisé s’il souhaite mener une attaque rapide et peu coûteuse ou encore pour mettre en place les
Figure 4.5 – En-tête MAC disponible en clair par écoute passive.
outils et attaques appropriées pour tenter de passer la sécurité. Il peut également utiliser la connaissance de l’activation de la sécurité pour mener une attaque par exhaustion de batterie. En effet, lorsqu’un nœud reçoit une trame sécurisée, le standard MAC définit que la trame doit être dans l’ordre déchiffrée puis authentifiée. Un attaquant peut forger une trame ayant les bons champs de l’en-tête MAC mais un payload chiffré et un MIC faux. Le nœud va alors faire les opérations coûteuses de vérification inutilement. En répétant l’opération, le nœud va épuiser rapidement sa batterie.
La plus grande faille lorsque la sécurité est activée au niveau de la couche MAC est portée par les adresses. En effet, celles-ci ne peuvent être cachées car utiles au routage. Il est possible de réaliser alors de l’analyse de trafic hop-by-hop et ainsi de déduire la topologie. Néanmoins, cette reconstruction est fortement limitée à la portée du collecteur. Elles peuvent également être utilisées pour des attaques ciblées. En effet, ces adresses sont statiques et liées au matériel. Un attaquant peut donc les utiliser pour faire du scan d’adresses, corréler les activités d’un nœud au sein du réseau ou même lorsque celui-ci est mobile entre plusieurs réseaux. La connaissance de l’adresse MAC liée au matériel lui permet d’identifier les vulnérabilités spécifiques à ce matériel et de mettre en place une attaque en conséquence. Les adresses étant statiques, l’attaquant possède tout le temps nécessaire pour mener à bien son attaque.
Afin d’éviter ou du moins de limiter l’utilisation de la connaissance des adresses dans des attaques plus puissantes, une contre mesure consiste à empêcher un attaquant d’observer une adresse et de la relier à un nœud. Pour cela, il est possible d’utiliser des techniques d’anonymat ou des pseudonymes. Ainsi l’attaquant ne pourra pas utiliser l’adresse pour cibler un nœud intéressant ou pour le suivre lorsque celui-ci est en mouvement.
4.5 Conclusion
Dans cette partie, nous avons étudié les fuites d’informations concernant deux modèles basés sur le standard IEEE 802.15.4 : le ZigBee et le 6LoWPAN.
Pour chacun de ces réseaux, nous avons testé différents mécanismes de sécurité proposés et analysé les métadonnées encore disponibles. Les réseaux ont été étudiés pendant deux phases de vie différentes. Dans un premier temps, nous avons observé les informations disponibles lorsque le réseau s’établit. Puis nous avons étudié les communications lors de l’échange de données et du maintien du routage.
Malgré la possibilité qu’offre les deux standards d’activer la sécurité à la couche Réseau, les métadonnées disponibles ainsi que leur exploitation ne sont pas identiques.
Tout d’abord, les phases de join et d’association définies par le standard ZigBee sont plus sensibles à de l’écoute passive que celles du standard 6LoWPAN. En effet, la sécurité ZigBee ne permet pas d’assurer la confidentialité de cet échange. L’échange est accessible en clair et un attaquant peut mener des attaques sur le protocole plus facilement. Il peut forger de faux protocoles de join et d’association pour mener des attaques DoS ou tenter d’attirer les nouveaux nœuds dans son propre réseau. Il peut également facilement identifier le début du protocole et en déduire la dynamique du réseau. La sécurité couche Réseau de 6LoWPAN permet de cacher cet échange et donc de le protéger contre ces attaques. L’échange étant chiffré, un attaquant ne peut alors pas forger de fausses trames afin de reproduire une fausse association sans connaitre la clé. Un attaquant doit déployer des techniques d’analyse de trafic plus poussées pour identifier le protocole dans les données collectées. Néanmoins, avec des recherches sur les motifs des protocoles et des en-têtes des trames, il est capable d’inférer le déroulement du protocole d’association et donc de l’analyser. Il peut ainsi avoir accès au dynamisme du réseau.
De plus, un attaquant a accès à plus d’informations sur les nœuds et le réseau avec ZigBee. Les champs présents lui permettent de connaitre le PAN ID, les différentes adresses, les capacités des nœuds mais également leurs rôles et, si le ZC est présent, de l’identifier par rapport aux autres nœuds. Il peut reconstruire la topologie. L’écoute du protocole d’association de 6LoWPAN uniquement ne permet pas de distinguer les nœuds routeurs du nœud 6BR. Les informations présentes permettent uniquement d’écarter le rôle de feuille. Comme pour le réseau ZigBee, un attaquant connait le PAN ID et les différentes adresses (MAC et IPv6) et peut commencer une reconstruction de la topologie.
L’échange de données et le maintien du routage permettent à un attaquant, indépendamment de la plateforme, de réaliser de l’analyse de trafic. Cette analyse de trafic permet de retrouver les identités des différents nœuds du réseau et la topologie. Il permet également de retrouver la mobilité des nœuds et leurs activités. Néanmoins, l’en-tête Réseau de ZigBee permet une analyse plus poussée et une reconstruction plus optimale en cas de portée limitée de l’intercepteur. En effet, la connaissance du champ "Radius" accessible en clair dans l’en-tête NTW permet d’indiquer à un attaquant le nombre de sauts réalisés depuis l’émission de la trame et donc, si un attaquant patiente assez longtemps, permet avec la connaissance des adresses de retrouver la topologie hors portée. Dans le cas du réseau 6LoWPAN, le nombre de sauts hors portée n’est pas indiqué. L’attaquant a donc une vision plus limitée et doit déployer plus de force pour reconstruire la topologie complète (par exemple, déployer plusieurs intercepteurs). En revanche, l’utilisation dans les réseaux 6LoWPAN du protocole SLAAC offre la possibilité de suivre plus facilement un nœud même lorsque celui-ci change de réseau. L’adresse MAC étant liée à l’adresse IPv6 un attaquant peut donc déduire des adresses IPv6 les adresses MAC, même des nœuds hors de portée, ce que ne peut pas faire un attaquant dans un réseau ZigBee. Enfin, la présence de l’adresse destination dans l’en-tête réseau permet d’identifier l’adresse IPv6 du 6BR.
Les failles viennent donc principalement des protocoles de join et d’association non sécurisés et de l’analyse de trafic réalisable grâce aux différentes informations contenues dans les en-têtes Réseau.
Un moyen de réduire les métadonnées disponibles est de mettre en place la sécurité sur la couche la plus basse du modèle OSI c’est à dire la couche MAC. Ainsi les adresses Réseaux par exemple ne pourront plus être accessibles par simple écoute. La confidentialité des données de la couche Réseau sera assurée. Néanmoins, même lorsque celle-ci est utilisée, l’en-tête MAC reste disponible en clair et sujet à de l’analyse de trafic. Une analyse des métadonnées disponibles lorsque la sécurité MAC est activée a révélé que les adresses MAC utiles pour le routage et ne pouvant être cachées représente une information importante pour l’analyse de trafic.
Les identifiants permanents que sont les adresses MAC peuvent être utilisés pour suivre un nœud ou pour inférer des informations sensibles utiles aux attaques actives ciblées. Un moyen de contrer ces attaques est de masquer les adresses utilisées pour le routage et présentes dans les en-têtes. Ainsi, il ne sera plus possible d’associer une adresse avec un hôte spécifique ou de retrouver sa localisation. Les techniques d’anonymat et d’utilisation de pseudonymes ont alors rapidement été adoptées pour répondre à ce problème. Par exemple, elles sont utilisées dans des produits grands publics comme iOS 8 ou encore Tail Linux.
Néanmoins, ces techniques ajoutent de la complexité lors du routage notamment dans les réseaux contraints. Nous allons donc voir dans la prochaine partie quelles solutions de l’état de l’art existent et si elles sont ap-plicables aux contraintes des WSN.
Partie 5
Solutions de l’état de l’art pour
dissimuler ses identifiants
Dans cette partie, les contre mesures de l’état de l’art sont étudiées afin d’identifier la solution de dissimulation des identifiants la plus appropriée aux contraintes des WSN. Nous allons présenter les solutions utilisant les techniques d’anonymat ainsi que celles utilisant les pseudonymes. Nous allons analyser chaque solution vis-à-vis de sa compatibilité avec les contraintes des WSN. Nous allons montrer que beaucoup de solutions dédiées aux réseaux classiques, et notamment les techniques permettant l’anonymat, sont incompatibles et qu’il est nécessaire de déployer une solution pensée pour les réseaux de capteurs.
5.1 Introduction
L’utilisation des identifiants permanents comme adresses ou partie des adresses rend le déploiement des réseaux sans fil plus rapide et efficace. C’est pourquoi les méthodes stateless comme SLAAC ont pris de plus en plus de place dans les processus de génération d’adresses. Grâce à la réutilisation de l’adresse MAC liée au matériel, le processus de génération des adresses IPv6 est plus rapide mais assure également l’unicité des adresses sans ajout de trafic.
Ces adresses sont fondamentales pour assurer les communications mais peuvent être exploitées par un attaquant pour mener des attaques ciblées. De plus, les cacher d’une écoute passive n’est pas facilement réalisable. Ainsi, même lorsque le chiffrement est activé à la couche la plus basse, les adresses MAC sont toujours disponibles en clair. Afin de limiter les fuites d’identifiants permanents dans les communications sans fil et leurs exploitations par un attaquant, il est donc nécessaire de déployer une solution de protection de la vie privée. Plusieurs voies peuvent être explorées.
Les solutions étudiées sont basées sur deux principes différents : 1. L’anonymat
2. L’utilisation de pseudonymes
Kelly et al. expliquent dans leur livre [96] que le principe d’anonymat consiste à empêcher une identité d’être liée à un ensemble spécifique d’activités grâce à des méthodes d’obfuscation. Ainsi, dans l’Internet classique, l’anonymat consiste à permettre l’utilisation des services Internet sans révéler l’identité ou la loca-lisation de l’utilisateur. Cette identité inclut les adresses MAC et/ou IP. Un service d’anonymat doit laisser à l’utilisateur le choix de diffuser ou non les informations permettant son identification. De nombreuses re-cherches ont été menées pour assurer l’anonymat dans le monde IP classique. Kelly et al. dans [96] détaillent le nombre conséquent de solutions existantes dans le monde du filaire ainsi que les avantages et les inconvé-nients de chaque solution. En ce qui concerne les réseaux sans fil, peu de littérature existe. L’article détaille néanmoins certaines des contre mesures adaptées aux contraintes de ce type de réseau.
En ce qui concerne l’utilisation de pseudonymes, les méthodes utilisées vont générer des pseudonymes que les clients vont pouvoir utiliser pour remplacer les champs d’identités et d’adresses présents dans les paquets transmis pour leurs communications. L’activité d’un pseudonyme ne sera pas obfusquée mais il sera
impossible de remonter à l’identité, l’activité ou la localisation du nœud réel présent dans le réseau. Il sera également impossible de lier deux pseudonymes utilisés par la même entité.
Néanmoins, les réseaux dans lesquels ces solutions sont déployées doivent conserver des performances raisonnables et permettre une qualité de service correcte. Les solutions ne doivent pas non plus introduire des failles de sécurité. Pour qu’une solution de dissimulation des identifiants soit convenable il faut qu’elle puisse fonctionner avec les critères de sécurité du réseau comme, par exemple, autoriser le contrôle d’accès.
Les solutions présentées par la suite vont donc être analysées sur plusieurs points :
• Protection de la vie privée : les attaques favorisées par l’utilisation des identifiants permanents sont-elles encore réalisables ? Des fuites d’identifiants peuvent-elles encore mener à des vulnérabilités exploitables par un attaquant ?
• Environnement : est-ce que cette solution est réalisable dans un réseau de capteurs (nœuds contraints, mobiles, topologie complexe) ?
• Sécurité : est-ce que la solution ne remet pas en cause la sécurité ? Est-il possible de légitimer le nœud avec l’aide / sans aide d’une autorité ?
• Performance : dans quelle mesure la solution détériore les performances du réseau ?
• Concordance : est-ce que cette solution fonctionne avec les protocoles utilisés dans 6LoWPAN (RPL, SLAAC) ? En effet, les solutions décrites par Kelly et al. dans le livre [96] ne sont pas étudiées vis-à-vis d’un réseau spécifique et donc du contexte décrit précédemment dans la partie 3 pour les WSN. Il faut donc veiller à ce qu’une solution soit utilisable avec les protocoles déployés dans les WSN.