FR2963690A1 - Systeme informatique "client-serveur" securise pour applications interactives - Google Patents

Abstract

Le domaine général de l'invention est celui des systèmes informatiques de type client-serveur pour applications graphiques, c'est-à-dire pour affichage de données sous formes d'unités logicielles appelées « widgets » sur des écrans d'affichage appelés « Display Unit », ledit système contrôlant le fonctionnement d'une machine, la machine comprenant au moins une interface homme-machine permettant d'interagir avec les widgets, ledit système gérant des données ou des fonctions critiques. Le système informatique selon l'invention comporte un moteur de sécurisation contrôlant l'intégrité de l'affichage des widgets critiques, les envois de commande effectués au moyen de l'interface homme-machine, la saisie et l'affichage des données critiques. Les principales dispositions de ce moteur de sécurisation sont l'emploi de « signatures » informatiques, la mise en place de circuits de « feedback» et l'utilisation de mécanismes de garde ou de boîtes de dialogue de confirmation dédiées. De façon préférentielle, la machine est un aéronef, le système informatique est l'avionique de bord dudit aéronef et les écrans d'affichage sont les systèmes de visualisation de cockpit.

Description

Système informatique « client-serveur » sécurisé pour applications interactives Le domaine de l'invention est celui des systèmes informatiques dits « client-serveur » sécurisés pour applications interactives, et en particulier pour applications avioniques.

10 Les systèmes « client-serveur», utilisés largement dans le monde des réseaux informatiques ont fait leur apparition au début des années 2000 dans l'avionique de cockpit. On entend par avionique de cockpit l'ensemble des moyens électroniques et informatiques permettant de traiter, de visualiser, de contrôler et de modifier les informations nécessaires au 15 pilotage et à la navigation d'un aéronef et plus généralement à l'accomplissement de la mission de l'aéronef pendant un vol. La norme ARINC 661 fournit un cadre standardisé pour la mise en oeuvre de ces architectures informatiques en aéronautique. Les composants d'un tel système sont principalement : 20 - Un serveur graphique fournissant une capacité à tracer des objets graphiques de base à partir de sollicitations reçues sous la forme de requêtes ou de commandes ; - Des clients baptisés « User Application » ou « U.A. » dans la norme ARINC 661 exécutant les fonctions opérationnelles et envoyant des 25 requêtes au serveur pour réaliser l'affichage des informations. Le serveur graphique offre aussi la capacité de traiter des actions qu'un opérateur, en l'occurrence l'équipage, veut lancer sur un client. Dans une architecture client-serveur, l'intelligence opérationnelle est donc localisée dans les clients. Le serveur se contente d'exécuter les requêtes de ses 30 clients sans n'en avoir aucune connaissance opérationnelle. A l'inverse, dans les architectures avioniques conventionnelles, l'intelligence opérationnelle est située dans les équipements de cockpit qui maîtrisent donc le contenu fonctionnel de ce qu'ils affichent. Les figures 1 et 2 décrivent les flots fonctionnels d'un serveur 35 interactif à l'initialisation du système et pendant l'utilisation du système. Une application interactive ou client envoie à l'initialisation du système, sous5 forme de commandes d«< instanciation », la définition des pages interactives qui sont stockées sur le serveur sous la forme du modèle des « widgets ». On entend par « widget » une unité logicielle associée à une représentation graphique et un comportement présenté sur les unités de visualisations de cockpits encore appelées « DU », signifiant « Display Unit ». Les widgets permettent à l'équipage au moyen d'un média de contrôle de donner des instructions au système de contrôle de l'aéronef et de recevoir des informations. A partir de ce modèle, comme on le voit sur la figure 2, des commandes graphiques sont générées cycliquement et envoyées à la machine graphique. Le modèle des widgets peut-être modifié soit par envoi d'une commande de l'application sur sa propre initiative, soit par l'action d'un utilisateur sur le média de contrôle qui génère également une réponse de l'application sous la forme d'une commande. Sur la figure 2, le parcours des commandes des média est représenté par des flèches en traits gras.

A titre d'exemples, les média de contrôle sont des claviers, des « souris » informatiques, des « trackballs », des écrans tactiles ou des postes de commande dédiés, par exemple de type « KCCU » pour « Keyboard Cursor Control Unit » . Les widgets sont classiquement des menus déroulants, des boutons graphiques, des zones de saisie numérique, des « combo-box » et plus généralement recouvrent l'ensemble des moyens d'interaction graphique.

En aéronautique, il existe un certain nombre de fonctions dites critiques qui doivent pouvoir être gérées par un système « client-serveur ».

