FR2926692A1 - Procedes et dispositifs pour ameliorer la fiabilite de communication entre un aeronef et un systeme distant - Google Patents

Abstract

L'invention a pour objet des procédés et des dispositifs pour améliorer la fiabilité de communication entre un aéronef et un système distant. Selon l'invention, l'aéronef transmet (200) une requête de vérification de sûreté à un système distant. A la réception (205) de la répcnse à cette requête comprenant au moins une indication relative à la sûreté du système distant, l'aéronef analyse cette indication et décide d'établir ou non une communication de données entre l'aéronef et le système distant. Lorsqu'une requête de vérification est reçue, le système distant est vérifié et une réponse à la requête est transmise à l'aéronef.

Description

La présente invention concerne la communication de données entre un aéronef et un système distant, par exemple un systèrne au sol ou un autre aéronef. Plus particulièrement, la présente invention concerne des procédés et des dispositifs pour améliorer la fiabilité de communication entre un aéronef et un système distant permettant notamment à l'aéronef de s'assurer que le système distant est sûr avant d'échanger des données. Les nouvelles générations d'avions, tels que par exemple les Airbus A380, A350 et A400M (Airbus, A380, A350 et A400M sont des marques), permettent d'échanger des données propres à l'avion, notamment avec des systèmes au sol. Ces données concernent par exemple des paramètres de l'avion transmis de l'avion à un système au sol pour faciliter les opérations de maintenance au sol. Ces données peuvent également concerner des indications ou des instructions reçues par un avion d'un système au sol relatives, par exemple, à des paramètres de vol tels que la trajectoire que doit suivre l'avion.

De telles données sont échangées entre l'avion et un ou plusieurs systèmes au sol. Les systèmes au sol peuvent notamment être gérés par les compagnies aériennes, le fabriquant de l'avion et/ou des sociétés de maintenance. Afin d'améliorer et de sécuriser l'échange de données entre avions et/ou entre un avion et un système au sol, les données échangées sont généralement compressées et chiffrées. La demande de brevet WO 2007/110509 présente ainsi des procédés et des dispositifs de traitement de données pour "émission et la réception de ces données entre un avion et un système au sol.

Cependant, si de tels procédés et dispositifs permettent de sécuriser la transmission de données entre un avion et un système au sol, ils ne prennent pas en compte la vulnérabilité éventuelle du dispositif communiquant avec l'avion. Ainsi, un avion communiquant avec un système au sol n'a aucune garantie sur la sûreté du système distant. Il est donc possible d'envisager l'hypothèse selon laquelle le système au sol, infecté par un virus informatique ou sous le contrôle d'un pirate informatique, transmettrait des données erronées à l'avion. Par conséquent, il existe un risque que le chargement de données compromises sur avion provoque des pannes ou des dysfonctionnements sur les systèmes embarqués. L'invention permet de résoudre au moins un des problèmes exposés 10 précédemment. L'invention a ainsi pour objet un procédé pour améliorer la fiabilité de communication de données entre un aéronef et un système distant, ce procédé comprenant les étapes suivantes, - transmission d'une requête de vérification de la sûreté dudit 15 système distant ; - réception, en réponse à ladite requête, d'au moins une indication relative à la sûreté dudit système distant ; - analyse de ladite indication ; et, - en réponse à ladite analyse, établissement ou non de ladite 20 communication de données entre ledit aéronef et ledit système distant. Le procédé selon l'invention permet ainsi à un aéronef de s'assurer que le système distant est sûr avant toute communication avec ce dernier. Le risque que les données échangées portent atteinte à l'intégrité de l'aéronef est donc limité. 25 Selon un mode de réalisation particulier, le procédé comprend en outre une étape de transmission d'un module applicatif adapté à analyser la sûreté dudit système distant. Il est ainsi possible d'augmenter la fiabilité du test du système distant en contrôlant directement le module d'analyse de sûreté. L'invention a également pour objet un procédé pour améliorer la 30 fiabilité de communication de données entre un aéronef et un système distant, ce procédé comprenant les étapes suivantes, - réception d'une requête de vérification de la sûreté dudit système distant ; - vérification de la sûreté dudit système distant ; et, - transmission d'une réponse à ladite requête, ladite réponse comprenant au moins une indication relative à ladite vérification. Le procédé selon l'invention permet ainsi de répondre à une requête d'un aéronef permettant à celui-ci de s'assurer que le système distant est sûr avant toute communication avec ce dernier. Le risque que les données échangées portent atteinte à l'intégrité de l'aéronef est donc limité.

