FR3113963A1 - Chaine de confiance avancee en aeronautique domaine de l'invention - Google Patents

Chaine de confiance avancee en aeronautique domaine de l'invention Download PDF

Info

Publication number
FR3113963A1
FR3113963A1 FR2009145A FR2009145A FR3113963A1 FR 3113963 A1 FR3113963 A1 FR 3113963A1 FR 2009145 A FR2009145 A FR 2009145A FR 2009145 A FR2009145 A FR 2009145A FR 3113963 A1 FR3113963 A1 FR 3113963A1
Authority
FR
France
Prior art keywords
metadata
public key
binary code
level
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2009145A
Other languages
English (en)
Other versions
FR3113963B1 (fr
Inventor
Stéphane Monnier
Alexandre Fine
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Priority to FR2009145A priority Critical patent/FR3113963B1/fr
Priority to US17/463,144 priority patent/US11876912B2/en
Publication of FR3113963A1 publication Critical patent/FR3113963A1/fr
Application granted granted Critical
Publication of FR3113963B1 publication Critical patent/FR3113963B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/68—Special signature format, e.g. XML format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé mis en œuvre par un calculateur avionique embarqué pour exécuter une pluralité de codes binaires associés à une pluralité d’ensembles de métadonnées, dans lequel: la pluralité de codes binaires et la pluralité de métadonnées sont hiérarchisés en un nombre de niveaux au moins égal à deux ; un premier code binaire, d’un niveau, est associé à un premier ensemble de métadonnées dudit niveau, et un deuxième code binaire d’un niveau inférieur, lui-même associé à un deuxième ensemble de métadonnées dudit niveau inférieur; le premier ensemble de métadonnées comprend une signature de données, lesdites données comprenant moins un premier condensat associé au premier code binaire, et le deuxième ensemble de métadonnées comprend une clé publique ; ledit procédé comprenant l’exécution, par le deuxième code binaire, des étapes suivantes: application d’une fonction de hachage pour obtenir un deuxième condensat du premier code binaire ; décryptage de la signature avec ladite clé publique pour obtenir ledit premier condensat ; autorisation de l’exécution du code binaire, si et seulement si et seulement si le premier condensat est identique au deuxième. Figure 3

Description

Chaine de confiance avancée en aéronautique
Domaine de l’invention
Le domaine de l’invention concerne la cyber sécurité. Le document décrit des systèmes et des procédés pour garantir l’authenticité et l’intégrité de logiciels exécutés sur une plateforme aéronautique embarquée.
Etat de l’art précédent.
L’exécution intègre et authentique de logiciels est difficile à garantir, de manière générale, et en aéronautique en particulier domaine pour lequel la sûreté est critique.
Parmi de nombreux problèmes techniques, il faut définir une architecture (matérielle et/ou logicielle) permettant de garantir, à tout le moins de de rendre robuste, l’exécution intègre (pas de corruption)etauthentique (signée par un détenteur d’un secret) de logiciels.
Ce problème est traditionnellement traité par des mécanismes de PKI (acronyme anglais pour Public Key Infrastructure - infrastructure à clé publique), en procédant notamment à la vérification de multiples signatures. Sur le plan matériel, ces mécanismes sont éventuellement couplés à un TPM (acronyme anglais deTrusted Platform Module ,en françaisModule de Plateforme Sécurisée), par exemple en charge d’enfouir une référence inaltérable dans le matériel. Dans une alternative, il peut être mis en place une « chaine de confiance », par récurrence, dans laquelle un élément initial vérifie l’authenticité et l’intégrité d’un élément de niveau supérieur, lequel à son tour vérifie un élément de niveau incrémenté. Par exemple, la séquence de démarrage ou BOOT peut vérifier le système d’exploitation ou OS (e.g. partitions, sommes de contrôle, etc), lequel vérifie à son tour progressivement le lancement d’applications logicielles, etc…
La littérature scientifique décrit de nombreuses techniques concernant les chaines de confiance. La littérature brevet comprend notamment le document EP2402879, lequel décrit un procédé d'installation logiciel embarqué. Cette méthode comprend la génération d'une ou plusieurs instances de fichiers de microprogrammes et la génération d'une ou plusieurs instances de certificats numériques qui sont des instances distinctes des instances de fichiers de microprogrammes. La méthode comprend l'association d'une ou plusieurs instances de certificat numérique avec une ou plusieurs instances de fichier de microprogramme afin de faciliter les mises à jour. Cette approche présente des limitations.
Il existe un besoin pour des procédés et des systèmes avancés de gestion de chaine de confiance en avionique.
Résumé de l’invention.
A cet effet, l’invention a pour objet un procédé mis en œuvre par un calculateur avionique embarqué pour exécuter une pluralité de codes binaires associés à une pluralité d’ensembles de métadonnées, dans lequel: la pluralité de codes binaires et la pluralité de métadonnées sont hiérarchisés en un nombre de niveaux au moins égal à deux ; un premier code binaire, d’un niveau, est associé à un premier ensemble de métadonnées dudit niveau, et un deuxième code binaire d’un niveau inférieur, lui-même associé à un deuxième ensemble de métadonnées dudit niveau inférieur; le premier ensemble de métadonnées comprend des données comprenant au moins un premier condensat associé au premier code binaire, et une signature des données ; le deuxième ensemble de métadonnées comprend une clé publique associée à la signature des données ; ledit procédé comprenant l’exécution, par le deuxième code binaire, des étapes suivantes: une vérification de la validité de la signature des données à l’aide de la clé publique ; si la signature des données est valide : application d’une fonction de hachage pour obtenir un deuxième condensat du premier code binaire ; une autorisation de l’exécution du premier code binaire, si et seulement si et seulement si le premier condensat est identique au deuxième.
Avantageusement, les données comprennent une pluralité de condensats associés à une pluralité de codes binaires dudit niveau ; si le premier ensemble de métadonnées est associé à un ensemble de métadonnées d’un niveau supérieur, les données comprennent au moins une clé publique associée à au moins une signature dudit ensemble de métadonnées du niveau supérieur.
Avantageusement, le procédé comprend en outre, si l’exécution du premier code binaire n’est pas autorisée, une étape d’envoi d’erreur à un système tiers.
Avantageusement, la clé publique est associée à un numéro d’instance ; ledit procédé comprend, en cas de révocation de la clé publique: l’incrémentation du numéro d’instance associé à la clé publique ; le remplacement de la signature des données par une nouvelle signature, obtenue par le chiffrement des données par une nouvelle clé privée associée à une nouvelle clé publique du deuxième ensemble de métadonnées ; et dans lequel l’exécution du premier code binaire n’est autorisée que si le numéro d’instance associé à la clé publique est supérieur ou égal au numéro d’instance associé à la dernière clé publique ayant permis son exécution.
Avantageusement, l’initialisation du chargement et de l’exécution d’un code binaire de premier niveau est permis par une clef publique engravée dans le matériel du calculateur avionique embarqué.
Avantageusement, chaque ensemble de métadonnées est associé à une pluralité de codes binaires de même niveau formant une application.
Avantageusement, la pluralité d’ensemble de métadonnées et la pluralité de code binaire forment un arbre enraciné, chaque nœud de l’arbre étant formé d’un ensemble de métadonnées et d’au moins un code binaire associé audit ensemble, et dans lequel l’exécution des codes binaires d’un nœud autre que le nœud racine est autorisé par un code binaire du nœud parent dudit nœud.
Avantageusement, le niveau inférieur est un niveau immédiatement inférieur.
L’invention a également pour un objet un produit programme d’ordinateur, ledit produit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon l’un des modes de réalisation de l’invention, lorsque ledit produit programme d’ordinateur est exécuté sur un ordinateur.
L’invention a également pour objet un système comprenant un calculateur avionique configuré pour mettre en œuvre des étapes du procédé selon l’un des modes de réalisation de l’invention.
D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :
un exemple de chaine de confiance, connu de l’état de la technique;
un autre exemple connu de l’état de la technique, spécifique à l’aéronautique ;
un exemple de mode de réalisation du procédé selon l’invention.
Certains acronymes anglo-saxons couramment utilisés dans le domaine technique de la présente demande pourront être employés au cours de la description. Ces acronymes sont listés dans le tableau ci-dessous, avec notamment leur expression anglo-saxonne et leur signification ainsi que la définition des principaux termes du domaine technique dans lequel se situe l’invention
Acronyme Expression Signification
ACD Aircraft Control Domain Domaine de Contrôle de l’aéronef. Regroupe les systèmes dont la fonction première est le contrôle de l’aéronef.
AISD Aircraft Information Service Domain Domaine de Service de l’Information de l’Aéronef. Regroupe les systèmes destinés à fournir des services et de la connectives à des systèmes aéronefs indépendants.
ARINC Aeronautical Radio INCorporated Société de Radio Aéronautique. Société détenue par de grands acteurs aéronautiques américains connue pour définir les principaux standards de communication à l’intérieur des aéronefs et entre les aéronefs et le sol. Désigne à la fois la société et les standards produits, par exemple les standards ARINC 429 ou ARINC 661.
ATC Air Traffic Control Contrôle de Circulation Aérienne (CCA). Service fourni par des contrôleurs aériens au sol pour diriger un aéronef au sol en sécurité.
EFB Electronic Flight Bag Sacoche de vol électronique. Dispositif électronique de gestion de l’information permettant aux équipages d’aéronef d’effectuer des tâches de gestion de vol plus facilement et efficacement, avec moins de papier.
FCC Flight Control Command Commandes de Contrôle de Vol.
FMS Flight Management System Système de Gestion de Vol. Système informatisé permettant de calculer des trajectoires et plans de vol d’aéronef, et de fournir les consignes de guidage adaptées au pilote ou pilote automatique pour suivre la trajectoire calculée.
Description détaillée de l’invention
La illustre un exemple de chaine de confiance, connu de l’état de la technique.
Dans cet exemple, la vérification se fait partransitivité: chaque niveau vérifie le niveau supérieur.
Selon cette approche le niveau k vérifie la signature du niveau k+1 tout en vérifiant aussi que la clé utilisée pour signer le niveau k+1 est reconnue comme légitime. Pour la vérification de cette légitimité, il est nécessaire d’intégrer la clé publique utilisée par le niveau N+1 dans le niveau N.
vérification est par exemple atteinte en vérifiant la signature d’un binaire. Cette signature est couramment déterminée en chiffrant le condensat du binaire (valeur de hachage ou hash) avec une clé privée. Typiquement, le condensat peut être le produit de l’algorithme SHA256, le chiffrement se faisant avec l’algorithme RSA 4096. Pour vérifier une signature, le condensat du binaire de cette signature doit être comparé avec le déchiffrement de la signature avec la clé publique
Cette approche de l’état de la technique n’est pas optimale pour plusieurs raisons.
Dans le cas d’une révocation d’une clé, la clé révoquée doit être enlevée de la liste des clés légitimes. Pour cela, il seraaussinécessaire de modifier le logiciel de niveau N en charge de vérifier la signature du logiciel de niveau N+1. Révoquer une clé utilisée pour signer un logiciel de niveau N+1, impose de modifier les logiciels de niveaux N et N+1 : a) le logiciel de niveau N pour enlever la clé et la remplacer par une nouvelle, et b) le logiciel de niveau N+1 pour signer le logiciel avec cette nouvelle clé. Cette situation ne convient pas en avionique.
La illustre un autre exemple connu de l’état de la technique, spécifique à l’aéronautique.
Un exemple de déroulement est décrit ci-après. Une clef enfouie ou gravée dans le matériel 210 (inaltérable) permet de charger et démarrer la séquence de démarrage BOOT 220, laquelle à son tour vérifie et démarre une première partie du système d’exploitation OS 230, qui démarre notamment des services systèmes, puis une autre partie (non représentée) qui charge des ressources destinées aux applications logicielles 240 qui vont être chargées en aval.
Des définitions de termes sont proposées ci-après.
Dans la suite du document, un « aéronef » peut être un avion commercial, ou un avion de fret, ou un hélicoptère, embarquant ou non des passagers. Ces termes désignent tout élément étant susceptible d’être télé-piloté (drone, par liaison radio, satellite, ou autre), au moins partiellement (de manière intermittente, ou périodique, ou même opportuniste au cours du temps).
Un aéronef comprend un ou plusieurs « calculateur avionique » (espècespécifiqued’ordinateur).
Un « calculateur avionique » est un système présentant des caractéristiques techniques spécifiques en comparaison d’un système « non-avionique » (ou « monde ouvert »), ces caractéristiques techniques étant certifiées administrativement par une autorité de confiance (en l’occurrence le régulateur aéronautique). La réglementation induit des caractéristiques techniques spécifiques. Concernant les caractéristiques techniques distinctives d’un système avionique, un système – de manière générale, i.e. avionique ou non-avionique - peut présenter ou être associé avec un taux de défaillance prédéfini (parmi une plage de taux de défaillance prédéfinie), un taux de défaillance comprenant ou déterminant un taux d’erreur d’exécution prédéfini. Dans un mode de réalisation, le taux de défaillance d’un système de type avionique est inférieur au taux de défaillance d’un système de type non-avionique. Dans un mode de réalisation, le taux de défaillance d’un système avionique est significativement ou substantiellement inférieur à celui d’un système non-avionique.
Un système ou calculateur avionique désigne un système fiabilisé (ou à fiabilité garantie). C’est un système dont la défaillance a des conséquences excédant des limites acceptées ou acceptables, donc redoutées. Une défaillance peut se caractériser par la perte de la fonction considérée, ou par la production de données erronées, avec ou sans détection d’une erreur. Selon le niveau de criticité des conséquences redoutées, la probabilité d’occurrence doit être maintenue inférieure à un seuil d’acceptabilité. Ainsi, plus la conséquence est critique, pour la probabilité d’occurrence acceptable est faible. Par exemple, en aéronautique, un événement catastrophique (décès multiples) devra avoir une probabilité d’occurrence inférieure à 10^-9 par heure de vol, alors qu’un incident majeur (réduction des marges de sécurité et des capacités opérationnelles, inconfort ou blessures légères) devra avoir une probabilité d’occurrence inférieure à 10^-5 par heure de vol. Pour assurer ces objectifs, l’architecture du système avionique selon l’invention (fiabilisé) ainsi que la conception de chaque composant garantissent cette probabilité d’occurrence par des garanties de taux de panne de chaque équipement (pannes physiques et/ou logiques) et des niveaux de vérification (couverture fonctionnelle et structurelle de test) des logiciels.
Un « code binaire » (ou ci-après un « logiciel ») est un code exécutable (e.g. des séquences d’instructions compilées), sur un ou plusieurs calculateur, ou des données que l’on nomme « database » (termes anglais signifiant en français « base de données »). Les codes binaires qui sont invoqués dans ce document sont des codes binaires particuliers, en ce qu’ils sont certifiés par le régulateur aérien (caractéristique administrative mais aussi technique dans la mesure où des propriétés techniques sont associées à ces codes, e.g. déterminisme, fiabilité, vérification symbolique, etc…). Un code binaire peut être tout ou partie d’un microprogramme ou firmware, d’un système d’opération, d’une application, d’un processus système on non, etc.
L’intégrité d’un code binaire signifie que ce code n’a pas été altéré ou attaqué ou corrompu ou autrement modifié (à l’exception des collisions de hachage, qui sont considérés ici comme improbables ou inexistantes).
La illustre un exemple de mode de réalisation du procédé selon l’invention.
Le procédé selon l’invention vérifie l’authenticité et l’intégrité d’un ou de plusieurs codes binaires. Les deux notions d’authenticité et d’intégrité sont indépendantes : en effet, il est possible d’avoir un code authentique mais non intègre, et inversement, il est possible d’avoir un code non authentique mais intègre. Ces deux dernières situations ne correspondent pas à des situations traitées par l’invention.
L’invention est basée sur plusieurs principes.
Tout d’abord les codes binaires sont hiérarchisés par niveaux successifs. Ils peuvent donc être rangés d’un niveau le plus bas ou niveau 1 à un niveau le plus haut ou niveau N. Il existe au moins deux niveaux, et l’exécution d’un code binaire de niveau k doit être autorisée par un code binaire d’un niveau inférieur k’. Ainsi, une chaîne de confiance est créée, consistant à autoriser séquentiellement l’exécution des codes, du plus bas au plus haut niveau.
Les codes binaires sont associés à des ensembles de métadonnées. Les ensembles de métadonnées sont également appelés certificats IMA (acronyme anglais pour Integrated Modular Avionics, ou avionique intégrée modulaire en français). Dans la suite de la description, on pourra utiliser, de manière interchangeable, le terme « ensemble de métadonnées », et certificat IMA.
Les ensembles de métadonnées sont également hiérarchisés par niveaux, et chaque ensemble de métadonnées est associé à un ou plusieurs codes binaires. De manière générale, chaque code binaire est associé à un unique ensemble de métadonnées, et chaque ensemble de métadonnées est associé à un ou plusieurs codes binaires.
Dans un ensemble de modes de réalisation de l’invention, chaque ensemble de métadonnées est associé à une pluralité de codes binaires de même niveau formant une application (par exemple, plusieurs codes binaires exécutables, et une base de données formant une application). Ceci permet de lier l’ensemble de l’application aux mêmes conditions d’exécution.
L’exécution d’un code binaire d’un niveau k, doit être autorisée par un code binaire d’un niveau inférieur k’. Afin de décrire plus en détails ce mécanisme, il sera décrit par le biais d’un premier code binaire de niveau k, et d’un deuxième code binaire de niveau inférieur k’. L’exécution du premier code binaire (de niveau k) doit être autorisée par le deuxième code binaire (de niveau k’).
Le premier code binaire (de niveau k) est associé à un premier ensemble de métadonnées, de niveau k également. Le deuxième code binaire (de niveau k’) est associé à un deuxième ensemble de métadonnées, du niveau inférieur k’ également .
Le niveau inférieur k’ peut être un niveau immédiatement inférieur k-1. Cependant, de manière plus générale, il peut s’agir de tout niveau inférieur k-1, k-2, k-3, etc… Ainsi, l’autorisation d’exécution d’un code binaire peut être fournie au niveau k par le niveau immédiatement inférieur k-1, ou un autre niveau inférieur de plus haut rang k-2, k-3, etc…
Dans la suite de la description, le mécanisme sera principalement décrit par la fourniture l’autorisation d’exécution d’un code de niveau k par un code de niveau k-1. Cependant, l’invention n’est pas limitée à ces exemples, et, comme indiqué ci-dessus, l’autorisation d’exécution peut également être fournie par un code de niveau k-2, k-3, etc…
Afin de permettre l’exécution des codes binaires, chaque ensemble de métadonnées comprend des données, comprenant elles-mêmes au moins un condensat d’un code binaire, et pouvant comprendre au moins une clé publique. Un ensemble de métadonnées comprend également une signature de ces données.
Plus particulièrement, le premier ensemble de métadonnées comprend des données comprenant au moins un premier condensat associé au premier code binaire, et une signature desdites données du premier ensemble de métadonnées, ou certificat IMA, de niveau k; et le deuxième ensemble de métadonnées, de niveau inférieur k’, comprend une clé publique associée à la signature de données du premier ensemble de métadonnées, ou certificat IMA, de niveau k. Si le premier code binaire est intègre, le premier condensat correspond au produit de l’application d’une fonction de hachage au premier code binaire. Si, de plus, les métadonnées sont authentiques et intègres, la signature des données correspond au cryptage d’un condensat des données avec une clé privée associée à la clé publique. Dans ce cas, la validité de la signature des données pourra être vérifiée avec succès en utilisant la clé publique du deuxième ensemble de métadonnées.
Afin d’autoriser ou non l’exécution du premier code binaire, le deuxième code binaire effectue les étapes suivantes.
Tout d’abord, il effectue une vérification de la validité de la signature des données à l’aide de la clé publique. En pratique, cette vérification consiste à décrypter la signature avec la clé publique contenue dans le deuxième ensemble de métadonnées, ou certificat IMA, de niveau inférieur k’, calculer un condensat des données contenues dans le premier ensemble de métadonnées en appliquant une fonction de hachage à ces données, puis comparer ce condensat au décryptage de la signature. Si les deux données obtenues sont identiques, la signature correspond bien aux mêmes données, cryptées avec la clé privée associée à la clé publique. Le premier ensemble de métadonnées peut alors être considéré comme authentique et intègre.
Ensuite, si la signature du premier ensemble de métadonnées est valide, le condensat du premier code binaire contenu dans le premier ensemble de métadonnées est considéré comme authentique et intègre, et le deuxième code binaire vérifie l’intégrité du premier code binaire.
Tout d’abord, il applique une fonction de hachage pour obtenir un deuxième condensat du premier code binaire. Il est bien sûr nécessaire que la même fonction de hachage soit utilisée à cette étape, que celle ayant été précédemment utilisée pour la génération du premier condensat. Cette fonction peut donc être une fonction prédéfinie.
Par exemple, la fonction SHA256 peut être utilisée. Cette fonction présente en effet l’avantage d’offrir à la fois un niveau de protection élevée, et d’être exécutable par un accélérateur cryptographique, permettant ainsi un temps d’exécution faible. Cette fonction peut ainsi être proposée de manière native par le calculateur avionique et utilisée par les codes binaires.
Enfin, le deuxième code binaire vérifie l’identité du premier condensat, contenue dans le premier ensemble de métadonnées, et du deuxième condensat, obtenu par le hachage du premier code binaire. L’exécution du premier code binaire n’est autorisée que si les deux condensats sont identiques.
En effet, une identité des deux condensats signifie que le condensat issu de l’application de la fonction de hachage au premier code binaire est bien le même que celui ayant servi pour la génération de la signature. Le premier code binaire est donc bien intègre.
Les caractéristiques de l’invention permettent donc bien l’exécution des codes binaires, si et seulement si ils sont authentiques et intègres.
De plus, en cas de révocation d’une clé ou d’un certificat, il suffit, de régénérer les métadonnées à l’aide d’une nouvelle paire de clés privées/clés publiques, c’est-à-dire qu’il suffit de remplacer la signature dans le premier ensemble de métadonnées par une nouvelle signature obtenue par une nouvelle clé privée, et remplacer la clé publique dans le deuxième ensemble de métadonnées par la clé publique associée à la nouvelle clé privée.
Contrairement aux solutions de l’état de l’art, il n’est donc pas nécessaire de régénérer les codes binaires eux-mêmes. L’invention permet ainsi une plus grande flexibilité dans l’autorisation d’exécution des codes binaires.
Si le mécanisme d’autorisation de l’exécution d’un code binaire a été ici décrit avec l’association de deux codes de deux niveaux successifs, ce mécanisme peut être généralisé à plusieurs niveaux, métadonnées, et codes.
Ainsi, les pluralités de codes et ensembles de métadonnées peuvent être représentés par un arbre enraciné, dans lequel chaque nœud de l’arbre est formé d’un ensemble de métadonnées et d’au moins un code binaire associé audit ensemble, et l’exécution des codes binaires d’un nœud autre que le nœud racine est autorisé par un code binaire du nœud parent dudit nœud. Dans cette représentation, le niveau d’une métadonnée ou d’un code binaire est défini par la profondeur du nœud auquel ils appartiennent. Typiquement, un nœud de l’arbre peut représenter une application, avec l’ensemble des codes binaires de l’application, et l’ensemble de métadonnées associé permettant l’exécution de l’application.
Ainsi, l’exécution d’un code est autorisée, de manière itérative, par l’ensemble des nœuds parents, ce qui permet d’établir de manière récursive l’authenticité et l’intégrité de l’ensemble des codes participant à l’exécution. Ainsi, une chaîne de confiance complète est obtenue.
Bien entendu, ceci n’est pas applicable à l’exécution d’un code binaire de premier niveau, donc situé à la racine de l’arbre.
Dans un ensemble de modes de réalisation de l’invention, ces codes de premier niveau peuvent cependant également être associés à un ensemble de métadonnées comprenant une signature, et l’autorisation d’exécution est identique à ce qui a été décrit précédemment, sauf que leur exécution est permise par une clef publique engravée dans le matériel du calculateur avionique, c’est-à-dire que la signature de l’ensemble de métadonnées du nœud racine doit être encryptée avec une clé privée associée à la clé publique engravée dans le matériel du calculateur avionique, et le condensat d’un code binaire de premier niveau obtenu par décodage de cette clé doit être identique à un condensat obtenu par hachage du code, pour que le code puisse s’exécuter.
Ceci permet de s’assurer qu’un code binaire de premier niveau / à la racine de l’arbre enraciné est bien authentique et intègre pour autoriser son exécution. Ceci permet de s’assurer que la chaîne de confiance est bien respectée, à partir du niveau d’exécution le plus bas, car la clé publique engravée dans le calculateur avionique est infalsifiable.
L’invention permet d’améliorer le temps d’exécution de la méthode d’autorisation d’exécution. En effet, pour une quantité de données à traiter équivalente, les fonctions de hachage sont aujourd’hui beaucoup plus rapides à exécuter que les fonctions de cryptage/décryptage. Dans ce cas, afin d’autoriser ou non l’exécution du premier code binaire, le cryptage/décryptage s’effectue uniquement sur un condensat des métadonnées, comprenant notamment un ou plusieurs condensats. Ainsi, les opérations lourdes en temps de calcul ne sont appliquées qu’une seule fois, ce qui permet un temps d’exécution faible. De plus, une unique vérification de signature du condensat est nécessaire afin de vérifier l’authenticité d’un ou plusieurs condensats. Le nombre d’appels à des fonctions de cryptographie (coûteuses en temps de calcul) s’en trouve donc réduit. Ceci est particulièrement pertinent dans le cas présent, puisque cela permet de réaliser la vérification de l’autorisation d’exécution d’un binaire en un temps réduit, et donc de ne pas retarder le chargement et l’exécution du code binaire.
Dans un ensemble de modes de réalisation de l’invention, les données signées du premier ensemble de métadonnées comprend : une pluralité de condensats associés à un ensemble de codes binaires dudit niveau k ; par exemple, l’ensemble des codes binaires peuvent correspondre aux codes binaires d’une même application ; par exemple, dans le cas où une structure en arbre est adoptée, l’ensemble de métadonnées peut comprendre un condensat par code binaire situé au même nœud de l’arbre.
Dans le cas où le premier ensemble de métadonnées est également associé à un ensemble de métadonnées de niveau immédiatement supérieur :
  • les données signées du premier ensemble de métadonnées comprennent au moins une clé publique associée à au moins une signature de l’ensemble de métadonnées d’un niveau supérieur k’’. Par exemple, si une structure en arbre est adoptée, le premier ensemble de métadonnées peut comprendre une clé publique pour l’ensemble de métadonnées de chaque nœud fils ;
  • la signature comprise dans le premier ensemble de métadonnées est donc une signature de données comprenant, en plus d’un ou plusieurs condensats de codes binaires, au moins une clé publique associée à au moins une signature d’un ensemble de métadonnées du niveau supérieur k’’ ; ainsi, la vérification de la signature permet, en une seule opération, de valider l’authenticité de l’ensemble condensats et clés publiques compris dans le premier ensemble de métadonnées. Dit autrement, lorsqu’une structure en arbre est adoptée, ceci permet de vérifier en une seule opération l’authenticité des condensats associés à l’ensemble des codes binaires du nœud courant, ainsi que des clés publiques permettant de vérifier l’authenticité des ensembles de métadonnées de chacun des nœuds fils.
