FR3135546A1 - Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés - Google Patents

Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés Download PDF

Info

Publication number
FR3135546A1
FR3135546A1 FR2204569A FR2204569A FR3135546A1 FR 3135546 A1 FR3135546 A1 FR 3135546A1 FR 2204569 A FR2204569 A FR 2204569A FR 2204569 A FR2204569 A FR 2204569A FR 3135546 A1 FR3135546 A1 FR 3135546A1
Authority
FR
France
Prior art keywords
data
installation
authorization
software
block
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.)
Pending
Application number
FR2204569A
Other languages
English (en)
Inventor
David Fernandez Blanco
Trista Lin
Frédéric LE MOUËL
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.)
Institut National des Sciences Appliquees de Lyon
PSA Automobiles SA
Original Assignee
Institut National des Sciences Appliquees de Lyon
PSA 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 Institut National des Sciences Appliquees de Lyon , PSA Automobiles SA filed Critical Institut National des Sciences Appliquees de Lyon
Priority to FR2204569A priority Critical patent/FR3135546A1/fr
Publication of FR3135546A1 publication Critical patent/FR3135546A1/fr
Pending 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/12—Applying verification of the received information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Abstract

Procédé d’autorisation d’installation d’un logiciel (123) dans un ego véhicule automobile (100) comprenant une mémoire (120) mémorisant une chaine de blocs (130) et des données d’autorisation (122) de l’installation, le procédé étant caractérisé en ce qu’il comprend les étapes suivantes : Réception de données d’installation (121) du logiciel (123), un premier bloc (131) dans la chaine de bloc (130) comprenant une empreinte cryptographique des données d’installation (121),Vérification d’une autorisation de l’installation à partir des données d’autorisation (122) et du premier bloc (131),Une étape d’installation du logiciel (123) en mémoire (120) à partir des données d’installation (121) à condition que l’installation soit autorisée et que l’empreinte corresponde aux données d’installation (121). Figure pour l’abrégé : figure 1

Description

Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés
L’invention concerne l’installation de logiciels dans un véhicule automobile.
Les véhicules actuels ont plusieurs processeurs ou systèmes fonctionnant avec des logiciels (autrement dit : programme d’ordinateur) embarqués dans la mémoire des véhicules automobiles. Ces logiciels doivent être mis à jour de manière sécurisée.
Dans ce but, l’invention concerne un procédé d’autorisation de l’installation d’un logiciel dans un ego véhicule automobile comprenant une mémoire mémorisant une chaine de blocs et des données d’autorisation de l’installation, le procédé étant caractérisé en ce qu’il comprend les étapes suivantes :
  • Réception de données d’installation du logiciel, un premier bloc dans la chaine de bloc comprenant une empreinte (autrement dit : un condensat) cryptographique des données d’installation,
  • Vérification d’une autorisation de l’installation à partir des données d’autorisation et du premier bloc,
  • Une étape d’installation du logiciel en mémoire à partir des données d’installation à condition que l’installation soit autorisée et que l’empreinte corresponde aux données d’installation (le procédé peut ainsi comprendre par exemple une étape de vérification que l’empreinte correspond aux données d’installation).
Ainsi, la distribution du logiciel présente l’avantage d’être :
- Contrôlée et sécurisée grâce aux données de sécurisation et à l’empreinte,
- Décentralisée, tout en permettant une traçabilité, grâce à l’utilisation d’une chaine de blocs.
Une chaine de blocs est par exemple un registre distribué avec des blocs confirmés organisés en chaîne séquentielle incrémentale utilisant des liens cryptographiques. La chaine de blocs est par exemple conforme à la norme 22739:2020 de l’organisation internationale de normalisation.
Ce procédé est mis en œuvre, par exemple, par un dispositif électronique. Le dispositif électronique peut comporter (ou être constitué) de plusieurs processeurs électroniques ou microcontrôleurs comportant une ou plusieurs mémoires.
L’invention concerne ainsi également un dispositif électronique configuré pour mettre en œuvre les étapes de ce procédé.
Une fois le logiciel installé, il peut être exécuté par un processeur de l’égo véhicule.
Afin de résoudre le même problème et avec les mêmes avantages, l’invention concerne également un procédé d’installation d’un logiciel, mis en œuvre dans un serveur mémorisant une chaine de blocs, le procédé étant caractérisé en ce qu’il comporte les étapes suivantes :
  • Envoi de données d’installation du logiciel, un premier bloc dans la chaine de bloc comprenant une empreinte (autrement dit : un condensat) cryptographique des données d’installation,
  • Envoi de données d’autorisation d’installation du logiciel, (les données d’autorisation d’installation étant) pour la mise en œuvre d’une étape de vérification d’autorisation de l’installation à partir des données d’autorisation et du premier bloc (le procédé peut ainsi comprendre par exemple une étape de vérification que l’empreinte correspond aux données d’installation).
