Si l’on oublie les possibilités d’emport du transpondeur de l’AN-225 dans un autre aéronef, la reprogrammation d’un transpondeur neuf avec le même code hexadécimal et les solutions de cet acabit, deux autres voies étaient possibles.

• La première, celle de forger directement des messages numériques, c’est-à-dire des suites d’octets contenant la position, la vitesse, le callsign etc. similaires à ceux produits par le logiciel usuel « dump1090 » qui est couplé aux récepteurs radios utilisés par les amateurs (qui constituent une grande partie du réseau de surveillance de Flightradar24) puis d’envoyer ces messages vers leur serveur.
  En somme de créer une version modifiée de dump1090 qui aurait produit de la donnée crédible sans avoir du tout besoin d’un récepteur radio.
• Une seconde méthode possible – celle finalement utilisée – était d’utiliser une chaîne Flightradar24 tout à fait normale, c’est-à-dire un récepteur radio standard et les logiciels habituels sans aucune modification mais d’utiliser un second appareil pour émettre directement des messages radio imitant une partie de ceux d’un véritable transpondeur.

La méthode retenue augmente un peu la portée de la démonstration car moyennant une radiodiffusion effective des signaux (OTA : over the air), elle permet par exemple d’utiliser un récepteur Flightradar24 de manière « non coopérative », c’est à dire à l’insu de son propriétaire et de son éventuel bon vouloir.

Au-delà et puisque c’est le nom de la technologie sous-jacente, elle met en évidence de façon « pratique » certaines faiblesses de la norme ADS-B qui ont déjà été soulignées dans des papiers de recherche, notamment celui écrit par Andrei Costin et Aurélien Francillon et consultable ici ou encore par un spécialiste en sécurité informatique lors d’une conférence DEFCON en 2012.

Dans le jargon cybersécurité, il existe un acronyme et même un blog « PoC||GTFO » (Proof of Concept or Get The Fuck Out) et c’est aussi dans cette tradition que s’inscrit le test grandeur nature effectué.

Je ne suis absolument pas spécialiste du contrôle aérien ni de l’ADS-B et donc je me garderai bien de conclure sur l’impact potentiel sur l’infrastructure aérienne réelle.
Les radars primaires et secondaires qui maillent le territoire n’y seraient pas sensibles car ils ont (me semble-t-il) besoin d’un écho (plot) réel correspondant à la présence d’un objet physique dans le faisceau au moment de l’illumination. Il y a peut-être toutefois des cas où les technologies de fusion des pistes pourraient être trompées et un plot réellement présenté à des contrôleurs ? Je serais curieux d’avoir l’avis de spécialistes.

Naïvement, j’ai tendance à croire qu’en revanche, les TCAS (dispositifs anticollision embarqués) basés eux aussi sur l’ADS-B pourraient y être plus sensibles et, en présence de traces simulées, émettre en cabine des alertes perturbant l’équipage de conduite. Le fait est que l’ADS-B n’offre aucune étape d’authentification (comme il en existe par exemple dans les communications réseau via par exemple le chiffrement par clé privée et le déchiffrement par clé publique) et que l’existence depuis quelques années d’émetteurs SDR peu coûteux permettant de mettre en œuvre des spoofing comme celui employé invite à repenser aux limites de cette technologie et en tout cas à mieux les connaître.
Cette remarque est également valable pour des technologies alternatives similaires comme les FLARM, les systèmes de « Remote ID » pour drones etc…
Sans mécanisme d’authentification, tous ces signaux sont falsifiables et ont été ou seront falsifiés un jour pour des usages malicieux.

Pour revenir plus spécifiquement à ma manipulation « Мрія » sur Flightradar24, j’ai utilisé un dispositif SDR HackRF qui coûte environ 300€ (à droite sur la photo ci-dessous du montage de test) et qui, comme son nom l’indique permet via son logiciel de moduler et émettre des signaux radio (dans une gamme de fréquence importante, permettant l’exploration et l’expérimentation vraiment intéressante autour des signaux radio).