Sécurité informatique des véhicules

Un article de Wikipédia, l'encyclopédie libre.

La sécurité informatique des véhicules est un enjeu majeur des véhicules autonombiles 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 ODB, Bluetooth, Wi-Fi, 3G/4G, RFID, clé USB, CD, très courants sur les véhicules modernes. Chacun de ces dispositifs risquerait d'ere une porte ouverte pour des hackeurs souhaitant accéder aux différents calculateurs de bord.

En 2015, les chercheurs américains Chris Valasek (en) 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[modifier | modifier le code]

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[1].

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)[2] de l’ETSI suivant le schéma suivant :

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 TVRA (en) complète et précise[2].

Évaluation des risques EBIOS[1]
Gravité des évènements Échelle Vraisemblance des menaces Échelle
1 Faible 1 Peu probable
2 Modéré 2 Rare
3 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[modifier | modifier le code]

Prise ODB et BusCan[modifier | modifier le code]

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[3].

Ce port est normalisé pour récupérer les données de diagnostic et les informations en provenance des calculateurs d’un véhicule. Le dongle 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[4].

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[5].

Dans un environnement de simulation, des tests ont été faits par T. Hoppe, S. Kiltz et J. Dittman "[6]. 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[6]. K. Nilsson et U.E. Larson "[7] 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»[8] 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[3].

Deux chercheurs en sécurité, J. Vazquez Vidal et A. G. Illera"[9] 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 20 dollars 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 »[9]. 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[10].

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[11].

L’accès au bus est obtenu à l’aide d'outils de scan (en) (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 SAE J2534 (en) 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 XS Evolution Multiplexer
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"[3] 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[4].

Bluetooth[modifier | modifier le code]

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 10 mètres, 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[12]. 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[13].

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[13].

L’étude de Madeline Cheah montre comment effectuer la recherche et la détection d'appareils Bluetooth équipant les voitures. En utilisant l’outil hcitool[14], cette étude a été faite sur 28 parcours en voiture d’une durée de 20 à 60 min. Elle a réussi à différencier les équipements Bluetooth de la voiture des autres appareils (comme les smartphones, les tablettes ou ordinateurs portable) en fonction des caractéristiques techniques de l’appareil. Sur les 122 véhicules diffusant leurs adresses MAC, 31 diffusaient leur nom (parfois le nom personnel), 7 diffusaient des services proposés par Bluetooth : profil main libre (HPF) (en), profil de port série (SPP) (en), profil Object Push Profile (OPP) (en) ou le profil PBAP (en) (PhoneBookk Access Profile), 3 diffusaient la plaque d’immatriculation (ce qui permet d’avoir des informations sur le possesseur), 3 indiquaient un dispositif avec une connexion au réseau interne du véhicule. Le tableau suivant indique les appareils trouvés : GPS, télématique, diagnostic[15]. 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[15].

En 2017, la société de sécurité Armis a découvert 8 failles dans le protocole Bluetooth, baptisé BlueBorne[16]. 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[17]

S. Checkoway[18] 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é. Mais avant pour cela, il faut obtenir l’adresse MAC de la voiture et coupler son propre appareil avec la voiture. L’outil Bluesniff[19] peut être utilisé, ou un radio-logiciel basé sur USRP[18].

L'article de Fahmida Y. Rashid dans eWeek[20] relate les essais d'une équipe de chercheurs dirigée par Stefan Savage, professeur d'informatique à l'Université de Californie à San Diego et de Tadayoshi Kohno, professeur adjoint d'informatique à l'Université de Washington. L'équipe a trouvé une vulnérabilité dans la façon dont Bluetooth a été implémenté, ce qui leur a permis d'exécuter du code malveillant en utilisant une application installée sur un smartphone qui avait été "couplé" avec le système Bluetooth de la voiture. Ils ont pu contrôler les freins, les serrures et l'affichage informatisé du tableau de bord de la voiture en accédant à l'ordinateur de bord

Cela implique que l'on peut exploiter les vulnérabilités des "connexions entre le port OBD et un terminal Bluetooth[15].

Wifi[modifier | modifier le code]

Présent depuis peu sur les véhicules, le WiFi a une utilisation restreinte dans la voiture. Une voiture en mouvement ne peut s'associer à des bornes physiques. Mais, un spot Wifi peut permettre d'accéder au réseau mobile à plusieurs personnes et pas seulement au détenteur d'une carte 3G/4G.

En 2016, des chercheurs de Keen Security Lab de Tencent ont pris le contrôle d'une Tesla Model S. Il faut que la voiture soit connectée à un hotspot wifi illicite pour prendre le contrôle du bus CAN et que le navigateur web embarqué soit utilisé. L'attaque a été confirmée par le constructeur[21].

Le chercheur Samy Kamkar a mis au point un boitier qui peut être placé sur la voiture et qui créé un hotspot wifi illicite. Ce boitier se nomme OwnStar. Il permet d'intercepter les identifiants et ainsi d'accéder à des fonctions comme la localisation ou le déverrouillage des portes. Le boitier renvoie les informations sur le réseau mobile au pirate. Samy Kamkar l'a fait fonctionner sur des voitures GM, BMW, Mercedes et Chrysler. "Dès que vous êtes sur mon réseau et que vous ouvrez l'application, j'ai pris le relais", explique Kamkar[22].

Mitsubishi a eu l'idée d'aller plus loin dans l'utilisation du Wifi. En créant une application sur smartphone qui permet de contrôler la voiture via le Wifi. Cette application surveille l'état de la voiture, déverrouille les portes, allume le chauffage ou la climatisation. Une équipe de chercheurs en sécurité de PenTestPartners a réussi à déchiffrer le mot de passe prédéfini sur leur Mitsubishi Outlander et à faire exécuter un certain nombre de tâches nécessitant normalement une application correctement authentifiée, y compris l'activation du système de climatisation, le changement du calendrier de chargement pour le système de batterie enfichable et la désactivation de l'alarme antivol.

RFID et Keyless[modifier | modifier le code]

Exemple de clé d’accès aux voiture

Les dispositifs d'immobilisation de véhicule RFID sont presque omniprésents dans les automobiles modernes. Ces systèmes incorporent une étiquette RFID dans une clé ou un porte-clés et un lecteur à proximité de la colonne de direction de la voiture. Ils empêchent la voiture de fonctionner à moins que la clé correcte (telle que vérifiée par la présence de la bonne étiquette RFID) soit présente.

Ces systèmes de clés de voiture utilisent le système de code tournant.

Flavio D. Garcia étudie la vulnérabilité des systèmes de commande à distance. Avec une équipe de chercheurs, il a proposé des outils pour l'analyse des protocoles RFID[23] RFID. Outils facilitant leur écoute clandestine et les logiciels et matériels écrit en open source et open design. Il avait contacté Volkswagen en 2012 sur le possible détournement du système RFID Magamos Crypto. En 2016, il fabrique un module radio[24]. Mais la technique demande d'avoir la clé du récepteur RFID de la voiture. En extrayant le firmware, ils se sont aperçus que cette clé est la même sur des millions de voitures.

Exemple d’un boitier qui intercepte et amplifie le signal d’une clé de voiture vers un second boitier proche de la voiture pour l’ouvrir et la démarrer aux dépens du conducteur.

Samy Kamkar, de nouveau, a mis au point un boitier: le RollJam[25]. Capable d'intercepter et d'enregistrer les commandes d'une clé. Le principe: lors de la demande de fermeture de la voiture par le propriétaire, le boitier RollJam brouille le signal et enregistre le code envoyé par la clé. Pour le propriétaire, il peut s'agir d'un mauvais contact et appuie de nouveau sur le bouton de fermeture. Le boitier brouille de nouveau le signal, intercepte et enregistre le nouveau code, mais envoie à la voiture le premier code intercepté. Le hacker a en sa possession un code qu'il peut utiliser quand il le voudra.

