La sécurité informatique des véhicules est un enjeu majeur des véhicules automobiles modernes. Cet enjeu est pris en compte dès la conception des systèmes embarqués.

Le véhicule connecté est contrôlé par des calculateurs embarqués et interconnectés (ECU). À travers ces calculateurs, le véhicule moderne offre des fonctionnalités nouvelles qui améliorent la qualité de conduite et renforcent la sécurité du passager. Cependant, les constructeurs sont confrontés à des problématiques de sécurité informatique induits par des dispositifs tels que prise OBD, Bluetooth, Wi-Fi, 3G/4G, RFID, clé USB, CD, très courants sur les véhicules modernes. Chacun de ces dispositifs risquerait d'être une porte ouverte pour des hackeurs souhaitant accéder aux différents calculateurs de bord.

En 2015, les chercheurs américains et Charlie Miller exploitent la vulnérabilité du système multimédia et prennent le contrôle des fonctions de sécurité et de confort (freins, volant, alimentation électrique du moteur, essuie-glaces) et de divertissement (volume sonore de l’autoradio). Cette démonstration effectuée à partir d’un ordinateur externe distant met en valeur les faiblesses de sécurité des applications embarquées sur les véhicules. Ces dispositifs sont chargés d'échanger des informations entre le véhicule et/ou le conducteur et le système informatique du constructeur ainsi que du processus d’authentification et le chiffrement des codes embarqués.

Pour anticiper et éviter ces cyberattaques, l’industrie des véhicules connectés et/ou autonomes et les équipementiers s’associent de plus en plus avec des spécialistes de la sécurité pour trouver des solutions ou contre-mesures. Les enjeux économiques, technologiques et sociétaux sont à la mesure de ce défi.

Évaluation et analyse de risques Thales et le Groupe PSA ont développé une analyse des risques qui permet d’identifier les risques et contre-mesures de sécurité avant toute spécification.

Elle se déroule en 5 étapes clés, issues de la méthode d’ Expression des besoins et identification des objectifs de sécurité (EBIOS) de l’ANSSI et de la méthode Threat, Risk, Vulnerability, Analysis (TVRA) de l’ETSI suivant le schéma suivant :

vignette|gauche|Schéma synthétique de la méthode.

Étape 1 : Étude du contexte Étape 2 : Expression des besoins de sécurité Étape 3 : Étude des menaces Étape 3a : Évaluation de la vraisemblance de la menace Étape 3b : Évaluation de l'intensité de la menace Étape 3c : Évaluation de l'impact de la menace sur la cible Étape 3d : Évaluation de l'impact global de la menace) Étape 4 : Identification des objectifs de sécurité Étape 5 : Détermination des exigences de sécurité

Le croisement de ces deux méthodes permet d'obtenir à la fois une évaluation des risques sur les données en cas d’atteinte en Disponibilité, Intégrité, Confidentialité et Preuve (DCIP) et une vision technique sur les composants de l’architecture se fondant sur une évaluation complète et précise.

+ Évaluation des risques EBIOS Gravité des évènements Échelle Vraisemblance des menaces Échelle 1 Faible 1 Peu probable 2 Modéré 2 Rare3 Majeur 3 Probable 4 Critique 4 Très probable

L’évaluation des risques EBIOS s’obtient en croisant la gravité des évènements avec la vraisemblance des menaces.

Vraisemblance des menaces Gravité des évènements Peu probable - N=1 Rare - N=2 Probable - N=3 Très probable - N=4 Faible - N=1 Modéré - N=2 Modéré & Probable Majeur - N=3 Critique - N=4 Ex. : Une gravité N=2 et une vraisemblance N=3 donnent un EBIOS Risk "Modéré et Probable"

Piratage de véhicules

Prise OBD et BusCan

Les calculateurs (ECU) d'un véhicule sont connectés à un bus où tous les messages sont diffusés à tous les nœuds connectés (ECU) et à l’ordinateur de bord. Ce bus CAN est utilisé sur la grande majorité des véhicules et accessible via le port OBD-II, obligatoire sur tous les véhicules (Depuis 1996 aux États-Unis, et depuis 2001 et 2004 dans l’Union européenne pour les voitures essence et diesel.

Ce port est normalisé pour récupérer les données de diagnostic et les informations en provenance des calculateurs d’un véhicule. Des dongles OBD et des lecteurs de code OBD sont disponibles et peuvent être achetés à distance. Mais lorsque les données sont diffusées, le bus CAN n'assure pas la confidentialité et l'authentification de la trame de données CAN, ouvrant la voie à un adversaire malveillant pour facilement écouter les données ou lancer une attaque de rejeu.

En aout 2017, des chercheurs de l’université de Milan et des Canadiens de LynkLayer Labs, de la société TrendMicro, ont confirmé la vulnérabilité du protocole de communication interne: le standard CAN. Lors d’erreurs de communication, le système renouvelle l’envoi du message entre les 2 ECU. Mais si un composant envoie trop de message, il est coupé du circuit CAN pour éviter que cela se propage sur d’autres éléments. Les chercheurs ont réussi à le déclencher, de manière artificielle, en créant une attaque par déni de service, qui oblige le système à désactiver certains éléments de la voiture (ABS, fermeture des portes, airbags) en utilisant une carte Arduino reliée à la prise OBD.

Dans un environnement de simulation, des tests ont été faits par T. Hoppe, S. Kiltz et J. Dittman ". Ils ont modifié quelques lignes de code sur des ECUs du sous-réseau Comfort CAN. Suivant une condition de vitesse, le code ouvre la fenêtre du conducteur, même si l'ECU activant la fenêtre indique qu'aucun bouton d'ouverture de fenêtre n'est activé. Pour cela, ils ont utilisé un PC raccordé au port ODB-II et au bus CAN. Une ECU reprogrammé peut aussi jouer ou rejouer des trames précédemment enregistrées et ainsi envoyer des instructions à d'autres ECU, masquant ainsi les sources légitimes de ces instructions. K. Nilsson et U.E. Larson " le démontrent aussi dans leur étude et indiquent que le réseau bus CAN ne dispose pas de protection suffisante contre des attaques et introduisent le concept de virus automobile se déclenchant dans des conditions spécifiques.

Cependant, les ECU ciblés peuvent ne pas être sur le même segment de bus que le point d'entrée de l'attaquant. K. Koscher» a pu résoudre ce problème en ciblant et en reprogrammant les calculateurs agissant comme passerelles entre les bus, permettant à un ECU situé sur un bus CAN non critique d'envoyer des trames sur un bus CAN critique. Par conséquent si un attaquant ne contrôle qu'un seul nœud du réseau, les architectures et les protocoles actuels lui permettent de prendre le contrôle total sur tout autre ECU du véhicule. On peut étendre de telles attaques à presque toutes les fonctions d'une voiture, le fuzzing peut-être particulièrement efficace.

Deux chercheurs en sécurité, J. Vazquez Vidal et A. G. Illera" sont allés plus loin et ont présenté lors de la conférence sur la sécurité Black Hat Asia 2014: le « CAN Hacking Tool ». Il s’agit d’un petit appareil qui accède au réseau CAN d’une voiture et qui permet de la pirater. Ce kit coûte moins de mais prend le contrôle total d’une voiture : fenêtres, phares, direction, freins, sans oublier les fonctions d’ouverture et de démarrage. « Cela ne prend que quelques minutes pour le brancher », déclare Vazquez Vidal, en ajoutant: « Nous pourrions attendre une minute ou un an ensuite, puis passer à l’acte à distance ». Le véhicule peut être piégé sans que l’on s’en rende compte (lors d’une révision, d’un prêt, d’un essai). À ce moment, les attaquants ont un backdoor installé et disponible. Ces travaux ne seront pas publiés afin de ne pas aider de potentiels pirates. Mais de telles révélations permettent d'amener les constructeurs à réfléchir sur l'importance de protéger l'accès du bus CAN.

