Soutenance mémoire
L’avionique modulaire intégrée (IMA)
Le terme « système avionique » désigne les éléments électroniques et informatiques embarqués à bord d’un aéronef. Ces éléments assurent différentes fonctionnalités parmi lesquelles on peut par exemple citer le traitement des informations provenant des capteurs, le pilotage automatique, la gestion du carburant, les communications bord/sol, ou le contrôle des moteurs. Ces équipements représentent une part importante des coûts de développement d’un aéronef, de l’ordre de 30 à 35% pour un avion commercial [PIPAME 2009].
D’une architecture fédérée à une architecture IMA
Historiquement, les systèmes avioniques étaient construits selon une architecture dite fédérée , c’est-à-dire qu’une fonction était hébergée sur un calculateur dédié (i.e., un matériel spécifique). Cette architecture permet une gestion simple et efficace des équipements pour répondre aux exigences de sûreté du milieu avionique. Elle facilite notamment la redondance des équipements et minimise les dépendances entre fonctions, ce qui limite d’une part les risques de propagation d’erreurs, et qui permet d’autre part d’isoler les fonctions défaillantes du reste du système [Gatti 2016]. Cependant, ce type d’architecture implique une forte dépendance entre le matériel et le logiciel, ce qui induit par exemple des systèmes de communication très dépendants des applications mais aussi du matériel, un parc de matériel très hétérogène au sein d’un même aéronef, et d’importants coûts de mise à jour, aussi bien logicielle que matérielle.
L’architecture IMA propose une nouvelle vision des systèmes avioniques en introduisant une ségrégation entre les composants logiciels et le matériel, ce qui permet de mutualiser les ressources matérielles de l’avion pour plusieurs fonctions avioniques. Cette nouvelle architecture a été mise en œuvre sur les programmes Rafale, Boeing 777, Falcon 7X, A380, A400M, Boeing 787, et plus récemment sur l’A350. Les composants communs d’acquisition et de commande des fonctions 1 et 2 ont été mutualisés dans un même calculateur, qui effectue les traitements T1 et T2. Cette nouvelle architecture apporte plusieurs avantages, notamment la réduction du poids de l’avion (moins de composants matériels et moins de câbles), des coûts de maintenance réduits de par l’utilisation de calculateurs génériques, et des coûts de développement réduits par l’utilisation de systèmes standardisés et de COTS (Commercial Off-The-Shelf).
Principes fondamentaux de l’IMA
L’un des défis majeurs de l’IMA est sa capacité à garantir les mêmes propriétés de sûreté que pour une architecture fédérée. Pour ce faire, les calculateurs IMA doivent garantir un partitionnement spatial et temporel robuste entre les applications, c’est-à-dire qu’une application qui s’exécute sur un calculateur ne doit en aucun cas impacter une autre application indépendante de la première s’exécutant sur le même calculateur (ou le même réseau de calculateurs). Dans le cas des calculateurs IMA, cette propriété est vérifiée par deux principes décrits dans la norme Ces deux types de ségrégations sont réalisées à l’aide d’une configuration statique de ressources. Notons qu’une application (au sens fonction avionique) peut être composée de plusieurs partitions (au sens logiciel), auxquelles des ressources sont allouées de façon indépendante.
La ségrégation spatiale consiste à séparer physiquement les ressources allouées à chaque partition. Plus précisément, l’espace mémoire et les ports d’entrée/sortie (I/O) sont alloués statiquement à chaque partition. Si un calculateur possède 30 connecteurs I/O, il peut par exemple en réserver 10 à la partition P1, 5 à la partition P2, et 15 à la partition P3. S’il possède 100Mo de mémoire RAM, chaque partition se verra allouer un espace RAM qui est garanti à l’exécution par une unité de gestion mémoire ou MMU (Memory Management Unit).
La ségrégation temporelle consiste à partager une même ressource physique sur une durée prédéfinie. C’est le cas pour l’utilisation de la CPU, les calculateurs avioniques actuels étant des calculateurs mono-coeur . Une période de temps commune à l’ensemble des partitions d’un même calculateur, appelée MAF (MAjor Frame), permet d’orchestrer l’exécution des partitions sur une période donnée. Cette orchestration est ensuite répétée en boucle pendant toute la durée d’exécution du calculateur. Au sein de cette période (50ms dans l’exemple), chaque partition se voit allouer une durée et un séquencement. les partitions P1, P2 et P3 se voient allouer respectivement 10ms, 20ms, et 5ms toutes les 50ms.
Concernant l’utilisation du réseau ARINC 664 part 7 ou A664p7 (Aircraft Data Network, Part 7, Avionics Full-Duplex Switched Ethernet Network), une latence maximale est garantie par l’allocation de Virtual Link (ou VL) pour les partitions d’une part, et par la configuration des switchs formant le réseau d’autre part.
L’ARINC 653 (Avionics Application Standard Software Interface) spécifie la partie logicielle permettant le partitionnement temporel et spatial pour les systèmes d’exploitation temps-réel avioniques critiques. Elle définit notamment une interface applicative ou API (Application Programming Interface) composée de plusieurs catégories de services : la gestion des partitions, la gestion des processus, la gestion du temps, les communication inter-partitions, les communications intra-partitions, et la gestion des erreurs.
Acteurs impliqués
Plusieurs acteurs sont impliqués dans le cycle de vie d’une application, parmi lesquels les fournisseurs d’applications, le fournisseur de calculateurs, l’intégrateur calculateur, l’intégrateur système, l’avionneur, ou encore les compagnies aériennes.
Rôles des acteurs
Le fournisseur de calculateur développe un calculateur conforme à l’architecture IMA, doté d’un système d’exploitation temps-réel (RTOS) certifié (COTS ou propriétaire) et des outils associés. En particulier, il doit proposer les services décrits par l’ARINC 653. Le développement de la plateforme matérielle et du RTOS peuvent éventuellement être effectués par deux acteurs différents. Les fournisseurs d’applications sont en charge du développement logiciel des fonctions avioniques. L’intégrateur calculateur alloue les ressources des calculateurs disponibles aux différentes applications, suit leur développement, et vérifie l’intégration technique des applications sur les calculateurs. L’intégrateur calculateur ne vérifie donc pas les fonctionnalités des applications, mais seulement l’utilisation correcte des ressources qui leur ont été allouées. L’intégrateur système et l’avionneur sont en charge de l’intégration fonctionnelle inter-applications. Une fois l’aéronef en opération, c’est à la compagnie aérienne de prévoir et de réaliser les éventuelles mises à jour.
Interactions entre acteurs
Dans un premier temps, le fournisseur de calculateur développe un calculateur intégrant un RTOS répondant aux spécifications de l’ARINC 653 [Prisaznuk 2008]. Il édite un document appelé Domaine d’Usage qui décrit le cadre d’utilisation pour lequel le calculateur a été certifié. Ce document explicite aussi bien des règles de codage (ex : vérification des types, identifiants uniques, …) que des règles destinées à l’intégrateur calculateur (ex : nombre maximal de partitions supporté) ou à l’intégrateur système (ex : capacité réseau disponible). Ces règles sont vérifiées à différents niveaux, via des outils automatiques ou manuellement.
Une fois le calculateur disponible et les ressources globales de l’avion connues, l’intégrateur calculateur répartit ces ressources entre les différentes applications commandées par l’avionneur. Il fournit un Contrat d’insertion [Conmy 2003] à chaque fournisseur d’application, qui décrit formellement les ressources pouvant être utilisées par l’application (mémoire allouée, I/O alloués, partitions allouées). Chaque fournisseur développe ensuite son application selon cette allocation, et retourne à l’intégrateur calculateur un fichier téléchargeable. Ce fichier téléchargeable, appelé FLS (Field Loadable Software) est un ensemble de code compilé contenant à la fois le code applicatif de la partition avionique correspondante, mais aussi ses données de configuration. L’intégrateur calculateur récupère ces différents FLS et installe l’ensemble sur un calculateur pour vérifier la bonne intégration des applications les unes à côté des autres, et notamment le respect du Domaine d’usage. Cette intégration est uniquement technique, c’est-à dire que l’intégrateur calculateur vérifie uniquement le bon usage des ressources, pas les fonctionnalités des applications. Ces dernières ont été vérifiées au préalable par les fournisseurs d’application.
Un deuxième niveau de vérification fonctionnelle, plus global, est effectué lors de l’intégration système, puis lors de l’intégration avion. Cette vérification consiste notamment à vérifier le bon fonctionnement de l’ensemble des fonctions de l’avion, les unes avec les autres, par exemple lors d’essais en vol. Enfin, l’aéronef est livré à la compagnie aérienne, qui sera responsable de sa mise à jour tout au long de son cycle de vie. Ces mises à jour sont effectuées par des opérateurs de maintenance qualifiés, partout dans le monde.
Risques de sécurité et modèle de menace
Cette organisation, de par le grand nombre d’acteurs impliqués et leurs fortes interactions, présente plusieurs faiblesses du point de vue de la sécurité. En effet, la multiplication des acteurs (à titre d’exemple, un A350 peut compter jusqu’à 35 applications, et plus de 50 compagnies aériennes l’utilisent aujourd’hui ) implique une plus grande surface d’attaque. Si la menace d’un attaquant externe peut être potentiellement bloquée aux interfaces de l’avion avant d’atteindre les systèmes avioniques, une attaque interne pourrait avoir de graves conséquences sur la sûreté du vol. C’est le modèle de menace qui est considéré dans cette thèse. Plus particulièrement, on peut décrire deux scénarios impliquant un attaquant interne chez un fournisseur d’application, ou chez une compagnie aérienne :
1. la modification malveillante d’un FLS avant son envoi à l’intégrateur calculateur, et
2. la modification malveillante d’un FLS lors d’une mise à jour.
Dans les deux cas, on peut imaginer aussi bien un opérateur malveillant, l’utilisation d’un dispositif de stockage corrompu, ou l’utilisation d’un dispositif de communication altéré. D’autres scénarios relatifs à des attaques externes pourraient avoir le même type de conséquences, mais ne sont pas directement considérés dans cette thèse. La menace prise en compte ici est donc celle d’un FLS modifié de façon malveillante qui serait chargé sur un calculateur.
Dans une architecture aussi statique qu’une architecture avionique, la modification malveillante d’un applicatif devrait, selon toute vraisemblance, générer des modifications dans l’utilisation des ressources calculateur. Dans ce contexte, le rôle de l’intégrateur calculateur est primordial. Dans un premier temps, il partage la responsabilité d’assurer la ségrégation spatiale et temporelle entre applications avec le fournisseur de calculateur, ce dernier décrivant les règles du Domaine d’usage dont le premier doit assurer le bon respect par l’ensemble qu’il intègre. Ensuite, il doit également s’assurer que les applications n’ont pas d’interactions non prévues les unes avec les autres, et il constitue un point central par lequel tous les FLS transitent lors de la phase d’intégration. Son rôle est central, c’est donc le point de vue adopté dans cette thèse. L’une des difficultés de ce positionnement est la potentielle confidentialité des documents relatifs aux applications. En effet, il est rare que l’intégrateur calculateur possède des connaissances fonctionnelles sur les applications qu’il doit intégrer (spécifications, code source). Généralement, ses connaissances se limitent au FLS de l’application et au contrat d’insertion échangé précédemment. En pratique, la mise en oeuvre de l’approche proposée dans cette thèse pourrait être distribuée entre l’intégrateur calculateur, l’intégrateur système, et/ou l’avionneur.
|
Table des matières
Introduction
1 Contexte et concepts fondamentaux
1.1 Définitions
1.1.1 La sûreté de fonctionnement
1.1.2 La sécurité-immunité
1.1.3 L’écosystème avionique
1.2 L’avionique modulaire intégrée (IMA)
1.2.1 D’une architecture fédérée à une architecture IMA
1.2.2 Principes fondamentaux de l’IMA
1.2.3 Acteurs impliqués
1.3 Problématiques de sécurité dans l’avionique
1.3.1 Contexte actuel
1.3.2 Contraintes spécifiques à l’embarqué critique temps-réel
1.4 Objectifs de la thèse
2 État de l’art
2.1 La sécurité dans les systèmes avioniques
2.1.1 Les mesures de sécurité-innocuité
2.1.2 Les mesures de sécurité-immunité
2.2 Les systèmes de détection d’intrusion
2.2.1 Principe général et classification
2.2.2 Les données d’entrée
2.2.3 Les techniques de détection d’anomalie
2.2.4 L’évaluation des HIDS
2.3 Contributions de cette thèse
3 Approche générale de l’HIDS avionique
3.1 Vue générale de l’approche
3.1.1 Composants de l’approche
3.1.2 Domaine de Sécurité de l’Application
3.2 Description des composants
3.2.1 Analyse de sécurité statique
3.2.2 Modélisation du SDA
3.2.3 Validation du SDA
3.2.4 Détection d’anomalies
3.2.5 Confirmation d’attaque et investigation au sol
3.3 Définition de l’outil d’injection d’attaque
3.3.1 Vue d’ensemble
3.3.2 Composants de l’outil
3.3.3 Définition des opérateurs d’attaque
3.4 Conclusion
4 Implémentation de l’approche pour l’évaluation de l’efficacité de détection
4.1 Implémentation de l’approche
4.1.1 Environnement d’étude
4.1.2 Outil d’analyse de l’utilisation des ressources
4.1.3 Moniteur de SDA
4.1.4 Prétraitement des données
4.1.5 Modélisation du SDA
4.1.6 Injection d’attaque
4.1.7 Vérification du SDA
4.2 Implémentation de l’outil d’injection
4.2.1 Ajout de code
4.2.2 Contrôle de l’activation de la charge malveillante
4.2.3 Opérateurs d’attaque implémentés
4.2.4 Gestion de la campagne d’injection
4.3 Expérimentations
4.3.1 Processus d’évaluation de l’HIDS
4.3.2 Expérimentation 1 : pertinence de l’outil
4.3.3 Expérimentation 2 : efficacité de détection de l’HIDS
4.4 Conclusion
5 Implémentation de l’HIDS embarqué pour l’évaluation des performances
Conclusion
