Les essaims de drones

Télécharger le fichier original (Mémoire de fin d’études)

Drones et essaims

L’utilisation de drones est de plus en plus répandue et continue à se développer. Les missions assurées par les drones de nos jours couvrent de nombreux domaines, comme par exemple la prise de vue aérienne, l’agriculture, l’inspection d’installations industrielles et demain peut-être, le transport de personnes [4]. La sécurité de ces systèmes a logiquement été l’objet de travaux de recherche qui sont synthétisés dans la première partie de cette section.
Les limites dues à l’utilisation d’un drone unique (notamment une couverture restreinte par une autonomie limitée) ont conduit les chercheurs à envisager la mise en œuvre de flottes de drones plus ou moins coopératifs [5] : manipulation d’objets, recherche de victimes ou de cibles, surveillance de larges zones, etc. La taille de l’essaim peut varier grandement, d’une dizaine à plusieurs centaines de drones, bien que de telles tailles d’essaim n’aient sans doute été étudiées que par simulation [6]. Ces essaims de drones peuvent être vus comme des systèmes multi-agents, c’est pourquoi la suite de cette section se concentre sur ce type de systèmes, ainsi que sur les solutions permettant de les sécuriser.

Sécurité des drones

La sécurité pour les drones est une condition à leur plus grande intégration dans l’espace aérien et ainsi à une adoption plus large. De nombreuses études ont donc abordé ces sujets par le passé. Dans [7], les auteurs proposent une analyse de risque conforme aux standards européens [8] pour les systèmes de drones. Ils étudient les cibles et les vecteurs des attaques contre ces derniers en considérant la confidentialité, l’intégrité et la dispo-nibilité des données et des sous-systèmes. Ils suivent en cela le modèle de menaces en cybersécurité défini par [9] et présentent des diagrammes en bloc pour modéliser le drone. Les moyens de communication ne sont toutefois pas identifiés séparément : les auteurs considèrent que ces deniers sont englobés dans tous les modules d’un drone et que tout signal de contrôle ou de donnée, toute commande entrante ou sortante passent nécessairement par eux.
Les communications dans un système à drones ont une topologie en point-à-point ou éventuellement en étoile lorsque plusieurs drones sont en lien avec une seule station sol. On classe généralement les flux de données échangées selon les catégories suivantes :
— Command and Control (C2) depuis la station de contrôle du drone vers ce dernier ;
— La télémétrie depuis le drone vers la station ;
— Données de mission a priori dans les deux directions.
Les auteurs évaluent alors la probabilité et l’impact de chaque menace pesant sur les éléments identifiés. Le risque est défini et calculé comme le produit de la probabilité et de l’impact. Les menaces identifiées et leur criticité sont données dans le Table 2.1. Celles qui ont été classées comme non critiques ont été considérées soit peu vraisemblables, soit conduisant à des conséquences avec un faible impact, soit les deux.
La contribution présentée dans [10] complète cette première étude en listant toutes les attaques qui ont été implémentées, soit sur des systèmes de drones réels soit en simulation. Bien que les attaques listées visaient des drones militaires, les mêmes attaques atteindraient vraisemblablement leur but sur de petits drones com-merciaux. Une part importante de ces attaques visaient le signal Global Positionning System (GPS) par brouillage ou par usurpation. Mais approximativement la moitié concerne les flux de communication, comme cible ou bien comme vecteur de l’at-taque. L’étude liste également les vulnérabilités du drone Bebop pour lequel une exploitation a été mise en œuvre avec succès :
— attaque par dépassement de mémoire tampon conduisant à l’arrêt du logiciel après l’envoi d’une requête de prise de contrôle du drone dont l’entrée dans le fichier JSON comptait environ mille caractères ;
— attaque en déni de service ayant conduit à l’arrêt du logiciel après l’envoi en parallèle d’une multitude de ces mêmes requêtes JSON (environ un millier) ;
— empoisonnement du tampon ARP conduisant à l’atterrissage du drone après que le contrôleur du drone ait été déconnecté lorsque les données ont été émises vers l’attaquant ;
— contrôle et modification de la trajectoire du drone en exploitant des données partagées pour tromper le système anticollision.
Les auteurs proposent une taxonomie complétée s’appuyant sur une précédente étude sur les véhicules autonomes [11]. Ils allouent enfin les attaques présentées précédemment à la taxonomie proposée et montrent ainsi que la plupart d’entre elles ciblent le signal GPS. Il pointent toutefois le manque de recherches sur les attaques sur les moyens de communication.
Bien que la cible de ces attaques soient les applications embarquées, le vecteur utilisé exploite souvent les faiblesses du réseau. De plus, si aucune barrière ne vient limiter ce qu’un attaquant peut faire sur le réseau, chaque vulnérabilité se retrouve exposée et facilement accessible.
On peut également lister [12] et [13] où les auteurs présentent plusieurs mises en œuvre d’attaques sur des drones commerciaux, dont certaines ciblent précisément le réseau :
— des-authentification sur le wifi ;
— injection de commandes pour prendre le contrôle du drone en inondant ce dernier avec des commandes émises par l’attaquant ;
— accès non autorisé, où l’attaquant se connecte au serveur telnet du drone, ce dernier étant exécuté en tant que super-utilisateur et ne demandant aucun mot de passe, permettant ainsi à l’attaquant de mener un large éventail d’attaques (téléversement de fichiers vérolés sur le drone, arrêt de processus, démarrage de logiciels malveillants ou de portes dérobées) ;
— empoisonnement de la mémoire tampon ARP ;
— déni de service en exploitant une vulnérabilité dans le protocole applicatif similaire au vol de session TCP [14].
Chacune de ces attaques est, soit liée au réseau (empoisonnement du cache ARP par exemple), soit la conséquence d’une conception défaillante. Certaines de ces faiblesses pourraient être évitées si le système de drone avait un meilleur contrôle sur son propre réseau, par exemple en authentifiant les communications et en leur associant une forme d’autorisation.

