État de l’art de la sécurité des systèmes avioniques

État de l’art de la sécurité des systèmes avioniques

Selon le US-CERT , le nombre d’attaques informatiques est en forte augmentation depuis 2006 [usc12]. Cette augmentation peut s’expliquer par deux raisons : la première est la complexité des systèmes actuels qui est de plus en plus élevée et donc plus difficile à gérer [Lab12] ; la deuxième raison est la simplicité d’utilisation d’outils automatiques d’attaque, maintenant accessibles aux débutants. Ces outils peuvent par exemple être utilisés pour réaliser des attaques de type Distributed Denial-of-Service . A titre d’exemple, le groupe de pirates Anonymous a lancé une série d’attaques en janvier 2012 après la fermeture du site de partage Megaupload, ce qui a rendu indisponible de nombreux sites Internet [Can12]. Un autre exemple d’attaque de plus grande envergure est celle d’août 2013 qui a touché la Chine en bloquant les accès à une grande partie des sites Internet Chinois [01N13]. Avec la même facilité, les attaques contre des applications Web sont aussi possibles avec des outils tels que WebScarab [OWA13]. Ces outils en libre circulation sont performants et permettent de lancer des attaques contre n’importe quel système distant. Il s’agit de programmes malveillants qui peuvent endommager de façon catastrophique les systèmes ciblés : accès, modification de données confidentielles; espionnage du système (keylogger) ; interruption de services (Denial-of-Service) ; exécution de virus ou rootkit ; attaque par force brute pour obtenir des mots de passe ; etc.

Les systèmes embarqués avioniques peuvent également être ciblés par ces attaques. Il est donc important de les protéger efficacement contre ces malveillances. Une attaque informatique visant un système avionique peut avoir de graves conséquences comme des pertes matérielles voire des pertes humaines. Afin d’éviter l’occurrence de défaillances dans les systèmes avioniques, des mécanismes de tolérance aux fautes sont utilisés (redondance, votes majoritaires, etc.). Cependant, ces mécanismes sont efficaces pour des défaillances d’origine accidentelle mais ils ne sont pas forcément efficaces face à des attaques (autrement dit, face à des fautes d’origine intentionnelle). Il est donc nécessaire de considérer aussi d’autres moyens de protection, spécifiquement développés pour faire face aux fautes intentionnelles que sont les attaques informatiques. Et même si de tels moyens sont déjà utilisés dans les avions aujourd’hui, ils ne sont pas dans la même état de maturité que les mécanismes de tolérance aux fautes accidentelles. De plus, les architectures des systèmes embarqués avioniques évoluant, les menaces considérées évoluant également, il est donc fondamental d’améliorer ces mécanismes et de les adapter aux nouvelles architectures.

Systèmes avioniques

Le terme architecture avionique représente l’ensemble des matériels et logiciels embarqués à bord de l’avion, qui assurent diverses fonctions telles que le traitement des informations provenant des capteurs, le pilotage automatique, la gestion du niveau de carburant, les échanges de messages avec l’opérateur au sol, pendant le vol, etc. Les architectures avioniques occupent une place non négligeable dans le coût des avions modernes (de l’ordre de 33% du coût total [pip09]).

Architecture fédérée