Selon un mode de réalisation particulier, le procédé comprend en outre des étapes de réception et d'installation d'un module applicatif adapté à analyser la sûreté dudit système distant. L'aéronef est ainsi en mesure de contrôler directement le module d'analyse de sûreté du système distant. De façon avantageuse, ladite requête de vérification est transmise à un système tiers, ladite étape de vérification étant mise en oeuvre au mcins partiellement par ledit système tiers. L'intervention d'un tiers dans le processus de vérification de sûreté du système distant permet d'accroître la fiabilité de la réponse du système distant, le tiers pouvant être contrôlé par une autorité distincte de celle du système distant.

Avantageusement, ladite réponse est au moins partiellement reçue dudit système tiers, ladite partie de ladite réponse reçue dudit système tiers étant au moins partiellement chiffrée par ledit système tiers pour limiter les risques de falsification de celle-ci. Selon un mode de réalisation particulier, ladite au moins une indication représente un niveau de sûreté dudit système distant. L'aéronef est ainsi en mesure d'évaluer lui-même le niveau de sûreté dudit système distant. Toujours selon un mode de réalisation particulier, ladite requête de vérification comprend au moins une référence à une instruction permettant de vérifier au moins un élément de sûreté dudit système distant. L'aéronef est ainsi en mesure de vérifier des points de sûreté particuliers du système distant. Toujours selon un mode de réalisation particulier, ladite requête de vérification comprend une indication relative à un niveau de sûreté requis dudit système distant pour permettre à l'aéronef d'exiger un niveau de sûreté minimal. L'invention a également pour objet un aéronef comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit 5 précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : -la figure 1 représente schématiquement un exemple 10 d'environnement dans lequel l'invention peut être mise en oeuvre ; - la figure 2 illustre certaines étapes d'un exemple d'algorithme mettant en oeuvre l'invention pour améliorer la fiabilité de communication entre un aéronef et un système au sol ou entre deux aéronefs ; - la figure 3 illustre certaines étapes d'un exemple particulier 15 d'algorithme mis en oeuvre dans un aéronef, conformément à l'invention ; - la figure 4, comprenant les figures 4a et 4b, illustre certaines étapes de deux exemples particuliers d'algorithme mis en oeuvre dans un système au sol, conformément à l'invention ; - la figure 5 illustre certaines étapes d'un exemple particulier 20 d'algorithme mis en oeuvre dans un système d'un tiers de confiance, conformément à l'invention ; et, - la figure 6 montre un exemple de dispositif permettant d'implémenter au moins partiellement l'invention. La figure 1 illustre schématiquement un exemple d'environnement 25 dans lequel l'invention peut être mise en oeuvre. Comme illustré, un aéronef 100 comprenant des moyens de communication sans fil peut recevoir des données d'une station de base au sol 105 et transmettre des données à celle-ci. Les données peuvent être transmises via une communication par satellite, ici via le satellite 110, ou directement, par exemple via une communication radio 30 HF (sigle de high frequency en terminologie anglo-saxonne) ou VHF (sigle de very high frequency en terminologie anglo-saxonne).

La liaison entre l'aéronef 100 et la station de base au sol 105 forme un canal de communication, de préférence sous forme numérique, appelé data link en terminologie anglo-saxonne. Cette liaison de communication est ici bidirectionnelle.

La station de base au sol 105 est reliée à un système au sol 115. Elle forme un relais permettant le transfert de données entre l'aéronef 100 e.: le système au sol 115 qui est de préférence indépendant du mode de transfert des données entre l'aéronef 100 et la station de base au sol 135. Alternativement, un canal de communication peut être établi directement ertre l'aéronef 100 et le système au sol 115. Il est ici considéré qu'un système est un système informatique pouvant consister, par exemple, en une machine telle qu'un serveur, un ordinateur ou une station de travail ou à plusieurs machines connectées en réseau.

De même, selon les besoins, un même aéronef peut établir plusieurs canaux de communication vers un système au sol ou vers plusieurs systèmes au sol. Par exemple, un premier système au sol peut être lié à une société de maintenance, un second au fabriquant de l'aéronef et un troisième à la compagnie aérienne de l'aéronef. Dans ce cas, les trois systèmes au sol peuvent être reliés à une seule station de base au sol ou à plusieurs. Plusieurs canaux de communication peuvent être utilisés simultanément. L'établissement de canaux de communication est ici réalisé de façon standard. Selon un mode de réalisation particulier, un système d'un tiers de confiance, appelé système tiers 120, est connecté au système au sol 115. Les connexions entre la station de base au sol 105 et le système au sol 115 et entre le système tiers 120 et le système au sol 115 sant avantageusement standard, filaires ou non, telles que des connexions Ethernet ou WiFi.

