Sécuriser la signalisation ferroviaire connectée

La signalisation connectée mêle deux exigences qui se contrarient volontiers : empêcher une commande illégitime, tout en maintenant un comportement sûr quand le réseau, l’alimentation ou l’identité distante disparaissent. Le compromis central est net : plus on connecte le contrôle pour gagner en supervision et en capacité, plus on doit prouver que la perte ou la compromission de cette connexion ne dégrade jamais la sûreté ferroviaire.

→ Lire l’explication complète de la marmotte

Séparer sûreté ferroviaire et cybersécurité

La sûreté ferroviaire vise à éviter un accident involontaire : collision, dépassement de vitesse, itinéraire incompatible ou franchissement d’un signal fermé. La cybersécurité vise à empêcher une action malveillante ou non autorisée : injection de télégramme, usurpation d’équipement, altération d’une configuration ou indisponibilité organisée. Les deux domaines se recouvrent, mais ne se remplacent pas. Un chiffrement parfait ne rend pas un algorithme d’enclenchement correct. Un calcul de sûreté ne repousse pas un poste opérateur compromis.

Dans l’European Train Control System (ETCS), un système européen de contrôle des trains, une Radio Block Centre (RBC), centre qui calcule des autorisations de mouvement par radio, peut transmettre une autorisation à bord. Cette autorisation ne doit être acceptée que si son origine, son intégrité, sa fraîcheur et son contexte sont vérifiés. Le canal radio ne constitue jamais une preuve suffisante. Un message reçu sur le bon réseau reste un message suspect jusqu’à validation cryptographique et contrôle métier.

La recommandation est de conserver une fonction de sécurité locale capable de conduire le train vers un état sûr sans dépendre d’un service central joignable. Une liaison distante peut optimiser l’exploitation, fournir une autorisation ou remonter un état, mais ne doit pas devenir l’unique frein entre une erreur distante et un mouvement dangereux. Le cloud qui promet de remplacer une logique locale certifiée avec trois conteneurs et une slide bleu nuit mérite un examen clinique.

Les normes de sûreté EN 50126, EN 50129 et EN 50716 structurent la démonstration de sûreté sur le cycle de vie ferroviaire. La norme IEC 62443, publiée par l’International Electrotechnical Commission (IEC), traite quant à elle la sécurité des systèmes d’automatisation et de contrôle industriels. Les appliquer côte à côte évite une erreur coûteuse : déclarer un équipement conforme à une exigence de sûreté puis découvrir que son interface d’administration expose une authentification réutilisable ou un protocole non chiffré.

La frontière d’architecture doit être explicite :

le domaine de sécurité opérationnelle exécute les fonctions de contrôle déterministes ;
le domaine de supervision reçoit les états nécessaires, avec filtrage et limitation de débit ;
les interfaces de maintenance traversent un bastion, une authentification forte et une journalisation ;
les échanges entre zones sont autorisés par flux métier, jamais par ouverture large entre sous-réseaux.

Les principes de segmentation réseau et d’interconnexion protégée s’appliquent ici sans romantisme : une zone de signalisation n’est pas un réseau bureautique avec davantage de câbles gris.

Identités, certificats et commandes de signalisation

Chaque équipement qui peut émettre, relayer ou accepter une commande doit disposer d’une identité distincte. Une identité partagée par une flotte de calculateurs rend l’attribution impossible et transforme la révocation en opération de destruction massive. Une clé privée compromise sur un équipement doit permettre de retirer cet équipement, pas d’arrêter toute la ligne parce qu’un secret commun a été copié dans une image de maintenance.

Une Public Key Infrastructure (PKI), infrastructure de gestion de certificats, fournit des certificats liant une identité à une clé publique. Elle doit distinguer au minimum les rôles d’autorité de certification, d’équipement de terrain, de centre de contrôle, de passerelle et d’administration. Un certificat d’administration ne doit jamais signer une autorisation de mouvement. La séparation des usages réduit la portée d’une compromission et simplifie l’audit.

Les clés racines et les clés d’autorité de certification doivent résider dans un Hardware Security Module (HSM), module matériel empêchant l’export non autorisé des clés privées. Un HSM ne corrige ni un mauvais modèle d’autorisation ni une station d’administration infectée. Il protège une frontière précise : l’extraction de la clé. Cette frontière compte beaucoup lors d’un dump mémoire, nettement moins dans une présentation commerciale.

Pour chaque commande critique, contrôler au moins :

l’identité cryptographique de l’émetteur ;
le rôle autorisé à produire cette catégorie de commande ;
l’intégrité du contenu signé ;
un identifiant de session ou de contexte associé au train, à la zone et à la version de configuration ;
un compteur monotone ou un nonce, valeur unique empêchant la réinjection ;
une durée de validité courte, évaluée avec une horloge maîtrisée ;
la cohérence métier avec l’état local connu.

