Procédé et dispositif électronique de téléchargement d’un fichier de données vers un équipement avionique, programme d’ordinateur associé Ce procédé de téléchargement d’un fichier de données (22) vers un équipement avionique (15) est mis en œuvre par un dispositif électronique (20), et comprend : - téléchargement du fichier de données (22) comportant au moins un bloc de données (58) et d’un fichier de configuration (32) contenant au moins un premier haché (64) et une signature cryptographique (36) ; chaque premier haché (64) ayant été obtenu par hachage d’un bloc (58) respectif ; la signature cryptographique (36) ayant été obtenue par chiffrement avec une clé de chiffrement (66) à partir du fichier de configuration (32) à l’exception de la signature (36) elle-même ; et - vérification de la signature cryptographique (36) ; et - si la signature (36) est correcte, contrôle du fichier de données (22) pour au moins un bloc (58) et en fonction du premier haché (64) respectif inclus dans le fichier de configuration (32). Figure pour l'abrégé : Figure 1 Procédé et dispositif électronique de téléchargement d’un fichier de données vers un équipement avionique, programme d’ordinateur associé La présente invention concerne un procédé de téléchargement d’un fichier de données vers un équipement avionique destiné à être embarqué à bord d’un aéronef, le procédé étant mis en œuvre par un dispositif électronique de téléchargement. Le fichier de données comporte au moins un bloc de données, et un fichier de configuration est associé au fichier de données. L’invention concerne aussi un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un tel procédé de téléchargement. L’invention concerne également un tel dispositif électronique de téléchargement d’un fichier de données vers un équipement avionique destiné à être embarqué à bord d’un aéronef. L’invention concerne le domaine du téléchargement de fichiers de données, notamment de bases de données, vers un équipement avionique embarqué à bord d’un aéronef, ledit équipement avionique étant par exemple inclus dans une plateforme aéronautique embarquée. L’invention concerne également le domaine de la cyber-sécurité, car il est nécessaire que le ou les fichiers de données, tels que les bases de données, utilisés par l’équipement avionique, ou plus généralement par un logiciel de la plateforme aéronautique, soient authentiques et intègres. Actuellement, le téléchargement de fichiers de données conformes à la norme ARINC 665 vers un équipement avionique est généralement effectué selon un protocole de communication conforme à la norme ARINC 615A, et le ou les fichiers de données à télécharger sont typiquement encapsulés dans un conteneur également appelé LSP (de l’anglais Loadable Software Part ). Ce conteneur comporte alors un fichier d’en-tête, également noté HF (de l’anglais Header File ), un ou plusieurs fichiers de données, également noté DF (de l’anglais Data File ), et un ou plusieurs fichiers de configuration, également appelés fichiers de support et notés SF (de l’anglais Support File ). Le fichier d’en-tête contient typiquement des informations relatives au format du conteneur, une liste de cibles, une liste des fichiers de données, une liste des fichiers de configuration, des données relatives à l’utilisateur, une information de contrôle de redondance cyclique ou CRC (de l’anglais Cycli c R ed u ndancy Check ) pour le fichier d’en-tête HF, et également une information CRC pour le conteneur. Le fichier d’en-tête HF a par exemple une extension en .luh. Les fichiers de données contiennent les données utiles, et ont par exemple une extension en .lup. Enfin, les fichiers de configuration contiennent par exemple une adresse indiquant un répertoire de destination vers lequel le téléchargement doit être effectué, et ces fichiers de configuration ont typiquement une extension en .ldr. Par ailleurs, la norme ARINC 835 requiert la vérification de l’authenticité d’un conteneur, tel qu’un LSP, avant son téléchargement. Toutefois, cela présuppose que l’opérateur effectuant le téléchargement est bienveillant et qu’il va se conformer à la norme ARINC 835 en acceptant le téléchargement que si le conteneur est authentique et intègre, ce qui n’est pas une hypothèse appropriée en matière de cyber-sécurité. Le but de l’invention est alors de proposer un procédé et un dispositif électronique de téléchargement d’un fichier de données vers un équipement avionique, offrant davantage de sûreté en matière de cyber-sécurité, en permettant de vérifier l’authenticité et l’intégrité du fichier de données lors de son téléchargement, notamment dans le cas d’une base de données compatible avec la norme ARINC 665. A cet effet, l’invention a pour objet un procédé de téléchargement d’un fichier de données vers un équipement avionique destiné à être embarqué à bord d’un aéronef, le fichier de données comportant au moins un bloc de données, un fichier de configuration étant associé au fichier de données ; le procédé étant mis en œuvre par un dispositif électronique de téléchargement et comprenant les étapes suivantes : - téléchargement du fichier de données et du fichier de configuration, le fichier de configuration contenant au moins un premier haché et une signature cryptographique ; chaque premier haché ayant été obtenu, préalablement à l’étape de téléchargement, par application d’un algorithme de hachage à un bloc respectif ; la signature cryptographique ayant été obtenue, préalablement à l’étape de téléchargement, par application d’un algorithme de chiffrement avec une clé de chiffrement à partir du fichier de configuration à l’exception de la signature elle-même ; - vérification de la signature cryptographique incluse dans le fichier de configuration téléchargé, via l’algorithme de chiffrement et une clé de vérification ; et - si la signature est correcte, contrôle du fichier de données téléchargé ; l’étape de contrôle étant effectuée pour au moins un bloc inclus dans ledit fichier de données et en fonction du premier haché respectif inclus dans le fichier de configuration téléchargé. Ainsi, le procédé de téléchargement selon l’invention permet de vérifier l’authenticité du fichier de données via la vérification de la signature cryptographique incluse dans le fichier de configuration associé audit fichier de données, ainsi que l’intégrité du contenu du fichier de données via le contrôle de celui-ci en fonction de premier(s) haché(s) inclus dans le fichier de configuration téléchargé. En complément facultatif, le fichier de configuration téléchargé contient en outre une adresse d’un répertoire de destination vers lequel le téléchargement est effectué, et la vérification de la signature cryptographique est alors effectuée automatiquement en fonction de ladite adresse, en particulier si le répertoire de destination est inclus dans une zone réservée prédéfinie, et que l’adresse contenue dans le fichier de configuration correspond alors à une adresse de cette zone réservée. En complément facultatif encore, le téléchargement est de préférence effectué selon un protocole de communication conforme à la norme ARINC 615A, et le fichier de données ainsi que le fichier de configuration sont alors conformes à ladite norme ARINC 665. En particulier, le fichier de configuration est alors également appelé fichier de support, et a typiquement une extension en .ldr. Le fichier de configuration contient alors, outre l’adresse du répertoire de destination, un premier haché pour chaque bloc respectif de données, ainsi que la signature cryptographique. L’homme du métier observera à cet égard que la norme ARINC 665 n’interdit pas l’ajout d’informations complémentaires dans chaque fichier de configuration. Suivant d’autres aspects avantageux de l’invention, le procédé de téléchargement comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - l’étape de contrôle comporte pour chaque bloc inclus dans ledit fichier de données : + calcul d’un deuxième haché par application de l’algorithme de hachage audit bloc respectif du fichier de données téléchargé ; + comparaison du deuxième haché calculé avec le premier haché respectif inclus dans le fichier de configuration téléchargé ; et + acceptation du bloc respectif du fichier de données téléchargé si le deuxième haché est égal au premier haché ; et rejet dudit bloc respectif sinon ; - le procédé comprend en outre, préalablement à l’étape de téléchargement, une étape de détermination d’un répertoire de destination, le répertoire de destination étant inclus dans l’équipement avionique et déterminé en fonction d’une adresse contenue dans le fichier de configuration ; et lors de l’étape de téléchargement, le fichier de données est téléchargé vers le répertoire de destination ; - l’étape de vérification, et le cas échéant l’étape de contrôle, sont effectuées seulement si le répertoire de destination est inclus dans une zone réservée prédéfinie ; - l’étape de téléchargement est effectuée selon un protocole de communication conforme à la norme ARINC 615A ; le fichier de données et le fichier de configuration étant chacun conforme à la norme ARINC 665 ; - l’algorithme de chiffrement est un algorithme de chiffrement asymétrique, la clé de vérification étant publique, et la clé de chiffrement étant privée ; l’algorithme de chiffrement asymétrique étant de préférence un algorithme RSA, tel que l’algorithme RSA-4096, ou un algorithme ECC ; - l’algorithme de chiffrement est appliqué à un haché additionnel (68) dépendant du fichier de configuration à l’exception de la signature elle-même ; le haché additionnel étant de préférence obtenu par application de l’algorithme de hachage au fichier de configuration à l’exception de la signature elle-même ; - l’algorithme de hachage est un algorithme SHA, tel que l’algorithme SHA-256 ; et - l’étape de téléchargement est effectuée par un module de téléchargement, et l’étape de vérification est effectuée avec l’aide d’un accélérateur cryptographique intégré au module de téléchargement. L’invention a également pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé de téléchargement, tel que défini ci-dessus. L’invention a aussi pour objet un dispositif électronique de téléchargement d’un fichier de données vers un équipement avionique destiné à être embarqué à bord d’un aéronef, le fichier de données comportant au moins un bloc de données, un fichier de configuration étant associé au fichier de données ; le dispositif électronique de téléchargement comprenant : - un module de téléchargement configuré pour télécharger le fichier de données et le fichier de configuration, le fichier de configuration contenant au moins un premier haché et une signature cryptographique ; chaque premier haché ayant été obtenu, préalablement au téléchargement, par application d’un algorithme de hachage à un bloc respectif ; la signature cryptographique ayant été obtenue, préalablement au téléchargement, par application d’un algorithme de chiffrement avec une clé de chiffrement à partir du fichier de configuration à l’exception de la signature elle-même ; - un module de vérification configuré pour vérifier la signature cryptographique incluse dans le fichier de configuration téléchargé, via l’algorithme de chiffrement et une clé de vérification ; et - un module de contrôle configuré, si la signature est correcte, pour contrôler le fichier de données téléchargé ; au moins un bloc inclus dans ledit fichier de données étant contrôlé en fonction du premier haché respectif inclus dans le fichier de configuration téléchargé. Ces caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : la est une représentation schématique d’un aéronef comprenant un équipement avionique et un dispositif électronique de téléchargement d’un fichier de données vers l’équipement avionique ; la est une représentation schématique d’un conteneur conforme à la norme ARINC 665, et comportant un fichier d’en-tête, plusieurs fichiers de données et plusieurs fichiers de configuration, chaque fichier de configuration étant associé à un fichier de données respectif ; et la est un organigramme d’un procédé, selon l’invention, de téléchargement d’un fichier de données vers l’équipement avionique, le procédé étant mis en œuvre par le dispositif électronique de téléchargement de la . Sur la , un aéronef 10 comprend un équipement avionique 15 et un dispositif électronique 20 de téléchargement d’un fichier de données 22 vers l’équipement avionique 15. L’aéronef 10 est par exemple un avion. En variante, l’aéronef 10 est un hélicoptère, ou encore un drone pilotable à distance par un pilote. L’équipement avionique 15 est connu en soi, et est apte à recevoir et à utiliser le fichier de données 22, par exemple de la part d’un serveur informatique, non représenté, ledit serveur étant embarqué à bord de l’aéronef 10, ou en variante externe à l’aéronef 10. L’équipement avionique 15 est typiquement configuré pour utiliser une base de données avioniques, telle qu’une base de données de navigation ou encore une base de données de performances, le fichier de données 22 destiné à être téléchargé est alors typiquement tout ou partie de ladite base de données avioniques. La base de données de navigation, également appelée NAVDB (de l’anglais NAVigation Date Base ) est typiquement une base de données contenant les données aéronautiques, telles que des données aéronautiques communes fournies régulièrement par un fournisseur de bases de données aéronautiques et/ou de données aéronautiques utilisateur contenant par exemple des éléments saisis par l’utilisateur et/ou par une compagnie affrétant l’aéronef 10. Les données aéronautiques contenues dans la base de données de navigation sont alors utilisées pour construire des routes géographiques et/ou des procédures. La base de données de performances, également appelée PERFDB (de l’anglais PERFormance Data Base ) contient des paramètres aérodynamiques et moteurs de l’aéronef 10. L’équipement avionique 15 comporte par exemple une mémoire 24 de stockage de données, ladite mémoire de stockage 24 comportant de préférence deux zones 26, 28 destinées à recevoir des fichiers de données téléchargés, à savoir une zone réservée 26 et une zone non-réservée 28. La zone réservée 26 est typiquement une zone sécurisée, telle qu’une zone chiffrée via un algorithme cryptographique. La zone non-réservée 28 est une zone de libre accès. Le dispositif électronique de téléchargement 20 est configuré pour télécharger au moins un fichier de données 22 vers l’équipement avionique 15, destiné à être embarqué à bord de l’aéronef 10. Dans l’exemple de la , le dispositif électronique de téléchargement 20 est embarqué à bord de l’aéronef 10. En complément, le dispositif électronique de téléchargement 20 est intégré à l’équipement avionique 15. En variante non représentée, le dispositif électronique de téléchargement 20 est externe à l’aéronef 10. Selon cette variante, le dispositif électronique de téléchargement 20 est par exemple intégré dans une passerelle de communication (de l’anglais g ateway ), disposée au sol, et à laquelle l’aéronef 10 est typiquement configuré pour être connecté lorsqu’il est stationné à un emplacement de stationnement dans un aéroport. Le dispositif électronique de téléchargement 20 comprend un module 30 de téléchargement du fichier de données 22 respectif et d’un fichier de configuration 32 associé audit fichier de données 22 ; un module 34 de vérification d’une signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé ; et un module 38 de contrôle du fichier de données 22 téléchargé. En complément facultatif, le dispositif électronique de téléchargement 20 comprend un module 40 de détermination d’un répertoire de destination 42, le répertoire de destination 42 étant inclus dans l’équipement avionique 15 et déterminé en fonction d’une adresse 44 contenue dans le fichier de configuration 32. Dans l’exemple de la , le dispositif électronique de téléchargement 20 comprend une unité de traitement d’informations 50 formée par exemple d’une mémoire 52 et d’un processeur 54 associé à la mémoire 52. Dans l’exemple de la , le module de téléchargement 30, le module de vérification 34, et le module de contrôle 38, ainsi qu’en complément facultatif le module de détermination 40, sont réalisés chacun sous forme d’un logiciel, ou d’une brique logicielle, exécutables par le processeur 54. La mémoire 52 du dispositif électronique de téléchargement 20 est alors apte à stocker un logiciel de téléchargement du fichier de données 22 et du fichier de configuration 32 ; un logiciel de vérification de la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé ; et un logiciel de contrôle, si la signature est correcte, du fichier de données 22 téléchargé. En complément facultatif, la mémoire 52 du dispositif électronique de téléchargement 20 est apte à stocker un logiciel de détermination du répertoire de destination 42 en fonction de l’adresse 44 contenue dans le fichier de configuration 32 téléchargé. Le processeur 54 est alors apte à exécuter chacun des logiciels parmi le logiciel de téléchargement, le logiciel de vérification et le logiciel de contrôle, ainsi qu’en complément facultatif le logiciel de détermination. En variante non représentée, le module de téléchargement 30, le module de vérification 34 et le module de contrôle 38, ainsi qu’en complément facultatif le module de détermination 40, sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglais Field Programmable Gate Array ), ou encore sous forme d’un circuit intégré, tel qu’un ASIC (de l’anglais Application Specific Integrated Circuit ). Lorsque le dispositif électronique de téléchargement 20 est réalisé sous forme d’un ou plusieurs logiciels, c’est-à-dire sous forme d’un programme d’ordinateur, également appelé produit programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple un medium apte à mémoriser des instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non-volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique. Sur le support lisible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles. Le fichier de données 22 comporte au moins un bloc de données 58. Dans l’exemple de la , le fichier de données 22 comporte plusieurs blocs de données 58. Le fichier de données 22 est par exemple noté DF i , où i est un indice entier compris entre 1 et N lorsque le fichier de données 22 est inclus dans un conteneur 60, comme représenté sur la . Chaque bloc de données 58 est alors par exemple noté B i , j , où i est l’indice associé au fichier de données 22 correspondant, et j est un indice entier compris entre 1 et P et identifiant le bloc 58 respectif au sein du fichier de données 22. Dans l’exemple de la , le nombre de blocs de données 58 inclus dans le fichier de données 22 correspondant est alors égal à P. Le fichier de données 22 est de préférence constitué de P blocs de données 58, où la valeur de P est supérieure ou égale à 1, la valeur de P étant variable d’un fichier de données 22 à l’autre. Dans l’exemple de la , chaque fichier de données 22 apte à être téléchargé est lui-même contenu dans le conteneur 60, également appelé LSP (de l’anglais Loadable Software Part ). Le conteneur 60 comprend alors typiquement un fichier d’en-tête 62, également noté HF (de l’anglais Header File ) ; N fichier(s) de données 22, également noté(s) DF 1 à DF N (de l’anglais Data File ), c’est-à-dire DF i où i est l’indice entier associé à chaque fichier de données 22 ou de configuration 32, et compris entre 1 et N ; et N fichier(s) de configuration 32, également noté(s) SF 1 à SF N (de l’anglais Support File ), c’est-à-dire SF i avec i compris entre 1 et N. Le conteneur 60 est de préférence constitué du fichier d’en-tête 62, de N fichier(s) de données 22, et de N fichier(s) de configuration 32, chaque fichier de configuration 32 étant associé à un fichier de données 22 respectif. En complément facultatif, le conteneur 60 est conforme à la norme ARINC 665. Selon ce complément facultatif, le fichier d’en-tête 62 a alors une extension en .luh, chaque fichier de données 22 a une extension en .lup, et chaque fichier de configuration 32, également appelé fichier de support, a une extension en .ldr. Le module de téléchargement 30 est configuré pour télécharger le fichier de données 22 et le fichier de configuration 32 associé. Lorsque plusieurs fichiers de données 22 sont destinés à être téléchargés, le module de téléchargement 30 est alors configuré pour télécharger chaque fichier de données 22 et chaque fichier de configuration 32 associé à un fichier de données 22 respectif. Le module de téléchargement 30 est par exemple configuré pour télécharger le conteneur 60. Le module de téléchargement 30 est configuré pour télécharger le ou les fichiers de données 22 et le ou les fichiers de configuration 32 à destination de la mémoire de stockage 24, et par exemple de la zone réservée 26 ou bien de la zone non-réservée 28. En complément facultatif, lorsque le fichier de configuration 32 respectif contient l’adresse 44, et que le module de détermination 40 détermine alors le répertoire de destination 42 associé à ladite adresse 44, le module de téléchargement 30 est alors configuré pour télécharger le fichier de données 22 à destination dudit répertoire de destination 42. Le module de téléchargement 30 est par exemple configuré pour, dans un premier temps, télécharger le ou les fichiers de données 22 et le ou les fichiers de configuration 32 dans une mémoire tampon (de l’anglais buffer ), non représentée, ceci pour effectuer la vérification de la signature cryptographique 36, puis le cas échéant le contrôle du fichier de données 22 ; et dans un deuxième temps si la signature est correcte, et si le contrôle subséquent du fichier de données 22 est également correct, télécharger alors le fichier de données 22 contrôlé dans la mémoire de stockage 24, par exemple dans la zone réservée 26 ou bien dans la zone non-réservée 28, et le cas échéant dans le répertoire de destination 42. En variante, le module de téléchargement 30 est configuré pour télécharger le ou les fichiers de données 22 et le ou les fichiers de configuration 32 directement dans la mémoire de stockage 24, et configuré ensuite pour supprimer chaque fichier de données 22 de la mémoire 24 pour lequel la signature cryptographique 36 est anormal, ou encore pour lequel le contrôle effectué par le module de contrôle 38 est anormal. En complément facultatif encore, le module de téléchargement 30 est configuré pour effectuer le téléchargement selon un protocole de communication conforme à la norme ARINC 615A, chaque fichier de données 22 et chaque fichier de configuration 32 étant alors conforme à ladite norme ARINC 665. Le fichier de configuration 32, également appelé fichier de support, est associé au fichier de données 22. Lorsque plusieurs fichiers de données 22 sont destinés à être téléchargés par le dispositif électronique de téléchargement 20, comme dans l’exemple de la , alors plusieurs fichiers de configuration 32 sont également prévus, et par exemple inclus dans le conteneur 60, et chaque fichier de configuration 32 est associé à un fichier de données 22 respectif. Autrement dit, chaque fichier de configuration 32 correspond à un unique fichier de données 22. Selon l’invention, le fichier de configuration 32 contient au moins un premier haché 64 et la signature cryptographique 36, chaque premier haché 64 étant associé à un bloc de données 58 respectif. Chaque premier haché 64 a été obtenu, préalablement au téléchargement, par application d’un algorithme de hachage à un bloc de données 58 respectif. La signature cryptographique 36 a été obtenue, préalablement au téléchargement, par application d’un algorithme de chiffrement avec une clé de chiffrement 66 à partir du fichier de configuration 32 à l’exception de la signature 36 elle-même. L’algorithme de chiffrement est par exemple un algorithme de chiffrement asymétrique, avec une clé de vérification publique, non représentée, la clé de chiffrement 66 étant privée. De préférence, pour l’obtention de la signature cryptographique 36, l’algorithme de chiffrement est appliqué à un haché additionnel 68 dépendant du fichier de configuration 32 à l’exception de la signature 36 elle-même. Le haché additionnel 68 est typiquement obtenu par application de l’algorithme de hachage au fichier de configuration 32 à l’exception de la signature 36 elle-même, comme représenté sur la . L’algorithme de hachage est par exemple un algorithme de type SHA (de l’anglais Secure Hash Algorithm ), tel que l’un des algorithmes SHA-256, SHA-384, SHA-512, SHA-512/256 et SHA-512/224, ou l’algorithme SHA-3. L’algorithme de chiffrement asymétrique est par exemple un algorithme de type RSA (de l’anglais Rivest Shamir Adleman ), tel que l’algorithme RSA-4096, ou encore un algorithme de type ECC (de l’anglais Elliptic Curve Cryptography ), tel qu’un algorithme à logarithme discret sur une courbe elliptique définie sur un groupe cyclique. Le fichier de configuration 32 comprend alors typiquement l’adresse 44 du répertoire de destination, le ou les premiers hachés 64 et la signature cryptographique 36. Chaque fichier de configuration 32 est de préférence constitué de ladite adresse 44, du ou des premiers hachés 64 et de la signature 36, le nombre de premier(s) haché(s) 64 étant égal au nombre de bloc(s) de données 58 contenus dans le fichier de données 22 associé. Dans l’exemple des figures 1 et 2, chaque fichier de configuration 32 contient alors l’adresse 44, également notée Dest i , où i est l’indice entier décrit précédemment et compris entre 1 et N ; P premier(s) haché(s) 64, également noté(s) H i,j , où j est l’indice entier décrit précédemment et compris entre 1 et P ; et la signature cryptographique 36, également notée Sgn i . Le module de vérification 34 est configuré pour vérifier, via l’algorithme de chiffrement et la clé de vérification, la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé. La clé de vérification est typiquement publique et associée, c’est-à-dire couplée, à la clé de chiffrement 66 qui est typiquement privée. La clé de vérification publique est alors mise à disposition par le détenteur de la clé de chiffrement 66 privée. Le module de vérification 34 est par exemple configuré pour appliquer l’algorithme de hachage au contenu du fichier de configuration 32 téléchargé excepté la signature 36 elle-même ; puis pour comparer le haché ainsi obtenu avec le résultat de l’application de l’algorithme de chiffrement avec la clé de vérification publique à la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé, c’est-à-dire pour comparer le haché ainsi obtenu avec à la signature cryptographique 36 déchiffrée avec la clé de vérification publique. Selon cet exemple, si le haché ainsi obtenu est identique à la signature cryptographique 36 déchiffrée, alors la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé est authentifiée, i. e. la signature cryptographique 36 est considérée comme correcte. Sinon, la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé est considérée comme anormale, et elle n’est alors pas authentifiée, entrainant le rejet du téléchargement du fichier de données 22. En complément facultatif, le module de vérification 34 utilise un accélérateur cryptographique intégré au module de téléchargement 30. Le module de vérification 34 permet alors de vérifier l’authenticité de la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé. Le module de contrôle 38 est configuré pour, si la signature cryptographique 36 est correcte suite à la vérification effectuée par le module de vérification 34, contrôler le fichier de données 22 téléchargé. Autrement dit, le module de contrôle 38 est configuré pour contrôler le fichier de données 22 téléchargé, seulement si la signature cryptographique 36 est authentique. Le module de contrôle 38 est configuré pour contrôler au moins un bloc de données 58 inclus dans ledit fichier de données 22 en fonction du premier haché 64 respectif inclus dans le fichier de configuration 32 téléchargé et associé audit fichier de données 22. De préférence, le module de contrôle 38 est, pour chaque bloc de données 58 inclus dans ledit fichier de données 22, configuré pour calculer un deuxième haché, non représenté, par application de l’algorithme de hachage audit bloc 58 respectif du fichier de données téléchargé ; puis pour comparer le deuxième haché calculé avec le premier haché 64 respectif inclus dans le fichier de configuration téléchargé ; et enfin pour accepter le bloc 58 respectif du fichier de données 22 téléchargé si le deuxième haché est égal au premier haché 64, et rejeter ledit bloc 58 respectif sinon, c’est-à-dire si le deuxième haché est distinct du premier haché 64. En complément facultatif, le module de détermination 40 est configuré pour déterminer le répertoire de destination 42 en fonction de l’adresse 44 contenue dans le fichier de configuration 32, le répertoire de destination 42 étant inclus dans l’équipement avionique 15, comme décrit précédemment. Selon un aspect complémentaire de ce complément facultatif, le module de vérification 34 est configuré pour vérifier la signature cryptographique 36 seulement si le répertoire de destination 42, déterminé par le module de détermination 40, est inclus dans la zone réservée 26 prédéfinie. Selon cet aspect complémentaire, le module de contrôle 38 est également configuré pour contrôler le fichier de données 22 téléchargé seulement si le répertoire de destination 42 est inclus dans la zone réservée 26 prédéfinie, puisque ledit contrôle est effectué seulement si la signature cryptographique 36 est correcte, c’est-à-dire si le résultat de la vérification effectuée par le module de vérification 34 est positif, et que cette vérification est effectuée seulement si le répertoire de destination 42 est inclus dans la zone réservée 26. Chaque bloc de données 58 respectif a par exemple une taille comprise entre 1 mégaoctet, également noté Mo, et 128 mégaoctets. Une telle plage de valeurs pour la taille de chaque bloc 58 respectif offre alors un bon compromis entre rapidité de hachage, puis de téléchargement, et granularité. Chaque base de données avionique, telle que la base de données de navigation, ou encore la base de données de performance, comprend alors typiquement de l’ordre de cent à mille blocs de données 58. En variante, non représentée, chaque fichier de données 22 comporte un unique bloc de données 58. La valeur de P est alors égale à 1 pour chaque fichier de données 22. Selon cette variante, chaque premier haché 64 est obtenu par application de l’algorithme de hachage au fichier de données 22 respectif. Selon cette variante, le module de contrôle 38 est, pour chaque fichier de données 22, configuré pour calculer un deuxième haché, non représenté, par application de l’algorithme de hachage audit fichier de données 22 téléchargé ; puis pour comparer le deuxième haché calculé avec le premier haché 64 respectif inclus dans le fichier de configuration téléchargé ; et enfin pour accepter le fichier de données 22 téléchargé si le deuxième haché est égal au premier haché 64, et rejeter ledit fichier de données 22 respectif sinon, c’est-à-dire si le deuxième haché est distinct du premier haché 64. Selon cette variante, et en complément facultatif, l’algorithme de chiffrement est appliqué en outre à chaque premier haché 64 pour obtenir une signature cryptographique respective, non représentée. Autrement dit, selon cette variante, à chaque fichier de données 22 est également associée une signature cryptographique respective. Selon ce complément facultatif, le module de contrôle 38 est, pour chaque fichier de données 22, configuré pour déchiffrer, via l’algorithme de chiffrement et la clé de vérification, la signature cryptographique associée, afin d’obtenir le premier haché 64 respectif, et ensuite comme décrit précédemment, pour calculer le deuxième haché par application de l’algorithme de hachage audit fichier de données 22 téléchargé ; puis pour comparer le deuxième haché calculé avec le premier haché 64 respectif préalablement déchiffré ; et enfin pour accepter le fichier de données 22 téléchargé si le deuxième haché est égal au premier haché 64, et rejeter ledit fichier de données 22 respectif sinon. Selon cette variante, et en complément facultatif encore, le conteneur 60 comporte un unique fichier de configuration 32, également appelé fichier de support, pour l’ensemble des fichiers de données 22 contenus dans ce conteneur 60. L’unique fichier de configuration 32 contient alors une liste des fichiers de données 22 avec pour chacun la valeur de sa signature cryptographique respective. Selon cette variante, et en complément facultatif encore, de manière analogue à ce qui a été décrit précédemment, la signature cryptographique 36 est obtenue par application de l’algorithme de chiffrement avec la clé de chiffrement 66 à partir du fichier de configuration 32 à l’exception de la signature 36 elle-même. De préférence, pour l’obtention de la signature cryptographique 36, l’algorithme de chiffrement est appliqué à un haché additionnel 68 dépendant du fichier de configuration 32 à l’exception de la signature 36 elle-même. Le haché additionnel 68 est typiquement obtenu par application de l’algorithme de hachage au fichier de configuration 32 à l’exception de la signature 36 elle-même. Le fonctionnement du dispositif électronique de téléchargement 20 selon l’invention va être à présent décrit en regard de la représentant un organigramme du procédé, selon l’invention, de téléchargement du fichier de données 22 vers l’équipement avionique 15. Lors d’une étape initiale 100 optionnelle, le dispositif de téléchargement 20 détermine, via son module de détermination 40, le répertoire de destination 42, inclus dans l’équipement avionique 15, ceci en fonction de l’adresse 44 contenue dans le fichier de configuration 32 associé au fichier de données 22 à télécharger. A l’issue de l’étape de détermination 100 optionnelle, le dispositif de téléchargement 20 passe à l’étape suivante 110 lors de laquelle il télécharge, via son module de téléchargement 30, le fichier de données 22 et le fichier de configuration 32 associé audit fichier de données 22, et de manière plus générale chaque fichier de données 22 et chaque fichier de configuration 32. L’étape de téléchargement 110 est de préférence effectuée selon un protocole de communication conforme à la norme ARINC 615A, le fichier de données 22 et le fichier de configuration 32 étant alors chacun conforme à ladite norme ARINC 665. Le téléchargement du fichier de données 22 et le fichier de configuration 32 associé est, lors de l’étape 110, par exemple effectué dans la mémoire tampon, puis est ultérieurement effectué dans la mémoire de stockage 24, par exemple dans la zone réservée 26 ou bien dans la zone non-réservée 28, et le cas échéant dans le répertoire de destination 42, si le téléchargement est accepté à l’issue d’une étape de vérification 120, puis d’une étape de contrôle 130, décrites par la suite. L’homme du métier comprendra alors qu’en revanche si le téléchargement est rejeté, soit à l’issue de l’étape de vérification 120 ou bien à l’issue de l’étape de contrôle 130, alors le fichier de données 22 et le fichier de configuration 32 ne sont finalement pas téléchargés dans la mémoire de stockage 24, et sont en outre effacés de la mémoire tampon. En variante, le téléchargement du fichier de données 22 et du fichier de configuration 32 est, lors de l’étape 110, effectué directement dans la mémoire de stockage 24, par exemple dans la zone réservée 26 ou bien dans la zone non-réservée 28, et le cas échéant dans le répertoire de destination 42. Selon cette variante, si le téléchargement est accepté à l’issue de l’étape de vérification 120 et de l’étape de contrôle 130, alors le fichier de données 120 et le fichier de configuration 130 sont conservés dans la mémoire de stockage 24 ; et sinon, c’est-à-dire si le téléchargement est rejeté à l’issue de l’étape de vérification 120 ou bien à l’issue de l’étape de contrôle 130, alors le fichier de données 22 et le fichier de configuration 32, préalablement téléchargés dans la mémoire de stockage 24 lors de l’étape 110, sont supprimés de la mémoire de stockage 24. Selon l’invention, le fichier de configuration 32 téléchargé contient au moins un premier haché 64 et la signature cryptographique 36, et plus précisément contient un premier haché 64 pour chaque bloc de données 58 respectif du fichier de données 22 téléchargé. Chaque premier haché 64 a été obtenu, préalablement à l’étape de téléchargement 110, par application de l’algorithme de hachage à un bloc 58 respectif, et la signature cryptographique 36 a été obtenue, également préalablement à l’étape de téléchargement 110, par application de l’algorithme de chiffrement avec la clé de chiffrement 66 au fichier de configuration 32 à l’exception de la signature 36 elle-même. A l’issue de l’étape de téléchargement 110, le dispositif de téléchargement 20 passe à l’étape suivante 120 lors de laquelle il vérifie, via son module de vérification 34, la signature cryptographique 36 incluse dans le fichier de configuration 32 téléchargé et associé au fichier de données 22 respectif. L’étape de vérification 120 est effectuée via l’application à ladite signature cryptographique 36 de l’algorithme de chiffrement avec la clé de vérification. La clé de vérification est typiquement publique, et préalablement mise à disposition par le détenteur de la clé de chiffrement 66 privée qui a été utilisée pour l’obtention préalable de la signature cryptographique 36. L’étape de vérification 120 est de préférence effectuée avec l’aide de l’accélérateur cryptographique, typiquement intégré au module de téléchargement 30, et le module de vérification 34 utilise alors ledit accélérateur cryptographique. A l’issue de l’étape de vérification 120, si la signature cryptographique 36 est considérée comme anormale, c’est-à-dire que la signature cryptographique est considérée comme n’étant pas authentique, ou en d’autres termes que le résultat de la vérification de la signature cryptographique 36 est négatif, alors le téléchargement est rejeté et le procédé de téléchargement est interrompu. A l’issue de l’étape de vérification 120, si la signature cryptographique 36 est au contraire considérée comme correcte, c’est-à-dire qu’elle est considérée comme authentique, ou encore que le résultat de la vérification de signature est positif, alors le dispositif de téléchargement 20 passe à l’étape suivante 130 lors de laquelle il contrôle, via son module de contrôle 38 le fichier de données 22 téléchargé. L’étape de contrôle 130 est effectuée pour au moins un bloc 58 inclus dans le fichier de données 22 et en fonction du premier haché 64 respectif inclus dans le fichier de configuration 32 téléchargé. Le contrôle dudit bloc 58 est typiquement effectué en calculant le deuxième haché pour ledit bloc 58, par application de l’algorithme de hachage audit bloc 58 ; puis en comparant ce deuxième haché calculé avec le premier haché 64 correspondant audit bloc 58 et inclus dans le fichier de configuration 32 téléchargé ; et en acceptant alors ledit bloc 58 si le deuxième haché est égal au premier haché, et en le rejetant sinon. De préférence, l’étape de contrôle 130 comporte, pour chaque bloc 58 inclus dans le fichier de données 22 téléchargé, le calcul du deuxième haché respectif par application de l’algorithme de hachage audit bloc 58 respectif du fichier de données 22 téléchargé ; la comparaison du deuxième haché calculé avec le premier haché 64 respectif inclus dans le fichier de configuration 32 téléchargé ; et l’acceptation dudit bloc 58 respectif si le deuxième haché est égal au premier haché 64, et le rejet dudit bloc 58 respectif sinon. A l’issue de l’étape de contrôle 130, si le fichier de données 22 téléchargé est considéré comme correct, c’est-à-dire si le résultat du contrôle effectué lors de l’étape 130 est positif, alors le téléchargement est accepté. Sinon, si le fichier de données 22 téléchargé est considéré comme anormal, c’est-à-dire si le résultat du contrôle effectué lors de l’étape 130 est négatif, alors le téléchargement est rejeté. En complément facultatif, l’étape de vérification 120, et le cas échéant (c’est-à-dire si le résultat de l’étape de vérification 120 est positif) l’étape de contrôle 130, sont effectuées seulement si le répertoire de destination 42 déterminé lors de l’étape de détermination 100 est inclus dans la zone réservée 26 prédéfinie. Ainsi, la signature cryptographique 36 et chaque premier haché 64 intégré dans le fichier de configuration 32 associé au fichier de données 22 permettent de vérifier l’authenticité et l’intégrité dudit fichier de données 22 durant son téléchargement, tout en restant le cas échéant conformes à la norme ARINC 665. Le fichier de données 22, destiné à être téléchargé dans l’équipement avionique 15, et par exemple inclus dans le conteneur 60, également appelé LSP et typiquement conforme à la norme ARINC 665, n’est alors accepté par le dispositif de téléchargement 20 selon l’invention que si la signature cryptographique 36 est reconnue par le module de vérification 34 lors de l’étape de vérification 120, ce qui permet de vérifier l’authenticité du fichier de données 22 ; et en outre si le(s) deuxième(s) haché(s) calculé(s) pour le(s) bloc(s) 58 du fichier de données 22 téléchargé correspond(ent) au(x) premier(s) haché(s) 64 inclus dans le fichier de configuration 32 téléchargé, ce qui permet alors de vérifier l’intégrité de chaque bloc 58. En outre, l’intégrité est vérifiée séparément pour chaque bloc 58, chaque premier haché 64 étant associé à un unique bloc 58 respectif. On conçoit ainsi que le procédé de téléchargement et le dispositif électronique de téléchargement 20 selon l’invention offrent davantage de sûreté en matière de cyber-sécurité, en permettant de vérifier l’authenticité et l’intégrité du fichier de données 22 lors de son téléchargement, notamment dans le cas d’une base de données compatible avec la norme ARINC 665. Procédé de téléchargement d’un fichier de données (22) vers un équipement avionique (15) destiné à être embarqué à bord d’un aéronef (10), le fichier de données (22) comportant au moins un bloc de données (58), un fichier de configuration (32) étant associé au fichier de données (22) ; le procédé étant mis en œuvre par un dispositif électronique de téléchargement (20) et comprenant les étapes suivantes : - téléchargement (110) du fichier de données (22) et du fichier de configuration (32), caractérisé en ce que le fichier de configuration (32) contient au moins un premier haché (64) et une signature cryptographique (36) ; chaque premier haché (64) ayant été obtenu, préalablement à l’étape de téléchargement (110), par application d’un algorithme de hachage à un bloc (58) respectif ; la signature cryptographique (36) ayant été obtenue, préalablement à l’étape de téléchargement (110), par application d’un algorithme de chiffrement avec une clé de chiffrement (66) à partir du fichier de configuration (32) à l’exception de la signature (36) elle-même ; et en ce que le procédé comprend en outre les étapes suivantes : - vérification (120) de la signature cryptographique (36) incluse dans le fichier de configuration (32) téléchargé, via l’algorithme de chiffrement et une clé de vérification ; et - si la signature (36) est correcte, contrôle (130) du fichier de données (22) téléchargé ; l’étape de contrôle (130) étant effectuée pour au moins un bloc (58) inclus dans ledit fichier de données (22) et en fonction du premier haché (64) respectif inclus dans le fichier de configuration (32) téléchargé. Procédé selon la revendication 1, dans lequel l’étape de contrôle (130) comporte pour chaque bloc (58) inclus dans ledit fichier de données (22) : + calcul d’un deuxième haché par application de l’algorithme de hachage audit bloc (58) respectif du fichier de données (22) téléchargé ; + comparaison du deuxième haché calculé avec le premier haché (64) respectif inclus dans le fichier de configuration (32) téléchargé ; et + acceptation du bloc (58) respectif du fichier de données (22) téléchargé si le deuxième haché est égal au premier haché (64) ; et rejet dudit bloc (58) respectif sinon. Procédé selon la revendication 1 ou 2, dans lequel le procédé comprend en outre, préalablement à l’étape de téléchargement (110), une étape (100) de détermination d’un répertoire de destination (42), le répertoire de destination (42) étant inclus dans l’équipement avionique (15) et déterminé en fonction d’une adresse (44) contenue dans le fichier de configuration (32) ; et lors de l’étape de téléchargement (110), le fichier de données (22) est téléchargé vers le répertoire de destination (42). Procédé selon la revendication 3, dans lequel l’étape de vérification (120), et le cas échéant l’étape de contrôle (130), sont effectuées seulement si le répertoire de destination (42) est inclus dans une zone réservée (26) prédéfinie. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape de téléchargement (110) est effectuée selon un protocole de communication conforme à la norme ARINC 615A ; le fichier de données (22) et le fichier de configuration (32) étant chacun conforme à la norme ARINC 665. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’algorithme de chiffrement est un algorithme de chiffrement asymétrique, la clé de vérification étant publique, et la clé de chiffrement (66) étant privée ; l’algorithme de chiffrement asymétrique étant de préférence un algorithme RSA, tel que l’algorithme RSA-4096, ou un algorithme ECC. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’algorithme de chiffrement est appliqué à un haché additionnel (68) dépendant du fichier de configuration (32) à l’exception de la signature (36) elle-même ; le haché additionnel (68) étant de préférence obtenu par application de l’algorithme de hachage au fichier de configuration (32) à l’exception de la signature (36) elle-même. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’algorithme de hachage est un algorithme SHA, tel que l’algorithme SHA-256. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape de téléchargement (110) est effectuée par un module de téléchargement (30), et l’étape de vérification (120) est effectuée avec l’aide d’un accélérateur cryptographique intégré au module de téléchargement (30). Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon la revendication précédente. Dispositif électronique (20) de téléchargement d’un fichier de données (22) vers un équipement avionique (15) destiné à être embarqué à bord d’un aéronef (10), le fichier de données (22) comportant au moins un bloc de données (58), un fichier de configuration (32) étant associé au fichier de données (22) ; le dispositif électronique de téléchargement (20) comprenant : - un module de téléchargement (30) configuré pour télécharger le fichier de données (22) et le fichier de configuration (32), caractérisé en ce que le fichier de configuration (32) contient au moins un premier haché (64) et une signature cryptographique (36) ; chaque premier haché (64) ayant été obtenu, préalablement au téléchargement, par application d’un algorithme de hachage à un bloc (58) respectif ; la signature cryptographique (36) ayant été obtenue, préalablement au téléchargement, par application d’un algorithme de chiffrement avec une clé de chiffrement (66) à partir du fichier de configuration (32) à l’exception de la signature (36) elle-même ; et en ce que le dispositif électronique de téléchargement (20) comprend en outre : - un module de vérification (34) configuré pour vérifier la signature cryptographique (36) incluse dans le fichier de configuration (32) téléchargé, via l’algorithme de chiffrement et une clé de vérification ; et - un module de contrôle (38) configuré, si la signature (36) est correcte, pour contrôler le fichier de données (22) téléchargé ; au moins un bloc (58) inclus dans ledit fichier de données (22) étant contrôlé en fonction du premier haché (64) respectif inclus dans le fichier de configuration (32) téléchargé.