Il reste cependant difficile d’accéder au port OBD-II, voire de modifier physiquement la structure du bus CAN d’un véhicule, pour un non-initié. On ne peut que suggérer que les attaques décrites précédemment impliquent que l'attaquant ait déjà un accès physique sur le bus. De tels scénarios d'attaque impliquent donc une violation de sécurité antérieure lorsque l'attaquant avait pu ouvrir le véhicule et brancher un dispositif sur le réseau.

L’accès au bus est obtenu à l’aide d' (Voir le tableau ci-dessous) qui sont programmés via des ordinateurs sous Windows, ou tout simplement en raccordant un PC directement sur le port OBD. Le logiciel de l’ordinateur portable interroge ou programme les calculateurs (Via l’API standard). Voici une liste non exhaustive des outils de diagnostic par constructeur.

+ Outils de diagnostic par constructeurs Constructeur Nom de l'outil

Constructeur Nom de l'outil

Constructeur Nom de l'outil Audi/Volkswagen VAS5052 Hyundai KIA HI-DS Scanner Gold Toyota/Lexus Intelligent TesterII Ford FoCOM Chrysler StarScan Nissan Consilt Benz Benz XP-Star Diagnosis Peugeot Citroën

BMW BMW ICOM A+B+C Honda HDS

Ainsi, un attaquant peut attendre le passage chez le constructeur, pour une révision, par exemple, car ce type d’ordinateur a aussi un accès à Internet. Théoriquement, il pourrait infecter l’ordinateur portable du garage avec un logiciel malveillant et l’utiliser pour manipuler le processus de programmation" Pour vérifier les fonctions des calculateurs pendant un processus de diagnostic, ces outils diffusent des trames de données CAN mais sans chiffrement et authentification pour forcer le contrôle de l'ECU.

Bluetooth

Le Bluetooth est devenu une norme pour la prise en charge des appels mains libres dans les véhicules grand public vendus par tous les principaux constructeurs automobiles. En usage normal, les appareils de classe 2 utilisés dans les applications automobiles ont une portée de , mais d'autres ont démontré que cette gamme peut être étendue par des amplificateurs et antennes directionnelles. L'accès se fait par synchronisation de 2 appareils (par appairage) documenté par K. Haataja et K. Hypponen. L’appariement est basé sur un échange de code secret après une identification par code PIN.

On peut lancer la détection automatique des appareils à proximité. Mais le propriétaire de l’appareil ciblé est averti que l’on cherche à s’appairer avec lui et la mise en relation doit se faire avec un mot de passe convenu avec le visiteur. Mais il arrive que les appareils ne soient pas sécurisés et que la fonction de sécurité soit désactivée. La machine est donc accessible sans une validation par le propriétaire. À ce stade, l’accès au téléphone est complet.

Ollie Whitehouse a développé en 2003, un outil, RedFang, qui détecte les appareils dont la fonction « non détectable » est activée : le but étant de trouver l’adresse attribuée à la machine, ce qui reste considérable. Mais ce même ingénieur, en couplant RedFang à Bluesnif indique pouvoir détecter l’adresse en environ 90 minutes.

Le tableau suivant indique les appareils trouvés : GPS, télématique, diagnostic. Cette étude tient compte de la vétusté des appareils Bluetooth disponibles sur les voitures. Les véhicules les plus anciens vont rester encore quelques années sur route. Le risque d'attaque est bien réel sur les appareils les plus anciens.

En faisant le même travail que Madeline Chea : localiser les connexions Bluetooth environnantes et récupérer les identifiants réseau (comme l'adresse MAC) uniques de l'appareil. Failles sur des systèmes comme Google, Android, IOS ou linux. L’exploitation de ces vulnérabilités pourrait permettre à un pirate d’exécuter du code malveillant sur le terminal de la victime, d’intercepter les communications par le biais d’une attaque Man in the middle ou même de prendre le contrôle de l’appareil.

S. Checkoway. a réussi à obtenir l’accès au système d’exploitation de l’ECU télématique et identifier le programme particulier de la fonctionnalité Bluetooth. Il a trouvé une commande spécifique pour la configuration Bluetooth. Ainsi, un autre périphérique Bluetooth peut exploiter cette vulnérabilité.