La signature doit couvrir un encodage canonique, c’est-à-dire une représentation binaire unique du message. Signer du JSON (JavaScript Object Notation) sans règles canoniques laisse apparaître des divergences de parseur : deux systèmes peuvent afficher le même objet tout en calculant des octets différents. La cryptographie ne sauvera pas un protocole ambigu. Elle signera l’ambiguïté avec une ponctualité exemplaire.

La révocation pose un piège classique. Une Certificate Revocation List (CRL), liste signée de certificats révoqués, ou le Online Certificate Status Protocol (OCSP), protocole de vérification d’état de certificat, ne révoque pas rétroactivement une session déjà établie ni un message déjà accepté. Les commandes critiques doivent donc porter leur propre durée de vie et être rejetées après expiration, même si la session de transport demeure ouverte.

Pour les fondations cryptographiques, consulter cryptographie appliquée et PKI, certificats et TLS. Ces mécanismes restent des briques : ils authentifient des entités et protègent des échanges, ils ne décident pas si un itinéraire est physiquement disponible.

Surface d’attaque des réseaux de contrôle ferroviaire

La surface d’attaque commence avant le protocole de signalisation. Elle comprend les postes de maintenance, les commutateurs industriels, les convertisseurs de protocole, les passerelles radio, les concentrateurs de journaux, les mécanismes de télémaintenance et les chaînes de mise à jour. Une architecture qui chiffre le lien radio mais laisse une interface de maintenance avec mot de passe local fixe protège surtout le diagramme.

L’injection ou la réinjection de messages vise les autorisations, les acquittements et les changements de configuration. La contre-mesure associe signature ou code d’authentification de message, compteur persistant et fenêtre temporelle stricte. Un compteur stocké seulement en mémoire vive revient à redémarrer avec l’amnésie comme stratégie de sécurité. Après redémarrage, le système doit récupérer un état de séquence fiable ou exiger une nouvelle session authentifiée.

Le brouillage et le déni de service ne se résolvent pas par chiffrement. La confidentialité d’un canal radio ne rend pas le spectre radio disponible. La réponse doit venir de la sûreté : temporisation bornée, détection de perte de communication, bascule vers un mode dégradé et freinage si l’autorisation ne peut plus être justifiée. La disponibilité réseau est une hypothèse mesurée, jamais un dogme.

La compromission d’une station de maintenance ouvre une voie latérale vers les automates et calculateurs de terrain. Imposer une authentification multifacteur, un bastion d’administration, des sessions enregistrées et des autorisations temporaires. Les comptes locaux d’urgence doivent être rares, scellés par procédure et testés. Un compte « admin/admin » sur une interface industrielle n’est pas de la compatibilité historique, c’est une invitation avec buffet.

Les mises à jour constituent une autre cible majeure. Vérifier une signature de paquet, l’identité du signataire, la compatibilité matérielle, la version minimale autorisée et la protection contre le retour à une version vulnérable. Le Secure Boot, démarrage vérifiant cryptographiquement le logiciel exécuté, doit ancrer cette chaîne dans une clé matérielle ou une mémoire protégée. Sans protection contre le retour arrière, un attaquant peut réinstaller une version valide mais vulnérable. Le musée des firmwares ne ferme jamais tout seul.

Vérifier une signature et une chaîne de certificats

La validation cryptographique doit précéder tout traitement métier de la commande. L’exemple suivant vérifie d’abord la chaîne du certificat émetteur et sa révocation, puis la signature d’un message binaire. Les fichiers sont des entrées de test reproductibles, pas une recette de déploiement.

# Vérifier le certificat de l'émetteur contre la racine, l'intermédiaire et la CRL.
# La CRL doit être fraîche selon la politique d'exploitation.
openssl verify \
  -CAfile racine-ca.pem \
  -untrusted ca-intermediaire.pem \
  -CRLfile crl-signalisations.pem \
  -crl_check_all \
  rbc-certificat.pem

# Extraire la clé publique du certificat validé.
openssl x509 -in rbc-certificat.pem -pubkey -noout > rbc-cle-publique.pem

# Vérifier la signature RSA-PSS du message binaire exact reçu.
# Toute modification d'un octet doit provoquer un échec.
openssl pkeyutl -verify \
  -pubin -inkey rbc-cle-publique.pem \
  -in autorisation-mouvement.bin \
  -sigfile autorisation-mouvement.sig \
  -pkeyopt digest:sha256 \
  -pkeyopt rsa_padding_mode:pss \
  -pkeyopt rsa_pss_saltlen:digest