Le niveau supérieur k’’ peut être un niveau immédiatement supérieur k+1, ou un niveau supérieur de plus haut rang k+2, k+3 etc…
Dans un ensemble de modes de réalisation de l’invention, les ensembles de métadonnées sont stockées dans des zones mémoires du calculateur avionique. Ces métadonnées sont stockées indépendamment des codes binaires. Cette indépendance permet notamment l’activation (respectivement la non-activation ou la désactivation) d’un ou de plusieurs des codes binaires embarqués.
L’invention permet ainsi de révoquer de manière sécurisée les clés qui ont permis de signer une application, sans avoir à modifier les applications de niveau inférieur. La gestion de l’autorisation d’exécution des différents codes logiciels est ainsi rendue plus dynamique.
Dans un ensemble de modes de réalisation de l’invention, le procédé comprend en outre l’étape consistant, si l’exécution du premier code binaire n’est pas autorisée, à communiquer l’erreur à un système tiers.
Cette étape est détectable. Une analyse système peut identifier l’erreur et sa cause (e.g. clef publique rejouée ou compromise), a posteriori. Dans un mode de réalisation (« interactif »), l’erreur et/ou des informations relatives à l’erreur peuvent être affichées. En d’autres termes, le procédé peut déterminer un log de sécurité et lever une alerte en fonction dudit log de sécurité.
Dans un ensemble de modes de réalisation de l’invention, une clef publique est associée à un intervalle temporel de validité, ledit intervalle étant associé à une ou plusieurs dates. Une clef publique peut expirer après une certaine date 1 prédéfinie. Une clef publique peut ne pas être utilisable avant une certaine date 2 prédéfinie. Une clef publique peut n’être utilisable qu’après une certaine date 3 et avant une date 4.
Dans un ensemble de modes de réalisation de l’invention, les ensembles de métadonnées sont également soumis à une date de validité des métadonnées. Ne pouvant pas interdire le démarrage d’un aéronef en cas d’un ensemble de métadonnées périmé, la date n’est pas utilisée pour autoriser ou non le lancement de l’exécution d’un logiciel. Cependant, de manière opérationnelle, quand la date est à disposition, la date d’un ensemble de métadonnées peut être vérifiée ; si elle n’est pas valide, une alarme peut être levée. De manière générale, divers schémas temporels peuvent être utilisés : e.g. Intervalles de temps prédéfinis, comprenant des instants temporels absolus et/ou des durées.
Dans un ensemble de modes de réalisation, le procédé comprend en outre un mécanisme dit antiretour de gestion des clefs publiques. Ce mécanisme consiste à empêcher, après la révocation d’une clé publique, l’autorisation d’exécution d’un code binaire sur la base d’un ancien ensemble de métadonnées.
Pour ce faire la clé publique est associée à un numéro d’instance. En cas de révocation de la clé publique associée à la signature de du premier ensemble de métadonnées, plusieurs opérations sont menées :
  • le numéro d’instance associé à la clé publique est incrémenté ;
  • la signature des données du premier ensemble de métadonnées est remplacée par une nouvelle signature, obtenue par le chiffrement des données par une nouvelle clé privée associée à une nouvelle clé publique du deuxième ensemble de métadonnées.
