FR3057420A1 - Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant - Google Patents

Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant Download PDF

Info

Publication number
FR3057420A1
FR3057420A1 FR1659665A FR1659665A FR3057420A1 FR 3057420 A1 FR3057420 A1 FR 3057420A1 FR 1659665 A FR1659665 A FR 1659665A FR 1659665 A FR1659665 A FR 1659665A FR 3057420 A1 FR3057420 A1 FR 3057420A1
Authority
FR
France
Prior art keywords
time
computer
token
remote server
hour
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1659665A
Other languages
English (en)
Inventor
Sylvain Patureau Mirand
Zakaria Lamghari
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PSA Automobiles SA
Original Assignee
Peugeot Citroen Automobiles SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Peugeot Citroen Automobiles SA filed Critical Peugeot Citroen Automobiles SA
Priority to FR1659665A priority Critical patent/FR3057420A1/fr
Publication of FR3057420A1 publication Critical patent/FR3057420A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un 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, - Emission (202) d'une réponse comprenant l'identifiant demandé et une première heure 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, une durée de validité, et un horodatage généré par le serveur distant (101), - Calcul (209) 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 (104) au moment de la réception du jeton, - Si la durée d'échange est inférieure à un seuil prédéterminé alors la mise à jour (210) de l'heure du calculateur (104) à partir de l'horodatage et ladite durée d'échange.

Description

Titulaire(s) : PEUGEOT CITROEN AUTOMOBILES SA Société anonyme.
Demande(s) d’extension
Mandataire(s) : PEUGEOT CITROEN AUTOMOBILES SA Société anonyme.
FR 3 057 420 - A1
164) PROCEDE ET SYSTEME DE SYNCHRONISATION AVEC CELLE D'UN SERVEUR DISTANT.
©) L'invention concerne un 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,
- Emission (202) d'une réponse comprenant l'identifiant demandé et une première heure 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, une durée de validité, et un horodatage généré par le serveur distant (101),
- Calcul (209) 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 (104) au moment de la réception du jeton,
- Si la durée d'échange est inférieure à un seuil prédéterminé alors la mise à jour (210) de l'heure du calculateur (104) à partir de l'horodatage et ladite durée d'échange.
D'UNE HEURE D'UN CALCULATEUR D'UN VEHICULE
i
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 5 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 io 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 i5 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
0 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 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.
0 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 serveur distant, comportant des étapes de :
Réception d’une demande d’un identifiant (UIN),
Emission d’une réponse signée par le boîtier comprenant l’identifiant (UIN) demandé et une première heure (T0) correspondant à une 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 (T0), 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 égale à la différence entre une deuxième date (T1) et la première date (T0), 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 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.
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.
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 à synchroniser son heure avec celle d’un serveur distant, caractérisé en ce qu’il comporte :
- 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 ;
- 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 îo 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é.
is 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:
0 - 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 25 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.
0 Le fournisseur de service 104 et l’autorité d'authentification 101 disposent chacun d’une heure d’horloge propre. II existe donc un besoin d’un mécanisme de synchronisation de l’horloge du fournisseur de 104 avec 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 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 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. 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 boîtier 104.
Les authentifications et les autorisations sont communiquées au moyen de jetons d'autorisation aussi appelés token ou encore « identity 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 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 accès à des fonctions ou des données sur les services hébergés sur le SP 104.
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.
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.
îo 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.).
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
0 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 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
0 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 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 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 îo 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 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
0 é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 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 ensemble de données contenant au moins une clé publique, au moins une 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 îo 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
0 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).
- 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
0 chaîne aléatoire générée par l’autorité d'authentification 101 permettant de 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 condensât (ou « hash ») du jeton, 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 îo 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).
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
2o 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 (UIN) et une première heure T0 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
0 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
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 indu le champs expires qui contient l’heure du HU et la durée de validité (lié au compteur de temps du HU).
Dans la signature du jeton est indu 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.
îo 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 T0 du jeton.
Le calculateur détermine ensuite la différence entre l’heure actuelle du calculateur 104 (aussi appelée deuxième heure T1) et la première heure T0. 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
2o 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 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
0 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 ίο 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-Cptlnit) 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 io (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 ;
La nouvelle valeur initial du calculateur 104 suit la relation suivante
Tinit= TendormissementReseau+ Cptinit.

Claims (6)

  1. REVENDICATIONS
    5 1. 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) îo demandé et une première heure (To) 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 (To), une durée de validité (expires_in), et un horodatage généré par le serveur distant (101 ),
    15 - 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 (T-ι) et la première date (To), la deuxième date (T-ι) é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é
  2. 2 0 (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
    25 durée d’échange (Difftime).
  3. 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. 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) desdites valeurs du jeton,
  5. 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 (To) 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), îo 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 (ΤΊ) é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)
    2 0
  6. 6. Véhicule caractérisé en ce qu’il comporte un calculateur selon la revendication précédente.
    1/2
    2/2
