Sécuriser les satellites et les liaisons montantes

Sécuriser les satellites et les liaisons montantes

Un satellite n’est pas hors d’atteinte parce qu’il est haut, il est exposé parce qu’il dépend d’une chaîne radio, logicielle et opérationnelle très longue. La priorité n’est pas de chiffrer chaque octet par réflexe : il faut protéger le contrôle de mission, empêcher le rejeu, conserver une capacité de reprise et accepter que la radio reste brouillable.

Explication de la marmotte

Un satellite ressemble à un équipement industriel placé très loin, sans technicien sur place pour appuyer sur le bouton de secours. Les ordres envoyés depuis le sol peuvent modifier son comportement, tandis que les informations reçues servent à décider de la suite. Le but est d’empêcher qu’une mauvaise personne prenne ce contrôle ou fasse taire le système.

→ Lire l’explication complète de la marmotte

Liaisons montantes : le contrôle de mission avant la confidentialité

La liaison montante transporte les télécommandes, les mises à jour logicielles, les changements de trajectoire et les paramètres de charge utile. Elle mérite un niveau de protection supérieur à la télémesure descendante : perdre une image est pénible, accepter une commande non autorisée est une compromission de mission.

Le compromis central oppose disponibilité immédiate et contrôle cryptographique rigoureux. Une authentification forte, des compteurs anti-rejeu et une double validation ralentissent l’exécution d’une commande. C’est le bon prix à payer pour les commandes critiques. Le mode dégradé ne doit jamais devenir un canal d’administration permanent parce qu’une console d’exploitation trouve la procédure « trop longue ». Ce genre de raccourci finit généralement dans une présentation intitulée retour d’expérience, avec beaucoup de rectangles rouges.

La recommandation est nette : séparer les flux de commande, de télémesure et de données utiles dès la conception radio et réseau. Le plan de télécommande doit utiliser une authentification mutuelle, un chiffrement authentifié et une protection anti-rejeu. Le plan de données peut accepter un niveau différent selon la sensibilité de la charge utile, mais ne doit pas partager les mêmes clés ni la même infrastructure d’émission.

Le protocole de sécurité de liaison spatiale du CCSDS (Consultative Committee for Space Data Systems) fournit un cadre interopérable pour protéger les trames. Son emploi ne dispense pas de définir le profil exact : algorithme, longueur de clé, taille du compteur, durée de vie des associations de sécurité et procédure de resynchronisation. « Compatible CCSDS » ne décrit pas une architecture. C’est une promesse marketing qui attend encore ses paramètres.

AES-GCM (Advanced Encryption Standard Galois/Counter Mode) convient aux trames lorsque l’unicité du vecteur d’initialisation est garantie pour chaque clé. Réutiliser un couple clé, vecteur d’initialisation détruit la confidentialité et l’intégrité attendues du mode. Sur une liaison intermittente, le compteur doit être persistant côté sol et côté satellite, ou dérivé d’un état impossible à répéter après redémarrage. Un compteur stocké uniquement en mémoire volatile fabrique du rejeu après coupure d’alimentation.

Les principes cryptographiques applicables aux clés symétriques, aux certificats et aux mécanismes de révocation restent ceux détaillés dans cryptographie. L’orbite ne rend pas les primitives moins fragiles, elle rend leur remplacement beaucoup plus cher.

Surface d’attaque orbitale et attaques radio connues

Le brouillage est l’attaque la plus accessible contre une liaison radio. Il ne requiert ni clé ni compréhension du protocole : il suffit de dégrader le rapport signal sur bruit autour de la fréquence visée. Le chiffrement ne protège pas contre le brouillage. Il protège le contenu, pas la disponibilité du spectre. Une architecture qui promet « anti-jamming grâce à AES » mérite une vérification immédiate, puis un café très fort.

Les contre-mesures sont physiques et opérationnelles : antennes directives, diversité géographique des stations sol, diversité de fréquences lorsque le cadre réglementaire le permet, détection de perte de porteuse, seuils de bascule et procédures de reprise testées. La modulation à étalement de spectre peut augmenter le coût du brouillage, mais elle n’annule pas un adversaire disposant de puissance et de proximité. La résilience vient de chemins alternatifs, pas d’un adjectif ajouté au modem.

L’usurpation consiste à émettre un signal qui imite une station légitime ou des données attendues. Une signature ou un code d’authentification de message bloque l’acceptation du contenu falsifié, à condition que la clé reste secrète et que la vérification soit faite avant toute action. Authentifier après avoir appliqué une télécommande reste une stratégie aussi utile qu’un parachute rangé dans le coffre.

Le rejeu rediffuse une commande valide, parfois des mois après son émission. Un numéro de séquence monotone, une fenêtre anti-rejeu et une date d’expiration réduisent ce risque. La fenêtre doit être dimensionnée pour les pertes et les réordonnancements attendus, puis bornée strictement. Une fenêtre infinie est une absence de protection avec une documentation plus longue.

La compromission d’une station sol reste souvent plus rentable que l’attaque radio. Les cibles incluent les serveurs de planification, les postes d’opérateurs, les modules radio définis par logiciel, les systèmes de génération de clés et les dépôts de logiciels embarqués. Les principes de segmentation, de filtrage et de journalisation décrits dans réseaux s’appliquent directement : isoler le réseau de contrôle, interdire les accès entrants non justifiés, enregistrer chaque émission et protéger les interfaces d’administration par authentification forte.

Clés de mission, HSM et rotations impossibles à improviser

Une clé de mission doit avoir un propriétaire, une finalité, une durée de vie et une procédure de destruction. Sans ces quatre éléments, il ne s’agit pas d’une gestion de clés mais d’une collection de secrets qui espèrent ne jamais devenir visibles.

La racine de confiance embarquée doit être injectée dans un environnement contrôlé avant lancement. Les clés de session ou de liaison doivent être dérivées ou chargées sous protection à partir de cette racine. Un HSM (Hardware Security Module) côté sol protège les clés maîtresses et limite leur exportation. Il ne sécurise ni le poste d’opérateur, ni le logiciel qui demande une signature, ni une commande déjà autorisée. Il fait exactement ce qui lui est demandé, avec le calme inquiétant d’une machine qui n’a jamais lu la procédure métier.

Une KEK (Key Encryption Key) chiffre les clés de trafic pendant leur stockage ou leur transport. Une DEK (Data Encryption Key) chiffre ou authentifie les données opérationnelles. Ces rôles doivent être séparés : exposer une clé de trafic ne doit pas permettre de déchiffrer l’inventaire complet des clés archivées.

Le module matériel doit exposer une interface PKCS#11 (Public-Key Cryptography Standards number 11) supportée par les outils de gestion, idéalement dans une version explicitement figée par le dossier d’architecture. La sélection, les droits et les journaux des objets cryptographiques doivent être revus comme du code. La page module cryptographique matériel et PKCS#11 couvre les contraintes de ce type d’intégration.

La rotation doit distinguer trois cas :

• rotation planifiée des clés de trafic, avec double présence temporaire des anciennes et nouvelles clés ;
• révocation d’urgence après suspicion de compromission, avec inhibition des commandes non critiques si la nouvelle clé ne peut pas être activée ;
• remplacement de la racine de confiance, souvent impossible sans mécanisme prévu avant lancement.

Une mise à jour de clé qui exige une liaison déjà sûre crée une dépendance circulaire. Il faut donc prévoir des clés de secours, des compteurs indépendants et des commandes de bascule limitées à des conditions précises. Les secrets de récupération doivent être répartis entre plusieurs détenteurs et protégés hors ligne. Une unique archive chiffrée avec le mot de passe du responsable d’astreinte n’est pas un plan de reprise, c’est un rituel vaudou avec chiffrement.

Exemple de contrôle d’intégrité d’une image embarquée

Une image logicielle destinée à un satellite doit être signée avant son transfert. La vérification doit porter sur le fichier exact, son manifeste de version et les métadonnées de compatibilité matérielle. Le satellite ne doit accepter qu’une clé publique ancrée lors de l’intégration, ou une clé intermédiaire validée par cette racine.

# Générer le condensat de l'image à transférer.
sha256sum flight-image.bin > flight-image.bin.sha256

# Signer le manifeste avec une clé privée conservée dans un HSM ou un poste isolé.
openssl dgst -sha256 \
  -sign mission-signing-private.pem \
  -out flight-image.bin.sig \
  flight-image.bin.sha256

# Vérifier avant l'envoi avec la clé publique autorisée.
openssl dgst -sha256 \
  -verify mission-signing-public.pem \
  -signature flight-image.bin.sig \
  flight-image.bin.sha256

Cet exemple utilise OpenSSL pour rendre le mécanisme vérifiable localement. En exploitation, la clé privée ne doit pas exister sous forme de fichier PEM (Privacy-Enhanced Mail) sur un serveur de transfert. La signature doit être demandée au HSM via PKCS#11, avec une autorisation séparée entre préparation de l’image et approbation de diffusion.

La signature garantit l’origine cryptographique de l’image et son intégrité. Elle ne garantit pas que le logiciel est sans vulnérabilité, compatible avec le matériel ou autorisé par les règles de mission. La validation fonctionnelle, la revue de code, l’analyse de dépendances et les essais de retour arrière restent nécessaires.

Exploitation, supervision et reprise après perte de contrôle

La supervision doit corréler quatre familles d’événements : demandes de télécommande, émissions effectives, accusés de réception radio et changements d’état du satellite. Sans horodatage synchronisé et journal immuable côté sol, une investigation ne peut pas distinguer une commande jamais émise, une trame perdue, une trame rejetée et une action exécutée sans accusé.

Les alertes prioritaires couvrent les échecs répétés d’authentification, les compteurs inattendus, les changements de fréquence, les tentatives de chargement de clé, les images logicielles refusées et les émissions hors créneau planifié. Un seuil d’alerte doit déclencher une action déterministe : bloquer, exiger une double approbation, basculer vers une station alternative ou passer en mode de sûreté. Une alerte sans procédure associée est juste une notification qui attend d’être ignorée.

La sauvegarde inclut les configurations de stations sol, les associations de sécurité, les journaux de commandes, les manifestes signés, les clés publiques et les éléments nécessaires à reconstruire un environnement de contrôle. Les clés privées ne doivent pas être restaurées comme des fichiers ordinaires : restaurer le HSM, ses politiques et ses fragments de récupération fait partie de l’exercice.

La reprise doit être testée contre des scénarios réalistes : perte d’une station sol, désynchronisation des compteurs, indisponibilité du service de signature, clé de trafic compromise et brouillage localisé. La résilience orbitale se prépare au sol. Après lancement, les marges de correction deviennent soudain très philosophiques.

🐝 Ce qui arrive si on s’en passe

Sans authentification ni compteur anti-rejeu persistant sur le plan de télécommande, toute station capable de reproduire le format de trame devient une source d’ordres acceptable, et un enregistrement de passage capté des mois plus tôt reste rejouable après un redémarrage qui a perdu l’état en mémoire volatile. Sans séparation des clés entre commande et charge utile, la compromission d’un flux de données ouvre le contrôle de mission. Sans image signée ancrée sur une racine intégrée avant lancement, un chargement logiciel modifié devient définitif faute d’intervention physique possible. Sans journal immuable et horodatage synchronisé au sol, il devient impossible d’établir si un changement d’état résulte d’une commande émise, d’une trame tierce ou d’une anomalie de bord. Sans procédure de rotation prévue, une clé suspectée compromise reste valide jusqu’à la fin de vie orbitale.

🦫 Explication de la marmotte 🍫

Un satellite reçoit des ordres depuis des stations installées au sol. Ces ordres peuvent allumer un appareil, modifier un réglage, installer un logiciel ou placer le satellite dans un état de protection. Ils passent par des ondes radio, donc une autre personne peut tenter de les écouter, de les copier, de les modifier ou de les empêcher d’arriver.

Pour éviter cela, chaque ordre est protégé par des secrets numériques connus seulement de la station autorisée et du satellite. Le satellite vérifie d’abord que l’ordre vient bien de la bonne source et qu’il n’a pas déjà été reçu. Il utilise pour cela un numéro qui avance à chaque message. Si ce numéro est ancien, le satellite refuse l’ordre, même si le contenu était valable autrefois.

Les secrets numériques doivent être préparés avant le lancement, car les remplacer après une panne peut être difficile. Ils sont conservés au sol dans des équipements spécialisés et changés selon une procédure prévue à l’avance. Les mises à jour de logiciel sont aussi vérifiées avant installation pour éviter qu’un fichier modifié soit accepté.

Cette protection ne peut pas empêcher quelqu’un de saturer les ondes radio avec un signal parasite. Il faut donc plusieurs stations, des moyens de détecter une perte de communication et des règles précises pour décider quoi faire. Si une vérification échoue, le satellite doit refuser l’action, enregistrer l’événement et attendre une commande valide.

À lire aussi

• Comment concevoir la sûreté cyber automobile et aéronautiqueAutomobile et aéronautique : quand une panne devient un risque physique, entre cybersécurité, disponibilité et fonctions de sûreté.
• Sécuriser l'accès des flottes de véhicules connectésSécuriser les systèmes de contrôle d'accès des véhicules connectés et des flottes face aux attaques par diagnostic et connectivité cellulaire.
• Sécuriser la signalisation ferroviaire connectéeArchitecture de sécurité pour la signalisation et les systèmes de contrôle ferroviaires connectés.
• Navigation inertielle et filtre de Kalman quand le GNSS est brouilléCe qui maintient une position quand le GNSS est brouillé ou leurré, de la centrale inertielle et sa dérive au filtre de Kalman, à la fusion de capteurs et au leurrage des capteurs eux-mêmes.

Pages voisines

La citent

• Accès hertziens, mobiles, satellites et small cells

Sécuriser les satellites et les liaisons montantes

Elle cite

• ⇄Lien dans les deux sens :Brouillage et leurrage GNSS, détection, OSNMA et repli du temps
• Architecture de journalisation d’audit immuable centralisée
• Partager un secret et distribuer la confiance

⇄ : les deux pages se citent l’une l’autre.