On entend par donnée ou fonction critique une donnée ou une fonction dont la modification impromptue ou l'activation intempestive par un système piloté peut engendrer un scénario catastrophique ou un accident pour l'aéronef. Les événements redoutés sont de deux natures, les erreurs humaines d'une part, et des dysfonctionnements conduisant à un problème de non-intégrité des fonctions ou des données ou encore une activation intempestive d'autre part. Les erreurs humaines consistent en une action involontaire ou intempestive de l'opérateur, par exemple un click involontaire sur un widget. Le problème d'intégrité concerne trois types d'évènements : - Une interaction de l'utilisateur qui obtient un bon retour visuel, mais dont la commande associée n'est pas traitée ou envoyée et l'utilisateur ne le sait pas. II faut donc garantir la prise en compte d'une requête utilisateur issue d'une action sur un élément graphique et la réalisation du traitement associé ; - Une interaction utilisateur qui n'engendre. aucun retour visuel, mais dont la commande associée est traitée ou envoyée et l'utilisateur ne le sait pas. II faut donc assurer la cohérence entre une interaction utilisateur et le retour visuel associé ; - Une modification inopinée de la structure du modèle des widgets ou des attributs de ce modèle.

Sur le plan de la sûreté de fonctionnement, il est nécessaire de mettre en place un contrôle d'intégrité de la fonction opérationnelle dans le système de cockpit. L'une des techniques couramment mise en oeuvre est le «feedback » qui consiste à vérifier, par un calcul inverse, la cohérence des paramètres affichés avec les paramètres fournis au système. Le fondement mathématique de ce mécanisme est basé sur le fait que la composition d'une fonction par son inverse est égale à la fonction identité (F° F"1 = identité).

Ainsi, s'il est possible de trouver la fonction inverse F-1 de la fonction d'affichage F d'un paramètre critique p, il suffit de vérifier que F(F"1(p)) = p pour garantir que la fonction F s'est bien exécutée. D'un point de vue système, afin de garantir qu'il n'y a pas de panne pouvant affecter à la fois la fonction et sa surveillance, les fonctions F et F_1 doivent être suffisamment ségréguées. Des mécanismes spécifiques de ségrégation ou « partitioning » sont ainsi mis en oeuvre dans la structure d'accueil de chaque coeur de calcul afin d'éviter qu'une éventuelle pollution d'une panne d'une première fonction affecte une seconde fonction (en particulier la fonction de surveillance). La figure 3 illustre le mécanisme du contrôle par « feedback » d'une chaîne de visualisation comprenant classiquement : des moyens d'acquisition des informations issues d'un capteur qui peut être une centrale inertielle, par exemple ; des moyens de traitement des dits paramètres et ; des moyens de génération graphique, l'ensemble constituant une 35 fonction F de traitement des paramètres du capteur.

Cette chaîne comporte une chaîne de surveillance qui acquière en parallèle les informations venant du capteur et les compare avec les données issues d'une fonction F 1 qui recalcule, à partir des informations graphiques, la valeur des paramètres venant du capteur.

Par conséquent, un système « client-serveur » utilisable, par exemple pour des applications aéronautiques, pour des fonctions critiques doit permettre : - L'affichage sur les « DU » de données critiques envoyées sous la forme de commandes par une application interactive hébergée sur un client. On citera notamment l'affichage de paramètres moteur envoyés par les calculateurs idoines ; - L'utilisation de l'interactivité sur les « DU » pour contrôler des fonctions critiques. A titre d'exemple, on souhaite que l'équipage puisse modifier l'état d'une pompe du système de gestion du fuel de façon sûre. L'introduction des architectures client-serveur dans les systèmes critiques pose le problème de la mise en oeuvre du contrôle d'intégrité. Le mécanisme actuel de feedback couvrant l'ensemble de la chaîne fonctionnelle ne peut pas se décliner directement sur le serveur d'une part et le client d'autre part. De plus, l'interactivité utilisateur, c'est-à-dire le lancement de commandes par l'équipage à partir de l'interface graphique n'est actuellement pas mise en oeuvre pour des fonctions critiques ou bien est mise en oeuvre à l'aide de moyens supplémentaires fortement contraignants sur le plan des facteurs humains. Actuellement, pour éviter ces problèmes, les architectures « client-serveur » sont mises en oeuvre dans des systèmes embarqués non critiques.

La présente invention a pour objet de proposer un mécanisme de 30 sécurisation d'un système client-serveur permettant d'empêcher le déclenchement fortuit d'une fonction par l'utilisateur ; de garantir l'intégrité des fonctions du serveur, y compris le lancement d'actions interactives par l'opérateur de garantir la cohérence de des informations entre le serveur et les clients.

