# Tous les chemins mènent à DROP : une évaluation de la sécurité d'un mécanisme de routage du Bluetooth Mesh

Elies Tali, Romain Cayre, Vincent Nicomette, Guillaume Auriol

► To cite this version:

Elies Tali, Romain Cayre, Vincent Nicomette, Guillaume Auriol. Tous les chemins mènent à DROP : une évaluation de la sécurité d'un mécanisme de routage du Bluetooth Mesh. Symposium sur la Sécurité des Technologies de l'Information et des Communications (SSTIC 2025), Jun 2025, Rennes, France. hal-05332778

HAL Id: hal-05332778

https://laas.hal.science/hal-05332778v1

Submitted on 27 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Tous les chemins mènent à DROP : une évaluation de la sécurité d'un mécanisme de routage du Bluetooth Mesh

Elies Tali¹,², Romain Cayre¹,², Vincent Nicomette¹,² et Guillaume

Auriol¹,²

{prenom.nom}@laas.fr

¹ CNRS, LAAS, 7 avenue du colonel Roche, F-31400 Toulouse, France

² Univ de Toulouse, INSA, LAAS, F-31400 Toulouse, France

**Résumé.** Le Bluetooth Mesh est un protocole sans fil récent basé sur le Bluetooth Low Energy, offrant une communication de type *many-to-many*. Disposer d'une sécurité robuste et assurer la confidentialité des communications sont des enjeux de plus en plus centraux dans le contexte de l'Internet des Objets. Ces contraintes ont ainsi guidé la conception du Bluetooth Mesh, faisant de celui-ci un protocole particulièrement intéressant à étudier du point de vue de la recherche en sécurité.

En particulier, le Bluetooth Mesh dispose à l'heure actuelle de deux mécanismes de relais destinés à assurer la transmission des messages d'un équipement à l'autre. Le premier de ces mécanismes, appelé *Managed Flooding* et reposant sur une retransmission systématique des communications par les noeuds relais, garantit la transmission des messages mais implique un coût élevé en termes d'utilisation du réseau. La fonctionnalité de *Directed Forwarding*, récemment introduite dans la version 1.1 du protocole, constitue quant à elle une nouvelle méthode de relais, reposant sur des chemins dédiés au sein du réseau et permettant la communication entre des noeuds distants, sans surcharger le réseau de messages inutiles. Dans cet article, nous présentons la première évaluation de la sécurité de la fonctionnalité de *Directed Forwarding* du Bluetooth Mesh. Nous montrons qu'un attaquant présent au sein du réseau peut perturber de manière significative le bon fonctionnement de ce mécanisme de routage. Cette analyse nous a notamment permis d'identifier plusieurs vulnérabilités du protocole, exploitant les caractéristiques de ce mécanisme de routage. Enfin, nous démontrons théoriquement et expérimentalement l'existence de différentes attaques par déni de service (DoS), impactant significativement la disponibilité et les propriétés de sécurité assurées par un réseau Bluetooth Mesh.

## 1 Introduction

Le Bluetooth Low Energy (BLE) est aujourd'hui l'un des protocole les plus populaires dans le contexte de l'Internet des Objets, permettant à des objets à ressources limitées de communiquer. En raison de cette place
centrale, plusieurs vulnérabilités affectant ce protocole ont été identifiées ces dernières années [13], menant à des attaques variées, allant du déni de service (DoS), incluant les attaques par épuisement de batterie [18, 21], jusqu'aux attaques de type *Man-in-the-Middle* (MitM) permettant d'injecter des paquets malveillants dans une connexion [5].

Le Bluetooth Mesh (BM), quant à lui, peut être considéré comme une spécialisation du Bluetooth Low Energy afin d'y intégrer des mécanismes propres aux réseaux maillés. Initialement publié sous la forme d'une spécification en 2017 par le Bluetooth SIG, la dernière version (v1.1) est sortie fin 2023. La conception du BM est particulièrement intéressante du point de vue de la sécurité, le protocole incluant par défaut de nombreux mécanismes destinés à protéger la confidentialité et l'intégrité des communications, par exemple par l'intégration de mécanismes de chiffrement des paquets non désactivables, intégrés à différents niveaux de la pile protocolaire, ou par l'intégration de mécanisme *anti-tracking* destinés à protéger la vie privée des utilisateurs.

Malgré cette conception solide, le BM possède également son lot de vulnérabilités, ciblant par exemple les suites cryptographiques utilisées [7] ou encore certaines fonctionnalités propres au protocole [1]. En revanche, les travaux de recherches dédiés à la sécurité du BM demeurent en nombre limité, en raison de sa récente publication et de son déploiement limité. Le manque d'outils de tests propres au protocole constitue également un problème significatif, le BM ne pouvant être intégré à une implémentation BLE existante sans modifications majeures visant à ajouter et coordonner les nombreux mécanismes de la pile protocolaire.

La version 1.1 du BM enrichit le protocole en y intégrant un nouveau mécanisme de routage, nommé *Directed Forwarding*. Cette nouvelle fonctionnalité permet un routage plus efficace des paquets dans le réseau afin d'optimiser la charge sur ce dernier.

Cet article a pour but d'explorer le fonctionnement de ce nouveau mécanisme de routage et son impact du point de vue de la sécurité. Nous démontrons qu'il est possible pour un équipement malveillant présent au sein d'un réseau BM d'impacter significativement le bon fonctionnement du réseau. En particulier, nous présentons comment un attaquant peut mettre en place des attaques par déni de service en détournant certaines fonctionnalités intégrées au sein du *Directed Forwarding*. Ces attaques sont implémentées en pratique et illustrées par des expérimentations reposant sur le framework *WHAD*, un écosystème d'outils dédiés à l'évaluation de la sécurité des protocoles sans fil, que nous avons étendu avec une implémentation du BM, que nous publions sous licence libre (MIT).
Cet article est structuré de la manière suivante. Tout d'abord, la section 2 présente le protocole BM et notamment des aspects essentiels à la compréhension de cet article. Ensuite, la section 3 introduit le Directed Forwarding et les détails de son fonctionnement. La section 4 présente les travaux de recherche existants liés à la sécurité du protocole BM. Dans la section 5, nous décrivons le modèle d'attaquant considéré ainsi que le fonctionnement théorique des attaques visant le mécanisme de Directed Forwarding. La section 6 présente nos expérimentations menées à l'aide du framework WHAD et de l'extension BM que nous y avons intégré. Enfin, nous présentons dans la section 7 des propositions de contre-mesures aux attaques présentées. Pour terminer, nous proposons notre conclusion et les perspectives liés à ces travaux de recherche dans la section 8.

## 2 Présentation technique du Bluetooth Mesh

Le BM s'appuie sur la pile protocolaire du BLE et est construite "au-dessus" de celle-ci. Il exploite principalement les d'advertising du BLE pour ses communications. La couche GATT (Generic Attribute Profile) du BLE peut elle aussi être utilisée pour permettre aux objets ne supportant pas l'advertising de rejoindre le réseau via un proxy. Bien que permettant des communications de type many-to-many, le BM reste dépendant d'un objet central, le Configuration Manager en charge de la configuration du réseau. Chaque objet dans le réseau est désigné comme un nœud. Les concepts présentés dans cette section s'appuient sur la spécification version 1.1 du protocole.

### 2.1 Provisioning

Un objet cherchant à rejoindre un réseau BM prend part au Provisioning. Cette étape vise à fournir à l'objet les informations dont il a besoin pour communiquer sur le réseau. Ces informations comprennent des clés cryptographiques ainsi que les adresses du nœud. Le nœud en charge de gérer l'intégration du nœud au sein du réseau est le Provisioner.

Afin de rejoindre un réseau BM, un objet envoie régulièrement des paquets Unprovisioned Device Beacons aux nœuds à portée. Un protocole d'échange de clés utilisant le protocole Elliptic Curve Diffie-Hellman est alors initié par le Provisioner. Le canal chiffré ainsi créé est utilisé par le Provisioner pour transmettre au nouveau nœud du réseau différentes informations nécessaires au fonctionnement du BM.
## 2.2 Adressage des nœuds

Le BM utilise différents types d'adresses pour identifier des nœuds ou groupes de nœuds. Les champs *Source* et *Destination* au niveau de la couche Réseau utilisent ces adresses. Toutes les adresses ont une taille de 2 octets. Il faut distinguer les adresses unicasts et les adresses virtuelles/de groupe.

Chaque nœuds possède une ou plusieurs adresses unicasts. Chacune de ces adresses correspond à un *Element* du nœud. Un *Element* est une entité adressable d'un nœud. Chaque *Element* contient un ou plusieurs *Model* qui sont en charge de gérer les messages applicatifs. Un nœud a au minimum un *Element* primaire associé à au moins un *Model* requis pour son fonctionnement.

De plus, le BM utilise le concept de plages d'adresses, où chaque plage couvre de 1 à 255 adresses unicast consécutives, en général assignées à un seul et même nœud. Lors du *Provisioning* d'un nœud, le *Provisioner* lui assigne une plage d'adresses unicasts contenant une adresse par *Element* du nœud. Par exemple, si un nœud possède 10 *Elements* et son adresse primaire est 0x01, alors la plage d'adresses unicast assignée au nœud ira de 0x01 à 0x0A.

Les adresses virtuelles et de groupe sont des adresses multicast. Elles ne sont jamais utilisées en tant que source d'un message. Les nœuds peuvent s'abonner à ces adresses et être en écoute des messages qui leurs sont destinés. En particulier, les adresses 0xFFFF et 0xFFFFB sont des adresses de broadcast.

## 2.3 Mécanismes de sécurité

**Clés cryptographiques** Dans un réseau BM, tous les messages sont chiffrés et signées afin de garantir la confidentialité et l'intégrité des communications. Il existe trois principaux types de clés :

- **Network Keys (NetKey)** : Elles sont utilisées pour obfusquer et chiffrer des données sur la couche Réseau (via les PrivacyKey et EncKey dérivées d'une NetKey). Cela permet d'empêcher l'écoute d'un attaquant hors du réseau. Tous les nœuds d'un réseau partagent une même NetKey.

- **Application Keys (AppKey)** : Les AppKeys sont utilisées au niveau de la couche Transport afin de chiffrer les messages applicatifs. Elle permettent une séparation des privilèges au niveau applicatif.
**— Device Keys (DevKey) :** Les DevKeys sont propres à chaque
nœud et utilisées pour établir une communication sécurisée entre
un nœud et le *Configuration Manager*.

Le protocole BM distingue deux types de messages (hors Beacons), à savoir les messages de contrôle et les messages applicatifs. Les messages applicatifs sont à destination des Models. Ils sont chiffrés sur la couche Réseau à l'aide d'une NetKey et sur la couche de Transport au moyen d'une AppKey ou d'une DevKey. Un troisième type de messages particulier, les Beacons, ne sont pas chiffrés mais uniquement authentifiés via une NetKey (sauf pour les Beacons utilisés lors du Provisioning qui ne sont pas authentifiés).

Les messages de contrôle sont utilisés pour la gestion du réseau. Ils sont uniquement chiffrés au niveau de la couche Réseau (NetKey) et, par conséquent, sont lisibles et transmissibles par n'importe quel nœud.

La figure 1 illustre la manière dont un message de contrôle *Path Confirmation* est traité, chiffré et obfusqué au niveau de la couche Réseau. La description du rôle de ce message sera donnée dans cet article.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Dissection d'un message de contrôle (*Path Confirmation*)</figcaption></figure>

**Mesures anti-rejeu** Les mécanismes de protection contre les attaques par rejeu sont fondamentaux dans le protocole BM, tant du point de vue fonctionnel que de la sécurité. Chaque message émis par un nœud comporte un numéro de séquence qui lui est associé, et chaque message émis par la suite par le même nœud doit utiliser un numéro de séquence
plus grand que le précédent. Dans la figure 1, le numéro de séquence est représenté dans le champ *SEQ*.

Chaque nœud maintient une *Replay Protection List* (RPL) qui enregistre le dernier numéro de séquence reçu dans un message provenant de chaque adresse source. Lorsqu'un message en provenance d'une adresse source spécifique est reçu avec un numéro de séquence inférieur ou égal à celui stocké dans l'entrée correspondante de la RPL, le message est systématiquement rejeté, étant considéré comme un rejeu.

Afin de prévenir le bouclage des numéros de séquence, un *Initialization Vector index (IV index)* est partagé par tout le réseau. Chaque numéro de séquence est associé à une valeur spécifique de l'*IV index*. Lorsqu'un nœud approche de la valeur maximale du numéro de séquence, il peut initier une procédure de mise à jour de l'*IV index*, qui est alors incrémenté. Cela entraîne la réinitialisation des numéros de séquence pour tous les nœuds, les liant au nouvel *IV index*.

## 2.4 Suppression d'un nœud et rafraîchissement de clés

Dans cette partie, nous nous intéressons plus particulièrement à un mécanisme propre au BM qui sera le sujet d'une étude de cas d'utilisation de nos attaques.

**Objectif de la procédure de rafraîchissement d'une NetKey** L'administrateur d'un réseau BM peut décider à tout moment de rafraîchir la NetKey d'un réseau. Le cas de figure classique amenant au rafraîchissement d'une NetKey est la suppression d'un nœud du réseau. La suppression d'un nœud est toujours à l'initiative du *Configuration Manager*. Il notifie le nœud en question via un message chiffré avec sa DevKey (message *Config Node Reset*) puis initialise la procédure de rafraîchissement de la NetKey.

Cette procédure permet de changer la NetKey du réseau (ou du sous-réseau, une NetKey étant rattachée à un sous-réseau logique). Aussi, le ou les nœuds à supprimer ne prenant pas part à la procédure ne recevront pas la nouvelle NetKey. En conséquence, ils ne pourront ni envoyer ni recevoir de messages et seront effectivement écartés du réseau. Cette procédure permet d'éviter les attaques *trash-can* (ou attaques de la poubelle) qui permettraient à un attaquant de récupérer une NetKey valide du réseau en prenant possession d'un nœud décommissionné par exemple.

**Phases d'une NetKey** Une NetKey peut se trouver, du point de vue d'un nœud en particulier, dans 4 différentes phases (phases 0, 1, 2 et
3). Une NetKey peut avoir 1 ou 2 valeur différentes en simultané. Hors procédure de rafraîchissement de clé, elle possède une unique valeur. Lorsque la procédure est en cours, la NetKey utilise 2 valeurs, l'ancienne et la nouvelle. Cela permet d'avoir une procédure non bloquante le temps que la nouvelle clé se propage dans le réseau.

Chaque phase d'une NetKey va dicter le comportement du nœud quant à son utilisation.

- En **phase 0**, la NetKey ne possède qu'une seule valeur qui est utilisée pour le chiffrement et le déchiffrement (fonctionnement "normal", hors procédure de rafraîchissement).

- En **phase 1**, l'ancienne valeur de la NetKey est utilisée en envoi par le nœud, et il accepte en réception les messages chiffrés via l'ancienne et la nouvelle NetKey.

- En **phase 2**, la nouvelle valeur de la clé est utilisée en envoi par le nœud, et il accepte en réception les messages chiffrés via l'ancienne et la nouvelle NetKey.

- En **phase 3**, la nouvelle valeur de la clé remplace l'ancienne et le nœud repasse directement la clé en phase 0 (phase de transition).

## Fonctionnement de la procédure

Le rafraîchissement d'une NetKey se fait via plusieurs types de messages envoyés à l'initiative du *Configuration Manager* vers chaque nœud restant dans le réseau. La première étape est l'envoi à tous les nœuds concernés d'un message *Config NetKey Update* spécifiant l'index de la NetKey à changer ainsi que sa nouvelle valeur. Ce message est envoyé à chaque nœud, un par un, chiffré via leur DevKey respective. Après réception du message, chaque nœud répond au *Configuration Manager* par un *Config NetKey Status* chiffré avec sa DevKey.

A la réception du message *Config NetKey Update*, un nœud mettra la NetKey en question en phase 1.

Lorsque le *Configuration Manager* a terminé de distribuer la nouvelle NetKey, il va alors faire passer les nœuds dans les différentes phases de NetKey afin de terminer la procédure. Il peut faire cela de 3 manières :

- Via des messages *Config Key Refresh Phase Set* envoyé à chaque nœud un à un via leur DevKey (la NetKey utilisée n'est pas importante pour ce message tant que le message est accepté).

- Via des *Secure Network Beacon*. Ces messages sont de type *Beacon* et donc uniquement authentifiés via une NetKey, pouvant donc être envoyés par tous les nœuds. Chaque nœud envoie périodiquement
ce message avec la phase dans laquelle il se trouve pour la NetKey en question.

- Via des *Mesh Private Beacon*, sur le même principe que les *Secure Network Beacon*.

Plus particulièrement, lorsque les *Secure Network Beacon* ou les *Mesh Private Beacon* (appelés *Beacons*) sont utilisés, ce qui est préconisé par défaut, tous les nœuds participent au changement de phase de la NetKey rafraîchie en envoyant périodiquement les *Beacons*. Le tableau 1 détaille les champs d'un *Secure Network Beacon*. Les *Beacons* utilisent toujours la valeur la plus récente de la NetKey s'il y en a 2 (phase différente de 0).

<table><caption>**Tableau 1.** Champs d'un message *Secure Network Beacon*</caption><thead><tr><td>Nom du champ</td><td>Description</td></tr></thead><tbody><tr><td>KeyRefreshFlag</td><td>Flag de rafraîchissement de la NetKey correspondant au Network ID (0 ou 1)</td></tr><tr><td>IVUpdateFlag</td><td>Flag de mise à jour de l'IV index (0 ou 1)</td></tr><tr><td>NetworkID</td><td>ID de la NetKey en question (et utilisée pour authentifier le message)</td></tr><tr><td>IVIndex</td><td>IV index courant</td></tr><tr><td>AuthValue</td><td>CMAC du message calculé via la NetKey en question</td></tr></tbody></table>

Un nœud passe la NetKey de la phase 1 à la phase 2 s'il reçoit un *Beacon* avec le *KeyRefreshFlag* égal à 1. Ensuite, un nœud passe la NetKey en phase 3 (puis 0) depuis les phases 1 ou 2 s'il reçoit un *Beacon* avec le *KeyRefreshFlag* égal à 0. La phase 2 peut donc être sautée. La figure 2, tirée de la spécification du BM, illustre ces transitions de phase. La procédure se termine lorsque tous les nœuds restants dans le réseau sont passés en phase 0 avec la nouvelle valeur de la NetKey.

## 3 Présentation du *Directed Forwarding*

Dans cette section, nous introduisons le fonctionnement du mécanisme de *Directed Forwarding*, destiné à permettre le relais de messages au sein d'un réseau BM.
<figure><img src="image_3.png" /><figcaption>Fig. 2. Phases d'une procédure de rafraîchissement d'une NetKey. [3]</figcaption></figure>

## 3.1 Les relais de messages en BM

La spécification annonce un maximum de 32767 objets dans un réseau BM (en supposant que chaque nœud ne possède qu'un seul *Element*, concept spécifique au BM et assimilable à un service réseau pouvant être adressé indépendamment).

Le BM prend en charge deux types de relais : le *Managed Flooding* (MF) et, à partir de la version 1.1, le *Directed Forwarding* (DF). Ces deux mécanismes reposent tout deux sur la présence de nœuds dits relais. Tout nœud supportant cette fonctionnalité peut devenir un nœud relais si le *Configuration Manager*, c'est à dire le noeud chargé de la gestion du réseau, lui transmet une requête d'activation. Un administrateur réseau doit ainsi activer la fonction de relais sur un nombre suffisant de nœuds pour assurer le traitement de toutes les communications. La figure 3 présente un exemple de topologie réseau en grille, que nous utiliserons comme topologie de référence tout au long de cet article. Nous considérons
également la présence d'un nœud malveillant, que nous présenterons plus en détail en section 5.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Réseau exemple en grille. Chaque nœud possède un unique Element.</figcaption></figure>

La méthode de relais à utiliser lors de la transmission d'un message est indiquée par l'intermédiaire du champ *NID* intégré au sein de la couche Réseau, comme illustré dans la figure 1. Sa valeur varie selon que le *Managed Flooding* ou *Directed Forwarding* a été choisi pour relayer le paquet.

Le *Managed Flooding (MF)* est la méthode de retransmission par défaut en BM. Son fonctionnement est relativement simple : lorsqu'un nœud envoie un message à une adresse unicast, chaque nœud relais qui le reçoit le retransmet à nouveau si la valeur du *TTL* est supérieure à 1 et si la destination du paquet n'est pas le nœud relais lui-même.

La figure 4 présente un exemple de message envoyé par 0x1F vers 0x02 en utilisant le MF. Tous les nœuds relais retransmettent le message une fois, assurant sa bonne transmission jusqu'au nœud destination. En contre-partie de sa simplicité, cette méthode a pour conséquence d'inonder le réseau en le surchargeant de messages redondants et superflus du fait des nombreuses retransmissions par chaque nœud relais.

La seule manière de limiter l'impact sur le réseau lors de l'utilisation du MF est de définir un *TTL* approprié lors de l'envoi d'un message. En effet, le BM utilise une mécanisme de *Heartbeat* afin d'optimiser le choix de la valeur de *TTL* lors de l'envoi d'un message. Les nœuds conçus pour émettre des messages de contrôle *Heartbeat* les envoient ainsi à intervalles réguliers : les nœuds abonnés à ces messages les reçoivent et infèrent alors
la distance entre eux et le nœud émetteur. Cette information peut ensuite
utilisée pour définir le TTL des messages.

## 3.2 Aperçu du *Directed Forwarding*

Le DF est basé sur la notion de chemin, reliant un nœud à un autre
au sein du réseau (la destination d'un chemin peut également être liée à
plusieurs nœuds dans le cas d'une adresse de destination de type multicast,
chemins que nous n'étudierons pas dans cet article).

Par rapport au MF, le DF réduit le nombre de messages relayés inutile-
ment, car seuls les nœuds relais faisant partie d'un chemin correspondant à
la source et à la destination du message sont chargés de la retransmission.
La figure 4 illustre un exemple simple montrant la différence entre le MF
et le DF en terme de paquets relayés.

<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Comportement des relais utilisant le *Managed Flooding* et le *Directed Forwarding*</figcaption></figure>

Le DF est un mécanisme relativement complexe disposant de multiples
fonctionnalités, telles que la mise en place d'un routage vers des adresses
unicast ou multicast, des chemins bidirectionnels, des mécanismes de
tolérance aux pannes, et plus encore. Nous avons identifié de nombreuses
similarités avec le protocole de routage AODVv2 [19] malgré des différences
significatives, le DF introduisant notamment de nouveaux concepts et
l'utilisation de messages différents.

## 3.3 Chemins en *Directed Forwarding*

Lorsqu'un nœud relais reçoit un paquet destiné à une adresse unicast
qui ne lui appartient pas ou à une adresse multicast, il relaye le message
s'il fait partie d'un chemin correspondant au paquet. Les chemins peuvent
être fixes (créés de manière centrale par le *Configuration Manager*) ou non fixes (initialisés automatiquement par les nœuds selon les besoins).

Les chemins sont stockés dans des *Forwarding Table* (une table de routage). Chaque nœud possède sa table, et chaque chemin auquel il appartient correspond à une entrée dans celle-ci.

Le tableau 2 répertorie quelques champs présents dans une entrée de *Forwarding Table* pour un chemin non fixe vers une plage d'adresses cibles unicast. L'origine ou la source d'un chemin est appelée *Path Origin* (PO) et la destination un *Path Target* (PT). Lorsqu'un chemin est bidirectionnel (2-way), il est valide du PT vers le PO également. Chaque nœud faisant partie d'un chemin conserve une entrée correspondante dans sa *Forwarding Table*.

<table><caption>**Tableau 2.** Quelques champs d'une entrée dans une *Forwarding Table* (chemin non-fixe, vers une plage d'adresses unicast)</caption><thead><tr><td>Nom du champ</td><td>Description</td></tr></thead><tbody><tr><td>BackwardPathValidatedFlag</td><td>Chemin bidirectionnel ou unidirectionnel</td></tr><tr><td>LaneCounter</td><td>Nombre de voies créées pour ce chemin</td></tr><tr><td>PathRemainingTime</td><td>Durée de vie restante du chemin</td></tr><tr><td>ForwardingNumber</td><td>Forwarding Number du chemin</td></tr><tr><td>PathOriginAddrRange</td><td>Plage d'adresses du PO</td></tr><tr><td>PathTargetAddrRange</td><td>Plage d'adresses du PT</td></tr><tr><td>DependentOriginList</td><td>Plages d'adresses des nœuds dépendants du PO</td></tr><tr><td>DependentTargetList</td><td>Plages d'adresses des nœuds dépendants du PT</td></tr></tbody></table>

Un chemin correspond à un paquet si la destination et la source correspondent aux informations du chemin. Les nœuds ne conservent pas l'adresse du nœud suivant sur le chemin. Leur seule connaissance est que le nœud suivant est supposé à portée radio.

## 3.4 Dépendance de nœuds

Une particularité du DF est le concept de nœuds dépendants. La dépendance indique la délégation de certaines tâches d'un nœud à un autre. Par exemple, le mécanisme de *Friendship* du BM utilise ce concept. Une *Friendship* est établie entre un LPN (*Low Power Node*) et un autre nœud (nœud ami). Elle permet aux objets aux ressources limitées d'optimiser leur consommation d'énergie. Le LPN délègue la réception des messages
à son nœud ami : à intervalle régulier, le LPN interroge son ami pour récupérer les messages qui lui ont été adressés. Le nœud ami gère aussi les chemins pour le LPN dans le cas où le DF est utilisé.

Un LPN est un nœud dépendant de son ami. Dans le contexte du DF, une entrée dans la *Forwarding Table* associée à un chemin stocke les adresses des nœuds dépendants du PO ou du PT.

Ainsi, un message relayé via DF correspond à un chemin si et seulement si :

- la source du message correspond au PO ou est un nœud dépendant du PO

- la destination du message correspond au PT ou est un nœud dépendant du PT

Par ailleurs, un chemin correspond à un message s'il s'agit d'un chemin bidirectionnel avec la source et la destination inversées.

## 3.5 Création des chemins non fixes

L'initialisation d'un chemin non fixe par un nœud est déclenchée lorsqu'il souhaite envoyer un message à une destination pour laquelle il ne dispose d'aucun chemin valide. Les messages permettant d'établir un chemin non fixe sont des messages de contrôle, ils sont donc uniquement chiffrés au niveau de la couche Réseau et lisibles par tous les nœuds.

Un exemple de création de chemin simple à sens unique non fixe est illustré dans la figure 5, allant du nœud avec l'adresse `0x1A` au nœud avec l'adresse `0x0E`, basé sur l'exemple de réseau représenté dans la figure 3.

<figure><img src="image_6.png" /><figcaption>**Fig. 5.** Exemple de création de chemin simple à sens unique non fixe avec une seule voie (de `0x1A` vers `0x0E`) en se basant sur la topologie exemple.</figcaption></figure>
Pour initialiser un chemin non fixe, le PO envoie un paquet *Path Request* à l'adresse du groupe *all-directed-forwarding-nodes*. Le tableau 3 détaille les champs de ce paquet.

<table><caption>**Tableau 3.** Champs d'un message *Path Request*</caption><thead><tr><td>Nom du champ</td><td>Description</td></tr></thead><tbody><tr><td>PathOriginLifetime</td><td>Durée de vie du chemin</td></tr><tr><td>PathDiscoveryInterval</td><td>Durée maximum pour la création du chemin</td></tr><tr><td>PathForwardingNumber</td><td>Forwarding Number du chemin</td></tr><tr><td>PathMetric</td><td>Valeur de la métrique (nombre de sauts)</td></tr><tr><td>Destination</td><td>Adresse du PT</td></tr><tr><td>PathOriginAddressRange</td><td>Plage d'adresses du PO</td></tr><tr><td>DependentOriginAddrRange</td><td>Plage d'adresses d'un nœud dépendant du PO (optionnel)</td></tr></tbody></table>

Notamment, un champ *ForwardingNumber* (FWN) est utilisé pour distinguer les différents cas de messages *Path Request* reçus et pour suivre la création d'un chemin non fixe en particulier. Chaque nœud conserve son propre FWN qu'il utilise et incrémente lorsqu'il initialise un nouveau chemin en tant que PO. Le FWN associé à un chemin est stocké dans l'entrée correspondante de la *Forwarding Table* de chaque nœud impliqué. Si un *Path Request* est envoyé en utilisant un FWN inférieur pour un chemin similaire, il est rejeté.

Lorsque le PO initie la création d'un chemin, ou lorsqu'un nœud reçoit un *Path Request* pour un nouveau chemin, il ajoute à sa *Discovery Table* une entrée correspondant au chemin en cours de création. Une entrée dans la *Discovery Table* stocke des données similaires à celles de l'entrée de la *Forwarding Table*, avec quelques informations supplémentaires pour les chemins en cours de création.

En particulier, la *Discovery Table* stocke la meilleure métrique reçue pour un chemin (en BM v1.1, il s'agit du nombre de sauts entre le PO et le nœud). Les nœuds stockent également dans cette table l'adresse du nœud (prochain saut) qui a envoyé le *Path Request* avec la meilleure métrique pour la propagation inverse.

Lors de la réception d'un *Path Request*, un nœud prend des actions en fonction de son contenu et du contexte :
- Si le nœud ou l'un de ses nœuds dépendants est le PT (l'une de ses adresses unicast ou une adresse multicast à laquelle il est abonné), le nœud lance un *Path Discovery Timer* et un *Path Reply Timer*.

- Si le nœud n'est pas le PT, et que le nœud est un nœud relais, il envoie le même *Path Request* avec la métrique incrémentée de 1 après un court délai et lance un *Path Discovery Timer*.

Lorsque le *Path Reply Timer* du PT expire (500 ms pour une destination unicast), il envoie un *Path Reply* au nœud qui a envoyé le *Path Request* avec la meilleure métrique. Le tableau 4 présente une dissection non exhaustive d'un message *Path Reply*.

<table><caption>**Tableau 4.** Champs d'un message *Path Reply*</caption><thead><tr><td>Nom du champ</td><td>Description</td></tr></thead><tbody><tr><td>ConfirmationRequest</td><td>Le PT demande-t-il la création d'un chemin bidirectionnel?</td></tr><tr><td>PathOrigin</td><td>Adresse de Element primaire du PO</td></tr><tr><td>PathForwardingNumber</td><td>Forwarding Number du chemin (le même que celui dans le Path Request)</td></tr><tr><td>PathTargetAddressRange</td><td>Plage d'adresses du PT</td></tr><tr><td>DependentTargetAddrRange</td><td>Plage d'adresses d'un nœud dépendant du PT (optionnel)</td></tr></tbody></table>

Lorsqu'un message *Path Reply* est envoyé, un seul nœud le reçoit (l'adresse destination du paquet sur la couche Réseau est celle stockée dans la *Discovery Table* et correspond au prochain saut du chemin). Lorsqu'un nœud reçoit un *Path Reply*, il ajoute à sa *Forwarding Table* le chemin créé (basé sur les informations contenues dans le *Path Reply* et dans l'entrée de la *Discovery Table*). Si le récepteur n'est pas le PO, il envoie alors son propre *Path Reply* au prochain nœud sur le chemin à destination du prochain nœud relais.

Lorsque le *Path Reply* est reçu par le PO, le chemin est créé. Si le champ *ConfirmationRequest* dans le message *Path Reply* est égal à 1, une procédure de confirmation est lancée pour établir un chemin bidirectionnel. Elle repose simplement sur l'envoi par le PO d'un paquet *Path Confirmation* au PT utilisant le chemin nouvellement créé.

Chaque chemin a une durée de vie définie, allant de 12 minutes à 10 jours. Avant l'expiration du chemin, le PO surveille son utilisation pendant une période de temps (par défaut 120 secondes). Si le chemin n'est pas
utilisé pendant cette période, il n’est pas réinitialisé automatiquement, résultant en sa suppression de toutes les *Forwarding Table*.

Un message de contrôle *Dependent Node Update* peut également être envoyé pour ajouter ou supprimer des plages d'adresses en tant que nœuds dépendants du PO ou du PT de chemins. Les paramètres de ce message sont présentés dans le tableau 5. Le champ *PathEndpoint* doit être le PO ou le PT du chemin. Dans le cas de l'ajout de nœuds dépendants, le chemin doit obligatoirement être un chemin bidirectionnel si le *PathEndpoint* est le PT.

<table><caption>**Tableau 5.** Champs d'un message *Dependent Node Update*</caption><thead><tr><td>Nom du Champ</td><td>Description</td></tr></thead><tbody><tr><td>Type</td><td>Type de mise à jour (ajout ou suppression)</td></tr><tr><td>PathEndpoint</td><td>Adresse du PO/PT dont on met à jour les nœuds dépendants</td></tr><tr><td>DependentNodeAddrRange</td><td>Plage d'adresses du nœud dépendant</td></tr></tbody></table>

Enfin, le message *Path Request Solicitation* est un message de contrôle utilisé pour demander à un nœud de mettre à jour ses chemins vers des adresses spécifiques. Lorsqu'un nœud reçoit ce message, il réinitialise les chemins de lui-même vers toutes les adresses listées dans le paquet. Le message est traité uniquement si le nœud dispose déjà un chemin depuis lui-même vers l'une des adresses mentionnées dans le paquet. Par exemple, ce message est utilisé lorsqu'un nœud se déplace physiquement dans le réseau afin de mettre à jour les chemins menant à lui.

Le seul champ d'un *Path Request Solicitation* est une liste d'adresses pour lesquels les nœuds récepteurs doivent mettre à jour les chemins qui les ont comme destination (si le message est traité avec succès).

## 3.6 Fiabilité et sécurité du *Directed Forwarding*

**Voies** Le *Configuration Manager* peut configurer les nœuds afin qu'ils créent plusieurs voies (*lanes*) pour un même chemin. Si le réseau est configuré pour avoir 2 voies par chemin, le PO d'un chemin, après un délai (*Path Discovery Timer* et *Lane Discovery Timer*) spécifié par le *Configuration Manager*, renvoie un *Path Request* avec exactement les mêmes paramètres (y compris le même champ *ForwardingNumber*). Par défaut, les nœuds initialiseront 2 voies par chemin.
Les nœuds qui font déjà partie de la première voie du chemin participent à la création du chemin, mais leur métrique est incrémentée de 1 pour chaque voie dont ils font déjà partie pour ce chemin. Cela garantit que les nœuds qui n'étaient pas précédemment sur le chemin soient désormais considérés comme meilleurs et potentiellement choisis pour la deuxième voie. La figure 6 illustre les 2 voies résultantes pour un chemin allant de 0x1F à 0x02.

<figure><img src="image_7.png" /><figcaption>Fig. 6. Exemple d'un chemin à 2 voies vers une adresse unicast</figcaption></figure>

Les chemins à plusieurs voies contribuent à la résilience du DF. Si, pour une raison quelconque, une voie cesse de fonctionner, une autre pourra prendre le relais et assurer que les messages continueront d'arriver à destination. Cependant, plus le nombre de voies nécessaires pour chaque chemin est élevé, plus les messages inonderont le réseau à chaque envoi.

**Validation de chemin** Pour valider en continu qu'un chemin est toujours valide, un PO initie régulièrement une procédure de validation de chemin. En effet, un chemin peut devenir invalide au cours de sa durée de vie si l'un des nœuds relais a été supprimé, déplacé, ou pour toute autre raison susceptible d'interrompre le comportement normal des nœuds relais. La validation du chemin est initiée par le PO en envoyant un paquet *Path Echo Request* au PT via DF. Étant donné que le message est relayé en DF, le *Path Echo Request* n'arrive à destination que si le chemin fonctionne correctement. Le PO attend un paquet *Path Echo Reply* en réponse du PT. Si le chemin est bidirectionnel, le *Path Echo Reply* est envoyé en DF pour vérifier le chemin inverse, ou envoyé via MF dans le cas contraire (car il n'y a pas de chemin inverse). Si aucune réponse n'est reçue par le PO après un délai, le chemin n'est plus considéré comme valide et est supprimé de
la *Forwading Table* du PO. Cette procédure est régulièrement déclenchée par le PO d'un chemin (le délai étant configuré par le *Configuration Manager*).

# 4 Travaux Existants

Les recherches existantes sur la sécurité du BM demeurent peu nombreuses à l'heure actuelle. Malgré cette situation, une systématisation des connaissances publiée par Wu et al. présente un modèle formel destiné à l'évaluation de la sécurité du BM [20].

Comparé au BLE, la sécurité du BM a été considérée comme une priorité lors de la conception du protocole, comme indiqué dans la spécification [3]. Néanmoins, plusieurs études récentes ont mis en évidence la présence de failles de sécurité affectant le protocole [1, 6, 7, 12].

De plus, un réseau BM reste fondamentalement un réseau sans fil maillé, et partage donc de nombreuses similitudes avec des protocoles tels que le ZigBee. Il est donc judicieux d'examiner les attaques visant ces protocoles, celles-ci étant susceptibles de pouvoir être adaptées au BM.

## 4.1 Attaques sur le Provisioning

Le *Provisioning* constitue un mécanisme critique au sein d'un réseau BM. Permettre à un objet non autorisé de rejoindre le réseau lui permet de recevoir la NetKey, lui permettant d'envoyer et de recevoir des messages de contrôle et compromettant ainsi la confidentialité et la protection de la vie privée assurées par le réseau.

Par défaut, le *Provisioning* n'impose aucun mécanisme de sécurité. L'échange de clés est réalisé par l'intermédiaire d'un canal non chiffré. Seules les données telles que l*'IV index*, la NetKey et les adresses unicast du nœud sont envoyées après l'échange de clés via un canal chiffré.

De plus, l'authentification des nœuds rejoignant le réseau est optionnelle, bien que l'administrateur du réseau dispose de la possibilité d'imposer son utilisation. Si cette fonctionnalité n'est pas activée, tout nœud situé dans la portée du réseau peut potentiellement le rejoindre. Le BM dispose d'un système d'authentification hors bande (dit "Out Of Band") si celui-ci est supporté par le *Provisioner*.

A l'heure actuelle, un certain nombre d'attaques ciblant le *Provisioning* ont été publiées, y compris en cas d'utilisation de l'authentification hors bande. Les attaques *BlueMirror* présentent diverses méthodes permettant à un attaquant de rejoindre le réseau en détournant une procédure de *Provisioning* légitime en cours [7].
Ces vulnérabilités ont été corrigées dans la version 1.1 du BM. Cependant, la même équipe de chercheurs a évalué les correctifs mis en place et ont ainsi pu établir qu’ils ne corrigent pas complètement ces vulnérabilités. Ainsi, des attaques MiTM demeurent potentiellement exploitables [6]. Ces travaux soulignent ainsi qu’un attaquant obtenant un accès au réseau, même sans autorisation, représente une menace à prendre en compte.

## 4.2 Attaques visant le mécanisme de *Friendship*

Un ensemble d'attaques exploitant le mécanisme de *Friendship* ont également été publiées. Lorsqu'un *Low Power Node* (LPN) délègue sa présence sur le réseau à un autre nœud (un nœud ami), ils établissent une relation de *Friendship* par le biais de messages de contrôle. Ainsi, dans [1], Álvarez et al. ont démontré la possibilité de détourner le mécanisme de *Friendship* pour empêcher son bon fonctionnement. Ces attaques exploitent notamment le fait que les messages de contrôle ne sont pas chiffrés au niveau applicatif et peuvent donc être manipulés par n'importe quel nœud du réseau.

## 4.3 Attaques sur les protocoles de topologie maillée

En raison de ses similarités avec le BM et de sa maturité, le ZigBee est un protocole maillé sans fil intéressant à étudier, affecté par certaines attaques potentiellement adaptables au BM. Par exemple, des attaques de type *sinkhole* et *blackhole* affectant ses protocoles de routage constituent des études de cas intéressantes pour l'analyse de la sécurité du BM [22].

De plus, la propagation d'informations erronées dans un réseau maillé est un vecteur d'attaque courant. Ainsi, le détournement du mécanisme de *Heartbeat* pour indiquer de manière erronnée une faible distance entre les nœuds a été mentionnée dans la littérature associée [14]. Cependant, nous n'avons trouvé en pratique aucune implémentation du BM qui utilise les informations des messages *Heartbeat* pour définir la valeur de *TTL* des messages lors de l'utilisation du MF.

Enfin, des attaques ciblant les protocoles de routage AODV/AODVv2 ont également été documentées. En particulier, des attaques de type *blackhole* et *sinkhole* sont décrites, ainsi que de nombreuses contre-mesures destinées à prévenir ces dernières [10, 15, 16]. Cependant, le DF utilise des mécanismes de gestion des chemins qui lui sont spécifiques, notamment l'utilisation de l'adresse source comme critère pour faire correspondre un chemin, le concept de dépendance ainsi que l'utilisation de messages de contrôle additionnels. De plus, aucune implémentation pratique de
telles attaques sur AODVv2 n'est disponible. A notre connaissance, aucun travaux n'ont exploré la sécurité du DF.

# 5 Attaques

Un enjeu central au sein d'un réseau maillé est de garantir la stabilité des communications. Dans cette section, nous introduisons notre modèle de menace et présentons le fonctionnement théorique des attaques que nous avons pu identifier, ciblant la fiabilité des communications dans un réseau BM.

## 5.1 Modèle de menace

**Contexte général** Notre travail de recherche repose sur un ensemble d'hypothèses concernant le réseau BM attaqué. Nous considérons un réseau reposant sur la version 1.1 du BM, où le mécanisme de DF a été activé sur l'ensemble des nœuds du réseau où se trouve l'attaquant. De plus, le réseau doit comporter au moins 2 nœuds qui ne sont pas à portée directe l'un de l'autre. Tout au long de cette section, le réseau exemple présenté en figure 3 sera utilisé.

**Objectifs de l'attaquant** L'attaquant a pour but de lancer des attaques par déni de service (DoS) afin d'empêcher le bon fonctionnement du réseau. Ses objectifs sont les suivants :

- **Effectuer une reconnaissance** afin d'obtenir des informations sur la topologie du réseau et les nœuds actifs.

- **Perturber le comportement correct du réseau.** Plus précisément, l'attaquant veut perturber les communications entre nœuds qui ne sont pas à portée radio et ne peuvent donc pas communiquer directement.

**Attributs de l'attaquant** Nous considérons un attaquant contrôlant au moins un nœud au sein du réseau, ayant rejoint le réseau de manière légitime ou illégitime, comme expliqué en section 4.1. L'attaquant peut également avoir récupéré des données valides issues d'un *Provisioning* à partir d'un dispositif non protégé ou via l'exploitation d'une vulnérabilité spécifique à l'objet (vulnérabilité matérielle, vulnérabilité liée au firmware...) [2]. Aucune AppKey spécifique n'est nécessaire dans notre modèle.
Les attaquants peuvent être soit statiques, soit mobiles. Un attaquant statique ne peut pas se déplacer physiquement et, par conséquent, se trouve à portée d'un ensemble fixe de nœuds au sein du réseau. Dans la figure 3, l'attaquant est statique et est situé au centre du réseau à l'adresse `0x11`. En revanche, un attaquant mobile a la capacité de se déplacer au sein du réseau, c'est-à-dire d'être à portée radio directe de différents nœuds au fil du temps. De plus, nous supposons que l'attaquant dispose d'une puissance d'émission (Tx) et d'une sensibilité de réception (Rx) standards.

## 5.2 Vulnérabilités

Notre article présente 2 vulnérabilités principales, liées au fonctionnement du DF. Celles-ci sont respectivement appelées $V_1$ et $V_2$.

**$V_1$ - Utilisation incorrecte de la fonctionnalité des nœuds dépendants**

Tout chemin non fixe peut répertorier les adresses des nœuds dépendants du PO ou du PT. Ces adresses sont donc considérées comme des sources/destinations valides pour le chemin.

De ce fait, tout nœud disposant d'un chemin valide partant de lui vers un nœud qui a des nœuds dépendants n'initialisera pas de nouveaux chemins vers les adresses des nœuds dépendants. En conséquence, cela peut empêcher la bonne transmission des messages à leur destination si le chemin correspondant est incorrect (si le chemin n'atteint pas la destination spécifiée).

Par exemple, en considérant la situation présentée en figure 3, supposons que le nœud `0x03` possède une seule entrée dans sa *Forwarding Table*. Il y stocke un chemin à une seule voie allant de `0x03` à `0x0B`. Le seul nœud relais intermédiaire est `0x04`.

Si cette entrée répertorie le nœud `0x0D` comme un nœud dépendant du PT du chemin, c'est-à-dire de `0x0B`, alors lorsque `0x03` souhaite envoyer un message à `0x0D`, le chemin vers `0x0D` correspondra et il enverra le message sans créer de chemin. Dans ce cas, le message n'atteindra jamais le nœud `0x0D`, car les nœuds le long du chemin de `0x03` à `0x0B` ne sont pas à portée de `0x0D`.

De plus, nous pouvons considérer que les chemins de plusieurs nœuds vers `0x0B` répertorient des nœuds dépendants incorrects et les utilisent par erreur. Non seulement les messages ne parviendront pas à leur destination, mais le nœud `0x0B` sera inondé de messages qui ne lui sont pas destinés via DF.
Toutefois, un chemin contenant une adresse donnée comme nœud dépendant de manière erronée ne garantit pas pour autant que le message n'atteindra pas sa destination.

Tout d'abord, si la destination du paquet est à portée de l'un des nœuds relais le long du chemin, celle-ci recevra le message. Ensuite, si un chemin légitime vers la destination existait avant la création ou la modification du chemin empoisonné avec de faux nœuds dépendants, le chemin légitime continuera de fonctionner. Cependant, ce chemin légitime peut disparaître après expiration de sa durée de vie s'il n'est pas utilisé durant la période de surveillance du chemin, menant à la vulnérabilité $V_1$.

## $V_2$ - Spoofing de messages de contrôles en lien avec le DF Étant donné que l'attaquant possède la NetKey du réseau, il est en mesure de forger et de transmettre des messages de contrôle arbitraires. De plus, il n'existe aucun mécanisme d'authentification permettant d'assurer que la source d'un message est correcte.

Ainsi, un attaquant peut envoyer des messages de contrôles liés au DF à tous les nœuds à portée radio. Les paramètres au niveau de la couche Réseau, tels que les champs *Source* ou *Destination*, ainsi que la charge utile des messages de contrôle, sont contrôlables par l'attaquant. Par exemple, les messages *Path Request* et *Path Reply*, essentiels à la création des chemins, peuvent être envoyés au nom d'un autre nœud avec des informations trompeuses.

De plus, le champ *Source* sur la couche Réseau d'un message de contrôle lié au DF n'est pas contraint dans la majorité des cas. L'attaquant peut ainsi usurper l'identité d'autres nœuds dans la charge utile des messages (au niveau de la couche Transport) tout en utilisant sa véritable adresse comme *Source* du paquet au niveau Réseau. Cela élimine la nécessité de deviner les numéros de séquence corrects.

Pour illustrer le fonctionnement de $V_2$, un attaquant peut envoyer un *Path Request* à la place d'un autre nœud avec les informations qui lui conviennent.

## 5.3 Actions élémentaires

Sur la base de notre modèle de menace et afin d'exploiter les vulnérabilités décrites, nous présentons un ensemble d'actions élémentaires. Lorsqu'elles sont combinées, ces actions constituent les étapes d'attaques complètes décrites ci-après. Les actions élémentaires sont étiquetées $E_1$ à $E_7$.
**E₁ - Création de chemin** Un attaquant peut créer un chemin depuis lui-même vers n'importe quel nœud du réseau. Il s'agit du comportement normal du BM. Cependant, il peut définir les paramètres du message *Path Request* comme il le souhaite, sans suivre les prérogatives du *Configuration Manager*.

De plus, l'attaquant peut initier la création d'un chemin depuis n'importe quelle adresse vers n'importe quel autre nœud (qui n'a pas la même adresse). Plus précisément, l'attaquant peut utiliser une adresse non utilisée (non attribuée à un quelconque nœud existant) comme PO.

**E₂ - Forcer l'envoi du Path Reply vers l'attaquant** Sous certaines conditions, lors de la création d'un chemin non fixe légitime n'impliquant pas l'attaquant, il peut faire en sorte d'être la destination d'un des messages *Path Reply*. Cela permet à l'attaquant de manipuler arbitrairement celui-ci (le supprimer, le transférer avec de fausses informations, etc.).

Pour y parvenir, les conditions suivantes doivent être vérifiées :

- **L'attaquant reçoit un des messages Path Request** lié à la création du chemin. À moins que le PO et le PT du chemin ne soient très proches, la probabilité qu'une telle situation se produise est élevée car le message est transféré par tous les nœuds relais qui ne sont pas le PT.

- **Le Path Request malveillant initié par l'attaquant arrive au PT à temps (avant la fin du Path Reply Timer, 500ms) avec la meilleure métrique.** Cela implique forcément que la distance Attaquant↔PT soit inférieure à PO↔PT, mais d'autres paramètres de distances rentrent en compte. La distance, dans la version 1.1 de BM, correspond systématiquement au nombre de sauts séparant deux nœuds.

Lorsque l'attaquant reçoit un message *Path Request* pour un PO quelconque vers un PT (qui n'est pas l'attaquant), il le transfère comme prévu. Cependant, la valeur de *PathMetric* du paquet est mise à 0. Ainsi, tous les nœuds recevant ce message considèrent que l'attaquant est le meilleur prochain saut pour le chemin (s'ils ne sont pas à portée directe du PO).

En conséquence, lors de la séquence d'envoi des *Path Reply* du PT vers le PO, l'attaquant sera considéré comme l'un des sauts, même s'il n'est pas nécessairement la meilleure option à choisir en réalité. À elle seule, E2 peut empêcher la création de chemins en supprimant le paquet *Path Reply*, mais elle peut également être utilisée pour créer des *sinkholes* lorsqu'elle
est combinée avec d'autres actions élémentaires (nous développons cette attaque dans la section 5.4).

**E3 - Empoisonnement de l'entrée de chemin via Path Reply malveillant**

Lors de la création d'un chemin non fixe légitime où il n'est ni PO ni PT, l'attaquant peut usurper l'identité du PT et envoyer un message *Path Reply* falsifié. Ainsi, il peut empoisonner l'entrée de la *Forwarding Table* du PO avec de fausses informations. L'attaquant doit avoir préalablement reçu l'un des *Path Request*, ce qui est fortement probable si le PO et le PT ne sont pas des voisins directs.

L'attaquant peut exploiter $V_1$ afin d'ajouter une fausse plage d'adresses de nœuds dépendants au PT, ainsi qu'une plage d'adresses de PT erronée au chemin en cours de création. D'autres paramètres du *Path Reply* peuvent également être modifiés par l'attaquant. La figure 7 est un exemple d'utilisation de $E_3$ exploitant $V_1$ lors de la création d'un chemin de 0x0A à 0x09.

<figure><img src="image_8.png" /><figcaption>Fig. 7. Action E3 exploitée pour empoisonner la *Forwarding Table* de 0x0A</figcaption></figure>

Le succès de l'exploitation de $E_3$ dépend de la distance PO↔PT par rapport à la distance PO↔Attaquant. Si la distance PO↔Attaquant est trop grande par rapport à PO↔PT, le *Path Reply* légitime sera reçu avant le *Path Reply* malveillant. Le message *Path Request* envoyé suite
à la réception d'un *Path Request* est transmis après un délai de 150 ms par les nœuds relais. D'autre part, le PT envoie son *Path Reply* 500 ms (*Path Reply Timer*) après la réception du premier *Path Request*. Ainsi, en théorie, la distance PO↔Attaquant peut dépasser la distance PO↔PT de 3 sauts maximum.

**E4- Empêcher la création de plusieurs voies** Un attaquant peut empêcher la création de plusieurs voies pour un chemin non fixe s'il reçoit l'un des *Path Request* pour la première voie. Cela n'entraînera pas la réinitialisation du chemin par le PO. En effet, si un chemin créé possède au moins une voie (même si d'autres sont nécessaires), l'initialisation du chemin est toujours considérée comme étant un succès.

$E_4$ exploite le champ *ForwardingNumber* (FWN) utilisé lors de la création du chemin. Lors de l'envoi d'un *Path Request* pour une voie additionnelle, le PO utilise la même valeur de FWN que pour la première voie. Par conséquent, un attaquant peut renvoyer exactement le même *Path Request* utilisé pour la première voie avec un FWN incrémenté de un. Après cela, le PT ignorera les futurs messages *Path Request* légitimes du PO pour des voies supplémentaires, puisque le FWN stocké par le PT sera désynchronisé.

La figure 8 présente un exemple où l'attaquant empêche la création d'une deuxième voie pour le chemin entre 0x0A et 0x0B.

**E5 - Contourner la validation de chemin et maintenir les chemins unidirectionnels actifs** Un attaquant, dont le nœud malveillant est situé n'importe où dans le réseau, peut faire croire au PO d'un chemin uni-directionnel que ce chemin fonctionne toujours correctement et est valide, même si ce n'est pas le cas. Dans le cas d'un chemin ne fonctionnant plus, cela entraînerait l'échec de la transmission des paquets à leur destination s'ils se basent sur le chemin non valide. La validation de chemin est le seul moyen pour un PO de s'assurer qu'un chemin est toujours actif. $E_5$ s'appuie sur le fait que :

- Le délai minimum entre l'envoi d'un *Path Echo Request* et la réception du *Path Echo Reply* est de 5 secondes.

- Les messages *Path Echo Reply* sont envoyés en utilisant le MF pour les chemins unidirectionnels. En conséquence, ils peuvent être envoyés depuis n'importe quelle partie du réseau.

Un attaquant doit donc envoyer à intervalle régulier (toutes les 5 secondes au minimum) un message *Path Echo Reply* correspondant au
<figure><img src="image_9.png" /><figcaption>**Fig. 8.** Utilisation de $E_4$ pour empêcher la création de plus d'une voie sur le chemin de $0x0A$ à $0x0B$</figcaption></figure>

chemin de la victime. Étant donné qu'il est envoyé via MF, l'attaquant n'a pas besoin d'être le long du chemin.

La partie non triviale afin d'exploiter $E_5$ consiste à trouver un numéro de séquence correct pour envoyer le *Path Echo Reply*. En effet, l'adresse *Source* du paquet au niveau de la couche Réseau doit être celle du PT. Le numéro de séquence utilisé doit donc être supérieur à celui du PT. L'attaquant peut soit le deviner en écoutant passivement les paquets, soit choisir une valeur élevée. Cependant, plus la valeur initiale est élevée, plus l'attaquant risque d'épuiser rapidement les numéros de séquence à utiliser. Il devra donc initier une procédure de mise à jour de l'*IV index*.

**E<sub>6</sub> - Mise à jour des nœuds dépendants dans les chemins**
Un attaquant peut mettre à jour la *Forwarding Table* des nœuds pour ajouter ou supprimer des nœuds dépendants dans leurs entrées de chemins. $E_6$ utilise le message de contrôle *Dependent Node Update* tel que décrit dans le tableau 5. En particulier, l'attaquant peut utiliser $E_6$ de manière malveillante pour ajouter des nœuds dépendants à n'importe quel PO ou PT (tant que les conditions sont remplies) et ainsi exploiter $V_1$.

**E<sub>7</sub> - Initialisation forcée de chemins des nœuds autour de l'attaquant**
En utilisant le message *Path Request Solicitation*, un attaquant
peut forcer les nœuds environnants (dans sa portée radio) à initialiser des
chemins vers un ensemble donné d'adresses. Ces adresses peuvent être
assignées ou non.

Pour que cette attaque fonctionne, chaque nœud victime doit :

- Être dans la portée radio de l'attaquant (au moins en réception).

- Avoir une entrée de chemin dans sa *Forwarding Table* avec *lui-même comme PO*. La valeur de la plage d'adresses du PT est sans importance. Cependant, l'attaquant doit connaître une adresse incluse dans la plage du PT.

L'utilisation légitime d'un *Path Request Solicitation* consiste à demander aux nœuds de mettre à jour les chemins qu'ils possèdent déjà. Cependant, ce message peut être exploité par un attaquant pour forcer les nœuds dans sa portée radio à initialiser des chemins vers n'importe quelles adresses qu'il souhaite. En effet, lorsqu'un nœud reçoit un *Path Request Solicitation*, il vérifie que seule une adresse listée dans le paquet est le PT d'un chemin dont il est le PO.

À partir de cela, tant que l'attaquant sait qu'un nœud autour de lui possède un chemin vers une adresse donnée, il peut forger un paquet *Path Request Solicitation* contenant cette adresse ainsi que d'autres adresses pour lesquelles il souhaite que la victime initialise un chemin. Cela lui permet de forcer la victime à initialiser des chemins vers n'importe quelles adresses de son choix, même des adresses inutilisées.

## 5.4 Attaques

Sur la base des vulnérabilités explicitées dans cet article, et en utilisant les actions élémentaires décrites, nous présentons 3 scénarios d'attaque possibles. Toutes les attaques exploitent d'une manière ou d'une autre $V_2$. Elles sont numérotées de $A_1$ à $A_4$.

- **$A_1$ - Découverte de réseau** : Permet à un attaquant de découvrir tous les nœuds du réseau, ainsi que la distance entre l'attaquant et chacun d'eux.

- **$A_2$ - Empoisonnement de Forwarding Table via un Path Reply hijacking** : Un attaquant peut réagir à la création d'un chemin non fixe afin d'empoisonner la *Forwarding Table* du PO, l'empêchant ainsi potentiellement d'envoyer des messages à un ensemble d'adresses.

- **$A_3$ - Empoisonnement de Forwarding Table via un chemin bidirectionnel** : Un chemin bidirectionnel de l'attaquant vers un nœud victime peut être utilisé pour empoisonner sa *Forwarding Table*.
Table presque sans prérequis. Cela perturbe considérablement la réception des messages envoyés par la victime.

- **A**_4_ : **Empoisonnement de Forwarding Table via Path Request Solicitation** : Un message de contrôle spécifique permet de forcer les nœuds à portée directe de l'attaquant à créer des chemins vers n'importe quelles adresses, chemins que l'attaquant peut utiliser pour empoisonner leur *Forwarding Table*.

**A**_1_ - **Découverte de réseau** Plusieurs de nos attaques reposent sur la connaissance des adresses utilisées (ou non) dans le réseau. En utilisant *E*_1, nous pouvons acquérir des informations sur toutes les adresses unicast actives utilisées dans le réseau. Nous pouvons donc considérer cette attaque comme un prérequis à d'autres attaques.

Bien qu'un mécanisme de *Heartbeat* existe en BM, selon la configuration, les nœuds ne sont pas nécessairement tenus d'envoyer ces messages. *A*_1, tant que le DF est activé sur le réseau, peut fournir à un attaquant des informations sur n'importe quel nœud du réseau.

Étant donné que le nombre d'adresses unicast assignées est limité (avec 32767 possibilités), un attaquant peut envoyer un message *Path Request* ciblant toutes les adresses unicast possibles. Un message *Path Reply* est attendu pour chaque adresse utilisée. De plus, l'attaquant peut également collecter des données liées aux plages d'adresses, c'est-à-dire si un nœud possède plusieurs *Elements*.

Si l'attaquant est statique, il est également possible d'envoyer, pour chaque nœud trouvé, un message *Path Echo Request* afin de recevoir un *Path Echo Reply*. L'attaquant peut alors calculer la distance entre lui-même et le nœud en examinant le champ *TTL* au niveau de la couche réseau (qui est toujours envoyé avec une valeur de 127 au départ). Pour réussir cette partie de l'attaque, l'attaquant ne doit pas envoyer de messages *Path Confirmation* pendant la création des chemin. En effet, un *Path Echo Reply* envoyé en utilisant le DF ne permet pas à l'attaquant d'obtenir des informations sur la distance (cela peut dépendre de l'implémentation, si le *TTL* est utilisé ou non en DF).

Une limite de *A*_1 est liée au temps nécessaire à son exécution. Si l'on considère que l'attaquant n'a qu'un seul nœud relais à sa portée, et si le réseau a la configuration du BM par défaut, *A*_1 prendrait environ 22,3 heures pour être exécutée en intégralité (borne supérieure). Cela est dû au fait qu'un nœud ne peut pas défaut avoir que 2 entrées dans sa *Discovery Table* en même temps. Une entrée est supprimée après 5 secondes si le chemin n'est pas créé. L'attaquant peut ainsi tester 2 adresses toutes les
5 secondes, ce qui conduit à la valeur de 22,3 heures. Cependant, étant donné que les adresses sont attribuées successivement aux nœuds lors du *Provisioning*, des stratégies d'optimisation peuvent être mises en place pour raccourcir cette durée.

De plus, un attaquant peut ne vouloir découvrir que quelques adresses non attribuées (par exemple pour les utiliser au sein d'autres attaques). Dans ce scénario, il peut commencer à partir d'une valeur d'adresse élevée et s'arrêter dès qu'il a trouvé suffisamment d'adresses non attribuées.

**A₂ - Empoisonnement de Forwarding Table via un Path Reply hijacking**

A₂ est déclenchée en réponse à un *Path Request* légitime reçu par l'attaquant. Si l'attaque est un succès, le PO dispose d'une entrée empoisonnée dans sa *Forwarding Table*, comme décrit dans V₁. Ainsi, le PO considère que le chemin créé est valide pour un ensemble d'adresses qui ne sont pas accessibles via ce chemin. En conséquence, il ne pourra potentiellement pas envoyer de paquets vers ces adresses. Cette attaque utilise les actions élémentaires E₂, E₃, E₄ et E₅.

Un attaquant peut réagir à un message *Path Request* reçu. Il suivra alors les étapes suivantes :

1. **Utiliser E₃ et envoyer un message Path Reply falsifié.** Le message envoyé indique que le PT est un nœud dépendant d'un autre, empoisonnant ainsi l'entrée de chemin du PO. Avec cette étape uniquement, la *Forwarding Table* du PO est empoisonnée, mais les messages du PO arriveront au PT. Le chemin reste donc valide du PO au PT mais est aussi valide pour d'autres adresses potentiellement inatteignables par le PO via ce chemin.

2. **Utiliser E₂ grâce à laquelle l'attaquant tente de devenir l'un des nœuds relais le long du chemin et d'empêcher le PO d'envoyer des messages au PT.** Pour cela, il envoie un *Path Request* falsifié annonçant une métrique de 0 pour créer un *sinkhole*. Si cette étape réussit, l'un des *Path Reply* sera alors dirigé vers l'attaquant. Il ne le transmettra pas puisque E₃ gère l'envoie du *Path Reply* (malicieux). En conséquence du succès de cette étape, les messages du PO vers la PT n'arriveront pas à destination puisque l'attaquant qui est un relais du chemin ne transmettra pas les messages. Bien que cette étape puisse échouer, une tentative ratée ne change pas le reste de l'attaque.

3. **Empêcher la création de voies supplémentaires avec E₄.**

Cela réduira les chances que les paquets atteignent leur destination,
car le chemin ne dispose que d'une seule voie et donc d'une quantité moindre de nœuds relais.

4. **Utiliser $E_5$ pour maintenir en vie le chemin empoisonné du PO.** En effet, le PO et le PT n'auront pas d'entrées de chemin équivalentes dans leur *Forwarding Table*. Par conséquent, le PT ne répondra pas aux *Path Echo Request* émis par le PO. $E_5$ peut être utilisée pour pallier ce problème.

L'attaque résulte en l'ajout d'un chemin empoisonné dans la *Forwarding Table* du PO, répertoriant des adresses erronées comme destinations valides pour le chemin. En conséquence, les messages envoyés par le PO vers ces adresses n'arriveront pas à destination tant que les nœuds correspondants ne sont pas à portée des nœuds relais composant le chemin. Les messages du PO vers le PT seront aussi potentiellement bloqués si $E_2$ est un succès.

La figure 9 illustre l'attaque $A_2$ en utilisant la topologie du réseau de la figure 3. Dans ce cas, l'attaquant a réussi à empoisonner la *Forwarding Table* du PO. En conséquence, lorsque `0x09` souhaite maintenant envoyer un message à une adresse dans la plage `0x01` à `0x1FE` pour laquelle il ne détient aucun autre chemin, il ne va pas initialiser un nouveau chemin puisque le chemin malicieux correspond. Si la destination du paquet ne se trouve pas en portée du chemin malicieux, le message est perdu. De plus, dans cet exemple, l'attaquant s'est placé avec succès comme l'un des relais du chemin, et peut ainsi bloquer tous les messages qu'il souhaite bloquer (sinkhole).

**$A_3$ - Empoisonnement de *Forwarding Table* via un chemin bidirectionnel**
Dans le but de tirer parti de la vulnérabilité $V_1$, cette attaque vise à empoisonner la *Forwarding Table* d'un nœud victime. L'attaque $A_3$ s'appuie sur les actions élémentaires $E_1$ et $E_6$. Cette attaque se déroule en deux étapes :

1. **Création d'un chemin bidirectionnel Attaquant $\leftrightarrow$ Victime avec $E_1$ :** Par défaut, en BM, un PT recevant un *Path Request* demandera la création d'un chemin bidirectionnel dans le *Path Reply* en réponse.

2. **Utilisation de $E_6$ pour mettre à jour les nœuds dépendants :** Un message de *Dependent Node Update* est envoyé afin d'ajouter une plage d'adresses de nœuds dépendants au chemin créé. Le *PathEndpoint* correspond à l'adresse de l'attaquant utilisée dans
<figure><img src="image_10.png" /><figcaption>**Fig. 9.** Attaque $A_2$ sur la création de chemin de 0x09 à 0x1C. Pour plus de clarté, les messages rejetés au niveau de la couche réseau ne sont pas affichés, de même que les *Path Request* qui n'annoncent pas une meilleure métrique.</figcaption></figure>

la première étape. L'attaquant peut envoyer autant de *Dependent Node Update* qu'il le souhaite, un par plage d'adresses à ajouter.

En conséquence, la *Forwarding Table* de la victime (ainsi que celle des nœuds relais situés le long du chemin créé) contient une entrée empoisonnée. En effet, cette entrée indique que le PO, c'est-à-dire l'attaquant, possède des nœuds dépendants qu'il n'a pas en réalité. Cependant, comme le chemin est un chemin bidirectionnel, ces nœuds dépendants sont également considérés comme des PT valides du chemin avec la victime comme PO.

Dès lors, supposons que la victime envoie un message à un nœud listé comme nœud dépendant de l'attaquant. Si le nœud n'est pas dans la portée radio des nœuds relais composant le chemin malveillant, il ne recevra pas le message.

La figure 10 montre un exemple de $A_3$ ciblant le nœud 0x09 dans la réseau d'exemple. Après l'attaque, si 0x09 souhaite envoyer un message à
<figure><img src="image_11.png" /><figcaption>**Fig. 10.** Attaque $A_3$ via utilisation malveillante du message *Dependent Node Update*</figcaption></figure>

une adresse entre 0x01 et 0xFF, celui-ci sera transmis par le chemin vers l'attaquant.

Cette attaque ne peut cibler qu'un ensemble limité de nœuds. En effet, attaquer une quantité trop importante de nœuds dans le réseau entraînerait une possible inondation des messages envoyés par les victimes, limitant de fait l'impact de l'attaque. Cela est dû au fait que le chemin créé est un chemin bidirectionnel. Ainsi, les messages envoyés de n'importe quelle adresse vers le nœud victime sont également relayés par ce chemin. Si plusieurs chemins empoisonnés se croisent, ce qui est très probable, cela entraînerait la transmission de la plupart des messages vers leur destination.

Il est toutefois possible de cibler des nœuds en portée directe de l'attaquant sans limites, car aucun nœud relais autre que la victime ne participe à l'attaque. En tirant profit de la connaissance accumulée lors
de l'attaque $A_1$, l'attaquant peut lister les nœuds en portée directe du noeud malveillant et les cibler en priorité.

Etant donné que le *Configuration Manager* constitue un point de défaillance unique, l'attaque utilisée contre celui-ci entraînerait une perturbation significative du réseau, pouvant mener à des scénarios d'attaques complexes tels que l'étude de cas étudié dans la section 5.7.

## 5.5 $A_4$ - Empoisonnement de *Forwarding Table* via *Path Request Solicitation*

L'attaque $A_4$ cible les nœuds dans la portée radio de l'attaquant. Un usage détourné du message *Path Request Solicitation* peut être utilisé pour empêcher les victimes d'envoyer des messages à tout noeud qui n'est pas dans leur portée.

Cette attaque vise à exploiter $V_1$ en utilisant $E_7$ et $E_3$. Comme elle n'affecte que les nœuds dans la portée radio de l'attaquant, nous pouvons différencier l'attaquant statique de l'attaquant mobile, ce dernier ayant probablement un impact plus important sur la disponibilité du réseau. Si l'attaquant est mobile, $E_5$ est également utilisée.

L'objectif est de forcer les nœuds autour de l'attaquant à créer des chemins vers des adresses inexistantes avec $E_7$. Étant donné que les adresses pour le PT des chemins n'existent pas, l'attaquant répond avec un *Path Reply* empoisonné en usurpant ces adresses avec $E_3$. En conséquence, ces entrées de chemin répertorient des adresses comme PT, même si elles sont en réalité inaccessibles via ce chemin.

Cette attaque suppose que l'attaquant sait que les nœuds autour de lui possèdent au moins un chemin vers n'importe quelle adresse qui provient d'eux (pour $E_7$). Les nœuds qui n'ont aucun chemin avec eux-même comme PO sont immunisés contre cette attaque.

Au préalable, l'attaquant doit également réaliser une attaque de dé couverte de réseau ($A_1$) afin de répertorier les adresses unicast assignées et non assignées dans le réseau.

En partant de cela, l'attaquant va :

1. **Utiliser $E_7$ et envoyer un message *Path Request Solicitation*.** Pour chaque victime, le message contient une adresse qui est le PT d'un chemin partant d'elle (peut être mutualisé). Il contient également au moins une adresse unicast non assignée pour l'étape suivante.

2. **En réponse au *Path Request* pour l'adresse inutilisée en voyé par chaque victime,** l'attaquant utilise $E_3$ pour empoisonner leur *Forwarding Table*.
<figure><img src="image_12.png" /><figcaption>Fig. 11. Attaque $A_4$ via *Path Request Solicitation* sur 2 nœuds autour de l'attquant</figcaption></figure>

La figure 11 illustre l'attaque basée sur la topologie de la figure 3. Le résultat de l'attaque est que les nœuds 0x0A et 0x12 ont des chemins vers la plage d'adresses 0x100 à 0x1FE, ainsi que vers les nœuds dépendants au PT allant de 0x01 à 0xFF. Cela signifie que les messages vers les adresses de cette plage utiliseront ce chemin et ne créeront pas un nouveau chemin (à l'exception de 0x02 et 0x03 qui ont leurs chemins valides). Cependant, l'attaquant pourrait jammer le réseau lorsqu'il reçoit un *Path Echo Request* pour ces chemins afin de bloquer la *Path Echo Reply*, ce qui entraînerait la suppression des chemins légitimes car considérés comme non valides.

Le nombre d'adresses inutilisées dans le paquet *Path Request Solicitation* dépend du nombre d'adresses vers lesquelles l'attaquant souhaite bloquer les messages. Chaque chemin créé via $A_4$ peut avoir un total de 510 adresses considérées comme des destinations valides (255 adresses cibles dépendantes, 255 adresses en PT). Ainsi, au maximum 65 adresses inutilisées sont nécessaires pour couvrir l'ensemble des 32767 adresses unicast.

De plus, un attaquant mobile est capable de mener cette attaque sur potentiellement plus de nœuds dans le réseau. Afin de maintenir les chemins créés vers les adresses inutilisées actifs lorsqu'il est éloigné des
nœuds, il peut utiliser $E_5$ puisque les chemins créés sont unidirectionnels. Si l'attaquant est statique, il recevra tous les *Path Echo Request* des victimes et pourra y répondre normalement.

Cette attaque peut éventuellement bloquer tous les messages nécessitant un relais des nœuds voisins de l'attaquant. Néanmoins, elle nécessite d'être à proximité des victimes et de connaître une partie de leur *Forwarding Table*. Elle est moins flexible que $A_3$, cependant elle ne nécessite pas l'activation de la fonctionnalité de chemins bidirectionnels sur le réseau contrairement à $A_3$.

## 5.6 Comparaison et synthèse des attaques par empoisonnement

Les attaques $A_2$, $A_3$ et $A_4$ ont chacune leurs pré-requis et impacts propres. Elles exploitent $V_1$ afin d'empoisonner les *Forwarding Tables* des victimes :

- $A_2$ est complexe et présente de nombreux prérequis. Elle repose également sur la réception d'un *Path Request*, ce qui ajoute une couche de difficulté. Cependant, elle met en évidence les limites des mécanismes de résilience mis en place par le DF.

- $A_3$ est fiable, présente très peu de prérequis et peut sévèrement impacter la victime. Cependant, elle ne peut cibler de manière fiable qu'un seul nœud sur le réseau avant de devenir inefficace (sans compter les nœuds en portée radio de l'attaquant). Néanmoins, le *Configuration Manager*, étant un point de défaillance unique, en fait une cible idéale. Cela nécessite cependant que la fonctionnalité de chemins bidirectionnels soit activée sur le réseau, ce qui est le cas par défaut mais n'est pas garanti.

- $A_4$ est fiable et efficace mais présente un prérequis de proximité avec les victimes ainsi que la connaissance préalable d'une partie de leur *Forwarding Table*. Elle reste néanmoins une alternative efficace à $A_3$ dans le cas où les chemins bidirectionnels ne pas activés dans le réseau (ce qui reste peu probable étant donné la valeur ajoutée de cette fonctionnalité et son activation par défaut).

## 5.7 Étude de cas d'un rafraîchissement de NetKey après une attaque sur le *Configuration Manager*

Les attaques décrites dans ce papier mettent en lumière la possibilité pour un attaquant de bloquer les messages d'un ou plusieurs nœuds vers
une partie d'un réseau BM dans le cadre des messages vers des adresses unicast.

Afin d'évaluer un impact réel sur un réseau BM de l'empoisonnement de la *Forwarding Table* du *Configuration Manager* (via *A*<sub>3</sub> par exemple), la situation choisie est la procédure de rafraîchissement de la NetKey telle que décrite dans la section 2.4.

**Situation de départ** Bien que décrite dans la spécification, la procédure de rafraîchissement d'une NetKey présente certaines ambiguïtés ou tout du moins laisse un certain degré de liberté aux développeurs voulant implémenter la pile protocolaire du BM.

Ainsi, le comportement du *Configuration Manager* lors de la distribution de la nouvelle NetKey (passage de la phase 0 à la phase 1) lorsque certains nœuds ne répondent pas à ses messages n'est pas détaillé.

Aussi, étant donné que les messages *Config NetKey Update* sont envoyés via des adresses de destination unicast, si le *Configuration Manager* a été la victime d'une attaque par empoisonnement de *Forwarding Table*, ces messages n'arriveront pas à leur destination. Nous supposons donc qu'un sous-ensemble de nœuds de notre réseau est inaccessible depuis le *Configuration Manager* à cause de l'attaque *A*<sub>3</sub> utilisée sur celui-ci.

Le *Configuration Manager* attend en réponse pour chaque nœud un message *Config NetKey Status* confirmant la bonne réception de la nouvelle clé. Cependant, dans le cas où le message n'arrive pas à destination (à cause de l'attaque ou bien même pour une autre raison), la suite de la procédure n'est pas spécifiée. Aussi, les 2 implémentations open source du BM que nous avons étudiées (ZéphyrOS et esp-idf) fournissent une API permettant de mettre en place la procédure depuis le *Configuration Manager* mais ne précisent pas comment gérer les cas d'échecs et ne les gèrent pas automatiquement.

Nous partons de l'hypothèse que le *Configuration Manager* envoie les messages *Config NetKey Update* aux nœuds par ordre croissant de leur adresse primaire unicast.

Nous pouvons partir de deux postulats différents pouvant être deux choix d'implémentation de cette procédure. Lorsque le *Configuration Manager* ne reçoit pas de réponse d'un nœud, il peut réagir de deux manières :

- $CM_1$ : il continue à tenter X fois d'envoyer le message au nœud. Une limite sera forcément donnée, et le *Configuration Manager* en cas d'échec total sur un nœud ne continue pas la procédure sur le reste des nœuds.
— $CM_2$: il continue à tenter X fois d'envoyer le message au nœud. En cas d'échec total, le *Configuration Manager* abandonne le nœud et passe au suivant dans la liste (ordre croissant des adresses primaires unicast) et termine la procédure avec ceux qui répondent.

Dans le cas du $CM_1$, il n'y a, à priori, pas de moyens prévus dans la spécification pour annuler un rafraîchissement de clé, c'est à dire faire passer une NetKey au sein d'un nœud de la phase 1 vers la phase 0 afin de garder l'ancienne valeur de la NetKey uniquement, même si en pratique rester en phase 1 permet de continuer à l'utiliser normalement. Un administrateur réseau peut en revanche supprimer la NetKey et la recréer, sous réserve d'avoir en avance une autre NetKey partagée par l'ensemble du sous-réseau ce qui paraît en pratique peu probable.

Du point de vue de l'attaquant, plusieurs cas de figures sont possibles vis à vis de la procédure.

— **NoRecvNK**: L'attaquant ne reçoit pas la nouvelle NetKey car il ne fait pas partie des nœuds recevant la nouvelle NetKey ou si le *Configuration Manager* est $CM_1$ et que l'adresse primaire unicast de l'attaquant est plus grande que le premier nœud bloquant.

— **RecvNK**: L'attaquant fait partie des nœuds recevant la nouvelle NetKey et la reçoit effectivement (soit car le *Configuration Manager* est $CM_2$, soit parce que l'attaquant a une adresse primaire unicast plus petite que le premier nœud non accessible depuis le *Configuration Manager* dans le cas $CM_1$.

Ces deux cas de figures NoRecvNK et RecvNK, combinés aux 2 comportements possibles du *Configuration Manager* ($CM_1$ et $CM_2$) permettent d'établir quatre situations (A,B,C et D) possibles comme décrit dans la table 6.

<table><caption>**Tableau 6.** Différentes situations présentées pour notre étude de cas.</caption><thead><tr><th></th><th>NoRecvNK</th><th>RecvNK</th></tr></thead><tbody><tr><th>CM<sub>1</sub></th><td>Situation A</td><td>Situation B</td></tr><tr><th>CM<sub>2</sub></th><td>Situation C</td><td>Situation D</td></tr></tbody></table>

Afin d'illustrer l'impact de l'empoisonnement total via $A_3$ de la *Forwarding Table* du *Configuration Manager*, la figure 12 présente la résultat de cette attaque sur notre réseau exemple avec le *Configuration Manager* situé au niveau du nœud 0x03.
<figure><img src="image_13.png" /><figcaption>**Fig. 12.** Conséquence de $A_3$ sur le réseau exemple, le nœud 0x03 est le *Configuration Manager*</figcaption></figure>

## Conséquences de l'empoisonnement dans la Situation A
Cette situation implique que l'attaquant ne reçoit pas la nouvelle NetKey et que la procédure de rafraîchissement de clé ne se termine pas.

Deux cas de figures peuvent amener l'attaquant à ne pas recevoir sa NetKey :

- L'attaquant a été blacklisté et n'est pas censé la recevoir (exclu du réseau).

- L'attaquant a une adresse primaire unicast plus grande que celle d'un nœud non accessible par le *Configuration Manager*.

Étant donné que la procédure de rafraîchissement a été avortée, tous les nœuds continuent d'utiliser l'ancienne valeur de la NetKey (en phase 0 ou 1). Il n'y a donc aucun changement de connectivité entre les nœuds. Les nœuds en rouge et hachurés dans la figure 12 seront ainsi toujours capables de parler avec les nœuds en vert/non hachurés.

Néanmoins, la procédure a été bloquée, ce qui peut poser problème dans le cas où le *Configuration Manager* voulait exclure des nœuds afin d'éviter par exemple une attaque de la poubelle. Aussi, certains nœuds resterons bloqués en phase 1 et il faudra obligatoirement terminer la procédure afin d'en retenter une nouvelle, la spécification ne décrivant aucun moyen de passer de la phase 1 à la phase 0 avec l'ancienne clé.
**Conséquences de l'empoisonnement dans la Situation B** Dans cette situation, la procédure de rafraîchissement de clé a été stoppée au moment où un nœud n'a pas répondu au *Configuration Manager* (car non accessible à cause de l'empoisonnement de sa *Forwarding Table*). De plus, l'attaquant a reçu la nouvelle NetKey, car il n'était pas blacklisté et le blocage de la procédure a eu lieu après l'envoi de la clé vers lui (nous considérons, pour cet exemple, que tous les noeuds verts/hachurés ont reçu la nouvelle NetKey).

Cette situation permet à l'attaquant de finaliser la procédure en faisant se propager dans le réseau un *Secure Network Beacon* pour la nouvelle valeur de la NetKey. Ainsi, les nœuds ayant reçu la nouvelle NetKey et le *Secure Network Beacon* n'utiliseront plus l'ancienne. De plus, les nœuds qui n'ont pas reçus la nouvelle NetKey utiliseront encore l'ancienne valeur.

Ainsi, l'état de réseau sera le suivant :

- Les nœuds ayant reçu la nouvelle NetKey et ceux ne l'ayant pas reçue ne pourront plus communiquer ensemble, même s'ils sont à portée directe les uns des autres. Dans la figure 12, les nœuds 0x6 et 0x7 ne pourront par exemple plus communiquer ensemble.

- L'attaquant possédant la nouvelle clé et ayant gardé l'ancienne peut, en théorie, communiquer avec tous les nœuds. En pratique, si l'attaquant est uniquement entourés de relais utilisant la nouvelle clé, les messages utilisant l'ancienne ne pourront être relayés.

**Conséquences de l'empoisonnement dans la Situation C** Dans cette situation, l'attaquant n'a pas reçu la nouvelle NetKey car il a été blacklisté. C'est aussi le cas pour les autres nœuds blacklistés ou non accessibles depuis le *Configuration Manager* à cause de l'empoisonnement. La procédure de rafraîchissement de clé s'est quant à elle terminée pour les nœuds qui ont reçu la nouvelle valeur.

Ici, le réseau est scindé en deux, les nœuds utilisant la nouvelle clé et les nœuds utilisant l'ancienne. Ces deux sous-ensembles ne peuvent plus communiquer entre eux.

L'attaquant quant à lui peut uniquement communiquer avec les nœuds ayant l'ancienne valeur de la clé.

**Conséquences de l'empoisonnement dans la Situation D** Dans cette dernière situation, l'attaquant a reçu la nouvelle NetKey et la procédure de rafraîchissement de clé s'est terminée pour les nœuds qui l'ont reçue sans intervention de l'attaquant.
Les conséquences sont les mêmes que celles de la situation B, sans que l'attaquant n'ait eu à envoyer de *Secure Network Beacons*.

# 6 Expérimentations

Afin de tester nos attaques, nous avons mené des expériences en utilisant les implémentations BM disponibles et le framework WHAD [4]. Nos résultats montrent la faisabilité pratique de nos attaques visant les piles BM open source.

## 6.1 WHAD

Notre recherche nécessitait un outil fiable et pratique pour tester la sécurité du BM. Par conséquent, nous avons utilisé le framework WHAD pour implémenter les attaques décrites dans l'article [4].

WHAD supporte plusieurs protocoles de communication sans fil, dont le BLE. Nous avons étendu le framework avec une implémentation de la pile protocolaire du BM flexible adaptée aux besoins de sécurité offensive. WHAD supportant par défaut une grande variété de matériels, notre implémentation est compatible avec plusieurs équipements radios.

Dans le cas du BM, nous utilisons la partie contrôleur de la pile BLE et avons implémenté la pile protocolaire du BM au niveau de l'hôte. Notre implémentation est à la fois minimale et modulaire, permettant de modifier la gestion des différents événements via des * callbacks *. Cette structure offre aux chercheurs en sécurité la possibilité de mettre en œuvre facilement leurs idées d'attaque avec le niveau d'abstraction approprié.

## 6.2 Banc de test

Afin d'évaluer nos attaques en pratique, nous avons utilisé un banc d'es-sai comprenant divers composants : plusieurs cartes ESP32-C6-DevKitC en tant que nœuds légitimes et un dongle nRF52840 (WHAD) pour l'attaquant. Une représentation de cette configuration est disponible en Annexe A.

Lors de l'évaluation des attaques, celles-ci étant principalement basées sur le DF, nous avons rencontré divers problèmes liés à l'indisponibilité de dispositifs supportant ce mécanisme de routage. En effet, à l'heure de la rédaction de cet article, il n'existe, à notre connaissance, qu'une seule implémentation du BM qui prend en charge la version 1.1 avec le DF. Cette implémentation repose sur le framework ESP-IDF que nous
avons utilisé avec les cartes ESP32-C6-DevKitC [9]. Nos nœuds utilisant ESP-IDF ont les caractéristiques suivantes :

- Un système de whitelist a été mis en place. Il est basé sur la Bluetooth Device Address de chaque nœud. Cette liste repose sur une fonctionnalité préexistante de ESP-IDF, et nous a permis de créer différentes topologies de réseau dans un espace limité.

- Chaque nœud possède une NetKey et une AppKey. De plus, tous les nœuds implémentent les modèles Generic On/Off Client et Server (au niveau de la couche Access). Ainsi, les nœuds prennent en charge l'envoi et la réception de messages applicatifs Generic On/Off.

- Une interface web accessible via un serveur HTTP (grâce au module de coexistence BLE-WiFi de ESP-IDF [8]). Elle permet d'accéder à un panneau de contrôle personnalisé utilisé pour gérer les whitelists, envoyer des messages à n'importe quelle adresse, et surveiller les chemins ainsi que les messages reçus.

## 6.3 Expérimentations et résultats

Nous avons mené des expérimentations afin d'évaluer l'impact de l'attaque $A_3$ sur le réseau. Plus généralement, nous avons quantifié l'impact de l'exploitation de $V_1$ sur un seul nœud. Sur la base d'une topologie en grille, nous avons calculé le ratio de nœuds inaccessibles depuis le nœud victime (que nous considérons comme étant le Configuration Manager). Nos tests ont lieu après l'exploitation de l'attaque $A_3$ sur la victime dont la Forwarding Table était vide.

Le ratio utilisé est le Reachable Nodes Ratio (RNR), défini par l'équation 1. La connectivité est testée en envoyant un message Generic On/Off Set à chaque nœud. Si le nœud cible reçoit le message, il répond par un message Generic On/Off Status en utilisant le MF, sa LED clignote et le nœud est considéré comme atteignable (ou reachable). Plus le RNR tend vers 0, plus l'impact de l'attaque est grand.

$$RNR = \frac{\text{Number of reachable nodes}}{\text{Total number of nodes}} \qquad (1)$$

Nos expériences font abstraction de la distance entre les nœuds, de la densité du réseau ou des puissances d'émission des nœuds avec la topologie en grille. Nous justifions cette abstraction par le fait que nos attaques ciblent le DF seulement et ne prennent pas en compte le comportement des couches physiques. Par exemple, un lien momentanément indisponible car
un nœud est derrière un mur épais résulterait uniquement en un changement dans notre topologie. Afin de nous assurer que nos tests démontrent avec précision l'impact de l'attaque uniquement, nous avons minimisé l'impact de facteurs "extérieurs" (comme des interférences) en envoyant les messages ON/Off plusieurs fois par nœud testé et en positionnant tous nos nœuds dans un même espace réduit et ouvert. En amont de l'évaluation, nous avons aussi testé la connectivité attendue de chaque nœud avec ses voisins (dans la topologie en grille) en vérifiant la bonne réception d'un message envoyé via le MF avec un TTL de 1 (message non relayé).

Les paramètres de nos expérimentations sont la taille de la grille du réseau (3x3 signifie 9 nœuds au total), ainsi que la position de l'attaquant et de la victime (au sein de la grille et leur position relative).

Sur cette base, nous avons considéré 3 cas de base Case1, Case2 et Case3 pour lesquels nous avons testé $A_3$. La figure 13 les présente.

<figure><img src="image_14.png" /><figcaption>Fig. 13. Représentation graphique des résultats des différents cas considérés.</figcaption></figure>

Dans le Case1, la grille "s'agrandit" autour de l'attaquant et la victime se trouve à l'extrémité. La distance entre l'attaquant et la victime est de 0 (ils sont dans la portée l'un de l'autre).
Le *Case2* est similaire au *Case1*, mais les positions de l'attaquant et de la victime sont inversées

Le *Case3* est un cas où l'attaquant et la victime se trouvent toujours sur "le bord" de la grille, sur une diagonale. Ainsi, la distance entre eux augmente à mesure que la grille s'agrandit. Ce cas représente le pire scénario pour notre attaque, car le chemin empoisonné est long, augmentant les chances qu'un nœud soit dans la portée d'un nœud relais du chemin.

Les résultats détaillés de l'expérimentation sont présentés dans la figure 14. Celle-ci montre que la valeur de RNR diminue à mesure que la taille de la grille augmente. L'attaque est plus efficace lorsque la distance entre l'attaquant et la victime est faible. En effet, plus il y a de nœuds relais sur le chemin, plus les chances qu'un message légitime parvienne à sa destination sont élevées. Cependant, nous pouvons observer que même dans le *Case3*, la valeur de RNR commence à diminuer à partir de la grille 4x4.

<figure><img src="image_15.png" /><figcaption>Fig. 14. Résultats de l'évaluation du Reachable Nodes Ratio (RNR).</figcaption></figure>

Ces expérimentations montrent que le positionnement de l'attaquant par rapport à la victime, la "centralité" de la victime ainsi que la taille du réseau influencent l'efficacité de l'attaque par empoisonnement de chemin. Toutefois, si nous extrapolons en fonction de la taille de la grille, la valeur de RNR tend vers 0, ce qui montre l'efficacité de l'attaque.
# 7 Contre-mesures

## 7.1 Suppression de la fonctionnalité de nœuds dépendants en DF

Nous proposons de supprimer la notion de dépendance en DF (notam- ment dans les *Forwarding Table*). D'un point de vue du PO, il n'est pas important de savoir si le PT d'un chemin est un nœud dépendant d'un autre. Il en est de même pour les nœuds dépendants du PO par rapport au PT. Au final, les messages sont envoyés avec les mêmes paramètres.

Ainsi, les nœuds conscients d'une relation de dépendance d'un autre nœud à eux même (via la relation de *Friendship* ou autre), peuvent se comporter comme si les plages d'adresses des nœuds dépendants leur appartenaient. Par conséquent, les messages *Path Request* auront pour réponse un *Path Reply* sans nœuds dépendants spécifiés. Lorsque un nœud reçoit un message destiné à l'un de ses nœuds dépendants, il le stocke dans une file d'attente (pour la *Friendship*), ce qui correspond au comportement actuel.

La suppression du concept de nœuds dépendants en DF aurait pour conséquence une augmentation du nombre de chemins. Si un nœud soutient 3 nœuds dépendants, au lieu d'un seul chemin, il y aura 4 chemins (un pour chaque nœud dépendant et le chemin vers le nœud support) pour chaque PO.

Cette solution empêcherait un attaquant d'utiliser $V_1$ et neutraliserait totalement $A_3$. Cependant, elle ne l'empêcherait pas de falsifier les messages *Path Reply* et de spécifier des plages d'adresses PT incorrectes.

## 7.2 Métrique plus sûre pour la sélection du meilleur chemin

De nombreuses études présentent des métriques plus sûres et plus efficaces lorsqu'il s'agit de choisir le meilleur chemin [11, 17]. Dans la version 1.1 du BM, la seule métrique disponible est celle décrite dans cet article.

Nous proposons une alternative simple qui ne nécessiterait pas de modifications structurelles du protocole. En utilisant une métrique basée sur le temps, les nœuds sélectionnent le meilleur chemin en fonction du premier message *Path Request* qu'ils reçoivent pour un chemin. Ainsi, le chemin "le plus rapide" est considéré comme le meilleur.

Bien sûr, cela ne représente qu'une capture de l'état du réseau lors de l'initialisation du chemin et cela ne constitue peut-être pas le chemin le plus rapide en pratique. La création de voies multiples pourrait être
réalisée en ajoutant un délai supplémentaire aux nœuds relais qui font
déjà partie d'une voie.

Cette solution rendrait les attaques de type *sinkhole*, telles que celles décrites dans $A_2$, beaucoup plus difficiles à réaliser. L'utilisation d'autres métriques issues de l'état de l'art, dans le but de rendre plus difficile pour un attaquant d'exploiter $E_2$, est suggérée.

8 Conclusion et Perspectives

Le BM a été conçu en tenant compte de la sécurité et de la confidentia-
lité, et vise à corriger les faiblesses des réseaux maillés existants. L'ajout
de paramètres de sécurité appliqués par défaut montre par exemple une
avancée en la matière. Cependant, la jeunesse du protocole et le manque
d'outils appropriés ont retardé, à notre sens, les évaluations de sécurité.

Dans cet article, nous présentons la première analyse du mécanisme
de *Directed Forwarding* récemment ajouté au BM. Nous avons identifié
plusieurs vecteurs d'attaque impactant la disponibilité du réseau. Nous
montrons que le DF permet à un nœud malveillant de perturber consi-
dérablement la création de routes et les communications en injectant des
messages de contrôle falsifiés. De plus, nous démontrons la faisabilité de
nos attaques en environnement réel. Nous introduisons également l'im-
plémentation du BM dans *WHAD*, ouvrant la voie à une analyse plus
systématique de la sécurité du protocole.

En perspective, nous envisageons de tester les autres fonctionnalités récemment ajoutées dans la version 1.1 du protocole, telles que le subnet bridging ou le Provisioning basé sur des certificats. De plus, tenter d'extrapoler les attaques existantes sur d'autres protocoles tels que le Zigbee ou le WirelessHART semble être une direction pertinente pour de futures recherches. Enfin, explorer l'utilisation du DF comme mécanisme défensif par l'utilisation de chemins fixes pourrait être une direction de recherche intéressante dans le cadre d'un Système de Détection d'Intrusion (IDS) centralisé pour les réseaux BM.

Références

1. Flor Álvarez, Lars Almon, Ann-Sophie Hahn, and Matthias Hollick. Toxic friends in your network : Breaking the bluetooth mesh friendship concept. In *ACM SSR*, 2019. https://doi.org/10.1145/3338500.3360334.

2. Taimur Bakhshi, Bogdan Ghita, and Ievgeniia Kuzminykh. A review of iot firmware vulnerabilities and auditing techniques. *Sensors*, 2024. https://doi.org/10.3390/s24020708.
3. Bluetooth SIG. Bluetooth mesh protocol specification. Technical report, Bluetooth Special Interest Group (SIG). Version 1.1, published September 12, 2023. https://www bluetooth.com/specifications/specs/mesh-protocol-specification-v1-1/

4. Romain Cayre and Cauquil Damien. WHAD: Wireless HAcknowledges Devices. https://github.com/whad-team/whad-client

5. Romain Cayre, Florent Galtier, Guillaume Auriol, Vincent Nicomette, Mohamed Kaâniche, and Géraldine Marconato. InjectABLE: Injecting malicious traffic into established Bluetooth Low Energy connections. In *IEEE/IFIP DSN*, 2021. https://laas.hal.science/hal-03193297

6. Tristan Claverie, Gildas Avoine, Stéphanie Delaune, and José Lopes Esteves. Extended version: Tamarin-based Analysis of Bluetooth Uncovers Two Practical Pairing Confusion Attacks. In *ESORICS*. Gene Tsudik, Mauro Conti, Kaitai Liang, Georgios Smaragdakis, 2023. https://hal.science/hal-04079883

7. Tristan Claverie and José Lopes Esteves. Bluemirror: Reflections on bluetooth pairing and provisioning protocols. In *IEEE WOOT*, 2021. https://doi.org/10.1109/SPW53761.2021.00054

8. Espressif Systems. ESP-IDF Coexistence API Guide. https://docs.espressif.com/projects/esp-idf/en/v5.3.1/esp32/api-guides/coexist.html

9. Espressif Systems. ESP-IDF: Espressif IoT Development Framework. https://github.com/espressif/esp-idf

10. S. Gurung and V. Mankotia. ABGF-AODV protocol to prevent black-hole, gray-hole and flooding attacks in MANET. *Telecommunication Systems*, 2024. https://doi.org/10.1007/s11235-024-01154-1

11. George Hatzivasilis, Ioannis Papaefstathiou, and Charalampos Manifavas. Scotres: Secure routing for iot and cps. *IEEE Internet of Things Journal*, 2017. https://doi.org/10.1109/JIOT.2017.2752801

12. Andrea Lacava, Pierluigi Locatelli, and Francesca Cuomo. Friendship security analysis in bluetooth low energy networks. In *MedComNet*, 2023. https://doi.org/10.1109/MedComNet58619.2023.10168876

13. Andrea Lacava, Valerio Zottola, Alessio Bonaldo, Francesca Cuomo, and Stefano Basagni. Securing bluetooth low energy networking: An overview of security procedures and threats. *Computer Networks*, 2022. https://doi.org/10.1016/j.comnet.2022.108953

14. Andrea Lacava, Valerio Zottola, Alessio Bonaldo, Francesca Cuomo, and Stefano Basagni. Securing bluetooth low energy networking: An overview of security procedures and threats. *Computer Networks*, 2022. https://doi.org/10.1016/j.comnet.2022.108953

15. Abdul Malik, Muhammad Zahid Khan, Mohammad Faisal, Muhammad Nawaz Khan, Tariq Hussain, and Razaz Waheeb Attar. Comprehensive taxonomy and critical analysis of mitigation approaches for black-hole and gray-hole security attacks in aodv-based vanets. *Computers and Electrical Engineering*, 2025. https://doi.org/10.1016/j.compeleceng.2024.109950

16. Elisha O Ochola and Mariki M Eloff. A review of black hole attack on aodv routing in manet. In *ISSA*, 2011.
17. Francesco Oliviero and Simon Pietro Romano. A reputation-based metric for secure routing in wireless mesh networks. In *IEEE GLOBECOM*, 2008. https://doi.org/10.1109/GLOCOM.2008.ECP.374.

18. Harry O'Sullivan. Security vulnerabilities of bluetooth low energy technology (ble). *Tufts University*, 2015.

19. Charles E. Perkins, John Dowdell, Lotte Steenbrink, and Victoria Pritchard. Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing. Internet-Draft draft-perkins-manet-aodvv2-05, Internet Engineering Task Force, 2024. Work in Progress. https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/05/.

20. Jianliang Wu, Ruoyu Wu, Dongyan Xu, Dave (Jing) Tian, and Antonio Bianchi. Sok : The long journey of exploiting and defending the legacy of king harald bluetooth. In *IEEE Symposium on Security and Privacy*. IEEE, 2024.

21. Qiaoyang Zhang and Zhiyao Liang. Security analysis of bluetooth low energy based smart wristbands. In *ICFST*, 2017. https://doi.org/10.1109/ICFST.2017.8210548.

22. Alireza Zohourian, Sajjad Dadkhah, Euclides Carlos Pinto Neto, Hassan Mahdikhani, Priscilla Kyei Danso, Heather Molyneaux, and Ali A. Ghorbani. Iot zigbee device security : A comprehensive review. *Internet of Things*, 2023. https://doi.org/10.1016/j.iot.2023.100791.

## A Expériences

<figure><img src="image_16.png" /><figcaption>Fig. 15. Description du banc de test.</figcaption></figure>
<figure><img src="image_17.png" /><figcaption>Fig. 16. Banc de test utilisé.</figcaption></figure>