WO2023276532A1 - 車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法 - Google Patents

車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法 Download PDF

Info

Publication number
WO2023276532A1
WO2023276532A1 PCT/JP2022/022159 JP2022022159W WO2023276532A1 WO 2023276532 A1 WO2023276532 A1 WO 2023276532A1 JP 2022022159 W JP2022022159 W JP 2022022159W WO 2023276532 A1 WO2023276532 A1 WO 2023276532A1
Authority
WO
WIPO (PCT)
Prior art keywords
update data
hash value
electronic control
master device
data
Prior art date
Application number
PCT/JP2022/022159
Other languages
English (en)
French (fr)
Inventor
古都 東松
英朗 吉見
真晃 安部
Original Assignee
株式会社デンソー
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 株式会社デンソー filed Critical 株式会社デンソー
Priority to CN202280045176.1A priority Critical patent/CN117561500A/zh
Priority to DE112022003289.8T priority patent/DE112022003289T5/de
Publication of WO2023276532A1 publication Critical patent/WO2023276532A1/ja
Priority to US18/537,350 priority patent/US20240111519A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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
    • H04L9/3239—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 involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the present disclosure includes a center device that transmits a distribution package including update data to be written in an electronic control device mounted on a vehicle in a streaming method, and a master device that receives the distribution package and transfers update data to the electronic control device.
  • the present invention relates to an in-vehicle communication system, a center device and a vehicle-side system used in the system, and an update data verification method for in-vehicle communication.
  • Patent Document 1 discloses a technique for distributing a data package containing an ECU update program from a server to an in-vehicle device by OTA (Over The Air) and rewriting the update program on the vehicle side.
  • OTA Over The Air
  • the storage method in which the entire update program is downloaded from the center device to the vehicle's memory, and then updated
  • the update program which is downloaded from the center device to the vehicle while the update is performed.
  • the OTA master which generally has a unit called DCM (Data Communication Module) or CGW (Central Gate Way), receives the distribution package containing the update program from the center device and selects the target ECU to be updated. Transfer and write updates to.
  • DCM Data Communication Module
  • CGW Central Gate Way
  • a digital signature is attached to the distribution package, and the OTA master uses the digital signature to check the integrity of the distribution package before writing it to the target ECU.
  • the OTA master sequentially writes the received update program to the target ECU without checking the integrity as described above. Therefore, if the data of the program included in the distribution package is replaced in the data transfer path from the center device to the target ECU, there is a risk that the incorrect data will be written to the target ECU as it is.
  • the present disclosure has been made in view of the above circumstances, and its object is to provide an in-vehicle communication system, a center device, a vehicle-side system, and an in-vehicle communication system capable of verifying the integrity of update data transmitted by a streaming method from the center device.
  • the center device also transmits a hash value calculated for the update data to the master device when transmitting the update data as a distribution package to the master device on the vehicle side in a streaming method.
  • the master device receives the distribution package, it transfers the update data to the electronic control device.
  • the electronic control device calculates a hash value for the update data, it transmits the hash value to the master device, and the master device combines the hash value transmitted from the center device and the hash value transmitted from the electronic control device. Compare to verify the integrity of the update data.
  • the center device when writing update data to each of the plurality of electronic control devices, the center device also transmits a plurality of hash values calculated for each update data to the master device.
  • the master device transfers each update data to each electronic control device, and each electronic control device calculates a hash value for each update data and transmits the hash value to the master device.
  • the master device compares hash values sent from the plurality of electronic control devices with corresponding hash values sent from the center device. Therefore, even in the case of transmitting update data to each of a plurality of electronic control units, it is possible to prevent incomplete update data from being installed in each electronic control unit.
  • the center device when the center device transmits the distribution package to the master device on the vehicle side in a streaming manner, the hash value calculated for the update data is also sent to the master device. Send.
  • the master device obtains a hash value of the entire update data by calculating a hash value of the update data for each predetermined data size, the master device compares the hash value with the hash value transmitted from the center device, Validate the integrity of the update data.
  • the master device calculates the hash value of the update data and verifies the integrity. can get.
  • FIG. 1 is a functional block diagram schematically showing the configuration of an in-vehicle communication system in the first embodiment
  • FIG. 2 is a diagram showing an example of repro policy metadata
  • FIG. 3 is a diagram showing an example of download metadata
  • FIG. 4 is a diagram conceptually showing a manner in which the distribution package is transmitted from the OTA center to the in-vehicle system by streaming.
  • FIG. 5 is a flowchart showing package generation processing performed by the OTA center.
  • FIG. 6 is a flowchart showing the same signature generation process
  • FIG. 7 is a flowchart showing the same signature transmission process
  • FIG. 8 is a flowchart showing package and signature reception processing performed by the OTA master
  • FIG. 9 is a flowchart showing processing on the target ECU side
  • FIG. 10 is a diagram equivalent to FIG. 4 when there is a single target ECU
  • FIG. 11 is a diagram conceptually showing a mode of transmitting a distribution package using a hash chain in the second embodiment
  • FIG. 12 is a flowchart showing signature generation processing performed by the OTA center.
  • FIG. 13 is a flowchart showing the processing on the OTA master side
  • FIG. 14 is a diagram conceptually showing how the OTA master calculates a hash value when transmitting a distribution package in the third embodiment.
  • FIG. 15 is a flowchart showing processing on the OTA master side
  • FIG. 15 is a flowchart showing processing on the OTA master side
  • FIG. 16 is a flowchart showing processing on the target ECU side
  • FIG. 17 is a diagram conceptually showing a manner in which a distribution package is transmitted with mixed storage methods in the fourth embodiment.
  • FIG. 18 is a flowchart showing processing on the OTA master side
  • FIG. 19 is a diagram conceptually showing a manner in which a distribution package is transmitted via a smartphone in the fifth embodiment;
  • FIG. 20 is a flowchart showing processing on the OTA center side
  • FIG. 21 is a flowchart showing processing on the smartphone side
  • FIG. 22 is a flowchart showing processing on the OTA master side.
  • an in-vehicle communication system 1 of this embodiment includes an OTA center 2 corresponding to a center device and a vehicle side system 3 .
  • the OTA center 2 has a PKG generation server 4, a distribution server 5, and a DB section 100.
  • the DB section 100 includes a software package DB 101, a digital signature DB 102, a configuration information DB 103, an individual vehicle information DB 104, an ECU repro data DB 105, and an ECU metadata DB 105. It has a data DB 106 .
  • “database” may be written as DB
  • "package" may be written as PKG.
  • the PKG generation server 4 includes a software package generation unit 9, a hash value collection unit 10, a hash value calculation unit 11, and a digital signature generation unit 12.
  • the software package generation unit 9 is a functional unit that generates a software package to be distributed to a vehicle in which the target ECU to be updated is installed. , FIG. 16, FIG. 19 and the like.
  • Japanese Patent Application Laid-Open No. 2020-27624 will be referred to as “reference publication”.
  • the software package includes program update data, rewriting specification data, and the like.
  • Software packages containing hash values are stored in the software package DB 101 .
  • the hash value collection unit 10 is a functional unit that collects update data for which a hash value is to be calculated from the software package.
  • the hash value calculation unit 11 applies a hash function to the collected data to obtain a hash value.
  • the digital signature generation unit 12 is a functional unit that attaches a generated digital signature to hash value concatenated information linking the calculated hash value and the target ID, which is the ID of the corresponding target ECU.
  • Digital signatures are stored in the digital signature DB 102 .
  • the distribution server 5 includes a distribution management unit 13, a vehicle information management unit 14, a software management unit 15, a campaign management unit 16, a configuration information management unit 17, and an individual vehicle state management unit 18.
  • the distribution management unit 13 is a functional unit that manages distribution of software packages and campaign information to each vehicle.
  • the vehicle information management unit 14 registers and manages the individual vehicle information uploaded from each vehicle in the individual vehicle information DB 104 .
  • An update program for the target ECU is registered in the software management unit 15 by an OEM (Original Equipment Manufacturer) or the like.
  • the OEM or the like registers campaign information, which is information relating to program updates mainly displayed on the vehicle-side system 3.
  • the configuration information management unit 17 manages configuration information for each vehicle model registered in the configuration information DB 103 .
  • the configuration information is identification information about the hardware and software of the ECUs installed in the vehicle, and includes identification information of the system configuration including a plurality of ECUs and identification information of the vehicle configuration including a plurality of systems.
  • the individual vehicle state management unit 18 manages information such as the program update state and version of the target ECU in each vehicle.
  • the PKG generation server 4 and distribution server 5 are functions implemented by computer hardware and software.
  • the configuration information DB 103, the individual vehicle information DB 104, the ECU repro data DB 105, and the ECU meta data DB 106 of the DB unit 100 correspond to the "configuration information DB 208, individual car information DB 213, ECU repro data DB 204, and ECU meta data DB 205" in the reference publication. ing.
  • the vehicle-side system 3 includes an OTA master 21 corresponding to a master device, and update target ECUs 22(1), 22(2), 22(3), . there is The ECU 22 to be updated is hereinafter referred to as the target ECU 22 .
  • the OTA master 21 is a functional unit combining the DCM 12 and CGW 13 shown in FIG.
  • the download processing unit 23 wirelessly communicates with the OTA center 2 to download distribution package data and digital signature data.
  • the unpack processing unit 24 performs unpack processing for separating the downloaded distribution package into data sections to be processed.
  • the hash value calculation unit 25 calculates hash values for data values to be calculated for hash values, and this functional unit is used in the second embodiment.
  • the hash value comparison unit 26 compares the hash value calculated on the target ECU 22 side as described later with the hash value included in the downloaded distribution package.
  • the target ECU 22 includes a microcomputer 27, a memory 28 and a hash value calculator 29.
  • the memory 28 is, for example, a flash memory, and the update data downloaded by the OTA master 21 is transferred and installed.
  • a hash value calculator 29 calculates a hash value for the update data transferred from the OTA master 21 .
  • ⁇ Repro policy metadata The repro policy metadata shown in FIG. 2 is transmitted from the OTA center 2 to the OTA master 21 prior to data download.
  • ⁇ Repro policy metadata version> This is the version of repro policy metadata, and version information such as "1.0.0” and "2.0.0" is stored.
  • Uptane registered trademark
  • OMA-DM Open Mobile Alliance-Device Management
  • JASPAR's specifications stipulate the data requirements applicable to the classic platform (CP) that runs on the static OS of the standardization organization AUTOSAR.
  • AUTOSAR also specifies data requirements applicable to a new type of adaptive platform (AP) running on a dynamic OS.
  • AGL is in-vehicle Linux (registered trademark)
  • Android is Android Automotive OS.
  • control method information such as "parameters” that are processed according to parameters set according to a specific format and "scripts” that are processed in a more free description format without a specific format are stored.
  • ⁇ Target layer> It is information corresponding to the target ECU 22 .
  • the PF, transfer method, and control method are the same as those described above.
  • the target ID is an ID corresponding to the target ECU 22, but storing it here is optional.
  • the download metadata shown in FIG. 3 is transmitted from the OTA center 2 to the OTA master 21 following the repro policy metadata.
  • ⁇ Distribution layer> For example, if the communication protocol is Uptane, it is information for acquiring Uptane metadata, and stores corresponding URI, data name, data size, hash value, target ID, transfer method, and the like.
  • ⁇ Master layer> For example, it is information for acquiring a vehicle PKG, and each item is the same as the distribution layer. This information can be multiple.
  • ⁇ Target layer> it is information for acquiring Software PKG, and each item is the same as the distribution layer. This information may also be plural. Vehicle PKG and Software PKG are described, for example, in "Specification of Update Configuration Management AUTOSAR AP R20-11, Document ID No.706", p.
  • AP and CP stand for software platform.
  • a software platform is also called a software architecture.
  • CP stands for AUTOSAR Classic Platform
  • AP stands for AUTOSAR Adaptive Platform.
  • an ECU that operates in compliance with the CP specifications is sometimes referred to as a CP ECU or CP ECU
  • an ECU that operates in compliance with the AP specifications is referred to as an AP ECU or an AP ECU.
  • the operating systems used in AP and CP are different.
  • the structure of the package that can be received differs between the CP ECU and the AP ECU.
  • the difference in the structure of these packages is mainly due to the difference in the processing performance of the ECU.
  • the processing performance of the CP ECU is low, so the specification data included in the package is also described in binary data. It has a package data structure that is easy to interpret and process even for ECUs with low processing performance.
  • AP ECUs have high processing performance, it is possible to install a parser function that analyzes structural character data written in some language and converts it into a data structure that can be handled by a program.
  • the data structure is not simple binary data, but an object-oriented data format such as JSON (JavaScript Object Notation) can be adopted, resulting in a flexible package data structure.
  • JSON JavaScript Object Notation
  • FIG. 4 conceptually shows the action of this embodiment.
  • the distribution server 4 of the OTA center 2 uses the hash value calculator 11 to convert each of the update data A to C into SHA (Secure Hush Algorithm)-2 is applied to calculate hash values a to c (FIG. 5, S0).
  • the hash value d is similarly calculated for the aforementioned download metadata D, but the flow charts shown in FIGS.
  • the digital signature generation unit 12 generates and attaches a digital signature to the hash value concatenated information, that is, encrypts it with a private key (S3), and transmits and stores the digital signature to the digital signature DB 102 ( S4, S5). Thereafter, when there is a transmission request for hash value concatenated information from the OTA master 21 (FIG. 7, S6; YES), the distribution server 5 sequentially transmits the hash value concatenated information and the distribution package to the OTA master 21 (S7, S7a).
  • the download processing unit 23 of the OTA master 21 receives the distribution package transmitted by the streaming method from the distribution server 5, the update data A to C are downloaded to the respective target ECUs 22(1) to 22(3). ) (S11). Subsequently, the download processing unit 23 receives the digital signature (S12).
  • a communication protocol using encryption such as Uptane or SSL (Secure Sockets Layer) is used.
  • the target ECU 22 downloads the update data received from the OTA master 21 (S21), it applies a hash function to the update data to calculate a hash value (S22). Then, the calculated hash value is transmitted to the OTA master 21 (S23).
  • the OTA master 21 verifies the received digital signature, that is, decrypts it with the public key, and acquires hash value concatenated information (S13). Then, each of the target ECUs 22(1) to 22(3) is requested to transfer the hash value (S14). No processing is required.
  • the hash value comparison unit 26 compares the hash values a to c obtained from the hash value concatenated information and the hash value a obtained from the target ECU 22. ' to c' are compared (S16). If both match (S17; YES), an installation instruction is issued to each of the target ECUs 22(1) to 22(3) (S18). On the other hand, if there is even one mismatch (S17; NO), a rollback instruction is issued to the target ECU 22 having the mismatch (S19). This process is optional.
  • the target ECU 22 When the target ECU 22 receives an installation request from the OTA master 21 (S24; YES), it installs the downloaded update data (S25). If there is no installation request (S24; NO) and there is a cancellation request from the OTA master 21 (S26; YES), the process is terminated.
  • FIG. 10 shows a case where there is a single target ECU 22.
  • FIG. The process is basically the same as the process shown in FIG. 4 except that the hash value for the metadata E is e.
  • the OTA center 2 when the OTA center 2 transmits the distribution package to the OTA master 21 on the vehicle side by streaming, the hash value calculated for the update data is also sent to the OTA master. 21.
  • the OTA master 21 transfers the update data to the target ECU 22 .
  • the target ECU 22 After calculating the hash value of the update data, the target ECU 22 transmits the hash value to the OTA master 21, and the OTA master 21 combines the hash value transmitted from the OTA center 2 with the hash value transmitted from the target ECU 22. Compare to verify the integrity of the update data.
  • the hash values a to c calculated for each of the update data A to C are also included.
  • the OTA master 21 transfers each of the update data A to C to each of the target ECUs 22(1) to 22(3), and each of the target ECUs 22(1) to 22(3) hashes each of the update data A to C.
  • the hash values a′ to c′ are sent to the OTA master 21 .
  • the OTA master 21 compares the multiple hash values a'-c' with the hash values a-c. Therefore, even in the case of transmitting update data A to C to a plurality of target ECUs 22(1) to 22(3), installation of incomplete update data can be similarly prevented.
  • the PKG generation server 4 generates hash values a to c obtained corresponding to update data A to C and hash value d obtained corresponding to metadata. Apply a hash function to The obtained hash value f is called a "hash chain" (Fig. 12, S8). The hash chain f corresponds to the upper hash value. Then, when a digital signature is given to the hash chain f (S9), steps S4 and S5 are executed.
  • the OTA master 21 When the OTA master 21 receives the distribution package from the distribution server 5 of the OTA center 2 (FIG. 13, S31), it transfers each update data A to C to each target ECU 22(1) to 22(3) (S32). Note that the processing performed by the target ECU 22 is the same as in FIG.
  • the download processing unit 23 receives the digital signature attached to the hash chain f (S33), it verifies the received digital signature (S34). A successful verification yields the hash chain f.
  • the OTA master 21 receives the hash values a'-c' calculated by the respective target ECUs 22(1)-22(3) (S35).
  • the hash value calculator 11 calculates a hash chain f' for the received hash values a' to c' (and d') (S36).
  • the hash value comparison unit 26 compares the hash chain f obtained from the OTA center 2 and the hash chain f' calculated by the hash value calculation unit 11 (S37). If both match (S38; YES), an installation instruction is issued to each of the target ECUs 22(1) to 22(3) (S18). On the other hand, if they do not match (S38; NO), the process is terminated or a rollback instruction is issued to the target ECU 22 (S40).
  • the OTA center 2 also transmits to the OTA master 21 the hash chain f, which is a hash value calculated for a plurality of hash values a to c.
  • the OTA master 21 calculates the hash chain f' for the hash values a'-c' received from the ECUs 22(1)-22(3), the OTA master 21 compares the hash chain f' with the hash chain f. As a result, even if any of the hash values a to c is incomplete data, it can be detected by verification, so that the security of the communication system can be further improved.
  • the OTA master 21 when a distribution package is received from the OTA center 2 by streaming, the OTA master 21 sequentially calculates hash values for update data. SHA-2 described above is used as the hash function. A case using the SHA-2 function will be described below as an example.
  • the processing on the OTA center 2 side is the same as in FIG.
  • the OTA master 21 grasps the size of the data to be received from the download metadata received from the OTA center 2 (Fig. 15, S41)
  • the OTA master 21 calculates how many times the data size is 512 bits (S42). ), the delivery package is received from the OTA center 2 by streaming (S43).
  • the OTA master 21 divides the received data into 512-bit units (S44). If the divided data is called a "message", for example, it is assumed that the data is divided into N messages. Then, the hash value calculator 25 applies the SHA-2 function to the message (S45), and holds the output result as the initial buffer value for the next SHA-2 function (S46). For example, with SHA-256, the hash length of a hash value obtained by applying it to 512-bit data is 256 bits. Then, the processing of steps S45 and S46 is repeated until the SHA-2 function is applied to (N-1) messages (S47; NO).
  • step S48 For the Nth message (S47; YES), it is determined whether or not the data size is an integer multiple of 512 bits (S48). -2 function is applied, and the output result is used as a hash value (S49). Then, the OTA master 21 verifies the digital signature received from the distribution server 4 and obtains a hash value (S50). In step S48, if the data size of the message is an integer multiple of 512 bits (YES), the final hash value has been obtained, so the process proceeds to step S50.
  • the hash value comparison unit 26 compares the hash value obtained in step S50 with the hash value calculated by the hash value calculation unit 25 (S51). to issue an installation instruction (S53). On the other hand, if they do not match (S52; NO), the process is terminated or a rollback instruction is issued to the target ECU 22 (S54).
  • the processing shown in FIG. 15 corresponds to one target ECU 22, and when there are a plurality of target ECUs 22, the processing shown in FIG. 15 is repeatedly executed. Further, the processing of the target ECU 22 shown in FIG. 16 executes only steps S21, S24, and S25 in FIG. 9, and the processing ends when "NO" is determined in step S24.
  • the OTA master 21 when the OTA master 21 obtains the hash value of the entire update data by calculating the hash value for each predetermined data size of the update data, the hash value and the OTA The hash value transmitted from the center 2 is compared to verify the integrity of the update data. With this configuration, integrity verification can be performed as processing within the OTA master 21 .
  • the fourth embodiment shows processing when the streaming method and the storage method are mixed.
  • the processing of the OTA center 2 is the same as in the first embodiment.
  • the OTA master 21 receives the storage-type package A and the streaming-type package B from the distribution server 5 (S61).
  • Package A is in zip format and contains verification data for Package A.
  • the OTA master 21 verifies the package A using the verification data, and transmits the update data K and L included in the package B to the target ECUs 22(4) and 22(5) (S62).
  • downloading of packages A and B is started.
  • the package is A (S63; YES) and the verification is completed normally (S70; YES)
  • the update data G to I included in the package A are written to the target ECUs 22(1) to 22(3) (S71). .
  • the installation of package A is started.
  • the verification does not end normally (S70; NO)
  • the process for package A ends.
  • a rollback instruction is issued to the target ECU 22 that has started the installation process of package B (S72).
  • the OTA master 21 receives the hash values k' and l' calculated by the target ECUs 22(4) and 22(5) for the update data K and L (S64). Note that the processing of these target ECUs 22 is the same as in FIG. Subsequently, when the digital signature is received from the distribution server 5, it is verified (S65).
  • the OTA master 21 may determine the package type and execute processing according to the result. Upon receiving package A and package B, the OTA master 21 determines the package type. As a result, when the OTA master 21 determines that the package is the storage-type package A, the OTA master 21 proceeds to S70 and executes the processes from S70 to S72. Further, when the OTA master 21 determines that the package is the streaming package B, the OTA master 21 proceeds to S64 and executes the processing from S64 to S69. The determination of the package type by the OTA master 21 is repeated by the number of received packages.
  • the update data and the hash value calculated for the data are to the OTA master 21 .
  • the OTA master 21 calculates a hash value for the update data and compares it with the corresponding hash value sent from the OTA center 2 to verify the integrity of the update data. Once the integrity is verified, the update data is transferred to the target ECUs 22(1)-22(3) corresponding to the storage scheme. As a result, security can be improved even when target ECUs 22 compatible with the storage method are mixed.
  • the fifth embodiment shows a case where the distribution package is once downloaded from the OTA center 2 to the smart phone 31 and transferred from the smart phone 31 to the OTA master 21 .
  • “smartphone” may be abbreviated as “smartphone” and car navigation device may be abbreviated as “navi”.
  • the OTA center 2 executes steps S1 to S4
  • the user communicates with the OTA center 2 using a car navigation device or a smart phone 31 (not shown), and distributes the package. It is determined whether or not the smartphone 31 is selected as the destination (S73). If the smartphone 31 is selected (YES), the package is distributed to the smartphone 31 (S74), and if the smartphone 31 is not selected (NO), the package is distributed to the OTA master 21 as before (S7). .
  • a user who has a smart phone 31 receives a push notification from the OTA center 2 on the premise that wireless communication pairing has been performed between the smart phone 31 and equipment on the vehicle side. is received (S81). Then, where to download the distribution package is selected by the smartphone 31 (S82). Then, the selection result is notified to the distribution server 5 of the OTA center 2 (S83).
  • the package is downloaded (DL) to the specified path of the smartphone 31 (S85). Subsequently, when the smartphone 31 notifies the distribution server 5 that the download of the package has been completed (S86), the smartphone 31 transfers the package to the OTA master 21 (S87).
  • the OTA master 21 transmits vehicle configuration information to the OTA center 2 in order to synchronize the vehicle configuration information with the OTA center 2 (S91).
  • the OTA master 21 verifies the digital signature received from the OTA center 2 and acquires hash value concatenated information (S93).
  • the OTA master 21 receives the directory notified from the OTA center 2. , the distribution package is downloaded from the smart phone 31 (S95). On the other hand, if the smartphone 31 is not selected as the destination (S94; NO), the OTA master 21 downloads the distribution package from the OTA center 2 (S96). After that, steps S12 to S19 of the first embodiment are executed.
  • the OTA master 21 can selectively download from the smartphone 31 the distribution package downloaded from the OTA center 2 to the smartphone 31 . This allows the distribution package to be obtained in a more flexible manner.
  • repro policy metadata and download metadata may be changed as appropriate according to individual designs.
  • Hash functions are not limited to SHA-2.
  • each device can be provided by software recorded in a physical memory device and a computer that executes it, software only, hardware only, or a combination thereof.
  • the controller is provided by an electronic circuit that is hardware, it can be provided by a digital circuit containing a number of logic circuits, or an analog circuit.
  • the controller and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by the computer program.
  • the controls and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits.
  • the control units and techniques described in this disclosure can be implemented by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. It may also be implemented by one or more dedicated computers configured.
  • the computer program may also be stored as computer-executable instructions on a computer-readable non-transitional tangible recording medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