Ainsi, la nouvelle signature est complètement compatible avec la nouvelle clé publique, et l’exécution du premier code binaire peut être autorisée ou non, de manière transparente. De plus, dans le cadre du mécanisme d’antiretour de clé publique, l’exécution du premier code binaire n’est autorisée que si le numéro d’instance de la clé publique permettant le décryptage de la signature d’un ensemble de métadonnée qui lui est associé est supérieur ou égal au numéro d’instance de la dernière clé publique ayant permis le décryptage de l’ensemble de métadonnées, c’est-à-dire qu’une fois chargé un ensemble de métadonnées associé à une clé publique avec un numéro d’instance incrémenté, il n’est plus possible d’autoriser l’exécution de ce code binaire sur la base d’un ancien ensemble de métadonnées. Ceci permet de prévenir une attaque basée sur le chargement d’un ancien certificat IMA ou d’une ancienne application dont la clé aurait été corrompue.
L’obtention de la nouvelle clé publique peut se faire de différentes manières. Dans un ensemble de modes de réalisation de l’invention, une nouvelle paire de clés comprenant la nouvelle clé publique et la nouvelle clé privée est générée, puis la nouvelle clé publique vient remplacer la clé publique initiale dans le deuxième ensemble de métadonnées.
Il est également possible de disposer à l’avance de plusieurs paires de clés privées et publiques, toutes les clés publiques étant comprises dans le deuxième ensemble de métadonnées, chacune associée à un numéro d’instance. Lorsque le numéro d’instance est incrémenté, la clé publique correspondant au nouveau numéro d’instance est sélectionnée, et la clé privée correspondante utilisée pour générer la nouvelle signature. Ce dernier mode de réalisation présente l’avantage que, lorsqu’une clé publique est révoquée, seul le premier de métadonnées correspondant doit être re-signé, la nouvelle clé publique étant déjà présente dans le deuxième ensemble de métadonnées, lui-même signé. Ainsi, la chaîne de confiance comprend la signature de toutes les clés publiques utilisées, mais, en cas de révocation d’une clé publique, seul un ensemble de métadonnées doit être re-signé.
Le mécanisme antiretour de gestion des clés publiques peut être mis en œuvre de différentes manières. Par exemple, le téléchargement d’un ensemble de métadonnées associé à une clé publique ayant un numéro d’instance inférieur au numéro d’instance de la clé publique courante peut être empêché. Alternativement, le numéro d’instance le plus élevé associé à une clé publique donnée peut être stocké, et le décryptage d’un ensemble de métadonnées correspondant via une clé publique ayant un numéro d’instance inférieur empêché.
De cette manière, lors de la révocation d’une clé, une fois le nouvel ensemble de métadonnées chargé avec une clé publique ayant un numéro d’instance incrémenté, il devient impossible de charger un ancien certificat IMA ou une ancienne application. Cette vérification d’autorisation étant faite au moment du téléchargement ou de l’exécution. Ce mécanisme anti-retour (« anti rollback » en anglais) ou « à cliquets » permet d’éviter un rejeu d’attaque : si une clef publique de niveau k est compromise alors un attaquant pourrait falsifier un niveau k+1 et lancer l’exécution d’un code malicieux.
Ainsi, il ne sera plus possible de charger ou d’exécuter un ancien logiciel présentant des vulnérabilités. De plus, il n’est ainsi pas possible pour un attaquant de recharger d’anciennes métadonnées avec une clé volée.
Il est décrit un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer une ou plusieurs des étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur.
Il est décrit un système comprenant un calculateur avionique déterministe pour la mise en œuvre d’une ou de plusieurs étapes du procédé.
La montre un exemple de métadonnées et codes binaires dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, sont représentés :
  • 5 ensembles de métadonnées Certificat IMA K-1_A, Certificat IMA K_A, Certificat IMA K_B, Certificat IMA K_C, Certificat IMA K+1_A ;
  • 9 codes binaires Bin K_A_1, Bin K_A_2, Bin K_A_3, Bin K_B_1, Bin K_B_2, Bin K_C_1, Bin K+1_A_1, Bin K+1_A_2, Bin K+1_A_3.
Les codes binaires et ensembles de métadonnées sont organisés par niveaux successifs, avec ici :
  • un niveau inférieur k-1, comprenant Certificat IMA K-1_A ;
  • un niveau intermédiaire k ;
  • un niveau supérieur k+1
Enfin, les métadonnées et codes binaires sont organisés selon des nœuds de l’arbre, avec ici :
  • un nœud K-1_A, de niveau k-1, comprenant l’ensemble de métadonnées Certificat IMA K-1_A, et au moins un code binaire non représenté ;
  • un nœud K_A, de niveau k, fils du nœud K-1_A, comprenant l’ensemble de métadonnées Certificat IMA K_A, et les codes binaires Bin K_A_1, Bin K_A_2 et Bin K_A_3 ;
  • un nœud K_B, de niveau k, fils du nœud K-1_A, comprenant l’ensemble de métadonnées Certificat IMA K_B, et les codes binaires Bin K_B_1 et Bin K_B_2 ;
  • un nœud K_C, de niveau k, fils du nœud K-1_A, comprenant l’ensemble de métadonnées Certificat IMA K_C, et le codes binaires Bin K_C_1 ;
  • un nœud K+1_A, de niveau k +1, fils du nœud K_B, comprenant l’ensemble de métadonnées Certificat IMA K+1_A, et les codes binaires Bin K+1_A_1, Bin K+1_A_2 et Bin K+1_A_3.
