FR2976753A1 - Procede d'initiation d'une communication securisee entre deux systemes de communication - Google Patents

Abstract

Procédé pour initier une communication entre un premier système de communication et un second système de communication, comportant les étapes suivantes consistant à : - générer une attestation de conformité du premier système de communication, ladite attestation de conformité permettant de déterminer si le premier système de communication est conforme à un système de référence, et - envoyer l'attestation de conformité générée à destination du second système de communication afin de permettre au second système de communication de décider, en fonction de l'attestation de conformité reçue, d'accepter ou non d'initier une communication avec le premier système de communication.

Description

Procédé d'initiation d'une communication sécurisée entre deux systèmes de communication

La présente invention concerne les communications avec des entités communicantes sensibles (ou critiques) et nécessitant un niveau de sécurité de communication élevé. Ces communications sont par exemple mises en oeuvre dans le domaine aéronautique, dans lequel les communications vers et depuis un aéronef doivent être particulièrement protégées lorsque des modules sensibles de l'aéronef sont mis en oeuvre. Afin de garantir la sécurité des systèmes aéronautiques, il convient d'éviter que les entités requérantes qui souhaitent communiquer avec des entités sensibles de l'aéronef ou du sol, comportent un code malicieux (tel qu'un virus informatique, un cheval de Troie ou autre). Les entités en question, requérantes ou sensibles, peuvent être matérielles, logicielles ou autre, et peuvent se trouver au sol ou dans un aéronef. Actuellement, pour limiter les risques, les entités requérantes devant communiquer avec les entités sensibles de l'aéronef, telles que les ordinateurs utilisés pour la maintenance des aéronefs, sont physiquement protégées afin de s'assurer qu'elles ne soient pas infectées par un code malicieux. En d'autres termes, il est impossible, pour une personne non autorisée, d'accéder physiquement à ces entités ou de les modifier sans que cela ne soit détecté. Toutefois, les tâches de maintenance sont de plus en plus souvent réalisées à partir de l'extérieur de l'aéronef. Ainsi, la protection physique des entités requérantes n'est plus possible pour garantir l'absence de code malicieux. Il existe donc un besoin pour une nouvelle fonctionnalité permettant le contrôle de l'accès par des systèmes dits « requérants » à des systèmes sensibles ou critiques (au sol ou dans un aéronef), par exemple des systèmes d'information.

Un premier aspect de l'invention concerne un procédé pour initier une communication entre un premier système de communication et un second système de communication, comportant les étapes suivantes consistant à : - générer une attestation de conformité du premier système de communication, cette attestation de conformité permettant de déterminer si le premier système de communication est conforme à un système de référence, et - envoyer l'attestation de conformité générée à destination du second système de communication afin de permettre au second système de communication de décider, en fonction de l'attestation de conformité reçue par le second système, d'accepter ou non d'initier une communication avec le premier système de communication. Ainsi, le second système de communication peut déterminer, avant de commencer une communication, si le premier système de communication a été altéré, par exemple par un code malicieux, par rapport à son état de référence (par exemple un état certifié). Le procédé peut en outre comporter une étape de démarrage du premier système de communication et l'attestation de conformité peut être générée en fonction du déroulement de cette étape de démarrage du premier système de communication.

Ainsi, il est possible de déterminer un statut d'intégrité du premier système de communication, sur la base d'une chaîne de mesures d'intégrité sur les différents modules composant le premier système de communication. Ce statut d'intégrité peut permettre de rendre compte d'une éventuelle altération du premier système de communication dans ces différents modules.

Par exemple, le procédé comporte en outre une étape de génération d'une empreinte de démarrage du premier système de communication. L'empreinte de démarrage comporte par exemple, un résultat d'une fonction de hachage appliquée sur des données utilisées lors de l'étape de démarrage.

Il peut par exemple s'agir d'une empreinte de données d'un code informatique exécuté lors de l'étape de démarrage.

L'utilisation d'une fonction de hachage peut offrir une garantie satisfaisante que deux systèmes différents aient des empreintes de données différentes. L'application d'une fonction de hachage sur des codes informatiques chargés sur un système peut permettre de détecter un nouveau code installé ou de détecter une modification ou une altération d'un code installé. L'attestation de conformité peut comporter l'empreinte de démarrage. Une empreinte de donnée peut être un moyen efficace et simple de comparaison entre le premier système de communication et le système de référence. On peut aussi prévoir en outre une étape de comparaison de l'empreinte de démarrage à une empreinte de référence pour déterminer si le premier système de communication est conforme au système de référence. Par exemple, l'attestation de conformité comporte une représentation du résultat de ladite étape de comparaison. On peut aussi prévoir en outre une étape d'envoi d'une attestation de référence, afin d'être comparée à l'attestation de conformité pour déterminer si le premier système de communication est conforme au système de référence. Par exemple, l'invention trouve des applications dans les environnements à forte exposition où des utilisateurs non autorisés peuvent évoluer dans des zones de moindre confiance, comme par exemple à bord d'un aéronef ou dans l'environnement proche de celui-ci. Par exemple encore, l'invention peut trouver des applications lorsqu'un système communique avec un système sensible au travers de réseaux se situant dans des environnements non contrôlés (réseaux sans fil, internet, réseaux publics, etc.). Toujours à titre d'illustration, l'invention peut s'appliquer pour des systèmes hébergeant des fonctions sensibles exploitant et produisant des données sensibles.

Un deuxième aspect de l'invention concerne un procédé pour décider d'accepter ou non d'initier une communication avec un système de communication, comportant les étapes suivantes consistant à : - recevoir de la part du système de communication une attestation de conformité, cette attestation de conformité permettant de déterminer si le système de communication est conforme à un système de référence, - déterminer, à partir de l'attestation de conformité reçue, si le système de communication est conforme au système de référence, et - décider, en fonction d'un résultat de l'étape de détermination, d'accepter ou non d'initier une communication avec le système de communication. Le procédé peut en outre comporter une étape consistant à comparer l'attestation de conformité reçue à une attestation de conformité de référence pour déterminer si le système de communication est conforme au système de référence. Par exemple, l'attestation de conformité comporte une empreinte de démarrage du système de communication.