Historiquement, dans les systèmes avioniques, chaque fonction de contrôle disposait de ses propres ressources matérielles (représentées par une machine ou un calculateur) pour son exécution . Ces dispositifs dédiés sont très souvent répliqués pour la tolérance aux fautes et peuvent varier d’une fonction à l’autre. Il en résulte ainsi une architecture hétérogène et faiblement couplée, où chaque fonction peut opérer de manière quasi indépendante vis-à-vis des autres fonctions. Une telle architecture est qualifiée de fédérée. Par exemple, la construction des Airbus A330 et A340 repose sur ce type d’architecture. Les équipements numériques mettant en œuvre certaines des fonctions à bord sont reliés par des bus mono-émetteur. Un avantage majeur des architectures fédérées, en plus de leur simplicité, est la minimisation des risques de propagation d’erreurs qui peuvent survenir lors de l’exécution d’une fonction au sein du système. Cela assure une meilleure disponibilité du système global dans la mesure où une fonction défaillante peut éventuellement être isolée sans avoir recours à un arrêt complet du système. Cette caractéristique inhérente aux architectures fédérées est primordiale dans des systèmes critiques comme ceux qui sont embarqués dans les avions. Un autre avantage des architectures fédérées est leur hétérogénéité. En effet, les types de machines utilisées peuvent varier d’une fonction à l’autre au sein du même système. Cela permet l’utilisation de machines ayant des puissances variables.

Cependant, cette vision classique de systèmes fédérés présente des inconvénients liés à une forte dépendance entre le logiciel et le matériel que nous résumons dans les points suivants :
• La communication entre systèmes dépend des applications et également du matériel d’exécution. Toute mise à jour d’une entité logicielle implique une modification importante dans le mécanisme de communication, entraînant souvent la modification des autres entités logicielles pour maintenir une bonne interopérabilité.
• Le matériel utilisé dans les applications avioniques est très hétérogène. En effet, chaque application possède ses propres contraintes fonctionnelles, et est exécutée sur un matériel qui lui est dédié. Assurer la maintenance matérielle dans ces conditions est une tâche fort coûteuse, d’un point de vue économique.
• La durée de vie d’un avion est de l’ordre de plusieurs dizaines d’années (25-30 ans, voire plus). Cette durée de vie est longue relativement à la durée de vie d’un matériel. En effet, vu les avancées technologiques actuelles, un matériel devient obsolète au bout de quelques années seulement. Dans de nombreux cas, le matériel planifié durant la conception peut même devenir obsolète au moment de la construction de l’appareil. De plus, même si ce matériel est mis à jour, il faut bien s’assurer de la portabilité du logiciel qui n’a pas été originellement développé pour ce nouveau matériel. Cette tâche s’avère particulièrement coûteuse en raison du lien étroit qui existe entre le logiciel et le matériel dans un système fédéré.

Architecture IMA

Dans les années 1990, sous l’impulsion de la commission européenne, des projets européens de recherche tel que PAMELA, NEVADA et VICTORIA [PAM01, NEV01, VIC01], ont permis l’émergence d’une autre vision dans la conception des systèmes avioniques ; celle-ci a pour but de pallier les insuffisances des architectures fédérées en proposant de dissocier les composants logiciels des composants matériels (dans les systèmes fédérés). Ce type d’architecture est qualifié de modulaire intégré, plus communément appelé IMA (Integrated Modular Avionics) [ARI08]. Le principe de l’architecture IMA [Mor91] est de répartir dans tout le volume de l’appareil un ensemble de ressources (calcul, mémoire, communication), qui pourront être partagées par plusieurs applications, qui accompliront les différentes fonctions du système avionique. Des exemples d’avions adoptant la solution intégrée sont l’Airbus A380 ou le Boeing B777. L’approche IMA présente trois principaux avantages :
• Réduction du poids grâce à un plus petit nombre de composants matériels et un câblage réduit, ce qui augmente l’efficacité énergétique ;
• Coût de maintenance réduit par l’utilisation de modules génériques ;
• Réduction des coûts de développement par l’utilisation de systèmes standardisés et de COTS (Commercial-Off-The-Shelf).

Cette organisation du système présente une plateforme unique pour plusieurs applications logicielles avioniques qui permet d’économiser les ressources, contrairement aux architectures fédérées. Par la même occasion, le coût de réalisation peut être limité de façon raisonnable. La plateforme consiste en un réseau temps-réel distribué, permettant à différentes applications de s’exécuter en parallèle. Cependant, elle introduit un risque de propagation d’erreur. Par exemple, une fonction en dysfonctionnement peut monopoliser le système de communication ou envoyer des commandes inappropriées, et pour chacune des fonctions il est difficile de se mettre à l’abri d’un tel comportement. Il est donc indispensable qu’une telle architecture assure un partage de ressource sûr entre les applications : le mécanisme dit de partitionnement [ARI08]. Par ce moyen, une ou plusieurs applications regroupées au sein d’un même module peuvent s’exécuter de manière sûre en parallèle (deux fonctions quelconques prévues pour s’exécuter dans un même module ne peuvent en aucun cas interagir l’une avec l’autre).

De manière pratique, l’architecture physique est décrite par la norme ARINC 651. Les ressources sont regroupées dans des modules génériques appelés LRM (Line Replaceable Module), qui sont à leur tour regroupés dans des étagères, la communication au sein de ces étagères étant réalisée avec des bus spéciaux, généralement de type ARINC 659. Les modules peuvent être de trois types :
• des modules cœurs qui sont ceux qui se chargent de l’exécution des applications;
• des modules d’entrée/sortie permettant la communication avec des éléments ne respectant pas l’architecture IMA ;
• des modules passerelles servant à la communication entre étagères (l’architecture IMA n’impose pas de moyen de communication spécifique entre ses différents composants).

Ce partitionnement est classé en partitionnement spatial (par exemple, la gestion de la mémoire) et temporel (la gestion des ressources temporelles par le CPU) [Rus99]. Le partitionnement spatial des applications repose sur l’utilisation de composants matériels chargés de gérer la mémoire pour empêcher toute corruption de zones mémoires adjacentes à une zone en cours de modification. Le partitionnement temporel dépend des fonctionnalités attendues de l’ensemble (par exemple, on aura besoin d’exécuter plus souvent des fonctions qui s’occupent du rafraîchissement de paramètres critiques). Avec ce partitionnement, des tranches de temps pour l’exécution des applications et l’exécution du noyau du système sont allouées statiquement. Afin de déterminer la durée des tranches de temps, des études d’estimation du pire cas du temps d’exécution (WCET ) sont réalisées de façon dynamique (sur le matériel ou sur simulateur) ou de façon statique (sans exécution) [Pua11]. Les méthodes d’estimation du WCET ne sont définies dans aucune norme avionique, il faut donc choisir la méthode appropriée en fonction de ses besoins. Il faut également prendre en compte l’utilisation de plusieurs cœurs dans les processeurs aujourd’hui car les multi-cœurs tendent à remplacer les mono-cœurs [Gen13, ZY09] ce qui change considérablement les calculs des durées d’exécution. La méthode dynamique d’évaluation du WCET s’appuie sur l’exécution de l’application sur le matériel ou sur simulateur et la mesure du temps d’exécution entre le début et la fin d’exécution. Le comportement de l’application peut dépendre des entrées/sorties. Il est donc nécessaire de générer ces informations. Une couverture exhaustive du domaine des entrées serait bien sûr souhaitable mais le risque d’explosion combinatoire est élevé. En général, il s’agit donc de trouver un compromis entre la couverture des entrées générées et la précision du WCET que l’on souhaite obtenir. Un outil peut être utilisé pour mesurer le WCET automatiquement. Par exemple, RapiTime permet de créer des traces d’exécution et supporte la norme DO-178B (norme avionique sur laquelle nous reviendrons dans la suite de ce chapitre). La méthode statique d’évaluation du WCET calcule la durée d’exécution en analysant la structure du programme. Différentes techniques d’analyse existent : analyse des flux (Flow analysis), calcul avec arbre (Tree-based computation), énumeration des chemins, (IPET, Implicit Path Enumeration Technique), analyse de bas niveau (Low-level analysis). Mais en pratique, ces durées d’exécution seront forcément dépendantes du matériel et des exécutions passées. Elles doivent être calculées dans toute la chaîne d’exécution, c’est-à-dire qu’il faut être capable de connaître le chemin d’exécution exact ainsi que chaque type de données à traiter (entier, chaînes de caractères, etc.). De plus, les durées doivent être calculées pour tous les chemins d’exécution. Des outils sont également disponibles pour une méthode d’estimation statique, nous pouvons citer Bound-T , AbsInT (notamment utilisé pour l’A380).

Table des matières

Introduction générale
Chapitre 1 État de l’art de la sécurité des systèmes avioniques
1.1 Systèmes avioniques
1.1.1 Architecture fédérée
1.1.2 Architecture IMA
1.2 Sûreté de fonctionnement et le développement logiciel
1.2.1 Quelques définitions de la sûreté de fonctionnement
1.2.2 Tolérance aux fautes dans le domaine avionique
1.2.3 Développement de logiciels critiques sûrs
1.2.4 Sécurité-immunité dans les standards avioniques
1.3 Problématique de la sécurité-immunité dans les systèmes avioniques
1.3.1 Connectivité accrue entre les applications
1.3.2 Partage de ressource entre applications
1.3.3 Utilisation de composants COTS
1.3.4 Conclusion
1.4 Différentes approches pour améliorer la sécurité-immunité
1.4.1 Intégration de mécanismes de sécurité adaptés
1.4.2 Utilisation de méthodes formelles
1.4.3 Analyse de vulnérabilités dans le processus de développement
1.5 Analyse de vulnérabilités dans les systèmes critiques embarqués
1.5.1 Approche par boîte blanche
1.5.2 Approche par boîte noire
1.6 Contribution de cette thèse
Chapitre 2 Caractérisation des attaques des systèmes embarqués
2.1 Attaques visant les fonctionnalités de base
2.1.1 Attaques ciblant le processeur
2.1.2 Attaques ciblant la gestion de la mémoire
2.1.3 Attaques ciblant les communications
2.1.4 Attaques ciblant la gestion du temps
2.1.5 Attaques ciblant la gestion des processus
2.1.6 Attaques ciblant l’ordonnancement
2.1.7 Attaques ciblant les mécanismes cryptographiques
2.1.8 Attaques ciblant les fonctions ancillaires
2.1.9 Conclusion
2.2 Les attaques ciblant les mécanismes de tolérance aux fautes
2.2.1 Détection d’erreurs
2.2.2 Recouvrement d’erreurs
2.2.3 Traitement de fautes
2.3 Contexte et hypothèses d’attaques
2.3.1 Attaquants
2.3.2 Hypothèse d’attaque : une application non critique malveillante
Chapitre 3 Mise en œuvre de la méthodologie
3.1 Système expérimental d’Airbus : noyau et partitions
3.1.1 Hypothèses concernant la partition malveillante
3.1.2 Phases d’exécution d’une partition
3.2 Architecture du P4080
3.2.1 Structure des cœurs e500mc
3.2.2 Contrôleur d’interruption
3.2.3 DataPath Acceleration Architecture (DPAA)
3.2.4 Démarrage sécurisé
3.3 Présentation de la plateforme
3.3.1 Observation du noyau et des applications
3.3.2 Configuration de la plateforme d’expérimentation
3.4 Attaques ciblant la gestion de la mémoire
3.4.1 Attaques ciblant le Security Engine
3.4.2 Attaques ciblant le Run Control/Power Management
3.5 Attaques ciblant les communications
3.5.1 Attaques ciblant les communications AFDX
3.5.2 Attaques ciblant les IPC
3.6 Attaques ciblant la gestion du temps
3.6.1 Première attaque : utilisation des interruptions
3.6.2 Seconde attaque : modification de la configuration d’une partition
3.6.3 Utilisation conjointe des deux attaques
3.7 Attaques ciblant les mécanismes de tolérance aux fautes
3.7.1 Réalisation du programme Crashme
3.7.2 Instrumentation du noyau
3.7.3 Résultats obtenus
Conclusion générale

Lire le rapport complet