Typiquement, les binaires d’un même nœud peuvent correspondre à l’ensemble d’une application
Afin de clarifier la , seule une partie des binaires et métadonnées de l’exemple sont représentés. Par exemple, le nœud K-1_A comprenant le Certificat IMA K-1_A comprend également au moins un code binaire, et le nœud K_A comprend plusieurs fils.
Dans cet exemple, chaque ensemble de métadonnées peut comprendre un ou plusieurs éléments parmi :
  • un ou plusieurs condensats obtenus par l’application d’une fonction de hachage aux binaires du même nœud que l’ensemble de métadonnées ;
  • une ou plusieurs clés publiques permettant de décrypter une signature des ensembles de métadonnées des nœuds fils ;
  • une signature du ou des condensats et clés publiques de l’ensemble de métadonnées.
A titre d’exemple, dans la , l’ensemble de métadonnées Certificat IMA K_A comprend :
  • 3 condensats Condensat Bin_K_A_1, Condensat Bin_K_A_2, Condensat Bin_K_A_3 correspondant respectivement au produit de l’application d’une fonction de hachage aux codes binaires Bin K_A_1, Bin K_A_2, Bin K_A_3 ;
  • t clés publiques Key K_A1, K_A2, … K_At correspondant respectivement à des ensembles de métadonnées de t nœuds fils du nœud K_A ;
  • une signature Certificat IMA_K_A signature, correspondant à une signature de l’ensemble de données formées par les 3 condensats et les t clés publiques, avec une clé privée, dont la clé publique correspondante est contenue dans le certificat Certificat IMA_K-1_A