Un troisième aspect de l'invention concerne un programme d'ordinateur ainsi qu'un produit programme d'ordinateur et un support de stockage pour de tels programme et produit, permettant la mise en oeuvre d'un procédé selon le premier ou le deuxième aspect lorsque le programme est stocké dans une mémoire d'un système de communication et exécuté par un processeur d'un tel système de communication. Un quatrième aspect de l'invention concerne un système de communication configuré pour la mise en oeuvre d'un procédé selon le premier ou le deuxième aspect de l'invention. Par exemple, un tel système comporte: - un composant configuré pour générer une attestation de conformité permettant de déterminer si le système est conforme à un système de référence, - une unité de contrôle pour initier une communication avec un autre système, et - une unité de communication pour transmettre l'attestation de conformité générée à destination de l'autre système afin de permettre à cet autre système de décider, en fonction de l'attestation de conformité envoyée, d'accepter ou non d'initier une communication avec le système de communication. Un cinquième aspect de l'invention concerne un système de communication configuré pour la mise en oeuvre d'un procédé selon le deuxième aspect de l'invention. Par exemple, un tel système comporte: - une unité de contrôle pour traiter une requête d'initiation d'une communication provenant d'un autre système, - une unité de communication pour recevoir une attestation de conformité provenant de cet autre système, et - un module de vérification configuré pour vérifier une attestation de conformité afin de décider, en fonction de l'attestation de conformité reçue, d'accepter ou non d'initier la communication requise par cet autre système. Les objets selon les deuxième, troisième, quatrième et cinquième aspects de l'invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect. D'autres caractéristiques et d'autres avantages de la présente invention apparaîtront à la lecture de la description non-limitative suivante, faite en référence aux figures suivantes parmi lesquelles : - la figure 1 a illustre un contexte général de mise en oeuvre de modes de réalisation de l'invention; - la figure 1 b illustre un système requérant, un composant de sécurité et un module de vérification selon des modes de réalisation ; - la figure 2 est un organigramme illustrant des étapes mises en oeuvre lors de la génération d'un registre d'intégrité selon des modes de réalisation ; - les figures 3a et 3b illustrent des modes de réalisation pour la comparaison de statuts d'intégrité courant et de référence ; - la figure 4 est un diagramme de séquence illustrant l'initialisation d'un composant de sécurité selon des modes de réalisation ; - la figure 5 est un diagramme de séquence illustrant une demande d'établissement de communication par un système requérant à un système sensible selon des modes de réalisation ; - la figure 6 est un organigramme illustrant des étapes mises en oeuvre du côté du système requérant pour une demande de communication par le système requérant à un système sensible selon des modes de réalisation ; - la figure 7 est un organigramme illustrant des étapes mises en oeuvre par un module de vérification pour une demande de communication par un système requérant à un système sensible selon des modes de réalisation ; et - les figures 8 et 9 illustrent schématiquement des systèmes de communication selon des modes de réalisation. Comme décrit dans la suite de la description, les modes de réalisation de l'invention offrent un moyen de s'assurer avec un niveau de garantie satisfaisant qu'un système requérant qui sollicite une communication avec un élément sensible d'un système d'information n'a pas été modifié depuis qu'il a été contrôlé par une autorité de confiance. La figure 1 a illustre un contexte général de mise en oeuvre de modes de réalisation de l'invention. Un aéronef 10, qui peut être en vol ou au sol, comporte un (ou plusieurs) système (SYST) 11 dit « sensible », c'est-à-dire qu'il héberge des fonctionnalités que l'on souhaite protéger, par exemple des fonctionnalités sensibles de l'aéronef (fonctionnalités avioniques de sécurité ou autre).

Le système 11 peut communiquer avec différents autres systèmes, par différents canaux de communication. Par exemple, le système 11 peut communiquer avec un (ou plusieurs) terminal de communication (REQ) 12, dit « requérant » ou « initiateur », à l'intérieur de l'aéronef. Pour établir une communication avec le système 11, le terminal de communication 12 peut par exemple utiliser un réseau filaire, un réseau sans fil ou autre, disponibles à bord de l'aéronef. Le terminal de communication peut appartenir ou non à l'aéronef.

Le système 11 peut par ailleurs communiquer avec un ou plusieurs autres systèmes à l'extérieur de l'aéronef. Par exemple, le système 11 peut communiquer avec un terminal de communication (REQ) 13 au sol, via un réseau de communication (NET) 14, comme par exemple le réseau Internet.

Dans des modes de réalisation, un système sensible (SYST) 15 se trouve au sol. Ce système héberge par exemple des fonctionnalités sensibles relatives au guidage des aéronefs ou à la récupération de données sensibles provenant d'aéronefs. Les terminaux 12 et/ou 13, et/ou le système 11 peuvent communiquer avec le système 15.

Le système 15 peut être accessible à la communication par d'autres biais que le réseau 14. Il peut s'agir d'autres communications directes, filaires, sans fil ou autre. Des modes de réalisation permettent de réduire les risques de transmission de données malicieusement corrompues (cohérentes et/ou non- cohérentes) et/ou de l'injection de code malicieux comme par exemple des virus ou des chevaux de Troie vers les systèmes sensibles à bord, ou vers les systèmes au sol et de limiter les agents de menace pouvant être une source pour mener une attaque informatique (comme une attaque par déni de service) vers les systèmes d'information embarqués d'un aéronef par exemple.

Comme décrit dans la suite, lorsqu'un système requérant souhaite établir une communication avec un autre système, il transmet d'abord une attestation de conformité qui permet d'évaluer la conformité du système requérant par rapport à un système de référence. Ainsi, il est possible de détecter une modification (malicieuse ou non) du système requérant, avant qu'il ait pu entrer en communication avec, par exemple, un système sensible d'un aéronef ou d'un équipement au sol. En outre, afin de limiter les accès par des systèmes non autorisés, le système requérant, peut transmettre au préalable des éléments relatifs à son identité et son intégrité à un module de vérification d'attestation de conformité.

