Envoi des certificats

Chaque avion est en possession de la totalité des clés publiques des sous-autorités de certifica- tion autorisées par l’OACI. Cela est possible, car leur nombre est réduit, et elles ne changent que peu fréquemment (dans le cas éventuel où une clé serait volée ou une NAA révoquée). Stocker directement les certificats de tous les avions n’est par contre pas réalisable. En effet, ceux-ci sont beaucoup trop nombreux, et changent régulièrement. Même pour les certificats à long terme, il n’est pas possible de fixer une date à laquelle tous les avions changeraient de

1. Demande d’un certificat par radio 2. Questions d’authentification par radio

6.a. Envoi du code aléatoire par radio

4. Envoi par ADS-B de sa clé publique et d’un nombre aléatoire chiffrés 3.c. Accepte la signature du certificat

7. Envoi du certificat par ADS-B

5. Déchiffrement des informations

6.b. Vérification du code aléatoire 3.a. Réponse aux questions d’authentification par radio

3.b. Vérification des réponses

A

vi

o

n

Con

trôleur

clé simultanément. Cela signifie qu’une partie des certificats est renouvelée tous les jours, et il n’est pas possible de mettre à jour les transpondeurs de façon aussi régulière pour y inclure la dernière liste de certificats, qui de toute façon ne rentrerait probablement pas en mémoire. Puisque les certificats de tous les avions ne peuvent pas être stockés dans les transpondeurs, ils doivent donc être reçus en cours de vol pour permettre l’identification des messages d’un nouvel avion.

4.2.3.1 Envoi sur demande

Une première possibilité consiste à récupérer les certificats par l’intermédiaire de requêtes. Bob est en vol, et authentifie déjà les messages de plusieurs avions à proximité. À un moment donné, il croise la route d’un nouvel avion, Alice, dont il ne connaît pas le certificat. Il va alors diffuser un message demandant à Alice d’envoyer son certificat. Carole, qui vient également de recevoir un premier message d’Alice, entend la requête de Bob. Elle n’en émet pas de nouvelles, mais attend simplement qu’Alice diffuse son certificat pour le recevoir tout comme Bob.

Cette solution a comme avantage que le certificat d’Alice peut être reçu instantanément dès lors qu’un nouvel avion a besoin de le connaître. On s’éloigne en partie du fonctionnement

broadcast de TESLA, puise l’on est en présence de requêtes. Cependant, la réponse d’Alice à

une requête est destinée à tous les avions à proximité, et pas uniquement à l’émetteur de la requête. Cela n’est donc pas très problématique.

L’émission de requêtes a tout de même pour inconvénient de nécessiter l’envoi de messages supplémentaires, qui utilisent le peu de bande passante disponible. Cela reste négligeable en vol de croisière, lorsque l’on croise relativement peu d’avions. Mais imaginons le cas où Bob arriverait près d’un gros aéroport. Il ne connaît aucun des certificats des avions présents sur l’aéroport et à ses alentours, ce qui peut en représenter plusieurs dizaines. Il doit alors envoyer autant de requêtes, auxquelles doivent répondre chacun des avions, simultanément. Bob, sans le vouloir et pour une raison légitime, vient de saturer la bande passante. Il y a de fortes chances que, même si elles sont émises avec des délais aléatoires, les réponses des avions rentrent en collision et soient perdues. Un attaquant pourrait alors bien entendu causer un déni de service en émettant de nombreuses requêtes de certificats auprès de tous les avions présents.

4.2.3.2 Diffusion périodique

Pour cette raison, nous choisissons plutôt pour la suite une émission périodique des certificats. Chaque avion émettra, à un intervalle prédéterminé, son certificat. Le choix de la durée de cet intervalle est important, et sera discuté en détail en 5.4.

Lorsqu’il arrive à portée d’Alice, Bob doit attendre que cette dernière diffuse son certificat pour être capable de commencer à authentifier ses messages. Un intervalle trop long retarde donc d’autant le processus d’authentification. À l’inverse, un intervalle trop court demandera l’émission de beaucoup de messages et utilisera une trop grande quantité de bande passante.

4.2.3.3 Utilisation des signatures basées sur l’identité

Une dernière possibilité est l’utilisation de signatures basées sur l’identité (IBS). Le concept a déjà été abordé en 2.4.2.6. L’objectif était alors que la clé publique d’un avion puisse être extraite de différentes informations le concernant (numéro d’immatriculation, identifiant 24 bits de l’OACI, . . .). Cependant, la clé privée associée était directement utilisée pour produire des signatures pour chaque message envoyé, ce qui utilisait trop de bande passante.

L’idée serait ici de plutôt se servir de cette clé privée pour produire les signatures de la chaîne de clés de l’avion. Ainsi, lorsque Bob croise la route d’Alice, il n’a qu’à écouter les messages qu’elle envoie. Il peut alors connaître les différentes informations sur son identité dont il a besoin pour produire sa clé publique. À partir de celle-ci, il sera capable de vérifier la signature produite par Alice pour sa chaîne de clés, et ainsi authentifier ses messages. La clé privée est fournie à Alice par la NAA. La NAA est la seule à pouvoir générer cette clé, grâce à sa propre clé privée et aux informations sur l’identité d’Alice. Cependant, l’identité telle que présentée en 2.4.2.6 ne change pas au cours du temps. La méthode peut alors s’apparenter à un certificat à long terme, mais non pas à court terme. Pour cela, il faudrait ajouter certaines informations à l’identité d’Alice, caractéristiques du vol en cours. Celles-ci pourraient être extraites du plan de vol, dans le cas où celui-ci existe. On pourrait par exemple choisir des informations sur la route empruntée (waypoints, nom de code des prochaines étapes du vol), pour limiter le vol à la zone correspondante, ou encore les heures de départ et d’arrivée prévues pour le limiter dans le temps. Ces informations devraient alors être diffusées par ADS-B en cours de vol pour que la clé publique correspondante puisse être générée. La spécification de l’ADS-B contient déjà des types de messages pouvant contenir de telles informations, même s’ils ne sont généralement pas utilisés actuellement. L’annexe D présente par exemple un message contenant les prochains waypoints du vol.

riterait d’être approfondie lors de recherches futures. En effet, son implémentation soulève plusieurs questions auxquelles il faudrait répondre. Quelles seraient les informations les plus appropriées pour la génération des clés ? Le surcoût de leur transmission par ADS-B serait-il inférieur à celui de la transmission directe de la clé et de son certificat ? Quel algorithme choisir pour la génération des clés, et quel en serait le niveau de sécurité ? Pour la suite, nous considérerons la diffusion périodique des certificats. Cependant, SAT pourrait facilement évoluer pour y intégrer une solution d’IBS.