Les journalistes d'Auto-Plus ont mis en pratique l'amplification de signal[26]. La clé Keyless permet d'ouvrir et de démarrer une voiture sans action du conducteur. Lorsqu'on s'éloigne de la voiture, elle se ferme automatiquement. Il suffit pour cela de deux boitiers amplificateurs. L'un proche du propriétaire l'autre proche de la voiture. Lorsque le signal est récupéré par le premier, le signal est envoyé au second qui active l'ouverture des portes et permet le démarrage de la voiture. Même si le hacker s'éloigne du signal de la carte ou de l'amplificateur, la voiture ne s'arrête pas. Car pour des raisons de sécurité, la voiture ne s'arrêtera pas à la perte du signal de la clé. Afin de ne pas générer d'accident. L'ADAC (Allgemeiner Deutscher Automobil-Club) a mis au point le même type d'attaque en .

Le plus étonnant est la vidéo de la police de West Midlands[27], au Royaume-Uni. Qui a diffusé des images de criminels volant une voiture en relayant un signal de la clé à l'intérieur de la maison, à la voiture dans l'allée.

Aurélien Francillon et son équipe du Département d'Informatique de l'école polytechnique fédéral de Zurich[28] a démontré dans son étude de la vulnérabilité du système PKES (Passive Keyless Entry and Start) dans certaines voitures.

Mobile 3G/4G et Internet[modifier | modifier le code]

Pour une connectivité étendue, la voiture est équipée d’une interface de téléphone portable. Elle est utilisée pour des fonctions internet-données (navigation) mais aussi vocales (service d’assistance basé sur la localisation ou simplement pour passer des appels téléphoniques). De plus des applications, prenant en charge l'environnement de voiture connectée sont désormais vendues sur des marchés d'applications tels que Google Play et l'Apple App Store, par exemple: Send To Car, UVO Smart Control et BMW ConnectedDrive[11].

C'est durant la conférence sur la sécurité informatique Blackhat USA 2015[29] que Charlie Miller et Chris Valasek ont présenté le piratage d'une Jeep Chrysler. En passant par le réseau mobile, ils ont pu accéder au bus CAN depuis leur ordinateur[30]. Ils ont réussi à prendre le contrôle des systèmes radios, AC, essuie-glases, transmission, direction et freins). Lors d’une démonstration sur autoroute, une Jeep Cherokee, conduite par un journaliste, Andy Greenberg (en), est piratée à distance par les deux chercheurs. Le journaliste est devenu impuissant lors de ce hacking qui a vu la radio s’allumer et les essuie-glace s’actionner. De plus, ils réussissent à couper le moteur sans que le conducteur puisse redémarrer la voiture. Lors d’une seconde démonstration, sur un parking, ils coupent les freins de la Jeep, ce qui envoie la voiture dans le fossé. C’est en passant par le réseau mobile de Sprint, en exploitant une faille du système UConnect ou In-car Internet (en), qu’ils ont pu accéder au système Harman-Kardon qui contrôle l’écran central et le système de divertissement. C'est par ce système qu’ils ont ou accéder au bus CAN de la voiture. Uconnect n'est pas le seul service utilisé par des véhicules connectés. Il en est de même pour les autres systèmes de télématique embarquées comme Sync de Ford ou OnStar de GM qui proposent une série de contrôles à distance. Pour l'amélioration des conditions de conduite, ils envoient des données de la voiture vers le conducteur.

Samuel Woo, dans son article propose une attaque en utilisant une application mobile malveillante dans l’environnement de la voiture connectée en le démontrant de façon pratique. Le modèle appliqué par S. Woo est le même que Koscher sur l’exploitation des vulnérabilités du bus CAN. À la différence, le test d’attaque prend en compte une application d’auto-diagnostic du véhicule, un outil d’analyse sur le port OBD-II et son couplage en Bluetooth. C’est au moment ou le propriétaire installe l’application que le hacker lance l’attaque réelle, en obtenant les informations de l’état du véhicule par l’application et la copie des données sur un serveur du hacker via le réseau mobile. De la même façon, l'attaquant peut envoyer des informations, des commandes vers le téléphone pour ensuite viser les ECU de la voiture[4].

Le schéma ci-contre montre schématiquement comment un hacker peut utiliser une application sur Smartphone pour envoyer des commandes vers le bus CAN.

Exemple d’une Twizy de Renault utilisé par les chercheurs de l’université du Luxembourg

Des chercheurs de l’université du Luxembourg ont fait une étude sur la Twizy de Renault. Couplé à un système de surveillance ouvert ou OpenVMS (Outils open source et ouvert équipé d’un module GPRS/GSM, d’un GPS et d’un port série), il peut être connecté au réseau GSM en utilisant une carte SIM standard. L’OVMS peut ainsi être contrôlé par SMS (en utilisant l’application Smartphone OVMS), envoyer des alertes par SMS ou être connecté à un ordinateur. De plus, il est équipé d’un récepteur GPS afin de pouvoir le localiser. Grâce à l’OVMS, l’équipe a pu accéder et reconfigurer le contrôleur Sevcon Gen4. Ce contrôleur gère les paramètres vitaux du moteur et interagit avec le fonctionnement du véhicule : ralentir, accélérer, arrêter le véhicule. L’OVMS « permet à l'utilisateur de surveiller l'état de la batterie de la voiture, le dernier emplacement GPS connu, et de contrôler certaines caractéristiques de la voiture telles que le statut de verrouillage des portes ou le système de chauffage à travers leurs Smartphones »[31].

On peut voir que l'OVMS permet d'étendre la plage d'interaction avec le bus CAN en utilisant le réseau cellulaire"[32], on se retrouve dans une situation de piratage de la voiture. Le test demande l’accès complet de la voiture et comme on peut le voir sur internet, beaucoup de personnes demandent comment configurer le contrôleur. Il ne s’agit de piratage, mais la connaissance des principes d’accès peut être utilisée par de mauvaises mains.

Après avoir pris le contrôle d'une Tesla Modèle S par wifi, les chercheurs de Keen Security Lab de Tencent ont récidivé mais via le réseau mobile. Malgré une mise à jour du firmware OTA, ils ont pu contourner les mécanismes de sécurité et accéder au bus de données CAN[21].. Ouverture des portières et du coffre à distance depuis une application mobile, prise de contrôle du système de freinage du véhicule en mouvement et contrôle des feux de croisement.

Lecteur CD et fichiers musicaux[modifier | modifier le code]

Presque toutes les automobiles livrées fournissent un lecteur de CD capable d'interpréter une grande variété de formats audio (audio "Red Book" brut, MP3, WMA, etc.). De même, les constructeurs automobiles proposent également un port multimédia numérique externe (généralement un port USB ou un port d'accueil iPod / iPhone) permettant aux utilisateurs de contrôler le système multimédia de leur voiture à l'aide de leur lecteur audio personnel ou de leur téléphone. Certains fabricants ont élargi cette interface plus loin; BMW et Mini ont récemment annoncé leur soutien pour "iPod Out", un système par lequel les appareils multimédia Apple seront en mesure de contrôler l'affichage sur la console de la voiture

La prise en charge d'un lecteur de CD seul est une menace limitée; mais, pour diverses raisons, les systèmes de supports automobiles ne sont pas des dispositifs autonomes. En effet, de nombreux systèmes de ce type sont interconnectés au bus CAN, soit pour s'interfacer directement avec d'autres systèmes automobiles (par exemple, pour supporter des carillons, certaines fonctions mains libres, ou pour afficher des messages sur la console). tous les microprogrammes de l'ECU. Ainsi, contre intuitivement, un lecteur de CD compromis peut offrir un vecteur pour attaquer d'autres composants automobiles. Stephen Checkoway l'indique dans son article - Analyses expérimentales complètes des surfaces d'attaque automobiles: "un fichier audio WMA qui, lorsqu'il est gravé sur un CD, joue parfaitement sur un PC mais envoie des paquets CAN arbitraires"[33]. Comme on a pu le voir précédemment, l'accès au bus CAN est un vecteur d'attaque important sur le fonctionnement de la voiture.

Système de guidage laser[modifier | modifier le code]

Exemple d’un LIDAR positionné sur le toit d’une voiture

Jonathan Petit, chercheur en sécurité a piraté un LIDAR[34], système embarqué sur les voitures autonomes. Grâce à peu de matériel, il a pu envoyer de fausses informations aux Véhicules autonomes. En détectant et en enregistrant les impulsions émises par un LIDAR, il a pu renvoyer ces mêmes signaux mais en trompant le LIDAR du véhicule attaqué. En créant l’illusion d’un mur, d’un piéton et de les faire bouger. Il est également possible d’envoyer tellement de signaux parasites que la voiture resterait immobile.

Il a expliqué à IEEE Spectrum : "La seule partie délicate était d'être synchronisé, de renvoyer le signal au lidar au bon moment. Alors le lidar a pensé qu'il y avait clairement un objet là »[35]

Système RDS et TMC[modifier | modifier le code]

Un détournement des signaux RDS et TMC peut permettre d'envoyer de fausses informations de trafic:

Les récepteurs GPS peuvent recevoir des informations, parfois payantes, sur les informations de bouchons, travaux et radar. En France, la réception RDS (Radio Data System) est gratuite, mais ce n’est pas le cas en Finlande ou une hackeuse s’est intéressée au RDS-TMC chiffré. Elle a réussi à le craquer grâce à un récepteur radio, une carte son et un ordinateur. En lisant la description du standard RDS ISO/DIS 14819-6, elle comprend que les messages TMC contiennent des références à une base de messages et à des lieux prédéfinis. La base est en libre-service, mais la clé de chiffrement (définissant le lieu) change tous les jours : chaque nuit, la clé change parmi 31 clé pré-généréés. Mais seul l’ID de la clé est transmise au GPS (qui possède les 31 clés). En restant au même endroit (lieu), chaque jour, elle a pu faire un tri sur les messages envoyés au GPS et parvenir à déterminer les clés[36].

Elle s’est basée sur le travail d’A. Barisani et de D. Bianco qui ont fait une démonstration au Cyberspace de Las Vegas. Ils ont mis au point un moyen d’envoyer aux systèmes de navigation, de fausses données de trafic. L’outil utilisé à une portée de 16 km et il permet de diffuser des messages d’alerte dans les systèmes de navigation[37].

Satellite[modifier | modifier le code]

Les voitures ne sont pas les seules à pouvoir être attaquées.

Des chercheurs de l’université du Texas ont réussi à détourner un yacht de sa trajectoire sans que l’équipage ne se rende compte de rien.

La méthode n’était pas d’utiliser un faux GPS, mais d'utiliser de faux signaux GPS avec lesquels, ils ont usurpé le GPS du yacht[pas clair][38].

V2V et V2I[modifier | modifier le code]

Les communications entre les véhicules (V2V) ou les infrastructures (V2I) routières sont la prochaine grande évolution dans le domaine du transport routier. Surtout avec l’arrivée prochaine de la technologie 5G. En effet, une voiture pourra communiquer son statut aux véhicules voisins. Cela permettrait par exemple à une voiture d'alerter les conducteurs en cas de danger imminent (freinage d'urgence d'une voiture à l'avant, véhicules arrivant à un carrefour, etc.) ou même pour s'adapter automatiquement aux nouvelles conditions routières ou météorologiques.

Actuellement, la technologie n’est pas encore sur les routes et les exemples de piratage ne sont pas légion. Cependant, l’étude de S-S. Park imagine déjà les possibilités de piratage et des menaces de sécurité sur ce type infrastructure[39].

D’autres alternatives à la 4G ou 5G sont apparues comme l’ITS (Intelligent Transportation Systems ou Système de transport intelligent) et le DSRC (Dedicated Short Range Communications). Quelle que soit la solution choisit au niveau européen ou aux États-Unis, il faudra prendre en compte la notion de sécurité d’accès aux systèmes et informations de ce type de voiture.

Propositions de solutions de sécurité[modifier | modifier le code]

Au cours des dix dernières années, beaucoup de recherches et d'améliorations dans différents domaines de la sécurité automobile ont été effectuées par la communauté scientifique[40].

La protection contre les cyberattaques doit s’opérer au niveau des systèmes embarqués mais également intervenir au niveau de l’environnement de connexion. Les solutions proposées tournent autour des topiques touchant à ces deux aspects.

En , durant le « First International Academic Workshop on Security, Privacy and Dependability for CyberVehicle », les chercheurs de l’Académie de Berlin établissent la liste suivante devant être prise en compte pour sécuriser les véhicules connectés des cyberattaques[41]:

  • Sécuriser et fiabiliser la communication intra et inter véhicule;
  • Sécuriser les mécanismes de protection contre le vol dans le domaine automobile;
  • Sécuriser les informations en les rendant anonymes;
  • Mettre en œuvre de Plateforme de confiance pour les véhicules;
  • Sécuriser les technologies sans fil et mobiles dans les véhicules;
  • Sécuriser et rendre confidentiel la localisation du véhicule;
  • Intégrer des systèmes de détection d’intrusion dans le système;
  • Sécuriser les interconnexions entre les Cloud et les réseaux embarqués des véhicules;
  • Sécuriser la mise à jour logicielle et l’activation des composants du véhicule;
  • Sécuriser les mises à jour distantes;
  • Protéger les IP des composants du véhicule[41].

Solutions de sécurisation de l'ECU et du CANbus[modifier | modifier le code]

Réinitialisation du compteur d’erreur de l’ECU

Le « bus-off-attack » est un type d'attaque par déni de service DOS qui exploite la fonction de gestion des erreurs du CAN en isolant automatiquement en mode "bus-off", les ECUs défectueux dont le contrôle d’erreur de Transmission (TEC) est supérieur à 255.

Voici le format d'une trame de données CAN

C'est une vulnérabilité importante au niveau des CAN bus compte tenu de sa capacité à annuler le code d'authentification de message (MAC), les sommes de contrôle. Il démontre aussi les limites du système de détection d'intrusion (IDS) à faire la différence entre une erreur système et une réelle attaque.

Pour ce faire, des chercheurs Américains du Michigan proposent un nouveau mécanisme de défense préventive en tirant parti des caractéristiques du « bus-off attack »[42] :

Phase 1

Les deux nœuds débute par défaut en mode : « erreur-active ». Après injection de M’ en même temps que M, la victime subit une erreur de bit. Elle transmet un indicateur d'erreur active et augmente son TEC de 8 bits. Comme le nœud de l’intrus possède 6 bits consécutifs, Une erreur de type « stuff » est déclenchée et son TEC augmente également de 8 bits. Suite à la retransmission des messages échoués de part et d’autre, la même erreur de bit se reproduit jusqu'à ce qu'ils passent tous deux en mode erreur-passif. L’intrus peut contraindre la victime à devenir passive-erreur avec juste une injection de message.

Exemple d'arbitrage CAN

Phase 1 à 2

Après 16 transmissions, l’intrus et la victime deviennent tous deux passifs lorsque leur TEC est de 128. Là encore, pour le message M retransmis, une erreur de bit se produit. Cependant, comme la victime est maintenant en mode passif-erreur, elle tente de délivrer un drapeau d'erreur passif composé de 6 bits récessifs. À ce moment-là, puisque l'adversaire transmet sa trame, la tentative de livrer le drapeau d'erreur persistera jusqu'à la fin de trame (EOF) de l'intrus. Contrairement à la phase 1, l’intrus adverse n'éprouve aucune erreur et réussit donc à transmettre sa trame, alors que la victime réussira plus tard lors de sa retransmission. Au total, en raison d'une erreur de bit, le TEC de la victime passe de 128 à 136 puis 135 tandis que celui de l’intrus passe de 128 à 127. En conséquence, l'adversaire repasse à "error-active", tandis que la victime reste erreur-passif.

Phase 2

Dans cette phase, l’intrus réitère ce processus pour chaque message M’ qu’il transmet périodiquement jusqu'à ce que la victime soit finalement passé en mode bus-off. C’est-à-dire avec un TEC supérieur à 255. En conséquence, l'ECU de la victime est déconnecté et, dans le pire des cas, l'ensemble du réseau s'arrête[42].

Les chercheurs exploitent alors le modèle et préconisent de prendre en compte N = 16 pour réinitialiser l'ECU victime lors de l'apparition de lors de l’apparition de ces deux évènements[42].

Le modèle de Contrôle de Flux d'Information Décentralisé (DIFC)

Configuration de Flux d'information décentralisé (DIFC)

Pour améliorer la sécurité et la confidentialité sur les réseaux embarqués des véhicules, ce modèle propose d’établir une base axée sur le contrôle décentralisé des flux d’information. Il contrôle les informations échangées entre deux entités et surveille l’intégrité des données envoyées vers le système embarqué. Il agit comme un coffre-fort de données. Il régule tous les échanges internes ou externes en appliquant les règles de sécurité spécifiquement établies. Une partie logicielle, le middleware, incluant une base de calcul d’intégrité, se charge de faire respecter ces règles. Il permet également d’homogénéiser et d’offrir un moyen évolutif de gestion des processus d’autorisation[43].

Ce modèle est une interface entre les connexions externes (Wi-Fi, LTE) et l’application tierce implémentée sur un dispositif propre au véhicule ou un mobile connecté au réseau embarqué.

L’architecture logicielle implémentée permet la communication à destination du middleware avec une adresse ip de base au niveau de la connexion "Etch" du véhicule. Des techniques d’isolation des applications tierces sont possibles. Le réseau Ethernet / IP embarqué permet également d’implémenter des protocoles tel qu’IPSec pour renforcer la sécurité de l’ECU[43].

Viden: Identification des attaquants sur les réseaux embarqués

La plupart des contre-mesures proposées déterminent bien la présence d’attaques sur les réseaux embarqués. Cependant ces solutions ne parviennent pas à identifier l'unité de contrôle électronique (ECU) à l'origine de l’attaque. Elles ne peuvent donc appliquer les solutions appropriées de manière ciblée. Cela s'explique parce que les réseaux embarqués sont principalement configurés comme des bus de diffusion et leurs messages manquent d'information d’identification concernant l’émetteur[44].

Schéma d'identification de Tension: aperçu de Viden

Pour répondre à cette faiblesse, une équipe de chercheurs américains proposent un nouveau schéma de détection d'attaques en ciblant plus précisément l'ECU incriminé. Cette méthode s'appelle Viden (Voltagebased identification). Elle permet d’identifier l’ECU attaquant en se basant sur une différentiation des tensions émises par différentes unités électroniques sur le réseau.

La première phase de Viden, appelée Apprentissage ACK, détermine si les tensions mesurées proviennent du véritable émetteur du message ou non. Viden exploite ensuite ces mesures pour construire et mettre à jour des profils de tension, véritables empreintes digitales, selon les calculateurs émetteurs. Ensuite, ces profils sont utilisés pour identifier l’ECU attaquant. Les correctifs ou politiques d’isolation de l’attaquant peuvent être alors appliqués rapidement et efficacement. Viden est aussi facile à déployer dans les réseaux embarqués[44].

Des évaluations expérimentales approfondies sur un prototype de bus CAN et deux véhicules réels ont montré que Viden peut identifier l'attaquant ECU avec un faible taux d’erreur de 0,2%. Cette solution permet de traiter chirurgicalement l’attaque en isolant / réparant l’ECU incriminé au lieu de traiter tous les ECUs aveuglément[44].

Solutions liées à l'environnement et l'infrastructure du véhicule[modifier | modifier le code]

La plupart des travaux sur la sécurisation des communications avec les réseaux embarqués des véhicules se concentrent sur le chiffrement, l’authentification et le contrôle d’accès en utilisant différents protocoles :

L’IPSec / Authentification Header

Une équipe de chercheurs Irlandais effectue en une étude portant sur la sécurisation des échanges entre le nœud CAN et l’environnement externe des véhicules équipés d’un réseau Ethernet embarqué placé entre les deux. Leur évaluation expérimentale propose l’utilisation du protocole IPSec / Authentication Header en mode transport pour sécuriser le trafic entrant vers le CAN. Les résultats ont révélé que le délai aller-retour des messages échos envoyés du nœud CAN au nœud Ethernet via la passerelle est d’environ 2 ms en incluant les 345 micros secondes correspondant à l’entête IPSec / AH.

Topology avec serveur Echo

Ceci démontre que l’utilisation d’un protocole IPSec est éprouvé pour ajouter des propriétés d’authenticité et d’intégrité aux communications automobile. Cette permet d'augmenter la sécurité des futurs réseaux embarqués basés sur Ethernet / IP[45].

Le Protocole TLS avec Autorité de certification et chiffrement symétrique

Un autre protocole a fait l’objet d’une étude en vue de répondre aux exigences concernant la sécurité des échanges avec les ECUs via les CAN bus, CAN FD (en), FlexRay, MOST, Bus LIN ou Ethernet / IP : le TLS. Des chercheurs Allemands de l'Institut Fraunhofer pour la sécurité des technologies de l'information ont, en , expérimenté ce protocole en l’associant à des algorithmes de chiffrement tels que ChaCha20 + Poly1305 et HC-128 + Rabbit[46].

Exemple d'architecture de l'autorité de Certification (CA)

La première association permet de répondre à toutes les exigences. La deuxième permet de maintenir un bon débit tout en réduisant la latence. De plus, ils présentent dans leur étude une architecture basée sur une infrastructure de clé publique qui permet aux garages d’échanger avec les ECU des véhicules de manière sécurisés dans le cadre de tests de diagnostiques une fois l’authentification établie par certificat. Ce dernier ne comporte que les éléments suivants : clé publique, informations sur l’émetteur, droits de l’ECU et la signature de l’Autorité de certification (CA).

La clé privé est quant à elle uniquement stockée dans l’ECU. Les droits de l’ECU contiennent les informations relatives au type de l’ECU, une liste de droits d’accès aux autres ECUs et les types de données ou commandes. Ceci permet de garantir l’accès aux fonctionnalités uniquement nécessaires par les ECU. De plus, le récepteur peut savoir s’il peut ou non envoyer des données à un autre ECU ou si l’ECU est autorisé à fournir certaines données ou exécuter certaines commandes.

CESAR : infrastructure d’évaluation de mise à jour logicielle automobile sans fil (WVI)

ECUs ou Véhicules se connectant aux Nœuds de Tests via un réseau backbone

C’est une infrastructure de banc d'essai configurable et hautement automatisée qui permet d'évaluer l'efficacité d'une mise à jour logicielle des systèmes embarqués automobiles. Elle permet de spécifier à travers des scénarios, différents mécanismes de mise à jour, différentes configurations de sécurité, et, différents protocoles sans fil de transfert de données. Elle permet d'identifier le nombre d'interfaces sans fil dont dispose le véhicule, la topologie réseau et l'ECU cible.

En outre, CESAR permet de mesurer l'efficacité de la mise à jour logicielle d’un hardware et dresser une état sur les faiblesses d'un système en test ou sur l'interaction d'une application spécifique (SW) avec un ECU donné.

De plus, le banc d'essai devrait passer à 100 nœuds dans l'avenir, en fournissant plusieurs profils de configurations permettant à l'utilisateur de choisir entre différentes topologies de réseau et piles de communication sans fil (par exemple, IEEE 802.11n ou IEEE 802.11s.

Ces profils de configuration doivent inclure différents paramétrages de sécurité et permettre à l'utilisateur de choisir entre différents paramètres de sécurité, tels que l'authentification ou la longueur de la clé.

L'architecture CESAR apporte les mesures de sécurité appropriées pour les configurations techniques de mise à jour de logiciel automobile et protocoles réseaux[47].

Contexte[modifier | modifier le code]

Industriel et économique[modifier | modifier le code]

voiture connectée[modifier | modifier le code]

Le marché de la voiture connectée est le 3e marché mondial sur le plan de la croissance, derrière le marché des tablettes et celui des smartphones[48].

Selon l'étude « Connected C@r » réalisée en par Strategy& (en), Les ventes mondiales de véhicules connectés vont tripler de 2017 à 2022. Le marché prévu est de 155,9 milliards de dollars au terme de cette période[49].

Le marché profite essentiellement au segment des véhicules haut de gamme. La tendance à la démocratisation vers les véhicules grands public s'accroît fortement[49].

La tendance est aussi très clairement orientée dans le sens d’une intensification de la mise en réseau. La voiture du futur sera en communication permanente avec son environnement, avec d’autres véhicules[50].

D'ailleurs, Le module de communication eCall permettant d'appeler le 112 automatiquement en cas d’accident et de fournir les informations nécessaires à l’intervention des secours devient obligatoire le sur tous les véhicules européens[50].

Le marché de la voiture connectée représente également un enjeu considérable pour les géants d’internet : Google, Apple[50].

Ces nouveaux entrants y voient un formidable potentiel de croissance avec un modèle commercial centré sur les données. Ils devront nécessairement coopérer avec les acteurs du numérique et des technologies de l'informatique embarquée[50].

voiture autonome[modifier | modifier le code]

La voiture totalement autonome n’est pas encore une réalité pour les automobilistes. Toutefois, elle est amenée à prendre de plus en plus d’importance sur le marché, bouleversant ainsi le modèle économique des industries automobiles[49].

Volvo, Ford, BMW mais aussi Apple, Google, Uber ou Tesla, presque tous les grands noms de l'automobile et de la technologie se sont lancés depuis quelques années dans une course de vitesse, à qui mettra la première voiture autonome viable sur le marché. La plupart des grands constructeurs promettent de premières productions en série dès 2020, voire 2021[48].

Le géant des puces Intel, qui a racheté la société israélienne Mobileye spécialiste en systèmes anti-collisions et assistance à la conduite, veut tester 100 voitures autonomes en 2018[48].

Waymo (Alphabet) fait des essais auprès de volontaires en Arizona dans le sud-ouest des États-Unis[48].

Selon une étude menée en par le cabinet Navigant, Waymo a effectué un bond de la 7e à la 2e place du classement juste derrière General Motors. Ce dernier propose un modèle sans pédale ni volant qu'il peut produire à grande échelle[51].

Règlementaire et juridique[modifier | modifier le code]

Le règlement 155 est le premier règlement international relatif à la sécurité informatique des véhicules[52]

États-Unis[modifier | modifier le code]

Le , la NHTSA — National Highway Traffic Safety Administration — administration chargée de la sécurité et des infrastructures routières américaine, a publié un ensemble de règles spécifiques concernant les voitures autonomes à destination des constructeurs automobiles[53].

Le guide intitulé «Federal Automated Vehicule Policy» est divisé en quatre parties :

  • Guide de performance des véhicules pour les véhicules automatisés;
  • Exemple de régulation pour un État;
  • Outils actuels de régulation de la NHTSA;
  • Outils réglementaires modernes[53].

La NHTSA donne des directives précises aux constructeurs en s'appuyant sur les différents niveaux d'autonomie des véhicules établis par le SAE International. Elle a demandé aux constructeurs d'effectuer une évaluation de leurs véhicules autonomes sur 15 points précisément décrits dans le guide qui concernent principalement la sécurité des usagers[53].

Asie[modifier | modifier le code]

Depuis mi 2013, à Singapour et au japon, les véhicules sont en tests sur les autoroutes mais aucune législation spécifique n'existe. Une simple autorisation des autorités locales permettent tester une voiture autonome sur la voie publique[53].

En 2015, le Japon adopte un plan national des véhicules autonomes qui prévoit une association entre le secteur automobile, le secteur électronique et les grandes universités du pays pour concevoir un véhicule sûr et totalement indépendant.Toujours aucune règlementation en perspective depuis[53].

La Corée du sud ne prévoit aucun cadre règlementaire mais opte pour la création d'une ville entièrement dédiée à l'expérimentation de son modèle autonome Kit-City[53].

La Chine n’a encore adapté aucune législation concernant les nouvelles technologies qui entourent l'automobile[53].

En janvier 2021, la règlement 155 a été transposé au Japon où il devient obligatoire sur les nouveaux types de véhicules avec mise-à-jour-par_air à partir de juillet 2022 ou en janvier 2024[52] pour les autres nouveaux véhicules produits, les dates sont juillet 2024, mai 2026.

La Corée, veut appliquer ce règlement dès 2022[52].

Europe et France[modifier | modifier le code]

Le cadre juridique des expérimentations sur voie publique est encore en construction en France. Les débats sont engagés pour rendre compatibles la Convention de Vienne dur la circulation routière (1968) aux nouvelles technologies embarquées automobiles[54].

Le , la France adopte la loi no 201-992 relative à la transition énergétique pour la croissance verte autorise. Dans son article 37, le gouvernement adapte la législation française pour permettre la circulation sur la voie publique des voitures partiellement ou totalement autonome[55].

Le , la Commission Européenne aux Nations unies modifie la Convention de Vienne afin de l'adapter aux avancées actuelles et de permettre aux États signataires de légiférer sur les voitures autonomes. Le , le gouvernement Français autorise par l'ordonnance no 2016-1060 l'expérimentation des « voitures sans chauffeur » sur les routes et autoroutes françaises.

Le , près de 26 pays européens, réunis à Amsterdam pour une conférence sur les véhicules connectés et autonomes, ont décidé d'autoriser les expérimentations sur voie publique des voitures autonomes[54].

Dans le cadre de la protection des données, l’union européenne adopte le Règlement Général sur la Protection des Données RGPD qui sera appliqué le .
Les fabricants devront mettre en place des éléments de sécurité de manière anticipée (« privacy by design ») dans leurs produits. En l’absence de ces protections, les fabricants encourent de lourdes sanctions financières)[56]. Ce règlement a pour but de renforcer la protection des données personnelles des usagers sur le territoire de l’Union européenne[57].

D’autre part, elle applique un droit coopératif à l'égard :

  • La normalisation ISO et ETSI;
  • Des avis et recommandations du G29 et de la CNIL concernant la protection des données;
  • Chartes et guides de bonnes pratiques de l’ENISA et de l’ANSSI concernant la cybersécurité[57].

Le 29 janvier 2021, le Secrétaire général de l’Organisation des Nations Unies — agissant en sa qualité de dépositaire — considère adopté la règlement 155: Prescriptions uniformes relatives à l’homologation des véhicules en ce qui concerne la cybersécurité et de leurs systèmes de gestion de la cybersécurité.

Le règlement 155 devrait devenir obligatoire dans l'union européenne dès juillet 2022 sur les nouveaux types de véhicules ou en juillet 2024[52]

Risques[modifier | modifier le code]

Vols de véhicules[modifier | modifier le code]

Avec la multiplication des services connectés dans les automobiles, la question de la sécurité est devenue un point essentiel pour les industriels et les forces de l'ordre. Le chef d’escadron de gendarmerie Millet et le colonel Franck Marescal, responsable de l'observatoire central des systèmes intelligents ont confirmé que les vols de voitures étaient de plus en plus souvent réalisés avec des outils électroniques. Il ne s’agit pas seulement de prises de contrôle à distance des commandes mais plus simplement de vols ou tentatives de vols[58].

40 millions d'automobilistes met à disposition les tendances de vols de voiture en France. Pour l'année 2015: 234 000 vols ou tentatives de vols ont été recensés. Dont 68% sont des vols en mouse jacking[59],[60]. Le mouse jacking ou « vol à la souris » est un vol de voiture en faisant usage de l’informatique et de l’électronique[60].

La sécurité au sein de la voiture connectée devient aussi un enjeu pour la formation dans le domaine de la cyber sécurité. C’est l’un des objectifs de la Chaire « Connected Car & Cyber Security » (C3S) qui a été lancée en par Télécom ParisTech.

Ces formations et recherches au niveau internationales seront axées entre autres sur les questions de sécurités autour de la voiture autonome, sur les protections d’attaques numériques ou sur la possible interception de données. Cela en relation avec de grands groupes comme Nokia, Thales, Renault, Wavestone ou Valeo[61].

Enjeux sociétal et éthique de la voiture autonome[modifier | modifier le code]

Principes moraux[modifier | modifier le code]

En cas d'accident[modifier | modifier le code]

Rappelons également que la commercialisation en série d'un véhicule autonome d'ici 2025 pose de nombreuses questions sur les plans éthiques[62].

Une question de choix se pose concernant les accidents impliquant des voitures autonomes. Malgré les nombreux avantages apportés en matière de sécurité à la voiture intelligente, des considérations éthiques sont à prendre compte. Le risque zéro n’existe pas, des cas de conscience peuvent se poser dans une situation extrême impliquant des individus. Cela pose la question du choix entre sauver un piéton plutôt que le conducteur par exemple ou un enfant plutôt qu’un adulte. Cette question appelle à des principes moraux qui seront à prendre en compte dans le paramétrage des algorithmes de ces voitures et dans son acceptation par la société[63].

Un laboratoire comme test[modifier | modifier le code]

En , Jean-François Bonnefon, Azim Shariff et Iyad Rahwan, chercheurs à la Toulouse School of Economics, à l’université de l’Oregon ont développé avec le Media Lab du MIT un test nommé « moral machine »[64] qui permet d'évaluer, en quelques minutes, ses propres choix moraux en cas d’accident impliquant une voiture autonome[65].

Entre Sécurité et Liberté[modifier | modifier le code]

La liberté est considérée comme un signe d’indépendance, symbole de liberté se retrouve avec compromise au détriment de la sécurité. Un choix appelle à des considérations éthiques quant au avantager l'une ou l'autre. Le conducteur va perdre dans ce choix la liberté de recourir aux procédures automatisées et plus encore l'opportunité de décider tout simplement[66].

Références[modifier | modifier le code]

  1. a et b Thalès 2016
  2. a et b Eagle Security Group
  3. a b et c Loukas 2015, p. 87
  4. a b et c Woo 2015, p. 993
  5. Bolesse 2017
  6. a et b Hoppe 2008, p. 238
  7. Nilsson 2008, p. 1
  8. Koscher 2010
  9. a et b Illera 2014
  10. UnderNew 2014
  11. a et b Studnia 2013
  12. Haataja 2008, p. 1096-1102
  13. a et b Courrier 2003
  14. hcitool 2018
  15. a b et c Cheah 2017, p. 87
  16. BlueBorne
  17. AitKaciAli 2011, p. 87
  18. a et b Checkoway 2011, p. 87
  19. Spill 2007
  20. Rashid 2011
  21. a et b Golson 2016
  22. Berman 2015
  23. Verdult 2012
  24. Bohic 2016
  25. LoiB 2015
  26. Autoplus 2016
  27. Police West Middland 2017
  28. Francillon 2016
  29. BlackHat
  30. Miller 2015
  31. Jafarnejad 2015
  32. Jafarnejad 2015
  33. Checkoway 2011
  34. Pain 2015
  35. Harris 2015
  36. Raisanen 2013
  37. BlackHat 2007
  38. Donohue 2013
  39. Park 2017
  40. Jungk
  41. a et b Munir 2013
  42. a b et c Cho 2016, p. 1047
  43. a et b Bouard 2013
  44. a b et c Cho 2017
  45. Lastinec 2015
  46. Zelle 2017
  47. Steger 2017
  48. a b c et d Strategy& 2016
  49. a b et c Pwc/
  50. a b c et d Mobility Tech Green
  51. Arnulf 2018
  52. a b c et d https://unece.org/sustainable-development/press/three-landmark-un-vehicle-regulations-enter-force
  53. a b c d e f et g Assurance.com 2018
  54. a et b Assurance.com 2018
  55. Le Monde Informatique 2016
  56. digital.security 2017, p. 24
  57. a et b Ifsttar 2017
  58. Le Monde Informatique 2016
  59. 40 Millions d'automobilistes 2017
  60. a et b https://www.ouest-france.fr/societe/faits-divers/les-vols-de-voitures-sont-de-plus-en-plus-technologiques-7124325
  61. IMT Paris Tech 2017
  62. Assurance.com 2017
  63. La Tribune 2017
  64. Lab MIT 2016, p. 198
  65. Leséchos 2016
  66. Jalis 2017


Bibliographie[modifier | modifier le code]

Articles[modifier | modifier le code]

Document utilisé pour la rédaction de l’article : document utilisé comme source pour la rédaction de cet article.*

CANbus et ECU

  • (en) Rafael Zalman et Albrecht Mayer, « A Secure but Still Safe and Low Cost Automotive Communication Technique », Proceedings of the 51st Annual Design Automation Conference, ACM, dAC '14,‎ , p. 43:1–43:5 (ISBN 9781450327305, DOI 10.1145/2593069.2603850, lire en ligne, consulté le 14 janvier 2018)
  • (en) A. Perrig, R. Canetti, J. D. Tygar et Dawn Song, « Efficient authentication and signing of multicast streams over lossy channels », Proceeding 2000 IEEE Symposium on Security and Privacy. S P 2000,‎ , p. 56–73 (DOI 10.1109/secpri.2000.848446, lire en ligne, consulté le 3 février 2018)
  • (en) Marten van Dijk, « Hardware Security and Its Adversaries », Proceedings of the 5th International Workshop on Trustworthy Embedded Devices, ACM, trustED '15,‎ , p. 1–2 (ISBN 9781450338288, DOI 10.1145/2808414.2808422, lire en ligne, consulté le 14 janvier 2018)
  • (en) Paul Carsten, Todd R. Andel, Mark Yampolskiy et Jeffrey T. McDonald, « In-Vehicle Networks: Attacks, Vulnerabilities, and Proposed Solutions », Proceedings of the 10th Annual Cyber and Information Security Research Conference, ACM, cISR '15,‎ , p. 1:1–1:8 (ISBN 9781450333450, DOI 10.1145/2746266.2746267, lire en ligne, consulté le 11 janvier 2018)
  • (en) Philipp Mundhenk, Artur Mrowca, Sebastian Steinhorst et Martin Lukasiewycz, « Open Source Model and Simulator for Real-time Performance Analysis of Automotive Network Security », SIGBED Rev., vol. 13, no 3,‎ , p. 8–13 (ISSN 1551-3688, DOI 10.1145/2983185.2983186, lire en ligne, consulté le 14 janvier 2018)
  • (en) Bogdan Groza, Stefan Murvay, Anthony Van Herrewege et Ingrid Verbauwhede, « LiBrA-CAN: Lightweight Broadcast Authentication for Controller Area Networks », ACM Transactions on Embedded Computing Systems (TECS), vol. 16, no 3,‎ , p. 90 (ISSN 1539-9087, DOI 10.1145/3056506, lire en ligne, consulté le 3 février 2018)
  • (en) Florian Pölzlbauer, Robert I. Davis et Iain Bate, « Analysis and Optimization of Message Acceptance Filter Configurations for Controller Area Network (CAN) », Proceedings of the 25th International Conference on Real-Time Networks and Systems, ACM, rTNS '17,‎ , p. 247–256 (ISBN 9781450352864, DOI 10.1145/3139258.3139266, lire en ligne, consulté le 14 janvier 2018)
  • (en) Jo Van Bulck, Jan Tobias Mühlberg et Frank Piessens, « VulCAN: Efficient Component Authentication and Software Isolation for Automotive Control Networks », Proceedings of the 33rd Annual Computer Security Applications Conference, ACM, aCSAC 2017,‎ , p. 225–237 (ISBN 9781450353458, DOI 10.1145/3134600.3134623, lire en ligne, consulté le 14 janvier 2018)
  • (en) Daniel Zelle, Christoph Krauß, Hubert Strauß et Karsten Schmidt, « On Using TLS to Secure In-Vehicle Networks », Proceedings of the 12th International Conference on Availability, Reliability and Security, ACM, aRES '17,‎ , p. 67:1–67:10 (ISBN 9781450352574, DOI 10.1145/3098954.3105824, lire en ligne, consulté le 14 janvier 2018). 
  • (en) W. A. Farag, « CANTrack: Enhancing automotive CAN bus security using intuitive encryption algorithms », 2017 7th International Conference on Modeling, Simulation, and Applied Optimization (ICMSAO),‎ , p. 1–5 (DOI 10.1109/icmsao.2017.7934878, lire en ligne, consulté le 23 novembre 2017)

IDS et IPS

  • (en) A. Taylor, N. Japkowicz et S. Leblanc, « Frequency-based anomaly detection for the automotive CAN bus », 2015 World Congress on Industrial Control Systems Security (WCICSS),‎ , p. 45–49 (DOI 10.1109/wcicss.2015.7420322, lire en ligne, consulté le 23 novembre 2017)
  • (en) K. M. A. Alheeti, A. Gruebler et K. D. McDonald-Maier, « An intrusion detection system against malicious attacks on the communication network of driverless cars », 2015 12th Annual IEEE Consumer Communications and Networking Conference (CCNC),‎ , p. 916–921 (DOI 10.1109/ccnc.2015.7158098, lire en ligne, consulté le 23 novembre 2017)
  • (en) Kyong-Tak Cho et Kang G. Shin, « Error Handling of In-vehicle Networks Makes Them Vulnerable », Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM, cCS '16,‎ , p. 1044–1055 (ISBN 9781450341394, DOI 10.1145/2976749.2978302, lire en ligne, consulté le 14 janvier 2018). 
  • (en) S. Abbott-McCune et L. A. Shay, « Intrusion prevention system of automotive network CAN bus », 2016 IEEE International Carnahan Conference on Security Technology (ICCST),‎ , p. 1–8 (DOI 10.1109/ccst.2016.7815711, lire en ligne, consulté le 23 novembre 2017)
  • (en) M. Gmiden, M. H. Gmiden et H. Trabelsi, « An intrusion detection method for securing in-vehicle CAN bus », 2016 17th International Conference on Sciences and Techniques of Automatic Control and Computer Engineering (STA),‎ , p. 176–180 (DOI 10.1109/sta.2016.7952095, lire en ligne, consulté le 23 novembre 2017)
  • (en) B. Jungk, « Automotive security state of the art and future challenges », 2016 International Symposium on Integrated Circuits (ISIC),‎ , p. 1–4 (DOI 10.1109/isicir.2016.7829737, lire en ligne, consulté le 23 novembre 2017). 
  • (en) Kyong-Tak Cho et KangG. Shin, « Viden: Attacker Identification on In-Vehicle Networks », Proceedings of the 2017 ACM SIGSAC Conference on Computer and CommunicationsSecurity, ACM, cCS'17,‎ , p. 1109–1123 (ISBN 9781450349468, DOI 10.1145/3133956.3134001, lire en ligne, consulté le 14 janvier 2018). 
  • (en) M. Marchetti et D. Stabili, « Anomaly detection of CAN bus messages through analysis of ID sequences », 2017 IEEE Intelligent Vehicles Symposium (IV),‎ , p. 1577–1583 (DOI 10.1109/ivs.2017.7995934, lire en ligne, consulté le 23 novembre 2017)

Interfaces de connexions

  • (en) Julian Timpner, Dominik Schürmann et Lars Wolf, « Secure Smartphone-based Registration and Key Deployment for Vehicle-to-cloud Communications », Proceedings of the 2013 ACM Workshop on Security, Privacy & Dependability for Cyber Vehicles, ACM, cyCAR '13,‎ , p. 31–36 (ISBN 9781450324878, DOI 10.1145/2517968.2517970, lire en ligne, consulté le 14 janvier 2018)
  • (en) Q. Wang et S. Sawhney, « VeCure: A practical security framework to protect the CAN bus of vehicles », 2014 International Conference on the Internet of Things (IOT),‎ , p. 13–18 (DOI 10.1109/iot.2014.7030108, lire en ligne, consulté le 23 novembre 2017)
  • (en) D.K. Oka, T. Furue, L. Langenhop et T. Nishimura, « Survey of Vehicle IoT Bluetooth Devices », 2014 IEEE 7th International Conference on Service-Oriented Computing and Applications,‎ , p. 260–264 (DOI 10.1109/soca.2014.20, lire en ligne, consulté le 20 novembre 2017)
  • (en) Alexander Kiening, Daniel Angermeier, Herve Seudie et Tyrone Stodart, « Trust Assurance Levels of Cybercars in V2x Communication », Proceedings of the 2013 ACM Workshop on Security, Privacy & Dependability for Cyber Vehicles, ACM, cyCAR '13,‎ , p. 49–60 (ISBN 9781450324878, DOI 10.1145/2517968.2517974, lire en ligne, consulté le 14 janvier 2018)
  • (en) Miao Xu, Wenyuan Xu, Jesse Walker et Benjamin Moore, « Lightweight Secure Communication Protocols for In-vehicle Sensor Networks », Proceedings of the 2013 ACM Workshop on Security, Privacy & Dependability for Cyber Vehicles, ACM, cyCAR '13,‎ , p. 19–30 (ISBN 9781450324878, DOI 10.1145/2517968.2517973, lire en ligne, consulté le 14 janvier 2018)
  • (en) Alexandre Bouard, Benjamin Weyl et Claudia Eckert, « Practical Information-flow Aware Middleware for In-car Communication », Proceedings of the 2013 ACM Workshop on Security, Privacy & Dependability for Cyber Vehicles, ACM, cyCAR '13,‎ , p. 3–8 (ISBN 9781450324878, DOI 10.1145/2517968.2517969, lire en ligne, consulté le 14 janvier 2018). 
  • (en) I. Studnia, V. Nicomette, E. Alata et Y. Deswarte, « Survey on security threats and protection mechanisms in embedded automotive networks », 2013 43rd Annual IEEE/IFIP Conference on Dependable Systems and Networks Workshop (DSN-W),‎ , p. 1–12 (DOI 10.1109/dsnw.2013.6615528, lire en ligne, consulté le 23 novembre 2017). 
  • (en) S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner et T. Kohna, « Comprehensive experimental analyses of automotive attack surfaces », ACM DL, USENIX Association Berkeley,‎ , p. 1 - 6 (lire en ligne). 
  • (en) K. M. J. Haataja et K. Hypponen, « Man-In-The-Middle attacks on bluetooth: a comparative analysis, a novel attack, and countermeasures », 2008 3rd International Symposium on Communications, Control and Signal Processing,‎ , p. 1096–1102 (DOI 10.1109/isccsp.2008.4537388, lire en ligne, consulté le 8 janvier 2018). 
  • (en) Jan Lastinec et Ladislav Hudec, « A Performance Analysis of IPSec/AH Protocol for Automotive Environment », Proceedings of the 16th International Conference on Computer Systems and Technologies, ACM, compSysTech '15,‎ , p. 299–304 (ISBN 9781450333573, DOI 10.1145/2812428.2812434, lire en ligne, consulté le 14 janvier 2018). 
  • (en) S. Jafarnejad, L. Codeca, W. Bronzi et R. Frank, « A Car Hacking Experiment: When Connectivity Meets Vulnerability », 2015 IEEE Globecom Workshops (GC Wkshps),‎ , p. 1–6 (DOI 10.1109/glocomw.2015.7413993, lire en ligne, consulté le 3 décembre 2017). 
  • (en) S. Woo, H. J. Jo et D. H. Lee, « A Practical Wireless Attack on the Connected Car and Security Protocol for In-Vehicle CAN », IEEE Transactions on Intelligent Transportation Systems, vol. 16, no 2,‎ , p. 993–1006 (ISSN 1524-9050, DOI 10.1109/tits.2014.2351612, lire en ligne). 
  • (en) Jiang Wan, Anthony Bahadir Lopez et Mohammad Abdullah Al Faruque, « Exploiting Wireless Channel Randomness to Generate Keys for Automotive Cyber-physical System Security », Proceedings of the 7th International Conference on Cyber-Physical Systems, IEEE Press, iCCPS '16,‎ , p. 13:1–13:10 (lire en ligne, consulté le 14 janvier 2018)
  • (en) H. Kaartinen et J. Jämsä, « Encryption and authentication of 802.11p traffic radio », 2016 International Symposium on Small-scale Intelligent Manufacturing Systems (SIMS),‎ , p. 77–82 (DOI 10.1109/sims.2016.7802903, lire en ligne, consulté le 23 novembre 2017)
  • (en) V.K. Sehgal, S. Mehrotra et H. Marwah, « Car security using Internet of Things », 2016 IEEE 1st International Conference on Power Electronics, Intelligent Control and Energy Systems (ICPEICES),‎ , p. 1–5 (DOI 10.1109/icpeices.2016.7853207, lire en ligne, consulté le 23 novembre 2017)
  • (en) Marco Steger, Carlo A. Boano, Kay Römer et Michael Karner, « CESAR: A Testbed Infrastructure to Evaluate the Efficiency of Wireless Automotive Software Updates », Proceedings of the 20th ACM International Conference on Modelling, Analysis and Simulation of Wireless and Mobile Systems, ACM, mSWiM '17,‎ , p. 311–315 (ISBN 9781450351621, DOI 10.1145/3127540.3127580, lire en ligne, consulté le 14 janvier 2018). 
  • (en) Daniel Zelle, Christoph Krauß, Hubert Strauß et Karsten Schmidt, « On Using TLS to Secure In-Vehicle Networks », Proceedings of the 12th International Conference on Availability, Reliability and Security, ACM, aRES '17,‎ , p. 67:1–67:10 (ISBN 9781450352574, DOI 10.1145/3098954.3105824, lire en ligne, consulté le 14 janvier 2018). 
  • (en) M. Cheah, J. Bryans, D. S. Fowler et S. A. Shaikh, « Threat Intelligence for Bluetooth-Enabled Systems with Automotive Applications: An Empirical Study », 2017 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W),‎ , p. 36–43 (DOI 10.1109/dsn-w.2017.22, lire en ligne, consulté le 23 novembre 2017). 
  • (en) L. Nkenyereye et J. W. Jang, « Integration of big data for querying CAN bus data from connected car », 2017 Ninth International Conference on Ubiquitous and Future Networks (ICUFN),‎ , p. 946–950 (DOI 10.1109/icufn.2017.7993938, lire en ligne, consulté le 23 novembre 2017)
  • (en) Z. Qi, Ping Dong, K. Ma et N. Sargeant, « A design of in-car multi-layer communication network with Bluetooth and CAN bus », 2016 IEEE 14th International Workshop on Advanced Motion Control (AMC),‎ , p. 323–326 (DOI 10.1109/amc.2016.7496370, lire en ligne, consulté le 21 novembre 2017)
  • (en) Sung-Su Park, Sang Gyun Du et Keecheon Kim, « Application of a HID certificate issue algorithm for strengthening private information security over the V2V environment », 2017 International Conference on Information Networking (ICOIN),‎ , p. 611–615 (DOI 10.1109/icoin.2017.7899558, lire en ligne, consulté le 10 janvier 2018)

Réseaux embarqués et architectures

  • (en) Dominic Spill et Andrea Bittau, « BlueSniff: Eve meets Alice and Bluetooth », ACM,‎ august 06 - 10, 2007 (lire en ligne). 
  • (en) Edward S. Canepa et Christian G. Claudel, « A Framework for Privacy and Security Analysis of Probe-based Traffic Information Systems », Proceedings of the 2Nd ACM International Conference on High Confidence Networked Systems, ACM, hiCoNS '13,‎ , p. 25–32 (ISBN 9781450319614, DOI 10.1145/2461446.2461451, lire en ligne, consulté le 14 janvier 2018)
  • (en) Alexander Georg Camek, Christian Buckl et Alois Knoll, « Future Cars: Necessity for an Adaptive and Distributed Multiple Independent Levels of Security Architecture », Proceedings of the 2Nd ACM International Conference on High Confidence Networked Systems, ACM, hiCoNS '13,‎ , p. 17–24 (ISBN 9781450319614, DOI 10.1145/2461446.2461450, lire en ligne, consulté le 14 janvier 2018)
  • (en) Arslan Munir, Farinaz Koushanfar, Hervé Seudié et Ahmad-Reza Sadeghi, « CyCAR'2013: First International Academic Workshop on Security, Privacy and Dependability for Cybervehicles », Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security, ACM, cCS '13,‎ , p. 1481–1482 (ISBN 9781450324779, DOI 10.1145/2508859.2509030, lire en ligne, consulté le 14 janvier 2018). 
  • (en) Rolf Ernst, Gernot Spiegelberg, Thomas Weber et Herman Kopetz, « Automotive Networks: Are New Busses and Gateways the Answer or Just Another Challenge? », Proceedings of the 5th IEEE/ACM International Conference on Hardware/Software Codesign and System Synthesis, ACM, cODES+ISSS '07,‎ , p. 263–263 (ISBN 9781595938244, DOI 10.1145/1289816.1289880, lire en ligne, consulté le 14 janvier 2018)
  • (en) Q. Zheng, « The design and the implementation of communication gateway between CAN bus and Ethernet », 2015 IEEE Advanced Information Technology, Electronic and Automation Control Conference (IAEAC),‎ , p. 862–866 (DOI 10.1109/iaeac.2015.7428679, lire en ligne, consulté le 23 novembre 2017)
  • (en) K. von Hünerbein, P. Argent et T. Schulze, « Multi-sensor vehicle testing: Recording inertial sensors via CAN bus in combination with recorded GNSS RF signals », 2015 DGON Inertial Sensors and Systems Symposium (ISS),‎ , p. 1–13 (DOI 10.1109/inertialsensors.2015.7314269, lire en ligne, consulté le 23 novembre 2017)

Ouvrages et autres

  • (en) Tobias Hoppe, Stefan Kiltz et Jana Dittmann, « Security Threats to Automotive CAN Networks – Practical Examples and Selected Short-Term Countermeasures », Computer Safety, Reliability, and Security, Springer, Berlin,Heidelberg, lecture Notes in Computer Science,‎ , p. 235–248 (ISBN 9783540876977, DOI 10.1007/978-3-540-87698-4_21, lire en ligne, consulté le 28 novembre 2017). 
  • (en) Dennis K. Nilsson, Ulf E. Larson, Francesco Picasso et Erland Jonsson, Proceedings of the International Workshop on Computational Intelligence in Security for Information Systems CISIS’08, Springer, Berlin, Heidelberg, coll. « Advances in Soft Computing », (ISBN 978-3-540-88180-3 et 9783540881810, DOI 10.1007/978-3-540-88181-0_11, lire en ligne), p. 84–91. 
  • (en) Loukas, George,, Cyber-physical attacks : a growing invisible threat, Oxford, UK, Waltham, MA, USA / Elsevier/BH, Butterworth-Heinemann is an imprint of Elsevier (ISBN 978-0-12-801290-1, OCLC 910102749, lire en ligne). 
  • (en) Charlie Miller et Chris Valasek, « Jeep Hacking 101 », IEEE Spectrum,‎ (lire en ligne). 
  • (en) Mark Harris, « Researcher Hacks Self-driving Car Sensors », IEEE Spectrum,‎ (lire en ligne). 
  • Loic B., « RollJam : 30$ pour hacker toutes les voitures », www.objetconnecte.com,
  • (en) Nikos Tziritas, Thanasis Loukopoulos et Spyros Lalis, « Agent placement in wireless embedded systems: Memory space and energy optimizations », 2010 IEEE International Symposium on Parallel & Distributed Processing, Workshops and Phd Forum (IPDPSW), IEEE,‎ 19-23 avril 2010, p. 1 - 7 (ISBN 978-1-4244-6534-7, DOI 10.1109/IPDPSW.2010.5470786, lire en ligne)
  • (en) K. Koscher, A. Czeskis, F Roesner, S. Patel et T. Kohno, « Experimental Security Analysis of a Modern Automobile », Center for Automotive Embedded Systems Security,‎ , p. 16 (lire en ligne). 
  • (en) A. Francillon, B. Danev et S. Capkun, « Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars », IN PROCEEDINGS OF THE 18TH ANNUAL NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM,‎ , p. 1-15 (lire en ligne). 
  • (en) R. Verdult, G. d K. Gans et F. D. Garcia, « A Toolbox for RFID Protocol Analysis », 2012 Fourth International EURASIP Workshop on RFID Technology,‎ , p. 27–34 (DOI 10.1109/rfid.2012.19, lire en ligne, consulté le 9 janvier 2018). 
  • (en) Michael Feiri, Jonathan Petit et Frank Kargl, « Efficient and Secure Storage of Private Keys for Pseudonymous Vehicular Communication », Proceedings of the 2013 ACM Workshop on Security, Privacy & Dependability for Cyber Vehicles, ACM, cyCAR '13,‎ , p. 9–18 (ISBN 9781450324878, DOI 10.1145/2517968.2517972, lire en ligne, consulté le 14 janvier 2018)

Liens externes[modifier | modifier le code]

Piratage des véhicules

Cybersécurité des véhicules

Économie et Société