Comment concevoir la sûreté cyber automobile et aéronautique

Comment concevoir la sûreté cyber automobile et aéronautique

Dans un véhicule ou un aéronef, une indisponibilité informatique peut finir dans une commande absente, une information fausse ou un actionneur placé dans un état dangereux. Le compromis central oppose disponibilité immédiate et contrôle de sécurité : ajouter des vérifications réduit la surface d’attaque, mais peut aussi ajouter délai, dépendances et nouveaux modes de panne.

Explication de la marmotte

Un système embarqué critique ressemble à une équipe chargée de maintenir un train sur ses rails ou un avion sur sa trajectoire : chaque membre doit savoir quand continuer, quand s’arrêter et quand demander de l’aide. Le but n’est pas seulement d’éviter le piratage, mais d’éviter qu’un défaut informatique devienne un accident.

→ Lire l’explication complète de la marmotte

Sûreté de fonctionnement et cybersécurité : un même chemin vers le danger

La sûreté de fonctionnement traite les défaillances accidentelles : composant défectueux, alimentation instable, erreur logicielle, capteur incohérent. La cybersécurité traite l’action hostile : message injecté, micrologiciel remplacé, identité volée, service saturé. Ces disciplines ont des causes différentes, mais partagent les mêmes effets physiques : perte de freinage, commande moteur erronée, donnée de navigation falsifiée ou indisponibilité d’un affichage critique.

La recommandation est nette : ne jamais confier une fonction de sécurité à une décision distante, ni à une chaîne logicielle unique. Une mise à jour à distance, un service cloud ou une passerelle réseau peuvent enrichir une fonction, jamais devenir le seul chemin entre une décision de sûreté et un actionneur. La connectivité vend bien dans les présentations. Un frein dépendant d’un certificat valide à l’autre bout du continent, un peu moins.

Pour l’automobile, l’analyse de danger et l’évaluation de risque doivent raccorder la cybersécurité à ISO 26262, norme de sûreté fonctionnelle, et ISO/SAE 21434, norme de cybersécurité véhicule. Pour l’aéronautique, cette jonction passe notamment par DO-326A, cadre de navigabilité de sécurité, et par les objectifs de sûreté du système concerné. Ces références n’éliminent aucun défaut : elles imposent de démontrer qu’un défaut connu mène à un état maîtrisé.

Le bon modèle est celui de la dégradation contrôlée. Une fonction doit définir son état sûr, le délai maximal pour l’atteindre, les sources de décision autorisées et les conditions de retour au service. Un arrêt brutal peut être plus dangereux qu’un fonctionnement limité : perdre la propulsion au décollage ou couper une assistance de direction sur autoroute ne devient pas acceptable parce qu’un pare-feu a crié victoire.

Préconditions de plateforme et séparation des domaines embarqués

Une architecture critique exige une séparation matérielle ou une séparation démontrable entre domaine connecté et domaine de commande. Le domaine connecté comprend la télématique, le divertissement, les interfaces radio, les ports de diagnostic et les services de mise à jour. Le domaine de commande comprend les calculateurs électroniques, ou ECU (Electronic Control Unit), les capteurs, les actionneurs et les réseaux déterministes.

Un pare-feu logiciel dans le même système d’exploitation qu’une application exposée ne constitue pas une frontière de sûreté. Une compromission avec privilèges noyau contourne cette séparation en quelques instructions. La frontière doit reposer sur un processeur distinct, une hypervision qualifiée pour le niveau de risque visé, ou une passerelle matérielle dont les règles sont minimales et vérifiables.

Les réseaux CAN (Controller Area Network) historiques illustrent le problème : un identifiant de trame décrit une priorité et une fonction, pas l’émetteur autorisé. Toute station capable d’émettre peut usurper un identifiant légitime. CAN FD (Flexible Data-rate) augmente la charge utile et le débit, mais n’ajoute ni authentification ni chiffrement. Changer de connecteur ou de vitesse ne transforme pas un bus partagé en réseau de confiance. Le bus garde ses souvenirs.

Une passerelle entre zones doit appliquer une politique de liste blanche : identifiants autorisés, sens, cadence maximale, taille, valeurs ou plages attendues. Cette validation doit être indépendante du calculateur émetteur. Une trame de commande légitime mais reçue cent fois plus vite que prévu est une attaque de disponibilité, même si son contenu paraît impeccable.

Le démarrage sécurisé doit vérifier une chaîne de signature depuis une racine immuable jusqu’au micrologiciel applicatif. La clé de signature ne doit pas résider dans l’image de compilation, dans un dépôt Git ou dans un serveur de livraison. Un HSM (Hardware Security Module) ou un composant matériel équivalent protège les opérations privées et réduit l’extraction de clé. La page module cryptographique matériel et PKCS#11 détaille les contraintes d’intégration d’un HSM avec PKCS#11 (Public-Key Cryptography Standards #11).

Surface d’attaque des bus, diagnostics et mises à jour

Le port de diagnostic est une frontière d’administration, pas un port de confort. Les protocoles de diagnostic doivent imposer une authentification mutuelle, des droits par opération et une temporisation des tentatives. Un code secret statique partagé entre tous les équipements est une dette de sécurité qui finit toujours par devenir une archive trouvable. Parfois il est même imprimé dans la documentation de maintenance, pour gagner du temps. Le temps gagne rarement la manche finale.

Les mises à jour OTA (Over The Air) doivent vérifier au minimum la signature, l’identifiant de cible, la version minimale acceptée, l’intégrité de l’image et la compatibilité matérielle. Le contrôle anti-retour est obligatoire : une image ancienne mais correctement signée peut réintroduire une vulnérabilité corrigée. Ce contrôle exige un compteur persistant, protégé contre la réinitialisation et pris en compte dans la stratégie de remplacement matériel.

La signature ne garantit PAS que le logiciel est sans défaut, que la logique de sécurité est correcte, ni que la disponibilité sera maintenue pendant l’installation. Elle garantit seulement l’origine autorisée et l’intégrité de l’objet signé, sous réserve que la clé privée reste secrète. Une signature sur un mauvais binaire produit un mauvais binaire authentique. La cryptographie n’a jamais été un service de relecture de code.

Les attaques à prévoir incluent :

• l’injection et le rejeu de trames sur un bus embarqué ;
• le brouillage radio ou la saturation d’une passerelle ;
• l’accès physique aux connecteurs de maintenance ;
• le remplacement d’un calculateur ou d’un capteur ;
• l’extraction de secrets depuis une mémoire non protégée ;
• la compromission de la chaîne de construction et de signature ;
• la falsification de position, de temps ou de données de capteurs externes.

La contre-mesure ne consiste pas à empiler des mécanismes cryptographiques. Elle consiste à associer chaque attaque à une conséquence physique, puis à vérifier la détection, le délai de réaction et l’état de repli. La cryptographie appliquée couvre les primitives ; ici, l’enjeu est surtout de ne pas leur demander de remplacer un mécanisme de sûreté.

Détection locale, mode dégradé et autorité de commande

La supervision doit distinguer erreur de communication, donnée incohérente et action malveillante. Une absence de message peut signaler une coupure de câble, un calculateur bloqué ou une saturation organisée. Une valeur plausible mais incompatible avec les autres capteurs est souvent plus dangereuse : elle traverse les contrôles de disponibilité et influence une décision réelle.

Chaque fonction critique doit disposer d’un budget temporel explicite : période nominale, délai de détection, nombre de messages manqués tolérés, délai d’entrée en mode dégradé et comportement de récupération. Sans ces valeurs, la logique de repli est une intention décorative. L’intention décorative est très populaire dans les matrices de risques, juste avant qu’un chronomètre réel ne demande son avis.

Le repli doit être local. Un contrôleur d’actionneur peut utiliser une source capteur secondaire, réduire une consigne ou maintenir une dernière valeur pendant une durée bornée. Il ne doit pas attendre une décision d’un serveur distant. Pour les fonctions aéronautiques, la séparation entre systèmes de mission, systèmes passagers et systèmes de contrôle doit empêcher une panne ou une compromission latérale de franchir la frontière vers les fonctions de vol.

Une redondance mal conçue multiplie les composants sans réduire le risque commun. Deux calculateurs exécutant la même image, alimentés par le même rail, recevant les mêmes données falsifiées et compilés par la même chaîne échouent ensemble. La diversité n’est justifiée que si elle supprime une cause commune identifiée : alimentation séparée, capteur de technologie différente, chemin logiciel distinct ou autorité de décision indépendante.

Exemple reproductible : surveiller un bus CAN sous Linux

Sur une plateforme de laboratoire Linux, vcan permet de tester la cadence et le filtrage sans équipement physique. Cette simulation ne valide ni le temps réel, ni les mécanismes électriques, ni la sûreté d’un véhicule. Elle valide seulement le comportement logiciel du traitement de trames.

# Installer les outils SocketCAN sur Debian ou Ubuntu.
sudo apt-get install can-utils

# Créer une interface CAN virtuelle, sans matériel raccordé.
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set vcan0 up

# Observer uniquement l'identifiant 0x180.
candump vcan0,180:7FF &

# Émettre une trame de test de 8 octets sur l'identifiant autorisé.
cansend vcan0 180#1122334455667788

# Supprimer l'interface après le test.
sudo ip link delete vcan0

Dans une passerelle réelle, un filtre noyau réduit la charge, mais ne doit pas devenir l’unique contrôle de sécurité. Le processus applicatif doit encore contrôler la cadence, la longueur, les bornes de valeurs et l’état de la fonction. Une trame CAN ne porte pas intrinsèquement un horodatage fiable ni une identité cryptographiquement vérifiée.