Le module de vérification peut faire partie du système sensible auquel le système requérant souhaite accéder, ou faire partie d'un système indépendant interposé entre le système sensible et le système requérant.

Le module de vérification peut avoir pour rôle, notamment : ^ d'authentifier sans ambiguïté le requérant sur la base de mécanismes de chiffrement, de signature numérique et de mécanismes questions / réponses, ^ d'authentifier un message de conformité fourni par le requérant sur la base de mécanismes de chiffrement et de signature numérique, ^ de vérifier si le requérant, déclarant sa conformité, est autorisé à communiquer avec un système d'information de l'aéronef (ou le sol) selon certaines conditions, ^ de contrôler l'attestation de conformité. Dans la suite, il est fait référence à trois entités (un système requérant (REQ_SYST) 16, un composant de sécurité (SECUR_COMP) 17 et un module de vérification (VERIF) 18, illustrées par la figure 1 b, communiquant entre elles, directement, ou via un réseau de communication.

Le système requérant 16 représente un système souhaitant entrer en communication avec un système sensible, par exemple d'un aéronef. Le système requérant est par exemple un ordinateur portable de maintenance, configuré pour accéder à des systèmes sensibles de l'aéronef pour les modifier ou pour les réviser.

Afin de générer une attestation de conformité du système requérant par rapport à un système de référence (par exemple le système tel qu'il est défini en sortie d'usine du fabricant), le système requérant interagit avec un composant de sécurité 17. Le composant de sécurité peut générer un statut d'intégrité courant et éventuellement héberger un statut d'intégrité de référence (protégé par un mécanisme de type signature numérique) afin que ces deux statuts puissent être comparés pour conclure à la conformité du système requérant. Le composant de sécurité génère par ailleurs l'attestation de conformité et fournit les éléments nécessaires à la fabrication de l'attestation de référence lors des phases d'intégration. Pour assurer l'intégrité et l'origine de l'attestation de conformité émanant du composant de sécurité, le composant de sécurité peut par ailleurs mettre en oeuvre des mécanismes de signature numérique et d'authentification numérique de données.

Le composant de sécurité peut faire partie du système requérant. Le composant de sécurité peut par exemple être un microcontrôleur sécurisé associé à un logiciel offrant des fonctionnalités de protection de données (stockage sécurisé), de génération de clés de chiffrement, de signature digitale et de chiffrement ou autre. Le composant de sécurité peut par exemple détenir plusieurs paires de clés de chiffrement utilisées pour l'initialisation de celui-ci, pour le stockage sécurisé ou pour la protection en intégrité des résultats de mesures, par exemple si elles sont insérées dans une attestation de conformité comme décrit dans la suite.

Le composant de sécurité est par exemple une puce électronique (par exemple une puce TPM, sigle de Trusted Platform Module en terminologie anglo-saxonne) et optionnellement un logiciel associé. Pour autoriser ou non une communication demandée par le système requérant, le composant de sécurité interagit avec un module de vérification 18.

Le module de vérification vérifie notamment l'origine des données qu'il reçoit, par exemple la source d'une attestation de conformité, en utilisant des mécanismes de signatures numériques. Le module de vérification vérifie également les données reçues elles-mêmes, par exemple l'attestation de conformité comparée à l'attestation de conformité de référence et peut autoriser ou non la communication demandée selon le résultat de cette double vérification. Afin d'autoriser ou non la communication du système requérant 16 avec un système sensible, le module de vérification 18 est interposé entre les deux systèmes.

Le module de vérification peut se trouver auprès du système requérant, auprès du système sensible ou auprès d'une entité tierce. Par exemple, dans une application aéronautique, le module de vérification peut se situer auprès de l'aéronef, dans un équipement du réseau central de sécurité (« secure backbone » en terminologie anglo-saxonne). Les composants du « secure backbone » ont pour rôle de contrôler et d'autoriser les communications éligibles internes et externes de l'aéronef.

Les systèmes requérants souhaitant communiquer avec les domaines sensibles de l'aéronef (par exemple ACD, sigle de Aircraft Control Domain en terminologie anglo-saxonne) fournissent au préalable la preuve de leur identité et l'attestation garantissant leur conformité. Les systèmes requérants peuvent être localisés sur des systèmes se trouvant: ^ dans des domaines exposés de l'aéronef (par exemple dans le PIESD sigle de Passenger Information and Entertainment Service Domain en terminologie anglo-saxonne), ^ dans un périmètre extérieur proche de l'aéronef communiquant via des moyens sans fil par exemple, et/ou ^ dans des infrastructures distantes de maintenance (par exemple le MCC sigle de Maintenance Control Centre ou le MRO sigle de Maintenance and Repair Organization en terminologie anglo-saxonne). La génération d'empreintes de démarrage d'un système pouvant servir de base à la génération d'une attestation de conformité en offrant un reflet de la séquence de démarrage d'un système requérant est décrite avant de présenter des exemples d'attestation de conformité basées sur ces empreintes. Un exemple d'initialisation d'un composant de sécurité permettant la génération des attestations, afin d'assurer des communications sécurisées de celles-ci est alors présenté et des exemples d'établissement de communication sont donnés. L'attestation de conformité peut être basée sur l'établissement d'une chaine de confiance lors du démarrage du système requérant 16. A chaque démarrage du système requérant, chaque composant logiciel ou matériel intervenant dans la séquence de démarrage mesure l'intégrité du composant qui s'exécute après lui et enregistre le résultat dans au moins un registre d'intégrité du composant de sécurité 17. L'ensemble du contenu de ces registres d'intégrité peut constituer un statut d'intégrité, appelé dans la suite « statut d'intégrité courant ».

En référence à la figure 2, on décrit la génération d'un tel statut d'intégrité courant.