L’essaim de drones : un système multi-agents

En comparaison avec un système mettant en œuvre un drone isolé et sa station sol, l’essaim de drones constitue un système multi-agents et met en jeu d’autres formes de communication. Bien que cette thèse n’aborde pas ce champ de recherche et que les solutions étudiées ne dépendent pas des données transportées, il parait pertinent de considérer qu’une partie au moins des communications entre drones sera vraisemblablement liée à la mise en œuvre d’une telle architecture.
Les communications dans un système multi-agents suivent des schémas diﬀérents des communications point-à-point évoquées précédemment : des communications entre drones sont nécessaires pour résoudre les diﬀérents problèmes inhérents aux systèmes multi agents et à leur organisation [15]. On peut citer l’allocation de tâches ou le consensus qui donnent lieu à des protocoles spécifiques.
L’exemple de l’allocation de tâche a conduit à la définition d’un protocole de contrat [16] ou d’enchères. Dans ce protocole, chaque agent ayant une tâche à confier, émet une demande à tous les agents susceptibles de remplir cette tâche, attendant d’eux qu’ils fassent une proposition chiﬀrée (l’unité de prix dépend du contexte) afin de pouvoir prendre une décision et allouer la tâche au mieux disant.
Un protocole de consensus revient à trouver une valeur commune entre les diﬀé-rents agents et nécessite également des communications entre drones. La vitesse de convergence de ce protocole dépend de la topologie du réseau.
La diﬀusion vers les autres nœuds prend généralement l’une des formes de com-munication suivantes [17] : la diﬀusion (broadcast ou multicast) lorsque cette forme de transmission est disponible ; le tableau noir (blackboard) où un nœud est res-ponsable de la retransmission des données vers ceux qui l’ont demandé et sinon, la communication point-à-point.

La sécurité dans un système multi-agents

