Hé, Charlie Miller ! Parlons de la sécurisation des véhicules autonomes

Un récent article de Wired sur Charlie Miller (connu pour le piratage et le contrôle à distance d'une Jeep) affirme que « une conversation ouverte et une coopération entre les entreprises » sont des conditions préalables nécessaires à la construction de véhicules autonomes sécurisés. Cela semble plutôt tiré par les cheveux alors que tant d'entreprises se battent pour dominer l'avenir de l'industrie automobile autrefois presque morte mais nouvellement ravivée (vous vous souvenez des trois grands renflouements ?). Aussi naïf que puisse paraître cette partie de l'article, ce qui m'a vraiment époustouflé, c'est l'implication que la réponse à la refonte de la sécurité se trouve uniquement dans l'industrie des véhicules autonomes.

Le concept de sécurité ne se limite pas aux véhicules autonomes il n'y a donc aucun avantage à prétendre que c'est le cas. Chaque industrie de l'IIoT essaie de résoudre des problèmes similaires et est étonnamment ouverte à partager ses découvertes. Je ne dis pas que Miller doit entreprendre un voyage d'illumination à travers toutes les autres industries pour créer la solution idéale pour la sécurité. Je dis que cela a déjà été fait pour nous, grâce à l'Industrial Internet Consortium (IIC).

L'IIC se compose de plus de 250 entreprises dans plusieurs secteurs - y compris des fournisseurs automobiles comme Bosch, Denso et TTTech - avec le même problème fondamental d'équilibrer la sécurité, la sécurité, les performances et bien sûr les coûts de leurs systèmes connectés. Si Câblé et Miller recherchent une conversation ouverte - cela se passe à l'IIC. L'IIC a publié l'Architecture de référence de l'Internet industriel, qui est disponible gratuitement pour tout le monde – comme dans la « bière gratuite », surtout si la voiture conduit à votre place ! Les extensions de ce document sont Industrial Internet Connectivity Framework (IICF) et Industrial Internet Security Framework (IISF). Ces documents fournissent des conseils d'un point de vue commercial jusqu'à la mise en œuvre, et l'IISF est particulièrement applicable car il traite des Wired's brèves mentions pour sécuriser les points de terminaison de connectivité et les données qui transitent entre eux.

Faites un tour avec moi et voyez comment nous pourrions modifier l'architecture de la voiture connectée pour se protéger contre des adversaires potentiels. Comme nous n'avons aucune attaque malveillante connue contre les voitures, nous pouvons commencer par le hack Miller's Jeep. Grâce à une « fonctionnalité » de porte dérobée dans l'unité principale Harmon Kardon, Miller a pu exécuter assez facilement des commandes à distance non protégées. Grâce à cet exploit initial, il a pu reprogrammer une puce connectée au bus CAN. À partir de là, il avait le contrôle presque total de la voiture. Vous pensez "supprimez simplement cette interface non protégée", n'est-ce pas ?

Miller ne se serait pas arrêté là, nous non plus. En supposant que nous puissions toujours trouver un exploit nous permettant d'accéder à la reprogrammation de la puce ARM, alors Wired's L'article suggère à juste titre d'établir une application authentifiée - peut-être en commençant par un démarrage sécurisé pour le noyau sous-jacent, en tirant parti de la zone de confiance ARM pour la prochaine étape du logiciel critique uniquement, et en implémentant une sorte d'authentification pour les systèmes d'exploitation et les processus d'application de niveau supérieur. Le point de terminaison de votre appareil peut commencer à ressembler à une pile d'applications de confiance (Figure 1 ci-dessous). Je ne peux que deviner combien coûte cette unité principale maintenant, mais pour être juste, ce sont des considérations valables pour exécuter une application de confiance. Le problème maintenant est que nous ne nous sommes connectés à rien, encore moins en toute sécurité. Ne vous inquiétez pas, je ne vous laisserai pas au bord de la route.

Bon nombre de ces applications de confiance se connectent directement au bus CAN, ce qui étend sans doute la surface d'attaque au contrôle du véhicule. Les données transmises entre ces applications ne sont pas protégées contre les auteurs et lecteurs de données non autorisés. Dans le cas des taxis autonomes, comme Câble souligne que les pirates potentiels ont désormais un accès physique à leur cible, augmentant ainsi leurs chances de s'emparer d'une application ou d'introduire un imposteur. Maintenant, la question devient :les applications peuvent-elles se faire confiance et faire confiance aux données sur le bus CAN ? Comment le combiné d'instruments fait-il confiance aux données de température externe ? Est-ce vraiment nécessaire ? Peut-être pas et c'est bon. Cependant, je suis à peu près sûr que le contrôle du véhicule doit faire confiance au LIDAR, au radar, aux caméras, etc. La dernière chose dont tout le monde veut s'inquiéter est un pirate informatique qui prend la voiture à distance pour une balade.

Nous parlons vraiment d'authenticité des données et de contrôle d'accès :deux dispositions qui auraient encore atténué les risques contre le piratage de Miller. La sécurisation des applications héritées est une bonne étape, mais considérons le scénario dans lequel un producteur de données non autorisé est introduit dans le système. Cet intrus peut injecter des commandes sur le bus CAN – des messages qui contrôlent la direction et le freinage. Le bus CAN n'empêche pas les éditeurs de données non autorisés ni ne garantit que les données proviennent du producteur authentifié. Je ne suggère pas que le remplacement du bus CAN soit la voie à suivre - bien que je ne sois pas opposé à l'idée de le remplacer par une solution plus centrée sur les données. De manière réaliste, avec un cadre comme les services de distribution de données (DDS), nous pouvons créer une architecture en couches guidée par l'IISF (Figure 2 ci-dessous). Le bus CAN et les composants critiques du lecteur sont effectivement des systèmes hérités pour lesquels le risque de sécurité peut être atténué en créant une barrière de bus de données DDS. De nouveaux composants peuvent ensuite être intégrés en toute sécurité à l'aide de DDS sans compromettre davantage le contrôle de votre véhicule. Alors, qu'est-ce que le DDS ? Et en quoi cela aide-t-il à sécuriser mon véhicule ? Heureux que vous ayez demandé.

Imaginez un réseau de capteurs automobiles, de contrôleurs et d'autres « participants » qui communiquent entre eux. Chaque participant ne reçoit que les données dont il a besoin d'un autre participant et vice versa. Avec le peer-to-peer, les participants de ce réseau peuvent s'authentifier mutuellement et si nos applications de confiance résistent, notre connectivité de confiance aussi. Comment sécurisons-nous ces connexions peer-to-peer ? TLS, non ? C'est possible, mais avec la complexité de la sécurisation de notre véhicule, nous voulons la flexibilité de faire un compromis entre les performances et la sécurité et d'appliquer des mécanismes de contrôle d'accès.

Revenons un peu en arrière et revoyons notre conversation sur l'IICF, qui fournit des conseils sur la connectivité pour les systèmes de contrôle industriels. L'IICF identifie les normes ouvertes existantes et les attribue succinctement à des fonctions précises d'un système IoT industriel. À la base, un véhicule autonome, aussi cool que cela puisse paraître, n'est qu'un système IoT industriel dans une carrosserie aérodynamique élégante avec des sièges en cuir en option. Alors, que suggère l'IICF pour l'intégration de logiciels pour un système IoT industriel, ou plus précisément, des systèmes autonomes ? Tu l'as deviné! DDS :un ensemble ouvert de normes conçues et documentées par le biais de conversations ouvertes par l'Object Management Group (OMG). Une solution automobile idéale tirant parti de DDS permet aux applications système de publier et de s'abonner uniquement aux messages dont elles ont besoin (voir la figure 3 ci-dessous pour notre vision d'une architecture autonome). Grâce à cette approche centrée sur les données, nous pouvons décomposer l'architecture des messages en fonction de leur criticité pour la sécurité ou du besoin d'intégrité des données.

Et maintenant que nous avons mis en place une solution de connectivité pour notre véhicule autonome, nous pouvons à nouveau parler de sécurité et de notre alternative TLS :une solution de sécurité centrée sur les données pour un cadre de messagerie centré sur les données. Avec DDS Security, les architectes système Industrial IoT peuvent utiliser des plugins de sécurité pour affiner les compromis de sécurité et de performances, une capacité nécessaire non offerte par TLS (Figure 4 ci-dessous). Authentifier uniquement les sujets de données sélectionnés, mais pas plus ? Vérifier. Crypter uniquement les informations sensibles mais pas plus ? Vérifier. En fait, il y a plus. Mis à part les courtiers cent

[1] [2] 下一页