FR 3057420 A1 20180413 FR 1659665 A 20161006 1 Procédé et système de synchronisation d'une heure d'un calculateur d'un véhicule avec celle d'un serveur distant L'invention concerne la synchronisation d'une horloge d'un calculateur de véhicule avec celle d'un serveur distant, plus particulièrement de la cadre de la gestion d'autorisation. On connaît par la demande de brevet français FR3022664 un procédé d'authentification d'une application exécutée sur un terminal auprès d'un fournisseur de service, par exemple un calculateur de véhicule. Le la procédé utilise des jetons, délivrés par un serveur, et décrivant des autorisations et des durées de validités. Un tel procédé nécessite une synchronisation des horloges du serveur et du fournisseur de service pour que les durées de validités soient bien respectées. Selon l'art connu, l'heure délivrée par des véhicules qui ne possèdent 15 pas de composant matériel dédié à cet usage n'est pas suffisamment fiable pour valider les informations horodatées reçues ou à émettre. Les besoins d'avoir une date et heure cohérentes entre celle du véhicule et celle des serveurs s'expliquent notamment pour gérer la validité des certificats, vérifier qu'une liste de révocation de certificat est valide, vérifier la cohérence de la 20 validité des droits, éviter l'usurpation de certificat permettant de consommer des services et éviter que l'utilisateur puisse altérer l'heure lui permettant de conserver des services auxquels il n'a plus les droits. Il existe donc un besoin d'un mécanisme permettant à un véhicule de de disposer d'une heure suffisamment fiable pour gérer les autorisations 25 délivrées par un serveur L'invention a donc pour but un procédé et un système de synchronisation de l'heure d'un véhicule avec celle d'un serveur distant de telle manière que le calculateur puisse valider des informations horodatées par le serveur. 30 Elle propose plus précisément à cet effet un procédé de synchronisation d'une heure d'un calculateur d'un véhicule avec celle d'un 3057420 2 serveur distant, comportant des étapes de : - Réception d'une demande d'un identifiant (UIN), - Emission d'une réponse signée par le boitier comprenant l'identifiant (UIN) demandé et une première heure (TO) correspondant à une 5 heure du calculateur au moment de la demande ; - Réception d'un jeton, généré par un serveur distant, comportant la première heure (TO), une durée de validité, et un horodatage généré par le serveur distant, - Calcul d'une durée d'échange, ladite durée d'échange étant 1 o égale à la différence entre une deuxième date (T1) et la première date (TO), la deuxième date (T1) étant égale à l'heure du calculateur au moment de la réception du jeton, - Si la durée d'échange est inférieure à un seuil prédéterminé (Delta) alors la mise à jour de l'heure du calculateur est permise à partir de 15 l'horodatage et ladite durée d'échange (DiffTime). L'invention permet de synchroniser l'heure d'un calculateur avec celle d'un serveur. L'invention a pour avantage de fonctionner avec un calculateur dépourvu d'un accès à un réseau étendu (de type Internet) et donc dépourvu d'un accès direct audit serveur. 20 Un terminal mobile est utilisé pour établir le dialogue entre le calculateur et le serveur. Un protocole de communication sécurisé permet de garantir l'authenticité des messages. Avantageusement, l'heure de mise à jour est égale à l'horodatage du serveur distant plus la durée d'échange. 25 Avantageusement, le jeton étant signé, l'horodatage du serveur distant est encodé dans la signature du jeton. De façon avantageuse, le procédé de mise à jour selon l'invention comprend en outre une étape d'extraction desdites valeurs du jeton. L'invention concerne aussi un calculateur de véhicule apte à 30 synchroniser son heure avec celle d'un serveur distant, caractérisé en ce qu'il comporte : 3057420 3 - Des moyens de réception d'une demande d'un identifiant, - Des moyens d'émission d'une réponse comprenant l'identifiant demandé et une première heure correspondant à une heure du calculateur au moment de la demande ; 5 - Des moyens de réception d'un jeton, généré par un serveur distant, comportant la première heure, une durée de validité, et un horodatage généré par le serveur distant, - Des moyens de calcul d'une durée d'échange, ladite durée d'échange étant égale à la différence entre une deuxième date et la première date, la deuxième date étant égale à l'heure du calculateur au moment de la réception du jeton, - Des moyens de mise à jour de l'heure du calculateur à partir de l'horodatage et de ladite durée d'échange, si la durée d'échange est inférieure à un seuil prédéterminé. L'invention concerne aussi un véhicule caractérisé en ce qu'il comporte un calculateur selon la revendication précédente. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels: - la figure 1 illustre exemple de système selon l'invention ; - la figure 2 illustre un logigramme représentant le procédé selon l'invention Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant. En référence à la figure 1, un système de synchronisation selon l'invention comporte au moins un terminal 103, un fournisseur de service 104 et une autorité d'authentification 101. L'accès, par le terminal 103, à des données ou des services du fournisseur de service 104 nécessite une authentification et des autorisations délivrées par l'autorité d'authentification 101. Le fournisseur de service 104 et l'autorité d'authentification 101 disposent chacun d'une heure d'horloge propre. Il existe donc un besoin d'un mécanisme de synchronisation de l'horloge du fournisseur de 104 avec 3057420 4 l'autorité d'authentification 101. Dans ce qui suit, on considère à titre d'exemple non limitatif que le terminal 103 est un téléphone mobile intelligent (aussi appelé smartphone en anglais). Mais l'invention n'est pas limitée à cet exemple. En effet, le terminal 5 103 peut être un ordinateur portable, une tablette tactile ou tout autre objet connecté (i.e. susceptible d'échanger des données via une connexion sans fils). Cet équipement mobile appartient, par exemple, au conducteur d'un véhicule ou à l'un des passagers du véhicule. Le fournisseur de service 104 (ou SP pour « Service Provider » en 10 anglais) est une ressource informatique. Le SP 104 contrôle l'accès à des données ou des commandes permettant de réaliser une activité. Le SP 104 protège l'accès à des données et à des applications. Il refuse tout accès sans authentification préalable. De façon avantageuse, il redirige l'utilisateur non authentifié vers un fournisseur d'identité. L'accès au service est donc restreint. 15 Les utilisateurs doivent être identifiés avant de pouvoir accéder à une donnée ou lancer l'exécution d'une commande. Dans la suite du document, le SP 104 est aussi appelée ressource 104 ou boitier 104. Les authentifications et les autorisations sont communiquées au moyen de jetons d'autorisation aussi appelés token ou encore « identity 20 credentials » en anglais. Les jetons utilisés pour transmettre les autorisations, sont chiffrés (ou cryptés) selon un mécanisme de cryptographie asymétrique (aussi appelé cryptographie à clé publique). Dans un tel système, on utilise une paire de clés : une clé publique pour le chiffrement et une clé privée pour le 25 déchiffrement. Lorsqu'une ressource envoie un jeton à une autre ressource informatique, il lui suffit de chiffrer le jeton à envoyer au moyen de la clé publique du destinataire. Ce dernier sera en mesure de déchiffrer le message à l'aide de sa clé privée (qu'il est seul à connaître). Les jetons intègrent les autorisations qui permettent de donner les 30 accès à des fonctions ou des données sur les services hébergés sur le SP 104. 3057420 5 Les autorisations sont vérifiées par le SP 104 soit en faisant une interrogation vers un annuaire de référence soit vers un manifeste interne au boitier permettant de faire des autorisations pouvant être communes dans le jeton mais n'apportant pas les mêmes services sur les différents systèmes. 5 Le SP 104 comporte un espace de stockage sécurisé apte à stocker une clé privée utilisée pour déchiffrer les jetons d'autorisation. L'espace de stockage sécurisé est par exemple une puce TPM (pour Trusted Platform Module), qui est un composant cryptographique matériel permettant de stocker des secrets (tels que des clefs de chiffrement) de manière sécurisée. la Dans ce qui suit, on considère à titre d'exemple non limitatif que le SP 104 est un boitier électronique d'un véhicule automobile. Le boitier électronique est un organe embarqué du véhicule qui est la frontière des données véhicule vers l'extérieur au travers de différents moyens : câble, protocoles sans fils (wifi, bluetooth,3G, etc.). 15 Mais l'invention n'est pas limitée à cet exemple. En effet, le SP peut être un système d'information de gestion ou un système qui pilote une machine à commande numérique ou plus généralement n'importe quel objet connecté (i.e. susceptible d'échanger des données via une connexion avec ou sans fil) et comprenant un espace de stockage sécurisé susceptible de 20 stocker une clé privée. De façon avantageuse le véhicule comporte aussi un compteur de temps, qui peut être le calculateur 104 ou un autre calculateur du véhicule. Le compteur de temps comptabilise les battements de temps (heartbeat) d'une seconde. Il ne fait que s'incrémenter et permet de 25 déterminer l'avancement du temps. Techniquement, c'est l'incrémentation d'une valeur numérique. L'autorité d'authentification 101 (ou fournisseur d'identité ou IdP pour Identity Provider) s'occupe d'authentifier l'utilisateur ainsi que de récupérer des informations additionnelles associées à son véhicule. L'Idp 101 permet 30 aux utilisateurs 102 de s'authentifier et de fournir des jetons au terminal 103 (ordinateur personnel ou Smartphone) leur permettant d'être reconnu auprès 3057420 6 du SP 104. Ainsi, l'Idp 101 permet d'autoriser un terminal 103 d'un utilisateur 102 à accéder à une ressource 104. Pour ce faire l'Idp 101 comporte des moyens de génération d'un jeton 5 et des moyens d'émission dudit jeton à destination du terminal 103. En particulier les moyens de génération du jeton comportent : - des moyens de création d'un premier champ de données comportant au moins les informations de validité du jeton ; - des moyens de création d'un deuxième champ de données 10 comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal 103 de l'utilisateur 102 sur la ressource 104 ; - des moyens de chiffrement des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la 15 mémoire de la ressource 104, - des moyens d'horodatage et de synchronisation avec un référentiel de temps. De façon avantageuse, l'Idp 101 comporte, en outre, des moyens pour signer, de façon électronique, des jetons d'autorisation. La signature 20 électronique permet de garantir l'intégrité d'un jeton et d'en authentifier l'auteur. Le système de signature électronique utilise une paire de clés. Une clé privée utilisée pour signer un jeton et une clé publique pour permettant de lire le jeton signé. Un tel système comporte généralement une infrastructure à clés 25 publiques (ou PKI pour Public Key Infrastructure en anglais) autrement dit une ressource informatique permettant de générer, de distribuer et de publier des certificats aux différents composants nécessaires (SP, IdP...). L'IdP 101 et le SP 104, disposent chacun d'un certificat qui leur est propre. On rappelle qu'un certificat (ou certificat électronique) est un 30 ensemble de données contenant au moins une clé publique, au moins une 3057420 7 information d'identification (par exemple : un nom, généralement stocké dans un champ de données dit CN pour « Common Name ») et au moins une clé privée pour signer. Le système comporte également une interface Internet par 5 l'intermédiaire de laquelle un utilisateur peut s'authentifier auprès de l'Idp 101. Dans le système de la figure 1, les jetons sont générés et utilisés de la façon suivante. Un jeton est produit par l'Idp 101, en réponse à une demande d'un utilisateur (préalablement authentifié auprès de l'autorité d'authentification 101). Le jeton est transporté par le terminal 103 de 10 l'utilisateur pour être finalement vérifié et consommé par le boîtier embarqué 104 pour autoriser l'utilisateur et une application exécutée sur le terminal 103 à accéder à certaines fonctions du boîtier 104 (par exemple le déverrouillage d'un ouvrant du véhicule). Un jeton d'autorisation est par exemple structuré de la manière 15 suivante (structure de type JSON). Le jeton d'autorisation comporte : - une première donnée (access_token) contenant les droits de l'utilisateur, chiffrés avec la clé publique du boîtier embarqué 104 (par exemple avec un algorithme de chiffrement asymétrique par exemple de type 20 RSA). Ainsi, seul le boîtier 104 destinataire peut déchiffrer le contenu du jeton. - une deuxième donnée (token_type) dont la valeur est fixée à « bearer » pour indiquer qu'il s'agit d'un jeton d'accès standard (par opposition à un jeton de conservation). 25 - une troisième donnée (expires_in) correspondant à une valeur de durée de validité du jeton. - Une quatrième donnée (expires) correspondant à une date et la valeur déterminant la durée validité du jeton (expires_in) - Une cinquième donnée (refresh_token) correspondant à une 30 chaîne aléatoire générée par l'autorité d'authentification 101 permettant de 3057420 8 requérir ultérieurement un nouveau jeton sans nouvelle authentification de la part de l'utilisateur, - Une sixième donnée token_signature correspondant à une signature de type HMAC (il s'agit d'un condensat (ou « hash ») du jeton, 5 généré grâce à un algorithme de hachage (par exemple SHA-1) et chiffré avec la clé privée de l'autorité d'authentification 101 (par exemple un algorithme de chiffrement asymétrique RSA). La signature assure l'authenticité de l'émetteur et l'intégrité (non-altération) du message. De façon avantageuse, la sixième donnée comporte un horodatage 10 généré par le serveur. L'ajout de l'horodatage dans la signature est réalisé selon une méthode connue de l'homme du métier. Le jeton comporte aussi une première heure To correspondant à une heure du calculateur 104 au moment de la demande d'autorisation contenu dans le champ expires (quatrième donnée). 15 L'invention concerne aussi un procédé de synchronisation d'une heure d'un calculateur 104 d'un véhicule 105 avec celle d'un serveur distant (101). En référence à la figure 2, le procédé comporte les étapes suivantes. Le procédé comporte d'abord une étape de connexion, de 20 l'application exécutée sur le terminal 103, sur le calculateur connecté 104 Après l'établissement du média de communication, l'application sur le terminal 103 interroge 201 le calculateur 104 en lui demandant son identifiant (UIN). Celui-ci lui répond 202 avec un message signé incluant son identifiant 25 (UIN) et une première heure TO correspondant à l'heure du calculateur 104 au moment de la demande. L'application transmet 103 une requête incluant le message issu du calculateur 104 pour s'authentifier sur le serveur IdP 101. L'utilisateur 102 s'authentifie (étapes 204 et 205) de façon plus ou 30 moins forte, par exemple envoyant un identifiant et un mot de passe (étape 205) en réponse à la réception d'une demande d'identification (étape 204). Ensuite, l'IdP 101 valide les droits de l'utilisateur sur le véhicule. Si l'utilisateur 3057420 9 102 est rejeté à l'authentification, un message d'erreur est transmis. L'IdP 101 émet 206 un jeton à destination du terminal 103. Dans le jeton est inclu le champs expires qui contient l'heure du HU et la durée de validité (lié au compteur de temps du HU). 5 Dans la signature du jeton est inclu un horodatage (aussi appelé timestamp) du serveur 101 afin de garantir un référentiel de temps pour la comparer sur le calculateur 104. Le jeton est reçu par le terminal 103 puis transmis 207 vers le calculateur 104. 10 Le calculateur 104 vérifie 208 la signature du jeton. L'heure du serveur 101 est extraite de l'horodatage contenu dans la signature du jeton. Le calculateur 104 extrait aussi la première heure TO du jeton. Le calculateur détermine ensuite la différence entre l'heure actuelle 15 du calculateur 104 (aussi appelée deuxième heure T1) et la première heure TO. Cette différence est appelée durée d'échange DiffTime (aussi appelée round time trip). Elle correspond au délai entre l'envoi 201 de l'identifiant UIN par le calculateur et la réception 207 du jeton. L'heure du calculateur 104 est mise à jour 210 à partir de l'heure du 20 serveur et de la durée d'échange. Par exemple, la nouvelle heure du calculateur 104 est égale à l'heure du serveur à laquelle on ajoute la durée de transmission. Ce mécanisme ne garantit pas que l'heure du serveur 101 et celle du calculateur 104 soient exactement les mêmes. Par contre, la précision est 25 suffisante pour vérifier la validité des autorisations des jetons. De façon avantageuse, le procédé selon l'invention comporte en outre des étapes suivantes. Une première étape consiste en une mise à l'heure initiale (Tinit) du calculateur 104. Cette étape est réalisée par exemple en usine, lors de la 3o mise en service du calculateur 104. Une fois l'heure paramétrée dans le calculateur 104, celui-ci capture la valeur diffusée par le compteur (Cptlnit) pour synchronisation entre l'heure 3057420 10 du calculateur 104et la valeur envoyée par le compteur (Cptlnit). L'heure du calculateur est incrémentée en fonction du compteur selon la relation suivante T=Tinit+(Cpt-Cptinit) où T est l'heure du calculateur 104, Tinit l'heure initiale du calculateur 5 104, Cpt la valeur courante du compteur et Cptinit la valeur initiale du compteur. Lors d'un endormissement (aussi appelé mise veille du calculateur 104), le calculateur 104 réalise une capture de la valeur du compteur (CptendormissementReseau), et de son heure actuelle 10 (TendormissementReseau), Au réveil réseau suivant, le calculateur 104 se resynchronisation avec une valeur du compteur capturée au reveil (Cpt) ; La nouvelle valeur initial (Cptinit) du compteur suit alors la relation suivante Cptinit= Cpt-CptendormissementReseau ; 15 La nouvelle valeur initial du calculateur 104 suit la relation suivante Tinit= TendormissementReseau+ Cptinit. REVENDICATIONS1. Procédé de synchronisation d'une heure d'un calculateur (104) d'un véhicule (105) avec celle d'un serveur distant (101), comportant des étapes de : - Réception (201) d'une demande d'un identifiant (UIN), - Emission (202) d'une réponse signée comprenant l'identifiant (UIN) demandé et une première heure (T0) correspondant à une heure du calculateur (104) au moment de la demande ; - Réception (207) d'un jeton, généré par un serveur distant (101), comportant la première heure (T0), une durée de validité (expires_in), et un horodatage généré par le serveur distant (101), - Calcul (209) d'une durée d'échange (DiffTime), ladite durée d'échange (DiffTime) étant égale à la différence entre une deuxième date (Ti) et la première date (T0), la deuxième date (T1) étant égale à l'heure du calculateur (104) au moment de la réception du jeton, - Si la durée d'échange (DiffTime) est inférieure à un seuil prédéterminé (Delta) alors la mise à jour (210) de l'heure du calculateur (104) à partir de l'horodatage et de ladite durée d'échange (DiffTime). 2. Procédé de mise à jour selon la revendication 1, caractérisé en ce que l'heure de mise à jour est égale à l'horodatage du serveur distant (101) plus la durée d'échange (Difftime). 3. Procédé de mise à jour selon l'une des revendications précédentes, caractérisé en ce que le jeton étant signé, l'horodatage du serveur distant (101) est encodé dans la signature du jeton. 4. Procédé de mise à jour selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape d'extraction (208) 3057420 12 desdites valeurs du jeton, 5. Calculateur (104) de véhicule (105) apte à synchroniser son heure avec celle d'un serveur distant (101), caractérisé en ce qu'il comporte : 5 - Des moyens de réception d'une demande d'un identifiant (UIN), - Des moyens d'émission d'une réponse comprenant l'identifiant (UIN) demandé et une première heure (T0) correspondant à une heure du calculateur (104) au moment de la demande ; - Des moyens de réception d'un jeton, généré par un serveur distant (101), 10 comportant la première heure (To), une durée de validité (expire_in), et un horodatage généré par le serveur distant (101), - Des moyens de calcul d'une durée d'échange (DiffTime), ladite durée d'échange (DiffTime) étant égale à la différence entre une deuxième date (Ti) et la première date (To), la deuxième date (Ti) étant égale à l'heure du 15 calculateur (104) au moment de la réception du jeton, - Des moyens de mise à jour de l'heure du calculateur (104) à partir de l'horodatage et de ladite durée d'échange (DiffTime), si la durée d'échange (DiffTime) est inférieure à un seuil prédéterminé (Delta) 20 6. Véhicule caractérisé en ce qu'il comporte un calculateur selon la revendication précédente.