Brevet FR3006836A1 — publié le 20141212

DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne de manière générale le domaine des télécommunications pour les véhicules automobiles et leur sécurité. Elle concerne plus particulièrement un procédé de téléchargement d'un certificat pseudonyme par un véhicule automobile équipé d'une unité de communication embarquée adaptée à émettre et à recevoir des messages radio à destination ou en provenance d'une unité de bord de route communiquant avec une infrastructure à clé publique délivrant ledit certificat pseudonyme. Elle concerne également un véhicule automobile équipé d'une unité de 10 communication embarquée adaptée à mettre en oeuvre un tel procédé de téléchargement. ARRIERE-PLAN TECHNOLOGIQUE Grâce au développement des systèmes de transport intelligents (« Intelligent Transport Systems » en anglais, ou ITS), un véhicule automobile est 15 désormais adapté à communiquer sans fil, soit avec un autre véhicule automobile - on parle alors de communication de véhicule à véhicule, ou communication V2V (pour « Vehicle-to-Vehicle » en anglais) -, soit avec une unité de bord de route (« Road Side Unit » en anglais) situé dans l'infrastructure routière - on parle alors de communication de véhicule à infrastructure, ou communication V2I (pour 20 « Vehicle-to-Infrastructure » en anglais). Ces communications entre véhicules automobiles et unités de bord de route, plus généralement appelées communications « V2X », sont établies gratuitement grâce à l'échange de messages standardisés dans le domaine radiofréquence, par exemple selon la norme européenne ITS-G5. 25 Les messages échangés par un véhicule automobile contiennent des informations critiques pour ce véhicule automobile, et doivent donc être sécurisés pour prouver leur authenticité et leur intégrité. À cette fin, dans le cadre des systèmes de transport intelligents, une infrastructure à clé publique (« Public Key Infrastructure ») est déployée, cette 30 infrastructure à clé publique comprenant une autorité de certification (« Certificate Authority ») pour délivrer notamment des certificats numériques, appelés certificats pseudonymes (« Pseudonym Certificates »), à ce véhicule automobile. Pour des raisons de protection de la vie privée des utilisateurs de ces systèmes de transport intelligents, le véhicule automobile doit changer fréquemment, par exemple à chaque trajet, ses certificats pseudonymes pour pouvoir établir des communications V2X dans le système coopératif ITS. À cet effet, il est possible de stocker l'ensemble des certificats pseudonymes nécessaires au véhicule automobile pour la durée totale de son utilisation dans une mémoire interne du véhicule automobile. Cependant, la mise en oeuvre de cette solution demande une capacité de stockage à la fois importante et sécurisée, cette option s'avérant ainsi complexe et coûteuse. En effet, le nombre total de certificats pseudonymes nécessaires est élevé : par exemple, il est estimé à mille cinq cents certificats par an en Europe et peut aller jusqu'à cinq mille certificats par an aux États-Unis. Une autre solution consiste à renouveler régulièrement par téléchargement l'ensemble des certificats pseudonymes indispensables au véhicule automobile pour continuer à utiliser les services basés sur les 15 communications V2X au cours de la vie du véhicule automobile. On connaît notamment du document US 2011/0191581 un procédé de téléchargement d'un certificat pseudonyme par un véhicule automobile équipé d'une unité de communication embarquée (« On-Board Unit » ou OBU) adaptée à émettre et à recevoir des messages radio, par exemple selon la norme Bluetooth, 20 à destination ou en provenance d'un appareil mobile, comme le téléphone portable du conducteur dudit véhicule automobile, ayant un accès Internet, par exemple via une communication au travers d'un réseau utilisant la norme GSM ou UMTS, vers une autorité de certification délivrant le certificat pseudonyme. Un tel procédé de téléchargement est, d'une part, complexe à mettre en 25 oeuvre dans la mesure où il doit être adapté à tous types d'appareils mobiles, et, d'autre part, coûteux pour le conducteur du véhicule automobile à qui revient la charge de payer les coûts de communication entre son appareil mobile et l'infrastructure à clé publique. OBJET DE L'INVENTION 30 Afin de remédier aux inconvénients précités de l'état de la technique, la présente invention propose un procédé de téléchargement d'un certificat pseudonyme par un véhicule automobile utilisant une architecture de communication standardisée pour tous types de véhicule automobile et gratuite entre le véhicule automobile et l'infrastructure à clé publique. Plus particulièrement, on propose selon l'invention un procédé de téléchargement d'un certificat pseudonyme délivré par une infrastructure à clé publique pour un véhicule automobile équipé d'une unité de communication embarquée adaptée à émettre et à recevoir des messages radio, respectivement à destination ou en provenance d'une unité de bord de route principale adaptée à communiquer avec ladite infrastructure à clé publique, ledit procédé de téléchargement comportant les étapes successives suivantes : a) émettre, grâce à ladite unité de communication embarquée, un message d'authentification à destination de ladite unité de bord de route principale contenant une requête d'accès dudit véhicule automobile à ladite infrastructure à clé publique, b) recevoir, grâce à ladite unité de communication embarquée, un message d'accès au réseau en provenance de ladite unité de bord de route principale, ledit message d'accès au réseau contenant des informations de routage et d'identification sur ladite infrastructure à clé publique pour l'accès du véhicule automobile à ladite infrastructure à clé publique par l'intermédiaire de ladite unité de bord de route principale, c) émettre, grâce à ladite unité de communication embarquée, un message de chargement dudit certificat pseudonyme à destination de ladite unité 20 de bord de route principale, ledit message de chargement contenant une requête de certificat pseudonyme auprès de ladite infrastructure à clé publique, et d) recevoir, grâce à ladite unité de communication embarquée, un message de renouvellement en provenance de ladite unité de bord de route principale, ledit message de renouvellement contenant ledit certificat pseudonyme. 25 Le procédé de téléchargement selon l'invention présente l'avantage de garantir une gestion des certificats pseudonymes pour les communications V2X qui est simple à mettre en oeuvre. En effet, grâce au procédé de téléchargement selon l'invention, le conducteur du véhicule automobile n'a pas besoin d'appareil mobile pour 30 télécharger de nouveaux certificats pseudonymes et n'a pas à configurer ou à installer un outil spécifique sur son appareil mobile. La communication entre le véhicule automobile et l'infrastructure à clé publique pour le renouvellement des certificats pseudonymes du véhicule est réalisée de manière transparente pour celui-ci grâce à l'unité bord de route, qui est connectée à l'infrastructure à clé publique via le réseau d'infrastructure ou via le réseau Internet et qui joue le rôle de relais de communication entre le véhicule automobile et l'infrastructure à clé publique. En outre, le procédé de téléchargement selon l'invention n'engendre pas de coût supplémentaire pour une communication entre l'unité de communication embarquée et l'infrastructure à clé publique grâce à l'utilisation de l'unité de bord de route principale dont les communications avec le véhicule automobile sont gratuites pour celui-ci. Enfin, lorsque cela est nécessaire, le procédé de téléchargement selon l'invention peut être mis en oeuvre pour télécharger en même temps plusieurs certificats pseudonymes. D'autres caractéristiques non limitatives et avantageuses du procédé conforme à l'invention sont les suivantes : - lesdits messages radio sont émis ou reçus par ladite unité de 15 communication embarquée du véhicule automobile dans une bande de fréquence qui est comprise entre 5,855 gigahertz et 5,925 gigahertz ; - lesdits messages radio sont émis ou reçus par ladite unité de communication embarquée du véhicule automobile selon la norme IEEE 802.11p ou selon la norme européenne ITS-G5, encore appelée « profil 20 européen » ITS-G5 ; - préalablement à l'étape a), ladite unité de communication embarquée reçoit un message d'annonce en provenance de ladite unité de bord de route principale informant ledit véhicule automobile de la disponibilité d'un accès réseau à ladite infrastructure à clé publique au travers de ladite unité de bord de route 25 principale, et à l'étape a), ledit message d'authentification est généré en fonction dudit message d'annonce ; - à l'étape c), ladite unité de bord de route principale adresse ladite requête de certificat pseudonyme à ladite infrastructure à clé publique qui génère et envoie ledit certificat pseudonyme à ladite unité de bord de route principale ; 30 - ladite infrastructure à clé publique comprend une autorité de certification pseudonyme et une autorité de certification long terme, ladite autorité de certification pseudonyme recueille ladite requête de certificat pseudonyme adressée par ladite unité de bord de route principale pour générer et transférer à ladite autorité de certification long terme une demande de validation de ladite requête de certificat pseudonyme, ladite autorité de certification long terme répond positivement à la demande de validation, et ladite autorité de certification pseudonyme génère ledit certificat pseudonyme renvoyé à ladite unité de bord de route principale ; - à l'étape b), ledit message d'accès au réseau est généré en fonction dudit message d'authentification ; - à l'étape c), ladite requête de certificat pseudonyme du message de chargement est formée à partir des informations de routage et d'identification contenues dans ledit message d'accès au réseau. - ladite requête de certificat pseudonyme est formée : - d'une première partie destinée à l'autorité de certification pseudonyme, et chiffrée au moyen d'une clé de chiffrement de ladite autorité de certification pseudonyme, et - d'une deuxième partie destinée à l'autorité de certification long terme, et chiffrée au moyen d'une clé de chiffrement de ladite autorité de certification long terme ; - à l'étape d), ledit message de renouvellement contenant ledit certificat pseudonyme est généré en fonction dudit message de chargement ; - les messages émis, respectivement reçus, par ladite unité de communication embarquée à destination, respectivement en provenance, de ladite unité de bord de route principale transitent par une unité de communication embarquée auxiliaire d'un véhicule automobile auxiliaire et/ou par une unité de bord de route secondaire. L'invention propose également un véhicule automobile équipé d'une unité de communication embarquée adaptée à émettre et à recevoir des messages radio, respectivement à destination ou en provenance d'une unité de bord de route principale adaptée à communiquer avec une infrastructure à clé publique adaptée à délivrer un certificat pseudonyme, ladite unité de communication embarquée étant adaptée à mettre en oeuvre un procédé de téléchargement selon l'invention. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 est une vue schématique d'ensemble d'un véhicule automobile communiquant avec une unité de bord de route principale connectée à une infrastructure à clé publique et téléchargeant un nouveau certificat pseudonyme selon un premier mode de réalisation du procédé de téléchargement ; - la figure 2 est un schéma représentant les différents messages échangés entre le véhicule automobile, l'unité de bord de route et l'infrastructure à clé publique de la figure 1 lors du procédé de téléchargement ; - la figure 3 est un diagramme détaillé illustrant les différentes opérations mises en oeuvre lors du procédé de téléchargement d'un certificat pseudonyme par le véhicule automobile de la figure 1 ; - la figure 4 est une vue schématique d'ensemble d'un véhicule automobile communiquant avec un véhicule automobile auxiliaire relié sans fil à une unité de bord de route principale connectée à une infrastructure à clé publique, et téléchargeant un ou plusieurs nouveaux certificats pseudonymes selon un deuxième mode de réalisation du procédé de téléchargement ; - la figure 5 est une vue schématique d'ensemble d'un véhicule automobile communiquant avec une unité de bord de route secondaire reliée sans fil à une unité de bord de route principale connectée à une infrastructure à clé publique, et téléchargeant un nouveau certificat pseudonyme selon un troisième mode de réalisation du procédé de téléchargement. En préambule, on notera que les éléments identiques ou correspondants des différents modes de réalisation représentés sur les différentes figures seront 25 référencés par les mêmes signes de référence et ne seront pas décrits à chaque fois. On notera également que les références de clés comportant le suffixe « PrK » se rapportent à une clé privée (« Private Key »), le suffixe « PuK » à une clé publique (« Public Key »), le suffixe « EK » à une clé de chiffrement 30 (« Encryption Key »), et le suffixe « SK » à une clé secrète (« Secret Key »). Sur les figures 1, 4 et 5, on a représenté un véhicule automobile 10 circulant ou stationnant sur une route 1 à deux voies au bord de laquelle se trouve une unité de bord de route principale RSU. D'autres véhicules automobiles (non représentés dans un souci de simplification des figures) circulent ou stationnent également sur cette route 1 et d'autres unités de bord de route (non représentées dans un souci de simplification des figures) sont également situées sur le bord de cette route. Le véhicule automobile 10 évolue ici dans un environnement routier « intelligent » où il peut établir des communications dites « V2X », soit de type « V2V » avec d'autres véhicules automobiles voisins, soit de type « V21 » avec les autres unités de bord de route, pour échanger des messages radio avec les uns ou avec les autres. À cet effet, le véhicule automobile 10 est équipé d'une unité de communication embarquée OBU adaptée à émettre et à recevoir des messages radio, respectivement à destination ou en provenance d'autres véhicules automobiles ou d'autres unités de bord de route, ces messages radios étant portés par des ondes radio W1, W2, W3, W4 (voir figures 1, 4 et 5). Par onde radio, on entend toute onde électromagnétique dont la 15 fréquence, exprimée en gigahertz (GHz), est inférieure à 300 GHz. De préférence, les messages radio sont émis ou reçus par l'unité de communication embarquée OBU du véhicule automobile 10 dans une bande de fréquence comprise entre 5,855 GHz et 5,925 GHz. La bande de fréquence utilisée dans les différents modes de réalisation est ici la bande de fréquence 20 dite ITS-G5, ci-après référencée G5, telle que spécifiée par l'Institut Européen des Normes de Télécommunication (« European Telecommunications Standards Institute » ou ETSI) dans les normes ETSI ES 202 663 et ETSI EN 302 571. Les messages radio peuvent par exemple être émis ou reçus par l'unité de communication embarquée OBU du véhicule automobile 10 selon la 25 norme IEEE 802.11p ou selon la norme européenne ITS-G5. Les messages sécurisés, signés et/ou chiffrés peuvent par exemple être émis ou reçus par l'unité de communication embarquée OBU du véhicule automobile 10 selon la structure des messages sécurisés définie par la norme européenne ETSI TS 103 097 ou la norme américaine IEEE 1609.2. 30 Pour émettre et recevoir les messages radio, l'unité de communication embarquée OBU du véhicule automobile 10 comprend un dispositif d'émission et de réception d'ondes radio, par exemple une antenne 11 (voir figures 1, 4, et 5), qui capte et rayonne les ondes radio portant ces messages radio. En utilisant des ondes radio porteuses dans la bande de fréquence G5, la portée maximale de l'antenne 11 est d'environ mille mètres. En d'autres termes, un message radio émis par l'unité de communication embarquée OBU du véhicule automobile 10 ne peut être reçu par une entité réceptrice, c'est-à-dire un autre véhicule automobile ou une unité de bord de route, que si la distance entre le véhicule automobile 10 et l'entité réceptrice est inférieure à la portée maximale. Réciproquement, un message radio émis par une entité émettrice, c'est-à-dire un autre véhicule automobile ou une unité de bord de route, ne peut être reçu par l'unité de communication embarquée OBU du véhicule automobile 10 que si la distance entre l'entité émettrice et le véhicule automobile 10 est inférieure à la portée maximale. L'antenne 11 est reliée à l'unité de communication embarquée OBU, par exemple au moyen d'un câble électrique 12 à double sens. Dans un sens, lors de la réception d'un message radio par l'unité de communication embarquée OBU, une onde radio, en provenance d'autres véhicules automobiles ou d'autres unités de bord de route, est captée par l'antenne 11 du véhicule automobile 10 qui délivre un signal électrique représentatif du message radio reçu à l'unité de communication embarquée OBU au travers du câble électrique 12, l'unité de communication embarquée OBU traitant alors le signal électrique délivré. Dans l'autre sens, lors de l'émission d'un message radio par l'unité de communication embarquée OBU, l'unité de communication embarquée OBU génère et transmet un signal électrique représentatif du message radio émis à l'antenne 11 du véhicule automobile 10 grâce au câble électrique 12, cette antenne 11 rayonnant alors une onde radio rayonnée à destination d'autres véhicules automobiles ou d'autres unités de bord de route. Pour traiter, respectivement générer, les signaux électriques représentatifs des messages radio, l'unité de communication embarquée OBU comprend un processeur (non représenté) apte à extraire, respectivement à 30 former, les messages radio portés par les ondes radio captées ou rayonnées. Afin de sécuriser les communications V2X du véhicule automobile 10 et de garantir l'authenticité des messages radio émis ou reçus par l'unité de communication embarquée OBU, tout en protégeant la vie privée de l'utilisateur du véhicule automobile 10, le véhicule automobile 10 a besoin d'utiliser un certificat pseudonyme (non représenté mais référencé PC ci-après) afin de s'authentifier auprès des autres véhicules automobiles ou auprès des autres unités de bord de route. Ainsi, dans les différents modes de réalisation représentés sur les figures 1, 4, et 5, l'unité de communication embarquée OBU peut également émettre et recevoir des messages radio, respectivement à destination ou en provenance d'une unité de bord de route principale RSU qui communique avec une infrastructure à clé publique PKI délivrant ce certificat pseudonyme PC au véhicule automobile 10 par l'intermédiaire de l'unité de bord de route principale RSU. De manière générale, un certificat est un fichier numérique, qui est, par exemple, codé sous forme binaire afin de faciliter son traitement, son stockage ou son échange. Dans les exemples décrits ci-après, on considérera que le certificat pseudonyme PC, généré et délivré par l'infrastructure à clé publique PKI au véhicule automobile 10, est un fichier spécifique à ce véhicule automobile 10 qui contient : - des informations d'identification du véhicule automobile 10, par exemple une identité anonymisée du véhicule automobile 10 comme un numéro de série, - une clé publique de signature numérique OBU-PuK du véhicule automobile 10, et - des informations relatives à la durée de validité ou à la date d'expiration du certificat pseudonyme PC. De manière générale, une clé de signature numérique est un nombre, une suite de nombres, ou une fonction mathématique, permettant de signer les messages radio échangés entre le véhicule automobile 10 et les autres véhicules automobiles ou les autres unités de bord de route. Une clé privée OBU-PrK du véhicule automobile10, relative à la clé publique OBU-PuK du même véhicule automobile 10, permet d'apposer une signature numérique sur un message radio émis par son unité de communication embarquée OBU et permet ainsi, comme le permettrait une signature manuscrite sur un message écrit, d'authentifier que le véhicule automobile 10 est bien l'auteur et l'expéditeur de ce message radio. De plus, la signature numérique permet de garantir l'intégrité d'un message radio émis par le véhicule automobile 10. Ainsi, l'échange de messages radio entre le véhicule automobile 10 et d'autres véhicules automobiles ou d'autres unités de bord de route qui sont signés grâce au certificat pseudonyme PC délivré par l'infrastructure à clé publique PKI est sécurisé et assure la protection de la vie privée. Le certificat pseudonyme PC est signé par l'infrastructure à clé publique PKI qui le génère et le délivre. L'infrastructure à clé publique PKI assure la gestion de certificats numériques, et en particulier celle des certificats pseudonymes : génération, délivrance, stockage. L'infrastructure à clé publique PKI comporte notamment un ou plusieurs serveurs informatiques avec des moyens informatiques pour générer et chiffrer des certificats numériques. Selon une caractéristique particulièrement avantageuse du procédé selon l'invention, l'infrastructure à clé publique PKI comprend ici (voir par exemple figure 2) une autorité de certification pseudonyme PCA (« Pseudonym Certificate Authority ») et une autorité de certification long terme LTCA (« Long-Term Certificate Authority »), dont on verra par la suite les rôles dans les différents modes de réalisation du procédé de téléchargement. Dans les différents modes de réalisation représentés sur les figures 1, 4, et 5, l'unité de bord de route principale RSU est connectée à l'infrastructure à clé publique PKI, la connexion étant ici réalisée au moyen d'une liaison filaire 2, par exemple par câble de cuivre (type Ethernet) ou par fibre optique. En variante, la connexion peut être réalisée au moyen d'une liaison sans fil, par exemple une liaison WiFi, GSM, UMTS, ou 4G. Grâce à son processeur et selon une caractéristique particulièrement avantageuse de l'invention, l'unité de communication embarquée OBU du véhicule automobile 10 est adaptée à télécharger ce certificat pseudonyme PC, en mettant en oeuvre les étapes : a) d'émission d'un message d'authentification AUTH (voir figure 2) à destination de l'unité de bord de route principale RSU, b) de réception d'un message d'accès ACC au réseau (voir figure 2) en provenance de ladite unité de bord de route principale RSU, c) d'émission d'un message de chargement LOA (voir figure 2) du certificat pseudonyme PC à destination de l'unité de bord de route principale RSU, le message de chargement LOA contenant une requête PCR de certificat pseudonyme auprès de l'infrastructure à clé publique PKI, et plus précisément ici auprès de l'autorité de certification pseudonyme PCA, et d) de réception d'un message de renouvellement UPD (voir figure 2) en provenance de l'unité de bord de route principale RSU, le message de renouvellement UPD contenant le certificat pseudonyme PC délivré par l'infrastructure à clé publique PKI, et plus précisément ici par l'autorité de certification pseudonyme PCA, au véhicule automobile 10. Ici, ces étapes a) à d) sont mises en oeuvre au sein d'un procédé plus vaste, qui comporte trois phases consécutives, référencées respectivement P1, P2, P3 (voir par exemple figures 2 et 3), et qui permet d'assurer une communication sécurisée de bout en bout, entre le véhicule automobile 10 et l'infrastructure à clé publique PKI, en passant par l'unité de bord de route principale RSU. Bien que le procédé décrit ci-dessous soit mis en oeuvre pour télécharger un seul certificat pseudonyme, il peut être adapté de manière évidente afin de permettre le téléchargement de plusieurs certificats pseudonymes, en même temps, par l'exécution des mêmes étapes a), b), c) et d) et des mêmes phases P1, P2, et P3. La première phase P1 consiste, pour le véhicule automobile 10, à s'authentifier auprès de l'unité de bord de route principale RSU afin d'être autorisé à accéder à l'infrastructure à clé publique PKI au travers de l'unité de bord de route principale RSU. La première phase P1 est initiée préalablement à l'étape a) du procédé de téléchargement, par l'émission d'un message radio par l'unité de bord de route principale RSU, ci-après dénommé message d'annonce et référencé SAM (voir bloc A1, figure 3). L'unité de communication embarquée OBU du véhicule automobile 10 reçoit alors ce message d'annonce SAM en provenance de l'unité de bord de route principale RSU. Dans des systèmes de transport intelligents, les unités de bord de route principales, c'est-à-dire celles qui sont en communication avec des infrastructures à clé publique, émettent en permanence des messages d'annonce, ces messages radio étant susceptibles d'être reçus par les unités de communication embarquées des véhicules automobiles proches de ces unités de bord de route principales, circulant à portée de réception. Afin d'authentifier l'expéditeur de tels messages d'annonce, chacun d'eux est signé au moyen d'une clé privée RSU-PrK de l'unité de bord de route principale RSU, et, d'autre part, signé par l'unité de bord de route principale RSU au moyen de l'un des ses certificats numériques d'authentification. De manière avantageuse, le message d'annonce SAM informe ici le véhicule automobile 10 qu'un accès réseau à l'infrastructure à clé publique PKI est disponible au travers de l'unité de bord de route principale RSU. En d'autres termes, le message d'annonce SAM indique au véhicule automobile 10 circulant à portée de réception de l'unité de bord de route principale RSU que celle-ci est reliée à l'infrastructure à clé publique PKI, et en particulier ici à l'autorité de certification pseudonyme PCA habilitée à délivrer des certificats pseudonymes aux véhicules automobiles. Lorsque l'unité de communication embarquée OBU du véhicule automobile 10 reçoit le message d'annonce SAM en provenance de l'unité de bord de route principale RSU, le processeur de l'unité de communication embarquée OBU détermine si le véhicule automobile 10 a besoin ou non d'un nouveau certificat pseudonyme. Cette opération, également préalable à l'étape a), est représentée sur la figure 3 par le bloc A2. Si le véhicule automobile 10 n'a pas besoin de certificat pseudonyme, alors le procédé de téléchargement s'interrompt (voir bloc F1, figure 3). Dans le cas contraire, c'est-à-dire lorsque le véhicule automobile 10 a besoin d'un certificat pseudonyme, le procédé de téléchargement continue (voir bloc A3, figure 3) en vérifiant l'authenticité du message d'annonce SAM grâce à la signature numérique incluse dans le message d'annonce SAM et au certificat numérique de l'unité de bord de route principale RSU ayant servi à le signer. Ensuite, le processeur de l'unité de communication embarquée OBU du véhicule automobile 10 génère une clé secrète OBU-SK qu'elle envoie dans le message d'authentification RUTH (voir figure 2), à l'unité de bord de route principale RSU, lors de l'étape a), représentée par le bloc A3 sur la figure 3. Ce message d'authentification AUTH est, de préférence, généré en fonction du message d'annonce SAM reçu précédemment (voir bloc A1, figure 3) par l'unité de communication embarquée OBU du véhicule automobile 10. En particulier, le message d'authentification AUTH est ici : - chiffré grâce à la clé de chiffrement RSU-EK de l'unité de bord de route principale RSU contenue dans le certificat numérique de l'unité de bord de route principale RSU envoyée dans le message d'annonce SAM, et - signé grâce à une clé privée OBU-PrK1 associée à un certificat pseudonyme valide VPC du véhicule automobile 10 enregistré dans une mémoire interne sécurisée de l'unité de communication embarquée OBU. En envoyant un tel message d'authentification AUTH à l'unité de bord de route principale RSU, le véhicule automobile 10, par l'intermédiaire de son unité de communication embarquée OBU, prouve son identité auprès de l'unité de bord de route principale RSU, et requiert ainsi, par l'envoi de ce message d'authentification AUTH, un accès à l'infrastructure à clé publique PKI. Lors de la réception du message d'authentification AUTH par l'unité de bord de route principale RSU, celle-ci vérifie (bloc B1 figure 3) le certificat pseudonyme valide VPC du véhicule automobile 10 et la signature numérique du message d'authentification AUTH. Ensuite, une fois que le véhicule automobile 10 est authentifié auprès de l'unité de bord de route principale RSU, celle-ci vérifie (bloc B2 figure 3) que le véhicule automobile 10 est autorisé à avoir un accès au réseau pour le téléchargement du certificat pseudonyme PC. Lorsque l'unité de bord de route principale RSU a déterminé que le véhicule automobile 10 était autorisé à avoir un accès au réseau, l'unité de bord de route principale RSU envoie, lors de l'étape b) (voir figure 2 et bloc B3 figure 3), les paramètres nécessaires pour accéder au service de téléchargement de certificat pseudonyme dans le message d'accès ACC au réseau, qui est reçu par le véhicule automobile 10 grâce à son unité de communication embarquée OBU. Selon une caractéristique particulièrement avantageuse du procédé selon l'invention, le message d'accès ACC au réseau envoyé par l'unité de bord de route principale RSU contient des informations de routage et d'identification sur l'infrastructure à clé publique PKI pour l'accès du véhicule automobile 10 à cette infrastructure à clé publique PKI, en particulier ici à l'autorité de certification pseudonyme PCA. Plus précisément, ce message d'accès ACC au réseau comprend : - une adresse telle qu'une adresse IP, du serveur de l'infrastructure à clé publique PKI, - un certificat numérique d'identification de l'autorité de certification 5 pseudonyme PCA, et - une information d'horodatage indiquant la date et l'heure de l'envoi du message d'accès ACC au réseau. L'ensemble de ces informations sont cryptées au moyen de la clé secrète OBU-SK partagée préalablement entre le véhicule automobile 10 et l'unité 10 de bord de route principale RSU. Ainsi, le message d'accès ACC au réseau est ici généré en fonction du message d'authentification AUTH qui contient cette clé secrète OBU-SK du véhicule automobile 10. À la fin de cette première phase P1 du procédé de téléchargement, le 15 véhicule automobile 10 et l'unité de bord de route principale RSU se sont mutuellement authentifiés l'un auprès de l'autre et partagent désormais la clé secrète OBU-SK avec laquelle le véhicule automobile 10 et l'unité de bord de route principale RSU vont pouvoir communiquer entre eux de manière sécurisée. Lors de la deuxième phase P2, le véhicule automobile 10 va envoyer une 20 requête PCR de certificat pseudonyme à l'infrastructure à clé publique PKI par l'intermédiaire de l'unité de bord de route principale RSU et, si sa requête PCR de certificat pseudonyme est valide, télécharger un certificat pseudonyme PC délivré par l'infrastructure à clé publique PKI requêtée par le véhicule automobile 10. Ainsi, lors de l'étape c) du procédé de téléchargement selon l'invention, 25 l'unité de communication embarquée OBU du véhicule automobile 10 émet le message de chargement LOA de ce certificat pseudonyme PC à destination de l'unité de bord de route principale RSU (voir bloc C1 de la figure 3). Ce message de chargement LOA contient la requête PCR de certificat pseudonyme auprès de l'infrastructure à clé publique PKI, et également un code 30 d'authentification d'empreinte cryptographique de message (« hash message authentication code »), référencé HMAC ci-après, qui est formé, autrement dit calculé, à partir de cette requête PCR de certificat pseudonyme au moyen de la clé secrète OBU-SK partagée. De manière générale, un code d'authentification d'empreinte cryptographique de message HMAC est un code pour authentifier un message en utilisant une fonction cryptographique, appelée fonction de hachage (« hash function »), en combinaison avec une clé secrète. Une fonction de hachage est une fonction mathématique cryptographique qui génère une empreinte de taille fixe, on parle aussi de condensat ou de cendre, à partir d'un message de taille arbitraire. Des fonctions classiques de hachage telles que MD5 ou SHA-1 peuvent être par exemple utilisées. Selon une caractéristique particulièrement avantageuse du procédé selon l'invention, la requête PCR de certificat pseudonyme contenue dans le message de chargement LOA est formée à partir des informations de routage et d'identification contenues dans le message d'accès ACC au réseau, et signée. Plus particulièrement, la requête PCR de certificat pseudonyme émise par l'unité de communication embarquée OBU du véhicule automobile 10 est formée d'une première partie PL1 destinée à l'autorité de certification pseudonyme PCA et d'une deuxième partie PL2 destinée à l'autorité de certification long terme LTCA. De manière avantageuse, la requête PCR de certificat pseudonyme est formée par la concaténation des première et deuxième parties PL1, PL2. La première partie PU contient des premières informations IN F01, qui sont générées par l'unité de communication embarquée OBU du véhicule automobile 10 et qui comprennent ici une ou plusieurs clés pseudonymes PsK du véhicule automobile 10 à inclure dans le certificat pseudonyme PC requis auprès de l'autorité de certification pseudonyme PCA. Les clés pseudonymes PsK sont générées par l'unité de communication embarquée OBU du véhicule automobile 10. La première partie PU est de préférence chiffrée au moyen de la clé de chiffrement PCA-EK de l'autorité de certification pseudonyme PCA. La deuxième partie PL2 est elle formée à partir de deuxièmes informations INFO2, et des premières informations INFO1 destinées à l'autorité de certification pseudonyme PCA. Par exemple, la deuxième partie PL2 peut être formée par la concaténation des deuxièmes informations INFO2 et d'une empreinte H1 des premières informations INFO1. Les deuxièmes informations INFO2, qui sont générées par l'unité de communication embarquée OBU du véhicule automobile 10, contiennent une empreinte de la ou des clés pseudonymes PsK contenues dans les premières informations INFO1, une donnée relative aux durées de validité de ces clés pseudonymes PsK, et une information d'horodatage indiquant la date et l'heure de l'envoi de la requête PCR de certificat pseudonyme par l'unité de communication embarquée OBU du véhicule automobile 10. La deuxième partie PL2 est de préférence signée avec une clé privée long terme OBU-PrK2 du véhicule automobile 10 puis chiffrée au moyen de la clé de chiffrement LTCA-EK de l'autorité de certification long terme LTCA. À la réception du message de chargement LOA émis par l'unité de communication embarquée OBU du véhicule automobile 10, l'unité de bord de route principale RSU vérifie (voir bloc D1, figure 3) l'intégrité de ce message de chargement LOA en calculant l'empreinte de la requête PCR de certificat pseudonyme et en comparant le résultat obtenu avec le code d'authentification d'empreinte cryptographique de message HMAC envoyé avec cette requête PCR de certificat pseudonyme. Si l'empreinte est différente du code d'authentification d'empreinte cryptographique de message HMAC, alors cela signifie que les données contenues dans la requête PCR de certificat pseudonyme ont été corrompues. Le procédé de téléchargement s'interrompt alors à ce stade (cf. bloc F1 de fin de procédé sur la figure 3). Si l'empreinte est identique au code d'authentification d'empreinte cryptographique de message HMAC, alors cela prouve que l'intégrité des données 25 contenues dans la requête PCR de certificat pseudonyme a été maintenue. Dans ce cas-là, l'unité de bord de route principale RSU adresse (voir figure 2 et bloc D2 de la figure 3) la requête PCR de certificat pseudonyme à l'infrastructure à clé publique PKI. Plus particulièrement ici, la requête PCR de certificat pseudonyme est transmise à l'autorité de certification pseudonyme PCA 30 faisant partie de l'infrastructure à clé publique PKI. L'autorité de certification pseudonyme PCA recueille donc la requête PCR de certificat pseudonyme adressée par l'unité de bord de route principale RSU (cf. bloc D3 figure 3) et vérifie notamment que les premières informations INFO1 contenues dans la requête PCR de certificat pseudonyme lui correspondent. Si non, le procédé de téléchargement s'interrompt (cf. bloc F1 figure 3). Lorsque les premières informations INFO1 sont correctes, alors l'autorité de certification pseudonyme PCA calcule (voir bloc D4 figure 3) une empreinte HC1 à partir de ces premières informations INFO1. L'autorité de certification pseudonyme PCA transfère alors (voir figure 2 et bloc D5 figure 3) à l'autorité de certification long terme LTCA une demande de validation PCRV de la requête PCR de certificat pseudonyme. Cette demande de validation PCRV est de manière générale formée à partir des premières et deuxièmes informations INFO1, INFO2 des autorités de certification pseudonyme PCA et long terme LTCA. Le contenu de la demande de validation PCRV est ici formée à partir de la concaténation de la deuxième partie PL2 de la requête PCR de certificat pseudonyme et de l'empreinte HC1 calculée précédemment par l'autorité de certification pseudonyme PCA à partir des premières informations INFO1. De plus, la demande de validation PCRV est de préférence signée au moyen de la clé privée PCA-PrK de l'autorité de certification pseudonyme PCA avant envoi à l'autorité de certification long terme LTCA. À réception de la demande de validation PCRV, l'autorité de certification long terme LTCA effectue les différentes opérations suivantes (voir bloc D6 figure 3) : - vérification du certificat numérique de l'autorité de certification pseudonyme PCA, - vérification de la signature de la demande de validation PCRV, - extraction et déchiffrement de la deuxième partie PL2 de la requête PCR de certificat pseudonyme, - comparaison entre l'empreinte HC1 transmise dans la demande de validation PCRV et l'empreinte H1 transmise dans la requête PCR de certificat pseudonyme, plus précisément dans sa deuxième partie PL2, et - vérification du certificat long terme LTC du véhicule automobile 10 et de la signature numérique contenue dans la deuxième partie PL2. Lorsque la comparaison du bloc D6 montre que l'empreinte HC1 est identique à l'empreinte H1, alors l'autorité de certification long terme LTCA répond positivement à la demande de validation PCRV, et envoie une réponse ANS (voir figure 2 et bloc D7 de la figure 3) positive à l'autorité de certification pseudonyme PCA. L'infrastructure à clé publique PKI, et plus particulièrement ici l'autorité de certification pseudonyme PCA, génère et envoie (cf. bloc D8 figure 3) le certificat pseudonyme PC requis par le véhicule automobile 10 à l'unité de bord de route principale RSU dans un message de livraison PCD du certificat pseudonyme PC (voir figures 2 et 3). Ainsi, lors de l'étape d), le véhicule automobile 10 reçoit, grâce à son unité de communication embarquée OBU, le message de renouvellement UPD (voir figure 2 et bloc D9 figure 3) en provenance de l'unité de bord de route principale RSU, qui contient le certificat pseudonyme PC délivré par l'autorité de certification pseudonyme PCA de l'infrastructure à clé publique PKI. De préférence, ce message de renouvellement UPD est généré en fonction dudit message de chargement LOA. Lorsque la comparaison du bloc D6 montre que l'empreinte HC1 est différente de l'empreinte H1, alors l'autorité de certification long terme LTCA répond négativement (voir bloc D7a figure 3) à la demande de validation PCRV, et envoie une réponse ANS (voir figures 2 et 3) négative à l'autorité de certification pseudonyme PCA qui envoie un message d'erreur ERR (voir figure 2 et bloc D8a figure 3) à l'unité de bord de route principale RSU qui le transfère (voir bloc D9a figure 3) au véhicule automobile 10. Dans ce cas, le procédé de téléchargement prend fin à ce stade (voir bloc Fi figure 3). Dans une troisième phase P3 du procédé de téléchargement (cf. figures 2 et 3), le véhicule automobile 10, et plus particulièrement son unité de 25 communication embarquée OBU, accuse réception du certificat pseudonyme PC téléchargé. Ainsi, dans une étape e), postérieure à l'étape d), l'unité de communication embarquée OBU émet (cf. bloc El figure 3) un message radio, dit premier message d'acquittement ACK1 (voir figure 2) à destination de l'unité de 30 bord de route principale RSU informant l'unité de bord de route principale RSU de la réception du message de renouvellement UPD contenant le certificat pseudonyme PC requis. De préférence, un deuxième message d'acquittement ACK2 (voir figure 2) est transmis à l'infrastructure à clé publique PKI, et ici à l'autorité de certification pseudonyme PCA, par l'unité de bord de route principale RSU. Ce deuxième message d'acquittement ACK2 est alors transféré à l'autorité de certification long terme LTCA qui met à jour un registre de base de données dans lequel toutes les demandes relatives aux requêtes de certificats pseudonymes reçues de la part d'une même unité de communication embarquée de véhicule automobile sont recensées. Dans une autre étape du procédé, on peut prévoir que l'unité de communication embarquée OBU du véhicule automobile 10 enregistre le certificat pseudonyme PC délivré par l'infrastructure à clé publique PKI dans une mémoire numérique de ladite unité. On vient de décrire le premier mode de réalisation du procédé selon l'invention, représenté sur la figure 1, selon lequel les échanges de messages radio entre l'unité de communication embarquée OBU du véhicule automobile 10 et l'unité de bord de route principale RSU se faisait de manière directe, supposant que pendant toute la durée du procédé de téléchargement du certificat pseudonyme PC le véhicule automobile 10 était situé à portée de l'unité de bord de route principale RSU. Lorsque le véhicule automobile 10, désirant télécharger de nouveaux certificats pseudonymes via l'échange de messages radio, n'est pas situé dans la zone de couverture d'une unité de bord de route principale RSU reliée à l'infrastructure à clé publique PKI pour la délivrance desdits certificats pseudonymes pour pouvoir le faire, il est avantageux d'utiliser les autres véhicules automobiles ou les autres unités de bord de route qui ne sont pas directement reliées à l'infrastructure à clé publique PKI. Ainsi, dans d'autres modes de réalisation du procédé de téléchargement, les messages radio émis, respectivement reçus, par l'unité de communication embarquée OBU à destination, respectivement en provenance, de l'unité de bord de route principale RSU transitent, soit par une unité de communication embarquée auxiliaire OBU2 d'un véhicule automobile auxiliaire 20, comme dans le deuxième mode de réalisation représenté sur la figure 4, soit par une unité de bord de route secondaire RSU2 comme dans le troisième mode de réalisation représenté sur la figure 5. De cette façon, les véhicules automobiles auxiliaires 20 ou les unités de bord de route secondaires RSU2 peuvent jouer le rôle de relais pour transmettre la requête de certificat pseudonyme du véhicule automobile 10 jusqu'à atteindre l'unité de bord de route principale RSU. Les véhicules auxiliaires 20 ou les unités de bord de route secondaires RSU2 permettent donc d'élargir la zone de couverture d'une unité de bord de route principale RSU reliée à une infrastructure à clé publique PKI. Selon une variante, le procédé de téléchargement selon l'invention peut impliquer l'utilisation d'une pluralité de véhicules automobiles auxiliaires et/ou une pluralité d'unités de bord de route secondaires pour la transmission des messages nécessaires à sa mise en oeuvre. Selon une autre variante, le procédé de téléchargement peut, dans un premier temps, par exemple pour les étapes a) et b), ne mettre en jeu que le véhicule automobile et l'unité de bord de route principale, puis dans un deuxième temps, par exemple pour les étapes c) et d), mettre en jeu également les véhicules automobiles auxiliaires et/ou les unités de bord de route secondaires. Ceci trouve une application lorsque le procédé commence alors que le véhicule automobile est dans la zone de couverture de l'unité de bord de route principale mais finit alors que, par suite de l'éloignement du véhicule automobile de l'unité de bord de route principale, le véhicule automobile n'est plus dans la zone de couverture de l'unité de bord de route principale.20 REVENDICATIONS1. Procédé de téléchargement d'un certificat pseudonyme (PC) délivré par une infrastructure à clé publique (PKI) pour un véhicule automobile (10) équipé d'une unité de communication embarquée (OBU) adaptée à émettre et à recevoir des messages radio, respectivement à destination ou en provenance d'une unité de bord de route principale (RSU) adaptée à communiquer avec ladite infrastructure à clé publique (PKI), ledit procédé de téléchargement comportant les étapes successives suivantes : a) émettre, grâce à ladite unité de communication embarquée (OBU), un message d'authentification (AUTH) à destination de ladite unité de bord de route principale (RSU) contenant une requête d'accès dudit véhicule automobile (10) à ladite infrastructure à clé publique (PKI), b) recevoir, grâce à ladite unité de communication embarquée (OBU), 15 un message d'accès (ACC) au réseau en provenance de ladite unité de bord de route principale (RSU), ledit message d'accès (ACC) au réseau contenant des informations de routage et d'identification sur ladite infrastructure à clé publique (PKI) pour l'accès du véhicule automobile (10) à ladite infrastructure à clé publique (PKI) par l'intermédiaire de ladite unité de bord de route principale (RSU), 20 c) émettre, grâce à ladite unité de communication embarquée (OBU), un message de chargement (LOA) dudit certificat pseudonyme (PC) à destination de ladite unité de bord de route principale (RSU), ledit message de chargement (LOA) contenant une requête (PCR) de certificat pseudonyme auprès de ladite infrastructure à clé publique (PKI), et 25 d) recevoir, grâce à ladite unité de communication embarquée (OBU), un message de renouvellement (UPD) en provenance de ladite unité de bord de route principale (RSU), ledit message de renouvellement (UPD) contenant ledit certificat pseudonyme (PC). 2. Procédé de téléchargement selon la revendication 1, selon lequel 30 lesdits messages radio sont émis ou reçus par ladite unité de communication embarquée (OBU) du véhicule automobile (10) dans une bande de fréquence (G5) qui est comprise entre 5,855 gigahertz et 5,925 gigahertz. 3. Procédé de téléchargement selon l'une des revendications 1 et 2, selon lequel lesdits messages radio sont émis ou reçus par ladite unité decommunication embarquée (OBU) du véhicule automobile (10) selon la norme IEEE 802.11p ou selon la norme européenne ITS-G5. 4. Procédé de téléchargement selon l'une des revendications 1 à 3, selon lequel : - préalablement à l'étape a), ladite unité de communication embarquée (OBU) reçoit un message d'annonce (SAM) en provenance de ladite unité de bord de route principale (RSU) informant ledit véhicule automobile (10) de la disponibilité d'un accès réseau à ladite infrastructure à clé publique (PKI) au travers de ladite unité de bord de route principale (RSU), et - à l'étape a), ledit message d'authentification (AUTH) est généré en fonction dudit message d'annonce (SAM). 5. Procédé de téléchargement selon l'une des revendications 1 à 4, selon lequel, à l'étape c), ladite unité de bord de route principale (RSU) adresse ladite requête (PCR) de certificat pseudonyme à ladite infrastructure à clé publique (PKI) qui génère et envoie ledit certificat pseudonyme (PC) à ladite unité de bord de route principale (RSU). 6. Procédé de téléchargement selon l'une des revendications 1 à 5, selon lequel, ladite infrastructure à clé publique (PKI) comprend une autorité de certification pseudonyme (PCA) et une autorité de certification long terme (LTCA), et selon lequel : - ladite autorité de certification pseudonyme (PCA) recueille ladite requête (PCR) de certificat pseudonyme adressée par ladite unité de bord de route principale (RSU) pour générer et transférer à ladite autorité de certification long terme (LTCA) une demande de validation (PCRV) de ladite requête (PCR) de certificat pseudonyme, - ladite autorité de certification long terme (LTCA) répond positivement à la demande de validation (PCRV), et - ladite autorité de certification pseudonyme (PCA) génère ledit certificat pseudonyme (PC) renvoyé à ladite unité de bord de route principale (RSU). 7. Procédé de téléchargement selon l'une des revendications 1 à 6, selon lequel, à l'étape b), ledit message d'accès (ACC) au réseau est généré en fonction dudit message d'authentification (AUTH). 8. Procédé de téléchargement selon l'une des revendications 1 à 7,selon lequel, à l'étape c), ladite requête (PCR) de certificat pseudonyme du message de chargement (LOA) est formée à partir des informations de routage et d'identification contenues dans ledit message d'accès (ACC) au réseau. 9. Procédé de téléchargement selon la revendication 6, selon lequel, ladite requête (PCR) de certificat pseudonyme est formée : - d'une première partie (PL1) destinée à l'autorité de certification pseudonyme (PCA), et chiffrée au moyen d'une clé de chiffrement (PCA-EK) de ladite autorité de certification pseudonyme (PCA), et - d'une deuxième partie (PL2) destinée à l'autorité de certification long 10 terme (LTCA), et chiffrée au moyen d'une clé de chiffrement (LTCA-EK) de ladite autorité de certification long terme (LTCA). 10. Procédé de téléchargement selon l'une des revendications 1 à 9, selon lequel, à l'étape d), ledit message de renouvellement (UPD) contenant ledit certificat pseudonyme (PC) est généré en fonction dudit message de 15 chargement (LOA). 11. Procédé de téléchargement selon l'une des revendications 1 à 10, selon lequel les messages émis, respectivement reçus, par ladite unité de communication embarquée (OBU) à destination, respectivement en provenance, de ladite unité de bord de route principale (RSU) transitent par une unité de 20 communication embarquée auxiliaire (OBU2) d'un véhicule automobile auxiliaire (20) et/ou par une unité de bord de route secondaire (RSU2). 12. Véhicule automobile (10) équipé d'une unité de communication embarquée (OBU) adaptée à émettre et à recevoir des messages radio, respectivement à destination ou en provenance d'une unité de bord de route 25 principale (RSU) adaptée à communiquer avec une infrastructure à clé publique (PKI) adaptée à délivrer un certificat pseudonyme (PC), ladite unité de communication embarquée (OBU) étant adaptée à mettre en oeuvre un procédé de téléchargement selon l'une des revendications 1 à 11.