Ainsi, l’authenticité de chaque ensemble de métadonnées est vérifiée par vérification de sa signature, grâce à une clé publique contenue dans la métadonnée du nœud parent, et l’intégrité des binaires est vérifiée via les condensats compris dans les ensembles de métadonnées du même nœud.
Ceci permet de définir une chaîne de confiance complète, partant d’un des métadonnées d’un nœud racine (ici Certificat IMA K-1_A), jusqu’à chaque binaire de chaque nœud.
Calculateur avionique
De manière générale, il n’existe pas de risque systémique dans les calculateurs avioniques. D’une part, les applications sont cloisonnées ou isolées ou confinées i.e. ne partagent pas de ressources communes qui pourraient être erronées (ou attaquées). D’autre part, à un niveau encore supérieur, hors du propos de ce document, les calculateurs sont dupliqués ou tripliqués, par divers mécanismes de sécurité intégrée (appelée en anglais « failsafe »).
Il est cependant remarquable de noter la propriété de déterminisme du système d’exploitation (par exemple, le système d’exploitation appelé « PikeOS »). Dans les ordinateurs personnels (monde ouvert), les prédictions de branche d’instructions peuvent conduire à des comportements non constants voire erratiques. Dans l’aéronautique, les mêmes données traitées par les mêmes algorithmes donnent les mêmes résultats (reproductibilité). En d’autres termes, les calculateurs avioniques sont d’une espèce d’ordinateur tout à fait particulier, défini notamment par la norme ARINC 653.
L’architecture des systèmes avioniques vise à détecter les données erronées et la propagation de pannes.
Dans un mode de réalisation, en lieu et place d’un système d’exploitation complet, le calculateur aéronautique peut se réduire à un séquenceur. Un séquenceur est installé dans le cockpit d’un aéronef. A bas niveau, il traite séquentiellement des commandes de vol, pour traiter des lois des commandes de vols, de manière prédéfinie. Par exemple, pendant 50 millisecondes, les commandes de vol sont seules concernées, les 50 ms suivantes sont utilisées pour d’autres consignes.
De manière générale, le périmètre de l’invention (i.e. les calculateurs adressés par le procédé selon l’invention et ses variantes) est celui de l’ACD.
Le périmètre ACD comprend des données et/ou des calculateurs certifiés FMS , de Pilote Automatique ou PA, des commandes de vol ou FCC, des données des systèmes de localisation ou IRS/GNSS/ADC, des données des systèmes de surveillance ACAS-TCAS, TAWS-GPWS et radar, des données des systèmes de roulage ou AOF, des données systèmes de communication radios RMS/RMP, des données de communications sans fil compagnie, des données de trafic aérien AOC ou ATC, des données de gestion des systèmes de maintenance, d’alerte, des données de motorisation, des données des systèmes de climatisation, des données gestion des trains d’atterrissage, des données concernant les actionneurs, des données concernant la distribution électrique et/ou hydraulique dans l’aéronef.
Par contraste, le domaine dit AISD n’est pas concerné par l’invention. Le périmètre concerne les sacs de vol électroniques ou EFB, les systèmes cabine ou IFE, des données issues de systèmes au sol, etc.
Si la cascade de signatures est vérifiée correctement, alors le système global est (démarré et exécuté de manière) authentique et intègre.
L’invention peut s’implémenter à partir d’éléments matériels et/ou logiciels. Elle peut être disponible en tant que produit programme d’ordinateur sur un support lisible par ordinateur. L’ordinateur peut être un calculateur de vol avionique. Le support peut être électronique, magnétique, optique, ou électromagnétique. Matériellement, les modes de réalisation de l’invention peuvent être divers. Par exemple, une architecture distribuée du type « informatique dans les nuages » (« cloud computing » en anglais) peut être utilisée. Des serveurs en pair-à-pair, entièrement ou partiellement distribués (existences de centres) peuvent interagir. L’invention ne se limite pas aux aéronefs et peut être implémentés dans les systèmes à sûreté critique («safety-critical systems» en anglais).
Les exemples ci-dessus démontrent la capacité de l’invention à proposer une chaîne de confiance permettant l’exécution sécurisée de code dans le domaine des calculateurs de vol. Ils ne sont cependant donnés qu’à titre d’exemple et ne limitent en aucun cas la portée de l’invention, définie dans les revendications ci-dessous.

