FR 3030830 A1 20160624 FR 1500314 A 20150218 DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne de manière générale la commande de fonctionnalités d'un véhicule automobile au moyen d'un terminal mobile. Elle concerne plus particulièrement un procédé de sécurisation de l'accès à au moins une fonctionnalité d'un véhicule automobile par un utilisateur, ledit utilisateur étant équipé d'un terminal mobile dans lequel est stockée une clé virtuelle d'accès à ladite fonctionnalité, ledit terminal mobile étant adapté, lorsqu'il est accessible, à communiquer avec un serveur central. L'invention s'applique particulièrement avantageusement dans le cas où la fonctionnalité commandée est le déverrouillage des portières du véhicule ou le démarrage du véhicule. ARRIERE-PLAN TECHNOLOGIQUE On a proposé de commander certaines fonctionnalités d'un véhicule automobile, telles que le déverrouillage des portières du véhicule, au moyen d'un 15 terminal mobile, par exemple un téléphone portable couramment utilisé par le propriétaire du véhicule. Afin de ne permettre cette commande qu'aux personnes effectivement autorisées, on utilise des clés virtuelles qui sont mémorisées dans les téléphones portables des personnes autorisées et dont une unité électronique de commande 20 du véhicule vérifie la présence avant de commander le déverrouillage des portières. Chaque clé virtuelle est généralement transmise de manière sécurisée au téléphone mobile, via le réseau de téléphonie mobile, par un serveur central appartenant au constructeur du véhicule automobile. 25 Un risque est que le propriétaire du véhicule automobile se fasse dérober son téléphone portable, et que le voleur ait alors accès au véhicule automobile. Dans cette situation, la solution actuellement proposée consiste, pour le serveur, à envoyer au terminal mobile un signal de commande de l'effacement de la clé virtuelle qu'il stocke. 30 Cette solution ne fonctionne malheureusement que si le téléphone mobile est connecté au réseau de téléphonie mobile. Dans le cas contraire, le voleur peut conserver un accès au véhicule automobile. L'inconvénient est alors qu'en maintenant le terminal mobile déconnecté du réseau de téléphonie mobile (par exemple « en mode avion »), le voleur garde un accès au véhicule automobile. OBJET DE L'INVENTION Afin de remédier à l'inconvénient précité de l'état de la technique, la présente invention propose de désactiver automatiquement la clé virtuelle au-delà 5 d'une durée de validité déterminée qui est affectée à cette clé. Plus particulièrement, on propose selon l'invention un procédé tel que défini dans l'introduction, dans lequel, la clé virtuelle ayant une durée de validité déterminée, il est prévu : - avant la fin de validité de la clé virtuelle, une première étape au cours 10 de laquelle le serveur central met automatiquement à jour la clé virtuelle, puis - lorsque le terminal mobile est accessible, une seconde étape au cours de laquelle le serveur communique automatiquement au terminal mobile cette clé virtuelle mise à jour. Ainsi, grâce à l'invention, si le voleur maintient le terminal mobile « en 15 mode avion », il ne conserve un accès au véhicule automobile qu'uniquement pendant la durée de validité de la clé virtuelle. Ensuite, cet accès lui est refusé. On notera ici que la durée de validité de la clé virtuelle s'exprimera préférentiellement sous la forme d'une date d'expiration. En variante, elle pourrait s'exprimer sous la forme d'un nombre d'accès limité à ladite fonctionnalité 20 (typiquement, on pourrait prévoir que la clé virtuelle soit mise à jour toutes les cent utilisations). Avantageusement, le véhicule automobile étant équipé d'une unité électronique adaptée à contrôler la validité de la clé virtuelle stockée dans le terminal mobile, l'unité électronique est adaptée à autoriser l'accès à ladite 25 fonctionnalité lorsque la clé virtuelle est invalide mais que au moins deux conditions sont remplies, à savoir que la clé virtuelle stockée dans le terminal mobile fut valide, et que l'utilisateur a valablement renseigné une information personnelle demandée par le terminal mobile. On comprend en effet que si l'usager est dans un endroit ou dans une 30 région du globe dans laquelle son terminal mobile ne peut pas communiquer avec le serveur, sa clé virtuelle ne peut pas être mise à jour. Dans cette situation, il est prévu que l'usager puisse conserver la possibilité d'accéder au véhicule en renseignant sur son terminal mobile une information personnelle. Préférentiellement, il est prévu une autre condition pour que l'unité électronique autorise l'accès à ladite fonctionnalité, à savoir que le temps passé depuis la fin de validité de la clé virtuelle n'a pas dépassé un seuil prédéterminé. Ainsi, si le voleur a non seulement dérobé le terminal mobile, mais aussi l'information personnelle permettant d'accéder au véhicule, cet accès lui sera 5 automatiquement refusé après une durée déterminée ou au-delà d'un nombre d'utilisations donné. D'autres caractéristiques avantageuses et non limitatives du procédé conforme à l'invention sont les suivantes : - la clé virtuelle étant élaborée à partir d'une clé mère à laquelle est 10 appliqué au moins un paramètre de dérivation, lors de la première étape, la clé virtuelle est mise à jour en modifiant la valeur dudit paramètre de dérivation, et lors de la seconde étape, ledit paramètre de dérivation est communiqué au terminal mobile ; - le véhicule automobile étant équipé d'une unité électronique adaptée à 15 contrôler la validité de la clé virtuelle stockée dans le terminal mobile, l'unité électronique est adaptée à refuser l'accès à ladite fonctionnalité lorsque la clé virtuelle est invalide ; - pour vérifier que l'utilisateur a valablement renseigné ladite information personnelle, le terminal mobile, ou respectivement l'unité électronique du véhicule 20 automobile, compare l'information personnelle renseignée (ou une valeur dérivée de cette information personnelle) avec une valeur préalablement mémorisée dans la mémoire du terminal mobile, ou respectivement de l'unité électronique ; - ladite information personnelle comporte un code secret ; - ladite information personnelle comporte une donnée biométrique ; 25 - il est prévu une autre condition pour que l'unité électronique autorise l'accès à ladite fonctionnalité, à savoir que le nombre d'accès à ladite fonctionnalité depuis la fin de validité de la clé virtuelle n'a pas dépassé un seuil prédéterminé ; - il est prévu une autre condition pour que l'unité électronique autorise 30 l'accès à ladite fonctionnalité, à savoir qu'un droit de dépassement temporaire de la durée de validité est affecté à la clé virtuelle. 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 représente un exemple de contexte dans lequel peut-être mise en oeuvre l'invention, comprenant notamment un serveur, un véhicule automobile et un terminal mobile ; - la figure 2 représente schématiquement des composants, utiles à la compréhension de l'invention, du véhicule automobile et du terminal mobile de la figure 1 ; - la figure 3 présente les étapes principales d'un procédé de transmission sécurisée d'une clé virtuelle mise à jour depuis le serveur jusqu'au terminal mobile de la figure 1 ; et - la figure 4 présente les étapes principales d'une méthode d'authentification du terminal mobile par le véhicule automobile de la figure 1. La figure 1 représente un exemple de contexte dans lequel peut être mise en oeuvre l'invention. Dans ce contexte, un véhicule automobile 10 comprend une unité électronique de commande 11 (ou ECU pour "Electronic Control Unit') qui est adaptée à commander des fonctionnalités du véhicule automobile 10 et qui peut entrer en communication, via une liaison sans fil, avec un terminal mobile 20. Ce terminal mobile 20 pourra être formé par un téléphone portable (ou téléphone cellulaire), préférentiellement de type "téléphone intelligent' ou "smartphone" selon la dénomination anglo-saxonne couramment utilisée. Il pourrait également s'agir d'une montre connectée, d'une paire de lunettes connectée... L'unité électronique de commande 11 est adapté à communiquer avec ce terminal mobile 20 afin d'échanger des données, par exemple en vue de la commande des fonctionnalités du véhicule automobile 10 au moyen du terminal mobile 20 (une telle fonctionnalité pouvant être par exemple le déverrouillage des portes du véhicule automobile 10 ou le démarrage du moteur du véhicule automobile 10), comme expliqué plus bas. La liaison sans fil utilisée pour communiquer entre l'unité électronique de commande 11 et le terminal mobile 20 est par exemple de type Bluetooth. Le terminal mobile 20 est par ailleurs conçu pour se connecter à un réseau de téléphonie mobile 30 qui comprend notamment une station de base 32 (ou antenne relais) en communication via une liaison radio avec le terminal mobile 20, et une passerelle 34 de connexion à un réseau public 40, par exemple le réseau Internet. Il comporte pour cela des moyens de connexion à la station de base 32, 5 par un protocole de téléphonie mobile de type 2G, 3G, 4G ou autre. Un serveur 50 (appelé serveur central ou serveur web) est également connecté au réseau public 40 de sorte que le terminal mobile 20 et le serveur 50 peuvent entrer en communication et échanger des données via le réseau de téléphonie mobile 30 et le réseau public 40. Le serveur 50 est ici géré par le 10 fabricant du véhicule automobile 10 ou par le fabricant de l'unité électronique de commande 11. La figure 2 représente schématiquement des composants, utiles à la compréhension de l'invention, du véhicule automobile 10 et du terminal mobile 20. Le véhicule automobile 10 comprend notamment l'unité électronique de 15 commande 11 déjà mentionnée, un actionneur 15 (conçu ici pour permettre le déverrouillage des portes du véhicule automobile 10), un module de communication sans fil 16 et une interface utilisateur 18. Un identifiant est attribué au véhicule automobile 10 et est conservé dans une base de données du serveur 50. Il s'agit ici d'un numéro d'identification VIN 20 (pour "Vehicle Identification Number"). Il pourrait en variante s'agir par exemple d'un numéro de série. L'unité électronique de commande 11 comprend un processeur 12 et une unité de mémorisation 14, par exemple une mémoire non-volatile réinscriptible ou un disque dur. 25 L'unité de mémorisation 14 mémorise notamment des programmes d'ordinateur comprenant des instructions dont l'exécution par le processeur 12 permet la mise en oeuvre par l'unité électronique de commande 11 des procédés décrits ci-dessous. L'unité de mémorisation 14 mémorise également des données utilisées 30 dans le cadre des procédés décrits ci-dessous, notamment une clé racine (ou clé maître) VK0 et une fonction cryptographique f, utilisées comme expliqué dans la suite. La clé racine VK0 et la fonction cryptographique f sont par exemple écrites dans l'unité de mémorisation 14 lors de la fabrication de l'unité électronique de commande 11, avant montage de cette unité électronique de commande 11 dans le véhicule automobile 10. La clé racine VK0 est également mémorisée au niveau du serveur 50 (dont on rappelle qu'il est géré par le fabricant du véhicule automobile 10), en association avec le numéro d'identification VIN attribué au véhicule automobile 10. Le terminal mobile 20 comprend quant à lui un processeur 22, une mémoire 24 (par exemple une mémoire non-volatile réinscriptible), un module de communication sans fil 26 un module 28 de communication sur le réseau de téléphonie mobile 30, et une interface utilisateur 27 (par exemple un écran tactile). Le module de communication sans fil 26 du terminal mobile 20 permet d'établir une liaison sans fil (ici de type Bluetooth comme déjà indiqué) avec le module de communication sans fil 16 du véhicule automobile 10 à travers laquelle le processeur 12 de l'unité électronique de commande 11 et le processeur 22 du terminal mobile 20 peuvent échanger des données, notamment comme exposé plus loin. Le module de communication 28 permet au terminal mobile 20 (et précisément au processeur 22 équipant ce terminal mobile 20) d'échanger comme déjà indiqué des données avec d'autres dispositifs connectés au réseau de téléphonie mobile 30 ou au réseau public 40, notamment avec le serveur 50. La mémoire 24 mémorise notamment des applications comprenant des instructions dont l'exécution par le processeur 22 permet la mise en oeuvre par le terminal mobile 20 des procédés décrits ci-dessous. La mémoire 24 mémorise également des données utilisées dans le cadre des procédés décrits ci-dessous. En référence aux figures 3 et 4, on décrira maintenant un procédé permettant de sécuriser l'accès au véhicule automobile 10. On considérera qu'avant la mise en oeuvre de ce procédé, le terminal mobile 20 est préparé pour la commande des fonctionnalités du véhicule automobile 10 et pour la communication avec le serveur 50. On considérera ainsi qu'il embarque une application utilisateur adaptée à communiquer avec l'unité électronique de commande 11 du véhicule automobile et dont l'intérêt sera bien décrit dans la suite de cet exposé. On considérera également qu'il stocke dans sa mémoire une clé virtuelle VK et la fonction cryptographique f. De même, avant la mise en oeuvre du procédé, le terminal mobile 20 est bien connu du serveur 50, qui a donc connaissance de données associées à ce terminal mobile 20. C'est en effet le serveur 50 qui aura préalablement élaborée la clé virtuelle VK et qui l'aura transmis au terminal mobile 20. Cette clé virtuelle VK aura été calculée de la manière suivante par le serveur 50. Une clé mère VKi est tout d'abord calculée en fonction de la clé racine VK0 et d'au moins un paramètre de dérivation DP. Ici, cette clé mère VK, est calculée en fonction de la clé racine VK0 et des dates de début et de fin de partage du véhicule automobile 10 (on se place ici dans le cas d'un prêt ou d'une location du véhicule). En variante, les paramètres de dérivation utilisés pourraient être différents. La clé virtuelle VK est ensuite calculée en fonction de la clé mère VKi et d'au moins un autre paramètre de dérivation DP. Ici, cette clé virtuelle VK est calculée en fonction de la clé mère VKi et de la date de création de la clé virtuelle VK. En variante, le ou les paramètres de dérivation utilisés pourraient être différents. On notera que, lorsque le serveur transmet au terminal mobile 20 la clé 20 virtuelle VK, il transmet également les paramètres de dérivation DP, pour une raison qui apparaîtra clairement dans la suite de la description, en référence à la figure 4. La méthode de sécurisation de l'accès au véhicule automobile 10 présente alors deux aspects, qui seront bien décrits en référence aux figures 3 et 25 4. Cette méthode comprend un premier aspect, que l'on pourra exposer sous la forme d'un procédé de transmission sécurisée d'une clé virtuelle VK depuis le serveur 50 vers le terminal mobile 20, dont les étapes principales sont illustrées sur la figure 3. 30 Elle comprend également un deuxième aspect, que l'on pourra exposer sous la forme d'un procédé d'authentification du terminal mobile 20 par l'unité électronique de commande 11, dont les étapes principales sont illustrées sur la figure 4. Selon une caractéristique particulièrement avantageuse de l'invention, la clé virtuelle VK a une durée de validité limitée. Le procédé de transmission sécurisée de la clé virtuelle VK illustré sur la figure 3 est alors prévu pour permettre de mettre à jour la clé virtuelle VK stockée dans le terminal mobile 20 avant que cette dernière ne vienne à échéance. Ainsi, il est prévu, avant la fin de validité de la clé virtuelle VK, une étape au cours de laquelle le serveur central 50 met automatiquement à jour la clé virtuelle VK, puis lorsque le terminal mobile 20 est accessible via le réseau de téléphonie mobile, une étape au cours de laquelle le serveur central 50 communique automatiquement cette clé virtuelle VK mise à jour au terminal mobile 20, ainsi que les paramètres de dérivation DP. Plus précisément, comme le montre la figure 3, au cours d'une première étape El, le serveur 50 détermine si la clé virtuelle approche de sa fin de validité. La durée de validité de la clé virtuelle VK pourra par exemple être fixée égale à 24 heures. On pourrait toutefois envisager que cette durée de validité varie en fonction de différents paramètres, tels que par exemple : - l'identité du propriétaire du terminal mobile 20 (la durée de validité étant choisie plus grande si le propriétaire du terminal mobile est le propriétaire du véhicule, et étant choisie moins grande s'il s'agit d'une personne louant le véhicule automobile, ...), - la région dans laquelle évolue le véhicule automobile 10 (la durée de validité étant choisie plus grande dans les régions où les réseaux de téléphonie mobile sont de moins bonnes qualités). Puis, dès que le serveur 50 détermine que la clé virtuelle VK approche ou atteint sa fin de validité, il élabore une nouvelle clé virtuelle VK mise à jour (étape E2). Cette nouvelle clé virtuelle VK est calculée en fonction de la clé mère VKi (qui reste ici inchangée pendant l'ensemble de la durée de la location du véhicule) et de la date de création de cette nouvelle clé virtuelle VK. Au cours d'une étape E3, le serveur 50 tente d'établir un contact avec le terminal mobile 20 (via le réseau public 40, la passerelle 34, la station de base 31 et la liaison radio). Si le terminal mobile 20 n'est pas accessible, le serveur 50 tente à nouveau d'établir un contact avec le terminal mobile 20, à intervalles réguliers, par exemple toutes les minutes. Au contraire, si le terminal mobile 20 est accessible, le contact est établi et il permet au serveur 50 de transmettre au terminal mobile 20 la nouvelle clé virtuelle VK mise à jour ainsi que les paramètres de dérivation DP (étape E4). Lorsqu'il reçoit ces informations, le terminal mobile 20 remplace dans sa mémoire 24 l'ancienne clé virtuelle par la nouvelle et les anciens paramètres de dérivation DP par les nouveaux (étape E5). Si, passé vingt-quatre heures, le serveur 50 n'est pas parvenu à établir le contact avec le terminal mobile 20, le procédé est réinitialisé à l'étape E2. On notera maintenant que lorsque le propriétaire du terminal mobile 20 se fait dérober son terminal mobile, il peut informer de ce vol le constructeur du véhicule automobile 10, de telle manière que le serveur 50 puisse transmettre au terminal mobile 20 une requête d'effacement de sa clé virtuelle VK. Le serveur 50 ne pourra bien entendu communiquer cette requête au terminal mobile 20 qu'à la condition que celui-ci soit connecté au réseau de téléphonie mobile. Dans le cas contraire, le risque est que le voleur conserve un accès au véhicule automobile. C'est pour réduire ce risque que le procédé d'authentification illustré sur la figure 4 est mis en oeuvre. Ce procédé d'authentification du terminal mobile 20 par l'unité électronique de commande 11 embarquée dans le véhicule automobile 10 est alors mis en oeuvre de la manière suivante. Au cours d'une étape S2, l'unité électronique de commande 11 du véhicule automobile 10 reçoit une demande de déverrouillage des portières du 25 véhicule. Ici, on considérera que cette demande est émise par le terminal mobile 20 (étape S1). Ainsi, à titre d'exemple, cette demande peut être exécutée manuellement par l'utilisateur, à l'aide de l'application utilisateur installée sur son terminal mobile 30 20, lorsqu'une liaison Bluetooth est établie entre le terminal mobile 20 et l'unité électronique de commande 11. Cette demande est formée par un ensemble de données transmises à l'unité électronique de commande 11, comportant notamment une requête de déverrouillage des portières et les paramètres de dérivation DP (ceux-là même qui ont permis au serveur 50 de calculer la clé virtuelle VK à partir de la clé racine VK0). Cette demande pourrait en variante être exécutée autrement. Elle pourrait par exemple être exécutée par l'utilisateur lorsqu'il manoeuvre l'une des poignées de portière du véhicule automobile. Dans cette variante, le véhicule automobile transmettrait alors un message au terminal mobile de manière que ce dernier lui retourne les paramètres de dérivation précités. Quoi qu'il en soit, lorsqu'elle reçoit une requête de déverrouillage des portières ainsi que les paramètres de dérivation DP, l'unité électronique de 10 commande 11 génère un défi (en anglais "challenge"), par exemple un nombre aléatoire RND (étape S3). L'unité électronique de commande 11 calcule alors à l'étape S4 une réponse RESP associée à ce défi RND par application de la fonction cryptographique f utilisant la clé virtuelle VK, ce que l'on peut écrire : 15 RESP = f(RND,VK). En effet, l'unité électronique de commande 11 ayant en mémoire la clé racine VK0 et ayant reçu les paramètres de dérivation DP, elle est adaptée à calculer au préalable la clé virtuelle VK. L'unité électronique de commande 11 du véhicule automobile 10 émet 20 alors à l'étape S5 le défi RND à destination du terminal mobile 20, grâce à la liaison Bluetooth établie. A l'étape S6, le terminal mobile 20 reçoit le défi RND. L'application utilisateur calcule à son tour, à l'étape 57, la réponse attendue RESP' par application au défi RND reçu de la fonction cryptographique f 25 utilisant la clé virtuelle VK mémorisée, ce que l'on peut écrire : RESP' = f(RND,VK). A l'étape 58, l'application utilisateur communique la réponse attendue RESP' à l'unité électronique de commande 11, grâce à la liaison Bluetooth. A l'étape S9, l'unité électronique de commande 11 du véhicule 30 automobile 10 reçoit donc cette réponse attendue RESP'. Elle compare alors la réponse RESP avec la réponse attendue RESP', en vérifiant si ces deux réponses sont égales (étape S10). Si l'égalité n'est pas vérifiée, l'unité électronique de commande 11 procède à l'étape S11, en mettant fin au processus d'authentification. De ce fait, l'accès au déverrouillage des portières ne sera pas autorisé. En effet, si l'égalité n'est pas vérifiée, cela signifie que la clé virtuelle utilisée pour le calcul de la réponse attendue RESP' n'est pas valide. En revanche, si l'égalité est vérifiée, cela signifie seulement que la clé virtuelle utilisée est ou fut valide. Alors, si l'égalité est vérifiée, l'unité électronique de commande 11 procède à l'étape S12 afin de vérifier si la clé virtuelle VK utilisée est encore valide. Au cours de cette étape, l'unité électronique de commande 11 vérifie si la date de création de la clé virtuelle VK utilisée (dont on rappelle qu'elle forme un paramètre de dérivation DP et qu'elle a été communiqué à l'unité électronique de commande 11 à l'étape S1) date de moins de 24 heures. Ici, on considère en effet que la durée de validité d'une clé virtuelle est toujours de 24 heures, et que cette durée de validité est donc connue de l'unité 15 électronique de commande 11. En variante, notamment dans le cas où cette durée de validité est variable d'une clé à l'autre, on pourra prévoir que cette durée de validité forme un paramètre de dérivation DP et qu'elle soit donc transmis à l'unité électronique de commande 11 au cours de l'étape S1. 20 Au cours de cette étape S12, l'unité électronique de commande 11 peut par ailleurs vérifier que l'utilisateur dispose, au moment de la tentative de déverrouillage des portières, d'un droit d'accès au véhicule. Elle peut en effet contrôler que le moment de la tentative de déverrouillage des portières est compris entre les dates de début et de fin de partage du véhicule automobile 10 25 (dont on rappelle qu'elles forment des paramètres de dérivation DP). Puis, si la clé virtuelle VK est valide et si l'utilisateur dispose d'un droit d'accès au véhicule, l'unité électronique de commande 11 procède à l'étape S13, en émettant à destination de l'actionneur 15 un signal de commande de la fonctionnalité demandée, ici le déverrouillage des portières du véhicule automobile 30 10. Dans le cas où l'utilisateur ne dispose plus d'un droit d'accès au véhicule, cet accès lui est refusé. Dans le cas où l'utilisateur dispose d'un droit d'accès au véhicule mais où la clé virtuelle n'est plus valide, différentes solutions peuvent être envisagées. La solution la plus simple est que, si la clé virtuelle VK n'est plus valide, l'unité électronique de commande mette directement fin au processus d'authentification. De ce fait, l'accès au déverrouillage des portières ne sera pas autorisé. Ainsi, lorsque le terminal mobile 20 a été volé et que le voleur a placé ce terminal mobile 20 « en mode avion », la clé virtuelle stockée dans le terminal mobile 20 ne reste valide qu'au maximum une journée. Passée cette journée, le voleur n'a donc plus accès au véhicule automobile 10. On peut en variante envisager une autre solution, qui est celle illustrée sur la figure 4 et qui, si la clé virtuelle VK n'est plus valide, permet toutefois à l'utilisateur de déverrouiller, sous certaines conditions, les portières. Il peut en effet arriver que le terminal mobile 20, bien que porté par son propriétaire, n'ait pas accès au réseau de téléphonie mobile et que le serveur 50 n'ait donc pas pu établir le contact avec celui-ci pour mettre à jour la clé virtuelle VK. Pour ne pas empêcher ce propriétaire d'accéder au véhicule automobile 10, il est alors prévu des étapes de vérification de l'identité du porteur du terminal mobile 20, de manière à vérifier que ce denier est bien autorisé à accéder au véhicule et qu'il ne s'agisse pas d'un voleur ayant dérobé le terminal mobile 20 à son propriétaire. Ces étapes supplémentaires pourront être mises en oeuvre soit directement par l'application utilisateur du terminal mobile 20 (le résultat de cette vérification étant ensuite transmis au véhicule automobile), soit par l'unité électronique de commande 11 du véhicule automobile 10. On considérera ici le cas où ces étapes sont mises en oeuvre par l'unité électronique de commande 11 du véhicule automobile 10. Ainsi, au cours d'une étape S14, l'unité électronique de commande 11 contrôle les droits attachés à la clé virtuelle VK. On considérera ici que chaque clé virtuelle VK présente soit un droit de dépassement temporaire de la durée de validité de cette clé virtuelle VK (cas par exemple où le propriétaire du terminal mobile est le propriétaire du véhicule automobile), soit aucun droit à un dépassement temporaire de la durée de validité de cette clé virtuelle VK (cas par exemple où le propriétaire du terminal mobile loue le véhicule automobile pour une durée réduite). Ici, on considérera que ce droit est attaché à la clé virtuelle VK en ce sens que ce droit fait parti des paramètres de dérivation DP ayant parmi d'aboutir au calcul de la clé virtuelle VK et que, à ce titre, sa valeur est transmis par le 5 terminal mobile 20 au véhicule automobile 10. Dans le cas où la clé virtuelle VK ne bénéficie d'aucun droit de dépassement, l'unité électronique de commande 11 met fin au processus d'authentification (étape S15). De ce fait, l'accès au déverrouillage des portières n'est pas autorisé. 10 Dans le cas contraire, le procédé se poursuit en une étape S16 au cours de laquelle l'unité électronique de commande 11 va vérifier si la clé virtuelle VK mémorisée dans le terminal mobile 20 n'est pas invalide depuis une durée trop importante. Pour cela, l'unité électronique de commande 11 lit, parmi les paramètres 15 de dérivation reçu, la date de création de la clé virtuelle VK mémorisée dans le terminal mobile. Si cette date est trop ancienne (si par exemple elle est dépassée depuis plus de sept jours), l'unité électronique de commande 11 met fin au processus d'authentification (étape S17). 20 Si la clé virtuelle VK a été générée il y a moins de sept jours, le procédé se poursuit en une étape S18 au cours de laquelle l'identité du porteur du terminal mobile 20 va être vérifiée. Cette étape consiste, pour l'unité électronique de commande 11, à commander le terminal mobile 20 de telle manière que ce dernier affiche sur son 25 écran tactile 27 un message demandant à l'utilisateur de renseigner une information personnelle (étape S19). Cette information personnelle peut consister en un code secret convenu au préalable avec le propriétaire du terminal mobile 20 (un code alpha numérique, un dessin à réaliser sur l'écran tactile, ...). Elle peut également consister en une 30 donnée biométrique, auquel cas le terminal mobile 20 doit être équipé d'un dispositif adapté (lecteur d'empreinte digitale, capteur d'image dont la définition permet d'acquérir une image très précise de l'iris, ...). Ici, on considérera le cas où l'information personnelle est un code secret. Alors, à l'étape S20, l'utilisateur renseigne le code secret sur l'écran tactile, puis le valide. On peut alors envisager deux solutions. La première solution consiste, pour le terminal mobile 20, à transmettre ce code secret à l'unité électronique de commande 11 de manière que celle-ci vérifie qu'il est exact. Cette première solution nécessite toutefois que l'unité électronique de commande 11 ait en mémoire la valeur de ce code secret. La seconde solution est que l'application utilisateur mémorisée dans le terminal mobile 20 vérifie elle-même si ce code est valable (étape S21). Cette solution nécessite que le terminal mobile 20 ait en mémoire soit le code, soit un moyen de vérifier l'exactitude de ce code. Mettre en mémoire ce code dans le terminal mobile peut s'avérer une solution pas suffisamment sécurisée. On préférera alors mémoriser dans la mémoire 24 du terminal mobile 20 une « fonction de hachage » et une « empreinte ». Une telle fonction, connue de l'homme du métier, permet, à partir d'une information d'entrée (ici le code secret), de donner un résultat (appeler « empreinte »). Une telle fonction est en revanche caractérisée par l'impossibilité pour une personne malveillante de retrouver l'information d'entrée à partir de l'empreinte. Un autre type de fonction dite « à sens unique » pourrait également être utilisée. Ainsi, au cours de cette étape S21, après que l'utilisateur a saisi le code secret, le terminal mobile calcule, au moyen de la fonction de hachage, l'empreinte qui lui est associée et il vérifie qu'elle correspond bien à l'empreinte mémorisée dans sa mémoire 24. Si tel n'est pas le cas, c'est-à-dire si le code secret renseigné n'est pas valable, le terminal mobile 20 met fin au processus d'authentification (étape S22). Dans le cas contraire, le terminal mobile renvoie à l'unité électronique de commande 11 un message validant l'identité du porteur du terminal mobile. Alors, l'unité électronique de commande 11 procède à l'étape S23, en émettant à destination de l'actionneur 15 un signal de commande de la fonctionnalité demandée, ici le déverrouillage des portières du véhicule automobile 10. En effet, dans ce cas, il aura été vérifié que la clé virtuelle VK stockée dans le terminal mobile 20 fut une clé valide, que cette clé virtuelle VK n'est pas trop ancienne, et que l'utilisateur était en possession de l'information personnelle demandée. On comprend donc que dans le cas où le porteur du terminal mobile 20 est le propriétaire du véhicule automobile 10, il garde un accès à ce dernier pendant huit jours après la dernière mise à jour de la clé virtuelle VK. On comprend également que dans le cas d'un voleur n'ayant pas à sa disposition l'information personnelle, ce voleur ne peut accéder au véhicule que le temps où la clé virtuelle VK est valide, c'est-à-dire moins de 24 heures, pour autant que le terminal mobile 20 ne soit pas accessible (« mode avion »). Enfin, dans le cas d'un voleur ayant à sa disposition l'information 10 personnelle (notamment le code secret qu'il aura extorqué au propriétaire du terminal mobile 20), il ne pourra disposer du véhicule automobile qu'une semaine au maximum, pour autant que le terminal mobile reste « en mode avion ». La présente invention n'est nullement limitée au mode de réalisation décrit et représenté, mais l'homme du métier saura y apporter toute variante 15 conforme à son esprit. En particulier, la fonctionnalité du véhicule automobile pour laquelle on souhaite contrôler l'accès pourra être le démarrage du moteur du véhicule automobile. Dans une variante de réalisation de l'invention, on pourra envisager que, 20 dans le cas où la clé virtuelle n'est plus valide, l'accès à la fonctionnalité soit autorisé si le porteur du terminal mobile peut renseigner non pas une mais plusieurs informations personnelles (par exemple un code secret puis une information biométrique). Selon une autre variante de réalisation de l'invention, on pourra 25 envisager que, dans le cas où la clé virtuelle n'est plus valide, le code secret ne soit pas demandé à chaque tentative d'accès au véhicule par le terminal mobile 20. On peut ainsi prévoir que, à l'étape S23, l'unité électronique de commande 11 renouvelle la clé virtuelle VK sur le terminal mobile 20, de manière que cette clé soit à nouveau valide pour 24 heures. Dans cette variante, ce renouvellement ne 30 pourra préférentiellement être répété qu'un nombre de fois consécutives limité, par exemple sept fois. REVENDICATIONS1. Procédé de sécurisation de l'accès à au moins une fonctionnalité d'un véhicule automobile (10) par un utilisateur, ledit utilisateur étant équipé d'un terminal mobile (20) dans lequel est stockée une clé virtuelle (VK) d'accès à ladite fonctionnalité, ledit terminal mobile (20) étant adapté, lorsqu'il est accessible, à communiquer avec un serveur central (50), caractérisé en ce que, la clé virtuelle (VK) ayant une durée de validité déterminée, il est prévu : - avant la fin de validité de la clé virtuelle (VK), une première étape au cours de laquelle le serveur central (50) met automatiquement à jour la clé virtuelle (VK), puis - lorsque le terminal mobile est accessible, une seconde étape au cours de laquelle le serveur central (50) communique automatiquement cette clé virtuelle (VK) mise à jour au terminal mobile (20). 2. Procédé de sécurisation selon la revendication précédente, dans laquelle la clé virtuelle (VK) étant élaborée à partir d'une clé mère (VKi) à laquelle est appliqué au moins un paramètre de dérivation (DP), - lors de la première étape, la clé virtuelle (VK) est mise à jour en modifiant la valeur dudit paramètre de dérivation (DP), et - lors de la seconde étape, ledit paramètre de dérivation (DP) est communiqué au terminal mobile. 3. Procédé de sécurisation selon l'une des revendications 1 et 2, dans lequel, le véhicule automobile (10) étant équipé d'une unité électronique (11) adaptée à contrôler la validité de la clé virtuelle (VK) stockée dans le terminal mobile (20), l'unité électronique (11) est adaptée à refuser l'accès à ladite fonctionnalité lorsque la clé virtuelle (VK) est invalide. 4. Procédé de sécurisation selon l'une des revendications 1 et 2, dans lequel, le véhicule automobile (10) étant équipé d'une unité électronique (11) adaptée à contrôler la validité de la clé virtuelle (VK) stockée dans le terminal mobile (20), l'unité électronique (11) est adaptée à autoriser l'accès à ladite fonctionnalité lorsque la clé virtuelle (VK) est invalide et que au moins deux conditions sont remplies, à savoir : - que la clé virtuelle (VK) stockée dans le terminal mobile (20) futprécédemment valide, et - que l'utilisateur a valablement renseigné une information personnelle demandée par le terminal mobile (20). 5. Procédé de sécurisation selon la revendication 4, dans laquelle, pour vérifier que l'utilisateur a valablement renseigné ladite information personnelle, le terminal mobile (20), ou respectivement l'unité électronique (11) du véhicule automobile (10), compare l'information personnelle renseignée, ou une valeur dérivée de cette information personnelle, avec une valeur préalablement mémorisée dans la mémoire du terminal mobile (20), ou respectivement de l'unité électronique (11). 6. Procédé de sécurisation selon l'une des revendications 4 et 5, dans laquelle ladite information personnelle comporte un code secret. 7. Procédé de sécurisation selon l'une des revendications 4 à 6, dans laquelle ladite information personnelle comporte une donnée biométrique. 8. Procédé de sécurisation selon l'une des revendications 4 à 7, dans laquelle il est prévu une autre condition pour que l'unité électronique (11) autorise l'accès à ladite fonctionnalité, à savoir que le temps passé depuis la fin de validité de la clé virtuelle (VK) n'a pas dépassé un seuil prédéterminé. 9. Procédé de sécurisation selon l'une des revendications 4 à 7, dans laquelle il est prévu une autre condition pour que l'unité électronique (11) autorise l'accès à ladite fonctionnalité, à savoir que le nombre d'accès à ladite fonctionnalité depuis la fin de validité de la clé virtuelle (VK) n'a pas dépassé un seuil prédéterminé. 10. Procédé de sécurisation selon l'une des revendications 4 à 9, dans laquelle il est prévu une autre condition pour que l'unité électronique (11) autorise l'accès à ladite fonctionnalité, à savoir qu'un droit de dépassement temporaire de la durée de validité est affecté à la clé virtuelle (VK).