Les systèmes multi-agents mettent en œuvre des architectures qui les exposent à des risques spécifiques. Il s’agit pour la plupart de risques rencontrés fréquemment au niveau applicatif. La recherche liée à la sécurité et aux systèmes multi agents a pris principalement deux directions : l’utilisation de systèmes multi-agents pour apporter de la sécurité d’une part, et la recherche de solutions pour sécuriser les échanges au sein du système d’autre part. La première approche n’étant pas dans le périmètre de cette thèse, nous nous focaliserons sur la seconde.
Les auteurs dans [18] recensent les principales menaces et exigences de sécurité selon les caractéristiques suivantes d’un système multi-agents :
— la conscience de l’environnement (situatedness) où l’origine de l’information doit être vérifiable ;
— l’autonomie n’est assurée qu’à condition de maîtriser l’accès aux agents ;
— la sociabilité qui repose avant tout sur la sécurité des moyens de communica-tion ;
— la mobilité des agents qui peuvent passer d’un hôte à un autre, exposant ainsi le système à l’injection d’agents malveillants ou la corruption d’un agent par un hôte malintentionné ;
— la coopération qui peut amener à la divulgation d’informations sensibles (par exemple un état interne).
Il existe des solutions au niveau applicatif comme au niveau des systèmes d’ex-ploitation permettant de renforcer le niveau de sécurité. Il a été d’ailleurs proposé d’intégrer ces bonnes pratiques dans les systèmes multi agent pour atteindre un niveau de sécurité acceptable [19]. Mais la protection du réseau et des moyens de communication au sein d’un tel système reste une question centrale en particulier sur un réseau sans fil. En particulier, la première menace identifiée dans [20] est l’injection de code qui parait tout à fait applicable dans le cas des agents mobiles.

Réseaux et sécurité

Réseaux de drones

