Contexte scientifique d’élaboration pour un routeur embarqué de nouvelle génération 

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

Contexte scientifique d’élaboration pour un routeur embarqué de nouvelle génération

Dans ce chapitre, le routeur Sécurisé de Nouvelle Génération (SNG) est présenté : après avoir défini les réseaux avioniques et aéronautiques, notamment les couches liaison et réseau liées à l’élaboration de notre système, nous exposons les besoins ayant conduit au lancement de la thèse puis détaillons les exigences de développement du routeur SNG. Un accent particulier est mis sur les phases de certification et d’évaluation de la sécurité et de la sûreté du routeur SNG.

Introduction aux réseaux avioniques et aéronautiques par la couche liaison

Les réseaux avioniques ont beaucoup évolués depuis les premières interconnexions d’équipements électroniques embarqués formant des réseaux de communication de données en 1968 ([DO-136 1968]). Ils se sont progressivement peuplés avec toujours plus d’équipements utilisateurs de l’infrastructure de communication. Les standards ont évolué pour tenir compte de l’augmentation de l’utilisation des réseaux en appor-tant simultanément des débits de plus en plus élevés. La sûreté de fonctionnement est cependant toujours restée une contrainte forte, garantissant ainsi une robustesse très élevée des moyens de communication. Dans cette section nous énumérerons les principaux standards mis en œuvre à l’intérieur des avions commerciaux de trans-port de passagers de masse. Ensuite les moyens de communication sol-bord seront présentés.

Les standards et protocoles de communication embarqués

Les premiers équipements embarqués dans les avions étaient connectés en point-à-point, c’est-à-dire qu’une liaison unique reliait exactement deux systèmes. Les premiers réseaux avioniques mettant en œuvre plus de deux équipements sont ap-parus en 1968 avec le standard DO-136 [DO-136 1968] qui définit le format des premières communications air-sol de données.
Cette norme propose une technologie qui permet de relier un émetteur de données à des récepteurs (de 1 à 20) et permet des échanges à une vitesse de transmission de 12.5 kbps ou de 100 kbps. Les données sont encapsulées dans des doubles mots (32 bits, entête comprise). Sa simplicité, sa fiabilité et son déterminisme en ont fait l’un des protocoles les plus employés en avionique. Cependant, il est nécessaire d’installer un bus de données par émetteur, il est monodirectionnel, il est limité à 20 récepteurs et le débit est aujourd’hui jugé insuffisant pour les nouveaux usages qui sont de plus en plus gourmants en terme de débits.
Ainsi d’autres protocoles de communication furent élaborés pour pallier ces li-mitations. Le standard [MIL1553 1975] et sa dernière version MIL-STD-1553B [MIL1553B 1978] furent développés entre 1968 et septembre 1978 par l’armée améri-caine pour l’avion de combat F-16 Falcon[MIL1553w 2013]. Ils proposent un bus série asynchrone bidirectionnel géré par un contrôleur et interconnectant jusqu’à 31 terminaux émetteurs de données ainsi que des moniteurs (seulement récepteurs). La vitesse de transmission est de 1 Mbps, donc supérieure à celles de l’ARINC 429, diffusé dans la même période, mais le MIL-STD-1553 est plus complexe élec-troniquement et plus coûteux à mettre en œuvre. Publié en 1999, l’ARINC 629 [ARINC629-1 1999, ARINC629-2 1999] définit un bus bidirectionnel développé pour le gros porteur civil commercial Boeing 777 [Boeing 2013]. Il permet d’atteindre jusqu’à 2 Mbps partagés par un maximum de 120 terminaux.
Cette norme définit une architecture de communication moderne avec des débits de l’ordre de 100 Mbps. Elle permet d’interconnecter des systèmes avioniques via des topologies réseaux complexes et offre aux applica-tions embarquées la possibilité d’échanger des données via notamment les protocoles UDP et IPv4 aux couches 4 (couche transport du modèle OSI [ISO7498-1 1994]) et 3 (couche réseau), protocoles présentés plus loin dans la section 2.3.1.
Sa partie 7 définit l’“Avionic Full-DupleX switched Ethernet” (AFDX [ARINC664P7-1 2009]), un protocole de niveau 2 (couche liaison), qui fut développé initialement par la communauté aéronautique pour l’avionneur Airbus Industries dans les années 2000. Basé sur le protocole Ethernet (IEEE 802.3), l’AFDX reste compatible avec les matériels Ethernet, courants aujourd’hui dans le domaine “grand public” et non aéronautique. Cela permet notamment de réduire fortement les coûts d’étude et de développement pour les industriels travaillant avec l’AFDX : par exemple, ils peuvent utiliser des commutateurs Ethernet classiques en laboratoire pour développer et tester les systèmes terminaux destinés à communiquer à terme avec de l’AFDX.
Offrant un débit de 100 Mbps bidirectionnel (Full-Duplex), il contraint temporelle-ment les trames de données à transiter à des créneaux horaires prédéterminés, ce qui permet de garantir la disponibilité du réseau pour les applications et de qualifier de déterministe les réseaux AFDX. Le succès de cette solution est visible par son utilisation par les avions gros porteurs commerciaux : Airbus A380, Boeing B787, Airbus A400M.
Les avions exploitent simultanément plusieurs de ces protocoles de communication, en plus de la redondance pour chacun des protocoles. Ainsi, l’A380 dispose de deux réseaux AFDX similaires (nommés “A” et “B”) pour les commandes de vol afin que la perte d’un réseau soit immédiatement secourue par le second. Il dispose en plus de liens de secours ARINC 429 au cas où la défaillance serait inhérente à la technologie AFDX et affecterait donc simultanément les deux réseaux. La table 2.1 résume les technologies présentées dans cette section.

Les standards et protocoles de communication entre l’avion et le sol

Les réseaux embarqués permettent principalement de connecter les équipements de bords entre eux, mais aussi d’acheminer les données issues des réseaux terrestres. La liaison entre les réseaux terrestres, dits “au sol” et les réseaux embarqués, dits “à bord”, s’effectue via une troisième catégorie de réseaux : les réseaux dit “sol-bord”. Ces réseaux reposent sur des ondes radios pour transmettre les données. L’objectif de cette section est de présenter les différentes technologies utilisées aujourd’hui pour assurer le niveau liaison entre l’avion et le sol.
Historiquement, la première technologie exploitait la bande radio Haute Fréquence (HF, [DO-163 1976]) et permettait d’acheminer la voix entre les pilotes et les con-trôleurs. D’une portée très grande de l’ordre de 5 000 km, la bande HF 1.5 MHz – 30 MHz allouée à l’aéronautique par l’Union Internationale des Télécommunications (UIT [uit 2013]) a cependant des défauts : mauvaise qualité sonore entraînant une difficulté des transmissions, faible nombre de canaux simultanément utilisables… Dans les zones terrestres peuplées, la bande VHF (Aeronautical Very High Fre-quency [DO-169 1979], de 118 à 137 MHz depuis 1994), d’une portée moindre mais d’une qualité meilleure, a vite supplanté la bande HF.
Parallèlement, les technologies par satellite se sont développées et ont permis d’apporter aux communications aéronautiques les mêmes avantages que la bande VHF mais pour toute zone (océanique comme continentale, seuls les pôles étant mal couverts par les satellites). L’organisation Inmarsat [Inmarsat 2013]fut fondée en 1979 et privatisée en 1999 et offre des débits par satellites de 600 bps à 10,5 kbps. La constellation de 66 satellites en orbite basse Iridium [Iridium 2013]est autorisée depuis 2011 par la FAA pour la transmission des données critiques aéronautiques à des débits de 2,4 kbps. Cependant, les prix et les délais des communications par satellite sont généralement bien supérieurs au VHF. Il en résulte qu’en vol, les pilotes exploitent prioritairement la VHF, puis les liaisons SATCOM s’il n’est pas possible d’employer la VHF, et enfin la HF dans le cas où les deux autres moyens seraient inutilisables.
Ces technologies, exploitées actuellement pour les communications vocales du con-trôle aérien, sont aussi depuis plus récemment exploitées pour la communication des données aéronautiques du contrôle aérien. Ainsi, les réseaux Datalink peuvent exploiter la bande radio HF avec un protocole de niveau liaison appelé HFDL (High Frequency Datalink) et permettant un débit maximal de 1,8 kbps [DO-265 2000]. Le Datalink sur VHF est similaire, il existe quatre versions du protocole VDL (VHF Datalink), mais le protocole le plus utilisé aujourd’hui est le VDL mode 2, spécifié par l’OACI en 1996, il offre un débit limité à 31,5 kbps [DO-281A 2005, DO-281B 2012]. Enfin, les liaisons SATCOM peuvent aussi transmettre des données. A un niveau protocolaire supérieur, le format des messages échangés par ces moyens est appelé ACARS (Aircraft Communication Addressing and Reporting System) et il est stan-dardisé par les normes ARINC 618 à 623 [ARINC618-6 2006, ARINC619-3 2009, ARINC620-7 2012, ARINC622-4 2001, ARINC623-3 2005]. Des technologies nouvelles sont également en cours d’étude. Ainsi, établir un réseau ad hoc où chaque avion est un nœud d’un réseau global permettrait de transmettre des données de proche en proche de l’avion émetteur jusqu’à une station au sol réceptrice, en utilisant des bandes de fréquence ne permettant pas d’interconnecter directement la source et la destination mais permettant de les interconnecter via une chaîne d’avions relayant les données (voir à cet effet l’étude [Besse 2013]).
Le Wifi et le WiMax sont d’autres technologies à l’étude [Matolak et al. 2011, Besse 2013]. Leurs faibles portées (de l’ordre de la dizaine de km pour le WiMax, de la centaine de mètres pour le Wifi), inférieures à celle des HF (environ 5000 km), VHF (environ 300 km) et SATCOM (distance non limitée), font qu’ils sont plutôt envisagés pour les communications lorsque l’avion est à l’aéroport. Ces technolo-gies pourraient par exemple permettre le téléchargement durant le stationnement à l’aéroport de mises à jour de cartes aéronautiques et météorologiques.
Toutefois, quelque soit le moyen de communication utilisé, celui-ci concerne le niveau de liaison (niveau 2 du modèle OSI). Ainsi, notre routeur SNG qui gère le niveau réseau (niveau 3) n’a pas besoin de savoir quel niveau de liaison est employé : il envoie les données à l’équipement adéquat qui traite les données en conséquence. La seule propriété pouvant impacter l’intégration du routeur au sein de l’avion concerne le débit offert par le médium de niveau inférieur : chacun des moyens offre un débit qui lui est propre, comme résumé dans la table 2.2.

Les moyens de communication réservés au passager

En plus des communications dédiées au contrôle aérien, d’autres moyens de commu-nication sont apparus dans les années 2000 pour vendre aux passagers des services de communication vocale et d’accès au web. La table 2.3 résume quelques solu-tions existant actuellement ou ayant existées mais abandonnées pour des raisons de rentabilité (cas de Connexion-by-Boeing).

Architecture globale d’intégration du SNG

Les protocoles de communication présentés dans la section précédente constituent la couche de liaison entre systèmes «voisins». Ils peuvent utiliser pour cela une connexion filaire (cas des protocoles des communications internes à l’avion) ou une connexion sans fil (cas des communications sol-bord). Dans ce dernier cas, des systèmes assurent la connexion entre le réseau embarqué et le réseau «extérieur» à l’avion.
Historiquement, chaque besoin de communications de données était pensé indivi-duellement, menant ainsi à la multiplication des liaisons. Cette approche cloison-née permet de garantir pour chaque communication une indépendance vis-à-vis des autres communications et ainsi apporter des garanties relatives à la sécurité et la sûreté de ces communications. Mais la multiplication des services aéronautiques a conduit les avionneurs à regrouper les systèmes partageant des protocoles de liaison communs en réseaux. Cette mutualisation permet de partager les liaisons et ainsi de réduire d’autant les contraintes d’installation associées : poids et positionnement des câbles, allocation de nouvelles fréquences radio pour les nouveaux services, cer-tification des systèmes et de leurs connexions.

Domaines réseaux avioniques et aéronautiques

Deux terminologies sont employées en aéronautique pour classer les réseaux en fonc-tion de leurs usages. La terminologie OACI définie dans l’annexe 10 [OACI ] est celle utilisée par Airbus, elle a une vue centrée sur les communications entre l’avion et les installations au sol et est parfaitement adaptée à la classification des commu-nications sol-bord. L’ARINC 664P5 [ARINC664P5 2005] propose une terminologie alternative, utilisée par THALES AVIONICS, qui est plutôt centrée sur les systèmes embarqués et les services qu’ils fournissent, elle est donc adaptée à la classification des systèmes et réseaux embarqués.
L’annexe 10 de l’OACI [OACI ] définit quatre classes de services et de communica-tions aéronautiques. L’Air Traffic Services Communication (ATSC) regroupe l’Air Traffic Control (ATC) réservée au contrôle, le Position Reporting pour la surveil-lance et le Flight Information Services (FIS) principalement dédiée à la navigation. L’Aeronautical Operational Control (AOC) regroupe les communications exigées du-rant les différentes phases du vol pour la sécurité du vol, sa régularité et son efficacité. Ces deux classes sont utilisées par les organismes d’Aviation Civile. L’Aeronautical Administrative Communication (AAC) sert aux aspects commerciaux du vol, cette classe est réservée à l’usage exclusif des compagnies aériennes. Enfin, l’Aeronautical Passenger Communication (APC) est dédiée aux communications passées par les passagers (Internet cabine, téléphonie…). L’ensemble de ces 4 domaines forment une architecture appelée «Aeronautical Telecommunication Network» (ATN) qui englobe donc les communications sol-sol, sol-bord et avioniques (bord-bord).
Le groupe de travail AEEC de l’entreprise ARINC a proposé dans [ARINC811 2005] une terminologie alternative avec quatre domaines avioniques de communication, proche de celle de l’OACI. L’Aircraft Control Domain (ACD) regroupe les systèmes embarqués nécessaires pour la gestion de l’avion et du vol. L’Airline Information Service Domain (AISD) regroupe les systèmes «non essentiels» à la sécurité du vol mais permettant d’optimiser tout processus du vol, ces systèmes sont destinés à la maintenance et à l’équipage, personnel commercial inclus. Le Passenger Informa-tion Entertainment Services Domain (PIESD) est dédié aux réseaux et systèmes embarqués auxquels les passagers ont accès depuis leur siège, il contient notamment l’In-Flight Entertainment (IFE) qui permet la diffusion aux passagers de films et de musiques, de jeux, de journaux en ligne… Enfin le Passenger-Owned Devices domain (PODD) réunit les réseaux et systèmes permettant aux passagers d’utiliser leurs systèmes personnels nécessitant des communications (téléphones portables, smartphones, tablettes tactiles, ordinateurs portables, etc…).
La figure 2.1 présente ces deux terminologies ainsi que les passerelles entre elles. Bien que définies de manière différente, l’ATC et l’ACD sont tous deux associés à des exigences extrêmement élevées en sûreté, en sécurité et en disponibilité. De plus, les systèmes et réseaux associés à l’ACD utilisent et transmettent des informations généralement associées à l’ATSC. Il y a donc un lien fort entre l’ACD et l’ATSC, voir même une certaine confusion… Il en est de même pour les couples AOC/AISD, AAC/AISD, APC/PIESD et APC/PODD.
Basée initialement sur des protocoles réseaux propriétaires fermés, l’architecture ATN proposée par l’OACI est en cours de mutation pour remplacer les proto-coles propriétaires par d’autres protocoles courants dans le monde extérieur à l’aéronautique, notamment des protocoles standardisés par l’Internet Engineering Task Force (IETF) qui publie et organise les standards et propositions sous forme de «Request For Comments» (RFC). Cette architecture de nouvelle génération est dénommée «Aeronautical Telecommunication Network with Internet Protocol Suite» (ATN/IPS) et son principal avantage est sa compatibilité avec les équipements réseaux grand public appelés «Composants Sur Étagères» («Commercial Off-The-Self» ou COTS). Notre routeur SNG s’inscrit pleinement dans l’architecture AT-N/IPS. Elle est présentée figure 2.2, on y retrouve certains protocoles de liaison présentés dans la section 2.1, les protocoles des niveaux supérieurs sont présentés plus loin dans la section 2.3.1.

Table des matières

1. Introduction générale 
1.1. Problématique
1.2. Contributions
1.2.1. Contributions et publications scientifiques
1.2.2. Contributions industrielles
1.2.3. Contributions logicielles
1.3. Structure du mémoire
2. Contexte scientifique d’élaboration pour un routeur embarqué de nouvelle génération 
2.1. Introduction aux réseaux avioniques et aéronautiques par la couche liaison
2.1.1. Les standards et protocoles de communication embarqués
2.1.2. Les standards et protocoles de communication entre l’avion et le sol
2.1.3. Les moyens de communication réservés au passager
2.2. Architecture globale d’intégration du SNG
2.2.1. Domaines réseaux avioniques et aéronautiques
2.2.2. Interconnexion des domaines avioniques par un routeur de nouvelle génération
2.2.3. Mutualisation des liaisons aéronautiques sol-bord par un routeur de nouvelle génération
2.3. Formalisation du cahier des charges industriel
2.3.1. Routage
2.3.2. Filtrage
2.3.3. Multiplexage et sécurisation des communications
2.3.4. Exigences non fonctionnelles : sûreté et sécurité
2.4. La certification, garante de l’innocuité
2.4.1. Introduction à la certification des logiciels en aéronautique
2.4.2. Spécifications officielles du routeur SNG
2.5. L’évaluation, garante de l’immunité
2.5.1. La norme ISO CEI 15408 CC ITSEC
2.5.2. Application au routeur SNG : le Profil de Protection
2.6. Résumé du chapitre
3. La méthodologie de développement rapide en 7 étapes 
3.1. Motivations
3.1.1. Présentation du cycle en V
3.1.2. La virtualisation
3.1.3. Le MILS : Diviser pour mieux régner sur un monde sûr
3.1.4. L’IMA : Diviser pour mieux régner sur un monde aéronautique sécurisé
3.2. Contribution à l’amélioration du processus
3.2.1. Les sept étapes démystifiées
3.2.2. Avantages de cette méthodologie
3.3. Choix d’outils pour l’application de la méthodologie au routeur SNG
3.3.1. Organisation architecturale du routeur SNG
3.3.2. Modélisation avec Simulink et Stateflow
3.3.3. Transformation avec GeneAuto vers les langages C et Ada
3.3.4. Collage manuel mais automatisable
3.3.5. Compilation avec gcc du code en langage C
3.3.6. Intégration avec Sysgo PikeOS
3.3.7. Exécution avec qemu-x86 puis sur système embarqué
3.3.8. Une autre chaîne d’outils, presque tous libres
3.3.9. Synthèse sur les chaînes d’outils
3.4. Métrix, logiciel d’évaluation de la qualité d’un code source
3.4.1. Objectifs de Métrix
3.4.2. Les métriques mesurées sur le code source
3.4.3. Représentation des résultats mesurés par Métrix
3.4.4. Conclusion sur notre logiciel Métrix
3.5. Résumé du chapitre
4. Mise en oeuvre du routeur SNG 
4.1. Architecture du logiciel du routeur SNG
4.2. Pfr4, la partition de routage et de filtrage pour IPv4
4.2.1. Contexte avionique et AFDX
4.2.2. Cheminement des paquets
4.2.3. Ordonnancement
4.2.4. Routage
4.2.5. Filtrage
4.3. Pfr6, la partition de routage et de filtrage pour IPv6
4.3.1. Ordonnancement, routage et filtrage
4.3.2. Le protocole Neighbor Discovery Protocol (NDP)
4.4. Pse et les mécanismes de sécurisation des flux
4.4.1. Établissement du canal avec IKEv2 : création d’un tunnel sécurisé
4.4.2. Stockage du matériel de sécurisation
4.4.3. Sécurisation des données avec ESP : exploitation d’un tunnel sécurisé
4.4.4. Mécanismes et algorithmes de sécurisation
4.5. Piface, la partition d’interfaçage du matériel avec Pfr4 et Pfr6
4.5.1. Intégration de Piface dans son environnement
4.5.2. La partition Piface vue de l’intérieur
4.6. Résumé du chapitre
5. Le protocole SCOUT 
5.1. Introduction
5.2. Fonctionnement du protocole SCOUT
5.2.1. Le protocole générique SCOUT
5.2.2. Prérequis de fonctionnement de SCOUT
5.2.3. Algorithme du protocole SCOUT
5.2.4. SCOUT avec IPv6 : Le protocole SCOUT6
5.2.5. Mise en oeuvre du dæmon SCOUT6
5.2.6. Exemples d’application de SCOUT6
5.3. Évaluation des performances de SCOUT6
5.3.1. Evaluation de l’impact de SCOUT6 en terme de capacité et de délai réseau
5.3.2. Complexité des opérations avec et sans SCOUT
5.4. Sécurité du protocole SCOUT6
5.4.1. Injection de paquets
5.4.2. Rejeu de paquets
5.4.3. Paquets volés, altérés et attaque de l’homme du milieu
5.4.4. Falsification d’adresses IP
5.4.5. Déni de Service (DoS)
5.4.6. Une attaque fonctionnelle contre SCOUT6 et sa conséquence
5.4.7. Conclusion sur la sécurité du protocole SCOUT6
5.5. Perspectives d’évolutions du protocole SCOUT
5.5.1. Le problème des Router Alert rejetés par les fournisseurs d’accès
5.5.2. Accélération de la seconde phase par interception du résultat de la première phase
5.5.3. Adaptation de SCOUT6 avec le protocole UDPv6
5.6. Résumé du chapitre
6. Évaluation des performances du routeur SNG 
6.1. Cadre d’expérimentation
6.1.1. Topologies réseaux d’études
6.1.2. Matériel mis en oeuvre
6.2. Métriques et outils
6.2.1. Métriques sélectionnées
6.2.2. Outils choisis
6.2.3. Trafics de charge
6.2.4. le programme sourcesonoff
6.3. Résultats des mesures de performance
6.3.1. Premiers résultats préparatoires
6.3.2. Étude de l’impact des mécanismes de sécurisation
6.3.3. Autres paramètres étudiés
6.4. Résumé du chapitre
7. Conclusions et perspectives 
7.1. Bilan des avancées et des contributions scientifiques
7.2. Perspectives continuant nos recherches
Publications
Liste des symboles
Bibliographie 
Annexes 
A. Protection Profile for the Secure Next Generation Router (PP RT SNG)
B. Mise en oeuvre du dæmon SCOUT6 version beta
C. Interface Homme-Machine de Métrix

Télécharger le rapport complet