Brevet FR3151730A1 — publié le 20250131

Un aspect de l’invention concerne un procédé d’établissement d’une connexion sécurisée de bout en bout entre un environnement embarqué d’un aéronef et un environnement sol d’un centre d’assistance situé au sol. La connexion sécurisée est dédiée exclusivement à une gestion d’une situation d’urgence. Le procédé comprend notamment l’échange de plusieurs messages « aircraft communication addressing and reporting system » ACARS et la mise en place d’un nuage « multiprotocol label switching » MPLS. Enfin, le procédé comprend l’établissement d’une connexion sécurisée entre l’environnement embarqué et l’environnement sol via un chiffrement hybride à l’aide d’une clé publique accessible par l’environnement sol et l’environnement embarqué et à l’aide d’une clé privée accessible exclusivement par l’environnement sol. Figure à publier avec l’abrégé : Figure 1 procédé d’établissement d’une connexion sécurisée entre un aéronef et un centre d’assistance situé au sol DOMAINE TECHNIQUE DE L’INVENTION Le domaine technique de l’invention est celui de la sécurité des communications et en particulier la sécurité des communications entre un aéronef et un centre d’assistance situé au sol. La présente invention concerne un procédé d’établissement d’une connexion sécurisée entre un aéronef et un centre d’assistance situé au sol. ARRIERE-PLAN TECHNOLOGIQUE DE L’INVENTION Lorsqu’un aéronef est confronté à un ensemble de défaillances importantes, le ou les pilotes doivent exécuter un ensemble de procédures pour décider si l’aéronef peut rester en condition de vol stabilisé et suffisamment navigable pour continuer le vol / la mission en cours, ou s’il est nécessaire de se dérouter pour atterrir au plus vite. Dans le futur, il est envisagé de n’avoir qu’un seul pilote par aéronef, il faudra donc pouvoir faire face à toutes les situations de crise, tout en maintenant l’exigence de sécurité du vol. Plusieurs solutions sont envisagées : l’une d’entre elles étant de permettre à une ou plusieurs personnes, situées dans un environnement au sol, d’apporter du soutien au pilote dans l’aéronef ou de prendre la main sur le poste de pilotage de l’aéronef. La prise en main à distance d’un poste de pilotage nécessite la mise en œuvre d’une liaison de connectivité sécurisée entre l’environnement embarqué du poste de pilotage de l’aéronef et l’environnement au sol. Toutefois, face à des cyber-attaques de plus en plus perfectionnées, la sécurisation d’une telle liaison est une tâche complexe à réaliser. A l’heure actuelle, la plupart des aéronefs de dernière génération embarquent des solutions de connectivité permettant des échanges de données opérationnelles entre les postes de pilotage desdits aéronefs et les centres opérationnels au sol. Les solutions implémentées se basent sur des technologies issues du monde des systèmes d’informations et réseaux de protocole internet, noté IP pour « Internet Protocol » en anglais, avec par exemple l’utilisation de modems cellulaires 4G/5G. Afin d’assurer la sécurité de cette liaison, il est par exemple connu d’utiliser des librairies de sécurisation comme le protocole de sécurité internet, « Internet Protocol Security » en anglais, utilisé notamment pour la mise en œuvre de Réseau privé virtuel, noté VPN pour « Virtual Private Network » en anglais. Même si les autorités de certification ont établi des règles et des directives pour cadrer l’implémentation de solutions de connectivité sécurisées, il n’y a pas d’exigence de confidentialité, discrétion et de garantie de service. De ce fait, le comportement de la connectivité sécurisée des aéronefs est basé sur la notion de « meilleur effort » ce qui ne permet pas de démontrer le niveau de qualité espéré pour une liaison de connectivité en situation d’urgence. Il existe donc un besoin d’un procédé permettant la transmission sécurisée de messages entre un environnement embarqué d’un aéronef et un environnement sol d’un centre d’assistance situé au sol, en particulier lorsque l’aéronef est en situation d’urgence. L’invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé d’établissement d’une connexion sécurisée de bout en bout entre un environnement embarqué d’un aéronef et un environnement sol d’un centre d’assistance situé au sol. Ainsi, la communication entre l’aéronef et le sol est réalisée par un ensemble de solutions permettant une connexion sécurisée. Un premier niveau de la solution sécurisée concerne la sécurisation du media de communication. Par souci de simplicité, ce niveau n’est pas décrit dans l’invention car il est de la responsabilité du fournisseur d’accès au media de communication. Un deuxième niveau de la solution concerne l’établissement d’une liaison sécurisée entre le gestionnaire d’accès distant de l’environnement embarqué et l’environnement sol. L’établissement de la connexion n’est effectif qu’après une authentification mutuelle forte entre l’aéronef et l’utilisateur au sol. Un troisième niveau de la solution concerne le chiffrement et la signature systématique de tous les échanges de commandes interactives d’urgence. Un aspect de l’invention concerne un procédé d’établissement d’une connexion sécurisée de bout en bout entre un environnement embarqué d’un aéronef et un environnement sol d’un centre d’assistance situé au sol, la connexion sécurisée étant dédiée exclusivement à une gestion d’une situation d’urgence avec : L’environnement embarqué comprenant un gestionnaire d’accès distant et un système de connectivité IP dédiés à la gestion de la situation d’urgence, le gestionnaire d’accès distant comprenant un premier module de filtrage matériel multi-réseaux et le système de connectivité IP étant en liaison avec le gestionnaire d’accès distant via le module de filtrage matériel multi-réseaux, et L’environnement sol comprenant un gestionnaire de connexion d’urgence dédié à la gestion de la situation d’urgence, le gestionnaire de connexion d’urgence comprenant un second module de filtrage matériel multi-réseaux, Le procédé comprenant : Envoyer un premier message « Aircraft Communication Addressing and Reporting System » ACARS via un réseau ACARS, le premier message ACARS étant envoyé par l’environnement embarqué à l’environnement sol lorsqu’ une situation d’urgence concernant l’aéronef est détectée, Recevoir et décoder le premier message ACARS par l’environnement sol du centre d’assistance, Lorsque le premier message ACARS est considéré comme décrivant une situation d’urgence, activer un environnement confidentiel dédié à la gestion de la situation d’urgence, l’activation de l’environnement comprenant : Envoyer un deuxième message ACARS via le réseau ACARS, le deuxième message ACARS étant envoyé par l’environnement sol à l’environnement embarqué et le deuxième message ACARS contenant une confirmation de la prise en compte de la situation d’urgence, Mettre en place un nuage « MultiProtocol Label Switching » MPLS entre le système de connectivité IP et le système de connexion aux fournisseurs de service d’accès au réseau IP, Etablir une connexion au nuage MPLS par les premier et second modules de filtrage matériel multi-réseaux, et Etablir une connexion sécurisée entre l’environnement embarqué et l’environnement sol via un chiffrement hybride à l’aide d’une clé publique et d’une clé privée, la clé publique étant accessible par l’environnement sol et l’environnement embarqué et la clé privée étant accessible exclusivement par l’environnement sol, l’établissement d’une connexion sécurisée comprenant le chiffrement de messages permettant l’établissement de la liaison sécurisée à l’aide de la clé publique, les messages chiffrés étant envoyés au sein du nuage MPLS et au moins l’un des messages chiffrés permettant le partage de la clé privée. Le terme « environnement » désigne l'ensemble des systèmes sur lesquels est exécuté le procédé selon l’invention. De plus, le terme « environnement » peut en outre désigner des logiciels système, dont le système d'exploitation, sur lesquels est exécuté le procédé selon l’invention. Grâce à l’invention, la transmission de messages entre un environnement embarqué d’un aéronef et un environnement sol d’un centre d’assistance situé au sol est sécurisée. En effet, la sécurisation est assurée par les différents niveaux de sécurité. De plus, ce système de transmission est totalement indépendant des autres systèmes de transmission de l’aéronef et du centre d’assistance, permettant ainsi d’accroître encore la sécurité du procédé. Outre les caractéristiques qui viennent d’être évoquées dans le paragraphe précédent, le procédé selon un aspect de l’invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : Le procédé comprend en outre une authentification multifactorielle afin d’accéder à une visualisation déportée d’un poste de pilotage de l’aéronef en situation d’urgence, la visualisation déportée étant effectuée au niveau de l’environnement sol, L’authentification multifactorielle comprend : Générer un mot de passe aléatoire par le gestionnaire d’accès distant, Envoi d’un troisième message ACARS comprenant le mot de passe généré via le réseau ACARS à l’environnement sol, Réception du troisième message par l’environnement sol et saisie du mot de passe par un utilisateur, et Lorsque le mot de passe saisi par l’utilisateur est authentifié, la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence est activée, La visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence comprend en outre une interface utilisateur, le procédé comprenant en outre : Réception par l’interface utilisateur d’une interaction initiée par l’utilisateur, l’interaction correspondant à une commande du poste de pilotage de l’aéronef, Envoi d’un message signé, le message signé comprenant la commande et un champ additionnel renseigné de manière aléatoire, Réception du message signé par l’environnement embarqué, Lorsque le message signé est authentifié par l’environnement embarqué : Envoi par l’environnement embarqué d’un quatrième message ACARS et d’un message IP à l’environnement sol, Réalisation de la commande comprise dans le message signé, la commande étant réalisée dans le poste de pilotage, et Mise à jour de la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence, Le procédé comprend en outre une déclaration de fin de situation d’urgence lorsque l’aéronef a atterri, la déclaration de fin d’urgence comprenant : Redémarrer le gestionnaire d’accès distant et du système de connectivité IP dédiés à la gestion de la situation d’urgence au niveau de l’environnement embarqué, Supprimer la connexion sécurisée au niveau de l’environnement sol, et Mettre à jour la clé publique et la clé privée. Un second aspect de l’invention concerne un environnement embarqué d’un aéronef comprenant un gestionnaire d’accès distant et un système de connectivité IP dédié à la gestion de la situation d’urgence, le gestionnaire d’accès distant comprenant un module de filtrage matériel multi-réseaux et le système de connectivité IP étant en liaison avec le gestionnaire d’accès distant via le module de filtrage matériel multi-réseaux, l’environnement embarqué étant configuré pour mettre en œuvre un procédé selon l’invention. Un troisième aspect de l’invention concerne un aéronef comprenant un environnement embarqué selon l’invention. Un quatrième aspect de l’invention concerne un environnement sol d’un centre d’assistance situé au sol comprenant un gestionnaire de connexion d’urgence, le gestionnaire de connexion d’urgence comprenant un second module de filtrage matériel multi-réseaux, l’environnement sol étant configuré pour mettre en œuvre un procédé selon l’invention. Un cinquième aspect de l’invention concerne un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent l’environnement embarqué et l’environnement sol à exécuter au moins une des étapes de la méthode selon l’invention. Par exemple, un premier programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un premier ordinateur, conduisent le premier ordinateur à mettre en œuvre les étapes du procédé selon l’invention effectuées au niveau de l’environnement sol. Dans un autre exemple, un second programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un second ordinateur, conduisent le second ordinateur à mettre en œuvre les étapes du procédé selon l’invention effectuées au niveau de l’environnement embarqué. Un sixième aspect de l’invention concerne un support lisible par ordinateur, sur lequel est enregistré le programme d'ordinateur selon l’invention. L’invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l’examen des figures qui l’accompagnent. BREVE DESCRIPTION DES FIGURES Les figures sont présentées à titre indicatif et nullement limitatif de l’invention. La montre une représentation schématique d’un exemple du procédé selon l’invention. Les figures 2, 3 et 4 montrent une représentation schématique d’un exemple d’une étape du procédé selon l’invention. La montre une représentation schématique d’un exemple d’environnement embarqué selon l’invention. La montre une représentation schématique d’un exemple d’environnement sol selon l’invention. DESCRIPTION DETAILLEE Les figures sont présentées à titre indicatif et nullement limitatif de l’invention. Un premier aspect de l’invention illustré à la concerne un procédé 100 d’établissement d’une connexion sécurisée de bout en bout entre un environnement embarqué d’un aéronef et un environnement sol d’un centre d’assistance situé au sol. Les étapes de l'exemple du procédé 100 sont indiquées par un rectangle avec des lignes pleines et les étapes facultatives sont indiquées par un rectangle avec des lignes en pointillés. Le procédé 100 est mis en œuvre à l’aide d’un environnement embarqué de l’aéronef. Un exemple d’environnement embarqué 500 adapté pour mettre en œuvre le procédé 100 est illustré en . L’environnement embarqué 500 comprend un gestionnaire 510 de pages systèmes, d’exécution NNC, pour « Non-Normal Checklist » en anglais, et de pilotage RCCP, pour « Remote Centralized Control Panel » en anglais, un cyber module 550, un gestionnaire d’accès distant 580 et un système 620 de connectivité IP. Le gestionnaire d’accès distant 580 et le système 620 de connectivité IP sont dédiés à la gestion d’une situation d’urgence, i.e. ne sont impliqués dans aucun autre procédé. Le gestionnaire 510 de pages systèmes, d’exécution NNC et de pilotage RCCP est un environnement de niveau DAL, pour « Design Assurance Level » en anglais, élevé. Le cyber module 550 est de niveau SAL, pour « Security Assurance Level » en anglais, 3. Le cyber module 550 est connecté avec le gestionnaire 510 de pages systèmes, d’exécution NNC et de pilotage RCCP via notamment un premier flux de diffusion 530 dédié à la situation d’urgence et via une première liaison de commandes interactives 540 d’urgence. Le premier flux de diffusion 530 dédié à la situation d’urgence a pour origine le gestionnaire 510 de pages systèmes, d’exécution NNC et de pilotage RCCP et destination le cyber module 550. La première liaison de commandes interactives 540 d’urgence est bidirectionnelle. Le gestionnaire d’accès distant 580 comprend un premier processeur 582, un élément de sécurisation 583, ou « secure element » en anglais, et un premier module 581 de filtrage matériel multi-réseaux. Le gestionnaire d’accès distant 580 est connecté au cyber module 550 via un second flux de diffusion 560 dédié à la situation d’urgence et une seconde liaison 570 de commandes interactives d’urgence. Le second flux de diffusion 560 dédié à la situation d’urgence a pour origine le cyber module 550 et destination le gestionnaire d’accès distant 580. La seconde liaison 570 de commandes interactives d’urgence est bidirectionnelle. Le système 620 de connectivité IP est connecté au gestionnaire d’accès distant 580 via le premier module 581 de filtrage matériel multi-réseaux. Le système 620 de connectivité IP est dédié à la gestion des situations d’urgence au niveau du poste de pilotage. Le premier processeur 582 réalise plusieurs fonctions dédiées à la gestion d’une situation d’urgence. Par exemple, le premier processeur 582 est en charge de la veille d’une détection de situation d’urgence afin d’activer les dispositifs nécessaires et d’initier l’établissement d’une connexion sécurisée. Le premier processeur 582 est aussi en charge de recevoir les messages de commandes interactives 750 provenant de l’environnement sol et de les traduire en commandes intelligibles par le cyber module 550 mais surtout par le gestionnaire de pages systèmes, d’exécution NNC et pilotage RCCP. Pour réaliser cette opération, le processeur utilisera les secrets enregistrés, c’est-à-dire des éléments tenus secrets tels que des clés et/ou certificats, dans l’élément de sécurisation afin de pouvoir déchiffrer les messages et de pouvoir vérifier l’identité de la source des messages. Dans un exemple, le système 620 de connectivité IP peut être équipé d’un système inertiel interne gyroscopique et accéléromètre 3 axes, dédié lui aussi à la gestion des situations d’urgence. Le système inertiel permet notamment de connaître la position et l’attitude de l’aéronef. Ces informations servent à déterminer en temps réel quel type de media de communication sera le plus fiable et disponible pour assurer la mission parmi par exemple un modem satcom Inmarsat ® SB-S, un modem satcom Iridium Certus ®, un modem « air-sol » à base de technologie cellulaire comme la technologie 5G ou tout autre moyen de connecter l’aéronef au sol qui répond aux contraintes de performances, disponibilité et qualité de service requis par le dispositif. D’autres exemples de moyens pouvant être utilisés pour connecter l’aéronef au sol sont les systèmes d’accès Internet via des constellations de satellites tels que One Web, Starlink ou encore Kuiper. Les informations envoyées par l’environnement sol, telles que les commandes interactives 610, transitent par le système 620 de connectivité IP et sont ensuite transmises au premier module 581 de filtrage matériel multi-réseaux. De même, les informations envoyées à l’environnement sol, telles que le flux de diffusion 600 dédié à la situation d’urgence et les commandes interactives 610, par l’environnement embarqué 500 sont transmises par le premier module 581 de filtrage matériel multi-réseaux au système 620 de connectivité IP. Dans un exemple, le premier module 581 de filtrage matériel multi-réseaux peut être un circuit intégré de type FPGA, pour « field-programmable gate array » en anglais. Dans un exemple, compatible avec l’exemple précédent, le premier module 581 de filtrage matériel multi-réseaux permet de mettre en œuvre plusieurs réseaux Ethernet indépendants et apporte une ségrégation physique entre chaque réseau établi. Ce premier module 581 de filtrage matériel multi-réseaux est par exemple basé sur la technologie EPEX, pour « Ethernet Port EXpander » en anglais, décrite dans le brevet EP2652628B1 daté du 2010-12-17 intitulé « Device for multiple ethernet connection to a computer unit and computer unit assembly and equipment linked together”. La technologie EPEX apporte la possibilité de réaliser du filtrage de flux au niveau des couches OSI, pour « Open Systems Interconnection » en anglais, de niveau 1, 2 et/ou 3 et permet aussi de gérer la bande passante allouable à chaque port pour se prémunir d’attaque de type noyage, « flooding » en anglais, ou déni de service. Dans un autre exemple, compatible avec l’exemple précédent, le gestionnaire d’accès distant 580 est de niveau SAL 3. Le procédé 100 est aussi mis en œuvre à l’aide d’un environnement sol d’un centre d’assistance situé au sol. Un exemple d’environnement sol 700 adapté pour mettre en œuvre le procédé 100 est illustré en . L’environnement sol 700 comprend un gestionnaire 710 de connexion d’urgence et un système 720 de connexion aux fournisseurs de service d’accès au réseau IP. Le gestionnaire 710 de connexion d’urgence et le système 720 de connexion sont dédiés à la gestion des situations d’urgence. Le gestionnaire 710 de connexion d’urgence comprend un second processeur 712, un second élément de sécurisation 713 et un second module 711 de filtrage matériel multi-réseaux, différent du premier module 581 de filtrage matériel multi-réseaux. Dans un exemple, le second module 711 de filtrage matériel multi-réseaux peut être un circuit intégré de type FPGA. Le gestionnaire 710 de connexion d’urgence envoie le flux de diffusion 790 au centre de contrôle opérationnel 760 dédié aux urgences. De plus, le gestionnaire 710 de connexion d’urgence envoie et reçoit des messages de commandes interactives 780. Les informations envoyées par l’environnement embarqué 500, telles que le flux de diffusion 740 et les messages de commandes interactives 750, transitent par le système 720 de connexion aux fournisseurs de service d’accès au réseau IP dédié à la gestion des situations d’urgence et sont ensuite transmises au second module de filtrage matériel multi-réseaux. De même, les informations envoyées à l’environnement embarqué 500, telles que les messages de commandes interactives 750, par l’environnement au sol sont transmises par le second module 711 de filtrage matériel multi-réseaux au système 720 de connexion aux fournisseurs de service d’accès au réseau IP dédié à la gestion des situations d’urgence. Le procédé 100 permet ensuite d’envoyer ces messages de commandes interactives au gestionnaire d’accès distant 580 de l’environnement embarqué 500 via une connexion sécurisée. Le procédé 100 permet aussi au gestionnaire 710 de connexion d’urgence de recevoir le flux de diffusion 740 qui a été envoyé par le gestionnaire d’accès distant 580 de l’environnement embarqué 500 via la connexion sécurisée. La connexion sécurisée établie selon le procédé 100 est une connexion sécurisée de bout en bout entre l’environnement embarqué 500 de l’aéronef et l’environnement sol 700 du centre d’assistance. Cette connexion sécurisée est dédiée exclusivement à la gestion d’une situation d’urgence pour un aéronef. Ainsi, dans un exemple, compatible avec les exemples précédents, la connexion est créée lorsqu’une situation d’urgence est détectée et terminée lorsque la situation d’urgence est résolue. Lorsqu’il n’y a pas de situation d’urgence, les dispositifs présentés précédemment et utilisés pour mettre en œuvre le procédé 100 ne sont pas accessibles depuis l’extérieur, c’est-à-dire en dehors de l’environnement embarqué 500 et en dehors de l’environnement sol 700. Ainsi, la durée de connexion est minimale et cela permet d’accroître la discrétion de cette connexion et donc sa sécurisation. Il est même possible dans un exemple d’isoler le gestionnaire d’accès distant 580 du cyber module 550 en désactivant les flux de données entre ces deux entités. Afin de s’assurer de leurs bons fonctionnements, un test de bon fonctionnement de la connexion entre le gestionnaire d’accès distant 580 et le système 620 de connectivité pour poste de pilotage peut être réalisé à intervalles réguliers. Ce test peut être réalisé par une fonction équivalente à une commande de type ‘ping’ afin de s’assurer de la disponibilité fonctionnelle de la liaison. De la même manière, le système 620 de connectivité pour poste de pilotage effectue un test de bon fonctionnement de sa liaison avec le sol. Ces deux tests peuvent être réalisés de manière disjointe afin de ne pas établir de connexion directe entre le gestionnaire d’accès distant 580 en situation d’urgence et l’environnement sol 700. Une situation d’urgence est une situation pouvant mettre en cause la sécurité du vol de l’aéronef et donc possiblement l’intégrité physique des personnes à bord de l’aéronef. Afin de gérer cette situation, il est nécessaire d’activer et/ou désactiver certaines commandes de l’aéronef. Le procédé selon la présente invention vise à aider le pilote de l’aéronef dans cette tâche. La détection d’une situation d’urgence peut être due à une détection de perte de capacité du pilote de l’aéronef. La détection d’une situation d’urgence peut aussi être due à une crise dans l’aéronef, par exemple une cascade de pannes systèmes, nécessitant l’aide ou l’assistance d’une ou plusieurs personnes déportées au sol. Le dispositif 520 de détection d’une situation d’urgence peut donc prendre en compte 2 sources d’entrée : Le résultat de la surveillance du niveau de capacité du pilote, et L’activation d’un élément de déclaration de situation d’urgence. Une première étape 110 du procédé 100 consiste à envoyer un message ACARS via un réseau ACARS. L’acronyme ACARS signifie en anglais « Addressing Communication And Reporting system » et désigne un système de liaison de données numériques pour la transmission de messages courts entre des aéronefs et des stations au sol par radio à bande aérienne ou par satellite. Le message ACARS est envoyé par l’environnement embarqué 500 à l’environnement sol 700 lorsqu’une situation d’urgence concernant l’aéronef est détectée. Ce message permet d’informer le centre d’assistance qu’une situation d’urgence a été détectée dans l’aéronef et que le pilote de l’aéronef a besoin d’assistance. Le message ACARS peut être opaque, c’est-à-dire que les données contenues dans ce message sont obfusquées. L'obfuscation des données est une forme de masquage des données dans laquelle les données sont délibérément brouillées. De manière optionnelle, le dispositif 520 en charge de la détection et de l’alerte en cas de situation d’urgence génère un signal interne à l’environnement embarqué 500. Ce signal interne informe notamment le gestionnaire 510 de pages systèmes, d’exécution NNC et pilotage RCCP et le cyber module 550 de l’activation du mode d’urgence. Ces modules activent alors une configuration donnant la priorité au traitement des flux de données associés à la situation d’urgence. Le réseau ACARS peut être implémenté avec un routeur 630 de connectivité du côté de l’environnement embarqué 500 et un module 730 de connexion aux fournisseurs de service d’accès au réseau ACARS. Dans une seconde étape 120, le message ACARS est reçu et décodé par l’environnement sol 700 du centre d’assistance situé au sol. Dans une troisième étape 130, un test est effectué afin de vérifier si le message concerne une situation d’urgence par le centre d’assistance. Lorsque le message ACARS est considéré comme décrivant une situation d’urgence par le centre d’assistance, un environnement confidentiel dédié à la gestion de la situation d’urgence est mis en place. La confidentialité est la caractéristique d’une information de n’être accessible qu’à ceux qui sont autorisés. Cette activation 130 de l’environnement confidentiel comprend trois sous-étapes 131 à 134. La montre une représentation schématique d’un exemple de la troisième étape 130 du procédé 100. La première sous-étape 131 de l’étape 130 est l’envoi d’un message ACARS via le réseau ACARS. Le message est envoyé par l’environnement sol à l’environnement embarqué. De plus, le message ACARS contient une confirmation de la prise en compte de la situation par le centre d’assistance. Par exemple, l’utilisateur au sol, pilote ou autre personnel, pouvant assister un aéronef en situation d’urgence et ayant l’autorisation d’entrée physique dans l’environnement confidentiel envoie un message de confirmation de la prise en compte de la situation via le réseau ACARS. La seconde sous-étape 132 de l’étape 130 est la mise en place d’un nuage 630 MPLS, pour « multiprotocol label switching » en anglais, entre le système 620 de connectivité IP et le système 720 de connexion aux fournisseurs de service d’accès au réseau IP. Le rôle principal de la technique réseau MPLS est de combiner les concepts du routage IP de niveau 3, et les mécanismes de la commutation de niveau 2. De plus, la technique réseau MPLS traite la commutation en mode connecté, basé sur les labels, les tables de commutation étant calculées à partir d’informations provenant des protocoles de routage IP ainsi que de protocoles de contrôle. La technique réseau MPLS peut être considérée comme une interface apportant au protocole internet, noté IP, le mode connecté et qui utilise les services de niveau 2. Enfin, il faut noter que la technique réseau MPLS n’est en aucune façon restreinte à une couche 2 spécifique et peut fonctionner sur tous les types de support permettant l’acheminement de paquets de niveau 3. Un nuage 630 MPLS, pour « Multiprotocol Label Switching » en anglais est plus précisément une infrastructure d’un fournisseur d’accès fonctionnant par commutation de labels. Cette technologie est choisie pour ses caractéristiques qui permettent d’assurer un bon niveau de performance de routage de flux. En effet, cette technologie de routage MPLS est considérée comme une couche OSI intermédiaire, couramment considérée comme « OSI 2,5 », entre la couche OSI 2 Ethernet et la couche OSI 3 IP. Ainsi, cette technologie permet de router les paquets IP sans avoir à les décapsuler car elle utilise un ou des labels qui sont ajoutés à la trame et qui permettent de rapidement router un paquet d’un élément du nuage 630 MPLS à un autre. De plus, cette technologie permet d’allouer une classe de service afin d’assurer une qualité de service et de l’allocation de bande passante. La troisième sous-étape 133 de l’étape 130 est la connexion, de l’environnement embarqué 500 au nuage 630 MPLS par le premier module 581 de filtrage matériel multi-réseaux ainsi que la connexion de l’environnement sol 700 au nuage 630 MPLS par le second module 711 de filtrage matériel multi-réseaux. La connexion 590 est la connexion de l’environnement embarqué 500 au nuage 630 MPLS gérée par le premier module 581. La connexion 800 est la connexion de l’environnement sol 700 au nuage 630 MPLS gérée par le second module 711.Cette sous-étape 133 permet l’établissement d’une communication aéronef-sol sécurisée au niveau des moyens de communication. Par exemple, cet établissement peut comprendre, dans un premier temps, l’établissement d’une connexion par le système 620 de connectivité IP avec l’environnement sol 700 via le media qui présente la meilleure qualité de service. L’ensemble des attributs de sécurisation de cette liaison sont activés pour établir un premier niveau de protection des échanges. Cette liaison est représentée par un premier tunnel 640 sur les figures 5 et 6. Concernant l’environnement sol 700, le système 720 de connexion aux fournisseurs de service d’accès réseau IP dédié aux situations d’urgences assure la terminaison de la liaison sécurisée. L’établissement de ce premier niveau de sécurisation implique les fournisseurs de service d’accès réseau IP qui vont contribuer à la qualité de service globale de la liaison d’urgence. La troisième sous-étape 133 de l’étape 130 peut être effectuée avant ou après la seconde sous-étape 132 de l’étape 130. La quatrième sous-étape 134 de l’étape 130 est l’établissement d’une connexion sécurisée entre l’environnement embarqué 500 et l’environnement sol 700. La connexion est sécurisée notamment via un chiffrement hybride faisant appel aux deux grandes familles de chiffrement : le chiffrement asymétrique et le chiffrement symétrique. Le chiffrement hybride est effectué à l’aide d’une clé publique et d’une clé privée. Dans un exemple, la clé publique peut faire partie d’une infrastructure de clés publiques. De plus, ces clés peuvent être également des certificats électroniques. La clé publique est accessible par l’environnement embarqué 500 et l’environnement sol 700. La clé publique peut par exemple être stockée au niveau de l’environnement sol 700. Préférentiellement, la clé publique n’est connue que de l’organisation qui opère les aéronefs et doit être stockée et gérée dans un environnement sécurisé. Dès qu’un soupçon qu’une clé est divulguée, l’ensemble de la flotte et de l’environnement confidentiel au sol pourra, voire même devra dans certains cas, être mis à jour dans les plus brefs délais. La clé privée asymétrique est accessible uniquement par l’environnement sol 700. L’établissement 134 d’une connexion confidentielle comprend le chiffrement de messages permettant l’établissement de la liaison sécurisée à l’aide de la clé publique. De plus, les messages chiffrés sont envoyés au sein du nuage 630 MPLS et au moins l’un des messages chiffrés envoyés comprend la clé privée symétrique et permet donc son partage avec l’environnement embarqué 500. La clé privée symétrique pourra ensuite être utilisée pour chiffrer et déchiffrer les échanges entre l’environnement sol 700 et l’environnement embarqué 500. La mise en œuvre de la quatrième sous-étape 134 peut être réalisée par le processeur 582 et l’élément de sécurisation 583 du gestionnaire d’accès distant 580 en situation d’urgence. Dans un exemple, cette sous-étape est réalisée en utilisant des secrets, en plus des clés précédemment citées, suffisamment forts pour être à sécurité quantique, appelée en anglais « Quantum-safe », par exemple en choisissant des librairies ou des programmes permettent de répondre aux exigences établies par l’institut national des standards et technologie, « National Institute of Standards and Technology » (NIST) en anglais, dans le standard « Post-Quantum Cryptography Standardization ». La cryptographie à sécurité quantique fait référence aux efforts visant à identifier des algorithmes résistants aux attaques des ordinateurs classiques et quantiques, afin de préserver la sécurité des informations, même après la construction d'un ordinateur quantique à grande échelle. A la fin de ces échanges, l’environnement embarqué a authentifié l’environnement sol. Il faut également préciser qu’un processus identique avec un autre jeu de clés est réalisé afin de que l’environnement sol authentifie l’environnement embarqué. Cette double authentification est communément une authentification mutuelle. A la fin de cette sous-étape 134, le tunnel 650 est mis en place. Ce tunnel 650 est au niveau OSI 3 ou Layer 3 Virtual Private Network, noté L3VPN. Ce tunnel permet ensuite de chiffrer les messages transportés et échangés. Dans un exemple, compatible avec les exemples précédents, le procédé 100 comprend une quatrième étape 140 optionnelle d’authentification multifactorielle afin d’accéder à une visualisation déportée d’un poste de pilotage de l’aéronef en situation d’urgence. Une authentification multifactorielle est une authentification demandant à l'utilisateur de fournir plusieurs preuves d'identité, aussi appelés facteurs. Les facteurs sont communément séparés en quatre types : Facteurs de connaissance : mot de passe, code confidentiel, etc. Facteurs physiques : smartphone, badge, clé USB, etc. Facteurs biologiques : empreinte digitale, reconnaissance faciale ou vocale, etc. Facteurs de localisation : connexion réseau, position géographique, etc. Dans un exemple, compatible avec les exemples précédents, l’accès à la zone permettant de gérer une situation d’urgence est soumise à une autorisation d’accès « physique », cette étape fait office de premier niveau de validation et authentifie l’utilisateur situé au sol comme étant capable d’assumer la responsabilité de toute action vis-à-vis de l’aéronef. L’authentification multifactorielle permet l’accès au niveau de l’environnement à la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence. Une visualisation déportée consiste ici à proposer une visualisation du poste de pilotage de l’aéronef pour un utilisateur situé dans le centre d’assistance. Cette déportation de la visualisation permet donc à un utilisateur, qui n’est pas physiquement dans l’aéronef, de voir en temps réel l’état du poste de pilotage afin par exemple de conseiller le pilote situé dans l’aéronef. Dans un exemple, compatible avec l’exemple précédent, l’authentification multifactorielle 140 comprend 4 sous-étapes 141 à 144. La montre une représentation schématique d’un exemple de l’étape 140 du procédé 100. La première sous-étape 141 de l’étape 140 consiste à générer un mot de passe aléatoire par le gestionnaire d’accès distant 580. Une seconde sous-étape 142 de l’étape 140 consiste à envoyer un message ACARS, comprenant le mot de passe généré, via le réseau ACARS à l’environnement sol 700. Une troisième sous-étape 143 de l’étape 140 consiste à recevoir le message par l’environnement sol 700 et à saisir le mot de passe. La saisie du mot de passe est par exemple effectuée par un utilisateur. De plus, dans un exemple, le processeur 582 peut attendre un temps limité, par exemple 30 secondes, pour permettre au pilote déporté de saisir le mot de passe sur un écran de l’environnement sol 700. Si le pilote au sol se trompe de mot de passe ou répond au-delà du temps limité, le processeur 582 génère un nouveau mot de passe qui est envoyé à l’environnement sol 700 via le réseau ACARS. Lorsque le mot de passe saisi par l’utilisateur est authentifié, la quatrième sous-étape 144 de l’étape 140 consiste à activer les flux de diffusion permettant la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence. Dans un autre exemple, l’authentification multifactorielle est effectuée en se basant sur un mécanisme de mot de passe à usage unique basé sur le temps, « One-Time Password » en anglais ou sur un mécanisme d’authentification « Google authenticator ». Dans un exemple, compatible avec les exemples précédents, le procédé 100 comprend en outre 7 étapes 150 à 210 optionnelles. Dans cet exemple, la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence comprend en outre une interface utilisateur. L’interface utilisateur permet notamment à l’utilisateur d’interagir avec le poste de pilotage via une interaction appliquée sur la visualisation déportée tel qu’un clic sur un bouton. Les étapes 150 à 210 sont par exemple mis en œuvre à chaque action demandée par le pilote au sol. L’étape optionnelle 150 du procédé 100 consiste à recevoir par l’interface utilisateur une interaction initiée par l’utilisateur situé au sol. De plus, l’interaction correspond à une commande du poste de pilotage de l’aéronef, comme l’arrêt, le redémarrage ou la modification de paramètres de fonctionnement d’un système de l’aéronef. L’étape optionnelle 160 du procédé 100 consiste à envoyer un message signé de l’environnement sol 700 vers l’environnement embarqué 500. Le message signé comprend la commande, ou une information permettant à l’environnement embarqué 500 d’identifier la commande, et un champ additionnel renseigné de manière aléatoire. Dans un exemple, la signature du message utilise également des clés asymétriques et/ou certificats. Ces clés asymétriques et/ou certificats sont différentes des clés et/ou certificats utilisés pour mettre en place le lien de communication sécurisé. L’étape optionnelle 170 du procédé 100 consiste à recevoir le message signé. La réception est effectuée par l’environnement embarqué 500. L’étape optionnelle 180 du procédé 100 consiste à authentifier le message signé. Par exemple, le processeur reçoit le message, déchiffre et vérifie la signature contenant la commande et le champ aléatoire. Lorsque le message signé est authentifié 180, l’environnement embarqué 500 envoie dans une étape 190 un message ACARS et un message IP à l’environnement sol 700. Dans l’exemple précédent, le processeur prend le contenu du champ aléatoire et le retourne à l’environnement sol 700 via un message ACARS et via un message IP. L’étape optionnelle 200 du procédé 100 consiste à réaliser la commande comprise dans le message signé. La commande est réalisée au niveau de l’aéronef dans le poste de pilotage. Dans l’exemple précédent, le processeur traduit le message de commande interactive d’urgence en une commande intelligible par le module 510 gestionnaire de pages systèmes, d’exécution NNC et pilotage RCCP. Cette commande est ensuite réalisée au niveau de l’environnement embarqué 500. L’étape optionnelle 210 du procédé 100 consiste à mettre à jour la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence. Ainsi, une fois l’action réalisée au niveau de l’aéronef, le résultat est disponible via le flux de diffusion. L’environnement sol 700 est ainsi alimenté par des données générées par l’aéronef en permanence pour alimenter la visualisation déportée et aider l’équipage sol à avoir la vision et suivre les évolutions du poste de pilotage. Dans un exemple, compatible avec les exemples précédents, le procédé 100 comprend en outre une étape optionnelle 220 de déclaration de fin de situation d’urgence lorsque l’aéronef a atterrit. L’étape 220 de déclaration de fin d’urgence comprend trois sous-étapes 221 à 223. La montre une représentation schématique d’un exemple de l’étape 220 du procédé 100. La première sous-étape 221 de l’étape 220 consiste à redémarrer le gestionnaire d’accès distant 580 et le système 620 de connectivité IP dédiés à la gestion de la situation d’urgence au niveau de l’environnement embarqué 500. Par exemple, l’alimentation électrique du gestionnaire d’accès distant 580 et du système 620 de connectivité IP dédiés à la gestion de la situation d’urgence peut être arrêtée puis redémarrée. La seconde sous-étape 222 de l’étape 220 consiste à supprimer la connexion sécurisée au niveau de l’environnement sol 700. La suppression de la connexion sécurisée au niveau de l’environnement peut consister à la réfuter. La troisième sous-étape 223 de l’étape 220 consiste à mettre à jour la clé publique et la clé privée. Cette étape 223 pouvant être effectuée avant que l’aéronef ne reprenne son service. Dans un exemple, à partir du moment où un aéronef active la gestion d’une situation d’urgence, ce mode de fonctionnement sera actif jusqu’à ce que la mission soit considérée comme entièrement réalisée à savoir lorsque l’aéronef est arrêté, moteurs éteints et positionné à une passerelle. Une fois ces conditions remplies, un opérateur de maintenance au sol pourra effectuer une opération permettant à l’aéronef de revenir dans une situation normale. Un exemple d’opération permettant à l’aéronef de revenir dans une situation normale est de couper toutes les sources d’alimentation électrique pour éteindre l’intégralité des systèmes et composants de l’aéronef, attendre quelques minutes puis réalimenter les systèmes et composants et enfin vérifier que l’aéronef redémarre correctement dans un mode « non urgence ». Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. Procédé (100) d’établissement d’une connexion sécurisée de bout en bout entre un environnement embarqué (500) d’un aéronef et un environnement sol (700) d’un centre d’assistance situé au sol, la connexion sécurisée étant dédiée exclusivement à une gestion d’une situation d’urgence avec : L’environnement embarqué (500) comprenant un gestionnaire d’accès distant (580) et un système (620) de connectivité IP dédiés à la gestion de la situation d’urgence, le gestionnaire d’accès distant (580) comprenant un premier module (581) de filtrage matériel multi-réseaux et le système (620) de connectivité IP étant en liaison avec le gestionnaire d’accès distant (580) via le module (581) de filtrage matériel multi-réseaux, et L’environnement sol (700) comprenant un gestionnaire (710) de connexion d’urgence dédié à la gestion de la situation d’urgence, le gestionnaire (710) de connexion d’urgence comprenant un second module (711) de filtrage matériel multi-réseaux, Le procédé comprenant : Envoyer (110) un premier message « Aircraft Communication Addressing and Reporting System » ACARS via un réseau ACARS, le premier message ACARS étant envoyé par l’environnement embarqué (500) à l’environnement sol (700) lorsqu’une situation d’urgence concernant l’aéronef est détectée, Recevoir et décoder (120) le premier message ACARS par l’environnement sol (700) du centre d’assistance, Lorsque le premier message ACARS est considéré comme décrivant une situation d’urgence, activer (130) un environnement confidentiel dédié à la gestion de la situation d’urgence, l’activation de l’environnement comprenant : Envoyer (131) un second message ACARS via le réseau ACARS, le second message ACARS étant envoyé par l’environnement sol (700) à l’environnement embarqué (500) et le second message ACARS contenant une confirmation de la prise en compte de la situation d’urgence Mettre en place (132) un nuage (630) « multiprotocol label switching » MPLS entre le système de connectivité IP (620) et le système (720) de connexion aux fournisseurs de service d’accès au réseau IP, Etablir (133) une connexion (590, 800) au nuage (630) MPLS par les premier et second modules (581, 711) de filtrage matériel multi-réseaux, et Etablir (134) une connexion sécurisée entre l’environnement embarqué (500) et l’environnement sol (700) via un chiffrement hybride à l’aide d’une clé publique et d’une clé privée, la clé publique étant accessible par l’environnement sol (700) et l’environnement embarqué (500) et la clé privée étant accessible exclusivement par l’environnement sol (700), l’établissement d’une connexion sécurisée comprenant le chiffrement de messages permettant l’établissement de la liaison sécurisée à l’aide de la clé publique, les messages chiffrés étant envoyés au sein du nuage (630) MPLS et au moins l’un des messages chiffrés permettant le partage de la clé privée. Procédé (100) selon la revendication 1 comprenant en outre une authentification multifactorielle afin d’accéder à une visualisation déportée d’un poste de pilotage de l’aéronef en situation d’urgence, la visualisation déportée étant effectuée au niveau de l’environnement sol. Procédé selon la revendication 2 dans lequel l’authentification multifactorielle (140) comprend : Générer (141) un mot de passe aléatoire par le gestionnaire d’accès distant (580), Envoi (142) d’un troisième message ACARS comprenant le mot de passe généré via le réseau ACARS à l’environnement sol (700), Réception (143) du troisième message par l’environnement sol (700) et saisie du mot de passe par un utilisateur, et Lorsque le mot de passe saisi par l’utilisateur est authentifié, la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence est activée (144). Procédé (100) selon la revendication 2 ou 3 dans lequel la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence comprend en outre une interface utilisateur, le procédé (100) comprenant en outre : Réception (150) par l’interface utilisateur d’une interaction initiée par l’utilisateur, l’interaction correspondant à une commande du poste de pilotage de l’aéronef, Envoi (160) d’un message signé, le message signé comprenant la commande et un champ additionnel renseigné de manière aléatoire, Réception (170) du message signé par l’environnement embarqué (500), Lorsque le message signé est authentifié (180) par l’environnement embarqué (500) : Envoi (190) par l’environnement embarqué (500) d’un quatrième message ACARS et d’un message IP à l’environnement sol (700), Réalisation (200) de la commande comprise dans le message signé, la commande étant réalisée dans le poste de pilotage, et Mise à jour (210) de la visualisation déportée du poste de pilotage de l’aéronef en situation d’urgence. Procédé (100) selon l’une quelconque des revendications précédentes comprenant en outre une déclaration (220) de fin de situation d’urgence lorsque l’aéronef a atterrit, la déclaration de fin d’urgence comprenant : Redémarrer (221) le gestionnaire d’accès distant (580) et du système (620) de connectivité IP dédiés à la gestion de la situation d’urgence au niveau de l’environnement embarqué (500), Supprimer (222) la connexion sécurisée au niveau de l’environnement sol (700), et Mettre à jour (223) la clé publique et la clé privée. Environnement embarqué (500) d’un aéronef comprenant un gestionnaire d’accès distant (580) et un système (620) de connectivité IP dédié à la gestion de la situation d’urgence, le gestionnaire d’accès distant (580) comprenant un module de filtrage matériel multi-réseaux (511) et le système (620) de connectivité IP étant en liaison avec le gestionnaire d’accès distant (580) via le module de filtrage matériel multi-réseaux, l’environnement embarqué (500) étant configuré pour mettre en œuvre un procédé selon l’une des revendications précédentes. Aéronef comprenant un environnement embarqué (500) selon la revendication précédente. Environnement sol (700) d’un centre d’assistance situé au sol comprenant un gestionnaire (710) de connexion d’urgence, le gestionnaire (710) de connexion d’urgence comprenant un second module de filtrage matériel multi-réseaux (711), l’environnement sol (700) étant configuré pour mettre en œuvre un procédé selon l’une des revendications 1 à 5. Programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent l’environnement embarqué et l’environnement sol selon les revendications 6 et 8 à exécuter au moins une des étapes de la méthode selon l’une des revendications 1 à 5. Support lisible par ordinateur, sur lequel est enregistré le programme d'ordinateur selon la revendication précédente.