Présentation de l’IEEE 802.15.4

Les caractéristiques nécessaires à la compréhension de la thèse sont données dans cette partie.

La plupart des OS actuels implémente la version 2006 [72] du standard IEEE 802.15.4 malgré la publication d’une révision en 2012. On peut noter que Kernel Linux 4.4 intègre depuis octobre 2015 la version 2012 du standard. Si aucune indication n’est donnée, la version étudiée est donc celle de 2006.

Pour de plus amples détails sur le standard, le lecteur est invité à consulter les standards ( [71–73]).

3.3.2.1 La couche Physique

La couche Physique permet d’activer/désactiver la radio. Ainsi, un nœud pourra être en veille et écono-miser de l’énergie. Elle est responsable de la transmission et de l’émission sur le média. Elle met en place les techniques d’étalement de spectre ainsi que la modulation et la démodulation du signal. Elle va permettre de sélectionner le canal et faire de la détection d’énergie du signal sur ce canal. Elle va également permettre de calculer le Link Quality Indicator (LQI) après réception d’une trame afin d’évaluer la qualité du lien.

Suite aux dernières versions du standard, la couche Physique exploite maintenant 8 bandes ISM

(Indus-trial Scientific Medical) dont les trois traditionnelles (de 2003) 868 MHz, 915 MHz et 2.4 GHz. 93 canaux

se partagent ces bandes. Des bandes ont également été ajoutées afin de permettre l’utilisation de l’Ultra

Wide Band (UWB) dans les techniques de localisation. La couche Physique permet également d’utiliser 7

modulations différentes.

Pour les bandes traditionnelles, 16 canaux se trouvent dans la bande 2.4 GHz, 10 dans la bande 915 MHz et 1 dans la bande 868 MHz. La bande 868-868.6 MHz est utilisée dans les pays européens, celle de 902-928 MHz est utilisée en Amérique du Nord et enfin la 2.4-2.483 GHz sert pour le monde entier.

Selon la bande utilisée, le débit peut aller de 20 à 250 kbit/s.

Dans la version de 2003, seul deux modes de fonctionnement existaient. En 2012, afin de pallier aux problèmes du monde industriel, 4 nouveaux modes sont venus s’ajouter. D’autres modes sont proposés dans la version 2012 et notamment une version Low Energy (LE). Néanmoins, par manque de spécifications des couches hautes à utiliser aux dessus de ces nouveaux modes, le déploiement n’est pas encore réalisé et réalisable.

Enfin la couche Physique gère l’accès au canal.

En effet, pour pouvoir communiquer, les nœuds doivent utiliser le protocole Carrier Sense Multiple Access

with Collision Avoidance (CSMA-CA) afin d’éviter les collisions. Pour cela, un nœud va choisir un temps

d’attente appelé backoff period. Dès que le temps est écoulé, le nœud va sonder le média. Il utilise le Clear

Channel Assessment (CCA). Ce processus peut prendre différentes formes et permet de déterminer si le média

est libre ou si un nœud voisin est en train d’émettre. Si celui-ci est occupé, le nœud repart sur une nouvelle période d’attente. Ce principe permet d’éviter un maximum de collisions même s’il n’est pas infaillible et qu’il est possible, si des demandes sont faites simultanément, de voir une collision.

3.3.2.2 La couche MAC

La couche MAC fournie une interface entre les couches hautes et la couche Physique. De ce fait, certains mécanismes décrit précédemment comme mécanismes de la couche Physique peuvent être considérés comme gérés par la couche MAC. C’est notamment le cas de la gestion de l’accès au canal ou encore le choix du duty

cycle pour la veille.

Elle permet la validation des trames mais assure également les protocoles d’associations/désassociassions et de sécurité. Pour cela, la couche MAC (version 2012) définit six types de trames :

• Beacon et Enhanced Beacon • Multipurpose

• Data

• Acknowledgment • MAC command

Comme indiqué précédemment, seules les trames utiles pour la compréhension de la suite seront présentées. Les trames "LLDN", "Multipurpose" et "Enhanced Beacon" sont spécifiques au mode de fonctionnement introduit dans la révision de 2012. Toutes les trames MAC suivent le format général présenté dans la Figure 3.2. La taille maximale d’une trame IEEE 802.15.4 est de 127 octets.

(a) Format de la version 2006. (b) Format de la version 2012.

Figure 3.2 – Format général des trames MAC IEEE 802.15.4.

Dans la Figure 3.2, les deux versions des trames MAC (2006 et 2012) sont mises en juxtaposition. Le champ SE du "Frame Control" donne des informations à propos de la sécurité. Si "SE" (Security

Enabled) est à 1 cela indique l’utilisation de la sécurité couche MAC et la présence du champ ASH dans

l’en-tête MAC, sinon celui-ci est absent. Le champ ASH sera détaillé dans la partie sécurité du standard IEEE 802.15.4. Ce champ permet de définir quelle sécurité est mise en place ainsi que les informations nécessaires pour générer les Initialization Vector (IV).

