Analyse de vulnérabilités de systèmes avioniques embarqués

Analyse de vulnérabilités de systèmes avioniques
embarqués

Développement de logiciels critiques sûrs

 Le développement logiciel des applications avioniques est réalisé en respectant un ensemble de normes et recommandations qui permettent de développer des systèmes critiques (logiciels et matériels) et de fournir des moyens de certifications. Le processus d’évaluation de la sécurité d’un système avionique a pour but de vérifier la conformité de la conception avec les exigences de navigabilité spécifiées par les autorités. Ces autorités sont l’EASA (European Aviation Safety Agency) pour l’Europe et la FAA (Federal Aviation Administration) pour les Etats-Unis. Les organismes suivants sont responsables de la rédaction des recommandations et normes : SAE (Society of Automotive Engineers), 16 RTCA (Radio Technical Commission for Aeronautics) pour les Etats-Unis et EUROCAE (European Organisation for Civil Aviation Equipment) pour l’Europe. La SAE8 fournit les documents de type ARP (Aerospace Recommended Practice) ; la RTCA Inc.9 fournit les documents de type DO et l’EUROCAE10 fournit les documents de type ED. Nous pouvons également citer l’ARINC11 (Aeronautical Radio INCorporated qui est une entreprise créée en 1929 par plusieurs compagnies aériennes et constructeurs aéronautiques américains et rachetée en août 2013 par Rockwell Collins. Elle définit de nombreuses recommandations pour huit types d’industries : l’aviation, les aéroports, la défense, le gouvernement, les services de santé, les réseaux, la sécurité ainsi que les transports. L’ARINC a notamment conçu dès 1978, le système ACARS (Aircraft Communications Addressing and Reporting System) qui permet d’effectuer encore aujourd’hui des communications entre les stations au sol et les avions en utilisant la radio (communication VHF12 ou HF13) ou le satellite. Les organismes européens et américains travaillent en collaboration pour réaliser des documents équivalents, c’est pour cette raison que les noms des recommandations contiennent deux références différentes (DO et ED). Ces recommandations ARP, DO et ED sont devenues des normes avioniques au fil des années. Quatre principales normes sont utilisées pour le développement logiciel critique. L’ARP 4754A/ED-79 (Guidelines for Development of Civil Aircraft and Systems) décrit un processus de développement des systèmes avioniques et inclut des études pour permettre leur certification. L’ARP 4761/ED-135 (Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment), quant à elle, décrit un ensemble de méthodes d’analyse et d’évaluation de la sécurité-innocuité des systèmes avioniques à des fins de certification. Ces deux normes sont en général utilisée conjointement. Le DO-178B/ED-12C (Software Considerations in Airborne Systems and Equipment Certification) définit les contraintes de développement liées à l’obtention de la certification de logiciel avionique et le DO-254/ED-80 (Design Assurance Guidance for Airborne Electronic Hardware) est son pendant pour le développement d’équipement matériel électronique. La figure 1.5 présente les liens entre ces différentes normes et recommandations.

Guide de développement pour l’aviation civile – ARP 4754A

La recommandation ARP 4754A (datant de décembre 2010) définit les processus de développement des avions civils et des systèmes critiques. Elle intègre notamment : la détermination et validation des exigences, le processus de certification, la gestion de la configuration, et la vérification de l’implémentation. Elle est utilisée conjointement avec l’ARP 4761 “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment” qui définit les méthodes d’évaluation de la sécurité-innocuité des systèmes critiques et permet d’assigner les niveaux d’assurance de conception. La recommandation ARP 4754A permet de valider que les exigences sont correctes et complètes avec des méthodes de haut niveau sans faire de différences entre le logiciel et le matériel (qui est faite par ailleurs dans les recommandations DO-178C pour le logiciel et DO-254 pour le matériel).

Méthodes d’évaluation de la sûreté pour l’aviation civile – ARP 4761

 Cette recommandation ARP 4761 définit plusieurs méthodes et techniques d’analyse de sûreté de fonctionnement sur le système, dont : Functional Hazard Analysis (FHA), Preliminary System Safety Analysis (PSSA), System Safety Analysis (SSA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA). Les systèmes avioniques peuvent avoir des niveaux de criticité différents suivant leurs applications et donc leurs 18 développements imposent plus ou moins de vérifications/recommandations. L’analyse de risques fonctionnels (FHA) permet d’identifier les défaillances potentielles du système et les conséquences de ces défaillances en attribuant un niveau de DAL (Design Assurance Level) auquel est associé une probabilité par heure qu’une défaillance ne survienne. Les cinq niveaux de DAL sont les suivants : • Niveau A : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème catastrophique, la sécurité du vol ou de l’atterrissage est compromis et le crash de l’avion possible. • Niveau B : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème majeur entraînant des dégâts sérieux voire la mort de quelques occupants. • Niveau C : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème sérieux entraînant par exemple une réduction significative des marges de sécurité ou des capacités fonctionnelles de l’avion. • Niveau D : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème ayant des conséquences mineures sur la sécurité du vol. • Niveau E : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème sans effet sur la sécurité du vol. Pour le niveau DAL A (niveau catastrophique), il est considéré comme atteint si la probabilité d’activation est inférieur à 1× 10−9 par heure, alors que pour le niveau DAL D (niveau mineur), le seuil maximum est de 1 × 10−3 par heure, et pour le niveau E, aucun seuil n’est imposé. L’analyse PSSA quant à elle, examine les conditions de défaillance de la FHA et décrit comment la conception du système devra respecter les engagements définis. Plusieurs techniques peuvent être utilisées pour le PSSA comme des arbres des fautes (FTA), des chaînes de Markov, etc.

LIRE AUSSI :  Etude et mise en place d’un réseau d’interconnexion d’une entreprise multi-sites

Table des matières

Table des figures
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ès
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
Chapitre 4 Protections des systèmes avioniques contre les malveillances
4.1 Contre-mesures spécifiques à notre plateforme d’expérimentation
4.1.1 Attaques ciblant la gestion de la mémoire
4.1.2 Attaques ciblant les communications
4.1.3 Attaques ciblant la gestion du temps
4.1.4 Attaques ciblant les mécanismes de tolérance aux fautes
4.2 Contre-mesures génériques
4.2.1 Attaques ciblant le processeur
4.2.2 Attaques ciblant la mémoire
4.2.3 Attaques ciblant les communications
4.2.4 Attaques ciblant la gestion du temps
4.2.5 Attaques ciblant la cryptographie
4.2.6 Attaques ciblant les fonctions ancillaires
4.2.7 Attaques ciblant les mécanismes de tolérance aux fautes
4.2.8 Recommandation aux développeurs
4.2.9 Analyse statique
4.2.10 Analyse dynamique
4.3 Architecture sécurisée pour la gestion d’un périphérique partagé
4.3.1 Principe
4.3.2 Virtualisation matérielle d’un périphérique
4.3.3 Utilisation de SR-IOV dans un contexte avionique embarqué
Conclusion générale
Bibliographie

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *