Synchronisation des horloges

Comme nous l’avons vu au chapitre 3, TESLA repose largement sur le temps et demande au minimum une synchronisation relative entre l’émetteur et les récepteurs. Dans la solution originale, Perrig et al. (2002a) proposaient un protocole de synchronisation reposant sur une négociation entre l’émetteur et chaque récepteur. On pouvait alors déterminer ∆, l’écart maximum entre leurs deux horloges. À partir de ∆, on était capable de déterminer le délai d optimal avant la diffusion des clés.

Cependant, cette technique présente deux problèmes majeurs dans le cadre de l’ADS-B. Tout d’abord, elle requiert un échange bidirectionnel entre chaque récepteur et l’émetteur. Cela est contraire au principe de communication uniquement broadcast que l’on veut conserver. De plus, la valeur optimale de d dépend de ∆, et est propre à chaque récepteur. Il faudrait donc

a priori utiliser une chaîne TESLA différente pour chaque récepteur. Ceci implique d’envoyer

un MAC différent pour chacun d’entre eux dans chaque message, ce qui augmente largement l’utilisation de bande passante et n’est pas envisageable. On pourrait également borner ∆, et choisir un d en conséquence. Cependant, un avion dont le défaut de synchronisation avec l’émetteur dépasserait ∆ ne serait pas capable d’authentifier les messages.

4.1.1 Utilisation du temps GNSS

Heureusement, les avions utilisant l’ADS-B sont équipés de systèmes de navigation par satel- lite, ou GNSS. En effet, c’est de ces systèmes que proviennent les informations de positionne- ment qu’ils transmettent. Il peut s’agir du Global Positioning System (GPS) américain, du GLObalnaya NAvigatsionnaya Sutnikovaya Sistema (GLONASS) russe, du Galileo européen ou encore du COMPASS chinois (Hegarty et Chatre, 2008).

Le positionnement GNSS repose sur la multilatération. En connaissant au minimum les posi- tions de quatre satellites, et en utilisant les différences de temps d’arrivée (TDOA) entre les signaux émis simultanément par chacun de ces satellites, on est capable de calculer notre po- sition. Il s’agit en fait de la situation symétrique de la multilatération présentée en 2.4.1.1, où l’on souhaitait calculer la position d’un avion à partir de son signal reçu par quatre antennes fixes.

Puisqu’il faut connaître la position des satellites pour être capable d’effectuer la multilatéra- tion, le signal envoyé par chaque satellite contient des informations sur son orbite. À partir de celles-ci, la position du satellite peut être calculée. Pour être capables d’émettre un signal de façon simultanée, les satellites embarquent une horloge atomique, très précise (une dévia- tion de moins de 10−16 seconde chaque seconde). De plus, une horloge maître synchronise régulièrement les horloges des différents satellites entre eux, pour encore plus de précision. Le temps exact d’émission du signal est également encodé dans celui-ci.

Une fois que l’avion a déterminé sa position grâce à la multilatération, il est capable de savoir la distance qui le sépare d’un satellite donné. Il peut alors calculer le temps de propagation du signal, et en déduire le temps actuel. Celui-ci est utilisé pour resynchroniser l’horloge de l’avion avec le temps GNSS exact. En effet, une horloge atomique coûte très cher, et les avions ne sont donc équipés que d’horloges au quartz. Ces dernières ne restent suffisamment précises pour les calculs de positionnement que pendant quelques secondes.

Selon la spécification du GPS, la précision alors obtenue pour l’horloge de l’avion par rapport à l’horloge maître sur laquelle se synchronisent les satellites est de l’ordre de 40 ns, et d’au pire 100 ns (GPS directorate, 2013). Cela est déjà très précis, mais des techniques de correction du positionnement ont été introduites pour encore améliorer ces résultats. En effet, l’orbite du satellite est sujette à de légères variations. Des corrections sont donc diffusées à travers des éphémérides. De plus, les horloges sont sujettes à de faibles dérives constantes qui peuvent être prédites. Enfin, des éruptions solaires peuvent produire des perturbations ionosphériques qui introduisent un délai dans la propagation du signal des satellites. Chaque système GNSS implémente donc son propre système de corrections ; dans le cas du GPS, il s’agit du Wide

Area Augmentation System (WAAS) géré par la FAA.

En conclusion, même en considérant une erreur maximale de synchronisation de 100 ns avec l’horloge maître, on obtient ∆ = 200 ns (dans le pire des cas, l’émetteur a 100 ns d’avance sur l’horloge maître et le récepteur est 100 ns en retard). Cela ne nécessite de négociation entre l’émetteur et le récepteur, et cette borne supérieure est commune à tous les avions. Une seule chaîne de clés TESLA et donc un unique MAC sera nécessaire pour la diffusion de chaque message.

4.1.2 Sécurité du temps GNSS

Étant donné que TESLA repose sur le temps pour vérifier l’authenticité d’un message, il faut s’assurer de la fiabilité de l’horloge. Comme nous venons de le voir, la précision de celle-ci est a priori assurée par le GNSS. Cependant, comme tout système, celui-ci peut être la cible d’une attaque. Ainsi, il pourrait être possible de manipuler le signal GNSS afin de retarder l’horloge d’un récepteur ou d’avancer l’horloge de l’émetteur. L’erreur de synchronisation pourrait alors dépasser ∆, et la clé d’un intervalle être diffusée alors qu’elle paraît encore valide pour l’authentification de cet intervalle.

Cependant, le signal GNSS est déjà utilisé pour l’obtention du positionnement d’un avion qui est diffusé par ADS-B. Même en se servant d’une autre source d’horloge sécurisée pour l’authentification des messages, leur contenu pourrait de toute façon être erroné bien que leur intégrité soit assurée (puisque l’erreur a été introduite à la source et non pendant la transmission).

La sécurité du GNSS est loin d’être une problématique nouvelle. En effet, c’est une tech- nologie qui a été introduite en premier lieu par l’armée américaine dans les années 1980, et de nombreux travaux ont été consacrés à ce sujet (Volpe, 2001; Humphreys et al., 2008; Papadimitratos et Jovanovic, 2008). L’étude et la résolution de ce problème sont cependant hors de la portée de ce mémoire. Il est toutefois intéressant de mentionner les travaux de Becker et al. (2009) et de Lo et Enge (2010), qui proposent justement l’utilisation de TESLA pour sécuriser le GNSS.