Le mécanisme de sécurisation est un ensemble fonctionnel encore appelé « moteur de sécurisation » mettant en oeuvre un ensemble de mécanismes propres à chaque famille de fonctions du serveur. Ainsi, le contrôle d'intégrité est basé sur un moteur de calcul concentrant les contrôles effectués sur un ensemble de mécanismes particuliers à chaque famille de fonction du serveur : Utilisation de « gardes » ; Utilisation de « signatures » mathématiques ; Mise en oeuvre de « feedback » sur certaines sous-fonctions mais pas sur la chaîne globale. La signature mathématique est une technique initialement conçue pour la surveillance des transmissions de données et de détection de corruption de fichiers informatiques. Cette technique est ici déclinée à des fins de sûreté de fonctionnement du système. Les mécanismes de sécurisation selon l'invention sont déclinés sur le protocole ARINC 661 mais cette invention est généralisable à tout type de systèmes interactifs client- serveur. Cette invention permet de garantir l'intégrité du serveur ARINC 661, c'est à dire garantir que les sorties critiques du serveur, c'est-à-dire des commandes en ARINC 661 ainsi que les instructions de tracé dans un langage graphique quelconque qu'on appelle dans la suite du texte « XGL » sont cohérentes de ses entrées fournies par le système de saisie et de pointage et les commandes ARINC 661. Il est à noter que le moteur de sécurisation est un ensemble de fonctions, de logiciels qui n'est pas localisé sur un calculateur particulier.

Plus précisément, l'invention a pour objet un système informatique de type client-serveur pour applications graphiques, c'est-à-dire pour affichage de données sous formes d'unités logicielles appelées « widgets » sur des écrans d'affichage appelés « Display Unit », chaque widget étant définie par des « attributs », ledit système destiné à contrôler le fonctionnement d'une machine, la machine comprenant au moins une interface homme-machine permettant d'interagir avec les widgets, ledit système gérant des données ou des fonctions critiques, c'est-à-dire des données ou des fonctions pouvant entraîner un dysfonctionnement grave de ladite machine, les widgets étant réunis dans une structure appelée « modèle » comprenant les propriétés de chaque widget ainsi que leur organisation hiérarchique, ledit modèle étant créé à partir d'un fichier de définition de l'application-client, les widgets assurant l'affichage des fonctions critiques étant appelés « widgets sécurisés », caractérisé en ce que ledit système informatique comporte un 10 moteur de sécurisation comprenant des dispositions_ de surveillance de l'affichage des widgets sécurisés, la première disposition de contrôle étant constituée par le premier calcul d'une « signature » du modèle des widgets sécurisés, par le second calcul d'une « signature » du fichier de définition des widgets sécurisés et par 15 la comparaison des deux signatures, une signature étant un code mathématique associé aux attributs des widgets sécurisés ; la seconde disposition de contrôle étant constituée par des algorithmes de vérification de la conformité de la pile d'instructions graphiques généré par le serveur avec le modèle des widgets sécurisés, 20 lesdits algorithme étant de type « feedback ». Avantageusement, le moteur de sécurisation comprend au moins une disposition de contrôle des envois de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, ladite disposition étant que les widgets sécurisées 25 sont de type « UA-Validation », c'est-à-dire que, lorsqu'un ordre de changement d'état dudit widget sécurisé est reçu venant de l'interface homme-machine, ledit widget sécurisé attend un message de confirmation du « client » avant de changer d'état. Avantageusement, le moteur de sécurisation comprend au moins : 30 - des premières dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites premières dispositions étant que les widgets sécurisés comportent soit des mécanismes de garde, soit des boîtes de dialogue, un mécanismes de garde est un objet graphique protégeant le widget sécurisé que l'on doit nécessairement déverrouiller avant d'accéder au dit widget sécurisé ; - des secondes dispositions de contrôle de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites secondes dispositions assurant la cohérence du verrouillage de la garde ou de la boîte de dialogue avec l'état du widget sécurisé ; - des troisièmes dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites troisièmes dispositions étant constituées par l'association de signatures des widgets critiques avec leurs gardes ou boutons de confirmation et la vérification par l'UA des couples de signatures via une table de correspondance; - des quatrièmes dispositions assurant l'intégrité de la valeur 15 saisie par l'utilisateur par la transmission à l'UA de la valeur et de sa signature pour vérification de leur cohérence par l'UA,

Préférentiellement, la machine est un aéronef, le système informatique est l'avionique de bord dudit aéronef et les écrans d'affichage 20 sont les systèmes de visualisation de cockpit et le système informatique fonctionne conformément à la norme aéronautique ARINC 661.

L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description qui va suivre donnée à titre non 25 limitatif et grâce aux figures annexées parmi lesquelles : Les figures 1 et 2 représentent deux synoptiques déjà commentés du fonctionnement typique d'un système client serveur selon l'art antérieur, le premier synoptique à l'initialisation du système et le second en fonctionnement courant du système; 30 La figure 3 représente une chaîne de visualisation comprenant une chaîne de surveillance avec feedback selon l'art antérieur ; La figure 4 représente les différents flux de données dans le cadre d'une application client-serveur aéronautique ; La figure 5 est une partie de représentation graphique de boutons de garde en position verrouillée et déverrouillée dans le cadre de l'affichage des circuits de commande moteur ; Les figures 6, 7 et 8 représentent les principes de fonctionnement 5 selon l'invention de mécanisme de garde ou de boîtes de dialogue dans le cas d'envoi de commandes sécurisées. Tout ce qui suit concerne un système informatique client-serveur sécurisé pour applications avioniques fonctionnant sous ARINC 661. 10 Cependant, les notions développées dans ce cadre particulier sont facilement transposables dans d'autres domaines techniques ayant des exigences semblables en matière de sécurité des échanges informatiques et des présentations graphiques.

15 La figure 4 représente le synoptique des échanges de données entre les différentes composantes du système client-serveur avionique. Le coeur du système est l'unité d'affichage ou « Display Unit » ou DU. II affiche les widgets à partir du modèle des widgets qui est la structure de données en mémoire gérée par le serveur ARINC 661 stockant les propriétés de chaque 20 widget ainsi que la hiérarchie entre widgets. Ce modèle est créé à partir du "User Application Definition File" ou « UADF », appelé plus simplement « DF » dans ce qui suit. Le « DU » interagit avec les différents média d'interaction contrôlés par l'utilisateur et I«< UA ». Comme on l'a vu, le moteur de sécurisation doit garantir l'intégrité 25 de l'affichage de données critiques puis dans un second temps l'interactivité sur les Displays Units. La description qui suit comporte donc deux grands chapitres, le premier consacré à la sécurisation de l'affichage, le second à la sécurisation de l'interactivité.

30 Sécurisation de l'affichage Il est nécessaire d'assurer la sécurisation de l'affichage d'une donnée critique envoyée en ARINC 661 par une UA à une DU. Un serveur ARINC 661 gère l'affichage des widgets sur une DU en deux étapes : a) gestion en mémoire d'une structure de données appelé modèle 35 des widgets contenant les propriétés de chaque widget et supportant les relations parent-enfant entre les différents widgets ; b) génération des instructions graphiques dites XGL par parcours de la structure de données.

Le moteur de sécurisation doit couvrir ces deux étapes. a) Sécurisation du modèle des widgets Deux types d'événements peuvent modifier ce modèle : Une commande en A661 envoyée par une UA ; Un événement envoyé par l'avionique de cockpit dit « CDS » pour « Cockpit Display System » ayant, par exemple, pour conséquence une reconfiguration des DU ; Concernant les évènements envoyés par le CDS, on distingue les reconfigurations issues d'une interaction pilote comme, par exemple, une demande de changement de page par l'équipage sur une DU de celles dues à une modification de l'état du système comme, par exemple, la panne d'un DU entraînant une reconfiguration du système. Le résultat d'une reconfiguration est la modification de l'affichage des éléments interactifs qui conditionne les dialogues entre les UA et le serveur ARINC 661. Cette modification des dialogues a un impact plus ou moins important sur le modèle de widgets. L'activation d'une nouvelle page interactive est un exemple de modification visible de l'extérieur qui entraîne une mise à jour du modèle des widgets, les attributs de visibilité de l'ensemble des widgets constituant cette page étant modifiés.

La sécurisation du modèle des widgets revient donc : à gérer son intégrité vis à vis du DF à l'initialisation, puis à s'assurer que le modèle n'est pas modifié inopportunément pendant l'exécution ou « run-time » ; enfin à s'assurer que son évolution est conforme aux commandes 30 ARINC 661 reçues des UA et des événements CDS. Il est important lors de la spécification de bien identifier les widgets à sécuriser pour n'appliquer ce processus que sur ces widgets.