Lors d'une étape S200 (STRT MODUL_DEM), un module de démarrage (MODUL_DEM) est lancé. Ce module de démarrage est par exemple un module de confiance placé au sein du système requérant par une autorité de confiance (par exemple un constructeur de systèmes de maintenance) autorisée à garantir les systèmes prévus pour communiquer avec les systèmes sensibles d'un constructeur aéronautique par exemple. Le module de démarrage peut être considéré comme un point de départ d'une chaîne de confiance. L'intégrité du module de démarrage peut ne pas être vérifiée. Ce module de démarrage est alors une racine de confiance pour les mesures à suivre. C'est le point de départ des mesures faites successivement dans la suite. Le module de démarrage peut être protégé à l'épreuve des attaques physiques et/ou logiques. Une fois lancé, le module de démarrage mesure, lors d'une étape S201 suivante (MESUR MODUL_1), la conformité d'un premier module opérationnel (MODUL_1) devant se lancer après lui dans l'ordre de la séquence de démarrage. Par exemple, ce premier module opérationnel est un logiciel de base résident. Une fois la mesure effectuée, un résultat de cette opération est stocké dans un premier registre d'intégrité 21 (REG1), d'un espace mémoire dédié au stockage du statut d'intégrité courant 20. A titre d'illustration, cet espace mémoire appartient au composant de sécurité 17. Ensuite, le premier module opérationnel dont l'intégrité a été mesurée est lancé lors d'une étape S202 (STRT MODUL_1). Une fois que le premier module opérationnel est lancé, on passe à une nouvelle étape de mesure S203 (MESUR MODUL_2) de l'intégrité d'un deuxième module opérationnel (MODUL_2) devant être lancé, toujours dans l'ordre de démarrage du système requérant. Par exemple, le deuxième module opérationnel est un chargeur du système d'exploitation du système requérant. Une fois la vérification effectuée, un résultat de la mesure est stocké dans un deuxième registre d'intégrité 22 (REG2) de l'espace mémoire 20. Le deuxième module opérationnel est ensuite lancé lors de l'étape S204 (STRT MODUL_2).

On passe alors à une étape S205 (MESUR MODUL_3), lors de laquelle on mesure l'intégrité d'un troisième module opérationnel (MODUL_3) devant être lancé dans l'ordre de la séquence de démarrage du système requérant. Le troisième module opérationnel est par exemple un système d'exploitation du système requérant. Une fois la mesure opérée, un résultat de cette mesure est stocké dans un registre d'intégrité 23 (REG3) de l'espace mémoire 20. Le troisième module opérationnel est ensuite lancé lors de l'étape S206.

Ensuite, lors d'étapes S207 (MESUR MODUL_4), S208 (MESUR MODUL_5), S209 (MESUR MODUL_6) les intégrités de quatrième, cinquième et sixième modules opérationnels (MODUL_4, MODUL_5, MODUL_6) devant être lancés dans l'ordre de démarrage du système requérant sont mesurées. Les quatrième, cinquième et sixième modules opérationnels sont par exemple des machines virtuelles mises en oeuvre pour le lancement d'applications. Une fois les mesures effectuées, les résultats de celles-ci sont stockés dans des registres d'intégrité respectifs 24, 25 et 26 (REG4, REGS, REG6) de l'espace mémoire 20.

Les quatrième, cinquième et sixième modules opérationnels sont ensuite lancés lors d'étapes S210 (STRT MODUL_4), S211 (STRT MODUL_5) et S212 (STRT MODUL_6). Chacun de ces modules peut ensuite lancer des applications (APPS) lors d'étapes (STRT APPS) S213, S214 et S215. Les mesures d'intégrité peuvent par exemple comporter l'application d'une fonction de hachage sur des données utilisées pour lancer l'application dont l'intégrité est mesurée. Le résultat d'une telle mesure peut alors être l'empreinte (aussi appelée condensat, signature ou « hash » en terminologie anglo-saxonne) du module dont l'intégrité est mesurée. Par exemple, la fonction de hachage utilisée est la fonction de 30 hachage connue sous le nom de SHA-1. Les fonctions de hachage peuvent offrir un niveau de garantie élevé que deux sources de données distinctes n'ont pas une empreinte identique. En effet, il est mathématiquement difficile de retrouver une source de données dont l'empreinte est égale à une empreinte donnée. Ces empreintes représentatives des éléments logiciels courants du système requérant, comparées à des éléments similaires de référence, peuvent permettre de détecter sans ambigüité une éventuelle corruption des codes d'exécution des différents modules. Les données sur lesquelles la fonction de hachage est ici appliquée correspondent par exemple aux données présentes sur un espace mémoire normalement réservé au lancement de l'application dont l'intégrité est mesurée. Par exemple, dans une architecture classique, c'est le BIOS (sigle de Basic input Output System en terminologie anglo-saxonne) qui est lancé en premier. Le BIOS accède ensuite au MBR (sigle de Master Boot Record en terminologie anglo-saxonne ou zone amorce) qui est le premier secteur adressable du disque dur du système et qui contient une routine d'amorçage dont le but est de charger le système d'exploitation.

Ainsi, dans un mode de réalisation particulier de l'invention basé sur une telle architecture, le BIOS, après démarrage, appelle une fonction de hachage, l'applique sur le MBR et enregistre le résultat avant que la routine d'amorçage soit lancée. Ainsi, l'intégrité de la routine d'amorçage est mesurée. L'espace mémoire contenant les registres d'intégrité peut par exemple être stocké auprès du système requérant 16. On peut prévoir une protection particulière de cet espace mémoire car il sert de base à l'établissement de l'attestation de conformité. Par exemple, comme décrit précédemment, cette zone mémoire se trouve dans le composant de sécurité 17 qui se trouve alors lui-même au sein du système requérant.

