FR 3082089 A1 20191206 FR 1854687 A 20180531 Procédé et système de déverrouillage à distance d'un véhicule automobile La présente invention se rapporte de manière générale aux domaines de l'automobile et des communications et concerne plus précisément un procédé de déverrouillage à distance d'un véhicule automobile. La protection des véhicules automobiles contre le vol implique l'existence de clefs légitimant celui qui porte une de ces clefs à utiliser le véhicule correspondant. L'authentification de l'utilisateur est aujourd'hui effectuée par un organe de commande dans le véhicule automobile, apte à verrouiller/déverrouiller les portes du véhicule automobile, et à autoriser le démarrage d'un moteur du véhicule. Afin de simplifier la gestion des clefs notamment pour les services d'auto- partage, des clefs virtuelles mémorisées dans des terminaux mobiles tels que des smartphones ou des ordinateurs portables ont été créées. Une telle clef virtuelle permet à un utilisateur d'ouvrir son véhicule en faisant communiquer son terminal mobile, dans lequel est mémorisée cette clef virtuelle, avec l'organe de commande du véhicule, grâce à une liaison sans fil, de type wi-fi (d'après les normes IEEE 802.11), NFC (d'après l'anglais « Near Field Communication »), « Bluetooth », « Bluetooth low energy », ou tout moyen de communication sans fil fourni en standard dans les smartphones. Le document FR3030830 décrit la génération de telles clefs virtuelles et leur utilisation. Des clefs virtuelles sont générées par un serveur distant de gestion des véhicules associées à un constructeur. Ce serveur distant dispose pour chaque véhicule, d'une clef racine et de paramètres de dérivation permettant de générer, à partir de cette clef racine, une clef virtuelle dont la durée d'utilisation est précisée dans les paramètres de dérivation. La clef virtuelle et les paramètres de dérivation sont transmis au terminal mobile d'un utilisateur de manière sécurisée grâce à un cryptage généré par un « coffre-fort 2 virtuel » que l'utilisateur doit télécharger sur son terminal mobile. Ce « coffre-fort virtuel » enregistre la clef virtuelle et les paramètres de dérivation reçus, et les transmet au véhicule lorsque l'utilisateur souhaite le déverrouiller, sous forme cryptée grâce au « coffre-fort virtuel ». Le véhicule a en mémoire la clef 5 racine, enregistrée en sortie d'usine dans le véhicule, ce qui lui permet de vérifier, grâce aux paramètres de dérivation, l'intégrité de la clef virtuelle et sa validité, avant d'accepter le déverrouillage du véhicule. Cette solution a l'avantage de ne pas nécessiter d'être sous couverture d'un réseau de communication au moment du déverrouillage du véhicule, de ne 10 pas utiliser pour la sécurisation des données transmises la carte SIM (d'après l'anglais « Subscriber Identity Module ») ce qui nécessiterait une dépendance à un opérateur mobile donné, et de ne pas utiliser le cryptage d'une technologie wi-fi ou NFC dont le piratage est relativement aisé. Cependant cette solution présente l'inconvénient de reposer sur une application relativement complexe à 15 télécharger sur le terminal mobile de l'utilisateur. De plus elle ne protège pas l'utilisateur contre une attaque de type «Homme du milieu », notamment contre l'interception, la modification, la falsification ou la ré-injection de messages, à moins d'utiliser un protocole sécurisé tel que TLS (d'après l'anglais « Transport Layer Security ») mais qui rend l'expérience utilisateur dissuasive lorsque le lien 20 de communication entre le terminal utilisateur et le véhicule est à bas débit du type BLE (d'après l'anglais « Bluetooth® Low Energy »). Un des buts de l'invention est de remédier à au moins une partie des 25 inconvénients de la technique antérieure en fournissant un procédé et un système de déverrouillage à distance d'un véhicule, qui soient simples à mettre en oeuvre, notamment utilisables à faible débit de communication entre le véhicule et le terminal mobile de l'utilisateur, tout en protégeant celui-ci contre des attaques de type « Homme du milieu », et sans nécessiter de 30 communications régulières entre le véhicule et un serveur distant. 3 A cette fin, l'invention propose un procédé de déverrouillage d'au moins une partie d'un véhicule automobile par un utilisateur équipé d'un terminal mobile, ledit procédé étant mis en oeuvre par un organe de commande dudit véhicule automobile, ledit procédé étant caractérisé en ce qu'il comporte les 5 étapes de : - réception d'au moins un jeton d'utilisation signé, envoyé audit véhicule par ledit terminal mobile, ledit jeton d'utilisation ne servant que pour une durée d'utilisation limitée dudit véhicule, - authentification dudit jeton d'utilisation en utilisant une clef de chiffrement 10 publique associée à un tiers habilité à déverrouiller ledit véhicule, - déverrouillage de ladite au moins une partie dudit véhicule lorsque ladite authentification résulte en un jeton d'utilisation valide. Grâce à l'invention, le déverrouillage du véhicule par un nouvel utilisateur pour lequel le véhicule n'a pas de données utilisateur est possible, sans que le 15 véhicule soit connecté à un réseau de télécommunication. En effet le véhicule n'authentifie pas directement l'utilisateur mais le jeton d'utilisation, grâce à la clef de chiffrement publique associée à un tiers distinct de l'utilisateur ou de son terminal mobile. De plus ce procédé ne nécessite pas d'accès préalable au véhicule par l'utilisateur pour configurer ou sécuriser la connexion entre le 20 véhicule et son terminal mobile. Avantageusement, le procédé selon l'invention comporte en outre une étape de lecture ou de déchiffrement, d'une clef de chiffrement publique associée audit terminal mobile. Cette clef permet au véhicule de s'assurer de l'identité du terminal mobile avec lequel il communique lors de la mise en place 25 ultérieure d'un secret commun avec ledit terminal permettant de sécuriser la liaison Bluetooth® avant envoi d'une commande de déverrouillage par le terminal. Selon une caractéristique avantageuse de l'invention, l'étape d'authentification dudit jeton d'utilisation est suivie d'une étape de sécurisation 30 d'une liaison « Bluetooth® Low Energy » non sécurisée entre ledit terminal mobile et ledit véhicule, par envoi par ledit véhicule audit terminal mobile d'un 4 message comportant une valeur numérique apte à permettre la génération ou la lecture par ledit terminal mobile d'un nombre aléatoire servant à la mise en place par ledit terminal mobile d'une liaison « Bluetooth® Low Energy » sécurisée par la lecture d'une commande nécessitant une telle sécurisation. 5 Ledit message est préférentiellement signé par le véhicule, ce qui permet au terminal utilisateur d'authentifier le véhicule. Cette caractéristique avantageuse de l'invention permet une protection contre une attaque de type « Homme du milieu » sans utiliser de protocole gourmand en bande passante tel que TLS qui dégrade fortement l'expérience 10 utilisateur pour des communications sur un lien bas débit. Elle permet la réutilisation de mécanismes existants dans le protocole « Bluetooth® Low Energy » mais sans nécessiter d'interface Homme-machine, notamment de moyens d'affichage sur le véhicule, ou de lecteur de code barre sur le terminal mobile, ou encore de canal de communication tiers. 15 Avantageusement, ledit message comporte une clef de chiffrement symétrique ou des moyens de génération d'une clef de chiffrement symétrique. Cette clef permet une sécurisation au niveau applicatif du procédé de déverrouillage. En effet le chiffrement des messages entre le terminal utilisateur et le véhicule en utilisant cette clef symétrique protège contre une application 20 malveillante sur le terminal utilisateur, car cette seconde couche de sécurité couvre l'ensemble du canal de communication. De surcroit cette sécurisation applicative permet de palier la découverte future et très probable de vulnérabilités au niveau du protocole BLE ou de son implémentation qui permettrait à un tiers d'écouter, modifier, de relayer ou de bloquer les messages 25 transitant sur l'interface radio, ou d'en ajouter. Avantageusement, ladite valeur numérique et lesdits moyens de génération correspondent à une clef publique de type courbe elliptique générée par ledit véhicule. Cette implémentation a l'avantage de ne pas échanger directement sur l'interface BLE le nombre aléatoire ou la clef de chiffrement 30 symétrique permettant sa sécurisation au niveau physique ou applicatif. 5 Avantageusement encore, préalablement à son envoi, ledit message est chiffré par ledit véhicule en utilisant la clef de chiffrement publique associée audit terminal mobile. Cette implémentation est utile lorsque le nombre aléatoire ou la clef de chiffrement symétrique sont générés et envoyés par le véhicule au 5 terminal, ce qui a l'avantage d'une implémentation simple du procédé. Ainsi un « Homme du milieu » ne peut pas utiliser le contenu du message, avant sécurisation au niveau physique de la connexion entre le terminal mobile et le véhicule. Avantageusement encore, l'envoi dudit message est suivi d'une étape de 10 réception par ledit véhicule, d'un message de contrôle envoyé par ledit terminal mobile, d'une étape de réception d'une commande de déverrouillage envoyée par ledit terminal mobile et d'une étape de vérification que le temps écoulé entre la réception du message de contrôle et la réception de ladite commande de déverrouillage est inférieur à un seuil maximal de durée. Cette procédure permet 15 de protéger le déverrouillage du véhicule d'une attaque dite « par retardement », dans laquelle le message envoyé par le terminal mobile serait intercepté et rejoué tel quel, une fois l'utilisateur éloigné, entre une personne mal intentionnée et le véhicule. Avantageusement encore, le procédé selon l'invention comporte une 20 étape de vérification d'une valeur d'un compteur contenue dans ledit message de contrôle, représentative d'un nombre de messages émis par ledit terminal mobile à destination dudit véhicule. Cela permet une protection contre une attaque du type « re-jeu » simple du message. L'invention concerne aussi un système de déverrouillage d'au moins une 25 partie d'un véhicule automobile par un utilisateur équipé d'un terminal mobile, ledit système étant caractérisé en ce qu'il comporte : un serveur distant apte à authentifier ledit utilisateur et à générer au moins un jeton d'utilisation associé audit utilisateur et ne servant qu'à une durée d'utilisation limitée dudit véhicule, à signer ledit jeton d'utilisation avec une clef 30 de chiffrement privée associée audit serveur distant, et à envoyer audit terminal mobile ledit jeton d'utilisation signé, 6 ledit terminal mobile, étant apte à communiquer avec ledit serveur distant pour authentifier ledit utilisateur et recevoir ledit jeton d'utilisation signé, et apte à communiquer avec ledit véhicule pour envoyer ledit jeton d'utilisation signé audit véhicule, 5 ledit véhicule automobile, étant apte à recevoir ledit jeton d'utilisation signé envoyé par ledit terminal mobile, à authentifier ledit jeton d'utilisation en utilisant une clef publique associée audit serveur distant, et à déverrouiller ladite au moins une partie dudit véhicule lorsque ledit jeton d'utilisation valide ce déverrouillage. 10 Il est à noter que la communication entre l'utilisateur et le serveur distant est éventuellement indirecte, notamment si plusieurs serveurs sont impliqués. Il est en effet judicieux de distinguer les serveurs dédiés à la gestion des véhicules, des serveurs dédiés à l'auto-partage qui authentifient les utilisateurs temporaires. Une interface de programmation entre ces deux types de serveurs 15 permet une implémentation de services d'autopartage par des acteurs distincts des constructeurs de véhicules, notamment par des particuliers. Avantageusement, ledit serveur distant est apte à intégrer audit jeton d'utilisation une clef de chiffrement publique associée audit terminal mobile avant sa signature avec la clef privée associée audit serveur distant. 20 Avantageusement encore, ledit véhicule comporte des moyens de génération d'un nombre aléatoire ou d'une clef publique de type courbe elliptique, et d'envoi audit terminal mobile, d'un message comportant ledit nombre aléatoire ou ladite clef publique de type courbe elliptique, ledit terminal mobile étant apte à mettre en place une liaison « Bluetooth® Low Energy » 25 sécurisée en utilisant ledit nombre aléatoire lu dans ledit message ou généré en utilisant ladite clef publique de type courbe elliptique, par la lecture d'une commande nécessitant une telle sécurisation. Avantageusement encore, lorsque ledit message comporte ledit nombre aléatoire, il comporte également une clef de chiffrement symétrique. 7 Avantageusement encore, ledit véhicule est apte à chiffrer ledit message préalablement à son envoi, avec la clef de chiffrement publique associée audit terminal mobile. Avantageusement encore, suite à la mise en place de ladite liaison 5 « Bluetooth® Low Energy » sécurisée, ledit terminal mobile est apte à envoyer un message de contrôle audit véhicule, à recevoir un accusé de réception dudit message de contrôle puis à envoyer une commande de déverrouillage audit véhicule, ledit véhicule étant apte à recevoir ledit message de contrôle, à envoyer ledit accusé de réception audit terminal mobile, à recevoir ladite 10 commande de déverrouillage et à vérifier que le temps écoulé entre la réception du message de contrôle et la réception de la commande de déverrouillage est inférieur à un seuil maximal de durée. Avantageusement encore, ledit terminal mobile et ledit véhicule sont chacun aptes à tenir à jour un compteur du nombre de messages qu'ils envoient 15 sur ladite liaison sécurisée, à intégrer la valeur dudit compteur dans lesdits messages envoyés sur ladite liaison sécurisée et à vérifier que ladite valeur du compteur contenue dans un message reçu sur ladite liaison sécurisée est strictement supérieure à celle contenue dans le précédent message valide reçu sur ladite liaison sécurisée. 20 Le système de déverrouillage selon l'invention présente des avantages analogues à ceux du procédé de déverrouillage selon l'invention. D'autres caractéristiques et avantages apparaîtront à la lecture d'un 25 mode de réalisation préféré décrit en référence aux figures dans lesquelles : - la figure 1 représente un mode de réalisation du système de déverrouillage selon l'invention, - la figure 2 représente des étapes préalables à l'utilisation du procédé de déverrouillage selon l'invention, dans ce mode de réalisation préféré, 30 - la figure 3 représente des étapes du procédé de déverrouillage selon l'invention, dans ce mode de réalisation préféré, 8 - et la figure 4 représente des étapes alternatives du procédé de déverrouillage selon l'invention, dans ce mode de réalisation préféré. 5 Selon un mode préféré de réalisation de l'invention représenté à la figure 1, le système de déverrouillage selon l'invention comporte au moins un véhicule V, un ou plusieurs serveurs distants SD généralement gérés par le constructeur du véhicule V, et au moins un terminal mobile TM d'un utilisateur. On considère pour simplifier, dans ce mode de réalisation, que le véhicule V et le terminal TM 10 ne communiquent qu'avec un seul serveur distant SD du réseau CLO du constructeur. Le véhicule V comporte un module matériel et logiciel de communication TCU qui lui permet d'envoyer et de recevoir des messages au/du serveur distant SD, de manière sécurisée. Cette communication utilise un réseau de téléphonie 15 mobile du type GSM (d'après l'anglais « Global System for Mobile communications ») ou UMTS (d'après l'anglais « Universal Mobile Telecommunication System ») ou de quatrième génération. Pour cela le module de communication TCU embarque une carte SIM (d'après l'anglais « Subscriber Identity Module ») ou USIM (d'après l'anglais « Universal Subscriber Identity 20 Module »). Le module de communication TCU permet aussi au véhicule V de communiquer avec le terminal mobile TM via une communication sans fil de type wi-fi, « Bluetooth® » ou NFC. On suppose, dans ce mode de réalisation de l'invention, que cette communication sans fil utilise une liaison « Bluetooth® Low Energy » (BLE). Le module de communication TCU implémente le protocole 25 correspondant avec les fonctionnalités sécuritaires additionnelles normalisées appelées « Authenticated pairing with encryption » et les méthodes d'appareillage « Out of Band » (0oB) » et « LE secure connections with Passkey ». Le véhicule V comporte en outre un organe de commande BCM matériel 30 et logiciel, communiquant avec le module de communication TCU et avec un système de sécurité SV du véhicule V. L'organe de commande BCM est apte à 9 écrire et effacer des données dans une mémoire MEM. La mémoire MEM stocke une paire de clefs cryptographiques asymétriques résistante à une attaque de type force brute : - une clef publique PUKV associée au véhicule V, 5 - et une clef privée PRKV associée au véhicule V. La mémoire MEM stocke également une clef publique PUKC associée au réseau CLO du constructeur. Ces clefs sont par exemple des clefs RSA de 2048 bits. En variante ces clefs sont stockées dans le module de communication TCU. Il est entendu que le procédé selon l'invention est implémentable de façon 10 distribuée sur plusieurs unités de contrôle du véhicule. Le serveur distant SD reçoit périodiquement du véhicule V des informations sur l'état du véhicule V, telles que sa localisation, l'état de ses pneus, etc. Il envoie au véhicule V des mises à jour à distance OTA (d'après l'anglais « Over The Air ») de certains modules logiciels. Il est également apte 15 à envoyer des commandes à distance au véhicule V, telles qu'un ordre de déverrouillage d'une ou plusieurs portières du véhicule, du coffre du véhicule, ou une autorisation de démarrage. Néanmoins dans ce mode de réalisation de l'invention, un tel ordre de déverrouillage est envoyé par le terminal mobile TM au véhicule V (plus précisément au module TCU), suite à l'envoi d'un jeton 20 d'utilisation. Ce jeton d'utilisation est décodé par l'organe de commande BCM qui stocke les informations relatives à l'utilisation du jeton dans la mémoire MEM et les efface après usage. Un jeton d'utilisation est associé notamment à une durée d'utilisation du véhicule. La durée d'utilisation est soit codée dans le jeton d'utilisation, soit convenue séparément entre le véhicule V et le serveur distant 25 SD notamment si cette durée est la même pour tous les jetons d'utilisation. Le serveur distant SD peut révoquer un jeton d'utilisation non encore reçu ou en cours d'utilisation par le véhicule V en lui envoyant un message approprié. Le jeton d'utilisation code si nécessaire également : un créneau horaire d'utilisation du véhicule V, en indiquant par exemple 30 une date de début ou de fin d'utilisation du véhicule V, 10 les autorisations associées au jeton, qui sont par exemple une autorisation d'ouverture/fermeture des portières et du coffre, ou du coffre seulement, ainsi qu'en général une autorisation de démarrage. Le serveur distant SD enregistre également ces données dans une base 5 de données BDD, qui concerne plusieurs véhicules, par exemple le véhicule V et le véhicule V2, et les utilisateurs associés. La base de données BDD stocke également une paire de clefs cryptographiques asymétriques résistante à une attaque de type force brute : - une clef publique PUKC associée au réseau CLO du constructeur, 10 - et une clef privée PRKC associée au réseau CLO du constructeur. La base de données BDD stocke également la clef publique PUKV associée au véhicule V et plus généralement les clefs publiques des véhicules gérés par le constructeur. Ces clefs sont par exemple des clefs RSA de 2048 bits. Le propriétaire du véhicule V a accès à un site web d'entrée du serveur 15 distant SD, grâce à des données d'identification et d'authentification auprès de ce serveur distant SD. Le serveur distant SD génère des jetons qu'il envoie au fur et à mesure à l'utilisateur. Lorsque le propriétaire est seul utilisateur de son véhicule V et veut pouvoir l'utiliser à tout moment en utilisant uniquement son terminal mobile TM, ces jetons d'utilisation indiquent par exemple uniquement 20 des durées d'utilisation. Cependant, si le propriétaire du véhicule V met en partage son véhicule, alors il a la possibilité d'enregistrer sur le site web du serveur distant SD, plusieurs autres utilisateurs avec les restrictions d'accès et horaires correspondants. Pour cela il indique leurs identifiants et leurs données d'authentification respectives, qui sont enregistrés par le serveur distant SD, qui 25 génère des jetons d'utilisation cohérents avec les contraintes d'utilisation inscrites pour les différents utilisateurs, et les transmet ensuite aux terminaux mobiles respectifs des utilisateurs du véhicule V. Ces jetons d'utilisation codent alors, aussi bien pour le propriétaire du véhicule V que pour les autres utilisateurs, non seulement des durées d'utilisation mais aussi des restrictions 30 horaires et des restrictions d'accès. La durée maximale d'utilisation associée à un jeton est par exemple de 24 heures, afin de renforcer la sécurité du système. 11 Sous une forme de codage simple, un jeton d'utilisation se compose par exemple de quatre parties concaténées : une première partie du jeton d'utilisation est un nombre aléatoire d'un nombre de chiffres prédéfini, la deuxième partie du jeton d'utilisation est une valeur qui code les informations 5 de validité dans le temps du jeton d'utilisation ainsi que les informations d'autorisation d'accès associées, la troisième partie contient la clef publique du terminal mobile destinataire du jeton et la quatrième partie est la signature du jeton avec la clef privée du serveur distant SD. Le serveur distant SD est également apte à envoyer un ou plusieurs 10 jetons associés aux utilisateurs du véhicule V, aux utilisateurs du véhicule V sur leurs terminaux mobiles correspondants, par exemple les terminaux mobiles TM et TM2. Cependant si l'un des terminaux mobiles n'est pas sous couverture réseau, le serveur distant SD réémet ces jetons à intervalles réguliers au destinataire défaillant jusqu'à ce que celui-ci soit en mesure de les recevoir. 15 Lorsqu'un jeton arrive proche de l'expiration le serveur distant SD alerte l'utilisateur correspondant, ou en régénère automatiquement si les droits d'accès de l'utilisateur ne sont pas limités dans le temps. Lorsqu'un jeton est envoyé à un terminal mobile, par exemple le terminal mobile TM, il est noté comme envoyé par le serveur distant SD dans la base de 20 données BDD. Le terminal mobile TM est apte à s'authentifier auprès du serveur distant SD grâce à un identifiant utilisateur et une donnée d'authentification correspondante, ici un code secret, auprès du serveur distant SD, pour recevoir 25 un jeton d'utilisation. Pour cela le terminal TM comporte une application préalablement téléchargée apte à communiquer avec le serveur distant SD en mode sécurisé (session https d'après l'anglais «HyperText Transfert Protocol Secure » ou plus généralement TLS d'après l'anglais «Transport Layer Security »), puis après authentification à recevoir le jeton d'utilisation envoyé par 30 le serveur distant SD. Lors de l'authentification, l'application fait afficher au terminal mobile TM, un clavier virtuel pour faire saisir à l'utilisateur son code 12 secret. En variante l'authentification de l'utilisateur et la communication entre le terminal mobile TM et le serveur distant SD se fait par navigation de l'utilisateur sur le site web du serveur distant SD. Le terminal mobile TM n'enregistre de préférence ni l'identifiant utilisateur ni le code secret correspondant, qui sont 5 envoyés au serveur distant SD lors de cette authentification, afin de se protéger d'un vol du terminal mobile TM. L'application est également apte à envoyer le jeton d'utilisation reçu au véhicule V après une procédure d'authentification auprès du véhicule V qui sera détaillée en relation avec la figure 3. A cette fin le terminal mobile TM implémente le protocole « Bluetooth® Low 10 Energy » (BLE) avec les fonctionnalités sécuritaires additionnelles normalisées appelées « Authenticated pairing with encryption », « Out of Band » (0oB) », et « LE secure connections with Passkey ». L'application dans le terminal mobile TM est apte à générer et mémoriser une paire de clefs cryptographiques asymétriques résistante à une attaque de 15 type force brute, qui permettent de sécuriser les échanges entre le terminal mobile TM et le véhicule V: - une clef publique PUKT associée au terminal mobile TM, - et une clef privée PRKT associée au terminal mobile TM. Ces clefs sont par exemple des clefs RSA de 2048 bits. 20 Une authentification réussie permet à l'utilisateur de déverrouiller ultérieurement le véhicule V et éventuellement de le faire démarrer. Lorsqu'un jeton d'utilisation a été envoyé par le terminal mobile TM au véhicule V, l'application dans le terminal mobile TM efface ce jeton de sa mémoire. Lorsqu'un jeton arrive proche de l'expiration ou vient d'être utilisé, cette 25 application alerte l'utilisateur pour qu'il recharge un jeton, aux moments où la couverture réseau est disponible pour le terminal mobile TM. L'organe de commande BCM du véhicule V est apte, lorsqu'il reçoit du terminal mobile TM un jeton d'utilisation associé à un utilisateur, à vérifier sa validité, à mémoriser certaines informations telles que la durée de validité ou la 30 date de début ou de fin d'utilisation dans la mémoire MEM, et en fonction des droits codés dans ce jeton, à permettre: 13 - l'ouverture ultérieure de la partie de véhicule dont l'accès est autorisé par ce jeton à l'horaire specifié dans le contenu du jeton, - le démarrage ultérieur du véhicule si celui-ci est autorisé par ce jeton d'utilisation à l'horaire specifié dans le contenu du jeton. 5 Une fois le jeton d'utilisation « consommé », c'est-à-dire à la fin de la durée d'utilisation du jeton d'utilisation ou à l'arrêt/re-verrouillage du véhicule, l'organe de commande BCM efface les informations associées au jeton de la mémoire MEM. Il est à noter que le véhicule n'enregistre pas de données utilisateur liées au jeton d'utilisation. En effet il n'authentifie pas l'utilisateur d'un jeton, mais le 10 jeton lui-même ainsi que le terminal utilisateur TM grâce au procédé décrit dans la suite. En référence à la figure 2, des premières étapes du procédé de déverrouillage selon l'invention, utilisé par l'utilisateur du terminal mobile TM sur 15 son véhicule V, sont représentées sous la forme d'un diagramme de flux. Lors d'une étape ESC1, le serveur distant SD, après avoir généré un jeton d'utilisation pour l'utilisateur du terminal mobile TM, établit une session de communication sécurisée https avec le terminal mobile TM. En variante la génération du jeton a lieu après l'étape d'authentification AUTH1. 20 Lors d'une étape suivante AUTH1, le serveur distant SD demande à l'utilisateur de saisir son identifiant et son code secret sur un clavier virtuel, via l'application téléchargée dans le terminal mobile TM. Ces données d'authentification sont envoyées au serveur distant SD qui authentifie ainsi l'utilisateur du terminal mobile TM. 25 Lors d'une étape suivante ENVI, le terminal mobile TM envoie sa clef publique PUKT au serveur distant SD, afin de permettre ultérieurement au véhicule V d'authentifier le terminal mobile TM. Lors d'une étape suivante ENV2, le serveur distant SD envoie un jeton d'utilisation associé à l'utilisateur au terminal mobile TM, en le signant avec la 30 clef privée PRKC du réseau CLO du constructeur, puis marque ce jeton comme 14 envoyé dans sa base de données BDD. Ce jeton d'utilisation comporte de préférence : - un identifiant de jeton et/ou une date de génération du jeton, permettant la révocation ou la substitution de celui-ci via une communication entre 5 le serveur distant SD et le véhicule V, et/ou une communication entre le serveur distant SD et le terminal mobile TM puis une communication entre le terminal mobile TM et le véhicule V, - des informations de validité dans le temps du jeton d'utilisation ainsi que les informations d'autorisation d'accès associées, 10 - l'identifiant du véhicule V, ce qui permet de ne pas pouvoir utiliser ce jeton pour un autre véhicule, - la clef publique PUKT du terminal mobile TM, afin que le véhicule puisse authentifier le terminal mobile TM. Lors de cette étape ENV2, le serveur distant SD envoie aussi au terminal mobile 15 TM la clef publique PUKV du véhicule, afin que le terminal mobile TM puisse authentifier le véhicule V. Lors d'une étape ultérieure ESC2, l'utilisateur s'approche de son véhicule V et connecte son terminal mobile avec le module de communication TCU du véhicule V via une liaison BLE classique utilisant la méthode appelée « Just 20 Work pairing ». Cette liaison ne requière que peu de ressources mais ne protège pas contre les attaques du type « Homme du milieu ». Lors d'une étape suivante ENV3 le terminal mobile TM envoie le jeton au véhicule V via la liaison BLE précédemment établie. A la réception de ce jeton, l'organe de commande BCM du véhicule vérifie que le jeton émane bien du 25 serveur distant SD en l'authentifiant grâce à la clef publique PUKC associée au serveur distant SD. Puis l'organe de commande BCM contrôle que le jeton est valide en vérifiant son identifiant et la durée/le créneau de validité associé, ainsi que les autorisations associées au jeton, et stocke ces informations, ainsi que la clef publique PUKT du terminal mobile TM dans la mémoire MEM. 30 Si les vérifications de l'organe de commande BCM sont concluantes, c'est-à-dire que le jeton est valide et authentifié, alors le module de 15 communication TCU met en place, dans les étapes suivantes, une connexion sécurisée avec le terminal mobile TM, afin de sécuriser l'ordre de déverrouillage envoyé ultérieurement par le terminal mobile TM au véhicule, notamment pour s'assurer que le message contenant la commande de déverrouillage a bien été 5 envoyé par le terminal mobile TM autorisé par le serveur SD. L'étape suivante GENK est la génération, par l'organe de commande BCM: - d'une clef de chiffrement symétrique DK permettant d'authentifier les futurs échanges entre le terminal mobile TM et l'organe de commande 10 BCM, au niveau applicatif ; l'utilisation d'une clef de chiffrement symétrique permet de diminuer la taille des messages échangés par rapport à l'utilisation d'une clef de chiffrement asymétrique ; - d'un nombre aléatoire OK de 128 bits permettant, ultérieurement, au terminal mobile TM et au module de communication TCU de mettre en 15 place une connexion « Bluetooth® Low Energy » sécurisée contre les attaques du type « Homme du milieu » en utilisant la méthode d'appairage normalisée dite « Out-Of-Band pairing », - et d'un nombre aléatoire PK de six chiffres permettant, ultérieurement, au terminal mobile TM et au module de communication TCU de mettre 20 en place une connexion « Bluetooth® Low Energy » sécurisée contre les attaques du type « Homme du milieu » en utilisant la méthode d'appairage normalisée dite « Passkey » dans le cas où la méthode d'appairage normalisée dite « Out-Of-Band pairing » n'est pas implémentée par le terminal mobile TM. 25 Dans l'étape suivante ENV4, l'organe de commande BCM: - chiffre la clef de chiffrement DK et les nombres aléatoires OK et PK, avec la clef publique PUKT du terminal, et signe l'ensemble avec la clef privée PRKV du véhicule, 30 - puis envoie la clef de chiffrement DK et les nombres aléatoires OK et PK ainsi chiffrés et signés au terminal mobile TM. Cela permet de se protéger 16 d'une attaque de type « Homme du milieu » sur la connexion BLE non encore sécurisée puisque seul le terminal mobile TM peut déchiffrer les données du message envoyé lors de cette étape ENV4. L'étape suivante STOK est l'authentification du message reçu lors de 5 l'étape ENV4 et le déchiffrage, par le terminal mobile TM, des données du message qu'il a reçu lors de l'étape ENV4, respectivement grâce à la clef publique PUKV du véhicule V et à sa clef privée PRKT. Puis il stocke, dans cette étape, la clef de chiffrement DK et les nombres aléatoires OK et PK dans sa mémoire. 10 A l'étape suivante ESC3, le terminal mobile TM lance une procédure normalisée pour passer en mode « Low Energy » sécurisé. Pour cela l'application spécifique dans le terminal mobile TM lit une commande nécessitant la sécurisation de la liaison BLE. Par défaut lors de cette étape, le terminal mobile TM utilise la méthode d'appairage normalisée dite « Out-Of- 15 Band pairing » mais en utilisant le nombre aléatoire OK déchiffré à l'étape précédente plutôt qu'un nombre reçu par un module NFC (« Near Field Communication »). S'il n'implémente pas cette méthode d'appairage, alors il utilise le nombre aléatoire PK à six chiffres comme « passkey » pour s'appairer avec le véhicule V comme il l'aurait fait s'il avait reçu ce nombre aléatoire après 20 affichage de cette « passkey » sur un périphérique distant, selon la méthode normalisée « passkey entry ». Lors de cette étape ESC3, un appairage est établi entre le terminal mobile TM et le module de communication TCU du véhicule V, de manière théoriquement sécurisée contre les attaques de type « Homme du milieu ». 25 Alternativement, la clef de chiffrement symétrique DK est générée en utilisant un algorithme d'échange de clefs Diffie Hellman basé sur des courbes elliptiques, connu sous l'abréviation ECDH (d'après l'anglais « Elliptic Curve Diffie Hellman»). Dans ce cas, les étapes GENK, ENV4, et STOK sont par 30 exemple modifiées et deviennent respectivement les étapes GENK1, ENV41, et STOK1 représentées à la figure 4: 17 A l'étape GENK1, l'organe de commande BCM génère une clef publique PUKV1 et une clef privée associée PRKV1 de type courbe elliptique. A partir de la clef privée PRKV1 ainsi générée, et de la clef publique PUKT du terminal mobile TM, l'organe de commande BCM génère ensuite la clef de chiffrement 5 symétrique DK en utilisant l'algorithme ECDH. A partir de cette clef de chiffrement symétrique DK, l'organe de commande BCM génère en outre un nombre aléatoire de six chiffres servant de « passkey », et/ou un nombre aléatoire de 128 bits pour utiliser ultérieurement la méthode d'appairage dite « Out of Band », en utilisant un algorithme contenu dans la mémoire MEM. 10 A l'étape suivante ENV41, l'organe de commande BCM signe la clef publique PUKV1 avec la clef privée PRKV du véhicule et envoie la clef publique PUKV1 ainsi signée au terminal mobile TM, sur la liaison BLE établie précédemment. L'étape suivante STOK1 est, après authentification du message reçu à 15 l'étape ENV41 grâce à la clef publique PUKV du véhicule, la génération par le terminal mobile TM de la clef de chiffrement symétrique DK en utilisant la clef publique PUKV1 reçue à l'étape précédente ENV41, ainsi que la clef privée PRKT du terminal mobile, selon l'algorithme ECDH. Puis le terminal mobile TM génère un nombre aléatoire de six chiffres servant de « passkey », ou bien un 20 nombre aléatoire de 128 bits pour utiliser ultérieurement la méthode d'appairage dite « Out of Band », en utilisant la clef de chiffrement DK précédemment générée. La génération d'un nombre aléatoire dans cette étape STOK1 utilise un algorithme contenu dans l'application téléchargée par le terminal mobile TM, identique à celui utilisé par l'organe de commande BCM à l'étape GENK1 pour 25 générer ce nombre aléatoire. La clef de chiffrement symétrique DK et le ou les nombres aléatoires ainsi générés dans cette alternative permettent ensuite de mettre en place une connexion BLE sécurisée selon une étape similaire à l'étape ESC3 de la variante principale de réalisation de l'invention. 30 Afin de sécuriser encore la connexion entre le terminal mobile TM et le véhicule V, notamment pour empêcher un re-jeu de message d'être efficace, au 18 niveau applicatif entre l'organe de commande BCM et le terminal mobile TM, ou même encore se prémunir contre d'éventuelles vulnérabilités futures du protocole BLE, le protocole applicatif suivant est mis en place : - Le terminal mobile TM et l'organe de commande BCM tiennent chacun un 5 compteur des messages qu'ils envoient. La valeur du compteur est envoyée avec chaque message. Ainsi le message ENV5 contiendra une valeur de compteur égale à un. - Le terminal mobile TM et l'organe de commande BCM utilisent un algorithme de chiffrement symétrique de type « block-cipher-based MAC » ou CMAC 10 utilisant la clef de chiffrement symétrique DK. Ainsi chaque message à envoyer, contenant une commande et le compteur de l'émetteur, sera chiffré avec la clef de chiffrement DK, et complété par le champ MAC (« Message Authentication Code ») associé avant d'être envoyé sur le lien sécurisé BLE. - Lorsqu'ils reçoivent un message sur ce lien sécurisé, le terminal mobile TM 15 ou le véhicule V vérifient l'authenticité et l'intégrité du message reçu grâce à la clef de chiffrement DK, puis vérifient que la valeur du compteur contenue dans le message reçu est strictement supérieure à celle du dernier message valide reçu, et met à jour la valeur du compteur de l'émetteur dans sa mémoire. 20 De plus, afin d'empêcher les attaques par retardement, chaque message critique envoyé par le terminal mobile TM sera précédé d'un message de contrôle ou message « factice » comme expliqué ci-après. Lors d'une étape suivante ENV5, le terminal mobile TM envoie un tel message de contrôle à l'organe de commande BCM du véhicule V, qui le reçoit. 25 Ce message ne comporte par exemple comme données applicatives que la valeur du compteur tenue par le terminal mobile TM, et est envoyé en suivant le protocole défini plus haut, destiné à empêcher un re-jeu malintentionné de ce message. Lors d'une étape suivante ENV6, l'organe de commande BCM ayant reçu 30 le message, stocke une estampille temporelle de réception de ce message, ou lance un compteur de temps. L'organe de commande BCM envoie également, 19 lors de cette étape ENV6, un accusé de réception comportant par exemple comme données applicatives uniquement la valeur du compteur tenue par l'organe de commande BCM, au terminal mobile TM, qui le reçoit. Lors d'une étape suivante ENV7, le terminal mobile TM ayant reçu 5 l'accusé de réception, valide celui-ci en vérifiant notamment la valeur du compteur que ce message contient, et envoie un message de déverrouillage du véhicule V, à l'organe de commande BCM, qui le reçoit. A la réception de ce message de déverrouillage, l'organe de commande BCM vérifie que le temps écoulé At entre la réception du premier message factice de contrôle à l'étape 10 ENV5 et la réception de ce message de déverrouillage est inférieur à un seuil maximal de durée. Si ce seuil est dépassé, alors l'organe de commande BCM ne tient pas compte du message de déverrouillage reçu, qui peut être un message retardé par un pirate. Ce seuil de durée maximal est dimensionné en fonction des cas d'usage du procédé selon l'invention, il peut notamment varier 15 en fonction des systèmes d'exploitation des terminaux mobiles des utilisateurs. Son ordre de grandeur est de la seconde. L'étape suivante REQS est l'envoi, lorsque le seuil de durée maximal n'est pas dépassé, par l'organe de commande BCM à un module de sécurité SV du véhicule, d'un ordre de déverrouillage de la partie du véhicule autorisée 20 à la dé-condamnation par le jeton d'utilisation, et éventuellement d'un ordre d'autorisation de démarrage du véhicule. Cet ordre de démarrage est en variante envoyé séparément par le terminal mobile TM à l'organe de commande BCM de façon similaire à l'envoi du message de déverrouillage. Ces ordres sont exécutés par le module de sécurité SV du véhicule, qui 25 permet à l'utilisateur d'utiliser en tout ou partie son véhicule. La fermeture des ouvrants du véhicule et la re-protection du démarrage du véhicule V est autorisée par le véhicule V depuis le terminal mobile TM tant que la durée d'utilisation du jeton d'utilisation n'est pas expirée. Puis l'organe de commande BCM avertit le serveur distant SD, toujours via le module TCU, dès que celui-ci 30 est sous couverture réseau, de cette consommation du jeton d'utilisation afin 20 que le serveur distant SD l'efface de sa base de données BDD, et efface le jeton consommé dans la mémoire MEM. Il est à noter qu'il est possible de réaliser l'invention de manières 5 légèrement différentes de ce mode de réalisation préféré de l'invention. Notamment le codage des données est faisable de différentes manières. L'envoi de la clef symétrique par le véhicule se fait par exemple dans un message séparé du message comportant les nombres aléatoires. Plus de messages sont donc en variante échangés entre le véhicule et le terminal mobile. De plus le 10 véhicule n'envoie par exemple qu'un nombre aléatoire au terminal mobile si celui-ci déclare auparavant au véhicule quelle(s) méthode(s) d'appairage il implémente, ou si le véhicule n'en implémente qu'une seule. Certaines données sont de plus codables dans ou en dehors du jeton d'utilisation lui-même, comme par exemple la clef publique du terminal mobile. Des étapes de chiffrement 15 supplémentaires sont en outre envisageables, par exemple le jeton envoyé au véhicule est en variante chiffré en utilisant la clef privée du terminal mobile, et/ou REVENDICATIONS1. Procédé de déverrouillage d'au moins une partie d'un véhicule automobile (V) par un utilisateur équipé d'un terminal mobile (TM), ledit procédé étant mis en oeuvre par un organe de commande (BCM) dudit véhicule automobile (V), ledit procédé étant caractérisé en ce qu'il comporte les étapes de : - réception (ENV3) d'au moins un jeton d'utilisation signé, envoyé audit véhicule (V) par ledit terminal mobile (TM), ledit jeton d'utilisation ne servant que pour une durée d'utilisation limitée dudit véhicule (V), - authentification dudit jeton d'utilisation en utilisant une clef de chiffrement publique (PUKC) associée à un tiers habilité à déverrouiller ledit véhicule (V), - déverrouillage (REQS) de ladite au moins une partie dudit véhicule (V) lorsque ladite authentification résulte en un jeton d'utilisation valide. 2. Procédé de déverrouillage selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape de lecture ou de déchiffrement, d'une clef de chiffrement publique (PUKT) associée audit terminal mobile (TM). 3. Procédé de déverrouillage selon la revendication 1 ou 2 caractérisé en ce que l'étape d'authentification dudit jeton d'utilisation est suivie d'une étape de sécurisation d'une liaison « Bluetooth® Low Energy » non sécurisée entre ledit terminal mobile (TM) et ledit véhicule (V), par envoi (ENV4, ENV41) par ledit véhicule (V) audit terminal mobile (TM) d'un message comportant une valeur numérique apte à permettre la génération ou la lecture par ledit terminal mobile (TM) d'un nombre aléatoire servant à la mise en place par ledit terminal mobile d'une liaison « Bluetooth® Low Energy » sécurisée par la lecture d'une commande nécessitant une telle sécurisation. 22 4. Procédé de déverrouillage selon la revendication 3, caractérisé en ce que ledit message comporte une clef de chiffrement symétrique (DK) ou des moyens de génération d'une clef de chiffrement symétrique (DK). 5 5. Procédé de déverrouillage selon la revendication 4, caractérisé en ce que ladite valeur numérique et lesdits moyens de génération correspondent à une clef publique de type courbe elliptique générée par ledit véhicule (V). 6. Procédé de déverrouillage selon l'une quelconque des revendications 3 à 5, 10 caractérisé en ce que, préalablement à son envoi (ENV4, ENV41), ledit message est chiffré par ledit véhicule (V) en utilisant la clef de chiffrement publique (PUKT) associée audit terminal mobile (TM). 7. Procédé de déverrouillage selon l'une quelconque des revendications 3 à 6, 15 caractérisé en ce que l'envoi (ENV4, ENV41) dudit message est suivi d'une étape de réception (ENV5) par ledit véhicule (V), d'un message de contrôle envoyé par ledit terminal mobile (TM), d'une étape de réception (ENV7) d'une commande de déverrouillage envoyée par ledit terminal mobile (TM) et d'une étape de vérification que le temps écoulé (At) entre la réception (ENV5) du 20 message de contrôle et la réception (ENV7) de ladite commande de déverrouillage est inférieur à un seuil maximal de durée. 8. Procédé de déverrouillage selon la revendication 7, caractérisé en ce qu'il comporte une étape de vérification d'une valeur d'un compteur contenue dans 25 ledit message de contrôle, représentative d'un nombre de messages émis par ledit terminal mobile (TM) à destination dudit véhicule (V). 9. Système de déverrouillage d'au moins une partie d'un véhicule automobile (V) par un utilisateur équipé d'un terminal mobile (TM), ledit système étant caractérisé en ce qu'il comporte: 23 - un serveur distant (SD) apte à authentifier ledit utilisateur et à générer au moins un jeton d'utilisation associé audit utilisateur et ne servant qu'à une durée d'utilisation limitée dudit véhicule (V), à signer ledit jeton d'utilisation avec une clef de chiffrement privée (PRKC) associée audit serveur distant (SD), et à 5 envoyer audit terminal mobile (TM) ledit jeton d'utilisation signé, - ledit terminal mobile (TM), étant apte à communiquer avec ledit serveur distant (SD) pour authentifier ledit utilisateur et recevoir ledit jeton d'utilisation signé, et apte à communiquer avec ledit véhicule (V) pour envoyer ledit jeton d'utilisation signé audit véhicule (V), 10 - ledit véhicule automobile (V), étant apte à recevoir ledit jeton d'utilisation signé envoyé par ledit terminal mobile (TM), à authentifier ledit jeton d'utilisation en utilisant une clef publique (PUKC) associée audit serveur distant (SD), et à déverrouiller ladite au moins une partie dudit véhicule (V) lorsque ledit jeton d'utilisation valide ce déverrouillage. 15 10. Système de déverrouillage selon la revendication 9, dans lequel ledit serveur distant (SD) est apte à intégrer audit jeton d'utilisation une clef de chiffrement publique (PUKC) associée audit terminal mobile (TM) avant sa signature avec la clef privée (PRKC) associée audit serveur distant (SD). 20 11. Système de déverrouillage selon l'une quelconque des revendication 9 à 10, caractérisé en ce que ledit véhicule (V) comporte des moyens de génération d'un nombre aléatoire (OK, PK) ou d'une clef publique de type courbe elliptique, et d'envoi audit terminal mobile (TM), d'un message comportant ledit nombre 25 aléatoire (OK, PK) ou ladite clef publique de type courbe elliptique, ledit terminal mobile (TM) étant apte à mettre en place une liaison « Bluetooth® Low Energy » sécurisée en utilisant ledit nombre aléatoire (OK, PK) lu dans ledit message ou généré en utilisant ladite clef publique de type courbe elliptique, par la lecture d'une commande nécessitant une telle sécurisation. 30 24 12. Système de déverrouillage selon la revendication 11, caractérisé en ce que lorsque ledit message comporte ledit nombre aléatoire (OK, PK), il comporte également une clef de chiffrement symétrique (D K). 5 13. Système de déverrouillage selon la revendication 11 ou 12, caractérisé en ce que ledit véhicule (V) est apte à chiffrer ledit message préalablement à son envoi, avec la clef de chiffrement publique (PUKT) associée audit terminal mobile (TM). 10 14. Système de déverrouillage selon l'une quelconque des revendications 11 à 13, caractérisé en ce que suite à la mise en place de ladite liaison « Bluetooth® Low Energy » sécurisée, ledit terminal mobile (TM) est apte à envoyer un message de contrôle audit véhicule (V), à recevoir un accusé de réception dudit message de contrôle puis à envoyer une commande de déverrouillage audit 15 véhicule (V), ledit véhicule (V) étant apte à recevoir ledit message de contrôle, à envoyer ledit accusé de réception audit terminal mobile (TM), à recevoir ladite commande de déverrouillage et à vérifier que le temps écoulé entre la réception du message de contrôle et la réception de la commande de déverrouillage est inférieur à un seuil maximal de durée. 20 15. Système de déverrouillage selon la revendication 14, caractérisé en ce que ledit terminal mobile (TM) et ledit véhicule (V) sont chacun aptes à tenir à jour un compteur du nombre de messages qu'ils envoient sur ladite liaison sécurisée, à intégrer la valeur dudit compteur dans lesdits messages envoyés 25 sur ladite liaison sécurisée et à vérifier que ladite valeur du compteur contenue dans un message reçu sur ladite liaison sécurisée est strictement supérieure à celle contenue dans le précédent message valide reçu sur ladite liaison sécurisée.