FR1659665A 2016-10-06 2016-10-06 Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant Withdrawn FR3057420A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1659665A FR3057420A1 (fr) 2016-10-06 2016-10-06 Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1659665 2016-10-06
FR1659665A FR3057420A1 (fr) 2016-10-06 2016-10-06 Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant

Publications (1)

Publication Number Publication Date
FR3057420A1 true FR3057420A1 (fr) 2018-04-13

Family

ID=57750170

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1659665A Withdrawn FR3057420A1 (fr) 2016-10-06 2016-10-06 Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant

Country Status (1)

Country Link
FR (1) FR3057420A1 (fr)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
B. HABERMAN, ED., D. MILLS: "Network Time Protocol Version 4: Autokey Specification", REQUEST FOR COMMENTS (RFC) 5906, 21 June 2010 (2010-06-21), Internet Engineering Task Force (IETF), pages 1 - 58, XP015070845 *
D.MILLS, J. MARTIN, ED., J. BURBANK, W. KASCH: "Network Time Protocol Version 4: Protocol and Algorithms Specification", REQUEST FOR COMMENTS (RFC) 5905, 21 June 2010 (2010-06-21), Internet Engineering Task Force (IETF), pages 1 - 110, XP015070844 *

Similar Documents

Publication Publication Date Title
EP3547202B1 (fr) Méthode d'accès à des données anonymisées
WO2017055716A1 (fr) Procede et dispositif d'authentification ameliores
EP3174241B1 (fr) Méthode d'établissement d'une communication sécurisée de bout en bout entre le terminal d'un utilisateur et un objet connecté
US9300639B1 (en) Device coordination
EP1471682A1 (fr) Procédé de signature électronique avec mécanisme de délégation, équipements et programmes pour la mise en oeuvre du procédé
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
FR3066666A1 (fr) Procede de securisation d'une communication sans gestion d'etats
WO2015193578A1 (fr) Procede et systeme d'authentification au moyen de jetons
WO2017081208A1 (fr) Procede de securisation et d'authentification d'une telecommunication
EP1011223A1 (fr) Procédé de création et gestion d'au moins une clé cryptographique et système pour sa mise en oeuvre
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
EP3532973A1 (fr) Procédé d'installation d'un certificat dans un calculateur de véhicule, calculateur et système associés
FR3057420A1 (fr) Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant
EP1400090B1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
EP2808819B1 (fr) Procédé de mise à jour de certificats dans un dispositif portable
EP3899765B1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
FR3093887A1 (fr) Procédé pour délivrer, à un dispositif nomade, une autorisation d’accès à un calculateur connecté d’un véhicule
FR3073998B1 (fr) Procede numerique de controle d'acces a un objet, une ressource ou service par un utilisateur
FR3041841A1 (fr) Procede et dispositif pour acceder a une ressource a l’aide d’un jeton chiffre
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
WO2007101941A1 (fr) Procede pour l' appairage securise de deux systemes prealablement a leur mise en communication
FR3049087A1 (fr) Procede permettant a des dispositifs par l'intermediaire de connaissances et de capacites croisees, de realiser des transactions a travers un reseau informatique decentralise
EP4160987A1 (fr) Procédé pour générer une signature électronique au moyen du protocole fido
CN117675234A (zh) 一种数据处理方法、设备及计算机可读存储介质
FR3044500A1 (fr) Procede et systeme d'acces, par un serveur, a des donnees confidentielles disponibles aupres d'un fournisseur de service.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180413

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

ST Notification of lapse

Effective date: 20230606