La taille des empreintes peut dépendre des algorithmes de hachage utilisés. Les tailles de l'espace mémoire 20 ou des registres d'intégrité 21 à 26 sont de préférence choisies en conséquence. A la fin de la séquence de démarrage, on dispose de données dans l'espace mémoire 20 qui reflètent le déroulement du démarrage ou de l'initialisation du système requérant. Le contenu de cet espace mémoire constitue un statut d'intégrité courant du système requérant.

Pour établir une attestation de conformité du système requérant par rapport à un système de référence, on peut envisager plusieurs solutions. Par exemple, il peut s'agir de comparer le système requérant au système tel qu'il est prévu initialement, par exemple par un constructeur ou une autorité de confiance. A cet effet, on peut comparer un statut d'intégrité courant avec un statut d'intégrité de référence comme évoqué précédemment pour le composant de sécurité. Le statut d'intégrité de référence du système requérant est construit par le fournisseur de ce système soit lors de la phase d'industrialisation, soit lors d'une mise à jour en phase de maintenance lorsque les composants couverts par les mécanismes d'intégrité évoluent. Une première solution, illustrée par la figure 3a, peut consister à mémoriser un statut d'intégrité de référence 30 au sein du composant de sécurité 17, crée par une autorité de confiance (ou le constructeur du système requérant) et qui est établi de la même manière qu'exposé ci-dessus pour le statut d'intégrité courant, en référence à la figure 2. Le statut d'intégrité de référence peut être signé par des clés de chiffrement indépendantes du module de sécurité. Il est par exemple possible de signer l'ensemble des registres de référence composant le statut d'intégrité de référence par une clé de chiffrement générée par un fournisseur de clés de chiffrement PKI (sigle de Public Key Infrastructure en terminologie anglo-saxonne). Ainsi le statut d'intégrité de référence est protégé par un mécanisme garantissant sa propre intégrité par exemple au module de vérification qui l'utilise.

On compare alors le statut d'intégrité courant 31 (REG) et le statut d'intégrité de référence 30 (REG_REF) dans un module de comparaison 32 (COMPAR) et l'attestation de conformité, transmise au module de vérification 18 (VERIF), comporte un résultat de cette comparaison comme par exemple « intégrité=OK » si le statut d'intégrité courant et le statut d'intégrité de référence coïncident. S'ils ne coïncident pas, le résultat de cette comparaison est par exemple « intégrité=NOK ». On peut prévoir d'autres types de messages, par exemple un message binaire ou autre.

Alternativement ou en combinaison, l'attestation de conformité comporte des éléments (statut d'intégrité courant et statut d'intégrité de référence) permettant au module de vérification de vérifier lui-même la conformité du système requérant au système de référence.