De manière générale, l’envoi et la réception selon l’invention peut être mis en œuvre par un réseau de télécommunication, par exemple un réseau de télécommunication cellulaire mobile.
Par exemple, l’empreinte cryptographique est obtenue à partir d’une fonction de hachage.
Selon un mode de réalisation, le procédé comprend en outre les étapes suivantes :
  • Réception des données d’installation depuis un premier ordinateur client identifié (auprès du serveur) à partir de premières données d’identification et authentifié (auprès du serveur) à partir de premières données d’authentification mémorisées par le premier ordinateur,
  • Réception des données d’autorisation depuis un deuxième ordinateur client identifié à partir de deuxièmes données d’identification (auprès du serveur) et authentifié à partir de deuxièmes données d’authentification (auprès du serveur) mémorisées par le deuxième ordinateur,
  • Les premières données d’identification étant différentes des deuxièmes données d’identification,
  • Les premières données d’authentification étant différentes des deuxièmes données d’authentification,
  • Le premier ordinateur client étant différent (autrement dit : distincts) du deuxième ordinateur client.
En variante, les données d’installation et les données d’autorisation peuvent être reçues du même ordinateur client ou même être engendrées par le serveur.
Avant la transmission des données d’autorisation par le deuxième ordinateur client, le logiciel peut être validé, par exemple par l’acteur (l’acteur est par exemple : une entreprise, un utilisateur, un groupe d’utilisateur) détenteurs du compte (ou utilisant le compte) identifié par les deuxièmes données d’identification et authentifié par les deuxièmes données d’authentification.
Ces étapes peuvent être réalisés pour une pluralité (un nombre supérieur à 2, voire supérieur à 5) de premiers ordinateurs clients et de deuxièmes ordinateurs clients ayant des données d’identification et des données d’authentification différentes les uns des autres.
Les données d’autorisation et d’installation sont alors mémorisées dans la mémoire du serveur.
Selon un mode de réalisation :
  • Les données d’autorisation comprennent un premier identifiant du logiciel, et
  • Le premier bloc comprend un deuxième identifiant du logiciel.
L’installation est par exemple autorisée à condition que le premier identifiant et le deuxième identifiant correspondent, par exemple qu’ils soient égaux.
En variantes, les données d’autorisation peuvent comprendre un code obtenu à partir d’un algorithme cryptographique symétrique.
Selon un mode de réalisation, les données d’autorisation comprennent une signature (par exemple, le premier identifiant est signé, si les données d’autorisation comprennent un premier identifiant du logiciel)
Par exemple, l’installation est autorisée à condition que la signature soit conforme (c’est-à-dire, par exemple, à condition que le résultat de l’encryptage de la signature avec la clef publique soit le premier identifiant).
Par exemple, la mémoire de l’égo véhicule mémorise une clef publique pour vérifier la signature. Ainsi, la signature est encryptée avec la clef privée, la clef privée formant avec la clef publique une paire de clefs asymétrique).
Le procédé peut comporter une étape de signature à partir de la clef privée mis en œuvre dans le deuxième ordinateur.
En variante, les données d’autorisation sont sécurisées grâce à la mise en œuvre d’un canal sécurisé entre l’égo véhicule et le serveur (ou le deuxième véhicule).
Selon un mode de réalisation, la chaine de bloc est mise à jour dans le serveur lorsque des blocs (par exemple le premier bloc, ou comprenant le premier bloc) sont reçues du premier ordinateur client, par exemple en même temps que les données d’installation du logiciel (ou les parties de la chaine de bloc mis à jour, ou uniquement les parties de la chaine de bloc jusqu’au premier bloc).
En variante, la chaine de bloc est mise à jour dans le serveur par le serveur sur réception des données d’installation.
Dans l’égo véhicule, la chaine de bloc peut être mis à jour par des connexions périodiques ou en réponse à la requête d’autorisation ci-dessous. Le serveur envoi alors la chaine de bloc à l’égo véhicule qui la mémorise dans sa mémoire. En variante, la chaine de bloc peut être mis à jour dans la mémoire de l’égo véhicule lorsqu’un deuxième véhicule comprenant une chaine de bloc à jour est proche de l’égo véhicule. La chaine de bloc peut alors être communiquée par le deuxième véhicule à de l’égo véhicule.
Selon un mode de réalisation, le procédé comprend en outre une étape de réception des données d’installation du logiciel et du premier bloc de la part d’un deuxième véhicule.
Selon un mode de réalisation, les données d’installation et le premier bloc sont reçues alors que les données d’autorisation sont déjà dans la mémoire de l’égo véhicule.
Selon un mode de réalisation, le procédé comprenant en outre l’étape suivante :
  • Envoi d’une requête d’autorisation d’installation du logiciel,
  • Réception des données d’autorisation, et éventuellement des données d’installation, en réponse à la requête d’autorisation.
La requête est par exemple envoyée, suite à une sélection du logiciel (parmi d’autres logiciels présents dans le serveur) par une interface homme machine de l’égo véhicule.
De son côté, le serveur reçoit la requête d’autorisation d’installation du logiciel et répond en renvoyant à l’égo véhicule les données d’autorisation.
Dans ce mode de réalisation, les données d’installation peuvent être présent dans la mémoire de l’égo véhicule préalablement à la réception des données d’autorisation.
L’invention concerne aussi un véhicule automobile comprenant le dispositif électronique selon l’invention.
L’invention concerne également un serveur configuré pour mettre en œuvre les étapes du procédé mis en œuvre dans un serveur selon l’invention.
Enfin, l’invention concerne aussi un système comprenant :
  • Le dispositif électronique (ou le véhicule) selon l’invention,
  • Le serveur selon l’invention.
L’invention concerne également un programme d’ordinateur comprenant des instructions, exécutables par un microprocesseur ou un microcontroller, pour la mise en œuvre d’un des procédés selon l’invention.
Les caractéristiques et avantages du dispositif électronique, du véhicule automobile, du système et du programme d’ordinateur sont identiques à ceux des procédés, c’est pourquoi, ils ne sont pas repris ici.
On entend qu’un élément tel que le dispositif électronique ou un autre élément est « configuré pour » réaliser une étape ou une opération, par le fait que l’élément comporte des moyens pour (autrement dit « est conformé pour » ou « est adapté pour ») réaliser l’étape ou l’opération. Il s’agit préférentiellement de moyens électroniques, par exemple d’un programme d’ordinateur, de données en mémoire et/ou de circuits électroniques spécialisés.
Lorsqu’une étape ou une opération est réalisée par un tel élément, cela implique généralement que l’élément comporte des moyens pour (autrement dit « est conformé pour » ou « est adapté pour » ou « est configuré pour ») réaliser l’étape ou l’opération. Il s’agit également par exemple de moyens électroniques, par exemple un programme d’ordinateur, des données en mémoire et/ou des circuits électroniques spécialisés.
D’autres caractéristiques et avantages de la présente invention apparaitront plus clairement à la lecture de la description détaillée qui suit comprenant des modes de réalisation de l’invention donnés à titre d’exemples nullement limitatifs et illustrés par les dessins annexés, dans lesquels.
représente un dispositif électronique d’un véhicule automobile, un véhicule automobile et un système selon un mode de réalisation de l’invention.
représente le procédé de l’invention, selon un exemple de réalisation, mis en œuvre par le dispositif électronique, le véhicule et le système de la .
Description détaillée d’un exemple de réalisation de l’invention
, le système 1000 comprend un serveur 400, un réseau de télécommunication 320 et un égo véhicule 100. Le système peut comporter en outre un réseau de télécommunication local sans fil 310, un deuxième véhicule 200, un premier ordinateur client 500 d’un fournisseur de logiciel et un deuxième ordinateur client 600 du fabricant du véhicule 100.
En référence aux figures 1 et 2, à l’étape S10, le serveur 400 reçoit les données d’installation 121 d’un logiciel 123 depuis le premier ordinateur client 500 identifié, auprès du serveur 400, à partir de premières données d’identification 510 et authentifié, auprès du serveur 400, à partir de premières données d’authentification 520 mémorisées par le premier ordinateur client 500. Les données d’installation 121 sont alors mémorisées dans la mémoire 420 du serveur 400.
Selon un mode de réalisation, la chaine de bloc 130 est mise à jour dans le serveur 400 et mémorisée dans la mémoire 420, lorsque des blocs comprenant un premier bloc 131 (par exemple les parties de la chaine de bloc 130 mis à jour, ou uniquement les parties de la chaine de bloc 130 mises à jour jusqu’au premier bloc 131) sont reçus du premier ordinateur client 500, par exemple en même temps que les données d’installation 121.
A l’étape S20, le serveur 400 reçoit des données d’autorisation 122 depuis un deuxième ordinateur client 600 identifié auprès du serveur 400 à partir de deuxièmes données d’identification 610 et authentifié auprès du serveur 400 à partir de deuxièmes données d’authentification 620 mémorisées par le deuxième ordinateur client 600.
Ainsi, le serveur 400 mémorise dans sa mémoire 420, la chaine de blocs 130, les données d’installation 121 et les données d’autorisation 122.
Les premières données d’identification 510 sont différentes des deuxièmes données d’identification 610. Les premières données d’authentification 520 sont différentes des deuxièmes données d’authentification 620.
Avant la transmission des données d’autorisation 122 par le deuxième ordinateur client 600, le logiciel 123 peut être validé, à partir des données d’installation obtenues du serveur 400, par exemple par un acteur (l’acteur est par exemple : une entreprise, un utilisateur, un groupe d’utilisateur, un utilisateur, par exemple un développeur informatique du fabricant du véhicule automobile ) détenteurs du compte (ou utilisant le compte) identifié par les deuxièmes données d’identification 610 et authentifié par les deuxièmes données d’authentification 620.
Ces étapes peuvent être réalisés pour une pluralité (un nombre supérieur à 2, voire supérieur à 5) de premiers ordinateurs clients et de deuxièmes ordinateurs clients ayant des données d’identification et des données d’authentification différentes les uns des autres.
Par exemple, les données d’autorisation 122 comprennent par exemple un premier identifiant du logiciel, et le premier bloc 131 comprend un deuxième identifiant du logiciel.
Le premier bloc 131 dans la chaine de bloc 130 comprend par exemple une empreinte (autrement dit : un condensat) cryptographique des données d’installation 121. Par exemple, l’empreinte cryptographique est obtenue à partir d’une fonction de hachage.
Le deuxième ordinateur client 600 peut avoir signé, préalablement à l’étape S20, le premier identifiant, à partir d’une clef privée. Ainsi, les données d’autorisation 122 produites et envoyées au serveur 400 par le deuxième ordinateur client 600 peuvent comprendre la signature ainsi obtenue.
A l’étape S30, le dispositif électronique 110 de l’égo véhicule envoi une requête d’autorisation d’installation du logiciel 123 au serveur 400.
A l’étape S40, le dispositif électronique 110 de l’égo véhicule 100 reçoit les données d’autorisation 122, et éventuellement les données d’installation 121, en réponse à la requête d’autorisation, et mémorise ces données en mémoire 120.
La requête est par exemple envoyée, suite à une sélection du logiciel 123 (parmi d’autres logiciels présents dans le serveur 400), par l’interface homme machine 150 (le serveur 400 peut comprendre pour cela en mémoire 420 une liste de logiciels mise à jour au moment de la réception des données d’installation par le serveur 400).
De son côté, le serveur 400 reçoit la requête d’autorisation d’installation du logiciel 123 et répond en renvoyant au dispositif électronique 110 de l’égo véhicule 100 les données d’autorisation 122 et éventuellement des données d’installation 121.
A l’étape S50, dans le dispositif électronique 110 de l’égo véhicule 100, la chaine de bloc 130 peut être mis à jour par des connexions périodiques ou en réponse à la requête d’autorisation ci-dessus. Le serveur 400 envoi alors la chaine de bloc 130 à l’égo véhicule 100 qui la reçoit et la mémorise dans sa mémoire 120. En variante, la chaine de bloc 130 et les données d’installation 121 peuvent être mis à jour dans la mémoire 120 lorsqu’un deuxième véhicule 200 comprenant une chaine de bloc à jour est proche de l’égo véhicule 100. La chaine de bloc 130 et/ou les données d’installation 121 peuvent alors être communiquées par le deuxième véhicule 200 à l’égo véhicule 100 et mémorisée dans la mémoire 120 de l’égo véhicule 100. Ainsi, la chaine de blocs et/ou les données d’installation 121 peuvent être présentes dans la mémoire 120 de l’égo véhicule préalablement à la réception des données d’autorisation 122.
Ou inversement, les données d’installation 121 et/ou le premier bloc 131 sont reçues par l’égo véhicule 100 alors que les données d’autorisation 122 sont déjà dans la mémoire 120 de l’égo véhicule 100.
A l’étape S60, le dispositif électronique 110 vérifie l’autorisation de l’installation à partir des données d’autorisation 122 et du premier bloc 131.
L’installation est par exemple autorisée à condition que le premier identifiant et le deuxième identifiant soient égaux.
Par exemple, l’installation est autorisée à condition que la signature soit en outre conforme. Par exemple, la mémoire 120 de l’égo véhicule mémorise une clef publique pour vérifier la signature. Ainsi, la signature est encryptée avec la clef privée, la clef privée formant avec la clef publique une paire de clefs asymétrique.
A l’étape S70, le dispositif électronique 110 installe le logiciel 123 en mémoire 120 à partir des données d’installation 121 à condition que l’installation soit autorisée et que l’empreinte corresponde aux données d’installation 121 (par exemple, une autre empreinte est calculée par le dispositif électronique à partir des données d’installation 121 et est comparée à l’empreinte reçu dans le premier bloc).
Une fois le logiciel 123 installé en mémoire 120, il peut être exécuté par un processeur de l’égo véhicule 100, par exemple à l’étape S80.
De manière générale, l’envoi et la réception selon l’invention peuvent être mis en œuvre par un réseau de télécommunication cellulaire mobile 320, à l’exception, par exemple, de la communication entre l’égo véhicule 100 et le deuxième véhicule 200 qui peut être mis en œuvre par un réseau local sans fil 310.

Claims (10)

  1. Procédé d’autorisation d’installation d’un logiciel (123) dans un ego véhicule automobile (100) comprenant une mémoire (120) mémorisant une chaine de blocs (130) et des données d’autorisation (122) de l’installation, le procédé étant caractérisé en ce qu’il comprend les étapes suivantes :
    • Réception de données d’installation (121) du logiciel (123), un premier bloc (131) dans la chaine de bloc (130) comprenant une empreinte cryptographique des données d’installation (121),
    • Vérification d’une autorisation de l’installation (S60) à partir des données d’autorisation (122) et du premier bloc (131),
    • Une étape d’installation (S70) du logiciel (123) en mémoire (120) à partir des données d’installation (121) à condition que l’installation soit autorisée et que l’empreinte corresponde aux données d’installation (121).
  2. Procédé d’autorisation d’installation d’un logiciel (123), mis en œuvre dans un serveur (400) mémorisant une chaine de blocs (130), le procédé étant caractérisé en ce qu’il comporte les étapes suivantes :
    • Envoi de données d’installation (121) du logiciel (123), un premier bloc (131) dans la chaine de bloc (130) comprenant une empreinte cryptographique des données d’installation (121),
    • Envoi de données d’autorisation (122) d’installation du logiciel (123), pour la mise en œuvre d’une étape de vérification d’autorisation de l’installation à partir des données d’autorisation (122) et du premier bloc (131).
  3. Procédé d’autorisation d’installation selon la revendication précédente, le procédé comprenant en outre les étapes suivantes :
    • Réception des données d’installation (121) depuis un premier ordinateur client (500) identifié à partir de premières données d’identification (510) et authentifié à partir de premières données d’authentification (520) mémorisées par le premier ordinateur (500),
    • Réception des données d’autorisation (122) depuis un deuxième ordinateur client (600) identifié à partir de deuxièmes données d’identification (610) et authentifié à partir de deuxièmes données d’authentification (620) mémorisées par le deuxième ordinateur (600),
    • Les premières données d’identification (510) étant différentes des deuxièmes données d’identification (610),
    • Les premières données d’authentification (520) étant différentes des deuxièmes données d’authentification (620),
    • Le premier ordinateur client (500) étant différent du deuxième ordinateur client (600).
  4. Procédé d’autorisation d’installation selon l’une quelconques des revendications précédentes dans lequel :
    • Les données d’autorisation (122) comprennent un premier identifiant du logiciel (123), et
    • Le premier bloc (131) comprend un deuxième identifiant du logiciel (123).
  5. Procédé d’autorisation d’installation l’une quelconque des revendications précédentes dans lequel les données d’autorisation (122) comprennent une signature.
  6. Procédé d’autorisation d’installation selon l’une quelconque des revendications précédentes prise en dépendance de la revendication 1, le procédé comprenant en outre l’étape suivante :
    • Envoi (S30) d’une requête d’autorisation d’installation du logiciel (123),
    • Réception (S40) des données d’autorisation (122), en réponse à la requête d’autorisation,
  7. Dispositif électronique (110) configuré pour mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 et 4 à 6.
  8. Véhicule automobile (100) comprenant le dispositif électronique (110) selon la revendication précédente.
  9. Serveur (400) configuré pour mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 2 ou 3, ou selon les revendications 4 ou 5 prises en dépendance de la revendication 2 ou 3.
  10. Système (1000) comprenant :
    • Le dispositif électronique (110) selon la revendication 7 ; et
    • Le serveur (400) selon la revendication 9.
