Brevet FR2912578A1 — publié le 20080815

MÉTHODE D'AUTHENTIFICATION D'UN DOCUMENT ÉLECTRONIQUE ET MÉTHODE DE VÉRIFICATION D'UN DOCUMENT AINSI AUTHENTIFIÉ DESCRIPTION DOMAINE TECHNIQUE La présente invention concerne de manière générale le domaine de la sécurité informatique et en particulier celui de la sécurité de fichiers embarqués à bord d'un aéronef. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les opérations de maintenance, de configuration ou de mise à niveau d'un aéronef nécessitent couramment le téléchargement de fichiers de programmes ou de données à bord de calculateurs ou de systèmes avioniques embarqués. Ce téléchargement de fichiers peut être réalisé grâce à un terminal (non embarqué) de chargement, encore dénommé Data Loader, via une passerelle de téléchargement (embarquée), à destination d'un ou de plusieurs équipements de l'aéronef. De maniere conventionnelle, les fichiers à télécharger sont organisés selon un format normalisé par le standard ARINC 665, disponible sous le site www.arinc.com. Ce format comprend essentiellement un en-tête (Header File) contenant une liste identifiant les fichiers à télécharger, suivi de ces fichiers eux-mêmes (Data Files), et d'un fichier ou plusieurs fichiers dits de support (Support File). Le fichier d'en-tête comprend également un code de détection d'erreur (CRC) permettant de vérifier l'intégrité des fichiers reçus. Le téléchargement des fichiers ainsi organisés obéit lui-même à un protocole de communication spécifique, normalisé dans le standard ARINC 615-3 et/ou ARINC 615A. Selon ce protocole, le terminal de chargement transmet dans un premier temps l'en-tête précité à l'équipement destinataire. Ce dernier en déduit la liste des fichiers à télécharger et vérifie leur intégrité au fur et à mesure qu'il les reçoit du terminal de chargement. Une telle méthode de téléchargement de fichiers est connue de l'état de la technique, notamment de la demande de brevet FR-A-2837585 déposée au nom de la présente demanderesse. Cette méthode de téléchargement ne répond cependant plus aux exigences de sécurité informatique que l'on attend désormais des équipements embarqués. En particulier, le code CRC précité ne permet au mieux que de vérifier si un fichier est dépourvu d'erreurs, par exemple d'erreurs de transmission ou d'enregistrement. On conçoit qu'il soit aisé d'altérer volontairement le contenu d'un fichier et d'en recalculer le code CRC, de sorte qu'aucune erreur ne serait détectée lors de la vérification de l'intégrité du fichier. Ainsi, une action malveillante de modification du fichier pourra fort bien passer inaperçue. Afin de combattre les différents types de menaces 30 qui pèsent sur les opérations d'un avion, et notamment de se prémunir d'un piratage informatique, il devient indispensable de s'assurer de l'authenticité des fichiers téléchargés. Par authenticité d'un fichier, on entend à la fois la garantie de son origine, c'est-à-dire du fait qu'il émane bien du fournisseur du fichier (par exemple constructeur aéronautique, compagnie aérienne), et la garantie de l'intégrité de son contenu, c'est-à-dire du fait que ce dernier n'a pas été altéré accidentellement ou intentionnellement. Une solution connue pour s'assurer de l'authenticité d'un fichier est de recourir à une signature numérique utilisant un algorithme de cryptographie asymétrique et une infrastructure à clés publiques. Selon ce schéma, le fournisseur signe une empreinte numérique du fichier à l'aide de sa clé privée et joint au fichier signé la clé publique correspondante, généralement certifiée par une autorité de certification. L'utilisateur du fichier peut vérifier à l'aide de la clé publique et de la signature numérique que le fichier en question est bien celui originellement signé par le fournisseur. Le certificat délivré par l'autorité de certification atteste que la clé publique appartient effectivement au fournisseur. En pratique, un tel certificat possède une durée de validité limitée (généralement à un an), sensiblement inférieure à la durée d'exploitation des avions commerciaux. Or, lorsque le certificat expire, la clé publique perd sa validité et les fichiers qui ont été signés avec la clé privée correspondante voient par conséquent leur authenticité invalidée. Afin de proroger l'authentification, le fournisseur pourrait ajouter périodiquement une nouvelle signature numérique aux fichiers déjà livrés et les livrer à nouveau à ses clients. Cela imposerait cependant aux clients d'effectuer des mises à jour systématiques de tous les fichiers embarqués. Cette solution, bien que techniquement réalisable, serait fortement pénalisante en termes de coût d'exploitation, tant pour le fournisseur que pour la compagnie aérienne. Le but de présente invention est par conséquent de proposer une méthode d'authentification de fichiers qui ne soit pas sujette à péremption, c'est-à-dire qui permette de garantir une fois pour toutes l'intégrité et l'origine d'un fichier, dès son élaboration. EXPOSÉ DE L'INVENTION La présente invention est définie par une méthode d'authentification d'un document électronique, en particulier d'un fichier destiné à être embarqué à bord d'un aéronef, comprenant : - la génération d'une signature numérique dudit document électronique à l'aide d'une clé privée correspondant à une clé publique certifiée par une autorité de certification ; une requête d'horodatage dudit document électronique auprès d'une autorité d'horodatage pour obtenir un jeton d'horodatage signe par cette autorité ; une requête d'obtention du statut du certificat de ladite clé publique, faisant suite à ladite requête d'horodatage -l'adjonction au dit document électronique de la signature numérique, du jeton d'horodatage et du statut dudit certificat pour créer un document électronique authentifié. Selon un premier mode de réalisation, le document comprend un fichier et la signature du document est obtenue en codant une empreinte numérique dudit fichier avec ladite clé privée. Le document peut être de type XML et la signature du document est alors fournie au format XMLDsig. Selon un second mode de réalisation, le document comprend une pluralité de fichiers et la signature numérique du document est obtenue par : - la génération d'une empreinte numérique individuelle pour chacun desdits fichiers ; - la génération d'une empreinte numérique collective pour l'ensemble desdits fichiers à partir de leurs empreintes numériques individuelles ; - le codage de l'empreinte numérique collective à partir de ladite clé privée. Le document est avantageusement conforme au format de la norme ARINC 665 pour une application à l'aéronautique. Le certificat de la clé publique est avantageusement conforme au format de la norme X.509. La requête d'obtention du statut du certificat de la clé publique est typiquement transmise à un serveur OCSP. L'invention concerne également une méthode de vérification de la validité d'un document 30 électronique authentifié par la méthode 20 25 d'authentification exposée ci-dessus, ladite méthode de vérification comprenant : - une étape de vérification de la signature numérique dudit document électronique ; - une étape de vérification du jeton d'horodatage signé par l'autorité d'horodatage ; - une étape de vérification du statut du certificat de la clé publique ; - une étape de détermination de la validité du document électronique, le document étant déclaré valide si les vérifications précédentes sont positives. Lorsque le document comprend plusieurs fichiers, les étapes de vérification de ladite signature numérique et dudit jeton d'horodatage utilisent une empreinte numérique collective desdits fichiers, ladite empreinte numérique étant obtenue au moyen d'empreintes numériques individuelles de chacun de ces fichiers. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention fait en référence aux figures jointes parmi lesquelles : La Fig. 1 illustre schématiquement la méthode d'authentification d'un document électronique selon un premier mode de réalisation de l'invention ; La Fig. 2 représente schématiquement une méthode de vérification de l'authenticité d'un document électronique obtenu selon la méthode de la Fig. 1 ; La Fig. 3 représente schématiquement un exemple d'application de la méthode d'authentification selon l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'invention part du principe que si un document électronique était considéré comme valide à un instant donné, sa validité ne peut être ultérieurement remise en cause que par l'apport d'une preuve contraire. Autrement dit, il suffira à l'utilisateur du document en question de s'assurer de son authenticité à la date à laquelle il a été signé. La Fig. 1 représente schématiquement la méthode d'authentification selon un mode de réalisation de 15 l'invention. On considérera dans la suite un document électronique à authentifier 100. Ce document peut comprendre un fichier de programme et/ou de données ou bien d'une pluralité de tels fichiers. On se placera 20 tout d'abord dans le cas où le document ne comprend qu'un seul fichier. On suppose que le fournisseur du document dispose d'un programme de chiffrement asymétrique, d'une bi-clé constituée d'une clé privée 107 de la clé publique 25 correspondante et d'un certificat électronique 147 attestant que ladite clé publique appartient bien au fournisseur. Le certificat aura été émis par un tiers de confiance, par exemple une autorité de certification. Ce certificat sera avantageusement 30 conforme au format X.509, standard de cryptographie de l'Union internationale des télécommunications pour les infrastructures à clés publiques (PKI). Dans une première étape 110, le fournisseur signe le document électronique à l'aide de sa clé privée 107. Plus précisément, une empreinte numérique de ce document, typiquement obtenue par une fonction de hachage, est codée au moyen de ladite clé privée. Le résultat est une signature numérique 117. Si le document électronique est au format XML, la signature du document sera avantageusement produite selon le format XMLDsig, tel que recommandé par le W3C (World Wide Web Consortium). On procède ensuite à un horodatage du document 100. Pour ce faire, on transmet une requête d'horodatage à une autorité d'horodatage de confiance TSA (trusted Time Stamping Authority). Cette requête a pour argument l'empreinte numérique de la signature 117 et éventuellement du document 100 lui-même. On pourra à cette fin utiliser la même fonction de hachage. Le serveur 125 d'horodatage crée, à partir de l'empreinte numérique qui lui a été transmise, un jeton d'horodatage (timestamp) signé, de manière connue en soi. Plus précisément, le serveur d'horodatage génère un jeton d'horodatage indiquant l'instant de génération du jeton par exemple sous la forme (date, heure, minute), concatène ce dernier à l'empreinte numérique qui lui a été transmise et produit une empreinte numérique de l'ensemble concaténé. Cette dernière empreinte est ensuite encodée au moyen de la clé privée de l'autorité d'horodatage pour obtenir une signature du jeton. Le serveur 125 retourne en 128 le jeton d'horodatage portant la signature ainsi obtenue. Le format du jeton d'horodatage a été normalisé par le standard RFC 3161 de l'IETF. A l'étape 130, faisant suite à l'étape 120 (c'est- à-dire intervenant en règle générale au plus quelques secondes ou quelques minutes après cette dernière), on procède à la vérification de la validité de la clé publique. Pour ce faire, une requête en vérification 136 est transmise via Internet à un serveur OCSP (Online Certificate Status Protocol) encore appelé répondeur OCSP. Cette requête contient, entre autres, le numéro de série du certificat, et le nom de l'autorité de certification. Le format de cette requête est normalisé par le standard RFC 2560 de l'IETF. Le serveur OCSP vérifie le statut du certificat dans la base de données de l'autorité de certification (ou des bases de données des autorités de certification en cas de chaînage de certificats). Le serveur OCSP retourne une réponse signée ou statut, 137, indiquant que le certificat est valide puisque le certificat n'est ni expiré ni révoqué. Le format de cette réponse est également normalisé par le standard RFC 2560 de l'IETF. En 140, un document authentifié est créé à partir du document initial 100 auquel sont adjoints la signature numérique du document par le fournisseur, 117, le jeton d'horodatage signé par l'autorité d'horodatage, 127, le statut du certificat (ou de la chaîne de certificats) de la clé publique, signé par le répondeur OCSP, 137, ainsi que le certificat lui-même émis par l'autorité de certification, 147. Lorsque le document 100 est multi-fichier, l'authentification peut bien entendu être effectuée au niveau de chaque fichier comme précédemment. Chaque fichier est alors considéré simplement comme un document électronique en soi. Selon un second mode de réalisation de l'invention, on génère avantageusement une empreinte numérique individuelle pour chaque fichier du document, puis une empreinte numérique collective de l'ensemble des fichiers à partir de ces empreintes individuelles. La signature du document est obtenue par codage de l'empreinte collective au moyen de la clé privée du fournisseur. L'horodatage est également commun aux dits fichiers. Pour ce faire, l'empreinte collective desdits fichiers est transmise comme argument de la requête 126. Les étapes 130 et 140 sont identiques à celles du premier mode de réalisation. La Fig. 2 illustre schématiquement une méthode de vérification de l'authenticité d'un document obtenu par la méthode d'authentification selon l'invention. On considère d'abord le cas où le document électronique authentifié comprend un seul fichier. Dans une première étape 210, l'utilisateur vérifie grâce à la signature numérique et la clé publique contenue dans le certificat, si cette signature correspond bien à l'empreinte numérique du document, autrement dit si le document en question a bien été signé par le fournisseur du fichier. Dans une seconde étape 220, l'utilisateur vérifie grâce au jeton d'horodatage signé que l'instant indiqué sur le jeton a bien été apposé sur le document en question. Plus précisément, il vérifie, grâce à la clé publique de l'autorité d'horodatage, si la signature électronique portée sur le jeton par cette autorité correspond bien à l'empreinte numérique du document, concaténée avec le jeton d'horodatage. Dans une troisième étape 230, l'utilisateur vérifie, à partir du statut 137, que le certificat de la clé publique du fournisseur, 147, était bien valide au moment où le document a été horodaté. Plus précisément, il vérifie que le temps porté sur le jeton d'horodatage 127 est antérieur à celui porté sur le certificat de statut 137 et que ce dernier indique bien que le certificat de la clé publique était valide. On notera que l'ordre des étapes 210, 220, 230 est sans importance puisqu'elles sont indépendantes l'une de l'autre. A l'étape 240, on conclut à la validité du document si les trois étapes de vérification 210, 220 et 230 sont positives. En effet, dans ce cas, l'intégrité et l'origine du document sont certaines à la date fournie par le jeton d'horodatage. L'utilisateur en déduit, conformément au principe énoncé en introduction, que si le document était valide à cette date, et en absence de preuve contraire, le document est toujours valide. En revanche, si l'une des vérifications est négative, la validité du document est infirmée. Si le document authentifié est multi-fichier, l'étape 210 de vérification de la signature numérique du document ainsi que l'étape 220 de vérification de l'instant d'horodatage utilisent comme empreinte numérique l'empreinte collective des fichiers. La Fig. 3 illustre un exemple d'application de la méthode d'authentification selon l'invention à un document électronique destiné à être embarqué à bord d'un aéronef. Le document en question représenté en 300 obéit au format ARINC 665 et comprend un fichier d'en- tête 301, une pluralité de fichiers de données 3021r 3022r...302N, et un fichier de support 303. Le document authentifié 300' se présente sous la forme d'un fichier d'en-tête sécurisé 301' suivi des mêmes fichiers de données et du fichier de support. En d'autres termes, le document authentifié 300' ne diffère du document original 300 que par le contenu de son fichier d'en-tête. Le fichier d'en-tête 301' du document authentifié comprend un premier segment 311 dont le contenu est identique à celui du fichier d'en-tête 301. Un second segment 312 du fichier d'en-tête contient la signature numérique du document. Plus précisément, ce segment contient tout d'abord les empreintes électroniques des différents fichiers ou bien de blocs de données constitutifs de ces fichiers. Ces empreintes électroniques sont obtenues au moyen d'une ou des fonction(s) de hachage prédéterminée(s) et sont suivies par la signature numérique à proprement parler. Cette dernière est obtenue en codant avec la clé privée du fournisseur une empreinte numérique collective des empreintes individuelles concaténées. Les segments suivants, notés 313 à 315, du fichier d'en-tête contiennent respectivement le jeton d'horodatage signé, le statut du certificat de la clé publique du fournisseur ainsi que le certificat lui- même. L'en-tête 301' du document 300' permet de s'assurer de la validité de ce document, notamment lors d'une opération de téléchargement à bord d'un aéronef. REVENDICATIONS 1. Méthode d'authentification d'un document électronique (100), en particulier d'un fichier destiné à être embarqué à bord d'un aéronef, caractérisée en ce qu'elle comprend : - la génération (110) d'une signature numérique dudit document électronique à l'aide d'une clé privée (107) correspondant à une clé publique certifiée par une autorité de certification ; une requête d'horodatage (126) dudit document électronique auprès d'une autorité d'horodatage (125) pour obtenir un jeton d'horodatage (127) signé par cette autorité ; - une requête d'obtention (136) du statut du certificat de ladite clé publique (137), faisant suite à ladite requête d'horodatage ; - l'adjonction (140) au dit document électronique de la signature numérique, du jeton d'horodatage et du statut dudit certificat pour créer un document électronique authentifié (150). 2. Méthode d'authentification selon la revendication 1, caractérisée en ce que le document comprend un fichier et que la signature du document est obtenue en codant une empreinte numérique dudit fichier avec ladite clé privée. 3. Méthode d'authentification selon la revendication 1, caractérisé en ce que le document estde type XML et que la signature du document est fournie au format XMLDsig. 4. Méthode d'authentification selon la revendication 1, caractérisée en ce que ledit document comprend une pluralité de fichiers et que la signature numérique du document est obtenue par : - la génération d'une empreinte numérique individuelle pour chacun desdits fichiers ; - la génération d'une empreinte numérique collective pour l'ensemble desdits fichiers à partir de leurs empreintes numériques individuelles ; - le codage de l'empreinte numérique collective à partir de ladite clé privée. 5. Méthode d'authentification selon la revendication 3, caractérisée en ce que le document est conforme au format de la norme ARINC 665. 6. Méthode d'authentification selon l'une des revendications précédentes, caractérisée en ce que ledit certificat de la clé publique est conforme au format de la norme X.509. 7. Méthode d'authentification selon la revendication 6, caractérisée en ce que la requête d'obtention du statut du certificat de la clé publique est transmise à un serveur OCSP. 8. Méthode de vérification de la validité d'un document électronique authentifié par une méthoded'authentification selon l'une des revendications précédentes, caractérisée en ce qu'elle comprend : - une étape de vérification (210) de la signature numérique dudit document électronique ; - une étape de vérification (220) du jeton d'horodatage signé par l'autorité d'horodatage ; - une étape de vérification (230) du statut du certificat de la clé publique ; - une étape de détermination (240) de la validité du document électronique, le document étant déclaré valide si les vérifications précédentes sont positives. 9. Méthode de vérification selon la revendication 8, caractérisée en ce que, le document comprenant plusieurs fichiers, les étapes de vérification de ladite signature numérique et dudit jeton d'horodatage utilisent une empreinte numérique collective desdits fichiers, ladite empreinte numérique étant obtenue au moyen d'empreintes numériques individuelles de chacun de ces fichiers.