Les champs d’adresses présents dans l’en-tête permettent d’effectuer le routage hop-by-hop. Nous avons vu que les adresses représentaient une fuite importante d’information de vie privée pour les nœuds car elles pouvaient être utilisées pour mener des attaques ciblées ou faire de l’analyse de trafic.

Un champ "IE list present" est ajouté entre la version 2006 et 2012 dans FC afin d’indiquer la présence ou non des champs IE dans l’en-tête MAC. En effet, la version 2012 modifie quelque peu le format de l’en-tête MAC. Afin de permettre l’utilisation des nouveaux modes d’opérations définis dans la partie sur la couche Physique sans introduire de nouvelles trames ainsi que de permettre la mise à jour dans le futur du format des trames sans une refonte complète, le standard a ajouté un champ "Information Elements" (IE) de taille variable. Ce champ se compose de deux parties : l’une appartenant à l’en-tête MAC et l’autre à son payload. Ainsi, si besoin, les données contenues dans le payload peuvent être chiffrées à l’aide de la sécurité MAC.

Il est possible d’insérer un ou plusieurs champs IE. Il permet d’encapsuler l’information facilement. Il est également possible d’avoir des en-têtes sans payload. Cette amélioration de la norme est utilisée dans la thèse par la suite.

Pour pallier à une faille de sécurité existante jusqu’à la version 2012, la trame "Acknowledgment" a été modifiée. En effet, le premier format de la trame était pensé pour être le plus simple possible afin de ne pas occuper trop le média ni nécessiter trop d’énergie. Elle était alors composée uniquement des champs FC, SN et du FCS de la Figure 3.2. Comme aucune sécurité n’était possible avec cette trame, des attaques utilisaient cette faille pour forger de faux acquittements.

La nouvelle version de la trame d’acquittement permet d’insérer des champs d’adresses mais également de la sécurité. Néanmoins, ce processus de sécurité apporte des fuites d’identités. En effet, là où un attaquant passif n’avait pas d’information sur qui acquittait qui, avec le nouveau format, il peut suivre les échanges et reconstruire la topologie plus facilement.

La sécurité a évoluée entre la version 2003 et 2012. Certaines améliorations permettent, comme le chiffre-ment de la trame "Acknowledgchiffre-ment", de combler des failles. D’autres ont été pensées pour faciliter l’implé-mentation et la compréhension des mécanismes.

3.3.2.3 La sécurité

Le standard définit différents niveaux de sécurité. Il a pour objectif d’assurer :

• La confidentialité des données • L’authenticité des données • L’intégrité de la trame

• La protection contre les attaques par rejeu

Indépendamment du niveau choisi, la protection contre les attaques par rejeu est toujours activée.

SL Suite Confidentialité Authenticité

00 Non Non Non

01 MIC 32 Non Oui (M=4) 02 MIC 64 Non Oui (M=8) 03 MIC 128 Non Oui (M=16)

04 ENC Oui Non

05 ENC-MIC 32 Oui Oui (M=4) 06 ENC-MIC 64 Oui Oui (M=8) 07 ENC-MIC 128 Oui Oui (M=16)

Table 3.3 – Niveaux de sécurité.

Si un développeur choisi un niveau de sécurité égal à 0 alors aucune sécurité n’est déployée. Les niveaux de sécurité de 1 à 3 de la Table 3.3 permettent uniquement la mise en place de la vérification de l’intégrité de la trame alors que les niveaux de 5 à 7 permettent d’assurer la confidentialité et l’intégrité. Le niveau 4, quant à lui, ne permet que le chiffrement de la trame. Il est recommandé d’utiliser un niveau de 7.

Un seul et même algorithme est utilisé afin d’assurer tous les niveaux de sécurité. En effet, le standard utilise le chiffrement authentifié AES-CCM* qui combine le mode CTR de l’AES pour le chiffrement et CBC-MAC pour l’authentification. Dans une précédente version de la norme, l’AES-CCM était recommandé mais ne permettait pas de faire du chiffrement seul ou de l’authentification seule.

La version Advanced Encryption Standard-Counter with CBC-MAC (AES-CCM) possède des inconvé-nients qui limitent son utilisation. Rogaway et al. détaillent dans [74] certaines d’entre elles et donne une solution prenant le meilleur de AES-CCM et comblant les manques. Ce n’est pas cette solution qu’utilise le standard pour remplacer l’AES-CCM mais la version revue et standardisée. L’AES-CCM* permet également de combler des failles de sécurité existantes sur la version classique et que Fouque, Martinet et al. ont identi-fiées dans l’article [75]. L’une des vulnérabilité vient de la possibilité d’utiliser des tags d’authentifications de tailles différentes (entre 32 et 128 bits) suivant la nécessité. Or, ce fonctionnement le rend vulnérable à des