FR2204569A 2022-05-13 2022-05-13 Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés Pending FR3135546A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2204569A FR3135546A1 (fr) 2022-05-13 2022-05-13 Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2204569 2022-05-13
FR2204569A FR3135546A1 (fr) 2022-05-13 2022-05-13 Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés

Publications (1)

Publication Number Publication Date
FR3135546A1 true FR3135546A1 (fr) 2023-11-17

Family

ID=84331041

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2204569A Pending FR3135546A1 (fr) 2022-05-13 2022-05-13 Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés

Country Status (1)

Country Link
FR (1) FR3135546A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200073651A1 (en) * 2018-09-05 2020-03-05 International Business Machines Corporation Multi-variable based secure download of vehicle updates
CN113037850A (zh) * 2021-03-18 2021-06-25 中国第一汽车股份有限公司 一种应用程序升级方法、装置、电子设备及存储介质
GB2599195A (en) * 2020-06-05 2022-03-30 Inlecom Systems Ltd Computer program trust assurance for Internet of Things (IoT) devices

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200073651A1 (en) * 2018-09-05 2020-03-05 International Business Machines Corporation Multi-variable based secure download of vehicle updates
GB2599195A (en) * 2020-06-05 2022-03-30 Inlecom Systems Ltd Computer program trust assurance for Internet of Things (IoT) devices
CN113037850A (zh) * 2021-03-18 2021-06-25 中国第一汽车股份有限公司 一种应用程序升级方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
CN111131313B (zh) 智能网联汽车更换ecu的安全保障方法及系统
EP1570648B1 (fr) Méthode de sécurisation des mises à jour de logiciels
US7886355B2 (en) Subsidy lock enabled handset device with asymmetric verification unlocking control and method thereof
EP3348085A1 (fr) Procédé de chargement d'une clé virtuelle au sein d'un terminal utilisateur et terminal utilisateur associé
US20040003243A1 (en) Method and system for authorizing reconfiguration of a vehicle
US20040003231A1 (en) Method and system for component authentication of a vehicle
EP2903867B1 (fr) Systeme de protection d'un vehicule automobile
CN115396121B (zh) 安全芯片ota数据包的安全认证方法及安全芯片装置
CN101404576A (zh) 一种网络资源查询方法和系统
WO2005101726A1 (fr) Procede d'authentification anonyme
CN106656992B (zh) 一种信息验证方法
CN115242634B (zh) 软件升级方法、设备和存储介质
WO2004004204A1 (fr) Procede et systeme d'authentification d'un composant par un vehicule
EP1886204A1 (fr) Procede de transaction et procede de verification
CN113612852A (zh) 一种基于车载终端的通信方法、装置、设备及存储介质
FR3067136A1 (fr) Procede de mise a jour d’un calculateur embarque de vehicule
CN115643564A (zh) 汽车安全的fota升级方法、装置、设备及存储介质
EP1263248B1 (fr) Procédé d'activation d'une fonction dans un terminal abonné à un réseau
FR3135546A1 (fr) Procédé d’autorisation d’installation d’un logiciel dans un véhicule automobile, dispositif, véhicule et système associés
US20040073799A1 (en) Method for loading a software program onto a mobile communication terminal
CN103559429B (zh) 软件处理的方法及系统
KR20090051475A (ko) 펌웨어 업그레이드를 위해 펌웨어를 복호화하는 장치 및방법
CN111464554A (zh) 一种车辆信息安全控制方法及系统
CN112583605B (zh) 一种基于区块链的免密认证方法、系统、终端及存储介质
US8666900B1 (en) Secure product enablement over channels with narrow bandwidth

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20231117

PLFP Fee payment

Year of fee payment: 3