本開示の一態様は、車載通信システム１において、ＯＴＡセンタ２は、ストリーミング方式で更新データを車両側のＯＴＡマスタ２１に送信する際に、更新データについて計算したハッシュ値もＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、更新データを受信するとターゲットＥＣＵ２２に転送する。ターゲットＥＣＵ２２は、更新データについてハッシュ値を計算すると、そのハッシュ値をＯＴＡマスタ２１に送信し、ＯＴＡマスタ２１は、ＯＴＡセンタ２より送信されたハッシュ値とターゲットＥＣＵ２２より送信されたハッシュ値とを比較して更新データの完全性を検証する。

Description

車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法 関連出願の相互参照
　本出願は、２０２１年６月２９日に出願された日本出願番号２０２１－１０７８３４号に基づくもので、ここにその記載内容を援用する。
　本開示は、車両に搭載される電子制御装置に書き込ませる更新データを含む配信パッケージをストリーミング方式で送信するセンタ装置と、配信パッケージを受信して電子制御装置に更新データを転送するマスタ装置とを備える車載通信システム，そのシステムに使用されるセンタ装置及び車両側システム並びに車載通信の更新データ検証方法に関する。
　近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムを書換える，所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献１には、サーバよりＥＣＵの更新プログラムを含むデータパッケージをＯＴＡ（Over The Air）により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。
　上記の更新プログラムを書換える方式には、センタ装置から更新プログラムの全てを車両側のメモリにダウンロードしてから更新を行うストレージ方式と、センタ装置から更新プログラムを車両側にダウンロードしながら更新を行うストリーミング方式とがある。車両側では、一般にＤＣＭ（Data Communication Module）やＣＧＷ（Central Gate Way）等と称されるユニットを有するＯＴＡマスタが、センタ装置から更新プログラムを含む配信パッケージを受信して、更新対象となるターゲットＥＣＵに更新プログラムを転送して書き込む。
　ストレージ方式では、配信パッケージにデジタル署名が付与されており、ＯＴＡマスタは、そのデジタル署名を用いて配信パッケージの完全性を確認してから、ターゲットＥＣＵに書き込みを行っている。
特開２０２０－２７６２４号公報
　しかしながら、ストリーミング方式では、ＯＴＡマスタが上記のように完全性を確認することなく、受信した更新プログラムを逐次ターゲットＥＣＵに書き込んでいる。そのため、センタ装置からターゲットＥＣＵまでのデータ転送経路において、配信パッケージに含まれるプログラムのデータが差し替えられると、その不正なデータがそのままターゲットＥＣＵに書き込まれてしまうおそれがあった。
　本開示は上記事情に鑑みてなされたものであり、その目的は、センタ装置からストリーミング方式で送信される更新データについても、完全性を検証できる車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法を提供することにある。
　請求項１記載の車載通信システムによれば、センタ装置は、更新データを配信パッケージとしてストリーミング方式で車両側のマスタ装置に送信する際に、更新データについて計算したハッシュ値もマスタ装置に送信する。マスタ装置は、配信パッケージを受信すると更新データを電子制御装置に転送する。電子制御装置は、前記更新データについてハッシュ値を計算すると、そのハッシュ値をマスタ装置に送信し、マスタ装置は、センタ装置より送信されたハッシュ値と、電子制御装置より送信されたハッシュ値とを比較して更新データの完全性を検証する。
　このように構成すれば、センタ装置からストリーミング方式で車両側に送信される配信パッケージ含まれる更新データが、途中で改竄される等して不完全なデータに置き換わったとしても、マスタ装置においてハッシュ値を用いた検証が行われるので、不完全な更新データが電子制御装置にインストールされてしまうことを防止できる。したがって、通信システムのセキュリティを向上させることが可能になる。
　請求項２記載の車載通信システムによれば、センタ装置は、複数の電子制御装置にそれぞれ更新データを書き込ませる際には、各更新データについて計算した複数のハッシュ値もマスタ装置に送信する。マスタ装置は、各更新データを各電子制御装置にそれぞれ転送し、各電子制御装置は、それぞれの更新データについてハッシュ値を計算すると、そのハッシュ値をマスタ装置に送信する。マスタ装置は、複数の電子制御装置より送信されたハッシュ値を、センタ装置より送信された対応するハッシュ値と比較する。したがって、複数の電子制御装置にそれぞれ更新データを送信するケースについても同様に、不完全な更新データが各電子制御装置にインストールされてしまうことを防止できる。
　請求項７記載の車載通信システムによれば、センタ装置は請求項１と同様に、ストリーミング方式で配信パッケージを車両側のマスタ装置に送信する際に、更新データについて計算したハッシュ値もマスタ装置に送信する。マスタ装置は、更新データについて所定のデータサイズ毎にハッシュ値を計算することで、更新データ全体についてのハッシュ値を得ると、そのハッシュ値とセンタ装置より送信されたハッシュ値とを比較して、更新データの完全性を検証する。
　すなわち、請求項１の電子制御装置に替ってマスタ装置が、更新データについてのハッシュ値を計算し完全性を検証するので、マスタ装置で検証処理を完結させて請求項１と同様の効果が得られる。
　本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図１は、第１実施形態において、車載通信システムの構成を概略的に示す機能ブロック図であり、 図２は、リプロポリシーメタデータの一例を示す図であり、 図３は、ダウンロードメタデータの一例を示す図であり、 図４は、ＯＴＡセンタより車載システムに、ストリーミング方式で配信パッケージを伝送する態様をイメージ的に示す図であり、 図５は、ＯＴＡセンタが行うパッケージ生成処理を示すフローチャートであり、 図６は、同署名生成処理を示すフローチャートであり、 図７は、同署名伝送処理を示すフローチャートであり、 図８は、ＯＴＡマスタが行うパッケージ及び署名受信処理を示すフローチャートであり、 図９は、ターゲットＥＣＵ側の処理を示すフローチャートであり、 図１０は、ターゲットＥＣＵが単一である場合の図４相当図であり、 図１１は、第２実施形態において、ハッシュチェーンを用いて配信パッケージを伝送する態様をイメージ的に示す図であり、 図１２は、ＯＴＡセンタが行う署名生成処理を示すフローチャートであり、 図１３は、ＯＴＡマスタ側の処理を示すフローチャートであり、 図１４は、第３実施形態において、配信パッケージを伝送する際に、ＯＴＡマスタがハッシュ値を計算する態様をイメージ的に示す図であり、 図１５は、ＯＴＡマスタ側の処理を示すフローチャートであり、 図１６は、ターゲットＥＣＵ側の処理を示すフローチャートであり、 図１７は、第４実施形態において、ストレージ方式が混在して配信パッケージを伝送する態様をイメージ的に示す図であり、 図１８は、ＯＴＡマスタ側の処理を示すフローチャートであり、 図１９は、第５実施形態において、スマートホンを経由して配信パッケージを伝送する態様をイメージ的に示す図であり、 図２０は、ＯＴＡセンタ側の処理を示すフローチャートであり、 図２１は、スマートホン側の処理を示すフローチャートであり、 図２２は、ＯＴＡマスタ側の処理を示すフローチャートである。
　　（第１実施形態）
　図１に示すように、本実施形態の車載通信システム１は、センタ装置に相当するＯＴＡセンタ２と、車両側システム３とを備えている。ＯＴＡセンタ２は、ＰＫＧ生成サーバ４，配信サーバ５及びＤＢ部１００を有し、ＤＢ部１００は、ソフトウェアパッケージＤＢ１０１，デジタル署名ＤＢ１０２，構成情報ＤＢ１０３，個車情報ＤＢ１０４，ＥＣＵリプロデータＤＢ１０５及びＥＣＵメタデータＤＢ１０６を有している。尚、「データベース」をＤＢと表記し、「パッケージ」をＰＫＧと表記することがある。
　ＰＫＧ生成サーバ４は、ソフトパッケージ生成部９，ハッシュ値収集部１０，ハッシュ値計算部１１，デジタル署名生成部１２を備えている。ソフトパッケージ生成部９は、データの更新対象となるターゲットＥＣＵが搭載されている車両に配信するソフトウェアパッケージを生成する機能部であり、その詳細については、例えば特開２０２０－２７６２４号公報の図１５，図１６，図１９等に開示されている。以下、特開２０２０－２７６２４号公報を「参照公報」と称する。ソフトウェアパッケージには、プログラムの更新データや書換え諸元データ等が含まれる。ハッシュ値を含むソフトウェアパッケージは、ソフトウェアパッケージＤＢ１０１に記憶される。
　ハッシュ値収集部１０は、上記のソフトウェアパッケージからハッシュ値を計算する対象となる更新データを収集する機能部であり、ハッシュ値計算部１１は、収集されたデータにハッシュ関数を適用してハッシュ値を計算する機能部である。デジタル署名生成部１２は、計算されたハッシュ値と対応するターゲットＥＣＵのＩＤであるターゲットＩＤとを紐付けたハッシュ値連結情報に、生成したデジタル署名を付与する機能部である。デジタル署名は、デジタル署名ＤＢ１０２に記憶される。
　配信サーバ５は、配信管理部１３，車両情報管理部１４，ソフトウェア管理部１５，キャンペーン管理部１６，構成情報管理部１７及び個車状態管理部１８を備えている。配信管理部１３は、各車両に対するソフトウェアパッケージやキャンペーン情報の配信を管理する機能部である。車両情報管理部１４は、個々の車両よりアップロードされる個車情報を個車情報ＤＢ１０４に登録して管理する。ソフトウェア管理部１５には、ターゲットＥＣＵの更新プログラムがＯＥＭ（Original Equipment Manufacturer）等により登録される。キャンペーン管理部１６には、主に車両側システム３で表示するプログラム更新に関する情報であるキャンペーン情報がＯＥＭ等により登録される。
　構成情報管理部１７は、構成情報ＤＢ１０３に登録される車両型式毎の構成情報を管理する。構成情報は、車両に搭載されるＥＣＵのハードウェア及びソフトウェアに関する識別情報であり、複数のＥＣＵから成るシステム構成の識別情報や、複数のシステムから成る車両構成の識別情報も含まれる。個車状態管理部１８は、各車両におけるターゲットＥＣＵのプログラム更新の状態、バージョン等の情報を管理する。尚、ＰＫＧ生成サーバ４及び配信サーバ５は、コンピュータのハードウェア及びソフトウェアにより実現されている機能である。
　ＤＢ部１００の構成情報ＤＢ１０３，個車情報ＤＢ１０４，ＥＣＵリプロデータＤＢ１０５及びＥＣＵメタデータＤＢ１０６は、参照公報における「構成情報ＤＢ２０８，個車情報ＤＢ２１３，ＥＣＵリプロデータＤＢ２０４及びＥＣＵメタデータＤＢ２０５」に対応している。
　車両側システム３は、マスタ装置に相当するＯＴＡマスタ２１と、プログラムが更新される対象となる電子制御装置である更新対象ＥＣＵ２２（１），２２（２），２２（３），…を備えている。以下、更新対象ＥＣＵ２２をターゲットＥＣＵ２２と称する。
　ＯＴＡマスタ２１は、参照公報では図１に示すＤＣＭ１２及びＣＧＷ１３を合わせた機能部であり、ダウンロード処理部２３，アンパック処理部２４，ハッシュ値計算部２５及びハッシュ値比較部２６を備えている。ダウンロード処理部２３は、ＯＴＡセンタ２と無線通信を行い、配信パッケージのデータやデジタル署名のデータをダウンロードする。アンパック処理部２４は、ダウンロードされた配信パッケージを、各処理を行うデータセクション毎に分離するアンパック処理を行う。ハッシュ値計算部２５は、ハッシュ値の計算対象となるデータ値についてハッシュ値を計算するが、この機能部は第２実施形態において使用される。ハッシュ値比較部２６は、後述するようにターゲットＥＣＵ２２側で計算されたハッシュ値を、ダウンロードされた配信パッケージに含まれているハッシュ値と比較する。
　ターゲットＥＣＵ２２は、マイコン２７，メモリ２８及びハッシュ値計算部２９を備えている。メモリ２８は、例えばフラッシュメモリであり、ＯＴＡマスタ２１がダウンロードした更新データが転送されてインストールされる。ハッシュ値計算部２９は、ＯＴＡマスタ２１より転送された更新データについてハッシュ値を計算する。
　　≪リプロポリシーメタデータ≫
　図２に示すリプロポリシーメタデータは、データのダウンロードに先立って、ＯＴＡセンタ２よりＯＴＡマスタ２１に送信される。
　　＜リプロポリシーメタデータバージョン＞
　リプロポリシーメタデータのバージョンであり、例えば「１．０．０」や「２．０．０」などのバージョン情報が格納される。
　　＜配信レイヤ＞
　ＯＴＡセンタ２との通信に使用されるプロトコル，例えばＵｐｔａｎｅ（登録商標）やＯＭＡ－ＤＭ（Open Mobile Alliance-Device Management）等を示す情報や、通信手段がＯＴＡマスタ２１であることを示す「セルラー」や、その他後述するスマートホンやＵＳＢメモリであること等の情報が格納される。
　　＜マスタレイヤ＞
　ＯＴＡマスタ２１について、そのプラットフォーム（ＰＦ）が、例えばＡＰ，ＣＰ，ＡＧＬ(Automotive Grade Linux)，Ａｎｄｒｏｉｄ（登録商標）であること等を示す情報が格納される。ＥＣＵのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人ＪＡＳＰＡＲの仕様では、標準化団体ＡＵＴＯＳＡＲの静的ＯＳで動作するクラシックプラットフォーム（ＣＰ）に適用可能なデータ要件が規定されている。また、ＡＵＴＯＳＡＲでは、動的ＯＳで動作する新たなタイプのアダプティブプラットフォーム（ＡＰ）に適用可能なデータ要件が規定されている。ＡＧＬは、車載Ｌｉｎｕｘ（登録商標）であり、Ａｎｄｒｏｉｄは、Android Automotive OSである。
　加えて、制御方式については、特定のフォーマットに従い設定されたパラメータに応じて処理する「パラメータ」や、特定のフォーマットがなくより自由な記載形式で処理する「スクリプト」等の情報が格納される。
　　＜ターゲットレイヤ＞
　ターゲットＥＣＵ２２に対応した情報である。ＰＦ，転送方式，制御方式については、前述したものと同様である。ターゲットＩＤは、ターゲットＥＣＵ２２に対応したＩＤであるが、ここに格納するのはオプションである。
　　≪ダウンロードメタデータ≫
　図３に示すダウンロードメタデータは、リプロポリシーメタデータに続いてＯＴＡセンタ２よりＯＴＡマスタ２１に送信される。
　　＜配信レイヤ＞
　例えば通信プロトコルがＵｐｔａｎｅであれば、Ｕｐｔａｎｅメタデータを取得するための情報であり、それに対応したＵＲＩ，データ名，データサイズ，ハッシュ値，ターゲットＩＤ,転送方式等が格納される。
　　＜マスタレイヤ＞
　例えばＶｅｈｉｃｌｅ　ＰＫＧを取得するための情報であり、各項目は配信レイヤと同様である。この情報は、複数の場合がある。
　　＜ターゲットレイヤ＞
　例えばＳｏｆｔｗａｒｅ　ＰＫＧを取得するための情報であり、各項目は配信レイヤと同様である。この情報も、複数の場合がある。尚、Ｖｅｈｉｃｌｅ　ＰＫＧやＳｏｆｔｗａｒｅ　ＰＫＧについては、例えば“Specification of Update Configuration Management AUTOSAR AP R20-11,Document ID No.706”のp50,52，53に掲載されており、当該文献の関連する記載を参照。
　ここで、ＡＰとＣＰとの違いについて説明する。ＡＰ及びＣＰはソフトウェアプラットフォームを表している。ソフトウェアプラットフォームは、ソフトウェアアーキテクチャとも呼ばれる。ＣＰは、AUTOSAR Classic Platformを表し、ＡＰはAUTOSAR Adaptive Platformを表す。さらに、ＣＰ仕様書に準拠して動作するＥＣＵをＣＰ　ＥＣＵ又はＣＰのＥＣＵと表記し、ＡＰ仕様書に準拠して動作するＥＣＵをＡＰ　ＥＣＵ又はＡＰのＥＣＵと表記することがある。
　ＡＰ及びＣＰにおいては、使用されるオペレーティングシステム，いわゆるＯＳや開発言語が異なる。ＣＰ　ＥＣＵとＡＰ　ＥＣＵは、受信できるパッケージの構造が異なる。　これらのパッケージの構造の違いは、主にＥＣＵの処理性能の違いに起因するものであり、一般的にＣＰのＥＣＵの処理性能は低いため、パッケージに含まれる諸元データなどもバイナリデータで記載されており、処理性能の低いＥＣＵでも解釈・処理しやすいパッケージデータ構造となっている。
　一方、ＡＰのＥＣＵは処理性能が高いものが用いられるため、何らかの言語で記述された構造的な文字データを解析してプログラムで扱えるデータ構造に変換するパーサー機能を搭載することが可能であり、データ構造には単純なバイナリデータではなく、例えばＪＳＯＮ（JavaScript Object Notation）のようなオブジェクト指向のデータ形式を採用できるため、柔軟なパッケージデータ構造となっている。
　次に、本実施形態の作用について説明する。図４は、本実施形態の作用を概念的に示している。ターゲットＥＣＵ２２（１）～２２（３）に対応する更新データをＡ～Ｃとすると、ＯＴＡセンタ２の配信サーバ４は、ハッシュ値計算部１１により、各更新データＡ～Ｃについて、例えばＳＨＡ（Secure Hush Algorithm）－２等のハッシュ関数を適用してハッシュ値ａ～ｃを算出する（図５，Ｓ０）。また、前述のダウンロードメタデータＤについても同様にハッシュ値ｄを算出するが、図４から図９に示すフローチャートでは、ハッシュ値ａ～ｃに関する処理のみを現している。
　次に、ハッシュ値収集部１０により、各ハッシュ値ａ～ｃを収集すると（図６，Ｓ１）、これらのハッシュ値ａ～ｃとターゲットＩＤとを紐付けたハッシュ値連結情報を生成する（Ｓ２）。それから、デジタル署名生成部１２が、ハッシュ値連結情報に対し、デジタル署名を生成して付与する、つまり秘密鍵により暗号化すると（Ｓ３）、そのデジタル署名をデジタル署名ＤＢ１０２に伝送して保存する（Ｓ４，Ｓ５）。その後、ＯＴＡマスタ２１よりハッシュ値連結情報の伝送要求があると（図７，Ｓ６；ＹＥＳ）、配信サーバ５は、ＯＴＡマスタ２１にハッシュ値連結情報と、配信パッケージとを順次伝送する（Ｓ７，Ｓ７ａ）。
　次に、車両側システム３側の処理について説明する。図８に示すように、ＯＴＡマスタ２１のダウンロード処理部２３は、配信サーバ５よりストリーミング方式で送信された配信パッケージを受信すると、各更新データＡ～Ｃを各ターゲットＥＣＵ２２（１）～２２（３）に転送する（Ｓ１１）。続いて、ダウンロード処理部２３は、デジタル署名を受信する（Ｓ１２）。尚、この場合の通信プロトコルは、ＵｐｔａｎｅやＳＳＬ（Secure Sockets Layer）等の暗号化を用いたものを使用する。
　一方、ターゲットＥＣＵ２２は、図９に示すように、ＯＴＡマスタ２１から受信した更新データをダウンロードすると（Ｓ２１）、その更新データにハッシュ関数を適用してハッシュ値を計算する（Ｓ２２）。それから、計算したハッシュ値を、ＯＴＡマスタ２１に伝送する（Ｓ２３）。
　ＯＴＡマスタ２１は、受信したデジタル署名を検証する、つまり公開鍵で復号化して、ハッシュ値連結情報を取得する（Ｓ１３）。それから、各ターゲットＥＣＵ２２（１）～２２（３）にハッシュ値の転送を要求するが（Ｓ１４）、ステップＳ２３において、ターゲットＥＣＵ２２がＯＴＡマスタ２１に自動的にハッシュ値を転送する仕様の場合、この処理は不要である。
　全てのターゲットＥＣＵ２２からハッシュ値ａ’～ ｃ’を受信すると（Ｓ１５；ＹＥＳ）、ハッシュ値比較部２６は、ハッシュ値連結情報より取得したハッシュ値ａ～ｃと、ターゲットＥＣＵ２２から取得したハッシュ値ａ’～ ｃ’とをそれぞれ比較する（Ｓ１６）。そして、両者が全て一致すれば（Ｓ１７；ＹＥＳ）、各ターゲットＥＣＵ２２（１）～２２（３）に対してインストール指示を発行する（Ｓ１８）。一方、何れか１つでも不一致があれば（Ｓ１７；ＮＯ）、不一致があったターゲットＥＣＵ２２にロールバック指示を発行する（Ｓ１９）。この処理はオプションである。
　ターゲットＥＣＵ２２は、ＯＴＡマスタ２１からのインストール要求があると（Ｓ２４；ＹＥＳ）ダウンロードした更新データをインストールする（Ｓ２５）。また、インストール要求がなく（Ｓ２４；ＮＯ）、ＯＴＡマスタ２１から中止要求があると（Ｓ２６；ＹＥＳ）処理を終了する。
　尚、以上の処理は、ターゲットＥＣＵ２２が複数の場合であるが、図１０はターゲットＥＣＵ２２が単一の場合を示す。メタデータＥについてのハッシュ値がｅとなるだけで、基本的には図４に示す処理と同様である。
　以上のように本実施形態によれば、車載通信システム１において、ＯＴＡセンタ２は、ストリーミング方式で配信パッケージを車両側のＯＴＡマスタ２１に送信する際に、更新データについて計算したハッシュ値もＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、配信パッケージを受信すると、更新データをターゲットＥＣＵ２２に転送する。ターゲットＥＣＵ２２は、更新データについてハッシュ値を計算すると、そのハッシュ値をＯＴＡマスタ２１に送信し、ＯＴＡマスタ２１は、ＯＴＡセンタ２より送信されたハッシュ値と、ターゲットＥＣＵ２２より送信されたハッシュ値とを比較して更新データの完全性を検証する。
　このように構成すれば、ＯＴＡセンタ２からストリーミング方式で車両側システム３に送信される配信パッケージに含まれる更新データが、途中で改竄される等して不完全なデータに置き換わったとしても、ＯＴＡマスタ２１においてハッシュ値を用いた検証が行われるので、不完全な更新データがターゲットＥＣＵ２２にインストールされてしまうことを防止できる。したがって、通信システム１のセキュリティを向上させることが可能になる。
　また、ＯＴＡセンタ２は、複数のターゲットＥＣＵ２２（１）～２２（３）にそれぞれ更新データＡ～Ｃを書き込ませる際には、各更新データＡ～Ｃについて計算した複数のハッシュ値ａ～ｃもＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、各更新データＡ～Ｃを各ターゲットＥＣＵ２２（１）～２２（３）にそれぞれ転送し、各ターゲットＥＣＵ２２（１）～２２（３）は、それぞれの更新データＡ～Ｃについてハッシュ値ａ’～ｃ’を計算すると、そのハッシュ値ａ’～ｃ’をＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、複ハッシュ値ａ’～ｃ’を、ハッシュ値ａ～ｃと比較する。したがって、複数のターゲットＥＣＵ２２（１）～２２（３）にそれぞれ更新データＡ～Ｃを送信するケースについても同様に、不完全な更新データがインストールされてしまうことを防止できる。
　　（第２実施形態）
　以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。図１１に示すように、第２実施形態では、ＰＫＧ生成サーバ４は、更新データＡ～Ｃに対応して得られたハッシュ値ａ～ｃ及びメタデータに対応して得られたハッシュ値ｄに対してハッシュ関数を適用する。そして、得られたハッシュ値ｆを「ハッシュチェーン」と称する（図１２，Ｓ８）。ハッシュチェーンｆは上位ハッシュ値に相当する。そして、ハッシュチェーンｆに対してデジタル署名を付与すると（Ｓ９）、ステップＳ４及びＳ５を実行する。
　ＯＴＡマスタ２１は、ＯＴＡセンタ２の配信サーバ５から配信パッケージを受信すると（図１３，Ｓ３１）、各更新データＡ～Ｃを各ターゲットＥＣＵ２２（１）～２２（３）に転送する（Ｓ３２）。尚、ターゲットＥＣＵ２２が行う処理は、図９と同様である。
　続いて、ダウンロード処理部２３は、ハッシュチェーンｆに対して付与されたデジタル署名を受信すると（Ｓ３３）、受信したデジタル署名を検証する（Ｓ３４）。検証が成功すれば、ハッシュチェーンｆが得られる。
　ＯＴＡマスタ２１は、各ターゲットＥＣＵ２２（１）～２２（３）が計算したハッシュ値ａ’～ｃ’を受信する（Ｓ３５）。ハッシュ値計算部１１は、受信したハッシュ値ａ’～ｃ’（及びｄ’）についてハッシュチェーンｆ’を計算する（Ｓ３６）。
　そして、ハッシュ値比較部２６は、ＯＴＡセンタ２より取得したハッシュチェーンｆと、ハッシュ値計算部１１が計算したハッシュチェーンｆ’とを比較する（Ｓ３７）。両者が全て一致すれば（Ｓ３８；ＹＥＳ）、各ターゲットＥＣＵ２２（１）～２２（３）に対してインストール指示を発行する（Ｓ１８）。一方、不一致であれば（Ｓ３８；ＮＯ）、処理を終了するか、又はターゲットＥＣＵ２２にロールバック指示を発行する（Ｓ４０）。
　以上のように第２実施形態によれば、ＯＴＡセンタ２は、複数のハッシュ値ａ～ｃについて計算したハッシュ値であるハッシュチェーンｆもＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、ＥＣＵ２２（１）～２２（３）より受信したハッシュ値ａ’～ｃ’についてハッシュチェーンｆ’を計算すると、ハッシュチェーンｆ’とハッシュチェーンｆとを比較する。これにより、複数のハッシュ値ａ～ｃの何れかが不完全なデータとなった場合も検証によって検知できるので、通信システムのセキュリティを更に向上させることができる。
　　（第３実施形態）
　図１４に示すように、第３実施形態では、ＯＴＡセンタ２からストリーミング方式で配信パッケージを受信する際に、ＯＴＡマスタ２１が更新データについて順次ハッシュ値を計算する。ハッシュ関数には、前述したＳＨＡ－２を用いる。以下、一例として、ＳＨＡ－２関数を使用した事例を説明する。ＯＴＡセンタ２側の処理は、図５と同様である。ＯＴＡマスタ２１は、ＯＴＡセンタ２から受信したダウンロードメタデータより、受信するデータのサイズを把握すると（図１５，Ｓ４１）、そのデータサイズが５１２ビットの何倍になるかを計算してから（Ｓ４２）、ＯＴＡセンタ２よりストリーミング方式で配信パッケージを受信する（Ｓ４３）。
　ＯＴＡマスタ２１は、受信したデータを５１２ビット単位で分割する（Ｓ４４）。分割したデータを「メッセージ」と称すると、例えば、Ｎ個のメッセージに分割されたとする。そして、ハッシュ値計算部２５は、メッセージにＳＨＡ－２関数を適用し（Ｓ４５）、その出力結果を次のＳＨＡ－２関数の初期バッファ値として保持する（Ｓ４６）。例えばＳＨＡ－２５６であれば、５１２ビットのデータに適用して得られるハッシュ値のハッシュ長は２５６ビットになる。そして、（Ｎ―１）個のメッセージにＳＨＡ－２関数を適用するまで（Ｓ４７；ＮＯ）ステップＳ４５，Ｓ４６の処理を繰り返す。
　Ｎ個目のメッセージについては（Ｓ４７；ＹＥＳ）、そのデータサイズが５１２ビットの整数倍か否かを判断し（Ｓ４８）、整数倍でなければ（ＮＯ）パディングを行って整数倍にしてからＳＨＡ－２関数を適用し、その出力結果をハッシュ値とする（Ｓ４９）。そして、ＯＴＡマスタ２１は、配信サーバ４から受信したデジタル署名を検証してハッシュ値を得る（Ｓ５０）。ステップＳ４８において、メッセージのデータサイズが５１２ビットの整数倍であれば（ＹＥＳ）、最終的なハッシュ値が得られているのでステップＳ５０に移行する。
　それから、ハッシュ値比較部２６は、ステップＳ５０で取得したハッシュ値と、ハッシュ値計算部２５が計算したハッシュ値とを比較し（Ｓ５１）、両者が一致すれば（Ｓ５２；ＹＥＳ）ターゲットＥＣＵ２２に対してインストール指示を発行する（Ｓ５３）。一方、不一致であれば（Ｓ５２；ＮＯ）、処理を終了するか、又はターゲットＥＣＵ２２にロールバック指示を発行する（Ｓ５４）。
　尚、図１５に示す処理は、１つのターゲットＥＣＵ２２に対応したもので、ターゲットＥＣＵ２２が複数の場合は、図１５に示す処理を繰り返し実行する。また、図１６に示すターゲットＥＣＵ２２の処理は、図９におけるステップＳ２１，Ｓ２４、Ｓ２５のみを実行するもので、ステップＳ２４で「ＮＯ」と判断すると処理を終了する。
　以上のように第３実施形態によれば、ＯＴＡマスタ２１は、更新データについて所定のデータサイズ毎にハッシュ値を計算することで、更新データ全体についてのハッシュ値を得ると、そのハッシュ値とＯＴＡセンタ２より送信されたハッシュ値とを比較して更新データの完全性を検証する。このように構成すれば、完全性の検証をＯＴＡマスタ２１内の処理として行うことができる。
　　（第４実施形態）
　図１７に示すように、第４実施形態は、ストリーミング方式とストレージ方式とが混在している場合の処理を示す。ＯＴＡセンタ２の処理は、第１実施形態と同様である。図１８に示すように、ＯＴＡマスタ２１は、配信サーバ５よりストレージ方式のパッケージＡ及びストリーミング方式のパッケージＢを受信する（Ｓ６１）。パッケージＡはｚｉｐ形式であり、パッケージＡについての検証データが含まれている。続いて、ＯＴＡマスタ２１は、検証データによってパッケージＡを検証し、パッケージＢに含まれている更新データＫ，ＬをターゲットＥＣＵ２２（４），２２（５）に伝送する（Ｓ６２）。ここで、パッケージＡ，Ｂのダウンロードが開始される。
　パッケージＡであり（Ｓ６３；ＹＥＳ）検証が正常に終了すれば（Ｓ７０；ＹＥＳ）、パッケージＡに含まれている更新データＧ～ＩをターゲットＥＣＵ２２（１）～２２（３）に書き込む（Ｓ７１）。ここで、パッケージＡのインストールが開始される。一方、検証が正常に終了しなければ（Ｓ７０；ＮＯ）、パッケージＡについての処理を終了する。また、パッケージＢのインストール処理を開始しているターゲットＥＣＵ２２に対しては、ロールバック指示を発行する（Ｓ７２）。
　パッケージＢであれば（Ｓ６３；ＮＯ）、ＯＴＡマスタ２１は、更新データＫ，Ｌについて、ターゲットＥＣＵ２２（４），２２（５）が計算したハッシュ値ｋ’，ｌ’を受信する（Ｓ６４）。尚、これらのターゲットＥＣＵ２２の処理は図９と同様である。続いて、配信サーバ５よりデジタル署名を受信すると、検証を行う（Ｓ６５）。
　そして、復号したハッシュ値ｋ，ｌとハッシュ値ｋ’，ｌ’とを比較し（Ｓ６６）、両者が一致すれば（Ｓ６７；ＹＥＳ）、各ターゲットＥＣＵ２２（４），２２（５）に対してインストール指示を発行する（Ｓ６８）。ここで、パッケージＢのインストールが開始される。また、両者が不一致であれば（Ｓ６７；ＮＯ）、パッケージＢについての処理を終了する。また、パッケージＡのインストール処理を開始しているターゲットＥＣＵ２２に対しては、ロールバック指示を発行する（Ｓ６９）。
　ここで、図１８について別の態様を説明する。上記実施形態では、Ｓ６３にて、パッケージがパッケージＡであるか否かを判定した。それに替えて、ＯＴＡマスタ２１は、パッケージの種別を判定し、その結果に応じた処理を実行しても良い。パッケージＡ及びパッケージＢを受信すると、ＯＴＡマスタ２１はパッケージの種別を判定する。その結果、ＯＴＡマスタ２１は、パッケージがストレージ方式のパッケージＡであると判定するとＳ７０へ移行し、Ｓ７０からＳ７２の処理を実行する。また、ＯＴＡマスタ２１は、パッケージがストリーミング方式のパッケージＢであると判定するとＳ６４に移行し、Ｓ６４からＳ６９の処理を実行する。ＯＴＡマスタ２１によるパッケージ種別の判定は、受信したパッケージの数だけ繰り返される。
　以上のように第４実施形態によれば、ＯＴＡセンタ２は、複数のターゲットＥＣＵ２２の一部に書き込ませる更新データをストレージ方式で送信する際には、その更新データと当該データについて計算したハッシュ値とをＯＴＡマスタ２１に送信する。ＯＴＡマスタ２１は、前記更新データについてハッシュ値を計算し、ＯＴＡセンタ２より送信された対応するハッシュ値と比較して前記更新データの完全性を検証する。完全性が検証されると、ストレージ方式に対応するターゲットＥＣＵ２２（１）～２２（３）に更新データを転送する。これにより、ストレージ方式に対応するターゲットＥＣＵ２２が混在している場合でも、セキュリティを向上させることができる。
　　（第５実施形態）
　図１９に示すように、第５実施形態は、ＯＴＡセンタ２から配信パッケージを一旦スマートホン３１にダウンロードし、スマートホン３１からＯＴＡマスタ２１に転送する場合を示す。尚、「スマートホン」を「スマホ」と表記し、カーナビゲーション装置を「ナビ」と表記する場合がある。図２０に示すように、ＯＴＡセンタ２は、ステップＳ１～Ｓ４を実行すると、後述するように、ユーザが図示しないカーナビゲーション装置やスマートホン３１によりＯＴＡセンタ２と通信を行っており、パッケージの配信先としてスマートホン３１を選択しているか否かを判断する（Ｓ７３）。スマートホン３１を選択していれば（ＹＥＳ）スマートホン３１にパッケージを配信し（Ｓ７４）、スマートホン３１を選択していなければ（ＮＯ）、従前通りＯＴＡマスタ２１にパッケージを配信する（Ｓ７）。
　図２１に示すように、スマートホン３１を所持しているユーザは、そのスマートホン３１と車両側の機器とで無線通信のペアリングが行われていることを前提として、ＯＴＡセンタ２よりプッシュ通知を受け取る（Ｓ８１）。そして、スマートホン３１により、どこに配信パッケージをダウンロードするか選択する（Ｓ８２）。すると、ＯＴＡセンタ２の配信サーバ５に選択結果が通知される（Ｓ８３）。
　ユーザがスマートホン３１を選択すれば（Ｓ８４；ＹＥＳ）、スマートホン３１の指定パスにパッケージがダウンロード（ＤＬ）される（Ｓ８５）。続いて、スマートホン３１が、パッケージのダウンロードが完了したことを配信サーバ５に通知すると（Ｓ８６）、スマートホン３１は、パッケージをＯＴＡマスタ２１に転送する（Ｓ８７）。
　図２２に示すように、ＯＴＡマスタ２１は、ＯＴＡセンタ２側と車両構成情報の同期を図るため、ＯＴＡセンタ２に車両構成情報を送信する（Ｓ９１）。カーナビゲーション装置に表示された指示をユーザが実行すると（Ｓ９２；ＹＥＳ）、ＯＴＡマスタ２１は、ＯＴＡセンタ２より受信したデジタル署名を検証し、ハッシュ値連結情報を取得する（Ｓ９３）。
　そして、カーナビゲーション装置又はスマートホン３１によって、配信パッケージの送信先としてスマートホン３１を選択したことをＯＴＡセンタ２に送信すると（Ｓ９４；ＹＥＳ）、ＯＴＡマスタ２１は、ＯＴＡセンタ２から通知されたディレクトリに従い、スマートホン３１から配信パッケージをダウンロードする（Ｓ９５）。一方、送信先としてスマートホン３１が選択されなければ（Ｓ９４；ＮＯ）、ＯＴＡマスタ２１は、ＯＴＡセンタ２から配信パッケージをダウンロードする（Ｓ９６）。以降は、第１実施形態のステップＳ１２～Ｓ１９を実行する。
　以上のように第５実施形態によれば、ＯＴＡマスタ２１は、選択的に、ＯＴＡセンタ２からスマートホン３１にダウンロードされた配信パッケージを、スマートホン３１からダウンロードすることができる。これにより、配信パッケージをより柔軟な態様で取得できる。
　　（その他の実施形態）
　リプロポリシーメタデータ及びダウンロードメタデータの内容は、個別の設計に応じて適宜変更すれば良い。
　ハッシュ関数は、ＳＨＡ－２に限らない。
　本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
　各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。
　本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。
 

Claims (20)

  1. 　車両に搭載される電子制御装置（２２）に、ストリーミング方式で更新データを配信パッケージとして送信するセンタ装置（２）と、
    　前記車両に搭載され、前記配信パッケージを受信して、前記電子制御装置に更新データを転送するマスタ装置（２１）と、
    　このマスタ装置より転送された更新データを記憶部に書き込む前記電子制御装置とを備え、
    　前記センタ装置は、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    　前記電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
    　前記マスタ装置は、前記センタ装置より送信されたハッシュ値と、前記電子制御装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信システム。
  2. 　前記センタ装置は、複数の電子制御装置にそれぞれ更新データを書き込ませる際には、各更新データについて計算した複数のハッシュ値も前記マスタ装置に送信し、
    　前記マスタ装置は、各更新データを各電子制御装置にそれぞれ転送し、
    　各電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
    　前記マスタ装置は、複数の電子制御装置より送信されたハッシュ値を、前記センタ装置より送信された対応するハッシュ値と比較する請求項１記載の車載通信システム。
  3. 　前記センタ装置は、前記複数のハッシュ値について計算したハッシュ値を上位ハッシュ値として、前記上位ハッシュ値も前記マスタ装置に送信し、
    　前記マスタ装置は、複数の電子制御装置より受信した複数のハッシュ値について上位ハッシュ値を計算すると、計算した上位ハッシュ値を、前記センタ装置より送信された上位ハッシュ値と比較する請求項２記載の車載通信システム。
  4. 　前記センタ装置は、複数の電子制御装置の一部についてストレージ方式で更新データを送信する際には、前記更新データと前記更新データについて計算したハッシュ値とを前記マスタ装置に送信し、
    　前記マスタ装置は、前記更新データについてハッシュ値を計算し、前記センタ装置より送信された対応するハッシュ値と比較して、前記更新データの完全性を検証し、
    　前記更新データの完全性が検証されると、前記ストレージ方式に対応する電子制御装置に更新データを転送する請求項２又は３記載の車載通信システム。
  5. 　前記センタ装置は、少なくともデータ取得先のアドレス，データ名及びデータサイズ，更新データの配信先である電子制御装置のＩＤ並びにデータ転送方式の情報を含むダウンロードメタデータに、前記ハッシュ値を加えて前記マスタ装置に送信する請求項１から４の何れか一項に記載の車載通信システム。
  6. 　前記センタ装置より、前記更新データを受信可能な携帯型情報端末を備え、
    　前記マスタ装置は、前記携帯型情報端末を介しても、前記更新データを受信可能である請求項１から５の何れか一項に記載の車載通信システム。
  7. 　車両に搭載される電子制御装置に、ストリーミング方式で更新データを配信パッケージとして送信するセンタ装置と、
    　前記配信パッケージを受信して、前記電子制御装置に更新データを転送するマスタ装置と、
    　このマスタ装置より転送された更新データを記憶部に書き込む前記電子制御装置とを備え、
    　前記センタ装置は、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    　前記マスタ装置は、前記更新データについて所定のデータサイズ毎にハッシュ値を計算することで、前記更新データ全体についてのハッシュ値を得ると、前記ハッシュ値と前記センタ装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信システム。
  8. 　車両に搭載される電子制御装置に、ストリーミング方式で更新データを送信する際に、前記更新データについて計算したハッシュ値も送信するセンタ装置。
  9. 　複数の電子制御装置にそれぞれ更新データを送信する際には、各更新データについて計算した複数のハッシュ値も送信する請求項８記載のセンタ装置。
  10. 　前記複数のハッシュ値について計算したハッシュ値を上位ハッシュ値として、前記上位ハッシュ値も送信する請求項９記載のセンタ装置。
  11. 　複数の電子制御装置の一部についてストレージ方式で更新データを送信する際には、前記更新データと前記更新データについて計算したハッシュ値とを送信する請求項９又は１０記載のセンタ装置。
  12. 　少なくともデータ取得先のアドレス，データ名及びデータサイズ，更新データの配信先である電子制御装置のＩＤ並びにデータ転送方式の情報を含むダウンロードメタデータに、前記ハッシュ値を加えて送信する請求項８から１１の何れか一項に記載のセンタ装置。
  13. 車両に搭載され、センタ装置よりストリーミング方式で送信され、更新データを含む配信パッケージを受信するマスタ装置と、
    　前記車両に搭載され、前記マスタ装置より転送された更新データを記憶部に書き込む電子制御装置とを備え、
    　前記マスタ装置は、前記センタ装置が前記更新データについて計算して送信したハッシュ値を受信し、
    　前記電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
    　前記マスタ装置は、前記センタ装置より送信されたハッシュ値と、前記電子制御装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車両側システム。
  14. 　前記マスタ装置は、前記センタ装置が、複数の電子制御装置にそれぞれ更新データを送信する際に、各更新データについて計算し送信した複数のハッシュ値も受信すると、各更新データを各電子制御装置にそれぞれ転送し、
    　各電子制御装置は、前記更新データについてハッシュ値を計算すると、前記ハッシュ値を前記マスタ装置に送信し、
    　前記マスタ装置は、複数の電子制御装置より送信されたハッシュ値を、前記センタ装置より送信された対応するハッシュ値と比較する請求項１３記載の車両側システム。
  15. 　前記マスタ装置は、前記センタ装置が、前記複数のハッシュ値について計算したハッシュ値を上位ハッシュ値として送信したものも受信し、
    　複数の電子制御装置より受信した複数のハッシュ値について上位ハッシュ値を計算すると、計算した上位ハッシュ値を、前記センタ装置より送信された上位ハッシュ値と比較する請求項１４記載の車両側システム。
  16. 　前記マスタ装置は、前記センタ装置が、複数の電子制御装置の一部に対する更新データを含む配信パッケージをストレージ方式で送信する際に、前記更新データと前記更新データについて計算したハッシュ値とを受信し、
    　前記更新データについてハッシュ値を計算し、前記センタ装置より送信された対応するハッシュ値と比較して、前記更新データの完全性を検証し、
    　前記更新データの完全性が検証されると、前記ストレージ方式に対応する電子制御装置に更新データを転送する請求項１４又は１５記載の車両側システム。
  17. 　前記センタ装置より、前記配信パッケージを受信可能な携帯型情報端末を備え、
    　前記マスタ装置は、前記センタ装置より、前記携帯型情報端末を介しても、前記配信パッケージを受信可能である請求項１３から１６の何れか一項に記載の車両側システム。
  18. 　車両に搭載され、センタ装置よりストリーミング方式で送信される更新データを配信パッケージとして受信するマスタ装置と、
    　前記車両に搭載され、前記マスタ装置より転送された更新データを記憶部に書き込む電子制御装置とを備え、
    　前記センタ装置は、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    　前記マスタ装置は、前記センタ装置が、前記更新データについて計算したハッシュ値も受信し、前記更新データについて所定のデータサイズ毎にハッシュ値を計算することで、前記更新データ全体についてのハッシュ値を得ると、前記ハッシュ値と前記センタ装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車両側システム。
  19. 　センタ装置が、車両に搭載される電子制御装置に、ストリーミング方式で更新データを送信する際に、
    　前記車両に搭載されるマスタ装置が前記更新データを配信パッケージとして受信すると前記電子制御装置に転送し、
    　前記センタ装置が、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    　前記電子制御装置が、前記更新データについて計算したハッシュ値を前記マスタ装置に送信し、
    　前記マスタ装置が、前記センタ装置より送信されたハッシュ値と、前記電子制御装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信の更新データ検証方法。
  20. 　センタ装置が、車両に搭載される電子制御装置に、ストリーミング方式で更新データを送信する際に、
    　前記車両に搭載されるマスタ装置が前記更新データを配信パッケージとして受信すると、前記電子制御装置に転送し、
    　前記センタ装置が、前記更新データについて計算したハッシュ値も前記マスタ装置に送信し、
    　前記マスタ装置が、前記センタ装置が前記更新データについて計算したハッシュ値も受信し、前記更新データについて所定のデータサイズ毎にハッシュ値を計算することで、前記更新データ全体についてのハッシュ値を得ると、前記ハッシュ値と前記センタ装置より送信されたハッシュ値とを比較して、前記更新データの完全性を検証する車載通信の更新データ検証方法。
PCT/JP2022/022159 2021-06-29 2022-05-31 車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法 WO2023276532A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202280045176.1A CN117561500A (zh) 2021-06-29 2022-05-31 车载通信系统、中心装置、车辆侧系统以及车载通信的更新数据验证方法
DE112022003289.8T DE112022003289T5 (de) 2021-06-29 2022-05-31 Bordeigenes kommunikationssystem, zentrale vorrichtung, fahrzeugseitiges system und verfahren zur verifizierung von aktualisierungsdaten einer bordeigenen kommunikation
US18/537,350 US20240111519A1 (en) 2021-06-29 2023-12-12 Onboard communication system, center device, vehicle-side system, and method for verifying update data of onboard communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021107834A JP2023005717A (ja) 2021-06-29 2021-06-29 車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法
JP2021-107834 2021-06-29

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/537,350 Continuation US20240111519A1 (en) 2021-06-29 2023-12-12 Onboard communication system, center device, vehicle-side system, and method for verifying update data of onboard communication

Publications (1)

Publication Number Publication Date
WO2023276532A1 true WO2023276532A1 (ja) 2023-01-05

Family

ID=84691255

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/022159 WO2023276532A1 (ja) 2021-06-29 2022-05-31 車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法

Country Status (5)

Country Link
US (1) US20240111519A1 (ja)
JP (1) JP2023005717A (ja)
CN (1) CN117561500A (ja)
DE (1) DE112022003289T5 (ja)
WO (1) WO2023276532A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1153193A (ja) * 1997-06-05 1999-02-26 Matsushita Electric Ind Co Ltd リモートダウンロードが可能な端末装置、その端末装置が備えるローダプログラムに適用されるダウンロード方法、そのローダプログラムを記録した記録媒体
JP2010282385A (ja) * 2009-06-04 2010-12-16 Fujitsu Ten Ltd 情報処理システム
JP2017149323A (ja) * 2016-02-25 2017-08-31 オムロンオートモーティブエレクトロニクス株式会社 車両制御システム
JP2020027666A (ja) * 2018-08-10 2020-02-20 株式会社デンソー 電子制御装置、車両用電子制御システム及び諸元データのデータ構造

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7059985B2 (ja) 2018-08-10 2022-04-26 株式会社デンソー 車両用電子制御システム、車両用マスタ装置、データ格納面情報の送信制御方法、データ格納面情報の送信制御プログラム、車両用マスタ装置側プログラム、センター装置、更新データの選定方法及びセンター装置側プログラム
JP6920571B2 (ja) 2019-07-10 2021-08-18 藤倉コンポジット株式会社 液検知センサ

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1153193A (ja) * 1997-06-05 1999-02-26 Matsushita Electric Ind Co Ltd リモートダウンロードが可能な端末装置、その端末装置が備えるローダプログラムに適用されるダウンロード方法、そのローダプログラムを記録した記録媒体
JP2010282385A (ja) * 2009-06-04 2010-12-16 Fujitsu Ten Ltd 情報処理システム
JP2017149323A (ja) * 2016-02-25 2017-08-31 オムロンオートモーティブエレクトロニクス株式会社 車両制御システム
JP2020027666A (ja) * 2018-08-10 2020-02-20 株式会社デンソー 電子制御装置、車両用電子制御システム及び諸元データのデータ構造

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HIDETOSHI TERAOKA; TOMOCHIKA OZAKI: "A survey on Extensibility of the Network Embedded Systems", IPSJ TRANSACTIONS ON CONSUMER DEVICES AND SYSTEMS, vol. 11, no. 1, 11 March 2021 (2021-03-11), JP , pages 1 - 13, XP009543034, ISSN: 2186-5728 *

Also Published As

Publication number Publication date
JP2023005717A (ja) 2023-01-18
US20240111519A1 (en) 2024-04-04
DE112022003289T5 (de) 2024-04-18
CN117561500A (zh) 2024-02-13

Similar Documents

Publication Publication Date Title
US10599420B2 (en) Updating a controller unit in a vehicle
US11163549B2 (en) Vehicle information communication system
JP5096680B2 (ja) ファームウェアコンポーネントのステータスの発行およびファームウェアコンポーネントのアップデート
US8978160B2 (en) Method for selective software rollback
US20140282470A1 (en) Remote transfer of electronic images to a vehicle
CN111263352A (zh) 车载设备的ota升级方法、系统、存储介质及车载设备
US20210019418A1 (en) Technique for authentication and prerequisite checks for software updates
EP3405923B1 (en) Updating a controller unit in a vehicle
JP2023505844A (ja) パッケージベースリモートファームウェアアップデート
WO2021166617A1 (ja) マスタ装置、データ配信システム及び更新制御プログラム
WO2023276532A1 (ja) 車載通信システム，センタ装置，車両側システム及び車載通信の更新データ検証方法
WO2022226938A1 (zh) 软件升级方法和相关产品
WO2023276531A1 (ja) 車載通信システム，リプロポリシーメタデータのデータ構造及びダウンロードメタデータのデータ構造
US20220284743A1 (en) Center device and in-vehicle electronic control device
US11972248B2 (en) Controlling software update of electronic control units mounted on a vehicle
CN110825406A (zh) 一种软件升级的方法及相关设备
WO2023153143A1 (ja) センタ装置及び配信パッケージの生成方法
WO2023013471A1 (ja) センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム
US20230036444A1 (en) System, method, and non-transitory storage medium
US11941126B2 (en) Center, information rewriting method, and non-transitory storage medium
US11947950B2 (en) Center, OTA master, method, non-transitory storage medium, and vehicle
US20220276853A1 (en) Ota master, center, system, update method, and vehicle
JP2022138385A (ja) 検証装置および検証方法
JP2021131694A (ja) データ配信装置、データ配信システム及びデータ配信プログラム
CN116489649A (zh) 基于嵌入式Linux系统的车载网关安全认证方法及设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22832690

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280045176.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 112022003289

Country of ref document: DE