Une autre solution, illustrée par la figure 3b, peut consister, pour un composant de sécurité 17', à envoyer le statut d'intégrité courant 31 (REG) en tant qu'attestation de conformité, à charge pour un module de vérification 18' de le comparer au statut d'intégrité de référence 30 (REG_REF) dans un module de comparaison 32 (COMPAR) du module de vérification. Dans cette solution, le statut d'intégrité de référence peut soit avoir été enregistré dans le module de vérification dans une phase d'initialisation préalable, comme discuté précédemment pour le système requérant, ou alors le module de vérification peut l'obtenir via une communication avec un module tiers. L'attestation de conformité doit être par ailleurs protégée en intégrité 15 contre des attaques malicieuses par des moyens de chiffrement et de signature numérique. Le dialogue entre le composant de sécurité (17, 17') du requérant et le module de vérification (18, 18') peut-être réalisé soit directement, soit par des éléments intermédiaires. 20 L'initialisation du composant de sécurité du requérant peut être réalisée chez le fabriquant comme décrit en référence à la figure 4 qui représente un diagramme de séquence entre le composant de sécurité 17 (SECUR_COMP), un fournisseur PKI 400 (PKI_PROV) et un module de vérification 18 (VERIF). 25 Comme évoqué ci-dessus, un composant de sécurité peut être un ensemble matériel et/ou logiciel permettant de construire une attestation de conformité avec un niveau de confiance satisfaisant. Un mécanisme de chiffrement mis en oeuvre par le composant de sécurité peut par exemple reposer sur des fonctions cryptographiques 30 asymétriques utilisant un certificat électronique. Le fournisseur PKI 400 fournit dans une communication préliminaire un certificat dont la clé privée va servir à signer les statuts de conformité de référence pour le composant de sécurité. Ce certificat est fourni au composant de sécurité 17 dans un message 401 (CERT_PKI) et au module de vérification dans un message 402 (CERT_PKI). Ainsi, le composant de sécurité ou le module de vérification peut vérifier l'origine des statuts de conformité de référence qu'ils reçoivent et ainsi garantir que la comparaison qui sera faite entre le statut de conformité de référence et le statut de conformité courant donnera un résultat fiable. Les messages 401 et 402 sont transmis de manière sécurisée, par exemple en utilisant un canal de communication spécifique ou par transport physique sur un support comme un CR-ROM, une clé USB, une carte à puce ou autre. Le composant de sécurité 17 génère quant à lui une paire de clés privée et publique de cryptographie lors d'une étape S403 (GEN_K). Cette paire de clés va servir à signer les attestations de conformité lors d'une demande de communication. Le composant de sécurité 17 transmet ensuite la clé publique dans un message 404 (PUB_K) vers le fournisseur PKI 400. Le composant de sécurité transmet également un message 405 comportant un ensemble d'informations (ID) permettant de l'identifier.

Alternativement, le composant de sécurité 17 peut transmettre au fournisseur PKI 400 un seul message (non représenté) comportant les informations contenues dans les messages 404 et 405. Le fournisseur PKI 400 crée alors un certificat numérique signé (CERT) lors d'une étape S406 (GEN CERT), par exemple un certificat conforme à la norme X.509, comportant notamment la clé publique (PUB_K) générée par le composant de sécurité 17 et les informations permettant de l'identifier. Le certificat (CERT) est signé avec la clé privé du certificat envoyé dans les messages 401 et 402. Ensuite, le certificat numérique crée est transmis au composant de sécurité 17 dans un message 407 (CERT). Le certificat numérique permet d'authentifier l'origine d'une attestation de conformité fournie par un système requérant et signée au moyen de la clé privée générée lors de l'étape S403. Le composant de sécurité, lors d'une demande de communication, joint à l'attestation de conformité courante le certificat signé par le fournisseur PKI. Dans des modes de réalisation particuliers, on peut prévoir plusieurs fournisseurs PKI.

La phase d'initialisation peut également comporter la construction et le stockage, lors d'une étape S408 (GEN ATTEST REF), du statut d'intégrité de référence 30 comme décrit précédemment. Ensuite, le composant de sécurité envoie une requête de signature 409 (REQ SIGN) vers le fournisseur PKI pour qu'il signe l'attestation d'intégrité de référence avec la clé privée du certificat envoyé dans les messages 401 et 402. L'attestation de conformité de référence est alors signée lors de l'étape S410 (SIGN) et une attestation de conformité de référence signée est transmise par le fournisseur PKI au composant de sécurité dans un message 411 (REF_SIGN). Ainsi, le composant de sécurité peut transmettre son statut d'intégrité de référence à des modules de vérification qui pourront, grâce au certificat (CERT_PKI) provenant du fournisseur PKI (envoyé dans le message 402), s'assurer que le statut d'intégrité de référence reçu est lui-même intègre, qu'il provient bien du composant de sécurité et qu'il a bien été généré par le fabriquant certifié. Les modules de vérification peuvent donc s'assurer que les statuts d'intégrité de référence qu'ils reçoivent proviennent sont eux-mêmes intègres, qu'ils proviennent bien d'un composant de sécurité et qu'ils ont bien été générés par le fabricant certifié. Pour s'assurer que les attestations de conformité qu'ils reçoivent par ailleurs des composants de sécurité sont intègres, ces attestations sont accompagnées du certificat du fournisseur PKI qui comporte la clé publique du composant de sécurité.

Par ailleurs, comme décrit dans la suite, les données émanant du composant de sécurité peuvent être accompagnées d'un identifiant de connexion entre le système requérant et le module de vérification.

En référence à la figure 5, illustrant un diagramme de séquence entre le système requérant 16 (REQ_SYST), le module de vérification 18 (VERIF), un module de filtrage 508 (FILT) et un système sensible 500 (CRIT_SYST), on décrit un exemple de demande de communication par le système requérant 16 à un système sensible 500 d'un aéronef. Le traitement d'une attestation de conformité du système requérant 16 par le module de vérification 18 peut, par exemple, être initié par une demande d'établissement de connexion 501 (REQ_COM) du système requérant à un système d'information de l'aéronef (non représenté) qui la transmet au module de vérification 18. Le module de vérification peut être en mesure d'exploiter des informations complémentaires (par exemple une liste des systèmes autorisés à communiquer avec le système sensible) pour contrôler la demande et l'autorisation du requérant à communiquer avec le système d'information de l'aéronef qu'il souhaite joindre. Lorsque la demande 501 a été reçue, le module de vérification 18 demande la fourniture d'un certificat de conformité du système requérant dans un message 502 (REQ_ATTEST). Ce message peut en outre comporter un identifiant de session pour la communication demandée, que le système requérant peut joindre aux messages qu'il transmet pour les identifier. Suite à ce message 502, le système requérant transmet son attestation de conformité (ATTEST) dans un message 503. Comme évoqué, cette attestation de conformité comporte par exemple le statut d'intégrité courant du système tel que généré au démarrage (comme décrit en référence à la figure 2), avec éventuellement le statut d'intégrité de référence tel que généré par une autorité de confiance comme par exemple le constructeur du système requérant et/ou un résultat d'une comparaison des statuts d'intégrité courant et de référence. Le message 502 est aussi accompagné du certificat (CERT) comportant la clé publique du composant de sécurité pour permettre de vérifier la signature numérique de l'attestation de conformité et s'assurer qu'elle provient bien du composant de sécurité.

Une fois le message 503 reçu, le module de vérification 18 vérifie la signature, par le fournisseur PKI, du certificat contenu dans le message lors d'une étape S504 (CHCK SIGN), au moyen du certificat reçu dans le message 402 comme déjà évoqué en référence à la figure 4. Lors de la même étape, le module de vérification 18 vérifie la signature numérique de l'attestation avec la clé publique du composant de sécurité. Si l'attestation de conformité est authentifiée et intègre c'est-à-dire qu'elle provient bien du composant de sécurité et qu'il n'a pas été modifié, l'attestation de conformité proprement dite est vérifiée lors d'une étape S505 (CHCK ATTEST). L'objet de la vérification dépend du contenu de cette attestation de conformité, comme évoqué précédemment. Si, suite à l'étape S505, le module de vérification 18 juge le système requérant conforme au système de référence, il lui adresse un message 506 comportant une confirmation (OK) de la possibilité d'établir la communication demandée dans le message 501 avec un système sensible 500 (CRIT_SYST). Si le message 503 n'est pas authentifié, l'étape S505 n'est pas mise en oeuvre et le message 506 comporte un rejet de la demande de communication (NOK). Si, suite à l'étape S505, le module de vérification 18 ne juge pas le 20 système requérant 16 conforme au système de référence, le message 506 comporte un rejet de la demande de communication (NOK). Dans le cas où le message 506 comporte une confirmation de la possibilité d'établir une communication, le module de vérification 18 transmet également un message de confirmation 507 vers un module de filtrage 508 25 (FILT) des communications vers le système sensible 500. Ce message peut permettre à ce module de filtrage de mettre à jour, lors d'une étape S509 (UPDAT), une liste des systèmes requérants autorisés à communiquer avec le système sensible 500. Une fois la liste mise à jour, le système requérant n'a plus besoin de donner son attestation de conformité lors de la session de 30 communication en cours. Une communication 510 (COM) entre le système requérant 16 et le système sensible 500 est alors établie.

La figure 6 représente un exemple d'organigramme illustrant des étapes mises en oeuvre du côté du système requérant. Lors du démarrage du système requérant S60 (STRT), un statut d'intégrité courant est généré dans un composant de sécurité. Ensuite, lorsque le système requérant souhaite entrer en communication avec un système sensible, il émet une demande de communication lors d'une étape S61 (REQ COM), elle peut être accompagnée d'un statut d'intégrité de référence. Cette demande est transmise à un module de vérification. En réponse, il reçoit de la part du module de vérification une demande d'attestation de conformité lors d'une étape S62 (REQ ATTEST). Cette demande est accompagnée d'un identifiant de session de communication généré aléatoirement par le module de vérification. Le statut d'intégrité courant est mis à jour pour intégrer l'identifiant de communication. Ce processus permet de s'assurer de l'unicité du statut d'intégrité courant ainsi généré, et donc de se protéger d'une attaque par rejeu (« Replay Attack » en terminologie anglo- saxonne). Ensuite, sur la base du statut d'intégrité courant, une attestation de conformité de système est générée lors d'une étape S63 (GEN ATTEST). L'attestation de conformité est alors transmise par le système requérant, lors d'une étape S64 (TRANS ATTEST), vers le module de vérification. Le module de vérification envoie alors vers le système requérant un résultat d'une vérification de l'attestation de conformité envoyée qui est analysée lors de l'étape T65 (RESULT ?).

Si le résultat reçu est un rejet de la demande (NOK), le processus s'arrête lors d'une étape S66 (STOP) et la communication avec le système sensible n'est pas établie. Cela peut signifier que le système requérant a été altéré, par exemple par un code malicieux, depuis sa sortie d'usine auprès de son fabricant certifié.

Si le résultat reçu est une confirmation (OK) de la possibilité d'établir la communication, celle-ci est mise en oeuvre lors d'une étape S67 (COM).

Des exemples d'étapes mises en oeuvre par le module de vérification sont représentés dans l'organigramme de la figure 7. Dans une première étape S700 (REQ COM), le module de vérification reçoit de la part d'un système requérant une demande de communication. Il génère alors, par exemple de manière aléatoire, un identifiant de session lors d'une étape S701 (GEN ID). La demande de communication peut être accompagnée de du statut d'intégrité de référence. Dans ce cas, le module de vérification vérifie son authenticité grâce aux certificats comme déjà décrit en référence à la figure 4.

Lors d'une étape suivante S702 (REQ ATTEST), le module de vérification demande au système requérant une attestation de conformité. Par ailleurs, il lui transmet l'identifiant de session précédemment généré. Lorsqu'en réponse le module de vérification reçoit l'attestation de conformité lors d'une étape S703 (RECEP ATTEST), il vérifie la signature numérique de celle-ci lors d'une étape T704 (CHCK SIGNAT). Si l'attestation de conformité n'est pas intègre (NOK), le module de vérification rejette la demande du système requérant lors d'une étape S705 (REJECT), et transmet un message de refus lors d'une étape S706 (TRANS RESULT). Si l'attestation de conformité est intègre (OK), le module de vérification vérifie, lors d'une étape T707 (CHCK VALID), la validité du certificat numérique qu'il a par ailleurs reçu pour authentifier l'attestation de conformité. Si le certificat n'est plus valide (NOK), la demande est rejetée (étapes S705 et S706). Si au contraire le certificat est valide (OK), le module de vérification vérifie, lors d'une étape T708 (CHCK ID), que l'identifiant de session fourni par le système requérant correspond bien à celui généré lors de l'étape S701. Si l'identifiant ne correspond pas, la demande est rejetée (étapes S705 et S706).

Cette vérification peut se faire en appliquant une fonction de hachage sur l'identifiant généré lors de l'étape S701.

Si au contraire l'identifiant correspond, on passe à l'étape T709 (CHCK AUTORIZ) lors de laquelle le module de vérification vérifie si le système requérant est autorisé à communiquer avec le système sensible. Par exemple, il vérifie si le système requérant ne fait pas partie d'une liste noire de systèmes ayant été identifiés comme corrompus ou volés. Si le test de l'étape T709 n'est pas satisfait (NOK), la demande est rejetée (étapes S705 et S706). Si au contraire, le test de l'étape T709 est satisfait, on passe à l'étape T710 (CHCK ATTEST), lors de laquelle l'attestation de conformité est vérifiée pour déterminer si la communication doit être autorisée ou non. Si le test de l'étape T710 n'est pas satisfait, la demande est rejetée (étapes S705 et S706). Si au contraire, le test de l'étape T710 est satisfait, on passe à l'étape S711 (REQ UPDAT) lors de laquelle une liste des systèmes autorisés à 15 communiquer avec le système sensible est mise à jour. Ensuite, un message indiquant que la communication est possible est transmis au système requérant lors de l'étape S706. Le module de vérification peut donc assurer au moins une des fonctions suivantes. Il peut gérer des communications sécurisées avec des 20 systèmes requérants. Il peut authentifier sans ambiguïté les systèmes requérants et vérifier leurs éligibilités à communiquer avec des systèmes sensibles qu'ils souhaitent atteindre. Il peut authentifier sans ambiguïté l'origine des attestations de conformité des systèmes requérants. Il peut vérifier le contenu des attestations de conformité (par exemple vérifier si l'attestation de 25 conformité comporte l'information du type « intègre » / « non intègre » ou alors comparer des statuts d'intégrité courant et de référence). Il peut aussi mettre à jour des règles de filtrage autorisant un échange de données selon des conditions diverses et variées de type phase horaire, phase de maintenance, phase de vol, valeur d'une donnée, ou autre. 30 Des programmes d'ordinateur pour la mise en oeuvre de procédés selon des modes de réalisation de l'invention peuvent être réalisés par la personne du métier à la lecture des organigrammes des figues 2, 4-7 et/ou de la présente description détaillée. La figure 8 illustre un système requérant selon un mode de réalisation. Le système requérant 80 comporte ici une unité de mémoire 81 (MEM). Cette unité de mémoire peut comporter une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé selon des modes de réalisation. L'unité de mémoire peut par ailleurs comporter une mémoire non volatile (par exemple du type EEPROM, sigle de Electrically Erasable Programmable Read-Only Memory en terminologie anglo-saxonne) pour stocker par exemple un programme d'ordinateur selon un mode de réalisation pour son exécution par un processeur (non représenté) d'une unité de contrôle 82 (PROC) du système requérant. Le système requérant 80 comporte par ailleurs une unité de communication 83 (COM) pour mettre en oeuvre des communications, notamment avec un système sensible et pour transmettre une attestation de conformité à un module de vérification conformément à un procédé selon un mode de réalisation. Le système requérant comporte par ailleurs un composant de sécurité 84 (SECUR_COMP) permettant la génération d'une attestation de conformité selon des modes de réalisation de l'invention.