Claims (10)

  1. Procédé mis en œuvre par un calculateur avionique embarqué pour exécuter une pluralité de codes binaires associés à une pluralité d’ensembles de métadonnées, dans lequel:
    • la pluralité de codes binaires et la pluralité de métadonnées sont hiérarchisés en un nombre (M) de niveaux au moins égal à deux ;
    • un premier code binaire, d’un niveau (k), est associé à un premier ensemble de métadonnées dudit niveau (k), et un deuxième code binaire d’un niveau inférieur (k’), lui-même associé à un deuxième ensemble de métadonnées dudit niveau inférieur (k’);
    • le premier ensemble de métadonnées comprend des données comprenant au moins un premier condensat associé au premier code binaire, et une signature des données ;
    • le deuxième ensemble de métadonnées comprend une clé publique associée à la signature des données ;
    ledit procédé comprenant l’exécution, par le deuxième code binaire, des étapes suivantes:
    • une vérification de la validité de la signature des données à l’aide de la clé publique ;
    • si la signature des données est valide :
      • application d’une fonction de hachage pour obtenir un deuxième condensat du premier code binaire ;
      • une autorisation de l’exécution du premier code binaire, si et seulement si et seulement si le premier condensat est identique au deuxième.
  2. Procédé selon la revendication 1, dans lequel :
    • les données comprennent une pluralité de condensats associés à une pluralité de codes binaires dudit niveau (k) ;
    • si le premier ensemble de métadonnées est associé à un ensemble de métadonnées d’un niveau supérieur (k’’), les données comprennent au moins une clé publique associée à au moins une signature dudit ensemble de métadonnées du niveau supérieur (k’’).
  3. Procédé selon l’une quelconque des revendications précédentes, comprenant en outre, si l’exécution du premier code binaire n’est pas autorisée, une étape d’envoi d’erreur à un système tiers.
  4. Procédé selon l’une quelconque des revendications précédentes, dans lequel :
    • la clé publique est associée à un numéro d’instance ;
    • ledit procédé comprend, en cas de révocation de la clé publique:
      • l’incrémentation du numéro d’instance associé à la clé publique ;
      • le remplacement de la signature des données par une nouvelle signature, obtenue par le chiffrement des données par une nouvelle clé privée associée à une nouvelle clé publique du deuxième ensemble de métadonnées ;
    • et dans lequel l’exécution du premier code binaire n’est autorisée que si le numéro d’instance associé à la clé publique est supérieur ou égal au numéro d’instance associé à la dernière clé publique ayant permis son exécution.
  5. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’initialisation du chargement et de l’exécution d’un code binaire de premier niveau est permis par une clef publique engravée dans le matériel du calculateur avionique embarqué.
  6. Procédé selon l’une quelconque des revendications précédentes, dans lequel chaque ensemble de métadonnées est associé à une pluralité de codes binaires de même niveau formant une application.
  7. Procédé selon l’une quelconque des revendications précédentes, dans lequel la pluralité d’ensemble de métadonnées et la pluralité de code binaire forment un arbre enraciné, chaque nœud de l’arbre étant formé d’un ensemble de métadonnées et d’au moins un code binaire associé audit ensemble, et dans lequel l’exécution des codes binaires d’un nœud autre que le nœud racine est autorisé par un code binaire du nœud parent dudit nœud.
  8. Procédé selon l’une des revendications précédentes, dans lequel le niveau inférieur (k’) est un niveau immédiatement inférieur (k-1).
  9. Un produit programme d’ordinateur, ledit produit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 8, lorsque ledit produit programme d’ordinateur est exécuté sur un ordinateur.
  10. Un système comprenant un calculateur avionique configuré pour mettre en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 8.
FR2009145A 2020-09-10 2020-09-10 Chaine de confiance avancee en aeronautique domaine de l'invention Active FR3113963B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2009145A FR3113963B1 (fr) 2020-09-10 2020-09-10 Chaine de confiance avancee en aeronautique domaine de l'invention
US17/463,144 US11876912B2 (en) 2020-09-10 2021-08-31 Aerospace advanced chain of trust

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2009145A FR3113963B1 (fr) 2020-09-10 2020-09-10 Chaine de confiance avancee en aeronautique domaine de l'invention
FR2009145 2020-09-10

Publications (2)

Publication Number Publication Date
FR3113963A1 true FR3113963A1 (fr) 2022-03-11
FR3113963B1 FR3113963B1 (fr) 2023-06-30