Clés, journaux, sauvegarde et reprise opérationnelle

Les clés de signature, certificats et secrets de diagnostic doivent avoir un propriétaire opérationnel, une durée de validité, une procédure de rotation et une procédure de révocation. Une révocation de certificat ne coupe pas les sessions déjà établies : la fonction concernée doit prévoir quand et comment elle réévalue la confiance. Cette règle vaut aussi pour un équipement hors ligne pendant plusieurs mois.

La rotation d’une clé de mise à jour exige une période de recouvrement : l’ancien matériel doit accepter la nouvelle chaîne, tandis que les équipements plus récents doivent pouvoir refuser une chaîne retirée. Supprimer l’ancienne clé avant la diffusion de la nouvelle rend une flotte hétérogène irrécupérable à distance. C’est une forme assez coûteuse de minimalisme.

Les journaux doivent enregistrer les transitions de mode, anomalies de bus, décisions de rejet, versions logicielles, échecs de vérification et événements de maintenance. Ils doivent être horodatés par une source surveillée, protégés contre l’effacement local et exportables après incident. Ils ne doivent pas contenir de clés, de jetons d’administration ou de données personnelles sans nécessité opérationnelle.

La reprise impose des images connues, signées et disponibles hors ligne, ainsi qu’une procédure de reprogrammation locale contrôlée. Une sauvegarde inaccessible sans l’infrastructure compromise n’est pas une sauvegarde, c’est un lien émotionnel avec un stockage distant. Les architectures de gestion de secrets et de racines de confiance relèvent aussi des principes présentés dans architecture cyber.

🐝 Ce qui arrive si on s’en passe

Sans cette architecture, le coût se paie hors du véhicule. Faute de séparation démontrable et de politique de trames vérifiée par une autorité indépendante, une anomalie constatée après incident reste indécidable : rien ne permet de distinguer un capteur défaillant d’une trame injectée, et l’analyse se termine sur une hypothèse. Faute d’inventaire fiable des versions embarquées et d’identifiant de cible contrôlé, le périmètre affecté par un défaut ne peut pas être délimité : la correction s’applique à toute la flotte ou à personne, et passe par un atelier plutôt que par une diffusion maîtrisée. Faute de budgets temporels écrits, aucun essai ne peut prouver qu’un état sûr est atteint dans le délai annoncé, ce qui rend la démonstration de conformité invérifiable et reporte la charge sur l’exploitation.

🦫 Explication de la marmotte 🍫

Dans une voiture ou un aéronef, des ordinateurs lisent des capteurs et envoient des ordres à des équipements physiques. Certains ordres agissent sur le freinage, la direction, la propulsion ou les informations de vol. Si un ordinateur tombe en panne, reçoit un faux message ou exécute un programme modifié, il peut envoyer un ordre incorrect ou ne plus envoyer d’ordre du tout.

La sécurité consiste donc à séparer les parties connectées à des réseaux extérieurs des parties qui commandent les équipements physiques. Les messages autorisés sont définis à l’avance : origine attendue, direction, fréquence et contenu acceptable. Quand un message arrive trop souvent, contient une valeur incohérente ou cesse d’arriver, le système doit détecter le défaut dans un délai défini.

Chaque fonction critique prévoit alors un comportement réduit : utiliser une mesure de secours, limiter une commande ou placer l’équipement dans un état moins dangereux. Cette décision doit être prise localement, sans attendre un réseau extérieur.

Les mises à jour de programme sont vérifiées avant installation afin de refuser une version modifiée ou trop ancienne. Les clés servant à cette vérification sont protégées et remplacées selon un calendrier. Enfin, les événements anormaux sont enregistrés et une méthode de restauration locale reste disponible. La sécurité informatique réduit les attaques, mais elle ne prouve pas que la fonction physique est correcte : cette preuve vient de l’analyse de sûreté, des essais et de l’architecture de repli.

À lire aussi

• 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 les satellites et les liaisons montantesSécurité spatiale des satellites, des liaisons montantes et de leur surface d'attaque orbitale.
• Sécuriser la signalisation ferroviaire connectéeArchitecture de sécurité pour la signalisation et les systèmes de contrôle ferroviaires connectés.
• Surveiller les usages anormaux d’un HSMGuide pratique pour journaliser, centraliser et détecter les usages anormaux des clés protégées par un module cryptographique matériel.

Pages voisines

La citent

• Méthodes formelles TLA+ et Coq (Rocq), où elles valent leur coût

Comment concevoir la sûreté cyber automobile et aéronautique

Elle cite

• ⇄Lien dans les deux sens :Brouillage et leurrage GNSS, détection, OSNMA et repli du temps
• ⇄Lien dans les deux sens :Navigation inertielle et filtre de Kalman quand le GNSS est brouillé
• Signer et vérifier les artefacts de build

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