(a) Principe de l’authentification CBC-MAC. (b) Principe du chiffrement CTR.

Figure 3.3 – Mécanismes de sécurité du standard IEEE 802.15.4.

Figure 3.4 – Champs Auxilliary Security Header (ASH).

attaques spécifiques. En effet, du fait de la taille variable des tags, un noeud récepteur doit être configuré pour accepter des tags de toute taille. Un attaquant va pouvoir utiliser cette propriété pour forger des fausses trames et réussir à les authentifier.

Pour les niveaux de sécurité 5 à 7, le Message Integrity Check (MIC) est généré puis chiffré en même temps que le reste du payload. Lors de l’émission de la trame on authentifie donc d’abord celle-ci en ajoutant le MIC puis on assure la confidentialité. Lors de la réception, il faut d’abord déchiffrer la trame avant de s’assurer de son intégrité. Les schémas de principe de l’authentification et du chiffrement sont donnés dans la Figure 3.3.

Afin de savoir avec quel niveau de sécurité la trame a été traitée et comment les IV (notés Biet Ai dans la Figure 3.3) ont été générés, le standard ajoute dans l’en-tête MAC le champ "Auxiliary Security Header" (ASH). Ce champ, décrit dans la Figure 3.4, est présent uniquement si le bit "Security Enabled (SE)" du FC est à 1.

Le champ "Security Control" de 1 octet permet d’indiquer comment et quel type de sécurité a été mis en place afin d’aider le récepteur à déchiffrer et/ou authentifier la trame.

Il comporte un premier champ "Security Level" permettant d’indiquer le niveau de sécurité établi parmi les 7 de la Table 3.3. Ainsi le récepteur sait s’il doit déchiffrer et/ou vérifier l’intégrité avant de traiter la trame reçue.

Le champ "Frame counter" permet de fournir une protection contre les attaques par rejeu. Enfin, le champ "Key ID" permet de spécifier les informations sur la clé utilisée.

Comme le montre la Figure 3.3, pour fonctionner, l’algorithme AES-CCM* a besoin de plusieurs éléments :

• Les données à chiffrer ou authentifier

• Les IV B_i et A_i

• La clé K

Les données à chiffrer et/ou authentifier vont dépendre du type de trame MAC émise.

Dans le standard IEEE 802.15.4, le parti prit est de ne pas transmettre l’IV dans la trame pour ne pas augmenter la taille de l’en-tête MAC et donc réduire le payload. Il faut alors que le récepteur de la trame puisse retrouver avec les données reçues comment celui-ci a été formé.

Les IV Ai utilisés pour le chiffrement suivent donc le format de la Figure 3.5.

Figure 3.5 – Format des IV pour le chiffrement.

L’élément le plus important de l’IV est le nonce. Il est lié à l’adresse étendue de l’émetteur de la trame, transmise en clair dans l’en-tête MAC. Nous verrons par la suite que l’utilisation de l’adresse MAC comme partie de l’IV complique le déploiement de solution de protection de l’identité des nœuds combinée au chif-frement.

Dans le standard la clé est définie explicitement ou implicitement et stockée. Une seule clé est utilisée. La gestion et le management des clés sont laissés à la charge des couches hautes. C’est pourquoi il est important de définir maintenant qu’elles sont ces couches hautes.

3.3.2.4 Les couches hautes du modèle OSI

Le standard IEEE 802.15.4 ne définit que les couches basses et laisse aux couches hautes la responsabilité de gérer nombres de protocoles important notamment ceux touchant à la sécurité.

Bien avant la publication de la version 2012 dédiée monde industriel, l’IEEE 802.15.4 avait déjà été choisi comme fondation de nombreux standards pour WSN déployés dans des environnements industriels. Le ZigBee ainsi que sa version ZigBeePro font partis de ces standards ayant optés pour l’IEEE 802.15.4 pour ses couches basses. Ils permettent de déployer des réseaux utiles pour des applications dans la domotique ou le smart

energy. D’autres encore comme le WirelessHART ou l’ISA100.11a offrent des possibilités pour les automates

industriels.

Malgré une efficacité prouvée dans le monde industriel, ces standards ne permettent pas d’établir simple-ment des communications IP entre capteurs. Or ce besoin grandit dû aux nouvelles applications de l’IoT. En effet, avec les communications IP, il est possible de fournir une adresse IP au nœud et d’utiliser celle-ci pour les requêtes. Ainsi, un utilisateur connaissant le déploiement de son réseau et les adresses peut, par exemple, consulter la température directement de son capteur déployé grâce à une requête lui étant adressée. C’est pourquoi le standard IPv6 Low power Wireless Personal Area Network (6LoWPAN) a été créé.

Dans cette thèse, les standards ZigBee mais également 6LoWPAN seront étudiés en terme de fuites d’identifiants. Il est donc nécessaire de connaitre le fonctionnement des deux ainsi que les protocoles utilisés.