Cette vérification ne suffit pas à accepter autorisation-mouvement.bin. Le logiciel doit ensuite vérifier le compteur, la période de validité, l’identifiant du destinataire, la zone concernée et les contraintes d’état. La signature répond à « qui a signé ces octets ? ». Elle ne répond pas à « cette instruction est-elle acceptable maintenant ? ».

Exploitation : rotation, supervision et reprise contrôlée

Les secrets d’équipement doivent être injectés hors de l’image logicielle, idéalement lors de l’enrôlement contrôlé. Ne jamais distribuer une clé privée dans un paquet de mise à jour partagé. La rotation des certificats doit accepter un chevauchement de certificats actifs : le nouveau certificat est déployé et reconnu avant retrait de l’ancien. Retirer d’abord l’ancien certificat revient à tester le mode dégradé avec un marteau.

Superviser les refus de signature, les écarts d’horloge, les rejets de compteur, les demandes de certificat inhabituelles, les changements de configuration et les pertes de liaison. Les journaux doivent être horodatés depuis une source maîtrisée, protégés contre l’altération et exportés hors de la zone compromise. Les pratiques décrites dans l’observabilité en architecture cyber aident à distinguer une panne radio d’une tentative de rejeu.

La sauvegarde doit couvrir les configurations signées, les certificats publics, les listes de révocation, les règles de filtrage, les journaux nécessaires à l’investigation et les éléments de restauration des autorités de certification. Les clés racines ne se restaurent pas depuis une archive accessible par le même compte qui administre le réseau. Une reprise crédible sépare les détenteurs, documente les cérémonies de restauration et teste les dépendances hors production.

Enfin, prévoir le comportement de chaque dépendance indisponible : serveur d’identité, DNS (Domain Name System), service de temps, liste de révocation, collecte de journaux et dépôt de mise à jour. Si l’absence d’un de ces services bloque une fonction de sécurité, cette dépendance appartient au périmètre de sûreté. La découvrir pendant une coupure relève moins de l’architecture que du théâtre expérimental.

🐝 Ce qui arrive si on s’en passe

Sans ces contrôles, l’exploitation perd d’abord ce qui permet de conclure après coup : un message accepté sur la seule foi du canal ne laisse aucune trace d’origine, et l’analyse post-incident ne peut plus trancher entre perte radio, erreur de configuration et rejeu. L’absence d’identité par équipement rend la remédiation grossière : retirer un secret partagé revient à immobiliser l’ensemble des calculateurs qui le portent, alors qu’un certificat individuel se révoque seul. Sans encodage canonique ni journalisation protégée, aucune preuve exploitable ne subsiste pour un audit de conformité ou une expertise. Enfin, une vérification cryptographique dont les réponses diffèrent selon la nature de l’échec renseigne l’attaquant sur le format attendu, comme l’illustre la question qui rend le module bavard.

🦫 Explication de la marmotte 🍫

Un système ferroviaire connecté échange des informations entre le train, les équipements au sol et les centres de contrôle. Ces informations peuvent autoriser un mouvement, indiquer une vitesse maximale ou signaler qu’une partie de voie est occupée. Avant d’accepter une instruction, le système vérifie qui l’a envoyée, si son contenu a été modifié, si elle concerne le bon train et si elle est encore valable.

Chaque équipement possède une identité numérique fondée sur des clés secrètes et des certificats. Le certificat permet de vérifier publiquement qu’une clé appartient bien à un équipement autorisé. La clé secrète reste protégée dans le matériel. Une instruction est accompagnée d’une preuve mathématique calculée avec cette clé. Si le contenu change, la preuve ne correspond plus et l’instruction est rejetée.

Le système vérifie aussi qu’une ancienne instruction ne revient pas plus tard. Pour cela, les messages portent un numéro qui augmente et une durée de validité. Une instruction expirée ou déjà vue est refusée.

Si le réseau radio tombe, si un certificat devient suspect ou si une vérification échoue, le système ne doit pas inventer une autorisation. Il applique un mode dégradé prévu : limiter le mouvement, demander une nouvelle information ou arrêter le train selon les règles de sécurité. Les journaux enregistrent ces événements afin d’identifier une panne, une erreur de configuration ou une attaque.

Pages voisines

La citent

Sécuriser la signalisation ferroviaire connectée

Elle cite

Sécuriser la signalisation ferroviaire connectée

Sécuriser la signalisation ferroviaire connectée

Séparer sûreté ferroviaire et cybersécurité

Identités, certificats et commandes de signalisation

Surface d’attaque des réseaux de contrôle ferroviaire

Vérifier une signature et une chaîne de certificats

Exploitation : rotation, supervision et reprise contrôlée

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines