Sécuriser l’accès des flottes de véhicules connectés

Un véhicule moderne cumule les fonctions d’un terminal mobile, d’un réseau industriel et d’un système embarqué qui peut déplacer plusieurs tonnes. Le contrôle d’accès distant, le démarrage sans clé et la télématique de flotte ajoutent des identités, des interfaces et des privilèges à une architecture dont le réseau interne n’a pas été conçu pour résister à un adversaire.

→ Lire l’explication complète de la marmotte

Bus CAN et calculateurs sans authentification

Le bus CAN (Controller Area Network) relie des calculateurs électroniques, appelés ECU (Electronic Control Unit), qui échangent des trames courtes identifiées par un arbitre de message. Le protocole arbitre les priorités et détecte des erreurs de transmission. Il n’authentifie ni l’émetteur ni le contenu. Une trame portant le bon identifiant est traitée comme légitime si le calculateur destinataire l’accepte.

Cette propriété n’est pas un bug oublié dans une cave. Le CAN a été conçu pour des réseaux physiquement confinés, avec des contraintes de latence, de coût et de fiabilité. Le compromis historique est net : obtenir un réseau déterministe et peu coûteux, au prix de l’absence de confiance cryptographique entre calculateurs. Ce compromis reste acceptable uniquement si les frontières qui donnent accès au bus sont strictement contrôlées. Dans un véhicule connecté, elles ne le sont plus par défaut.

Les fonctions de contrôle d’accès aggravent l’enjeu. Une commande de verrouillage, une autorisation de démarrage, une ouverture de coffre ou une immobilisation à distance ne sont pas des événements métier anodins. Elles peuvent dépendre de plusieurs calculateurs, d’une clé numérique, d’une application mobile et d’un service de flotte. Une injection sur un segment CAN pertinent peut contourner une décision prise correctement plus haut dans la pile.

Segmenter les domaines est donc la première décision d’architecture. Le domaine télématique, l’infodivertissement, le diagnostic et les fonctions de propulsion ou de carrosserie ne doivent pas partager un bus plat. Une passerelle centrale doit filtrer les identifiants CAN, les directions de flux et les cadences autorisées. Elle doit aussi appliquer un état de session pour les opérations sensibles. Un filtre qui laisse passer toute trame connue parce qu’elle est connue ne filtre rien, il fait de la décoration réseau.

Le CAN FD (Controller Area Network Flexible Data-Rate) augmente la capacité de transport, pas la sécurité intrinsèque. Ajouter de la bande passante à un réseau sans authentification permet surtout de faire circuler plus vite les mêmes mauvaises idées. Les mécanismes d’authentification de message, lorsqu’ils sont disponibles dans l’écosystème véhicule, doivent être réservés aux commandes à impact physique ou patrimonial. Les appliquer à chaque trame d’un réseau ancien sans étude de latence, de synchronisation et de gestion de clés produit souvent un système qui échoue au démarrage, ce qui est une façon coûteuse de protéger une voiture immobile.

Ports de diagnostic, UDS et accès atelier

Le port OBD-II (On-Board Diagnostics II) expose un accès physique destiné au diagnostic et à la maintenance. Il peut donner accès à plusieurs réseaux internes selon le câblage et la passerelle du véhicule. Le protocole UDS (Unified Diagnostic Services) transporte notamment des opérations de lecture, de codage, de programmation et de changement de session. Ces services sont nécessaires en atelier. Ils deviennent une surface d’attaque dès qu’un appareil non autorisé peut atteindre le port.

L’attaque documentée la plus banale consiste à brancher un équipement sur le port de diagnostic, écouter le trafic puis rejouer ou injecter des messages. La difficulté dépend du véhicule, mais la défense ne doit pas dépendre de la difficulté supposée. Le matériel de diagnostic générique est bon marché, disponible et ne demande aucune cérémonie mystique autour d’un oscilloscope.

La recommandation est tranchée : traiter le diagnostic comme une administration à privilèges, pas comme une prise de courant un peu bavarde. Une passerelle de diagnostic doit imposer une authentification mutuelle par certificats, limiter les services UDS selon le rôle, journaliser chaque session et imposer une expiration courte des autorisations d’atelier. L’accès aux fonctions de programmation doit être séparé des fonctions de lecture de défauts.

Un code secret statique de déverrouillage de diagnostic ne suffit pas. Il finit dans un outil, une documentation, une image disque ou une conversation de support. Le mécanisme doit utiliser un défi aléatoire, une réponse liée au véhicule et au contexte de session, puis une autorisation cryptographiquement vérifiable. La clé racine ne doit jamais être exportable depuis le calculateur ou l’outil d’atelier. Un HSM (Hardware Security Module) ou un composant matériel sécurisé embarqué sert précisément à empêcher cette extraction, pas à faire joli dans une matrice de conformité.

Le contrôle physique reste indispensable. Un verrou de port, un emplacement non accessible depuis l’habitacle et une détection d’ouverture réduisent la fenêtre d’attaque, sans remplacer l’authentification. Une serrure protège contre l’accès direct ; elle ne transforme pas un protocole permissif en protocole sûr.

Connectivité cellulaire et pivot vers le véhicule

La TCU (Telematics Control Unit) assure la connectivité cellulaire, les mises à jour, la localisation et les services distants. Pour une flotte, elle relaie souvent les ordres de verrouillage, les droits conducteur, les données de maintenance et la position. Cette centralisation est rentable, mais elle concentre aussi la capacité de nuisance.

Les compromissions documentées de services télématiques ont montré le chemin classique : un service exposé sur le réseau mobile ou un composant de connectivité vulnérable est compromis, puis l’attaquant cherche un pivot vers les réseaux véhicule. La séparation entre processeur applicatif et passerelle automobile doit donc être matérielle ou au minimum fortement cloisonnée. Une règle de pare-feu logicielle dans le même système compromis n’est pas une frontière, c’est une suggestion polie.

Le canal distant doit utiliser TLS (Transport Layer Security) avec authentification mutuelle. Le véhicule vérifie le certificat du service, le service vérifie un certificat propre au véhicule, et la clé privée du véhicule reste dans un composant non exportable. Une PKI (Public Key Infrastructure) doit émettre des certificats distincts par véhicule, par environnement et, si nécessaire, par fonction. Réutiliser un certificat de flotte pour tous les véhicules transforme la révocation d’un véhicule en opération de chirurgie collective.

Les commandes distantes doivent être signées, horodatées, associées à un identifiant de véhicule et protégées contre le rejeu par un compteur persistant ou un nonce (nombre utilisé une seule fois). La signature doit couvrir l’action, le véhicule cible, la durée de validité et le contexte d’autorisation. Sans cela, une commande légitime interceptée peut être rejouée après révocation d’un conducteur ou d’un opérateur.

La révocation reste le piège classique. Révoquer un certificat dans le système central n’annule pas une session déjà établie ni une commande déjà mise en file. Les jetons d’accès doivent être courts, les sessions doivent pouvoir être interrompues par le véhicule, et les autorisations sensibles doivent être réévaluées au moment de l’exécution. La gestion des identités, détaillée dans les fondations IAM, s’applique ici avec une contrainte supplémentaire : le véhicule peut être hors ligne au pire moment.

Architecture de contrôle d’accès pour une flotte

La bonne architecture sépare trois décisions : identifier l’acteur, autoriser l’action, puis exécuter la commande dans le véhicule. L’application mobile, le portail flotte, l’outil atelier et l’interface d’urgence ne partagent pas les mêmes privilèges. Une identité d’opérateur de flotte ne doit pas devenir, par magie administrative, une identité capable de reprogrammer un calculateur.

L’autorisation doit être contextuelle : véhicule ciblé, rôle, période de location, état du véhicule, zone géographique si cette règle est justifiée, et nature de l’action. Un ordre de déverrouillage peut être acceptable à proximité du véhicule. Une désactivation d’immobilisation ou une programmation de clé exige une approbation forte, une traçabilité et souvent une présence physique.

Les API (Application Programming Interface) de flotte constituent une frontière majeure. Elles doivent imposer des jetons liés à un client, limiter les débits, journaliser les commandes et isoler chaque tenant. L’identifiant de véhicule ne doit jamais suffire à autoriser une action. Une API qui accepte un identifiant prévisible et un jeton surdimensionné est un annuaire de véhicules avec bouton télécommande, ce qui réduit l’expérience utilisateur à une expérience judiciaire.

Le plan de contrôle central ne doit pas disposer d’un accès brut au CAN. Il doit exprimer des intentions métier limitées, par exemple unlock_doors ou enable_start, que la TCU traduit selon des règles locales. La passerelle véhicule valide alors la fraîcheur, l’autorisation et l’état nécessaire avant d’émettre des messages vers le domaine concerné. Cette séparation réduit le rayon d’explosion d’une compromission cloud, sujet également lié aux choix décrits dans l’architecture cyber.

Exemple de filtrage CAN en laboratoire

Avant toute intégration, tester les règles sur une interface virtuelle Linux évite de découvrir une erreur de filtrage sur un véhicule réel. L’exemple suivant utilise can-utils et une interface vcan0 pour vérifier qu’une règle n’accepte qu’un identifiant prévu. Il ne pilote aucun matériel.

# Créer une interface CAN virtuelle, réservée au laboratoire.
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# Observer uniquement l'identifiant 0x123 avec un masque exact.
candump vcan0,123:7FF &

# Trame attendue : elle doit apparaître dans la capture.
cansend vcan0 123#1122334455667788

# Trame hors politique : elle ne doit pas apparaître dans la capture filtrée.
cansend vcan0 321#AABBCCDDEEFF0011

Ce test valide seulement une sélection d’identifiants. Il ne valide ni l’origine d’une trame, ni l’autorisation d’une commande, ni la résistance à un rejeu. Confondre filtrage et authentification est un classique aussi tenace que le mot « intelligent » collé sur un objet qui possède un modem.

Clés, supervision et reprise opérationnelle

Chaque véhicule doit posséder une identité cryptographique unique, provisionnée lors de la fabrication ou de l’enrôlement contrôlé. Les clés de signature et d’authentification doivent être séparées par usage. Une KEK (Key Encryption Key) protège les clés de données ou de session, tandis qu’une clé d’authentification ne doit pas servir à chiffrer des journaux par commodité. La séparation des usages limite les conséquences d’une extraction ou d’une erreur de code.

La rotation exige une période de chevauchement : le véhicule doit accepter l’ancienne et la nouvelle chaîne de confiance pendant une fenêtre bornée, puis rejeter l’ancienne. Une rotation sans inventaire des versions logicielles et des véhicules hors ligne provoque des pertes d’accès. À l’inverse, accepter indéfiniment l’ancienne clé transforme la rotation en décoration comptable.

La supervision doit corréler les événements du portail, du service télématique et du véhicule : échecs d’authentification, commandes rejetées, bascules de session, tentatives de diagnostic et écarts d’horodatage. Les journaux doivent être exportés lorsque le réseau est disponible, mais une mémoire locale protégée est nécessaire pour les incidents hors couverture.

Le mécanisme ne garantit pas la disponibilité cellulaire, la sécurité physique d’une clé déjà volée, ni la sûreté fonctionnelle du véhicule. La sécurité d’accès ne remplace ni la validation des logiciels embarqués, ni le cloisonnement réseau, ni les procédures d’intervention d’urgence. Les exigences de résilience doivent être conçues avec les équipes de sûreté et d’exploitation, pas ajoutées lors de la dernière réunion où quelqu’un découvre que les véhicules roulent parfois hors réseau.

🐝 Ce qui arrive si on s’en passe

Sans ces protections, une intrusion ne se limite pas à un geste ponctuel : un accès diagnostic non authentifié permet d’enrôler une clé supplémentaire dans l’immobiliseur, et cette clé reste valide après le départ de l’attaquant tant que la liste des clés appairées n’est pas auditée. Les trames injectées faussent aussi les données remontées à la flotte (kilométrage, défauts, position), si bien que la planification de maintenance et la facturation reposent sur des valeurs fabriquées. Faute d’identité unique par véhicule et de journal local protégé, une ouverture ou un démarrage ne peut être rattaché ni à un opérateur ni à une commande signée. Il devient alors impossible de distinguer une panne, une erreur de manipulation et un acte malveillant, ce qui bloque l’enquête et la décision de révoquer le bon accès.

🦫 Explication de la marmotte 🍫

Un véhicule connecté contient plusieurs petits ordinateurs qui échangent des messages pour gérer les portes, le démarrage, les capteurs et la maintenance. Historiquement, ces messages ont été conçus pour circuler vite dans un véhicule fermé. Ils ne vérifient pas toujours quel ordinateur les a envoyés. Si une personne atteint le réseau interne, elle peut donc tenter d’envoyer des messages qui paraissent normaux.

Deux entrées sont particulièrement surveillées. La première est la prise utilisée par les garages pour lire les défauts et modifier certains réglages. La seconde est l’équipement qui relie le véhicule au réseau mobile et aux services de gestion de flotte. Une faiblesse sur cet équipement peut permettre de chercher un passage vers les fonctions du véhicule.

La défense commence par séparer les réseaux internes : le matériel connecté au réseau mobile ne doit pas pouvoir commander directement les fonctions sensibles. Chaque demande à distance doit identifier son auteur, préciser le véhicule concerné, expirer rapidement et ne pouvoir être réutilisée. Le véhicule vérifie ensuite cette demande avant d’agir.

Les clés numériques servant à prouver les identités doivent être différentes pour chaque véhicule, conservées dans un composant protégé et remplacées régulièrement. Si une clé est compromise, elle doit pouvoir être retirée sans bloquer toute la flotte. Enfin, les événements doivent être enregistrés afin de détecter une tentative inhabituelle, même lorsqu’un véhicule est temporairement sans réseau.

Pages voisines

La citent

Sécuriser l'accès des flottes de véhicules connectés

Elle cite