Tendances en matière de sécurité automobile :
L’accent mis sur la sécurité s’est accru avec l’adoption d’une architecture zonale, en remplacement de l’architecture de domaine traditionnelle. Dans une architecture de domaine, les calculateurs électroniques (ECU) aux fonctions similaires sont interconnectés au sein d’un sous-réseau, créant ainsi de nombreux domaines indépendants. Ces domaines sont classés en propulsion et transmission, contrôle de la carrosserie, climatisation, etc. Chacun peut être développé pour répondre à un niveau de sécurité différent, selon son importance pour le véhicule. À l’inverse, dans le concept zonal, les ECU sont connectés à un contrôleur de zone local et à des passerelles. Dans une architecture zonale, les fonctions de plusieurs contrôleurs de domaine sont centralisées au sein d’un contrôleur unique. Cette centralisation réduit le coût et la complexité du système, ce qui explique la préférence croissante pour l’architecture zonale. Un inconvénient de l’architecture zonale réside dans l’obligation pour les ECU de différents domaines de partager le réseau de communication, ce qui implique que tous les ECU de cette architecture doivent adopter des niveaux de sécurité plus élevés.
Figure 1. Architecture de domaine versus architecture zonale.
Pour garantir la sécurité automobile, les organismes publics et les institutions internationales de normalisation exigent des constructeurs automobiles qu'ils adoptent de nouvelles normes telles que l'ISO/SAE 21434 et des réglementations comme les directives UNECE WP.29 R155/R156, ainsi que des réglementations similaires applicables dans certaines zones géographiques.
L'ISO 21434 est une norme de cybersécurité relativement récente dans l'industrie automobile. Elle porte sur les exigences d'ingénierie et de processus tout au long du cycle de vie du produit et inclut les politiques organisationnelles, les processus de développement produit et la gestion des problèmes de sécurité durant ce cycle. Pour que les véhicules soient conformes aux normes de cybersécurité, cette norme doit être adoptée par l'ensemble de la chaîne d'approvisionnement, par les constructeurs eux-mêmes, ainsi que par leurs fournisseurs directs et les prestataires de logiciels et de composants semi-conducteurs. Les directives
UNECE R155 et R156 sont des réglementations de cybersécurité adoptées à ce jour par 65 pays. Les constructeurs automobiles doivent les mettre en œuvre pour commercialiser leurs véhicules dans ces pays et, depuis juillet 2024, la conformité est obligatoire pour tous les nouveaux véhicules en production.
La réglementation de la CEE-ONU fait référence aux spécifications techniques de la norme ISO 21434 et exige la mise en œuvre d'un système de gestion de la cybersécurité (SGCS). Ce système doit couvrir l'intégralité du cycle de vie du véhicule, de sa conception à sa mise hors service. Durant toute cette période, le SGCS exige une surveillance des cybermenaces et la mise en œuvre de procédures pour les atténuer. Dans certains cas, la technique d'atténuation peut consister en la mise à jour rapide du micrologiciel d'un calculateur vulnérable. Par conséquent, les mises à jour de micrologiciel à distance sont devenues nécessaires pour tous les véhicules afin de se conformer à la réglementation de la CEE-ONU. Le système embarqué du calculateur doit intégrer un démarrage sécurisé, des mises à jour de micrologiciel sécurisées et une communication sécurisée pour garantir des mises à jour de micrologiciel à distance robustes.
La recharge sans fil des appareils personnels dans l'habitacle est un exemple d'application nécessitant une capacité de mise à jour à distance et un niveau d'authentification élevé. Le Wireless Power Consortium (WPC), qui gère les spécifications de recharge sans fil Qi®, s'inquiète des chargeurs malveillants susceptibles d'endommager les téléphones et autres appareils. Les normes Qi 1.3 et Qi 2.0, plus récentes, exigent que les chargeurs sans fil s'authentifient cryptographiquement pour la recharge haute puissance. Pour permettre cette authentification, les chargeurs sans fil compatibles Qi doivent intégrer des certificats d'unité produit (PUC) dans leur matériel. Ces certificats sont des certificats à clé publique que les fabricants peuvent obtenir auprès d'autorités de certification agréées par le WPC. Les chargeurs doivent également intégrer un matériel de haute sécurité conforme aux normes CC EAL (Common Criteria Evaluation Assurance Level) ou JIL (Joint Interpretation Library), capable de gérer l'authentification par signature ECC, le stockage sécurisé des clés et le stockage sécurisé du certificat X.509.
Sécurité logicielle et matérielle :
La fonction de démarrage sécurisé est essentielle pour établir la confiance dans le calculateur, car le chargeur de démarrage sécurisé garantit l’authenticité du micrologiciel exécuté sur le dispositif et son intégrité, tant pendant qu’après sa fabrication. Le chargeur de démarrage est donc responsable de la garantie que le micrologiciel utilisé provient bien du fabricant ou du fournisseur direct. La mémoire du calculateur qui stocke le chargeur de démarrage sécurisé doit être immuable (ou non modifiable) ; elle doit donc être protégée en écriture et programmable une seule fois, lors de la programmation initiale en usine. Au cours de la séquence de démarrage, le contrôleur de signal numérique temps réel exécute le chargeur de démarrage sécurisé pour vérifier l’authenticité et l’intégrité des images d’application. L’authenticité et l’intégrité peuvent être vérifiées à l’aide de l’algorithme de signature numérique à courbe elliptique (ECDSA) et d’algorithmes de hachage. La figure 2B décrit les étapes de création d’une application avec une image signée, et la figure 2C illustre le processus de vérification de l’application à l’aide d’un contrôleur de signal numérique temps réel embarqué. La figure 2C montre l'utilisation de la fonction de hachage SHA-256 pour obtenir une synthèse et vérifier l'étape en utilisant ECDSA et l'algorithme ECDSA P-256.
Figure 2. Processus de démarrage sécurisé, mise à jour du firmware et carte mémoire du contrôleur.
La fonction de mise à jour sécurisée du firmware peut constituer une section immuable du contrôleur de signal numérique temps réel. Elle est chargée d'interagir avec la passerelle centrale via le réseau du véhicule afin de recevoir la nouvelle image d'application. Cette image d'application intégrant l'adresse IP fonctionnelle du nœud, les concepteurs doivent impérativement recourir au chiffrement et à l'authentification du nœud via l'interface de communication pour éviter son exposition. La figure 2A illustre l'architecture mémoire d'un contrôleur doté d'une fonction de mise à jour du firmware. Celle-ci comprend généralement trois sections : une pour l'image active, une pour le téléchargement de la nouvelle image et une section de réinitialisation d'usine stockant l'image par défaut comme mécanisme de récupération en cas de panne. La mise à jour du firmware doit également vérifier l'authenticité et l'intégrité du système, ainsi que le processus de démarrage sécurisé, et mettre en œuvre une politique de mise à jour garantissant que le firmware ne puisse être mis à jour que vers une version plus récente. Enfin, elle doit implémenter une méthode de récupération système utile dans certaines situations, par exemple lorsque l'image d'application active ou l'application téléchargée échoue au contrôle d'authenticité.
Pour mettre en œuvre ces fonctionnalités de sécurité, la technique recommandée consiste à utiliser un module de sécurité matériel (HSM) externe associé à un microcontrôleur ou un contrôleur de signal numérique (DSC) sécurisé, ou encore un microcontrôleur/DSC intégrant un HSM. Un microcontrôleur/DSC avec HSM intégré est avantageux lorsqu'un encombrement réduit est requis. Les solutions de sécurité embarquées utilisant le DSC dsPIC33, par exemple, prennent en charge les HSM internes et externes ; les deux sont largement adoptés par les constructeurs automobiles. Les HSM constituent une enclave de sécurité lorsque la zone de stockage des clés sécurisées et les modules cryptographiques sont séparés du système principal microcontrôleur/DSC. Ceci réduit les risques de sécurité par rapport à un microcontrôleur stockant les clés dans sa mémoire interne. Le microcontrôleur/DSC sécurisé complète un HSM externe par des fonctionnalités telles qu'une mémoire de démarrage sécurisée immuable, une mémoire Flash programmable une seule fois et la possibilité de désactiver l'accès au mode débogage. Une plateforme ECU basée sur un HSM et une famille de microcontrôleurs sécurisés est plus adaptée car elle permet de sélectionner le microcontrôleur approprié en fonction des besoins en mémoire et en fonctionnalités.
Le développement avec un module de sécurité matériel (HSM) externe ou intégré exige une compréhension approfondie de la sécurité et une analyse poussée des nombreux paramètres de configuration afin de répondre aux exigences de sécurité spécifiques de chaque application et aux profils de sécurité souhaités. Il est donc important de démarrer le développement avec un écosystème d'outils offrant un prototypage matériel rapide et des configurateurs graphiques. Un autre aspect important est la programmation sécurisée des clés et des données secrètes dans le HSM pendant la phase de production, sans exposer d'informations sensibles. Cette problématique a été atténuée par certains fournisseurs de semi-conducteurs HSM qui proposent une livraison sécurisée de HSM. Ces dispositifs simplifient considérablement la production. Les
calculateurs modernes sont développés selon l'architecture AUTOSAR (Automotive Open System Architecture). Par conséquent, le développement de la sécurité requiert un HSM et un microcontrôleur/DSC sécurisé, compatible avec les composants logiciels AUTOSAR disponibles sur le marché. AUTOSAR prend en charge la mise en œuvre de la sécurité via différents blocs fonctionnels.
La figure 3 présente un schéma conceptuel de l'architecture AUTOSAR. En bas se trouve le DSC (microcontrôleur physique), et en haut le logiciel de base (BSW). Le BSW est divisé en trois couches : la couche de services, la couche d'abstraction de l'ECU et la couche d'abstraction du microcontrôleur (MCAL). Au-dessus se trouve la couche d'environnement d'exécution (RTE), qui fournit une interface standardisée permettant à une application d'accéder aux couches sous-jacentes. Elle facilite également la communication entre les composants applicatifs de niveau supérieur, programme le BSW et gère ses ressources et instances. En haut, la couche application est segmentée en composants logiciels AUTOSAR (SW-C). Cette couche est composée de nombreux composants logiciels, chacun assurant une fonction spécifique à l'ECU.
Le BSW dispose d'une interface standard pour l'utilisation de fonctionnalités de sécurité telles que les périphériques cryptographiques, les ancres de confiance et les modules HSM. L'architecture AUTOSAR divise l'implémentation cryptographique en trois couches : une couche de services, une couche d'abstraction matérielle et MCAL. La couche de services contient le gestionnaire de services cryptographiques (CSM). Les composants applicatifs interagissent avec le CSM pour accéder à la bibliothèque cryptographique sous-jacente, au HSM, et pour programmer des fonctions cryptographiques.
La pile cryptographique peut être configurée pour utiliser les fonctions cryptographiques matérielles disponibles dans le DSC ou des périphériques cryptographiques externes, tels qu'un HSM auxiliaire externe. La pile AUTOSAR peut intégrer l'utilisation d'un HSM externe via l'interface périphérique série (SPI) de MCAL et le pilote cryptographique approprié du fournisseur du HSM.
La fonction de sécurité principale est assurée par la pile cryptographique, qui a accès aux primitives cryptographiques et à la gestion des clés. AUTOSAR prend en charge trois protocoles de communication sécurisés : SecOC (Secure Onboard Communication), TLS (Transport Layer Security) et IPsec (Internet Protocol Security). SecOC est une norme ouverte définie par l'organisation AUTOSAR et est privilégiée pour la communication sécurisée entre calculateurs. Elle peut être utilisée sur un réseau CAN, Ethernet ou LIN. Le logiciel BSW d'AUTOSAR intègre des fonctions de diagnostic sécurisé et de détection d'intrusion. Des fonctionnalités supplémentaires, telles que les mises à jour sécurisées du firmware, peuvent être implémentées dans la pile de chiffrement.
Figure 3. Fonctions cryptographiques d'AUTOSAR.
Conclusion : L’essor du marché des véhicules connectés soulève des préoccupations majeures en matière de confidentialité et de sécurité pour les organismes publics, les constructeurs automobiles et les conducteurs. De nouvelles réglementations imposent donc aux véhicules d’intégrer des mesures de cybersécurité afin de protéger les données et d’améliorer la sécurité. La cybersécurité concerne l’ensemble de la chaîne d’approvisionnement, des constructeurs automobiles aux fournisseurs de composants. Les concepteurs peuvent utiliser un module HSM associé à un microcontrôleur/DSC sécurisé ou un microcontrôleur/DSC intégrant un HSM dans un seul boîtier. Par ailleurs, un écosystème d’outils de prototypage rapide, de bibliothèques et de configurateurs graphiques pour HSM facilite le développement. La disponibilité des bibliothèques et du support AUTOSAR contribue également à réduire les efforts d’ingénierie. L’écosystème idéal pour un DSC ou un microcontrôleur embarqué doit être entièrement conforme à AUTOSAR, à la norme de sécurité fonctionnelle ISO 26262, aux certifications de sécurité fonctionnelle supplémentaires et aux bibliothèques de sécurité. Pour plus d’informations sur AUTOSAR, la cybersécurité automobile et la sécurité fonctionnelle selon la norme ISO 26262, veuillez consulter la documentation relative à l’écosystème automobile DSC dsPIC33
Auteur : Nelson Alexander, ingénieur en chef et responsable marketing produit chez Microchip Technology.