Si plusieurs systèmes au sol sont mis en oeuvre, ils peuvent être reliés à un seul système tiers ou à plusieurs.

Dans un souci de clarté, ne sont considérés ici qu'un système au sol et qu'un système tiers. Si plusieurs systèmes au sol et/ou plusieurs systèmes tiers sont utilisés, il est nécessaire d'utiliser des identifiants. L'utilisation de tels identifiants est bien connue l'homme de l'art.

Comme illustré sur la figure 2 et de façon générale, l'aéronef 100 transmet une requête de vérification au système au sol 115 (étape 200), via la station de base au sol 105, avant de transmettre des données propres à l'aéronef 100 ou de recevoir des données pouvant compromettre la sécurité de l'aéronef 100. Après vérification du système au sol 115, certifiée ou non par le système tiers 120, le système au sol 115 répond à la requête de vérification. Après avoir reçu cette réponse (étape 205), l'aéronef 100 l'analyse pour déterminer si le système au sol 115 est sûr (étape 210). Si le système au sol 115 est sûr, l'aéronef 100 peut recevoir et/ou transmettre des données (éte pe 215).

Si le système au sol 115 n'est pas sûr, l'aéronef 100 ne transmet ni ne reçoit de donnée de ce système. Un message est alors, de préférence, transmis au système au sol, plus particulièrement à l'administrateur de ce système, pour demander la mise en conformité du syslème au sol avec les exigences requises de l'aéronef (étape 220).

Il peut exister des situations intermédiaires selon lesquelles le système au sol est partiellement sûr. Dans ce cas, seuls certains types de données peuvent être échangés. De façon avantageuse, les communications entre l'aéronef et le système au sol sont sécurisées durant cette phase de vérification. La sécurisation des communications consiste par exemple à chiffrer les informations transmises ou à utiliser un tunnel de communication chiffré. La vérification du système au sol est de préférence réalisée à l'aide d'un module applicatif de vérification installé dans le système au sol qui peut contrôler plusieurs aspects du système au sol pour déterminer son état de sécurité. Ce module applicatif de vérification peut être installé temporairement dans le système au sol, le temps de la vérification, ou installé de façon permanente.

Si le module applicatif est installé de façon temporaire, il peut notamment être transmis par l'aéronef, par exemple avec la requête de vérification, ou par un système distinct, notamment par un système d'un tiers de confiance, sur requête de l'aéronef.

Si le module applicatif est installé de façon permanente, il peut ê:re contrôlé régulièrement par un système d'un tiers de confiance ou sur requête de l'aéronef afin de vérifier que ce module n'a pas été substitué par un autre. La nature des vérifications effectuées par le module applicatif peut être liée à la façon dont il est installé.