Dans le cadre de cette thèse, les communications au sein de l’essaim sont assu-rées par un réseau sans fil. Mais il existe diﬀérents types de réseaux avec diﬀérentes topologies : réseaux cellulaires, réseaux satellites, réseaux ad hoc. Nous n’excluons a priori aucune de ces solutions. Toutefois, les contraintes physiques liées à leur topologie peuvent limiter le spectre des missions confiées à l’essaim : limite de pro-pagation de la cellule si celle-ci est assurée par une infrastructure au sol, limite de propagation des signaux satellites, utilisation de multi-lien soit pour augmenter la disponibilité, soit pour augmenter le débit disponible.
On trouve également plusieurs classifications de réseaux ad hoc mobiles [21] selon les caractéristiques de ces mobiles en terme de vitesse de déplacement, de trajec-toire, de densité et conséquemment, de vitesse de changement de topologie au sein du réseau. Comme illustré dans la figure 2.1, on trouve tout d’abord les réseaux Mobile Ad Hoc Network (MANET) dans lesquels les mobiles sont supposés être des équipements personnels au sens large (téléphones, ordinateur portable). La vi-tesse de déplacement y est basse, il n’existe a priori pas de schéma particulier pour leur trajectoire et la densité est moyenne à élevée. Les Vehicular Ad Hoc Network (VANET) appliquent ces mêmes principes pour des véhicules sur une infrastructure routière. Les trajectoires sont donc bien plus contraintes, les vitesses plus élevées et la densité variable. Enfin on trouve les Flying Ad Hoc Network (FANET) qui regroupent l’ensemble des réseaux ad hoc où les mobiles peuvent voler. Bien qu’il existe un réseau de routes aériennes, qui pourraient contraindre les déplacements à l’image des VANET, les FANET considèrent généralement que les mobiles suivent des trajectoires liées à leur mission ou bien aux caractéristiques de vol, en particulier pour les aéronef à voilure fixe qui requièrent une vitesse minimale et n’autorisent pas les virages au delà de certaines limites. Cette dernière catégorie regroupe des si-tuation très variées et les caractéristiques retenues les concernant dépendent souvent du cas considéré par les auteurs : drones civils ou militaires, drones à voilure fixe ou tournante, mission d’exploration de transport de personnes et de marchandises, de guerre même… D’ailleurs d’autres appellations sont apparues pour désigner ces réseaux en particulier dans le cas de réseaux d’une flotte de drones. Ils sont alors parfois désignés sous l’appellation Unmanned Aerial Ad Hoc Network (UAANET) [22]. L’essaim représente certainement encore un cas particulier. En eﬀet, l’essaim représente une entité à part entière à laquelle on peut prêter une intention voir un comportement qui sont liés à la mission, au delà des comportements individuels de ses constituants. Si un individu peut à l’occasion s’extraire de l’essaim pour un temps et mener une mission en autonomie, la raison d’être de l’essaim vient de la collaboration des individus dans un but commun. Cette collaboration implique une communication déjà évoquée précédemment concernant les systèmes multi-agents. Mais cette notion d’essaim a également des implications sur les trajectoires des individus : elles ne sont plus indépendantes mais centrées sur l’essaim et sa mission. Il en résulte sans doute des caractéristiques spécifiques, moins en terme de vitesse ou de trajectoire que de densité et de vitesse de changement de topologie.
Cette spécificité est d’ailleurs indirectement confirmée au travers de certaines études sur les technologies sans fil adaptées à des équipes ou flottes de drones [4] où les auteurs confirment que le wifi répond aux exigences de débit et de délais pour de nombreuses applications ne requérant qu’un nombre limité de sauts.
Il existe diﬀérents protocoles mettant en œuvre un routage dynamique au sein d’un réseau ad hoc mobile [22]. Leurs principes et politiques de routages sont aussi divers que les mobiles qui constituent un tel réseau et il est diﬃcile d’en désigner un qui soit meilleur quelles que soient les hypothèses : proactifs comme par exemple Destination-Sequenced Distance Vector (DSDV) [23] et Optimized Link State Rou-ting (OLSR) [24], réactifs à l’exemple de Dynamic Source Routing (DSR) [25] et Ad hoc On-demand Distance Vector (AODV) [26], géographiques comme Greedy Per-imeter Stateless Routing (GPSR) [27], hybride ou hiérarchique. Les auteurs dans [28] comparent diﬀérentes approches sur une flotte de drones et concluent à une meilleure adaptation du protocole AODV à ces conditions d’évaluation.
Routage proactif
Les protocoles de routage proactifs sont très proches des protocoles de routage rencontrés dans les réseaux filaires. Leur principe est la propagation des informations de routage vers tous les nœuds du réseau, de manière indépendante des besoins réels applicatifs, d’où la notion de proactivité. Dans cette approche, chaque nœuds maintient donc en mémoire l’ensemble des routes disponibles et ces protocoles sont parfois désignés sous l’appellation de protocoles de routage basés sur des tables (table-driven) . On y retrouve les mêmes méthodes de dissémination et de calcul de route que pour le filaire (par exemple OSPF ou BGP) : vecteur distance ou état de lien.
Dans la méthode par vecteur distance, chaque nœud fournit à ses voisins sa propre table de relayage en indiquant la distance associée à chaque destination. Ainsi chaque nœud complète sa table avec les informations de ses voisins et est capable de choisir le plus court chemin. Cette méthode est basée sur l’algorithme de Bellman-Ford distribué. Cette méthode est eﬃcace dans le sens où il y a peu d’information redondante qui circule dans le réseau, mais les modifications topo-logiques engendrent des vagues de mise à jour et le temps de convergence de tels protocoles sont relativement longs, selon la profondeur du réseau. On trouve dans cette catégorie : DSDV.
Dans la méthode par état de lien, chaque nœud fournit l’état de ses liens avec son environnement direct à l’ensemble des nœuds du réseau. Chaque nœud reconstitue donc la topologie du réseau est peut alors appliquer un algorithme de recherche de l’ensemble des chemins les plus court : l’algorithme de Dijkstra. On en déduit aisément que ces protocoles sont plus consommateurs en ressources ce qui peut limiter la mise à l’échelle, mais sont généralement plus réactifs et on des temps de convergence inférieurs. On trouve dans cette catégorie : OLSR.
Ce dernier a été optimisé pour une utilisation sur un réseau ad hoc en hiérar-chisant les nœuds du réseau. Le protocole inclut ainsi la désignation de Multi Point Relays (MPRs) qui ont pour tâche de relayer les messages en diﬀusion (broadcast). De plus, ces nœuds ont la responsabilité de générer les états de lien avec la possibilité de se limiter aux liens avec d’autres MPR. L’arbre est ainsi élagué et la quantité d’information en est réduite.
Routage réactif
Contrairement aux précédents, les protocoles de routage réactifs ne cherchent à établir une route que lorsqu’elle est nécessaire. C’est donc au moment où une application initie un dialogue avec un autre nœud que la route doit être déterminée. Ce type de protocole est ainsi constitué de procédures de découverte et de maintien de routes.
L’établissement d’une route consiste en la recherche du destinataire par la dif-fusion d’un paquet protocolaire Route Request (RREQ). Ce paquet est retransmis de proche en proche jusqu’à arriver à la destination, qui répondra alors avec un paquet Route Reply (RREP). Enfin, le maintien des routes consiste à s’assurer que le prochain saut est capable de recevoir la transmission : acquittement par la sous couche MAC, réception de transmissions, etc. La mise à jour des routes suite à la perte de connectivité avec un voisin se fait au travers de l’émission de paquet Route Error (RERR).
Afin de garantir un routage fonctionnel quelle que soit la destination, il est primordial que chaque nœud ait l’opportunité de recevoir le paquet RREQ. Ce paquet étant émis en diﬀusion, chaque protocole prévoit toutefois un moyen de contrôler la profondeur de l’exploration (champ Time to Live (TTL) du protocole IP ou champ spécifique du protocole). L’exploration peut ainsi être réalisée par cercles s’élargissant au fur et à mesure de la recherche.
DSR est un exemple de protocole réactif. Il utilise le routage à la source. Autre-ment dit, l’algorithme de recherche de route retourne la route complète à l’émetteur et cette dernière est fournie dans chaque paquet à l’émission. Il n’est donc pas né-cessaire de maintenir une table pour ce protocole, mais chaque paquet contient les données de route restante vers la destination augmentant la quantité de données transmises.
AODV est un autre exemple de protocole réactif. En plus des paquets précédents, il définit un paquet Hello qui permet d’une part de surveiller la visibilité radio avec ses voisins, mais également de créer des routes vers les voisins directs sans recourir à la procédure de détection par RREQ. Le routage à la source n’étant pas utilisé ici, chaque nœud doit maintenir des tables le long des routes établies. C’est ce qui est fait lorsqu’un RREQ est diﬀusé au sein du réseau comme illustré dans la figure 2.2 : chaque nœud garde une entrée pour la route retour. Ces dernières sont utilisées pour relayer le paquet RREP vers la source. Au passage du RREP, chaque nœud crée également une route pour pouvoir relayer les paquets dans le sens voulu comme illustré dans la figure 2.3.
Enfin, il existe des protocoles dits hybrides qui combinent approche proactive et réactive.
Routage géographique
Dans ce type de routage, les nœuds sont capables de déterminer leur position géographique, par exemple au travers d’un système de navigation terrestre par satel-lite ou Global Navigation Satellite System (GNSS), et de la transmettre aux autres ou à un service centralisé de localisation. Ainsi, chacun connaît ou peut demander la position de tous les nœuds du réseau. Il est alors possible de déterminer le prochain nœud à qui transmettre un paquet : c’est le nœud qui me permet de me rapprocher le plus de la destination tout en restant dans ma couverture radio. Il est donc néces-saire de connaître la position des nœuds en visibilité radio. GPSR est un exemple de protocole géographique.
Attaques
La sécurité dans ces réseaux a été étudiée dans plusieurs travaux de recherche avec diﬀérentes approches. Les auteurs dans [29] classifient les attaques spécifique-ment au niveau du réseau entre passives et actives. Les passives consistent principalement en la captation des transmissions des mobiles et leur analyse et n’altèrent en rien le fonctionnement du réseau. Les attaques actives identifiées consistent en :
— privation du sommeil (sleep deprivation) par sollicitations licites mais répé-titives et prolongées conduisant à l’épuisement des batteries, par exemple en émettant continuellement des RREQ en AODV ;
— dégradation des performances du réseau, souvent par perte intentionnelle mal-veillante de paquets (malicious packet dropping) qu’elle soit totale ou partielle : un nœud intermédiaire dans le réseau détruit ou retarde des paquets au lieu de les retransmettre au plus vite au prochain saut le long des routes établies.
Elles peuvent être précédées par des attaques cherchant à corrompre les mécanismes impliqués dans le routage et nécessitent alors l’émission de requêtes ou de réponses par l’attaquant :
— trou noir ou gris (black hole ou gray hole) où le routage est corrompu par l’at-taquant qui émet des réponses aux requêtes de découverte (RREQ en AODV) pour faire partie d’un nombre important de routes, et ainsi pouvoir soit perdre une partie des paquets volontairement (variante gray hole) voir même l’en-semble des paquets (variante black hole) ;
— rushing où l’attaquant cherche à prendre de vitesse les autres nœuds afin de s’imposer comme nœud intermédiaire ;
— par imposture ou attaque sybil où l’attaquant se fait passer pour un autre nœud.
On peut également lister l’attaque par trou de ver (wormhole) [30]. Elle consiste à créer un tunnel entre deux points du réseau, créant ainsi un chemin plus court qui aura donc la priorité lors de l’établissement des routes. Cette attaque peut être menée par simple rejeu des paquets de contrôle entre les deux extrémités du tunnel. L’attaque est donc une altération du routage qui peut mener soit à une dégradation des performances du réseau, soit à la divulgation d’informations.
Diverses approches ont été proposées pour répondre à ces attaques : le renforce-ment des protocoles présentant des faiblesses [22] avec de nombreuses propositions comme Secure AODV (SAODV) [31], Secure Eﬃcient Ad hoc Routing (SEAR) [32] par exemple, ou la détection de ces attaques [29].
SAODV permet l’authentification des messages de contrôle par l’utilisation de signatures et de chaînes de hachage. Ainsi, les champs statiques comme les adresses IP sont signés et ainsi vérifiés lors de la réception du paquet. Les champs mutables sont protégés par une chaîne de hachage dont la fonction n’est a priori connue que par les nœuds légitimes du réseau. L’utilisation de ce protocole interdit la participation de nœuds illégitimes au routage dans le réseau. Il est toutefois sensible aux attaques de type trou de ver.
Les auteurs dans [33] proposent le protocole Secure UAV Ad hoc routing Protocol (SUAP) qui reprend les principes et les bonnes propriétés du protocole SAODV en ajoutant des mécanismes de vérification supplémentaires pour contrer les attaques wormhole. Ce mécanisme vérifie la corrélation entre le nombre de sauts le long de la route et la distance relative entre deux nœuds. Il nécessite une synchronisation au sein du réseau qui est rendue possible par l’utilisation de systèmes de géolocalisation comme par exemple Galiléo. Les performances de ce protocole permettent l’échange des données temps réel avec une qualité de service acceptable.

Table des matières

1 Introduction
1.1 Les drones
1.2 Les essaims de drones
1.3 Sécurité et sûreté
1.4 Les communications de drones
1.5 Contributions
1.6 Plan du mémoire
2 État de l’art
2.1 Drones et essaims
2.2 Réseaux et sécurité
2.3 Apprentissage automatique
2.4 Conclusion
3 Architecture
3.1 Solutions proposées
3.2 Émulation
3.3 Mesures de performance
3.4 Synthèse
4 Application à la sécurité
4.1 Caractérisation des menaces
4.2 L’architecture face aux menaces
4.3 Détection d’attaques au sein du réseau
4.4 Performances
5 Conclusion
5.1 Travaux réalisés
5.2 Futurs travaux
Bibliographie
Liste des acronymes