La figure 9 illustre un exemple d'architecture d'un système 90, par exemple un système sensible avec lequel un système requérant souhaite communiquer, comportant un module de vérification 94 (VERIF) pour autoriser ou non des communications avec l'extérieur selon un mode de réalisation. Le système 90 comporte une unité de mémoire 91 (MEM). Cette unité de mémoire comporte ici une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé selon des modes de réalisation. L'unité de mémoire comporte par ailleurs ici une mémoire non volatile (par exemple du type EEPROM) pour stocker par exemple un programme d'ordinateur selon un mode de réalisation pour son exécution par un processeur (non représenté) d'une unité de contrôle 92 (PROC). Le système 90 comporte par ailleurs une unité de communication 93 (COM) pour mettre en oeuvre des communications, notamment avec un système requérant et pour recevoir une attestation de conformité conformément à un procédé selon un mode de réalisation. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont 5 possibles.

Claims (15)

1. REVENDICATIONS1. Procédé pour initier une communication (509) entre un premier système de communication (12, 13, 16, 80) et un second système de communication (11, 15, 500, 90), comportant les étapes suivantes consistant à : - générer (S46, S61) une attestation de conformité (503) du premier système de communication, ladite attestation de conformité permettant de déterminer si le premier système de communication est conforme à un système de référence, et - envoyer (S64) l'attestation de conformité générée à destination du second système de communication afin de permettre au second système de communication de décider, en fonction de l'attestation de conformité reçue par le second système de communication, d'accepter ou non d'initier une communication avec le premier système de communication.
2. 2. Procédé selon la revendication 1, comportant en outre une étape de démarrage (S60) du premier système de communication et dans lequel l'attestation de conformité est générée en fonction du déroulement de ladite étape de démarrage du premier système de communication.
3. 3. Procédé selon la revendication 2, comportant en outre une étape de génération d'une empreinte de démarrage du premier système de communication.
4. 4. Procédé selon la revendication 3, dans lequel ladite empreinte de démarrage comporte un résultat d'une fonction de hachage appliquée sur des données utilisées lors de l'étape de démarrage du premier système de communication. 30
5. 5. Procédé selon l'une quelconque des revendications 3 ou 4, dans lequel ladite empreinte de démarrage comporte une empreinte de données d'un code informatique exécuté lors de l'étape de démarrage.25
6. 6. Procédé selon l'une quelconque des revendications 3 à 5, dans lequel l'attestation de conformité comporte ladite empreinte de démarrage.
7. 7. Procédé selon l'une des revendications 3 à 6, comportant en outre une étape de comparaison de l'empreinte de démarrage à une empreinte de référence pour déterminer si le premier système de communication est conforme au système de référence.
8. 8. Procédé selon la revendication 7, dans lequel l'attestation de conformité comporte une représentation du résultat de ladite étape de comparaison.
9. 9. Procédé selon l'une quelconque des revendications 1 à 8, comportant en outre une étape d'envoi d'une attestation de référence, prévue pour être comparée à l'attestation de conformité pour déterminer si le premier système de communication est conforme au système de référence.
10. 10. Procédé pour décider d'accepter ou non d'initier une communication avec un système de communication, comportant les étapes suivantes consistant à : - recevoir (S703) de la part du système de communication une attestation de conformité (503), ladite attestation de conformité permettant de déterminer si le système de communication est conforme à un système de référence, - déterminer (T710), à partir de l'attestation de conformité reçue, si le système de communication est conforme audit système de référence, et - décider (S706), en fonction d'un résultat de l'étape de détermination, d'accepter ou non d'initier une communication avec le système de communication.
11. 11. Procédé selon la revendication 10, comportant en outre une étape consistant à comparer l'attestation de conformité reçue à une attestation de conformité de référence pour déterminer si le système de communication est conforme audit système de référence.
12. 12. Procédé selon l'une quelconque des revendications 10 et 11, dans lequel l'attestation de conformité comporte une empreinte de démarrage du système de communication.
13. 13. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications précédentes lorsqu'il est chargé et exécuté par un processeur d'un système de communication. 10
14. 14. Système de communication (12,13, 80) comportant : - un composant (17, 17', 84) configuré pour générer une attestation de conformité permettant de déterminer si le système de communication est conforme à un système de référence, - une unité de contrôle (82) pour initier une communication avec un autre 15 système de communication, et - une unité de communication (83) pour transmettre l'attestation de conformité générée à destination dudit autre système de communication afin de permettre audit autre système de communication de décider, en fonction de l'attestation de conformité reçue par ledit autre système de communication, d'accepter ou 20 non d'initier une communication avec le système de communication.
15. 15. Système de communication (10, 15, 90) comportant : - une unité de contrôle (92) pour traiter une requête d'initiation d'une communication provenant d'un autre système de communication, 25 - une unité de communication (93) pour recevoir une attestation de conformité provenant dudit autre système de communication, et - un module de vérification (18, 18', 94) configuré pour vérifier une attestation de conformité afin de décider, en fonction de l'attestation de conformité reçue, d'accepter ou non d'initier la communication requise par ledit autre système.5