Ainsi, quelle que soit la façon dont il est installé, il peut vérifier les éléments suivants : - conformité de la version du système ; - conformité de la version de mise à jour de logiciels installés ; - conformité de la version de mise à jour des définitions de virus dans un logiciel anti-virus ; - conformité des ports de communication ouverts et des services associés (pouvant révéler la présence d'un accès secret qui pourrait être utilisé pour accéder frauduleusement au système au sol) ; -présence ou absence de services prédéterminés (par exemple de services liés à Internet tels que des services ssh, web ou e-mail) ; - activation de certains services prédéterminés (par exemple de services du type pare-feu, appelé firewall en terminologie anglo-saxonne, ou d'autorisation de flux) ; et, - respect de règles prédéterminées (par exemple la composition et la fréquence de modification des mots de passe utilisés). D'autres éléments, tels que les éléments suivants, ne sont avantageusement contrôlés que par des modules applicatifs installés de façon permanente, -absence de détection de virus durant un délai prédéterminé ; - absence de modification de fichiers prédéterminés (par exemples de fichiers systèmes) durant un délai prédéterminé ; - pertinence de la protection d'accès (par exernple par tentatives de mots de passe génériques) ; - absence de débordement, aussi appelé overflow en terminologie anglo-saxonne, de la mémoire tampon du système ; - absence de service installé non autorisé ; -absence de connexion autorisée après de nombreuses tentatives ; et, -absence de vulnérabilité (par exemple par recherche des ports de communication ouverts et des tentatives d'intrusion sur ces ports).

Naturellement, de nombreux autres éléments peuvent être utilisés. Par exemple, les éléments suivants, sans être des critères de sûreté du système au sol, peuvent être utilisés comme indicateurs ou indices de confiance, - absence de détection d'intrusion par les NIDS (sigle de Network Intrusion Detection System en terminologie anglo-saxonne) ; -absence de détection d'intrusion par les HIDS (sigle de Host Intrusion Detection System en terminologie anglo-saxonne) externes ou intégrés au module applicatif de vérification ; et, - absence de détection d'anomalie par rapport à une utilisation normale du système au sol. La vérification de ces éléments est de préférence réalisée de façon standard. Selon un premier mode de réalisation, le rnodule applicatif de vérification comprend une liste de tous les éléments à vérifier. Ainsi, lorsque la requête de vérification est transmise au système au sol, la réponse du système au sol est positive si tous les éléments sont vérifiés et négative si au moins un élément n'est pas vérifié. Selon un second mode de réalisation, la requête de vérification comprend une indication des éléments qui doivent être vérifiés. Selon ce mode de réalisation, un index peut être associé à chaque élément utilisé pour vérifier la sûreté du système au sol. De même, un index peut être associé à plusieurs éléments prédéterminés. De façon avantageuse, une liste d'indexes est mémorisée dans l'aéronef et dans le système au sol ou dans un système tiers. Ainsi, lorsque le système au sol reçoit la requête de vérification comprenant une liste d'indexes, le module applicatif est en mesure de déterminer quels sont les éléments qui doivent être vérifiés.

Selon un troisième mode de réalisation, un score est associé à chaque élément. Il est également possible d'affecter un coefficient à chaque élément. Ainsi, la sûreté du système au sol peut être graduelle. Par exemple, le score associé à la conformité de la version de mise à jour des définitions de virus dans un logiciel anti-virus peut varier de 0 à 10 de la façon suivante : 10 si la version est la dernière, 5 si la version est l'avant dernière, 2 si la version a moins de quinze jours et 0 dans tous les autres cas. Le résultat de la vérification prend ainsi la forme d'un sccre consistant en la combinaison, par un exemple une combinaison linéaire, des résultats de vérification obtenus pour chacun des éléments vérifiés.

Le score obtenu peut être vérifié par l'aéronef, le système au sol ou un système tiers. Dans les deux derniers cas, le score exigé par l'aéronef est de préférence transmis dans la requête de vérification. Par ailleurs, l'aéronef peut exiger qu'au moins une partie des vérifications effectuées soit certifiée par un tiers de confiance. 2.0 Ainsi, de façon générale la requête de vérification peut prendre la forme suivante dans laquelle chaque paramètre est optionnel : Securitycheck request(ID_module, liste indexes, score, certif) Le paramètre ID module est un identifiant du module applicatif devant être utilisé pour vérifier la sûreté du système au sol. Cet identifiant peut 25 faire référence à un message transmis par l'aéronef et contenant ce module. II peut également être un chemin dans un arbre pour trouver le module sur le système au sol ou dans un système distinct. Un tel chemin est par exemple de la forme adresse_system/dirl/dir2/module.exe où adresse _system est l'adresse du système ou du serveur sur lequel se trouve le module applicatif, /dirl/dir2/ 30 est le chemin d'accès au module à partir de la racine du système ou du serveur identifié et module.exe est le nom du module applicatif.

Si le paramètre ID module n'est pas renseigné, le module applicatif devant être mis en oeuvre est celui désigné par défaut dans le système au sol. Si aucun module applicatif n'est désigné par défaut dans le système au sol, la réponse du système au sol est l'échec de la vérification comprenant éventuellement un code indiquant le type d'échec. Le paramètre liste_indexes est la liste des indexes des éléments devant être vérifiés. Un caractère prédéterminé est de préférence inséré entre chaque index. Si le paramètre liste_indexes n'est pas renseigné, tous les éléments sont de préférence vérifiés.

Le paramètre score précise le niveau de vérification requis par l'aéronef. Une valeur particulière, par exemple -1, est avantageusement utilisée pour demander au système au sol de transmettre le score obtenu durant la vérification afin de permettre à l'aéronef de déterminer si le score est suffisant ou non. Si le paramètre score n'est pas renseigné, tous les éléments doivent être vérifiés, la réponse du système au sol étant positive si tous les éléments sont vérifiés et négative si au moins un élément n'est pas vérifié. Le paramètre certif donne une indication quant à la certification de la vérification par un tiers de confiance. Ce paramètre peut être, par exemple, une concaténation d'un index représentant l'identifiant d'un tiers de confiance et d'un code représentant le niveau de certification requis. A titre d'illustration, un tel code peut être caractéristique d'un ensemble d'éléments à vérifier, c'est-à-dire que le code correspond ici à une liste des indexes des éléments à vérifier. Si le paramètre certif n'est pas renseigné, la vérification effectuée par le système au sol n'est pas certifiée.

La requête suivante illustre un exemple de requête pouvant être utilisée par un aéronef pour vérifier un système au sol, Securitycheck request(9.23.4/system/verif.exe, 1/2/5/22, -1, 5-2/22) Dans cet exemple, le module applicatif devant être utilisé par le système au sol, nommé verif.exe, est accessible sur la machine ayant l'adresse 9.23.4 dans le répertoire system. Seuls les éléments 1, 2, 5 et 22 doivent être vérifiés. L'élément 22 correspond, par exemple, aux éléments ayant les indexes 9, 10, 11 et 12. Le paramètre -1 indique que l'aéronef demande au système au sol de lui transmettre le score obtenu par la vérification des éléments 1, 2, 5 et 22 à l'aide du moclule applicatif désigné. Enfin, la valeur 5 du paramètre 5-2/22 indique qu'au moins une partie de la vérification doit être certifiée par le tiers de confiance ayant l'identifiant 5 tandis que l'indication 2/22 précise que la vérification des éléments ayant les indexes 2, 9, 10, 11 et 12 doit être certifiée. De façon avantageuse, le temps de réponse du système au sol est mesuré et comparé à un ou plusieurs seuils. Ainsi, par exemple, si la vérification du système au sol est positive et que le temps de réponse est inférieur à un premier seuil, l'aéronef accepte de transmettre ou de recevoir des données. Si la vérification du système au sol est positive et que le temps de réponse est supérieur au premier seuil mais inférieur à un second seuil, l'aéronef n'accepte de transmettre ou de recevoir que certains types de données. Enfin, si la vérification du système au sol est positive et que le temps de réponse est supérieur au second seuil, l'aéronef n'accepte de transmettre ou de recevoir aucune donnée. La réponse transmise par un système au sol à un aéronef suite à une requête de vérification peut prendre la forme suivante, Securitycheck response(valid, error code) où valid est un indicateur, par exemple un indicateur booléen, qui indique si la vérification est positive (l'indicateur valid prend alors une première valeur) ou si la vérification est négative (l'indicateur valid prend alors une seconde valeur). La variable error code est un code d'erreur utilisé si la vérification du système au sol a rencontré un problème afin de fournir à l'aéronef une indication sur la nature de ce problème.

Alternativement, la réponse transmise par un système au sol à un aéronef suite à une requête de vérification peut prendre la forme suivante, Securitycheck response(score, error code) où score correspond au résultat de la vérification, c'est-à-dire, par exemple, à la somme pondérée des résultats obtenus par chacun des éléments vérifiés. Si le résultat de la vérification doit être certifié, le paramètre transmis à l'aéronef (valid ou score) est de préférence chiffré, le déchiffrage permettant d'authentifier le tiers de confiance et ainsi de reconnaître la certification. _e chiffrage/déchiffrage peut être mis en oeuvre à l'aide d'algorithmes à clés standard. La figure 3 illustre certaines étapes d'un exemple particulier d'algorithme mis en oeuvre dans un aéronef, conformément à l'invention, peur améliorer la fiabilité de communication entre cet aéronef et un système au sol. Après avoir établi un canal de communication entre cet aéronef et un système au sol selon un mécanisme standard (étape 300), l'aéronef transmet le module applicatif devant être utilisé pour vérifier la sûreté du système au sol (étape 305). Ce module applicatif est de préférence un code exécutable indépendant du système d'exploitation du système au sol. Le module applicatif est par exemple du code Java (Java est une marque) semi-compilé. Une requête de vérification est alors transmise au système au sol (étape 310). L'aéronef attend alors la réponse à cette requête (comme suggéré par la flèche pointillée). Après avoir reçu la réponse à la requête de vérification (étape 315), l'aéronef détermine le temps écoulé entre la transmission de la requête et la réception de la réponse à celle-ci. Ce temps est comparé à un seuil prédéterminé 12 (étape 320).

Si le temps écoulé entre la transmission de la requête et la réception de la réponse à celle-ci est supérieur au seuil .12, un message de mise en conformité est de préférence adressé au système au sol, avantageusement à l'administrateur de ce système, afin de demander la mise en conformité du système au sol avec les exigences requises de l'aéronef (étape 325).

Au contraire, si le temps écoulé entre la transmission de la requête et la réception de la réponse à celle-ci est inférieur ou égal au seuil l2, l'aéronef analyse la réponse transmise par le système au sol (étape 330). Il convient de remarquer ici que, comme indiqué précédemment, le temps écoulé entre la transmission de la requête et la réception de la réponse à celle-ci peut être comparé à un second seuil prédéterminé .1-1. Ainsi, si le temps écoulé est compris entre les seuils t1 et 12, seules la transmission et/ou la réception de certains types de données ne sont autorisées tandis que si le temps écoulé est inférieur à 1, tous les types de données peuvent être échangés. Naturellement, il est possible d'utiliser plus de deux seuils. Selon la réponse reçue, l'analyse de celle-ci réside simplement dans la détermination de la réponse (positive ou négative) ou dans la comparaison de scores. Si un score est transmis dans la réponse, celui-ci peut être comparé avec un ou plusieurs seuils prédéterminés mémorisés dans l'aéronef. Selon le résultat de cette comparaison, l'aéronef peut décider de transmettre et/ou de recevoir tous les types de données, de ne transmettre et/ou de ne recevoir que certains types de données ou de ne transmettre et de ne recevoir aucun type de données. Si l'aéronef décide de ne transmettre et de ne recevoir aucun type de données, un message de mise en conformité est de préférence adressé au système au sol (étape 325).

Au contraire, si l'aéronef décide de transmettre et/ou de recevoir au moins certains types de données, des données peuvent être échangées entre l'aéronef et le système au sol (étape 335), comme suggéré par les flèches pointillées. Après avoir transmis un message de mise en conformité ou après 2.0 avoir échangé des données, une requête de désinstallation du module applicatif de vérification est de préférence transmise au système au sol (étape 340). Il convient de remarquer que cette étape peut être exécutée dès que l'aéronef a reçu la réponse à la requête de vérification. La connexion entre l'aéronef et le système au sol est ensuite rompue 2.5 (étape 345). La figure 4, comprenant les figures 4a et 4b, illustre certaines étapes de deux exemples particuliers d'algorithme mis en oeuvre dans un système au sol, conformément à l'invention, pour améliorer la fiabilité de communication entre cet aéronef et un système au sol. 30 Selon le premier exemple illustré sur la figure 4a, le module applicatif de vérification est chargé de façon temporaire dans le système au sol. Après avoir établi un canal de communication entre un aéronef et le système au sol selon un mécanisme standard (étape 400), le système au sol reçoit de l'aéronef un module applicatif de vérification qui est ensuite installé (étape 405). Comme précisé précédemment, ce module est avantageusement un code exécutable indépendant du système d'exploitation du système au sol Il est donc, de préférence, directement exécutable. Si nécessaire, une étape de conversion (non représentée) est mise en oeuvre pour convertir le module applicatif reçu en module exécutable sur le système au sol. Lorsque le système au sol reçoit une requête de vérification (étape 410), il exécute e module applicatif de vérification reçu (étape 420). La vérification est effectuée, le cas échéant, selon les paramètres contenus dans la requête. Si au moins une partie de la vérification doit être certifiée par un tiers de confiance, une étape de certification est mise en oeuvre (étape 425). Une telle étape consiste par exemple à transmettre des résultats de vérification effectués par le module applicatif au système d'un tiers de confiance pour les comparer avec des résultats de vérification effectués préalablement par celui-ci. Si les résultats sont identiques, un certificat, de préférence chiffré, est transmis par le système du tiers de confiance au système au sol pour être transmis à l'aéronef.

Le résultat de vérification est alors transmis avec, le cas échéant, le certificat à l'aéronef (étape 430). En fonction de ce résultat, si l'aéronef le décide, des données peuvent être échangées entre l'aéronef et le système au sol (étape 435). Comme suggéré par le trait pointillé, l'autorisation permettant cet échange de données étant déterminée par l'aéronef, le système au sol agit comme un client de l'aéronef et répond à ses requêtes. Après que le système au sol ait reçu de l'aéronef une requête de désinstallation du module applicatif de vérification (étape 440), ce module est désinstallé (étape 445).

Lorsque le système au sol a été vérifié et que des données ont, éventuellement, été échangées, la connexion entre l'aéronef et le système au sol est rompue (étape 450).

Selon le second exemple illustré sur la figure 4b, le module applicatif de vérification est chargé de façon permanente dans le système au sol. Ce module applicatif comprend une fonction permettant d'effectuer régulièrement une vérification du système au sol et de transmettre un rapport de sécurité au système d'un tiers de confiance (étape 455). Après avoir établi un canal de communication entre un aéronef et le système au sol selon un mécanisme standard (étape 460), le système au sol peut recevoir de l'aéronef une requête de vérification (étape 465). Cette requête est ensuite transmise au système du tiers de confiance (étape 470) pour permettre à celui-ci d'évaluer la sûreté du système au sol à partir des rapports de sécurité reçus précédemment. Après que cette sûreté ait été évaluée, le système du tiers de confiance transmet une réponse à la requête au système au sol (étape 475) qui, à son tour, la transmet à l'aéronef (étape 480).

De façon avantageuse, la réponse reçue du tiers de confiance est chiffrée ou signée numériquement de telle sorte que le système au sol ne puisse pas la modifier, empêchant ainsi qu'un pirate ayant pris le contrôle du système au sol ne puisse modifier les résultats de l'évaluation de la sûreté du système au sol.

Comme dans l'exemple décrit précédemment en référence à la figure 4a, en fonction des résultats reçus, l'aéronef décide s'il autorise l'échange de données avec le système au sol (étape 485). Comme suggéré par le trait pointillé, l'autorisation permettant cet échange de données étant déterminée par l'aéronef, le système au sol agit comme un client de l'aéronef et répond à ses requêtes. Lorsque le système au sol a été vérifié et que des données ont, éventuellement, été échangées, la connexion entre l'aéronef et le système au sol est rompue (étape 490). La figure 5 illustre certaines étapes d'un exemple particulier d'algorithme mis en oeuvre dans un système d'un tiers de confiance, conformément à l'invention, pour améliorer la fiabilité de communication entre un aéronef et un système au sol.

Selon cet exemple, un module applicatif de vérification est chargé de façon permanente dans le système au sol. Comme décrit précédemment par référence à la figure 4b, ce module applicatif comprend une fonction permettant d'effectuer régulièrement une vérification du système au sol et de transmettre un rapport de sécurité au système d'un tiers de confiance (étape 500). Ces résultats de sûreté du système au sol sont de préférence mémorisés par le système tiers dans une base de données 505. Après avoir reçu du système au sol une requête de vérification (étape 510), le système du tiers de confiance vérifie la sûreté du système au sol (étape 515). Une telle vérification est effectuée, le cas échéant, selon es paramètres contenus dans la requête. Cette vérification peut notamment consister à analyser les rapports de sécurité mémorisés dans la base de données 505. Le résultat de la requête est alors, de préférence, chiffré ou signé numériquement selon un mécanisme standard (étape 520) de telle sorte que le système au sol ne soit pas en mesure de falsifier les résultats lorsque ceux:-ci sont transmis à l'aéronef puis transmis au système au sol (étape 525). Ainsi, le système du tiers de confiance a une vision sur une péricde de temps relativement longue permettant de déterminer si le système distant est sûr ou pas. Selon un mode de réalisation particulier, si l'aéronef ne reçoit pas de réponse du tiers de confiance, il peut décider de faire confiance au programme résident installé sur le système au sol à la condition de communiquer avec le système au sol selon un mode dégradé, c'est-à-dire un mode selon lequel seuls certains types de données peuvent être échangés. De façon avantageuse, le système du tiers de confiance comprend une application de surveillance de type heartbeat, selon lequel une communication périodique est établie entre le système du tiers de confiance et le système au sol, permettant au système du tiers de confiance de s'assurer du bon fonctionnement du module applicatif de vérification installé sur le système au sol. Cette application de surveillance permet de s'assurer que le module applicatif de vérification n'est pas éteint ou n'a pas été redémarré.

Comme indiqué précédemment, les canaux de communication utilisés par l'aéronef et le système au sol durant la phase de vérification du système au sol sont de préférence sécurisés. Une solution consiste à signer numériquement les informations échangées pour être certain que celles-ci sont issues de l'aéronef, du système au sol ou d'un tiers de confiance, c'est-à-dire qu'elles ne sont pas transmises par un pirate qui usurpe l'identité de l'aéronef, du système au sol ou du tiers de confiance. Une analyse de risques peut être nécessaire pour déterminer quelles sont les contre-mesures nécessaires pour empêcher que le certificat ide signature soit dérobé. Selon une première implémentation, le module applicatif de vérification utilise des certificats numériques déportés dans des cartes à puces ou dans des clés du type clés USB (sigle de Universel Serial Bus en terminologie anglo-saxonne) adaptés à protéger un certificat de signature. II est également possible d'intégrer le certificat numérique nécessaire à la signature dans le module applicatif de vérification lui-même. Des mécanismes de protection contre l'ingénierie inverse, appelée reverse engineering en terminologie anglo-saxonne, peuvent alors protéger le certificat stocké dans le module d'une éventuelle extraction. Plusieurs solutions existent, notamment les solutions suivantes, - l'offuscation : le code source est transformé avant compilation pour le rendre incompréhensible par un humain (par exemple en complexifiant le code ou en effectuant des transformations lexicales) ; - la mise en place de mécanismes anti-débogage (par exemple en vérifiant l'absence d'une application de débogage) et anti-vidage de la mémoire pour empêcher un tiers de récupérer les informations contenues dans la mémoire vive ; et/ou, - la compression et le chiffrement du certificat lui-même.

Le module applicatif de vérification peut ainsi être considéré comme une boite noire qui rend très difficile la récupération du certificat de signature et plus généralement la compréhension du mode de fonctionnement du module applicatif pour le pirate. Un dispositif adapté à mettre en oeuvre l'invention ou une partie le l'invention est illustré sur la figure 6. Le dispositif 600 est par exemple un calculateur, un micro-ordinateur ou une station de travail. Le dispositif 600 comporte ici un bus de communication 602 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 603 (CPU, Central Processing Unit) ; - une rnémoire morte 604 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes "Prog", "Progl" et "Prog2" ; - une mémoire vive ou mémoire cache 606 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, - une interface de communication 618 adaptée à transmettre et à recevoir des données. Optionnellement, le dispositif 600 peut également disposer : - d'un écran 608 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 610 ou d'un autre dispositif de pointage, un écran tactile ou une télécommande ; - d'un disque dur 612 pouvant comporter les programmes "Prog", "Progl" et "Prog 2" précités et des données traitées ou à traiter selon l'invention ; et, - d'un lecteur de cartes mémoires 614 adapté à recevoir une carte mémoire 616 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention.

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 612 ou en mémoire morte 604. Selon une variante, la carte mémoire 616 peut contenir des données, notamment des clés de chiffrement, ainsi que le code exécutable ces programmes précités qui, une fois lu par le dispositif 600, sera stocké dans le disque dur 612. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 618, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 600 avant d'être exécutés. L'unité centrale 603 va commander et diriger l'exécution ces instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 612 ou dans la mémoire morte 604 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 612 ou la mémoire morte 604, sont transférés dans la mémoire vive 606 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). Bien que la description précédente soit essentiellement orientée vers l'échange de données entre un aéronef et un système au sol, il convient de remarquer ici que l'invention est également adaptée à améliorer la fiabilité Ces communications entre plusieurs aéronefs. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications 5 dans la description précédente.

Claims (10)

REVENDICATIONS

1. Procédé pour aéronef (100) pour améliorer la fiabilité de communication de données entre ledit aéronef et un système distant (115), ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, -transmission (200) d'une requête de vérification de la sûreté dudit système distant ; - réception (205), en réponse à ladite requête, d'au moins une indication relative à la sûreté dudit système distant ; - analyse (210) de ladite indication ; et, - en réponse à ladite analyse, établissement ou non de ladite communication de données entre ledit aéronef et ledit système distant.

2. Procédé selon la revendication précédente comprenant en outre une étape de transmission (305) d'un module applicatif adapté à analyser la sûreté dudit système distant.

3. Procédé pour système distant (115) pour améliorer la fiabilité de communication de données entre un aéronef (100) et ledit système distant, ce procédé étant adapté à coopérer avec le procédé pour aéronef selon la revendication 1 ou la revendication 2, ce procédé pour système distant étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (410) de ladite requête de vérification de la sûreté dudit système distant ; - vérification (420) de la sûreté dudit système distant ; et, -transmission (430) d'une réponse à ladite requête, ladite réponse comprenant ladite au moins une indication relative à ladite vérification, ledit procédé permettant l'établissement d'une communication de données entre ledit aéronef et ledit système distant en fonction de l'analyse de ladite au moins une indication comprise dans ladite réponse.

4. Procédé selon la revendication précédente comprenant en outre des étapes de réception et d'installation (405) d'un module applicatif adapté à analyser la sûreté dudit système distant.

5. Procédé selon la revendication 3 ou la revendication 4 selon lequel ladite requête de vérification est transmise à un système tiers, ladite étape de vérification étant mise en oeuvre au moins partiellement par ledit système tiers.

6. Procédé selon la revendication 5 selon lequel ladite réponse est au moins partiellement reçue dudit système tiers, ladite partie de ladite réponse reçue dudit système tiers étant au moins partiellement chiffrée par ledit système tiers.

7. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite au moins une indication représente un niveau de sûreté dudit système distant.

8. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite requête de vérification comprend au moins une référence à une instruction permettant de vérifier au moins un élément de sûreté dudit système distant.

9. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite requête de vérification comprend une indication relative à un niveau de sûreté requis dudit système distant.

10. Aéronef comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 et 2 et des revendications 7 à 9 dépendantes de la revendication 1.25