Pour assurer cette sécurisation, le moteur de sécurisation utilise 35 des « signatures », une signature étant un code mathématique associé aux attributs des widgets sécurisés. Ce code est généralement un code de « Hamming ». Il est à noter qu'un DF peut-être vu comme un ensemble de commandes ARINC 661 et donc que l'on peut utiliser la même méthode de signature pour une commande ARINC 661 envoyée par une UA et un fichier DF. Pour ces signatures, on peut utiliser une fonction tenant compte : Du type de la commande et de son code A661 ; Des identifiants du widget ; De la valeur de la commande. Par exemple, à l'initialisation de la DU ou sur reconfiguration, le moteur de cohérence calcule la signature du DF pour les widgets sécurisés et leurs parents et la signature du modèle et vérifie l'égalité des deux signatures. On a ainsi : SignatureDF = f(Eattributs des widgets sécurisés du DF) SignatureMod = f(Eattributs des widgets sécurisés du modèle) 15 Au « run-time », tant qu'aucun événement 'ne vient modifier le modèle, le moteur de cohérence recalcule cycliquement à chaque intervalle de temps At, la signature du modèle et vérifie que SignatureMod à t+At = SignatureMod à t. 20 Sur modification du modèle des widgets suite à une commande ARINC 661 envoyée par une UA, le moteur de cohérence retrouve la commande A661 à partir du changement d'attributs du modèle. On a: Commande A661 = F 1(changement d'attributs du modèle) Il vérifie l'égalité avec la commande A661 reçue. A titre de premier 25 exemple, le widget x de la page y de type « toggle button » ou « interrupteur à bascule » passe de l'état non enfoncé à l'état enfoncé. La fonction F-' (changement d'attributs du modèle) permet de retrouver la commande ARINC 661 intitulée « Enfoncer widget x de la page y ». A titre de second exemple, l'attribut « text » d'un widget x2 « text box » de la page y prend la 30 valeur « ALPHA » permet de retrouver la commande Set text « ALPHA » widget x2 page y. II est à noter que la surveillance d'intégrité du modèle de widget, c'est à dire le calcul et la vérification des signatures telles que décrit ci-dessus, doit être ségréguée de la fonction d'affichage. 35 Ainsi, la sécurisation du modèle des widgets par le moteur de cohérence se fait de la manière suivante : Pour éviter que le modèle soit non cohérent du DF : o Comparaison de la signature du DF avec la signature du modèle à l'initialisation et sur reconfiguration. Pour éviter une modification impromptue du modèle en l'absence de commande : o Comparaison de la signature du modèle entre t et t+At au run-time ; Pour éviter l'exécution d'une commande ne correspondant pas à la commande reçue : o Calcul de la commande ARINC661 sur modification du modèle et comparaison avec la commande reçue.

15 b) Sécurisation de la génération des instructions graphiques II s'agit de garantir la sécurisation de l'affichage d'une donnée critique jusqu'à la sortie du Serveur A661, c'est à dire la génération de la pile de commande graphique en XGL. La solution selon l'invention pour sécuriser la génération des 20 instructions graphiques consiste à faire vérifier cycliquement par le moteur de cohérence pour les widgets sécurisés la conformité de la pile d'instructions graphiques avec le modèle des widgets. Une telle vérification est dépendante du type de widget. A titre d'exemple, un algorithme de vérification de la conformité de la pile d'instructions graphiques avec le modèle des widgets 25 pour les widgets de type « Label » peut être : Pour tous les widgets sécurisés de type « Label », Trouver la commande « XGLWriteText » dans la pile d'instructions graphiques correspondant au widget. Pour cela, on a besoin d'un paramètre "feedback id" dans la commande XGLWriteText sur le 30 modèle de la fonction existante SGLFeedbackVertex ; A partir de la commande XGLWriteText, on remonte la pile jusqu'à la commande XGLSetAttributes précédente .et on compare ses paramètres avec les attributs du modèle pour le widget courant comme, par exemple, les couleurs de police et de fond, la taille de 35 la police de caractères, ... 10 On vérifie la conformité des coordonnées d'affichage. Dans la commande XGL, le système de coordonnées peut être différent du système de coordonnées du modèle. II convient donc d'avoir projeté préalablement dans le modèle pour chaque widget sécurisé leurs coordonnées relatives aux commandes XGL. Un algorithme doit être écrit sur ce modèle pour chaque type de widgets que l'on veut sécuriser. Ainsi, la sécurisation de la génération des instructions graphiques par le moteur de cohérence se fait de la manière suivante : Vérification cyclique de la cohérence de la conformité de la pile d'instructions graphiques générée (XGL) avec le modèle de widget par l'ajout de fonctions de type "feedback id" au langage graphique XGL.

Sécurisation de l'interactivité L'interactivité sur les DU regroupe plusieurs éléments qui sont : a) L'interaction à effet transitoire sur l'unité d'affichage, comprenant le déplacement du curseur, la gestion du focus, c'est-à-dire la zone de widget ou le widget sélectionnable, la surbrillance ou « highlight » des objets traversés par le curseur, l'ouverture d'une « combo-box », le défilement d'une liste ; ... b) L'interaction d'envoi d'une commande par un widget qui, pour les commandes critiques, doit être sécurisée ; c) L'interaction de saisie et d'affichage d'une donnée, qui pour des données critiques, doit être sécurisée.

a) L'interaction à effet transitoire L'interaction à effet transitoire a un retour visuel immédiat vers l'utilisateur qui détecte un éventuel disfonctionnement et peut utiliser un moyen d'interaction secondaire si nécessaire. Par exemple, la non prise en compte de la position du curseur. De plus, ce type d'interaction ne génère pas d'envoi de commandes ou de données vers l'application interactive. Ces deux arguments font que ce type d'interaction n'est pas critique et n'a donc pas besoin d'être sécurisé.35 b) L'interaction d'envoi d'une commande Pour l'interaction d'envoi d'une commande, les widgets critiques sont de type dites « UA Validation ». Ces widgets ont la particularité d'attendre un message de confirmation de l'application cliente avant de changer d'état. Par exemple, un bouton à deux états (enfoncé/non enfoncé) va envoyer sur un événement de click curseur une demande de changement d'état à I'UA qui pilote cette fonction et attendre un message de confirmation de l'UA avant d'effectuer son changement d'état. Si le message de confirmation ne parvient pas au widget avant une durée définie, il revient à son état initial. Ce mécanisme garanti la cohérence entre l'état de l'IHM et l'état de l'UA si on sait garantir le traitement d'une donnée critique entre une UA et une DU, point abordé au chapitre précédent. Ce mécanisme de « UA Validation » est nécessaire mais non suffisant. Il n'empêche pas un déclenchement inopportun d'un widget soit par bug, soit par erreur de l'utilisateur. Pour pallier ce dernier problème, toute commande critique est sécurisée soit par un mécanisme de garde, soit par une boîte de dialogue de confirmation. Un mécanisme de garde est un objet graphique protégeant un widget sécurisé que l'on doit nécessairement déverrouiller avant d'accéder audit widget sécurisé.

II convient ensuite de garantir la garde ou le bouton de confirmation. Pour assurer cette fonction, le moteur de sécurisation envoie à l'UA par le bouton de garde ou de confirmation une signature calculée par une fonction f appliquée par exemple à l'identifiant du widget ou tout autre caractéristique unique au moment ou la garde est levée ou le bouton de confirmation cliqué. On procède de même sur l'interaction du widget associé à la fonction critique. On envoie une signature calculée par la même fonction f, après avoir levé la garde ou avant l'affichage du bouton de confirmation. L'UA décode ensuite les deux signatures et en vérifie la cohérence l'une par rapport à l'autre dans une table d'association des identifiants des widgets critiques et de leurs gardes ou bouton de confirmation respectifs. Il convient également de ségréguer la gestion du bouton et celle de sa garde. A titre d'exemple, la figure 5 est une partie de la représentation graphique de boutons de garde en position verrouillée et déverrouillée dans le cadre de l'affichage des circuits de commande moteur. Sur cette figure, sont représentés les deux réacteurs de l'appareil au centre de la figure, leurs circuits d'alimentation en carburant, des indications de niveau « 6100 » et deux boutons de commande notés « ENG1 » et « ENG2 », permettant d'allumer ou d'éteindre les réacteurs. On comprend bien que ces boutons sont fondamentaux pour la bonne marche de l'appareil. Ces deux boutons sont sécurisés au moyen de gardes représentés par des rectangles en gris sur la figure 5. En position verrouillée, la garde recouvre le bouton comme on le voit à gauche de la figure 5. En position déverrouillée, la garde est en position abaissée et ne recouvre plus le bouton comme on le voit à droite de la figure 5. Pour verrouiller ou déverrouiller, l'utilisateur amène puis clique sur le pointeur représenté par les deux V en gras formant un X sur la figure 5 sur la garde choisie. Ainsi, pour sécuriser l'interaction d'envoi d'une commande critique en ARINC 661 d'une DU vers une UA, le moteur de sécurisation met en 15 oeuvre simultanément les trois moyens suivants : Pour éviter le déclenchement intempestif d'un widget au niveau de l'IHM due à une erreur humaine ; o Utilisation systématique d'un mécanisme de garde ou d'une boîte de dialogue sur la même DU géré par des logiciels ségrégués ; o Association de signatures des widgets critiques avec leurs gardes ou boutons de confirmation et vérification par l'UA des couples de signatures via une table de correspondance ; o Repositionnement automatique de la garde sur le bouton si besoin (après une interaction, après une durée définie,...) ; Pour éviter l'absence de cohérence entre l'IHM et l'UA, c'est-à-dire que des commande ne soient pas prises en compte et ne soient pas exécutées par l'UA : o Utilisation de widgets « UA Validation » uniquement.

Ainsi, le problème consistant à sécuriser l'interaction d'envoi d'une commande critique revient à garantir la cohérence de l'affichage des widgets 35 par rapport à l'état de I'UA. 20 25 30 c) L'interaction de saisie et d'affichage d'une donnée Dans le cas de l'interaction de saisie, l'implémentation actuelle de l'ARINC 661 pour des applications aéronautiques propose une famille de widgets « UA Validation ». La valeur saisie dans un widget de type « Edit box » ou sélectionnée dans un widget de type « Combo box » est vérifiée par l'UA puis renvoyée à la DU pour affichage définitif. L'emploi de telles widgets garantit la cohérence entre l'UA et la DU si on sait garantir le transfert d'une donnée critique entre une UA et une DU, problème déjà traité.

On peut se satisfaire de ce mécanisme et compter sur l'utilisateur pour vérifier que la valeur saisie est bien la valeur prise en compte par I'UA. Toutefois, il est plus sûr de mettre en place via le moteur de sécurisation selon l'invention un système de signature sur la valeur saisie ou sélectionnée depuis la DU selon le type de widget considéré (edit box ou combo box) jusqu'à l'UA. L'UA vérifie alors la cohérence de la signature avec la valeur saisie ou sélectionnée avant de valider et d'envoyer la valeur confirmée à la DU. Le calcul de la signature de la valeur doit se faire au plus près de la saisie et dans une couche logicielle ségréguée. Plusieurs solutions sont envisageables comme par exemple un clavier « intelligent » de type KCCU, acronyme de « Keyboard Cursor Control Unit », capable de mémoriser le résultat d'une saisie et d'en calculer la signature ou encore la transmission d'une signature « touche par touche » pour reconstituer la saisie sur la DU et vérifier la cohérence. Enfin, il est préférable de recourir à l'emploi systématique d'un mécanisme de garde pour protéger l'accès aux widgets de saisie ou bien d'une boîte de dialogue de confirmation, gérés dans les deux cas par une couche logicielle ségréguée, afin d'empêcher toute saisie involontaire. Cette garde ou cette boîte de dialogue doit obéir au mécanisme de contrôle par le moteur de cohérence avec le widget de saisie déjà décrit plus haut.

Ainsi, pour sécuriser l'interaction de saisie ou de sélection d'une valeur critique en ARINC 661 d'une DU vers une UA par l'emploi simultané des quatre moyens suivants : Pour éviter l'envoie intempestif d'une valeur par l'IHM ainsi que 35 pour éviter, après la saisie, l'envoi d'une valeur incorrecte o Utilisation systématique d'un mécanisme bouton de garde ou d'une boîte de dialogue sur la même DU mais géré par une couche logicielle ségréguée ; o Gestion par le moteur de sécurisation d'une association de signatures aux valeurs critiques saisies ou sélectionnées et vérification par l'UA de la cohérence de la signature et de la valeur ; o Gestion par le moteur de sécurisation de la cohérence de la garde ou boîte de dialogue avec le widget de saisie par l'UA. Pour garantir par la cohérence entre l'interface homme-machine et l'UA comme, par exemple, la confirmation de la prise en compte de la valeur saisie : o Utilisation de widgets "UA Validation" uniquement. 15 Ce principe est représenté sur les figures 6, 7 et 8 qui représentent les diagrammes de séquence d'utilisation de boutons de garde ou de boîtes de dialogue dans le cas d'envoi de commandes sécurisées. La figure 6 représente le principe général d'un diagramme de séquence pour 20 une saisie avec garde et les figures 7 et 8 représentent ce même diagramme selon qu'il s'agit d'un bouton gardé ou d'une boîte de dialogue de confirmation.

La figure 6 est organisée en trois colonnes, la première regroupe 25 les tâches effectuées par l'utilisateur ou « USER », la seconde les tâches effectuées par la « DU », la troisième les tâches effectuées par I«< UA ». Les lignes de tâches sont regroupées par ordre logique, les flèches indiquant le sens des actions, les lignes de tâches se succèdent par ordre chronologique. Ainsi, l'utilisateur assure trois tâches, la première « Click guard » consiste à 30 déverrouiller la garde choisie, la seconde « Edit value » consiste à entrer la valeur choisie, la troisième « Monitor Value » enfin consiste à valider la valeur choisie. Le DU transmet les informations reçues et l'UA assure la sécurisation des opérations. 10 Les figures 7 et 8 sont organisées en quatre colonnes, la première regroupe les tâches effectuées par l'utilisateur ou « USER », la seconde et la troisième les tâches effectuées par deux couches de logiciels ségréguées appartenant à la « DU » et notées « DU SW layer 1 » et « DU SW layer 2 », la quatrième les tâches effectuées par I«< UA ». Les lignes de tâches sont regroupées comme précédemment par ordre logique, les flèches indiquant le sens des actions, les lignes de tâches se succèdent par ordre chronologique. L'utilisateur assure comme dans le cas de la figure 6, les tâches de déverrouillage, de sélection et de validation.

Le tableau ci-dessous récapitule les différentes actions du « moteur de sécurisation » selon l'invention réparties entre la DU et l'UA et fonction des différentes phases de traitement du serveur ARINC 661. PHASE Display Unit (D.U.) User Application (U.A.) INITIALISATION Comparaison DF vs Modèle CYCLE DE Comparaison FONCTIONNEMENT signatures modèle entre T et T+AT Vérification cohérence commande XGL critiques et objets du modèle COMMANDE U.A. Feedback sur modification du modèle COMMANDE USER Calcul signature garde Vérification cohérence des signatures Calcul signature widget SAISIE USER Calcul signature garde Vérification cohérence des signatures Calcul signature widget Calcul signature valeur Vérification cohérence des signatures15

Claims (7)

1. REVENDICATIONS1. Système informatique de type client-serveur pour applications graphiques, c'est-à-dire pour affichage de données sous forme d'unités logicielles appelées «widgets » sur des écrans d'affichage appelés « Display Unit » (DU), chaque widget étant définie par des « attributs », un client étant appelé « User Application » (UA), ledit système contrôlant le fonctionnement d'une machine, la machine comprenant au moins une interface homme-machine permettant d'interagir avec les widgets, ledit système gérant des données ou des fonctions critiques, c'est-à-dire des données ou des fonctions pouvant entraîner un dysfonctionnement grave de ladite machine, les widgets étant réunis dans une structure appelée « modèle » comprenant les propriétés de chaque widget ainsi que leur organisation hiérarchique, ledit modèle étant créé à partir d'un fichier de définition de l'application-client (DF), les widgets assurant l'affichage des fonctions critiques étant appelés « widgets sécurisés », caractérisé en ce que ledit système informatique comporte un moteur de sécurisation comprenant des dispositions de contrôle de l'affichage des widgets sécurisés, la première disposition de contrôle étant constituée par le premier calcul d'une « signature » du modèle des widgets sécurisés, par le second calcul d'une « signature » du fichier de définition des widgets sécurisés et par la comparaison des deux signatures, une signature étant un code mathématique associé aux attributs des widgets sécurisés ; la seconde disposition de contrôle étant constituée par des algorithmes de vérification de la conformité de la pile d'instructions graphiques généré par le serveur avec le modèle des widgets sécurisés, lesdits algorithme étant de type « feedback ».
2. 2. Système informatique de type client-serveur selon la revendication 1, caractérisé en ce que le moteur de sécurisation comprend au moins une disposition de contrôle des envois de commande et des saisies de l'utilisateur effectués au moyen de l'interface homme-machine sur les widgets sécurisés, ladite disposition étant que les widgets sécurisés sont de type « UA-Validation », c'est-à-dire que, lorsqu'un ordre de changementd'état dudit widget sécurisé est reçu venant de l'interface homme-machine, ledit widget sécurisé attend un message de confirmation du client (UA) avant de changer d'état.
3. 3. Système informatique de type client-serveur selon l'une des revendications 1 ou 2, caractérisé en ce que le moteur de sécurisation comprend au moins des premières dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites premières dispositions étant que les widgets sécurisés comportent soit des mécanismes de garde, soit des boîtes de dialogue, un mécanismes de garde est un objet graphique protégeant le widget sécurisé que l'on doit nécessairement déverrouiller avant d'accéder au dit widget sécurisé.
4. 4. Système informatique de type client-serveur selon la revendication 3, caractérisé en ce que le moteur de sécurisation comprend au moins des secondes dispositions de contrôle de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites secondes dispositions assurant la cohérence du verrouillage de la garde ou de la boîte de dialogue avec l'état du widget sécurisé.
5. 5. Système informatique de type client-serveur selon la revendication 3, caractérisé en ce que le moteur de sécurisation comprend au moins des troisièmes dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites troisièmes dispositions étant constituées par l'association de signatures des widgets critiques avec leurs gardes ou boutons de confirmation et la vérification par le client (UA) des couples de signatures via une table de correspondance.
6. 6 Système informatique de type client-serveur selon la revendication 3, caractérisé en ce que le moteur de sécurisation comprend au moins des quatrièmes dispositions de contrôle de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machinesur les widgets sécurisés, lesdites quatrièmes dispositions assurant l'intégrité de la valeur saisie par l'utilisateur par la transmission au client (UA) de la valeur et de sa signature pour vérification de leur cohérence par le client (UA).
7. 7. Système informatique de type client-serveur selon l'une des revendications précédentes, caractérisé en ce que la machine est un aéronef, le système informatique est l'avionique de bord dudit aéronef et les écrans d'affichage sont les systèmes de visualisation de cockpit et que le système informatique travaille selon la norme aéronautique ARINC 661.