FR 2951562 A1 20110422 FR 0957248 A 20091015 -1- L'invention concerne l'accès au système d'information d'un aéronef. De nos jours, les nouveaux avions intègrent souvent la gestion de leur maintenance, y compris la documentation relative à cette dernière. A cette fin, il existe dans le système d'information de bord des applications qui permettent de consulter les procédures de maintenance, d'anticiper les pannes éventuelles et enfin d'effectuer des opérations de maintenance. Dans le but de soulager l'occupation du poste de pilotage et de faciliter les opérations de maintenance, des connecteurs informatiques sous la forme de prises sont disponibles dans d'autres parties de l'avion pour brancher un ordinateur portable de maintenance et accéder à ces applications. Ces prises sont installées dans des zones de confiance et ne sont donc accessibles qu'à des personnes autorisées. Pour faciliter encore la maintenance, on souhaite maintenant pouvoir disposer, éventuellement à titre optionnel, de prises situées dans des zones accessibles au public, c'est-à-dire aux passagers de l'avion. Mais ces prises représentant autant de points d'entrée pour une éventuelle attaque du système d'information de l'avion, il est souhaitable de protéger leur accès. Un but de l'invention est de protéger l'accès à ces prises pour préserver l'accès restreint au système d'information de l'avion. Une solution qui atteindrait ce but devrait de préférence satisfaire en outre quatre critères. Tout d'abord, il devrait s'agir d'une méthode d'authentification qui ne nécessite pas de mettre à jour une base de comptes dans l'avion ni dans l'ordinateur portable de maintenance. Cette condition est spécifique au monde avionique. En effet, il est très difficile de mettre à jour un avion après chaque vol sans impacter sa disponibilité. Par conséquent, toute solution utilisant une base de données de personnes autorisées à bord est a priori à exclure car elle est inefficace si l'avion n'est pas mis à jour fréquemment. La méthode d'authentification ne doit pas nécessiter de support amovible supplémentaire (clé USB, carte à puce, dongle à mot de passe à usage unique ou token OTP...) car ceux-ci sont très lourds à gérer pour une compagnie disposant d'une flotte d'avions. Cette utilisation entraîne une gestion lourde du cycle de vie du support (initialisation, enregistrement des pertes, ...) qui n'est pas envisageable en pratique dans le contexte de la maintenance d'un avion et, qui plus est, est considéré par les compagnies comme trop coûteuse. La méthode d'authentification doit être compatible avec les contraintes environnementales de maintenance. En effet, elle doit pouvoir être mise en oeuvre 2951562 -2- dans toutes les conditions de maintenance et donc être compatible avec un travail de nuit, des intempéries, un environnement sale, une zone éloignée, etc. Par exemple, le fait que les opérations de maintenance soient salissantes exclut toute solution d'authentification basée sur une empreinte digitale. 5 Enfin, la méthode d'authentification doit pouvoir être qualifiée de «forte », c'est-à-dire pouvoir résister à un attaquant ayant des compétences informatiques très élevées. En effet, le système à protéger est critique. Dans le domaine des systèmes d'authentification, une authentification est dite forte si elle combine deux éléments ou facteurs d'authentification à choisir parmi les suivants : ce que l'entité 10 considérée connait, ce que l'entité détient, ce que l'entité est et ce que l'entité sait faire. A cet effet, on prévoit selon un premier aspect de l'invention un procédé pour accéder à un système d'information d'un aéronef, dans lequel : - le système reçoit d'un connecteur de l'aéronef une demande d'authentifiant ; 15 - le système détermine si le connecteur présente une caractéristique prédéterminée ; et - dans le cas où le système détermine que le connecteur présente la caractéristique prédéterminée, le système envoie un authentifiant au connecteur. Selon un deuxième aspect de l'invention compatible avec le premier aspect, on 20 prévoit un procédé pour accéder à un système d'information d'un aéronef, dans lequel : - le système reçoit un authentifiant ; - le système détermine si l'authentifiant est valable ; et - dans le cas où le système détermine que l'authentifiant est valable, le 25 système autorise un accès au système à partir d'un connecteur de l'aéronef depuis lequel a été envoyé l'authentifiant. La caractéristique prédéterminée pourra être relative au fait que le connecteur se trouve dans une zone d'un type prédéterminé de l'aéronef, notamment une zone associée à un certain niveau de sécurité tel qu'une zone à accès restreint. 30 L'invention tire parti du fait qu'il existe déjà un ensemble de mesures de sécurité autour des avions pour limiter l'accès à certaines zones sensibles. C'est le cas du poste de pilotage ou cockpit qui contient des instruments de mesure et des terminaux pour accéder au système d'information de l'avion. L'accès à ces zones sensibles est limité à une liste de personnes autorisées. 35 L'invention répond aux conditions préférées précitées pour les raisons suivantes. Elle n'impose pas de gestion de base de comptes à bord. En effet, les 2951562 -3- authentifiants peuvent être générés à la demande et il n'est pas nécessaire d'enregistrer des informations sur le personnel autorisé dans le système d'information de bord pour mettre en oeuvre l'invention. Le procédé de l'invention n'impose pas d'utiliser un support amovible puisque 5 l'authentifiant peut être récupéré sur le terminal de maintenance, par exemple lors de sa connexion en zone à accès restreint. Aucun support amovible n'est donc nécessaire pour permettre l'authentification de l'opérateur de maintenance. L'invention permet de mettre en oeuvre le principe consistant à connecter le terminal dans un premier temps depuis une zone à accès restreint avant de s'en 10 servir dans tout autre zone. Elle est donc compatible avec les contraintes du travail des équipes de maintenance. De plus, cette solution est utilisable dans n'importe quelle condition environnementale de travail (salissure, froid, pluie, nuit,...). Enfin, l'invention peut être mise en oeuvre de façon à combiner deux facteurs d'authentification : ce que l'entité sait faire et ce que l'entité détient. En effet, pour 15 s'authentifier, l'opérateur de maintenance doit dans un premier temps accéder à une zone présentant la caractéristique prédéterminée (cela correspond à "ce que je sais faire") pour récupérer l'authentifiant. Et on peut prévoir que l'opérateur doit utiliser ce dernier dans un temps limité ("ce que je détiens"). Cette solution d'authentification peut donc être mise en oeuvre de façon à être "forte". 20 Avantageusement, le système compare l'authentifiant reçu avec un authentifiant enregistré dans le système. Avantageusement, le système déclenche un compteur mesurant un intervalle de temps écoulé depuis un évènement prédéterminé, de préférence une déconnexion dernière en date, à l'égard du système, d'un terminal ayant envoyé 25 l'authentifiant, la validité de l'authentifiant dépendant d'un état du compteur. De préférence, le système supprime le compteur lorsque l'intervalle dépasse une valeur prédéterminée. Avantageusement, le système enregistre l'authentifiant. De préférence, le système supprime l'authentifiant lorsque survient un 30 évènement prédéterminé, par exemple si l'intervalle dépasse une valeur prédéterminée. Avantageusement, les étapes de réception, de détermination et d'autorisation forment une série d'étapes exécutée plusieurs fois. On prévoit également, selon un troisième aspect de l'invention, un aéronef qui 35 comprend un système d'information apte : - lorsqu'il reçoit d'un connecteur de l'aéronef une demande d'authentifiant, à déterminer si le connecteur présente une caractéristique prédéterminée ; et 2951562 -4- - dans le cas où le système détermine que le connecteur présente la caractéristique prédéterminée, à envoyer un authentifiant au connecteur. On prévoit aussi, selon un quatrième aspect de l'invention compatible avec le troisième, un aéronef qui comprend un système d'information apte : 5 - lorsqu'il reçoit un authentifiant, à déterminer si l'authentifiant est valable ; et - dans le cas où le système détermine que l'authentifiant est valable, à autoriser un accès au système à partir d'un connecteur de l'aéronef depuis lequel a été envoyé l'authentifiant. On prévoit, par ailleurs, selon l'invention un procédé pour accéder à un 10 système d'information d'un aéronef, dans lequel : - un terminal envoie une demande d'authentifiant au système à partir d'une zone de l'aéronef d'un type prédéterminé ; - le terminal reçoit et enregistre l'authentifiant ; - on déconnecte le terminal du système ; et 15 - le terminal, à nouveau connecté au système, adresse l'authentifiant au système. Avantageusement, avant d'envoyer la demande, le terminal détermine si un authentifiant est enregistré dans le terminal. De préférence, l'envoi de la demande est initié par des moyens automatisés. 20 Avantageusement, l'envoi de l'authentifiant est initié par des moyens automatisés De préférence, le terminal déclenche un compteur mesurant un intervalle de temps écoulé depuis un événement prédéterminé, de préférence une déconnexion dernière en date du terminal à I 'égard du système, la validité de l'authentifiant 25 dépendant d'un état du compteur. Avantageusement, le terminal supprime l'authentifiant lorsque survient un évènement prédéterminé On prévoit également selon l'invention un terminal pour accéder à un système d'information d'un aéronef, qui comprend des moyens aptes à : 30 - envoyer une demande d'authentifiant au système à partir d'une zone de l'aéronef d'un type prédéterminé ; - recevoir et enregistrer l'authentifiant ; - adresser l'authentifiant au système. On prévoit par ailleurs, selon l'invention, un programme d'ordinateur 35 comprenant des instructions de code apte à commander l'exécution d'une ou plusieurs des étapes d'un procédé selon l'invention lorsqu'il est utilisé sur un ordinateur. 2951562 -5- On prévoit également selon l'invention un support d'enregistrement de données comprenant un tel programme sous forme enregistrée. On prévoit enfin, selon l'invention, la mise à disposition d'un tel programme sur un réseau de télécommunication en vue de son téléchargement. 5 D'autres caractéristiques et avantages de l'invention apparaitront encore dans la description suivante d'un mode de réalisation donné à titre d'exemple non limitatif en référence aux dessins annexés sur lesquels : - la figure 1 est une vue de côté schématique d'un aéronef selon l'invention ; et - les figures 2 et 3 sont des schémas illustrant la mise en oeuvre du procédé de 10 l'invention au sein de l'aéronef de la figure 1. Nous allons présenter ci-après le principe général du présent mode de mise en oeuvre de l'invention. Nous envisagerons ensuite des détails de mise en oeuvre avec des variantes, puis nous présenterons les différentes étapes d'un exemple de mise en oeuvre. 15 L'aéronef du présent exemple a été illustré à la figure 1. Il s'agit en l'espèce d'un avion 2 comprenant un fuselage 4, des ailes non illustrées et un empennage 6. Cet avion comprend un poste de pilotage 8. L'avion comprend un système d'information 10 qui comporte plusieurs ordinateurs reliés entre eux par un réseau de communication de bord 24. Il est possible de se connecter à ce réseau 20 et au système au moyen de connecteurs ou prises 11 disponibles dans différentes zones de l'avion. Ces zones sont ici classées en deux catégories ou types. On distingue ainsi des zones d'un premier type tel que les zones situées dans la partie 12 de l'avion de la figure 1 et les zones d'un deuxième type telles que les zones situées dans la 25 partie 14 de cet avion. Les zones du premier type sont ici voisines du cockpit et globalement situées à l'avant du fuselage tandis que les zones du deuxième type sont situées à l'arrière des zones du premier type et comprennent la cabine destinée à être occupée par les passagers de l'avion, par exemple sur deux ponts situés l'un au-dessus de l'autre. Dans le présent exemple, les zones du premier 30 type sont des zones à accès restreint au contraire des zones du deuxième type. Cela signifie que le niveau de sécurité associé aux zones du premier type est plus élevé que celui associé aux zones du deuxième type. Ainsi, les zones du deuxième type sont physiquement accessibles à toutes les personnes se trouvant à bord, y compris les passagers, alors que les zones du premier type sont physiquement 35 accessibles seulement à certaines personnes autorisées telles que le personnel de bord ou le personnel de maintenance. En dépit de cette possibilité d'accès physique, l'invention vise à réserver l'accès par les zones du deuxième type à 2951562 -6- certaines personnes seulement telles que les opérateurs de maintenance. Le procédé est mis en oeuvre synthétiquement de la façon suivante. Une personne telle qu'unopérateur 16, chargé de la maintenance, récupère dans un premier temps à l'aide d'un terminal tel qu'un ordinateur portable de maintenance 5 18 un authentifiant électronique 30 dans une zone 12 du premier type. Cet authentifiant qui consiste en l'espèce en un ticket est la preuve que l'opérateur est autorisé à accéder à cette zone. L'opérateur 16 se déplace vers une zone 14 du deuxième type, par exemple la cabine pour les passagers. Il connecte ensuite son terminal 18 au système 10 d'information de l'avion via une prise 11 de cette zone. Pour cela, il présente le ticket électronique 30 pour s'authentifier et être autorisé à accéder au système d'information 10. Pour améliorer le niveau de sécurité de la solution, le ticket 30 n'est valable que dans un temps limité. Ainsi, passé un délai prédéterminé, le ticket est invalidé 15 et le système d'authentification mis en place à cette fin rejettera toute demande d'accès au système d'information avec ce ticket. Inversement, tant que le ticket est valable, l'opérateur 16 a la possibilité de se déplacer et de se connecter tour à tour sur différentes prises 11 pour accéder au système d'information, que ces prises se trouvent dans une zone du premier ou du 20 deuxième type. En particulier, il peut se connecter successivement à plusieurs prises situées en zones de type deux (zone libre) sans devoir revenir entretemps dans la zone à accès restreint. Pour la mise en oeuvre de ce procédé, le système d'information de bord 10 comprend en l'espèce un module formant un gestionnaire de tickets 20 en charge 25 de créer les tickets 30, de les distribuer, de gérer leur durée de validité et enfin de les supprimer. Il comprend aussi un module formant un serveur d'authentification 26 en charge de vérifier la validité d'un ticket et d'autoriser l'accès au système d'information. En référence à la figure 2, le gestionnaire de tickets 20 et le serveur d'authentification 26 sont chacun reliés à une base de données de tickets 22 du 30 système d'information ainsi qu'au réseau de communication 24. Le gestionnaire de tickets et le serveur d'authentification pourront être des modules logiciels assurant les fonctions précitées et qui seront détaillées plus loin. Nous allons maintenant présenter les principales étapes du procédé de l'invention et envisager différents modes de mise en oeuvre. 35 Une première étape principale est la création du ticket 30. Cette création a lieu dans le système d'information 10. On peut prévoir qu'elle est automatique, c'est-à-dire initiée par des moyens automatisés ou au contraire déclenchée par 2951562 -7 l'opérateur 16 ou d'une tierce personne. La génération automatique du ticket par le système d'information a pour avantage de limiter les actions nécessaires pour aller en zone à accès libre. Par exemple, le simple fait de brancher le terminal 18 sur une prise du système 5 d'information peut déclencher la création d'un ticket pour ce terminal. A l'inverse, la génération sur demande a pour avantage de ne pas créer de ticket lorsque cela n'est pas nécessaire. De plus, dans cette solution, l'opérateur 16 est conscient qu'une sécurité est mise en place puisqu'il doit faire une demande avant d'aller en zone à accès libre. 10 Une alternative consiste à générer automatiquement le ticket 30 lorsque le terminal de maintenance le demande depuis une prise en zone à accès restreint et cette demande et effectuée automatiquement lors de la connexion du terminal sur le système d'information après vérification que le terminal ne contient pas déjà un ticket. 15 Le gestionnaire de ticket 20 doit rendre impossible de prévoir le ticket. On ne doit pas pouvoir le créer indépendamment du système d'information. Un attaquant ne doit pas pouvoir rejouer un ticket avec succès, c'est-à-dire accéder au système en présentant un ticket qui a déjà servi et est expiré. Une autre étape principale est la récupération du ticket 30. En effet, une fois le 20 ticket créé, il doit être récupéré par le terminal 18. De même que pour la création, deux modes de réalisation sont envisageables, à savoir un mode automatique et un mode sur demande. Si l'on préfère que l'opérateur 16 soit impliqué dans le processus de demande d'accès, on favorisera la solution sur demande. Si au contraire, on privilégie la rapidité et la facilité d'utilisation, on préfèrera la 25 récupération automatique dès la connexion du terminal, c'est-à-dire la récupération initiée par des moyens automatisés, par exemple par le terminal lui ûmême. Une autre étape importante est le stockage du ticket. En l'espèce, le ticket est stocké dans la base 22 de l'avion et dupliqué dans le terminal 18 de l'opérateur. La gestion de la durée de validité du ticket constitue aussi une étape 30 importante et préférée dans le présent exemple. Cette gestion peut se faire de trois façons. Soit le ticket contient son propre compteur de temps dans le terminal de maintenance, soit le système d'information 10 détient un compteur de temps associé à chaque ticket, soit, encore, ce système détient un tel compteur de temps associé à chaque ticket et le terminal 18 lui-aussi gère en interne un compteur de 35 temps pour son ticket. Parmi ces trois solutions, la première a pour inconvénient de pouvoir être corrompue. En effet, il est envisageable de modifier directement le ticket sur le 2951562 -8- terminal pour que le ticket reste valable au-delà de la durée prévue. La deuxième solution corrige ce problème de corruption étant donné que la vérification de la validité ne se fait que sur le système d'information de l'avion et que la base de ticket 22 est protégée contre les attaques. La troisième solution conserve cet 5 avantage et de plus limite le nombre de tickets à vérifier. En effet, le terminal 18 se charge de modifier l'état de son ticket (état valable ou état non valable) à partir de son propre compteur. Cela permet de gérer localement l'effacement du ticket sur le terminal 18. Lorsque l'opérateur est connecté et authentifié avec son terminal 18 sur le 10 système d'information 10, il est préférable de faire en sorte que sa session de travail ne soit pas interrompue à cause de l'expiration du ticket. C'est pourquoi, en l'espèce, la durée de validité est uniquement décomptée lorsque le terminal 18 est déconnecté du système 10. Par conséquent, lorsque l'opérateur déconnecte le terminal 18 de la prise qui le reliait au système 10, ce dernier déclenche un 15 compteur mesurant l'intervalle de temps s'écoulant depuis cette déconnexion. Pour être valable, la prochaine connexion à une prise du système d'information devra intervenir avant que le compteur ait atteint une durée prédéterminée, par exemple une heure. Si une nouvelle connexion du terminal 18 au système d'information est demandée à partir d'une zone de type deux alors que cette période est écoulée, 20 l'opérateur devra se rendre dans une zone du premier type pour demander à nouveau un authentifiant. Une autre étape encore est la présentation du ticket. En effet, le système d'information 10 de l'avion, dans le présent exemple, authentifie le terminal 18 à partir du ticket que celui-ci présente. Il s'agit donc d'une authentification par 25 comparaison du ticket présenté par le terminal 18 avec celui se trouvant dans la base 22. Deux modes de réalisation sont envisageables à cette fin, le mode automatique ou le mode sur demande. A nouveau, si l'on préfère que l'opérateur 16 soit impliqué dans le processus d'authentification, on favorisera la solution où la présentation du ticket se fait sur demande initiée par l'opérateur. A l'inverse, si l'on 30 favorise la rapidité et la facilité d'utilisation, on préfèrera que la présentation du ticket au système d'information soit initiée par des moyens automatisés dès la connexion du terminal 18 au réseau 24. Par ailleurs, la validité du ticket est vérifiée lors de l'authentification du terminal 18 par le système 10. Enfin, une autre étape importante est l'effacement du ticket. En effet, lorsque le 35 ticket n'est plus valable, on préfère en l'espèce qu'il soit supprimé. Deux modes de réalisation sont envisageables pour cela. Soit le ticket est supprimé uniquement de la base 22, soit le ticket est supprimé de cette base et du terminal 18. L'avantage 2951562 -9- de la deuxième solution est que le terminal 18 ne conserve pas un ticket non valable qui de toute façon sera rejeté lors d'une authentification sur le serveur d'authentification de l'avion. Sa mémoire ne se trouve donc pas inutilement encombrée. 5 Nous allons maintenant décrire un exemple détaillé de mise en oeuvre du procédé de l'invention en référence à la figure 3. Le mode de mise en oeuvre décrit ici correspond au choix d'une automatisation des interactions entre le système d'information 10 de l'avion 2 et le terminal 18. Le terminal 18 comprend un module 32 constituant un service de demande de 10 tickets apte à se déclencher lors de l'activation du lien réseau du service ad hoc du terminal 18, c'est-à-dire lorsque ce service détecte une connexion du terminal 18 sur une prise du réseau 24. Il comprend aussi un service 36 de présentation du ticket. Tous deux sont ici des modules logiciels du terminal 18. Lors d'une étape liminaire, l'opérateur 16 connecte le terminal 18 sur une prise 15 11 d'une zone du premier type (à accès restreint) du réseau 24 de l'avion. Lors d'une étape 101, le service de demande de ticket 32 du terminal 18 détermine si ce dernier contient déjà un ticket. Il effectue cette vérification, déclenchée automatiquement par la connexion, auprès de la mémoire 34 du terminal. On suppose ci-après que le terminal 18 détermine qu'il ne contient pas 20 déjà un ticket. Au cours d'une étape 102, le service 32 exécute une requête vers le système d'information 10. Cette requête comprend une demande de ticket. La requête a été initiée de façon automatisée par le service 32 après l'étape de vérification. Le service 32 se met ensuite à l'écoute d'une réponse du système 10. 25 Le gestionnaire de tickets 20 est apte à déterminer si la prise à partir de laquelle le terminal 18 a adressé la requête présente une caractéristique prédéterminée, en l'espèce si une table du système 10 associe à la prise un numéro signifiant qu'elle se situe dans une zone de type 1. Cela revient à déterminer s'il s'agit d'une zone à accès restreint ou pas. Lors d'une étape 103, il 30 détermine donc si la demande de tickets a été effectuée à partir d'une prise en zone à accès retreint. On suppose ci-après que le système 10 détermine que c'est effectivement le cas. Au cours d'une étape 104, le gestionnaire de tickets 20 crée un nouveau ticket 30 et l'enregistre dans la base 22. Ce ticket est unique et obtenu par un générateur 35 d'aléa. Au cours d'une étape 105, le ticket est envoyé au service de demande de ticket 32 du terminal 18. 2951562 -10- A l'inverse, si le système 10 reçoit une requête de demande de ticket à partir d'une prise présentant un numéro signifiant qu'elle ne se situe pas dans une zone de type 1, alors le gestionnaire de ticket 20 répond au terminal en lui en adressant un refus de distribution de ticket. 5 La zone 34 de stockage du ticket dans le terminal est prévue pour être accessible par le service 32 de demande de ticket et le service 36 de présentation du ticket. Au cours d'une étape 106, le terminal enregistre dans la mémoire 34 le ticket reçu. Lors d'une étape 107, l'opérateur déconnecte le terminal 18 à l'égard du 10 réseau 24. Afin d'éviter toute modification du ticket pour que celui-ci soit toujours valable, le système d'information 10 gère seul la durée de validité du ticket. Pour cela, lors d'une étape 108 déclenchée par la déconnexion, le gestionnaire de ticket 20 crée un compteur de validité 31 qu'il associe au ticket 30 nouvellement généré. Ainsi 15 seuls les terminaux déconnectés 18 ont un compteur de validité associé à leur ticket dans la base 22. A la suite de cela, le gestionnaire de tickets 103 assure un suivi périodique de la validité du ticket, en comparant la durée affichée sur le compteur 31 avec une durée prédéterminée. Si la durée du compteur dépasse cette dernière, alors le ticket devient non valable et le gestionnaire de tickets 20 20 supprime le ticket ainsi que son compteur de la base 22. Parallèlement à la création du compteur dans le système 10, lors d'une étape 109, le service 36 de présentation du ticket du terminal 18 crée lui aussi un compteur de validité 31 associé au ticket. De même que dans le système 10, le service 36 assure un suivi périodique de la validité du ticket, en comparant la durée 25 affichée par le compteur 31 avec une durée prédéterminée. Si la durée du compteur dépasse cette dernière, le ticket devient non valable et le service 36 supprime le ticket ainsi que son compteur de la mémoire 34. Lors d'une étape 110, l'opérateur qui s'est déplacé connecte à nouveau le terminal au système 10. Il est ici indifférent que cette connexion ait lieu depuis une 30 zone du premier type ou du deuxième type. Lors d'une étape 111, le service de demande de ticket 32 détermine si le terminal contient déjà un ticket. Il effectue cette détermination auprès de la mémoire 34. Cette détermination est initiée de façon automatisée par le terminal après la phase de connexion. 35 Le service de demande de ticket 32 ayant trouvé et récupéré un ticket, le service 36 de présentation du ticket du terminal 18 envoie le ticket au serveur d'authentification 26 du système 10. Cette présentation du ticket est initiée de 2951562 -11- façon automatisée par le terminal après la phase de récupération du ticket. Le serveur d'authentification 26 doit être un service en écoute. Il a accès à la base 22. Lors d'une étape 113, après avoir reçu le ticket transmis par le terminal, le serveur d'authentification 26 détermine si un ticket identique à celui reçu est 5 enregistré dans la base 22. Compte tenu de ce que l'on a indiqué plus haut, si un ticket donné est toujours présent dans cette base, c'est qu'il est valable. Ainsi, au cours de l'étape 114, la base 22 adresse au serveur 26 le résultat de la comparaison du ticket reçu avec celui archivé dans la base. Si l'authentification échoue, le serveur d'authentification envoie une réponse 10 négative au terminal 18. A l'étape 115, si l'authentification est réussie, le serveur d'authentification 26 autorise le terminal 18 à accéder au reste du système d'information de l'avion depuis la prise à laquelle il est maintenant connecté. Lorsque l'opérateur 16 déconnecte à nouveau le terminal 18 de la prise 11, le 15 système 10 et le terminal créent chacun un nouveau compteur qui mesure l'intervalle de temps jusqu'à la prochaine connexion éventuelle. Lorsque le gestionnaire de ticket 20 détecte qu'un ticket n'est plus valable en raison de l'expiration de son compteur de validité, il supprime le ticket et son compteur de la base 22. Il en est de même dans le terminal 18 avec le service 36 20 de présentation du ticket. Ce mode de réalisation met donc en oeuvre une création du ticket avec une demande automatique de ticket lors de la connexion du terminal 18, après vérification de l'absence de ticket dans ce dernier. Puis la distribution du ticket a lieu avec une récupération automatique du ticket 25 suite à une demande effectuée sur une prise en zone à accès restreint. Le problème du stockage du ticket est résolu grâce à une sauvegarde du ticket dans la base 22 du système d'information de l'avion qui est accessible par le service gestionnaire de tickets 20 et le service d'authentification 26, ainsi que dans le terminal pour être accessible par le service 36 de présentation du ticket. 30 Cette solution assure la gestion de la validité du ticket grâce à un compteur associé à chaque ticket géré pour l'authentification par le gestionnaire de tickets 20 du système 10, et à un compteur dans le terminal afin de ne présenter au système d'information de l'avion qu'un ticket valable. Cette solution facilite la présentation du ticket grâce à l'envoi automatique du 35 ticket au système d'information 10 une fois la phase de récupération de ticket effectuée. Elle résout la question de la place disponible en mémoire grâce à un 2951562 -12- effacement automatique du ticket suite au contrôle régulier de la validité du ticket effectuée dans le terminal 18 par le service de présentation 36 ainsi que dans le système d'information 10 par le gestionnaire de ticket 20. Le système d'information 10 et le terminal 18 comprennent un ou plusieurs 5 microprocesseurs et une ou plusieurs mémoires. Le système 10 sera formé généralement de plusieurs ordinateurs. Le terminal 18 forme un ordinateur. Il peut être constitué par un ordinateur portable, un assistant personnel de type PDA, voire un terminal de téléphonie mobile. Tout ou partie des étapes du procédé de l'invention peuvent être commandées 10 par un programme d'ordinateur. Ce dernier comprend des instructions de code aptes à commander l'exécution de ces étapes lorsqu'il est exécuté sur un ordinateur. On peut prévoir d'enregistrer ce programme sur un support d'enregistrement de données tel qu'un disque DVD, un dispositif à mémoire flash ou un disque dur. On pourra mettre à disposition un tel programme sur le réseau 15 24 ou sur un réseau de télécommunications indépendant de l'aéronef en vue de son téléchargement, par exemple pour le téléchargement de mises à jour. Bien entendu, on pourra apporter à l'invention de nombreuses modifications sans sortir du cadre de celle-ci. On pourra prévoir que la caractéristique prédéterminée ne concerne pas un 20 type de zones du connecteur ni n'est pas relative à un niveau de sécurité qui leur est associé, bien que l'invention trouve tout son intérêt dans un tel cas. Le type pourrait ainsi renvoyer à la localisation de la zone (avant, arrière du fuselage, pont supérieur, pont inférieur, etc.). Les zones du premier type (accès restreint) ne sont pas forcément en partie 25 avant de l'avion comme représenté sur la figure 1. En pratique, il peut s'agir du cockpit ainsi que des zones de repos de l'équipage (situées en partie avant de l'avion). Mais on peut aussi envisager que tout ou partie des zones d'accès restreint soient par exemple en partie arrière de l'avion (par exemple des zones difficiles d'accès du fait de leur situation). On pourrait ainsi avoir une zone en accès 30 restreint en partie avant et une autre zone en accès restreint en partie arrière. REVENDICATIONS1. Procédé pour accéder à un système d'information (10) d'un aéronef (2), caractérisé en ce que : - le système reçoit d'un connecteur de l'aéronef une demande d'authentifiant ; - le système détermine si le connecteur présente une caractéristique prédéterminée ; et - dans le cas où le système détermine que le connecteur présente la caractéristique prédéterminée, le système envoie un authentifiant (30) au connecteur. 2. Procédé pour accéder à un système d'information (10) d'un aéronef (2), de préférence selon la revendication précédente, caractérisé en ce que : - le système reçoit un authentifiant (30) ; - le système détermine si l'authentifiant est valable ; et - dans le cas où le système détermine que l'authentifiant est valable, le système autorise un accès au système à partir d'un connecteur de l'aéronef depuis lequel a été envoyé l'authentifiant. 3. Procédé selon la revendication précédente dans lequel le système (10) compare l'authentifiant reçu (30) avec un authentifiant enregistré dans le système. 4. Procédé selon l'une quelconque des revendications 2 et 3, dans lequel le système (10) déclenche un compteur (31) mesurant un intervalle de temps écoulé depuis un évènement prédéterminé, de préférence une déconnexion dernière en date, à 1 'égard du système, d'un terminal (18) ayant envoyé l'authentifiant, la validité de l'authentifiant (30) dépendant d'un état du compteur (31). 5. Procédé selon l'une quelconque des revendications 2 à 4, dans lequel les étapes de réception, de détermination et d'autorisation forment une série d'étapes exécutée plusieurs fois. 6. Aéronef (2) caractérisé en ce qu'il comprend un système d'information (10) apte : - lorsqu'il reçoit d'un connecteur de l'aéronef une demande d'authentifiant, à déterminer si le connecteur présente une caractéristique prédéterminée ; et - dans le cas où le système détermine que le connecteur présente la caractéristique prédéterminée, à envoyer un authentifiant (30) au connecteur. 7. Aéronef (2), de préférence selon la revendication précédente, caractérisé en ce qu'il comprend un système d'information (10) apte : - lorsqu'il reçoit un authentifiant (30), à déterminer si l'authentifiant est valable ; et 2951562 -14- - dans le cas où le système détermine que l'authentifiant est valable, à autoriser un accès au système à partir d'un connecteur de l'aéronef depuis lequel a été envoyé l'authentifiant. 8. Procédé pour accéder à un système d'information (10) d'un aéronef (2), 5 caractérisé en ce que : - un terminal (18) envoie une demande d'authentifiant au système à partir d'une zone (12) de l'aéronef d'un type prédéterminé ; - le terminal reçoit et enregistre l'authentifiant (30) ; - on déconnecte le terminal du système ; et 10 - le terminal, à nouveau connecté au système, adresse l'authentifiant (30) au système. 9. Procédé selon la revendication précédente dans lequel, avant d'envoyer la demande, le terminal (18) détermine si un authentifiant (30) est enregistré dans le terminal. 15 10. Procédé selon l'une quelconque des revendications 8 à 9 dans lequel le terminal (18) déclenche un compteur (31) mesurant un intervalle de temps écoulé depuis un événement prédéterminé, de préférence une déconnexion dernière en date du terminal à I 'égard du système, la validité de l'authentifiant (30) dépendant d'un état du compteur (31). 20