Family

ID=74045617

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2009145A Active FR3113963B1 (fr) 2020-09-10 2020-09-10 Chaine de confiance avancee en aeronautique domaine de l'invention

Country Status (2)

Country Link
US (1) US11876912B2 (fr)
FR (1) FR3113963B1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3113963B1 (fr) * 2020-09-10 2023-06-30 Thales Sa Chaine de confiance avancee en aeronautique domaine de l'invention

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0686906A2 (fr) * 1994-06-10 1995-12-13 Sun Microsystems, Inc. Procédé et dispositif pour améliorer la sûreté de logiciel et pour la distribution de logiciel
EP2402879A1 (fr) 2010-07-01 2012-01-04 Rockwell Automation Technologies, Inc. Procédés de signature de micrologiciel
US20120131322A1 (en) * 2006-07-18 2012-05-24 Certicom Corp. System and Method for Authenticating a Gaming Device
EP2962241A1 (fr) * 2013-03-01 2016-01-06 Intel Corporation Continuation de confiance pour microprogramme de démarrage de plate-forme

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002065282A2 (fr) * 2001-02-09 2002-08-22 Microsoft Corporation Distribution d'executables binaires et de contenu a partir d'emplacements/de machines homologues
US20070157146A1 (en) * 2006-01-03 2007-07-05 Mediatek Inc. Method of packing-based macro placement and semiconductor chip using the same
JP4359622B2 (ja) * 2007-01-22 2009-11-04 富士通株式会社 電子署名プログラム、および電子署名装置
US9721101B2 (en) * 2013-06-24 2017-08-01 Red Hat, Inc. System wide root of trust chaining via signed applications
FR2979442B1 (fr) * 2011-08-29 2013-08-16 Inside Secure Microprocesseur protege contre le vidage de memoire
EP2860904A1 (fr) * 2013-10-08 2015-04-15 Thomson Licensing Procédé de signature d'un ensemble d'éléments binaires et mise à jour de signature, dispositif électronique correspondant et produit de programme informatique
US10599853B2 (en) * 2014-10-21 2020-03-24 Princeton University Trust architecture and related methods
US9536080B2 (en) * 2015-05-29 2017-01-03 Apple Inc. Method for validating dynamically loaded libraries using team identifiers
US20170255775A1 (en) * 2016-03-02 2017-09-07 Apple Inc Software verification systems with multiple verification paths
US11314865B2 (en) * 2017-08-01 2022-04-26 The Trustees Of Princeton University Pluggable trust architecture
US10754952B2 (en) * 2018-07-23 2020-08-25 Vmware, Inc. Host software metadata verification during remote attestation
US11398896B2 (en) * 2019-01-11 2022-07-26 Johnson Controls Tyco IP Holdings LLP Building device with blockchain based verification of building device files
US11574060B2 (en) * 2019-04-24 2023-02-07 International Business Machines Corporation Secure initial program load
US11513701B2 (en) * 2019-05-03 2022-11-29 EMC IP Holding Company LLC Storage management system and method
US11544095B2 (en) * 2019-06-28 2023-01-03 Microsoft Technology Licensing, Llc Container management system with a remote sharing manager
US11093169B1 (en) * 2020-04-29 2021-08-17 EMC IP Holding Company LLC Lockless metadata binary tree access
US11356275B2 (en) * 2020-05-27 2022-06-07 International Business Machines Corporation Electronically verifying a process flow
FR3113963B1 (fr) * 2020-09-10 2023-06-30 Thales Sa Chaine de confiance avancee en aeronautique domaine de l'invention

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0686906A2 (fr) * 1994-06-10 1995-12-13 Sun Microsystems, Inc. Procédé et dispositif pour améliorer la sûreté de logiciel et pour la distribution de logiciel
US20120131322A1 (en) * 2006-07-18 2012-05-24 Certicom Corp. System and Method for Authenticating a Gaming Device
EP2402879A1 (fr) 2010-07-01 2012-01-04 Rockwell Automation Technologies, Inc. Procédés de signature de micrologiciel
EP2962241A1 (fr) * 2013-03-01 2016-01-06 Intel Corporation Continuation de confiance pour microprogramme de démarrage de plate-forme

Also Published As

Publication number Publication date
US11876912B2 (en) 2024-01-16
US20220078021A1 (en) 2022-03-10
FR3113963B1 (fr) 2023-06-30

Similar Documents

Publication Publication Date Title
KR102310252B1 (ko) 자동차 운전자 보조 시스템에 관련된 방법
US10956555B2 (en) Management system, vehicle, and information processing method
US20180131697A1 (en) Hardware components configured for secure physical separation of communication networks in a vehicle and methods of use thereof
US9419802B2 (en) Secure message filtering to vehicle electronic control units with secure provisioning of message filtering rules
RU2638736C2 (ru) Верификация информации воздушного летательного аппарата в ответ на скомпрометированный цифровой сертификат
CN112783518B (zh) 一种基于ipfs的车载应用容器化隔离的框架系统及实现方法
KR20210059003A (ko) 디바이스의 보안 프로비저닝 및 관리
US20210377004A1 (en) Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Servers
Kuppusamy et al. Uptane: Security and customizability of software updates for vehicles
CN104683409A (zh) 终端间应用共享的方法和终端
EP2178016A2 (fr) Procédé de fonctionnement d'un équipement embarqué, équipement associé et aéronef comprenant un tel équipement
CA3152085C (fr) Surveillance passive et prevention de mises a niveau non autorisees de micrologiciel ou de logiciel entre des dispositifs informatiques
EP2460071A2 (fr) Traitement automatisé de données multi-usages, mettant en oeuvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité
US11328065B1 (en) Architectures, systems, and methods for building trusted and secure artifacts
CN106850529B (zh) 利用冗余线路可替换单元（“lru”）和复合飞机可更改信息（“ami”）的飞机身份管理
FR3113963A1 (fr) Chaine de confiance avancee en aeronautique domaine de l'invention
CN107409044B (zh) 针对具有可替换部件的机器的数字标识和授权
US20220156377A1 (en) Firmware runtime patch secure release process
US11805407B2 (en) Apparatus and method for securely updating binary data in vehicle
US20230336356A1 (en) Data storage device, data storage method, and non-transitory computer readable storage medium
US9239247B1 (en) Verification of devices connected to aircraft data processing systems
US11321494B2 (en) Platform configurations
FR2927181A1 (fr) Procede et dispositif de commande securises pour terminal de maintenance deporte.
CN112733123B (zh) 授权管理方法和分布式管理系统
Tratter et al. Shared Mobility for Transport and Its Environmental Impact VeSIPreS: A Vehicular Soft Integrity Preservation Scheme for Shared Mobility

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220311

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4