WO2023053621A1 - データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラム - Google Patents

データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラム Download PDF

Info

Publication number
WO2023053621A1
WO2023053621A1 PCT/JP2022/024875 JP2022024875W WO2023053621A1 WO 2023053621 A1 WO2023053621 A1 WO 2023053621A1 JP 2022024875 W JP2022024875 W JP 2022024875W WO 2023053621 A1 WO2023053621 A1 WO 2023053621A1
Authority
WO
WIPO (PCT)
Prior art keywords
ota
key
cdn
encrypted
common key
Prior art date
Application number
PCT/JP2022/024875
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 CN202280065002.1A priority Critical patent/CN118140454A/zh
Priority to JP2023550370A priority patent/JPWO2023053621A1/ja
Priority to DE112022004670.8T priority patent/DE112022004670T5/de
Publication of WO2023053621A1 publication Critical patent/WO2023053621A1/ja
Priority to US18/618,840 priority patent/US20240267221A1/en

Links

Images

Classifications

    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • 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
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • 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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • 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
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
    • 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/3242—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 keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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 relates to a data communication system, center device, master device, encryption program and decryption program.
  • Patent Document 1 discloses a technique for distributing an update package in which update data is packaged from a center device to a master device on the vehicle side by OTA (Over The Air) technology.
  • the master device is a device that manages the reprogramming of application programs in the ECU.
  • the update data delivered from the center device to the master device includes, for example, application programs and data such as automatic driving, advanced driver-assistance systems (ADAS), and multimedia.
  • ADAS advanced driver-assistance systems
  • the decryption process of the advanced encryption standard (hereinafter abbreviated as AES (Advanced Encryption Standard)) has become a bottleneck. Therefore, if a cipher block chaining mode of a general block cipher (hereinafter referred to as CBC mode (Cipher Block Chaining Mode)) is adopted as the encryption method and decryption method, the throughput is expected to be about 10 Mbps.
  • CBC mode Cipher Block Chaining Mode
  • the data size is 20 GB, it takes a little less than 5 hours to download the update package. If the time required to download the update package becomes longer like this, depending on the usage scene, the driver may be forced to wait longer than necessary while the update package is being downloaded, which may adversely affect the UX of the driver.
  • the present disclosure aims to appropriately increase the throughput when the master device downloads update data from the center device.
  • a center device that distributes update data to a master device and a master device that installs the update data downloaded from the center device in an electronic control device to be reprogrammed are provided.
  • a counter (CTR) mode was adopted as an encryption method and a decryption method for update data.
  • a configuration that uses the CBC mode as an encryption method and decryption method has disadvantages such as the inability to prepare for encryption and decryption, and the inability to perform encryption parallel processing.
  • the configuration employing the CTR mode as the encryption method and the decryption method has merits of improving throughput, such as being able to prepare for encryption and decryption and parallel processing of encryption and decryption.
  • the CTR mode which has the merit of contributing to the above-described throughput improvement, is adopted. Throughput can be appropriately increased when the master device downloads update data from the center device.
  • a center device that distributes update data to a master device and a master device that installs the update data downloaded from the center device in an electronic control device to be reprogrammed are provided.
  • An output feedback (OFB) mode was adopted as an encryption method and a decryption method for update data.
  • a configuration that uses the CBC mode as an encryption method and decryption method has disadvantages such as the inability to prepare for encryption and decryption, and the inability to perform encryption parallel processing.
  • the configuration employing the OFB mode as the encryption method and the decryption method has the merit of contributing to an improvement in throughput, such as being able to prepare in advance for encryption and decryption.
  • the OFB mode which has the merit of contributing to the above-described improvement in throughput, is adopted as opposed to the conventional one that adopts the CBC mode. Throughput can be appropriately increased when the master device downloads update data from the center device.
  • FIG. 1 is a diagram showing the flow of processing in the entire system of the first embodiment
  • FIG. 2 is a functional block diagram of the OTA Center and OTA Master
  • FIG. 3 is a diagram for explaining encryption processing in CTR mode.
  • FIG. 4 is a diagram for explaining decoding processing in CTR mode.
  • FIG. 5 is a diagram showing a comparison of the merits and demerits of the CBC mode and the CTR mode
  • FIG. 6 is a diagram showing a comparison of throughput between CBC mode and CTR mode
  • FIG. 7 is a diagram for explaining decoding processing in CBC mode
  • FIG. 1 is a diagram showing the flow of processing in the entire system of the first embodiment
  • FIG. 2 is a functional block diagram of the OTA Center and OTA Master
  • FIG. 3 is a diagram for explaining encryption processing in CTR mode.
  • FIG. 4 is a diagram for explaining decoding processing in CTR mode.
  • FIG. 5 is a diagram showing a comparison of the merits and demerits of the CBC
  • FIG. 8 is a diagram for explaining decoding processing in CTR mode;
  • FIG. 9 is a diagram showing the processing of the OTA center,
  • FIG. 10 is a diagram showing the processing of the center,
  • FIG. 11 is a diagram showing the processing of the OTA center,
  • FIG. 12 is a diagram showing the processing of the OTA master,
  • FIG. 13 is a diagram showing the processing of the OTA master,
  • FIG. 14 is a diagram showing the processing of the OTA master,
  • FIG. 15 is a diagram for explaining OFB mode encryption processing according to the second embodiment.
  • FIG. 16 is a diagram for explaining OFB mode decoding processing.
  • FIG. 17 is a diagram showing a comparison of the merits and demerits of the CBC mode and the OFB mode, FIG.
  • FIG. 18 is a diagram showing a comparison of throughput between CBC mode and OFB mode
  • FIG. 19 is a diagram for explaining decoding processing in CTR mode
  • FIG. 20 is a diagram for explaining OFB mode decoding processing.
  • FIG. 21 is a diagram showing the processing of the OTA center
  • FIG. 22 is a diagram showing the processing of the OTA center
  • FIG. 23 is a diagram showing the processing of the OTA center
  • FIG. 24 is a diagram showing the processing of the OTA master
  • FIG. 25 is a diagram showing the processing of the OTA master
  • FIG. 26 is a diagram showing the processing of the OTA master
  • FIG. 27 is a diagram showing the flow of processing in the overall system of the third embodiment
  • FIG. 28 is a diagram showing the processing of the OTA center
  • FIG. 29 is a diagram showing the processing of the OTA center
  • FIG. 30 is a diagram showing the processing of the OTA center
  • FIG. 31 is a diagram showing the processing of the OTA master
  • FIG. 32 is a diagram showing the processing of the OTA master
  • FIG. 33 is a diagram showing the processing of the OTA master
  • FIG. 34 is a diagram showing the flow of processing in the entire system of the fourth embodiment
  • FIG. 35 is a functional block diagram of the OTA Center and OTA Master
  • FIG. 36 is a diagram showing the processing of the OTA master
  • FIG. 37 is a diagram showing the processing of the OTA master
  • FIG. 38 is a diagram showing the processing of the OTA master
  • FIG. 39 is a diagram showing the processing of the OTA master of the fifth embodiment
  • FIG. 40 is a diagram showing the processing of the OTA master
  • FIG. 41 is a diagram showing the processing of the OTA master
  • FIG. 42 is a diagram showing the relationship between memory capacity and access speed
  • FIG. 43 is a diagram showing the flow of processing in the entire system of the sixth embodiment
  • FIG. 44 is a functional block diagram of the OTA Center and OTA Master
  • FIG. 45 is a diagram showing how RP metadata is transmitted
  • FIG. 46 is a diagram showing the structure of RP metadata
  • FIG. 47 is a diagram showing the structure of RP metadata
  • FIG. 48 is a diagram showing the processing of the OTA center
  • FIG. 49 is a diagram showing the processing of the OTA center
  • FIG. 50 is a diagram showing the processing of the OTA center
  • FIG. 51 is a diagram showing the processing of the OTA center
  • FIG. 52 is a diagram showing the processing of the OTA master
  • FIG. 53 is a diagram showing the processing of the OTA master
  • FIG. 54 is a diagram showing the processing of the OTA master
  • FIG. 55 is a diagram showing the flow of processing in the entire system of the seventh embodiment
  • Figure 56 is the function of the CCMP mode
  • FIG. 57 is a diagram for explaining throughput estimation in CCMP mode
  • FIG. 58 is a functional block diagram of a conventional method
  • FIG. 59 is a diagram for explaining throughput estimation by the conventional method
  • FIG. 60 is a diagram showing a comparison of throughput between the CCMP mode and the conventional method
  • FIG. 61 is a functional block diagram of the OTA Center and OTA Master;
  • FIG. 62 is a diagram showing the processing of the OTA center,
  • FIG. 63 is a diagram showing the processing of the OTA center,
  • FIG. 64 is a diagram showing the processing of the OTA center,
  • FIG. 65 is a diagram showing the processing of the OTA master,
  • FIG. 66 is a diagram showing the processing of the OTA master,
  • FIG. 67 is a diagram showing the processing of the OTA master,
  • FIG. 68 is a diagram showing the flow of processing in the entire system of the eighth embodiment,
  • FIG. 69 is a functional block diagram of GCMP mode,
  • FIG. 70 is a diagram for explaining throughput estimation in GCMP mode;
  • FIG. 71 is a diagram showing a comparison of the throughput of the GCMP mode and the conventional method
  • FIG. 72 is a diagram showing the processing of the OTA center
  • FIG. 73 is a diagram showing the processing of the OTA center
  • FIG. 74 is a diagram showing the processing of the OTA center
  • FIG. 75 is a diagram showing the processing of the OTA master
  • FIG. 76 is a diagram showing the processing of the OTA master
  • FIG. 77 is a diagram showing the processing of the OTA master
  • FIG. 78 is a diagram showing the flow of processing in the entire system of the ninth embodiment
  • FIG. 79 is a diagram showing the processing of the OTA center
  • FIG. 80 is a diagram showing the processing of the OTA center
  • FIG. 81 is a diagram showing the processing of the OTA center
  • FIG. 82 is a diagram showing the processing of the OTA center
  • FIG. 83 is a diagram showing the processing of the OTA master
  • FIG. 84 is a diagram showing the processing of the OTA master
  • FIG. 85 is a diagram showing the processing of the OTA master
  • FIG. 86 is a diagram showing the processing of the OTA master
  • FIG. 87 is a diagram showing the flow of processing in the entire system of the tenth embodiment
  • FIG. 88 is a diagram showing a CDN cost comparison
  • FIG. 89 is a diagram showing a CDN cost comparison
  • FIG. 90 is a diagram showing a CDN price table for each cloud service;
  • FIG. 91 is a diagram showing a price table of the storage method of each cloud service provider
  • FIG. 92 is a diagram showing a price table for each streaming size in the streaming method of the cloud service provider
  • FIG. 93 is a diagram showing a price table for each streaming size in the streaming method of each cloud service provider
  • FIG. 94 is a functional block diagram of the OTA Center and OTA Master
  • FIG. 95 is a diagram showing the processing of the OTA center
  • FIG. 96 is a diagram showing the processing of the OTA center
  • FIG. 97 is a diagram showing the processing of the OTA center
  • FIG. 98 is a diagram showing the processing of the OTA center
  • FIG. 99 is a diagram showing the flow of processing in the entire system of the eleventh embodiment
  • FIG. 95 is a diagram showing the processing of the OTA center
  • FIG. 96 is a diagram showing the processing of the OTA center
  • FIG. 97 is a diagram showing the processing of the OTA center
  • FIG. 98 is
  • FIG. 100 is a diagram showing a common key that can be shared by DHE or ECDHE;
  • FIG. 101 is a diagram showing the processing of the OTA center,
  • FIG. 102 is a diagram showing the processing of the OTA center,
  • FIG. 103 is a diagram showing the processing of the OTA center,
  • FIG. 104 is a diagram showing the processing of the OTA center,
  • FIG. 105 is a diagram showing the processing of the OTA master,
  • FIG. 106 is a diagram showing the processing of the OTA master,
  • FIG. 107 is a diagram showing the processing of the OTA master,
  • FIG. 108 is a diagram showing the processing of the OTA master,
  • FIG. 109 is a diagram showing the flow of processing in the entire system of the twelfth embodiment, FIG.
  • FIG. 110 is a diagram showing the processing of the OTA center
  • FIG. 111 is a diagram showing the processing of the OTA center
  • FIG. 112 is a diagram showing the processing of the OTA center
  • FIG. 113 is a diagram showing the processing of the OTA master
  • FIG. 114 is a diagram showing the processing of the OTA master
  • FIG. 115 is a diagram showing the processing of the OTA master
  • FIG. 116 is a diagram showing the flow of processing in the entire system of the thirteenth embodiment
  • FIG. 117 is a diagram for explaining encryption processing in CTR mode
  • FIG. 118 is a diagram for explaining decoding processing in CTR mode
  • FIG. 119 is a diagram showing the processing of the OTA center
  • FIG. 120 is a diagram showing the processing of the OTA center
  • FIG. 120 is a diagram showing the processing of the OTA center
  • FIG. 120 is a diagram showing the processing of the OTA center
  • FIG. 120 is a diagram showing the processing of the OTA center
  • FIG. 121 is a diagram showing the processing of the OTA center
  • FIG. 122 is a diagram showing the processing of the OTA master
  • FIG. 123 is a diagram showing the processing of the OTA master
  • FIG. 124 is a diagram showing the processing of the OTA master
  • FIG. 125 is a diagram showing the flow of processing in the entire system of the fourteenth embodiment
  • FIG. 126 is a diagram explaining the AES individual key
  • FIG. 127 is a diagram showing the processing of the OTA center
  • FIG. 128 is a diagram showing the processing of the OTA center
  • FIG. 129 is a diagram showing the processing of the OTA center
  • FIG. 130 is a diagram showing the processing of the OTA master
  • FIG. 131 is a diagram showing the processing of the OTA master
  • FIG. 132 is a diagram showing the processing of the OTA master
  • FIG. 133 is a diagram showing the flow of processing in the entire system of the fifteenth embodiment
  • FIG. 134 is a diagram showing the processing of the OTA center
  • FIG. 135 is a diagram showing the processing of the OTA center
  • FIG. 136 is a diagram showing the processing of the OTA master
  • FIG. 137 is a diagram showing the processing of the OTA master
  • FIG. 138 is a diagram showing the flow of processing in the entire system of the sixteenth embodiment
  • FIG. 139 is a diagram showing an attack from an intermediary attacker
  • FIG. 140 is a diagram showing a mode of adding a digital signature
  • FIG. 141 is a diagram showing the processing of the OTA center
  • FIG. 142 is a diagram showing the processing of the OTA center
  • FIG. 143 is a diagram showing the processing of the OTA center
  • FIG. 144 is a diagram showing the processing of the OTA master
  • FIG. 145 is a diagram showing the processing of the OTA master
  • FIG. 146 is a diagram showing the flow of processing in the entire system of the seventeenth embodiment
  • FIG. 147 is a diagram showing the processing of the OTA center
  • FIG. 148 is a diagram showing the processing of the OTA center
  • FIG. 149 is a diagram showing the processing of the OTA master
  • FIG. 150 is a diagram showing the processing of the OTA master
  • FIG. 151 is a diagram showing the processing of the OTA master
  • FIG. 152 is a diagram showing the flow of processing in the entire system of the eighteenth embodiment
  • FIG. 153 is a diagram showing a CDN price table for each cloud service
  • FIG. 154 is a diagram showing a CDN price table for each cloud service
  • FIG. 155 is a diagram showing a price table of the storage method of each cloud service provider
  • FIG. 156 is a diagram showing the price table of the storage method of each cloud service provider
  • FIG. 157 is a diagram showing a price table for each streaming size in the streaming method of each cloud service provider
  • FIG. 158 is a diagram showing a price table for each streaming size in the streaming method of each cloud service provider
  • FIG. 159 is a diagram showing a price table for each streaming size in the streaming method of each cloud service provider
  • FIG. 159 is a diagram showing a price table for each streaming size in the streaming method of each cloud service provider
  • FIG. 160 is a diagram showing a price table for each streaming size in the streaming method of each cloud service provider
  • FIG. 161 is a diagram showing quality information of each cloud service provider
  • FIG. 162 is a diagram for explaining the selection of CDN vendors
  • FIG. 163 is a diagram showing the processing of the OTA center
  • FIG. 164 is a diagram showing the processing of the OTA center
  • FIG. 165 is a diagram showing the processing of the OTA center
  • FIG. 166 shows a modification of the eleventh embodiment, and is a diagram showing part of the flow of processing in the entire system
  • FIG. 167 is a diagram showing part of the flow of processing in the entire system
  • FIG. 168 is a diagram showing part of the flow of processing in the entire system
  • FIG. 169 is a diagram showing part of the flow of processing in the entire system
  • FIG. 170 is a diagram showing the processing of the OTA master
  • FIG. 171 is a diagram showing the processing of the PC
  • FIG. 172 is a diagram showing the processing of the OTA center
  • FIG. 173 is a diagram showing the processing of the OTA master
  • FIG. 174 shows a modification of the twelfth embodiment, and is a diagram showing part of the flow of processing in the entire system
  • FIG. 175 is a diagram showing part of the flow of processing in the entire system
  • FIG. 176 is a diagram showing part of the flow of processing in the entire system
  • FIG. 177 is a diagram showing part of the flow of processing in the entire system
  • FIG. 177 is a diagram showing part of the flow of processing in the entire system
  • FIG. 178 is a diagram showing the processing of the OTA master
  • FIG. 179 is a diagram showing the processing of the PC
  • FIG. 180 is a diagram showing the processing of the OTA center
  • FIG. 181 is a diagram showing the processing of the OTA master
  • FIG. 182 shows a modification of the sixteenth embodiment, and is a diagram showing part of the flow of processing in the entire system
  • FIG. 183 is a diagram showing part of the flow of processing in the entire system
  • FIG. 184 is a diagram showing part of the flow of processing in the entire system
  • FIG. 185 is a diagram showing part of the flow of processing in the entire system
  • FIG. 186 is a diagram showing the processing of the OTA master
  • FIG. 187 is a diagram showing the processing of the PC
  • FIG. 188 is a diagram showing the processing of the OTA center
  • FIG. 189 is a diagram showing the processing of the OTA master
  • FIG. 190 is a diagram showing the flow of processing in the entire system of the nineteenth embodiment
  • FIG. 191 is a diagram showing the processing of the campaign notification generation unit
  • FIG. 192 is a diagram showing the processing of the CDN vendor selection unit
  • FIG. 193 is a diagram showing the processing of the CDN vendor selection unit
  • FIG. 194 is a diagram showing the flow of processing in the entire system of the first modification of the nineteenth embodiment
  • FIG. 195 is a diagram showing the processing of the CDN vendor selection unit
  • FIG. 196 is a diagram showing the flow of processing in the entire system of the second modification of the nineteenth embodiment, FIG.
  • FIG. 197 is a diagram showing a selection table
  • FIG. 198 is a diagram showing the processing of the CDN vendor selection unit
  • FIG. 199 is a diagram showing the processing of the CDN vendor selection unit
  • FIG. 200 is a diagram showing the processing of the performance measurement unit
  • FIG. 201 is a diagram showing the processing of the CDN server confirmation unit
  • FIG. 202 is a diagram showing the flow of processing in the entire system of the third modification of the nineteenth embodiment
  • FIG. 203 is a diagram showing processing of the log transmission unit 3a.
  • FIG. 204 is a diagram showing the processing of the performance measurement unit
  • FIG. 205 is a diagram showing the processing of the performance measurement unit
  • FIG. 206 shows the fourth modification of the nineteenth embodiment, and shows the processing of the CDN vendor selection unit 7a.
  • FIG. 207 is a diagram showing the processing of the campaign notification generation unit;
  • FIG. 208 is a diagram showing the flow of processing in the entire system of the fifth modification of the nineteenth embodiment,
  • FIG. 209 is a diagram showing a round robin record;
  • FIG. 210 is a diagram showing the processing of the CDN vendor selection unit 7a,
  • FIG. 211 is a diagram showing the processing of the switching unit;
  • FIG. 212 is a diagram showing the flow of processing in the entire system of the twentieth embodiment;
  • FIG. 213 is a diagram showing a calculation method,
  • FIG. 214 is a diagram showing the processing of the campaign notification generation unit;
  • FIG. 215 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 216 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 217 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 218 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 219 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 220 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 221 is a diagram showing the processing of the CDN vendor selection unit;
  • FIG. 222 is a diagram showing the processing of the progress information management unit;
  • FIG. 223 is a diagram showing the processing of the CDN vendor selection unit;
  • 224 is a diagram depicting processing of a campaign notification generation unit;
  • a data communication system 1 includes an OTA center 2 and a vehicle-side system 3 mounted on a vehicle, and the OTA center 2 and the vehicle-side system 3 are configured to be able to communicate data.
  • the OTA center 2 corresponds to a center device.
  • the OTA center 2 and the vehicle-side system 3 have a one-to-many relationship, and the OTA center 2 can perform data communication with an unspecified number of vehicle-side systems 3 .
  • the vehicle-side system 3 includes an OTA master 4 and a target ECU 5.
  • the OTA master 4 corresponds to a master device.
  • the OTA master 4 and the target ECU 5 are connected to an in-vehicle network such as CAN (Controller Area Network) (registered trademark), and are connected so as to be able to communicate data via the in-vehicle network.
  • the in-vehicle network may be LIN (Local Interconnect Network), FlexRay (registered trademark), CAN FD (CAN Flexible Data rate) (registered trademark), Ethernet (registered trademark), or the like.
  • the target ECU 5 is an ECU to be reprogrammed by the application program.
  • An application program is a program related to execution of an application, and includes, for example, an application program, a firmware program, and an operating system program.
  • the OTA center 2 comprises a package generation server 6 and a distribution server 7.
  • the package generation server 6 is a server having a function of packaging update data and generating an update package.
  • An update package is, for example, a zip file in which multiple files containing update data are compressed and stored.
  • the distribution server 7 is a server having a function of distributing the update package generated by the package generation server 6 to the vehicle-side system 3 .
  • the OTA center 2 delivers a campaign notification to the vehicle-side system 3 or a mobile information terminal such as a smartphone owned by the user when a reprogramming request for the ECU application program occurs due to, for example, a version upgrade due to functional improvement, etc.
  • the OTA center 2 places the update package on a content delivery network (hereinafter referred to as CDN (Content Delivery Network)) 8 on the condition that the download consent is obtained from the user, and distributes the update package via the CDN 8. to the OTA master 4.
  • CDN Content Delivery Network
  • the OTA center 2 causes the CDN 8 to distribute the update package to the OTA master 4 on condition that the download approval from the user is obtained.
  • the OTA master 4 transfers the update package to the target ECU 5 and installs the update package on the target ECU 5 on the condition that the installation consent is obtained from the user.
  • a company that provides CDN8 as a service is called a CDN vendor.
  • the OTA master 4 acquires the update package by accessing the CDN server of the CDN 8 .
  • the OTA center 2 encrypts the update package with an AES key in CTR mode.
  • the vehicle-side system 3 encrypts the update package in CTR mode with an AES key.
  • the OTA center 2 has an RSA (Rivest-Shamir-Adleman cryptosystem) public key for each vehicle.
  • the OTA master 4 is written with an RSA private key at the vehicle manufacturing stage.
  • the OTA center 2 includes, as functional blocks related to encryption, a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, An encrypted package placement unit 2e and a campaign notification transmission unit 2f are provided.
  • the update package encryption unit 2b corresponds to update data encryption.
  • the encrypted package placement section 2e corresponds to an encrypted data placement section.
  • Each part 2a to 2f is realized by cooperation of microcomputer hardware and software, which has CPU (Central Processing Unit), RAM (Random Access Memory), ROM (Read Only Memory), I/O (Input/Output), etc. It is The CPU implements the functions of the OTA center 2 by executing various programs stored in the ROM, including an encryption program, an update data placement program, a secret information sharing program, and the like.
  • the common key generation unit 2a generates an AES key as a common key for encrypting the update package.
  • the package encryption unit 2b encrypts the update package in CTR mode using the generated AES key.
  • the package encryption unit 2b encrypts the counter value by executing AES block encryption processing on the counter value using an AES key.
  • the package encryption unit 2b performs an exclusive OR (XOR) operation on the encrypted counter value and the update package, combines a plurality of encrypted fragments, and generates an update package encrypted with an AES key. Generate.
  • the counter value is, for example, an eight-digit number, and is incremented by "1" for each AES block.
  • the common key encryption unit 2c encrypts the AES key with the RSA public key.
  • the common key storage unit 2d stores the AES key encrypted with the RSA public key in the campaign notification.
  • the encrypted package placement unit 2e places the update package encrypted with the AES key in the CDN8.
  • the campaign notification transmission unit 2f transmits a campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed.
  • the campaign notification transmission unit 2f may deliver the campaign notification to a mobile information terminal such as a smartphone owned by the user.
  • the OTA master 4 includes, as functional blocks related to decryption, a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, and an encrypted package decryption unit 4e. and an installation processing unit 4f.
  • the encrypted package acquisition unit 4c corresponds to an encrypted data acquisition unit.
  • the encrypted package decryption section 4e corresponds to an encrypted data decryption section.
  • Each of the units 4a to 4f is realized by cooperation of hardware and software of a microcomputer having a CPU, RAM, ROM, I/O, and the like.
  • the CPU implements the functions of the OTA master 4 by executing various programs stored in the ROM, including a decryption program, an update data acquisition program, a secret information sharing program, and the like.
  • the common key acquisition unit 4a acquires the encrypted AES key from the acquired campaign notification.
  • the common key decryption unit 4b decrypts the encrypted AES key with the RSA private key to extract the AES key.
  • the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN8.
  • the block cipher processing unit 4d executes the AES block cipher processing of the counter value using the AES key. Encrypt the counter value.
  • the encrypted package decryption unit 4e decrypts the encrypted counter value and the encrypted update package downloaded from the CDN 8 by XOR (Exclusively-OR) operation.
  • the install processing unit 4f transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5.
  • the encryption processing in CTR mode is as shown in FIG. 3, and the decryption processing in CTR mode is as shown in FIG.
  • the disadvantages of the CBC mode are that "preparations for encryption and decryption cannot be performed” and that "parallel processing of encryption cannot be performed”
  • the advantage of the CTR mode is that "preparations before encryption and decryption cannot be performed”. Since preparation is possible, high speed is possible” and "parallel processing of encryption and decryption is possible”. That is, as an advantage of adopting the CTR mode as the encryption mode, as shown in FIG. 6, the throughput is reduced by about 40% compared to the case of adopting the CBC mode of a general block cipher. can be improved.
  • FIG. (1-1) Processing of OTA Center 2 (see FIGS. 9 to 11)
  • the OTA center 2 generates an AES key for encrypting the update package (A011, corresponding to common key generation procedure).
  • the OTA center 2 encrypts the update package in CTR mode with the generated AES key (A012, corresponding to update data encryption procedure).
  • the OTA center 2 encrypts the AES key with the RSA public key (A013, corresponding to common key encryption procedure).
  • the OTA center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A014, corresponding to common key storage procedure).
  • the OTA center 2 places the update package encrypted with the AES key in the CDN 8 (A015, corresponding to the encrypted data placement procedure).
  • Arranging the update package on the CDN8 indicates that the update package is arranged on the origin server of the CDN8.
  • the OTA center 2 transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (corresponding to A016, campaign notification transmission procedure).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B014, block cipher procedure).
  • the OTA master 4 decrypts the encrypted counter value and the encrypted update package downloaded from the CDN 8 by performing an XOR operation (B015, corresponding to the encrypted data decryption procedure).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B016, corresponding to the installation procedure).
  • the decryption process in the target ECU 5 can also be improved in throughput by about 40%. can be done.
  • the configuration adopts the CTR mode as the encryption method and decryption method of the update package.
  • the CTR mode preparation for encryption and decryption can be performed, and parallel processing of encryption and decryption can be performed, as opposed to the conventional one that employs the CBC mode.
  • the OTA master 4 downloads the update package from the OTA center 2, it is possible to enjoy the benefits of the CTR mode and appropriately increase the throughput.
  • FIG. 15 to 26 A second embodiment will be described with reference to FIGS. 15 to 26.
  • OFB mode an output feedback mode
  • the package encryption unit 2b encrypts the update package in OFB mode using the generated AES key.
  • the block encryption processing unit 4d executes IV (Initialization Vector) value-based AES stream encryption processing using the AES key. to encrypt the IV value.
  • An IV value is an initialization vector value, and indicates, for example, a randomly generated bit string.
  • the encrypted package decryption unit 4e decrypts the encrypted IV value and the encrypted update package downloaded from the CDN 8 by performing an XOR operation.
  • the OFB mode encryption process is as shown in FIG. 15, and the OFB mode decryption process is as shown in FIG.
  • the disadvantage of the CBC mode is that "preparations for encryption and decryption cannot be performed” and “parallel processing of encryption cannot be performed”
  • the advantage of the OFB mode is that "preparation before encryption and decryption cannot be performed”. Because it is ready, it can be speeded up.” That is, as an advantage of adopting the OFB mode as the encryption mode, as shown in FIG. 18, the throughput is reduced by about 25% compared to the case of adopting the CBC mode of a general block cipher. can be improved.
  • the decryption process in CTR mode since the input is the counter value, the decryption process can be started before receiving the update package, which is the ciphertext. Also, since there is no mutual dependency, multiple cryptographic operations can be executed in parallel at the same time. On the other hand, as shown in FIG. 20, in OFB mode decryption processing, multiple cryptographic operations cannot be executed in parallel at the same time because of mutual dependencies. However, the process of XORing the encrypted IV value and the encrypted update package and decrypting them can be executed in parallel. Therefore, in decoding processing in OFB mode, the throughput cannot be improved as much as in decoding processing in CTR mode described in the first embodiment. can be done.
  • FIG. (2-1) Processing of OTA Center 2 (See FIGS. 21 to 23)
  • the OTA center 2 generates an AES key for encrypting the update package (A021, corresponding to common key generation procedure).
  • the OTA center 2 encrypts the update package in OFB mode with the generated AES key (A022, corresponding to update data encryption procedure).
  • the OTA center 2 encrypts the AES key with the RSA public key (A023, corresponding to common key encryption procedure).
  • the OTA center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A024, corresponding to common key storage procedure).
  • the OTA center 2 places the update package encrypted with the AES key in the CDN 8 (A025, corresponding to the encrypted data placement procedure).
  • the OTA center 2 transmits the campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (corresponding to A026, campaign notification transmission procedure).
  • the OTA master 4 executes IV value-based AES stream encryption processing using the AES key to encrypt the IV value in parallel with downloading and acquiring the encrypted update package CDN 8 (B024, block cipher procedure).
  • the OTA master 4 decrypts the encrypted IV value and the encrypted update package downloaded from the CDN 8 by performing an XOR operation (B025, corresponding to the encrypted data decryption procedure).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B026, corresponding to the installation procedure).
  • the configuration adopts the OFB mode as the encryption method and the decryption method of the update package.
  • the OFB mode preparation for encryption and decryption can be performed in contrast to the conventional one that adopts the CBC mode.
  • the OTA master 4 downloads the update package from the OTA center 2, it is possible to enjoy the benefits of the OFB mode, and the throughput can be increased appropriately.
  • FIG. The third embodiment adopts a hypertext transfer protocol (hereinafter referred to as HTTP (Hypertext Transfer Protocol)) as a communication protocol between the CDN 8 and the OTA master 4, transmits a range request to the CDN 8, and updates the update package. is downloaded in a streaming manner, the distribution cost is suppressed more than when hypertext transfer protocol secure (hereafter referred to as HTTPS (Hypertext Transfer Protocol Secure)) is adopted.
  • HTTP Hypertext Transfer Protocol Secure
  • the CDN 8 delivery fee is differentiated between when HTTP is used as the communication protocol to the CDN 8 and when HTTPS is used.
  • HTTPS Transaction Layer Security
  • the CDN 8 When using HTTPS, the CDN 8 must perform handshake processing, encryption key exchange processing, and encryption operation processing stipulated by transport layer security (hereinafter referred to as TLS (Transport Layer Security)). Since the processing load on the CPU increases, the delivery charge for HTTPS is approximately 30% higher than that for HTTP. For this reason, the distribution cost can be suppressed by using HTTP for downloading the update package.
  • HTTPS is not used when distributing update packages from the CDN 8 to the vehicle-side system 3 .
  • the campaign notification transmission unit 2f establishes TLS communication between the OTA center 4 and the OTA master 4, and then transmits the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed.
  • the common key acquisition unit 4a acquires the campaign notification from the OTA master 4 when the campaign notification transmitted from the OTA center 2 is received. get the key.
  • the encrypted package acquisition unit 4c transmits a range request to the CDN 8, designates a data range to be downloaded, and downloads and acquires the encrypted update package from the CDN 8 by streaming.
  • the installation processing unit 4f transfers the decrypted update package to the target ECU 5 by streaming, and installs the update package in the target ECU 5.
  • the OTA master 4 acquires the encrypted update package from the CDN 8 by the streaming method. good.
  • the streaming method since header information is included at the time of communication, distribution costs can be further reduced by using HTTP.
  • FIG. (3-1) Processing of OTA Center 2 (see FIGS. 28 to 30)
  • the OTA center 2 generates an AES key for encrypting the update package (A031).
  • the OTA Center 2 encrypts the update package in CTR mode with the generated AES key (A032).
  • the OTA center 2 encrypts the AES key with the RSA public key (A033).
  • the OTA Center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A034).
  • the OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A035).
  • the OTA center 2 transmits a campaign notification containing an encrypted AES key to the vehicle system 3 to be reprogrammed (A036). .
  • the OTA master 4 executes the AES block encryption processing of the counter value using the AES key to obtain the counter value. is encrypted (B034).
  • the OTA master 4 XORs the encrypted counter value and the encrypted update package downloaded from the CDN 8 and decrypts them (B035).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 by streaming, and installs the update package in the target ECU 5 (B036).
  • HTTP is adopted as a communication protocol between the CDN 8 and the OTA master 4, and the OTA master 4 transmits a range request to the CDN 8, thereby downloading the update package from the CDN 8 by streaming.
  • the distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be appropriately reduced compared to the conventional system that employs HTTPS as a communication protocol.
  • FIG. 34 A fourth embodiment will be described with reference to FIGS. 34 to 38.
  • FIG. The fourth embodiment attempts to speed up the decryption process when downloading an update package by performing all keystream calculations in advance in the background before obtaining download consent from the user.
  • the OTA master 4 includes a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, and an encrypted package decryption unit.
  • the key stream calculation unit 4g is provided.
  • the keystream calculation unit 4g performs all keystream calculations in advance in the background before the download consent is obtained from the user.
  • the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8 on condition that the download approval from the user is obtained.
  • the encrypted package decryption unit 4e decrypts the calculated key stream and the encrypted update package downloaded from the CDN 8 by performing an XOR operation.
  • FIG. (4-1) Processing of OTA Center 2 The processing of the OTA center 2 is the same as the processing of the OTA center 2 described in the first embodiment (FIGS. 9 to 11).
  • the OTA master 4 displays the download approval screen on the HMI (Human Machine Interface) by distributing the campaign notification to the vehicle side system 3 and the portable information terminal such as a smartphone owned by the user (B044).
  • the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 on the condition that the download consent is obtained from the user (B045).
  • the OTA master 4 XORs the pre-calculated keystream and the encrypted update package downloaded from the CDN 8 to decrypt (B046).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B047).
  • the following effects can be obtained. All keystream calculations are pre-performed in the background before the user's consent to download is obtained. As a result, it is possible to speed up the decoding process of the update package in the OTA master 4 and increase the throughput when the OTA master 4 downloads the update package from the OTA center 2 .
  • FIG. 39 to 42 A fifth embodiment will be described with reference to FIGS. 39 to 42.
  • FIG. 39 to 42 the fourth embodiment pre-performs all keystream computation in the background before download acceptance is obtained from the user
  • the fifth embodiment performs Perform some keystream computations in advance in the background.
  • a part of the key stream to be calculated is determined in consideration of the memory capacity of the cache memory of the CPU and the throughput of the AES encryption operation, and has a size that can be stored in the cache memory.
  • the keystream calculation unit 4g performs part of the keystream calculation in the background in advance before obtaining the download consent from the user.
  • the keystream calculation unit 4g generates a keystream and adds it to the cache memory in parallel with the encrypted package acquisition unit 4c downloading and acquiring the encrypted update package from the CDN8.
  • FIG. (5-1) Processing of OTA Center 2
  • the processing of the OTA center 2 is the same as the processing of the OTA center 2 described in the first embodiment (FIGS. 9 to 11).
  • the OTA master 4 displays a download approval screen on the HMI by distributing the campaign notification to the vehicle-side system 3 and a portable information terminal such as a smartphone owned by the user (B054).
  • the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 on the condition that the download consent is obtained from the user (B055).
  • the OTA master 4 XORs the pre-calculated keystream and the encrypted update package downloaded from the CDN 8 to decrypt (B056).
  • the OTA master 4 At this time, the OTA master 4 generates a keystream and adds it to the cache memory (B057) in parallel with downloading and acquiring from the encrypted update package CDN8, and calculates the rest of the keystream.
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B058). Note that the relationship between memory capacity and access speed is as shown in FIG. 42, and the size of the cache memory may be determined according to the required access speed.
  • the following effects can be obtained. It is configured so that some keystream calculations are performed in the background in advance before the download consent is obtained from the user. As a result, it is possible to speed up the decoding process of the update package in the OTA master 4 while saving the memory usage of the OTA master 4, and increase the throughput when the OTA master 4 downloads the update package from the OTA center 2. can be enhanced.
  • the OTA master 4 specifies the encryption method by including the encryption method in repro policy metadata (hereinafter referred to as RP metadata) or the like and transmitting it from the OTA center 2 to the OTA master 4.
  • the encryption method transmitted from the OTA center 2 to the OTA master 4 includes encryption algorithm, encryption key length, encryption mode, message authentication code (hereinafter referred to as MAC (Message Authentication Code)) algorithm, and the like.
  • RP metadata includes configuration information of the update package, that is, information representing the configuration type of the update package, and is data for the OTA master 4 to check the data content to prevent delivery errors of the update package.
  • the OTA master 4 may specify the encryption method by including the encryption method in download metadata (hereinafter referred to as DL metadata) or the like and transmitting it from the OTA center 2 to the OTA master 4 .
  • the DL metadata is data that includes information for downloading update packages for each of a plurality of target ECUs 5 and defines the content that the OTA master 4 should grasp.
  • the OTA center 2 includes a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, an encrypted package placement unit 2e,
  • the RP metadata generation unit 2g and the RP metadata encryption unit 2h are provided.
  • the RP metadata generation unit 2g generates RP metadata including the common key cryptosystem.
  • the RP metadata encryption unit 2h encrypts RP metadata with an RSA public key.
  • the OTA master 4 includes a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, and an installation processing unit 4f.
  • it includes an RP metadata acquisition unit 4h, an RP metadata decryption unit 4i, and a common key cryptosystem specification unit 4j.
  • the RP metadata acquisition unit 4h downloads and acquires the encrypted RP metadata from the CDN8.
  • the RP metadata decryption unit 4i decrypts the encrypted RP metadata with the RSA private key and extracts the RP metadata.
  • the common key cryptosystem identification unit 4j interprets the content of the RP metadata and identifies the common key cryptosystem.
  • the flow from the CDN 8 to the distribution of the update package to the OTA center 2 is as follows.
  • a campaign notification is transmitted from the OTA center 2 to the OTA master 4 or the portable information terminal owned by the user.
  • the OTA master 4 accesses the CDN 8 to transmit the RP metadata and the DL metadata from the CDN 8 to the OTA master 4 and distribute the update package from the CDN 8 to the OTA center 2 .
  • the RP metadata and DL metadata are transmitted from the OTA center 2 to the OTA master 4 prior to downloading the update package.
  • the RP metadata includes information of RP metadata version, distribution layer, master layer, and target layer. Each information is as follows.
  • RP metadata version This is the version of the RP metadata, and is version information such as "1.0.0” or "2.0.0".
  • Distribution layer (b-1) Communication protocol A protocol used for communication with the OTA center 2, for example, information indicating Uptane (registered trademark), OMA-DM (Open Mobile Alliance-Device Management), etc. .
  • (b-2) Communication Means This is the distribution route of the update package, and is information indicating the OTA master 4, such as cellular, smart phone, USB memory, and the like.
  • PF Master layer Information about OTA master 4 (c-1) PF
  • AP AUTOSAR Adaptive Platform
  • CP AUTOSAR Classic Platform
  • AGL Automotive Grade Linux
  • Android registered trademark
  • 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.
  • AP and CP indicate software platforms.
  • a software platform is also referred to as a software architecture.
  • the AP and CP use different operating systems and development languages.
  • the structures of receivable update packages differ between an ECU that operates in accordance with the CP specifications and an ECU that operates in accordance with the AP specifications.
  • the difference in the structure of these update packages is mainly due to the difference in processing performance of the ECU.
  • the processing performance of ECUs that operate according to CP specifications is relatively low, so the specification data included in the update package is also written in binary data, so even ECUs with low processing performance can interpret and process it. It has an easy-to-use data structure.
  • Control method Information such as parameters processed according to parameters set according to a specific format, and scripts processed in a more free description format without a specific format.
  • Encryption method Includes encryption algorithm, encryption key length, encryption mode, padding method, encryption key ID, signature algorithm, signature key ID, signature mode, hash algorithm, presence/absence of area specification, offset size, and protected data size Information.
  • Target layer This is information about the target ECU 5 .
  • (d ⁇ 1) PF Similar to the master layer.
  • (d-2) Transfer method Storage method or streaming
  • (d-3) Control method Same as master layer.
  • (d-5) Encryption method Same as the master layer.
  • FIG. (6-1) Processing of OTA Center 2 (see FIGS. 48 to 51)
  • the OTA center 2 generates a common key for encrypting the update package (A061).
  • the OTA center 2 encrypts the update package in a specific encryption mode using the generated common key (A062).
  • the OTA center 2 encrypts the common key with the RSA public key (A063).
  • the OTA center 2 stores the common key encrypted with the RSA public key in the campaign notification (A064).
  • the OTA center 2 generates RP metadata including the common key cryptosystem (A065).
  • the OTA center 2 encrypts the RP metadata with the RSA public key (A066).
  • the OTA center 2 places the update package encrypted with the common key and the RP metadata encrypted with the RSA public key in the CDN 8 (A067).
  • the OTA center 2 transmits the campaign notification in which the encrypted common key is stored to the vehicle-side system 3 to be reprogrammed (A068).
  • the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B066). From this point on, the OTA master 4 performs the processing from step B014 onward described in the first embodiment if the CTR mode is adopted as the specific encryption mode, and if the OFB mode is adopted as the specific encryption mode. If so, the processes after step B024 described in the second embodiment are performed. Similarly, in other encryption modes, the update package is decrypted and the data is transferred to the target ECU according to the procedure corresponding to the encryption mode.
  • the encryption method is included in RP metadata or DL metadata and transmitted from the OTA center 2 to the OTA master 4 . This allows the OTA master 4 to specify the encryption method.
  • FIG. 7 embodiment A seventh embodiment will be described with reference to FIGS. 55 to 67.
  • FIG. The seventh embodiment employs a CCMP mode (Counter mode with Cipher-block chaining Message authentication code Protocol) as a measure against communication path encryption and data tampering.
  • CCMP mode Counter Mode with Cipher-block chaining Message authentication code Protocol
  • the configuration adopting CCMP mode and the conventional method of AES CBC-HMAC (Hashed Message Authentication Mode Code) SHA (Secure Hash Algorithm) 2 decryption and signature verification are adopted.
  • AES CBC-HMAC Hashed Message Authentication Mode Code
  • SHA Secure Hash Algorithm 2 decryption and signature verification
  • the OTA center 2 includes a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, an encrypted package placement unit 2e,
  • the MAC key generation unit 2i is provided.
  • the MAC key generator 2i generates a MAC for preventing tampering with the update package.
  • the OTA master 4 includes a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, and an installation processing unit 4f.
  • a MAC key acquisition unit 4k is provided.
  • the MAC key acquisition unit 4k acquires the MAC key from the acquired campaign notification.
  • FIG. (7-1) Processing of OTA Center 2 (see FIGS. 62 to 64)
  • the OTA center 2 generates an AES key for encrypting the update package and a MAC key for preventing tampering with the update package (A071).
  • the OTA center 2 encrypts the update package in CCMP mode with the generated AES key and MAC key, and assigns a MAC (A072).
  • the OTA center 2 encrypts the AES key and MAC key with the RSA public key (A073).
  • the OTA Center 2 stores the AES key and MAC key encrypted with the RSA public key in the campaign notification (A074).
  • the OTA center 2 places the update package encrypted with the AES key and MAC key on the CDN 8 (A075).
  • the OTA center 2 transmits a campaign notification in which the encrypted AES key and MAC key are stored to the reprogramming target vehicle-side system 3 (A076).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B074). .
  • the OTA master 4 XORs the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt (B075).
  • the OTA master 4 generates and verifies a MAC in AES-CBC mode using the MAC key from the plaintext of the decrypted update package (B076). When the MACs match, the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B077).
  • the OTA master 4 terminates the process if the MACs do not match.
  • the OTA master 4 may record a log indicating that the processing has terminated due to the MAC mismatch, and display an error on the HMI (not shown).
  • the OTA master 4 may decrypt the encrypted update package by XOR operation and transfer the decrypted update package to the target ECU 5 at the same time.
  • the OTA master 4 generates and verifies the MAC in the AES-CBC mode using the MAC key from the plain text of the decrypted update package, and if it determines that the MACs do not match, installs the update package to the target ECU 5. It may be configured to notify the cancellation.
  • the configuration adopts the CCMP mode as a communication path encryption between the OTA center 2 and the OTA master 4 and as a countermeasure against data falsification.
  • the CCMP mode By adopting the CCMP mode, when the OTA master 4 downloads the update package from the OTA center 2, in addition to communication channel encryption, data falsification countermeasures can be provided. As a result, security can be enhanced, and more secure OTA distribution can be realized.
  • FIG. 8 (Eighth embodiment) An eighth embodiment will be described with reference to FIGS. 68 to 77.
  • FIG. The eighth embodiment employs a GCMP mode (Galois/Counter Mode Protocol) as communication path encryption and data falsification countermeasures.
  • GCMP mode Galois/Counter Mode Protocol
  • the processing time of the hardware accelerator is more dominant than the processing time of the main core, but the throughput can be further improved by adopting the GCMP mode.
  • FIG. (8-1) Processing of OTA Center 2 (see FIGS. 72 to 74)
  • the OTA center 2 generates an AES key for encrypting the update package and a MAC key for preventing tampering with the update package (A081).
  • the OTA center 2 encrypts the update package in GCMP mode with the generated AES key and MAC key, and gives it a MAC (A082).
  • the OTA center 2 encrypts the AES key and MAC key with the RSA public key (A083).
  • the OTA Center 2 stores the AES key and MAC key encrypted with the RSA public key in the campaign notification (A084).
  • the OTA center 2 places the update package encrypted with the AES key and MAC key on the CDN 8 (A085).
  • the OTA center 2 transmits a campaign notification in which the encrypted AES key and MAC key are stored to the reprogramming target vehicle-side system 3 (A086).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B084). .
  • the OTA master 4 XORs the encrypted counter value and the encrypted update package downloaded from the CDN 8 and decrypts them (B085).
  • the OTA master 4 generates and verifies a MAC in GMAC mode using the MAC key from the decrypted plaintext of the update package (B086). When the MACs match, the OTA master transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B087).
  • the GCMP mode is adopted as a communication channel encryption between the OTA center 2 and the OTA master 4 and as a countermeasure against data falsification.
  • the GCMP mode when the OTA master 4 downloads the update package from the OTA center 2, in addition to communication channel encryption, data falsification countermeasures can be provided. As a result, security can be enhanced, and more secure OTA distribution can be realized.
  • FIG. 8 A ninth embodiment will be described with reference to FIGS. 78 to 86.
  • FIG. The ninth embodiment adopts not only the CDN 8 but also a smartphone, a USB memory, etc. as the distribution route of the update data, and by supporting the diversity of the distribution routes, increases the flexibility of the OTA update method for the user.
  • a smart phone or a USB memory corresponds to a recording medium.
  • a smart phone and a USB memory will be exemplified as storage media, but an SD card, a micro SD card, a compact flash, or the like may be used as the storage media.
  • FIG. (9-1) Processing of OTA Center 2 (see FIGS. 79 to 82)
  • the OTA center 2 generates a common key for encrypting the update package (A091).
  • the OTA center 2 encrypts the update package in a specific encryption mode using the generated common key (A092).
  • the OTA center 2 encrypts the common key with the RSA public key (A093).
  • the OTA center 2 stores the common key encrypted with the RSA public key in the campaign notification (A094).
  • the OTA center 2 generates RP metadata including the common key cryptosystem and distribution route (A095).
  • the OTA Center 2 encrypts the RP metadata with the RSA public key (A096).
  • the OTA center 2 places the update package encrypted with the common key and the RP metadata encrypted with the RSA public key on the CDN 8 (A097).
  • the OTA center 2 transmits a campaign notification in which the encrypted common key is stored to the vehicle-side system 3 to be reprogrammed (A098).
  • the OTA master 4 acquires the encrypted update package through the identified distribution route (B096). That is, when the OTA master 4 specifies the smartphone as the distribution route, the OTA master 4 downloads the encrypted update package from the CDN 8 via the smartphone in a batch storage method. When the OTA master 4 specifies the USB memory as the distribution route, the OTA master 4 downloads the encrypted update package from the CDN 8 via the USB memory in a batch storage method. From this point on, the OTA master 4 performs the processing from step B014 onward described in the first embodiment if the CTR mode is adopted as the specific encryption mode, and if the OFB mode is adopted as the specific encryption mode. If so, the processes after step B024 described in the second embodiment are performed.
  • the update package is obtained from the CDN 8 via a recording medium such as a smartphone or a USB memory. It is possible to diversify the distribution routes of update packages, and to select distribution routes that are superior in distribution cost and usability. As a result, the distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be appropriately suppressed, and the user experience value can be improved.
  • the OTA master 4 interprets the contents of the RP metadata in step B095 to specify the common key encryption method and distribution route, but the RP metadata describes a plurality of distribution routes. In some cases, it may be possible to select one of a plurality of delivery routes.
  • FIG. 87 A tenth embodiment will be described with reference to FIGS. 87 to 98.
  • FIG. 87 a plurality of CDN vendors are dynamically selected as destinations of the update package in the CDN 8 according to the distribution method, the OTA target area, which is the distribution area, and the distribution data size, thereby suppressing the distribution cost.
  • CDN cost comparisons are shown in FIGS. 88-89.
  • the price tables are as shown in FIGS. 90-93.
  • Each CDN vendor has different price advantages and disadvantages depending on the distribution area such as Japan and North America, the distribution data size, etc. For example, referring to FIG. However, CDN1 is the cheapest in North America and the EU. Based on this fact, the CDN vendor with the lowest distribution cost is selected according to the distribution method, OTA target area, and distribution data size.
  • the OTA center 2 includes a common key generation unit 2a, an update package encryption unit 2b, a common key encryption unit 2c, a common key storage unit 2d, an encrypted package placement unit 2e,
  • the CDN vendor selection unit 2j is provided.
  • the CDN vendor selection unit 2j selects a CDN vendor by referring to the CDN vendor management database.
  • FIG. (10-1) Processing of OTA Center 2 (see FIGS. 95 to 98)
  • the OTA center 2 generates an AES key for encrypting the update package (A101).
  • the OTA Center 2 encrypts the update package in CTR mode with the generated AES key (A102).
  • the OTA center 2 encrypts the AES key with the RSA public key (A103).
  • the OTA Center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A104).
  • the OTA center 2 identifies the distribution method (A105), identifies the OTA target area (A106), identifies the distribution data size (A107), and selects the distribution method, OTA target area, and distribution data size from the CDN vendor management database.
  • the price table is referred to as a key (A108).
  • the OTA center 2 uses at least one of the distribution method such as the storage method and the streaming method, the OTA target area such as Japan, North America, and the EU (European Union), and the distribution data size such as GB, TB, and PB as a key.
  • the OTA center 2 selects a CDN vendor with the lowest distribution cost for each area, and places the update package encrypted with the AES key on the selected CDN 8 (A109, corresponding to CDN vendor selection procedure). Alternatively, the OTA center 2 may place update packages encrypted with an AES key on each CDN 8 . The OTA center 2 sends an encrypted AES key and a campaign notification containing the update package data storage location and URI information so that the selected CDN vendor can be accessed, to the reprogramming target vehicle-side system 3 ( A110).
  • a CDN 8 with a superior distribution cost is selected from multiple CDNs 8 with different distribution costs according to the distribution method, OTA target area, and distribution data size, and the update package is placed on the selected CDN 8. It was configured to The distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be suppressed appropriately.
  • the update package at the OTA center 2 in principle, even if the intermediate route is zero trust, there is no security problem. For this reason, there is no need to encrypt the update data on the edge side of the CDN 8, and the processing load and security functions of the CDN 8 can be reduced.
  • the OTA system Until the update package reaches the OTA master 4 from the OTA center 2, even if the data is falsified or the CDN 8 is attacked by DDoS on the way, the OTA system will not be affected, and the system intervening on the way will have intelligent security. Countermeasures such as a web application firewall, TLS communication, and signed URLs that limit the OTA masters 4 to be distributed can be made unnecessary. As a result, the running cost of the OTA system can be reduced on a cost basis, and the distribution cost can be suppressed in any system configuration.
  • FIG. The eleventh embodiment uses Diffie-Hellman key exchange (hereinafter referred to as DHE (Diffie-Hellman key exchange) or elliptic curve Diffie-Hellman key exchange (hereinafter referred to as DHE) for key distribution between the OTA center 2 and the OTA master 4.
  • DHE Diffie-Hellman key exchange
  • DHE elliptic curve Diffie-Hellman key exchange
  • ECDHE Elliptic curve Diffie-Hellman key exchange
  • An update package applicable to each vehicle model or specific vehicle group applicable to the CDN 8 is delivered while enjoying the advantage of being able to ensure forward secrecy.
  • the private key and public key pair (a/A, b/B) can be destroyed after sharing the secret information (S), and both the OTA center 2 and the OTA master 4 are HSM (Hardware Security Module).
  • secret information (S) can be shared very securely because it does not need to be stored in the This shared secret information (S) can be used as a key for common key cryptography or the like.
  • FIG. (11-1) Processing of OTA Center 2 (see FIGS. 101 to 104)
  • the OTA center 2 generates an AES key for encrypting the update package (A111).
  • the OTA Center 2 encrypts the update package in CTR mode with the generated AES key (A112).
  • the OTA center 2 generates an ECDHE key pair from the random number (A113).
  • the OTA center 2 shares a secret key with the OTA master 4 using the ECDHE algorithm (A114, corresponding to secret information sharing procedure).
  • the OTA center 2 encrypts the AES key with the secret key (A115).
  • the OTA Center 2 stores the AES key encrypted with the private key in the campaign notification (A116).
  • the OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A117).
  • the OTA center 2 transmits a campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A118, corresponding to encryption key distribution procedure).
  • step A114 will be explained.
  • the OTA master 4 inquires the program version of the ECU installed in the vehicle and collects the vehicle configuration information.
  • the OTA master 4 receives a push notification regarding the campaign from the OTA center 2, it inquires the ECU about the program version and collects the vehicle configuration information.
  • the OTA master 4 establishes TLS communication with the OTA center 2 and transmits the vehicle configuration information to the OTA center 2 .
  • the OTA master 4 collects vehicle configuration information and generates an ECDHE key pair. Send to OTA Center 2.
  • the process of collecting vehicle configuration information by the OTA master 4 is also applied to other embodiments. Based on the public key of the OTA master 4 obtained from the OTA master 4 and the secret key of the OTA center 2, the OTA center 2 obtains a secret key in the ECDHE algorithm.
  • the OTA master 4 (11-2) Processing of OTA master 4 (see FIGS. 105 to 108)
  • the OTA master 4 generates an ECDHE key pair from random numbers (B111).
  • the OTA master 4 shares a secret key with the OTA center 2 using the ECDHE algorithm (B112, corresponding to secret information sharing procedure).
  • the OTA master 4 receives the campaign notification sent from the OTA center 2 and acquires the campaign notification, the OTA master 4 acquires the AES key from the acquired campaign notification (B113).
  • the OTA master 4 decrypts the encrypted AES key with the private key and extracts the AES key (B114).
  • the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B115).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B116). .
  • the OTA master 4 XORs the encrypted counter value and the encrypted update package downloaded from the CDN 8 and decrypts them (B117).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B118).
  • DHE or ECDHE is adopted for key distribution between the OTA center 2 and the OTA master 4, and the OTA center 2 encrypts the AES key based on secret information shared by each vehicle and distributes it to the OTA master 4. and As a result, the forward secrecy of ECDHE can be appropriately ensured, and efficient distribution of update data by the CDN 8 can be appropriately realized.
  • FIG. 11th embodiment A modification of the eleventh embodiment will be described with reference to FIGS. 166 to 173.
  • FIG. The eleventh embodiment has been described on the assumption that the vehicle is equipped with a wireless communication device and the OTA master 4 can transmit and receive data to and from the OTA center 2 and the CDN 8 via a wireless communication line. However, there are cases where the vehicle is not equipped with a wireless communication device or the user does not like to use the wireless communication line.
  • the OTA master 4 does not transmit/receive data to/from the OTA center 2 or the CDN 8 via a wireless communication line, but instead uses a storage medium such as an SD card to update the program. explain.
  • the OTA master 4 and OTA center 2 use storage media for data transfer with the outside.
  • Data transfer between the OTA master 4 and the storage medium uses the port for the storage medium installed in the vehicle.
  • the ports installed in the vehicle are, for example, ports installed in a car navigation device, a center display device, and other vehicle control devices.
  • Data transfer between the OTA center 2 and the storage medium is performed by connecting the storage medium to a personal computer (hereinafter referred to as PC).
  • PC personal computer
  • the stored data is downloaded to the storage medium by operating the PC.
  • a smart phone, tablet terminal, or the like that supports storage media can be used instead of the PC.
  • PCs, smartphones, tablet terminals, etc. that support storage media are also referred to as operation terminals.
  • FIG. 1 A case where an SD card is used as a storage medium will be described with reference to FIGS. 166 to 169.
  • FIG. 1 data is transferred from the OTA master 4 to the SD card 11, data is uploaded from the SD card 11 to the OTA center 2, data is downloaded from the OTA center 2 to the SD card 11, and from the SD card 11 to the OTA master 4. are processed in the order of data transfer.
  • the transfer of data from the OTA master 4 to the SD card 11 will be described with reference to FIG.
  • the OTA master 4 acquires software version information and the like from the target ECU 5 and transfers and stores the acquired software version information and the like to the SD card 11 as vehicle configuration information.
  • the OTA master 4 generates an ECDHE key pair from random numbers, transfers the ECDHE public key to the SD card 11, and stores it.
  • the SD card 11 stores the vehicle configuration information transferred from the OTA master 4 and the ECDHE public key of the OTA master 4 .
  • the uploading of data from the PC to which the SD card 11 is connected to the OTA center 2 will be described with reference to FIG.
  • the PC reads the vehicle configuration information stored in the SD card 11 and the ECDHE public key of the OTA master 4, and transmits the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA.
  • the vehicle configuration information uploaded to the OTA center 2 is used by the PKG generation server 6 to determine whether there is a campaign.
  • the ECDHE public key of the OTA master 4 uploaded to the OTA center 2 shares a secret key in the distribution server 7 based on the ECDHE algorithm.
  • the secret key in this case is a different secret key for each vehicle.
  • the OTA center 2 downloads the update package encrypted with the AES key to the SD card 11 and stores it.
  • the OTA center 2 generates an ECDHE key pair from random numbers, downloads a key to be shared with the OTA master 4 (ECDHE public key of the OTA center 2 ) to the SD card 11 , and stores it.
  • the OTA center 2 downloads and saves the campaign notification storing the encrypted AES key to the SD card 11.
  • the SD card 11 stores the update package downloaded from the OTA center 2, the ECDHE public key of the OTA center 2 and the encrypted AES key.
  • the transfer of data from the SD card 11 to the OTA master 4 will be described with reference to FIG.
  • the OTA master 4 reads the encrypted update package stored in the SD card 11, the ECDHE public key of the OTA center 2, and the encrypted AES key from the SD card 11 to acquire them.
  • FIG. (11-3) OTA master 4 processing (see FIG. 170)
  • the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information.
  • Configuration information such as information is acquired as vehicle configuration information (B1111).
  • the OTA master 4 transfers and stores the acquired vehicle configuration information to the SD card 11 (B1112).
  • the OTA master 4 generates an ECDHE key pair from the random number (B1113).
  • the key pair includes the ECDHE public key and the ECDHE private key of the OTA master 4 .
  • the OTA master 4 transfers and stores the ECDHE public key of the OTA master 4 to the SD card 11 (B1114).
  • the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.
  • the OTA center 2 (11-5) Processing of OTA Center 2 (see FIG. 172)
  • the OTA center 2 generates an AES key for encrypting the update package, and encrypts the update package with the AES key in CTR mode.
  • the OTA center 2 acquires the vehicle configuration information uploaded from the PC to which the SD card 11 is connected and the ECDHE public key of the OTA master 4 (A1111).
  • the OTA center 2 determines whether there is a campaign based on the vehicle configuration information (A1112). When the OTA center 2 determines that there is no campaign (A1112: NO), it transmits a no-campaign notification to the PC (A1113) and terminates the process.
  • the OTA center 2 determines that there is a campaign (A1112: YES), it generates an ECDHE key pair from random numbers (A1114).
  • the key pair is the OTA Center 2's ECDHE public key and ECDHE private key.
  • the OTA center 2 downloads and stores the ECDHE public key of the OTA center 2 to the SD card 11 (A1115).
  • the OTA center 2 generates an ECDHE common key (secret key) from the ECDHE secret key of the OTA center 2 and the ECDHE public key of the OTA master 4 (A1116), and encrypts the AES key with the generated ECDHE common key (secret key). (A1117).
  • the OTA center 2 stores the encrypted AES key in the campaign notification, and downloads and saves the campaign notification containing the encrypted AES key to the SD card 11 (A1118).
  • the OTA center 2 downloads and stores the encrypted update package in the SD card 11 (A1119).
  • OTA master 4 processing (see FIG. 173)
  • the OTA master 4 acquires the ECDHE public key of the OTA center 2, the campaign notification, and the update package from the SD card 11 (B1121).
  • the OTA master 4 generates an ECDHE common key (secret key) from the ECDHE secret key of the OTA master 4 and the ECDHE public key of the OTA center 2 (B1122).
  • the OTA master 4 extracts the encrypted AES key from the campaign notification and decrypts it using the ECDHE common key (secret key) (B1123).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B1124).
  • the OTA master 4 decrypts the encrypted counter value and the encrypted update package by XOR operation (B1125).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B1126).
  • the random number a generated by the OTA center 2 is a random number for each vehicle model (random number according to a specific rule), and the random number b generated by the OTA master 4 is a vehicle model.
  • the secret key shared by the ECDHE is made common to each vehicle model by using either one of the fixed value, the count-up value, or the hash value of the software version of the OTA master 4, or a combination thereof, and the ECDHE While enjoying the advantage of ensuring forward secrecy, the process of distributing the key is omitted, and the encrypted package applicable to each vehicle model or specific vehicle group is distributed by CDN.
  • FIG. (12-1) Processing of OTA Center 2 (See FIGS. 110 to 112)
  • the OTA center 2 generates an ECDHE key pair from random numbers common to each vehicle model or each vehicle group (A121).
  • the OTA center 2 shares a secret key with the OTA master 4 using the ECDHE algorithm (A122, corresponding to secret information sharing procedure).
  • A122 corresponding to secret information sharing procedure
  • a secret key shared with the OTA master 4 by the ECDHE algorithm is used as an AES key for encrypting the update package.
  • the OTA Master 4 uses the private key shared with the OTA Center 2 as an AES key to decrypt the encrypted update package.
  • the OTA Center 2 generates an AES key for encrypting the update package (A123).
  • the OTA Center 2 encrypts the update package in CTR mode with the generated AES key (A124).
  • the OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A125).
  • the OTA center 2 transmits a campaign notification in which the encrypted AES key is stored to the vehicle-side system 3 to be reprogrammed (A126, corresponding to encryption key distribution procedure).
  • the OTA master 4 (12-2) Processing of OTA master 4 (see FIGS. 113 to 115)
  • the OTA master 4 generates an ECDHE key pair from random numbers generated according to the specific rules described above (B121).
  • the OTA center 2 shares the secret key with the OTA center 2 using the ECDHE algorithm (B122, corresponding to secret information sharing procedure).
  • the OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B123).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B124). .
  • the OTA master 4 XORs the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt (B125).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B126).
  • DHE or ECDHE is adopted for key distribution between the OTA center 2 and the OTA master 4, and the secret key shared by ECDHE is made common for each vehicle model.
  • the forward secrecy of ECDHE can be appropriately ensured, and the efficient distribution of update data by the CDN 8 can be appropriately realized while simplifying the time and effort of key distribution compared to the eleventh embodiment.
  • the transfer of data from the OTA master 4 to the SD card 11 will be described with reference to FIG.
  • the OTA master 4 acquires software version information and the like from the target ECU 5 and transfers and stores the acquired software version information and the like to the SD card 11 as vehicle configuration information.
  • the OTA master 4 uses either one of a fixed value for each vehicle model, a count-up value, or a hash value of the software version of the OTA master 4, or a combination thereof to create an ECDHE key pair common to each vehicle model. , and a key to be shared with the OTA center 2 (ECDHE public key of the OTA master 4) is transferred to the SD card 11 and stored.
  • the SD card 11 stores the vehicle configuration information transferred from the OTA master 4 and the ECDHE public key of the OTA master 4 .
  • the uploading of data from the PC to which the SD card 11 is connected to the OTA center 2 will be described with reference to FIG.
  • the PC reads the vehicle configuration information stored in the SD card 11 and the ECDHE public key of the OTA master 4, and transmits the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA.
  • the vehicle configuration information uploaded to the OTA center 2 is used by the PKG generation server 6 to determine whether there is a campaign.
  • the ECDHE public key of the OTA master 4 uploaded to the OTA center 2 shares a secret key in the distribution server 7 based on the ECDHE algorithm.
  • the secret key in this case is a secret key common to each vehicle model.
  • the OTA center 2 generates an ECDHE key pair from random numbers common to each vehicle model or vehicle group, and downloads the key to be shared with the OTA master 4 (ECDHE public key of the OTA center 2) to the SD card 11. to save.
  • the OTA center 2 encrypts the update package by using the secret key shared by ECDHE as an AES key, downloads the encrypted update package to the SD card 11, and stores it.
  • the SD card 11 stores the ECDHE public key of the OTA center 2 downloaded from the OTA center 2 and the update package.
  • the transfer of data from the SD card 11 to the OTA master 4 will be described with reference to FIG.
  • the OTA master 4 reads and obtains the encrypted update package stored in the SD card 11 and the ECDHE public key of the OTA center 2 .
  • the OTA masters 4 share a secret key based on the ECDHE algorithm.
  • the OTA master 4 uses the secret key shared by ECDHE as an AES key to decrypt the encrypted update package.
  • FIG. (12-3) OTA master 4 processing (see FIG. 178)
  • the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information.
  • Configuration information such as information is acquired as vehicle configuration information (B1211).
  • the OTA master 4 transfers and stores the acquired vehicle configuration information to the SD card 11 (B1212).
  • the OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B1213).
  • the key pair includes the ECDHE public key and the ECDHE private key of the OTA master 4 .
  • the OTA master 4 transfers and stores the ECDHE public key of the OTA master 4 to the SD card 11 (B1214).
  • the ECDHE key pair is a random number generated according to a specific rule as in the twelfth embodiment, and is common to each vehicle model.
  • the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.
  • the OTA center 2 acquires the vehicle configuration information uploaded from the PC to which the SD card 11 is connected and the ECDHE public key of the OTA master 4 (A1211). The OTA center 2 determines whether there is a campaign based on the vehicle configuration information (A1212). When the OTA center 2 determines that there is no campaign (A1212: NO), the OTA center 2 transmits a no-campaign notification to the PC (A1213) and terminates the process.
  • the OTA center 2 determines that there is a campaign (A1212: YES), it generates an ECDHE key pair from random numbers common to each vehicle model or each vehicle group (A1214).
  • the key pair is the OTA Center 2's ECDHE public key and ECDHE private key.
  • the OTA center 2 downloads and stores the ECDHE public key of the OTA center 2 to the SD card 11 (A1215).
  • the OTA center 2 generates an ECDHE common key (secret key) from the ECDHE secret key of the OTA center 2 and the ECDHE public key of the OTA master 4 (A1216), and encrypts the update package with the generated ECDHE common key (secret key). (A1217).
  • the OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1218).
  • the OTA master 4 acquires the ECDHE public key and update package of the OTA center 2 from the SD card 11 (B1221).
  • the OTA master 4 generates an ECDHE common key (private key) from the ECDHE private key of the OTA master 4 and the ECDHE public key of the OTA center 2 (B1222).
  • the OTA master 4 encrypts the counter value by executing AES block encryption processing on the counter value using the AES key (B1223).
  • the OTA master 4 decrypts the encrypted counter value and the encrypted update package by XOR operation (B1224).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B1225).
  • FIG. 13th embodiment The thirteenth embodiment will be described with reference to FIGS. 116 to 124.
  • FIG. The thirteenth embodiment does not simply apply the CTR mode, but makes it more secure by devising counter values. Specifically, the CTR mode is made safer by inserting a nonce into the campaign notification first communicated between the OTA center 2 and the OTA master 4 and inserting the nonce into the counter value.
  • FIG. 117 shows the encryption process that inserts the CTR mode nonce
  • FIG. 118 shows the decryption process that inserts the CTR mode nonce.
  • FIG. (13-1) Processing of OTA Center 2 (see FIGS. 119 to 121)
  • the OTA center 2 generates an AES key for encrypting the update package (A131).
  • the OTA center 2 generates a nonce with random numbers (A132).
  • the OTA Center 2 encrypts the update package in CTR mode with the generated AES key and nonce (A133).
  • the OTA center 2 encrypts the AES key with the RSA public key (A134).
  • the OTA center 2 may encrypt the AES key with the RSA public key and at the same time encrypt the nonce with the RSA public key.
  • the OTA Center 2 stores the AES key and nonce encrypted with the RSA public key in the campaign notification (A135).
  • the OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A136).
  • the OTA center 2 transmits the campaign notification in which the encrypted AES key and nonce are stored to the reprogramming target vehicle-side system 3 (A137).
  • a configuration is adopted in which a nonce is included in the campaign notification first communicated between the OTA center 2 and the OTA master 4, and the nonce is included in the counter value.
  • the CTR mode can be made safer by incorporating the nonce into the counter value.
  • the fourteenth embodiment will be described with reference to FIGS. 125 to 132.
  • the key used for encryption is not a common key for all vehicles in order to narrow the range of influence when the key is compromised, but a derivative that is individualized for each specific vehicle group unit.
  • the use of keys localizes the loss in the event of key compromise while maintaining CDN 8 distribution cache efficiency, resulting in more secure OTA distribution.
  • the VIN number is divided into a plurality of divisions for the same vehicle model and model year, and a different AES individual key is used for each division.
  • VIN numbers AAA to CCC, VIN numbers DDD to KKK, and VIN numbers SSS to ZZZ are used, and different AES individual keys are used.
  • the individual key database contains, for example, AES individual keys separated by OEM code, vehicle model, year, AES master key, seed value, and VIN number.
  • FIG. (14-1) Processing of OTA Center 2 (see FIGS. 127 to 129)
  • the OTA center 2 generates an AES individual key for encrypting the update package from the AES master key and seed value (A141).
  • a seed value is, for example, a random number, a counter value, a time stamp, or the like.
  • the OTA Center 2 encrypts the update package in CTR mode with one of the generated AES individual keys and the nonce (A142).
  • the OTA center 2 encrypts the AES individual key with the RSA public key (A143).
  • the OTA Center 2 stores the AES individual key and nonce encrypted with the RSA public key in the campaign notification (A144).
  • the OTA center 2 places the update package encrypted with one of the AES individual keys and the nonce on the CDN 8 (A145).
  • the OTA center 2 transmits the campaign notification containing the encrypted AES individual key and nonce to the reprogramming target vehicle system 3 (A146).
  • the fourteenth embodiment the following effects can be obtained.
  • the key used for encryption instead of using a common key for all vehicles, a configuration is adopted in which a derived key that is individualized for each specific vehicle group is used. Loss during key compromise can be localized while maintaining CDN 8 delivery cache efficiency. As a result, it is possible to improve security when the OTA master 4 downloads the update package from the OTA center 2, thereby realizing more secure OTA distribution.
  • FIG. 15th embodiment The fifteenth embodiment will be described with reference to FIGS. 133 to 137.
  • FIG. 1 in preparation for the worst case of leakage of the private key, a key version is assigned so that the key can be updated OTA, and the OTA center 2 manages the key update key.
  • the OTA center 2 manages version information of the RSA public key used to encrypt the AES key and the RSA private key used to decrypt it. By managing the version information, downgrading is prevented when updating the RSA private key and the RSA public key.
  • the OTA center 2 and the OTA master 4 each have a key update key used for updating the secret key.
  • a new private key pair is generated, a key update package is generated using the key update key, and the key update package is transmitted to the OTA master 4, so that the secret Implement key rekeying.
  • FIG. 15-1) Processing of OTA Center 2 (see FIGS. 134 to 135)
  • the OTA center 2 generates a new key pair of a new RSA private key and a new RSA public key (A151).
  • the OTA center 2 encrypts the generated new RSA private key with the key update key in CTR mode and performs MAC operation to generate a key update package (A152).
  • the OTA center 2 switches the old RSA public key to the new RSA public key (A153).
  • the OTA center 2 transmits the key update package to the vehicle-side system 3 to be reprogrammed (A154).
  • the OTA master 4 acquires the key update package, decrypts the new RSA private key with the key update key in CTR mode, and performs MAC verification (B151).
  • the OTA master 4 switches the old RSA private key to the decrypted new RSA private key (B152).
  • a new private key pair is generated when the private key is leaked or at regular intervals, and a key update package is generated using the key for key update, and the key update package is transmitted to the OTA master 4 .
  • security can be improved when the OTA master 4 downloads the update package from the OTA center 2, and more secure OTA distribution can be realized.
  • FIG. 139 to 140 DHE is vulnerable to attacks from intermediary attackers, but by adding a digital signature, it is counteracted by attacks from intermediary attackers.
  • a digital signature a digital signature using an encryption algorithm of RSA or elliptic curve DSA is used.
  • FIG. (16-1) Processing of OTA Center 2 (see FIGS. 141 to 143)
  • the OTA center 2 generates an ECDHE key pair from random numbers generated for each vehicle model or each vehicle group (A161).
  • the OTA center 2 gives a digital signature to the ECDHE key with the RSA private key (A162).
  • the RSA private key is used here, it is not limited to the RSA private key, and any public key cryptosystem can be used as an alternative, such as an ECDSA (Elliptic Curve Digital Signature Algorithm) private key.
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • the OTA center 2 shares a secret key with the OTA master 4 using the ECDHE algorithm (A164).
  • the OTA Center 2 generates an AES key for encrypting the update package (A165).
  • the OTA Center 2 encrypts the update package in CTR mode with the generated AES key (A166).
  • the OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A167).
  • the OTA center 2 transmits the campaign notification in which the encrypted AES key is stored to the reprogramming target vehicle-side system 3 (A168).
  • the OTA master 4 (16-2) Processing of OTA master 4 (see FIGS. 144 to 145)
  • the OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B161).
  • the OTA master 4 verifies the digital signature of the ECDHE public key received from the OTA center 2 with the RSA public key (B162). Also here, as in the OTA center 2, it is not limited to the RSA public key, and any public key cryptosystem can be used as an alternative. For example, the ECDSA public key may be used. If the verification result is positive, the OTA master 4 shares the secret key with the OTA center 2 using the ECDHE algorithm (B163). After that, the OTA master 4 performs the processes after step B113 described in the eleventh embodiment.
  • a digital signature is added in ECDHE key sharing.
  • attacks from intermediate attackers can be countered, and more secure OTA distribution can be realized.
  • FIG. 16th embodiment A modification of the sixteenth embodiment will be described with reference to FIGS. 182 to 189.
  • FIG. In the modified example of the sixteenth embodiment, similarly to the modified examples of the eleventh and twelfth embodiments, the OTA master 4 does not transmit/receive data to/from the OTA center 2 or the CDN 8 via a wireless communication line. A situation in which program update is performed using a storage medium such as an SD card will be described.
  • the main difference between the modified example of the 16th embodiment and the modified example of the 12th embodiment is that the ECDHE public key of the OTA center 2 is given a digital signature with the key of the public key cryptosystem to prevent an attack from an intermediary attacker. It is in the point of opposing to.
  • data is transferred from the OTA master 4 to the SD card 11
  • data is uploaded from the PC connected to the SD card 11 to the OTA center 2
  • data is transferred from the OTA center 2 to the SD card 11.
  • Downloading and transfer of data from the SD card 11 to the OTA master 4 are shown.
  • the main difference from the modified example of the twelfth embodiment is that, as shown in FIG. , for example, a digital signature is given with an RSA private key or an ECDSA private key.
  • the OTA center 2 transfers the signed ECDHE public key to the SD card 11 and stores it.
  • the OTA master 4 reads the signed ECDHE public key from the SD card 11 and verifies it using the RSA public key stored in the vehicle-side system 3 .
  • FIG. (16-3) OTA master 4 processing (see FIG. 186)
  • the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information.
  • Configuration information such as information is acquired as vehicle configuration information (B1611).
  • the OTA master 4 transfers and stores the acquired vehicle configuration information to the SD card 11 (B1612).
  • the OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B1613). In this case, the key pair includes the ECDHE public key and the ECDHE private key of the OTA master 4 .
  • the OTA master 4 transfers and stores the ECDHE public key of the OTA master 4 to the SD card 11 (B1614).
  • the ECDHE key pair is a random number generated according to a specific rule as in the twelfth embodiment, and is common to each vehicle model.
  • the SD card 11 is disconnected from the vehicle system 3 and connected to the PC.
  • the process ends.
  • the OTA center 2 acquires the vehicle configuration information uploaded from the PC to which the SD card 11 is connected and the ECDHE public key of the OTA master 4 (A1611). The OTA center 2 determines whether there is a campaign based on the vehicle configuration information (A1612). When the OTA center 2 determines that there is no campaign (A1612: NO), it sends a no-campaign notification to the PC (A1613) and terminates the process.
  • the OTA center 2 determines that there is a campaign (A1612: YES), it generates an ECDHE key pair from random numbers common to each vehicle model or vehicle group (A1614).
  • the key pair is the OTA Center 2's ECDHE public key and ECDHE private key.
  • the OTA center 2 signs the ECDHE public key of the OTA center 2 with the RSA private key (A1615), and downloads and stores the signed ECDHE public key of the OTA center 2 to the SD card 11 (A1616).
  • the OTA center 2 generates an ECDHE common key (secret key) from the ECDHE secret key of the OTA center 2 and the ECDHE public key of the OTA master 4 (A1617), and encrypts the update package with the generated ECDHE common key (secret key). (A1618).
  • the OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1619).
  • the OTA master 4 acquires the signed ECDHE public key of the OTA center 2 and the update package from the SD card 11 (B1621).
  • the OTA master 4 verifies the signed ECDHE public key of the OTA center 2 with the RSA public key (B1622).
  • the OTA master 4 determines whether or not the verification result is normal (B1623), and if it determines that the verification result is abnormal (B1623: NO), it notifies an error (B1624).
  • the OTA master 4 determines that the verification result is normal (B1623: YES), it generates an ECDHE common key (private key) from the ECDHE private key of the OTA master 4 and the ECDHE public key of the OTA center 2 (B1625).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B1626).
  • the OTA master 4 decrypts the encrypted counter value and the encrypted update package by XOR operation (B1627).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B1628).
  • FIG. 17th embodiment The seventeenth embodiment will be described with reference to FIGS. 146 to 151.
  • FIG. in the tenth embodiment a CDN vendor with the lowest distribution cost is selected for each area from among a plurality of CDN vendors. This configuration is statically selected. Specifically, the tenth embodiment encrypts the update package at the OTA center 2 and minimizes the distribution cost according to the distribution method, OTA target area, and distribution data size. , the update package is not encrypted at the OTA center 2, and the communication between the CDN 8 and the OTA master 4 is protected by TLS communication, and the distribution cost is minimized according to the distribution method, OTA target area, and distribution data size.
  • FIG. (17-1) Processing of OTA Center 2 (see FIGS. 147 to 148)
  • the OTA center 2 identifies the distribution method (A171), identifies the OTA target area (A172), identifies whether TLS is used as the communication protocol for the vehicle (A173), and identifies the distribution data size (A174).
  • the price table is referred to from the CDN vendor management database using the delivery method, OTA target area, communication protocol and delivery data size as keys (A175).
  • the OTA center 2 may refer to the price table using at least one of the distribution method, OTA target area, communication protocol, and distribution data size as a key.
  • the OTA center 2 selects a CDN vendor with the lowest distribution cost for each area, and places the update package on the selected CDN 8 (A176).
  • the OTA center 2 transmits the campaign notification to the reprogramming target vehicle system 3 (A177).
  • the OTA master 4 acquires the campaign notification by receiving the campaign notification transmitted from the OTA center 2 (B171).
  • the OTA master 4 establishes TLS communication with the CDN vendor listed in the campaign notification to obtain the update package (B172). It should be noted that the information of the CDN vendor may not be described as long as the URI information is described in the campaign notification.
  • the OTA master 4 exchanges the AES common key using the TLS communication protocol. It negotiates to select the AES-CTR mode as the encryption mode.
  • the OTA master 4 downloads and acquires the update package encrypted with the TLS AES common key from the CDN 8 based on the URI information (B173, corresponding to update data acquisition procedure).
  • the OTA master 4 encrypts the counter value by executing AES block cipher processing on the counter value using the AES key (B174). .
  • the OTA master 4 XORs the encrypted counter value and the encrypted update package downloaded from the CDN 8 and decrypts them (B175).
  • the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B176).
  • the update package is not encrypted at the OTA center 2, and the communication between the CDN 8 and the OTA master 4 is protected by TLS communication, and the distribution cost is minimized according to the distribution method, OTA target area, communication protocol, and distribution data size. It was configured to As a result, the distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be suppressed appropriately.
  • FIG. The 18th embodiment selects the optimal CDN vendor based on comprehensive consideration of not only the distribution cost but also the throughput and response delay time of the CDN vendor, and periodically updates the price table and quality characteristics of the CDN vendor. check, keep the CDN vendor management database up-to-date, and always select the CDN vendor with the most competitive advantage in the market.
  • the price tables are as shown in FIGS. 153 to 160, and the quality information of each cloud service provider is as shown in FIG. As shown in FIG.
  • CDN vendor B when comparing CDN vendor A and CDN vendor B, CDN vendor B is superior to CDN vendor A in terms of distribution cost, but in terms of throughput weighting and response delay time weighting CDN Vendor A dominates CDN Vendor B.
  • CDN Vendor A dominates CDN Vendor B.
  • the throughput and response delay time of the CDN vendor should be comprehensively considered, not CDN vendor B, which is superior only in terms of distribution cost. It is possible to draw the conclusion that the superior CDN vendor A should be selected.
  • FIG. (18-1) Processing of OTA Center 2 (see FIGS. 163 to 165)
  • the OTA center 2 identifies the distribution method (A181), identifies the OTA target area (A182), and refers to the price table from the CDN vendor management database using the distribution method and OTA target area as keys (A183).
  • the OTA center 2 may refer to the price table using at least one of the distribution method and the OTA target area as a key.
  • the OTA Center 2 identifies the quality characteristics of each CDN vendor from the CDN vendor management database (A184).
  • the OTA center 2 selects the optimal CDN vendor for each area from the CDN vendor selection logic registered in the CDN vendor selection logic database based on the distribution cost and quality characteristics of the CDN vendor for each area, and encrypts with the AES key.
  • the selected update package is placed in the selected CDN8 (A185).
  • the OTA center 2 transmits a campaign notification in which the encrypted AES key is stored to the reprogramming target vehicle-side system 3 (A186).
  • the OTA Center 2 automatically acquires the price table of each CDN vendor from the website and updates the CDN vendor management database (A187).
  • the OTA center 2 measures the throughput and response delay time of each CDN vendor and updates the CDN vendor management database (A188).
  • the distribution server 7 periodically visits each CDN vendor's website and downloads the latest price table.
  • the distribution server 7 downloads the latest price table by registering with the distribution service.
  • the following effects can be obtained.
  • We select the most suitable CDN vendor by comprehensively considering not only the distribution cost but also the throughput and response delay time of the CDN vendor, regularly check the price table and quality characteristics of the CDN vendor, and always We kept our administrative database up-to-date and always chose the most competitive CDN vendors in the market. As a result, the distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be suppressed appropriately.
  • CDN quality characteristics are not limited to throughput and response delay time, but content cache hit ratios and past trouble records can also be considered, and these can be included in the CDN vendor management database. It is possible. It is also possible to regularly review the addition or deletion of CDN vendors to which the OTA center 2 is connected, and to connect with CDN vendors that are competitive in the market.
  • FIG. 90 The nineteenth embodiment will be described with reference to FIGS. 90 and 190 to 193.
  • FIG. The tenth embodiment described above has a configuration in which a CDN vendor with the lowest distribution cost is selected for each area from a plurality of CDN vendors.
  • selection of a CDN vendor will be specifically described.
  • the distribution cost is determined according to the distribution data size, the OTA target area (sometimes referred to as a region) that is a distribution area, and the distribution method from among a plurality of CDN vendors as the location of the update package on the CDN 8. Dynamically select the smallest CDN vendor.
  • the nineteenth embodiment will be described with reference to the price table illustrated in FIG. 90 described above.
  • the price table may have a format different from that of FIG.
  • the distribution server 7 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, and a CDN distribution unit 7d.
  • the CDN vendor selection unit 7a selects a CDN vendor based on selection information and update package information that are necessary for selecting a CDN vendor.
  • the selection information includes information on the data size of the target campaign, the number of vehicles targeted for distribution of the target campaign, the region, the distribution method, and the like.
  • the data storage unit 7b stores campaign information as well as identification information that can identify the CDN vendor selected by the CDN vendor selection unit 7a.
  • the identification information includes, for example, the name of the CDN vendor, an identification number identifying the CDN vendor, or a URL indicating the CDN vendor.
  • the campaign notification generation unit 7c acquires information from the data storage unit 7b and generates campaign notifications to be distributed to vehicles and the like.
  • the CDN distribution unit 7d has a storage area corresponding to each CDN vendor.
  • the storage areas comprise storage area A, storage area B, and storage area C.
  • Each storage area of the CDN distribution unit 7d and the CDN server are synchronized. That is, the CDN distribution unit 7d arranges the data in the storage area A and transfers the data to the CDN server A, for example, when distributing the data from the CDN server A to the vehicle-side system 3 .
  • the CDN server A distributes the transferred data to the vehicle-side system 3 when the data is transferred from the CDN distribution unit 7d.
  • Each storage area of the CDN distribution unit 7d may be called an origin server of each CDN server.
  • FIG. 19 Note that processing such as encryption of the update package by the OTA center 2 is the same as in the tenth embodiment or other embodiments. Also, the processing of the OTA master 4 is the same as in the first embodiment or other embodiments. In the nineteenth embodiment, selection of a CDN vendor will be mainly described.
  • the campaign notification generator 7c acquires campaign information from an external source such as an OEM server (A191).
  • the campaign information includes information on the data size of the target campaign, the number of vehicles targeted for distribution of the target campaign, the region, and the distribution method.
  • the campaign notification generation unit 7c stores the acquired campaign information in the data storage unit 7b (A192). Storing the campaign information may be referred to as deploying the campaign information.
  • the campaign notification generation unit 7c notifies the CDN vendor selection unit 7a of the CDN vendor selection request (A193), and waits for acquisition of the selection notification from the CDN vendor selection unit 7a.
  • the campaign notification generation unit 7c acquires the selection notification from the CDN vendor selection unit 7a (A194)
  • the campaign notification generation unit 7c accesses the data storage unit 7b and acquires the identification information of the CDN vendor selected by the CDN vendor selection unit 7a (A195 ).
  • the campaign notification generation unit 7c generates a parameter file containing the URL of the selected CDN based on the identification information of the CDN vendor as a campaign notification (A196).
  • the campaign notification generator 7c distributes the generated campaign notification to the vehicle system 3 (A197).
  • the CDN vendor selection unit 7a When the CDN vendor selection unit 7a starts the first CDN selection process, it calculates the distribution data size indicating the data size distributed from the CDN server to the update target vehicle (A1921). Specifically, the CDN vendor selection unit 7a multiplies the data size of the target campaign by the number of vehicles targeted for delivery of the target campaign, and calculates the distribution data size scheduled to be distributed from the CDN server.
  • the CDN vendor selection unit 7a repeats the subsequent processing for each CDN vendor (A1922 to A1929).
  • the CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the previously calculated distribution data size and region information regarding the region (A1923). For example, in the case of a 30 TB campaign targeting North America, the CDN vendor selection unit 7a acquires charge information for " ⁇ 10 TB" and " ⁇ 40 TB" in the "North America" region. Charge information may be acquired for all data sizes.
  • the CDN vendor selection unit 7a refers to the charge information based on the distribution data size and calculates the distribution billing amount (A1924).
  • the calculation of the distribution charge amount may differ for each CDN vendor, and is determined by the distribution charge amount calculation method of the CDN vendor. For example, when calculating the distribution billing amount for CDN1 in the price table of FIG. 90, if the region is "North America" and the distribution data size is 30 TB, the price tables for " ⁇ 10 TB" and " ⁇ 40 TB" are referenced.
  • the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests (A1925). When the CDN vendor selection unit 7a determines that the CDN vendor does not charge according to the number of requests (A1925: NO), the CDN vendor selection unit 7a determines the distribution charge amount as the charge amount of the CDN vendor (A1928). After completing the billing amount calculation, calculate the billing amount of the next CDN vendor.
  • the CDN vendor selection unit 7a determines that the CDN vendor charges according to the number of requests (A1925: YES), it calculates the number of requests (A1926).
  • the number of requests varies depending on the delivery method. If the delivery method is the storage method, the number of requests is the number of vehicles targeted for campaign delivery. If the distribution method is the streaming method, divide the data size of the target campaign by the chunk size at the time of streaming and multiply by the number of vehicles targeted for distribution of the campaign to calculate the number of requests.
  • the CDN vendor selection unit 7a calculates a billing amount (sometimes referred to as request billing amount) based on the calculated number of requests (A1927).
  • the request charge amount is the charge amount per request multiplied by the number of requests.
  • the CDN vendor selection unit 7a determines the sum of the distribution charge amount and the request charge amount as the charge amount of the CDN vendor (A1928), finishes calculating the charge amount for the CDN vendor under consideration, and proceeds to the next step. Calculate the billing amount of the CDN vendor.
  • the CDN vendor selection unit 7a calculates the billing amount for all CDN vendors, The CDN vendor with the lowest distribution cost, that is, the CDN vendor with the lowest billing amount is selected (A1930), and the first CDN selection process ends. After completing the first CDN selection process, the CDN vendor selection unit 7a stores the selection result, that is, the identification information of the selected CDN vendor in the data storage unit 7b (A1914), and notifies the campaign notification generation unit 7c of the selection result. (A1915).
  • the distribution server 7 refers to the CDN vendor management DB, selects a CDN 8 with a superior distribution cost from a plurality of CDNs 8 with different distribution costs according to the distribution method, OTA target area, and distribution data size, and distributes the update package to the relevant CDN 8. It was configured to be placed in the selected CDN8. As a result, the distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be suppressed appropriately.
  • FIG. A first modification of the nineteenth embodiment uses a DNS (Domain Name System) server so that the URL of the CDN server included in the campaign notification delivered to the vehicle-side system 3 is not changed.
  • the CDN vendor with the lowest distribution cost is selected for each campaign.
  • the campaign notification includes the URL of the CDN server. Therefore, when the CDN vendor with the lowest distribution cost is changed, the URL described in the campaign notification is changed.
  • the campaign notification generation unit 7c needs to access the data storage unit 7b and acquire information on the CDN vendor each time a campaign notification is generated.
  • the DNS setting unit 7e updates the conversion information between the URL and the IP address registered in the DNS, so that the campaign notification generation unit 7c always describes the same URL in the campaign notification. can be done.
  • the vehicle-side system 3 can access the selected CDN server by changing the information of the DNS server 12 .
  • each CDN server has a unique IP address and a unique URL.
  • each CDN server has a unique IP address, but the CDN servers have a common URL.
  • the distribution server 7 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, and a CDN distribution unit 7d. , and a DNS setting unit 7e. Differences from the nineteenth embodiment will be mainly described below.
  • the DNS server 12 is a server that provides a mechanism for converting domain names and IP addresses.
  • the campaign notification received by the vehicle-side system 3 includes the URL of the CDN server accessed to download the data.
  • the vehicle-side system 3 inquires of the DNS server 12 about the URL indicated in the received campaign notification.
  • the DNS server 12 transmits the IP address corresponding to the URL for which the inquiry was obtained to the vehicle-side system 3, or transfers the connection destination to the address specified by the IP address.
  • the DNS setting unit 7e stores identification information and IP addresses of CDN vendors.
  • the DNS setting unit 7e transmits an IP address setting request to the DNS server 12 and sets registration information in DNS.
  • the DNS setting unit 7e acquires the information of the DNS server 12 or saves the previous setting information to the DNS server 12, and the CDN server registered in the DNS server 12 and the CDN vendor selection unit 7a select The IP address update request may be sent to the DNS server 12 if the DNS server is different from the CDN server.
  • the campaign notification generation unit 7c generates a campaign notification including the fixed URL when receiving the selection notification from the CDN vendor selection unit 7a.
  • the CDN URL information included in the campaign notification can always be the same, and security can be enhanced.
  • the DNS server 12 checks the delivery status of the CDN server, If it is determined that the distribution is not possible, the IP address of the CDN server with the next lowest distribution cost is answered to the vehicle side system 3 .
  • the distribution server 7 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, a CDN distribution unit 7d, a DNS
  • a performance measurement unit 7f is provided in addition to the setting unit 7e.
  • the DNS server 12 has a CDN server confirmation unit 12a.
  • a test file for measuring the performance of the CDN server is arranged in the storage area of the CDN distribution unit 7d.
  • the performance measurement unit 7f transmits a test file distribution request to the CDN server, causes the CDN server to distribute the test file, and measures the time required to distribute the test file as the distribution time.
  • the delivery time is, for example, the time from when the delivery of the test file is started to when the completion of reception of the test file is specified.
  • the CDN vendor management DB has a CDN server selection table, as shown in FIG.
  • the selection table includes cost rankings determined by the CDN vendor selection unit 7a and distribution flags determined by the performance measurement unit 7f.
  • the performance measurement unit 7f calculates the response speed from the time required to distribute the test file for each CDN server, and inputs the determination result based on the calculated response speed into the selection table.
  • the performance measuring unit 7f sets the distribution flag of the CDN server to ON (TRUE) when the response speed is equal to or higher than the specified value, and turns off (TRUE) the distribution flag of the CDN server when the response speed is less than the specified value. FALSE).
  • the CDN server confirmation unit 12a determines whether or not the CDN server designated by the URL is ready for distribution when receiving an inquiry about the IP address corresponding to the URL from the vehicle-side system 3, and determines whether the distribution is possible. When determined, the IP address of another CDN server is answered.
  • FIG. (19-4) Processing of CDN vendor selection unit 7a (see FIGS. 198 to 199)
  • the CDN vendor selection unit 7a calculates the billing amount for each CDN vendor (A1921 to A1929), and determines the cost order of the CDN vendors (A1951). That is, the CDN vendor selection unit 7a determines the CDN vendor with the lowest distribution cost as the first rank, and the CDN vendor with the next lowest distribution cost as the second rank.
  • the CDN vendor selection unit 7a saves the selection result in the data storage unit 7b (A1914), it saves the cost ranking in the selection table of the CDN vendor management DB (A1941).
  • the performance measuring unit 7f repeats the subsequent processing for each CDN vendor (A1961 to A1966).
  • the performance measuring unit 7f executes the following processes at regular intervals while the distribution server 7 is running or at arbitrary timing by the administrator of the distribution server 7. FIG.
  • the performance measurement unit 7f accesses the CDN server (A1962) and transmits a test file distribution request to the CDN server.
  • the performance measuring unit 7f calculates the response speed based on the time required to distribute the test file, and determines whether or not the calculated response speed is equal to or higher than a prescribed value (A1963).
  • the time required for distribution may be compared with a specified value without calculating the response speed, or the distribution data size per unit time may be compared with a specified value.
  • the performance measurement unit 7f determines that the response speed is equal to or higher than the specified value (A1963: YES), it determines that the CDN server is a server that can be used for distribution, and sets the distribution flag to ON (A1964). When the performance measurement unit 7f determines that the calculated response speed is less than the specified value (A1963: NO), it determines that the CDN server is a server that cannot be used for distribution, and sets the distribution flag to OFF. (A1965).
  • the campaign notification indicates the URL to access to download the update data.
  • the vehicle-side system 3 inquires of the DNS server 12 about the IP address to access to download the update package.
  • the CDN server confirmation unit 12a obtains an inquiry about the IP address of the URL indicated in the campaign notification from the vehicle system 3 (A1971).
  • the CDN server confirmation unit 12a inquires the CDN vendor management DB of the distribution server 7 about the distribution status of the CDN server indicated by the campaign notification (A1972).
  • the CDN server corresponds to the CDN vendor scheduled to acquire the data
  • the distribution status corresponds to the distribution flag.
  • the CDN server confirmation unit 12a acquires the distribution flag of the CDN vendor scheduled for data acquisition from the delivery server, it determines whether the CDN vendor scheduled for data acquisition is available (A1973). That is, the CDN server confirmation unit 12a determines whether the acquired distribution flag is ON or OFF.
  • the CDN server confirmation unit 12a determines that the distribution flag is on (A1973: YES)
  • the CDN server confirmation unit 12a determines that the distribution flag is off (A1973: NO)
  • the CDN vendor with the next highest cost order is set as the CDN vendor with the next highest priority
  • the CDN vendor with the next highest priority is set as the CDN vendor with the next highest priority. It is set as the CDN vendor scheduled to be acquired (A1975), and the process returns to step A1973.
  • the CDN server confirmation unit 12a may access the CDN vendor management DB and request transmission of the selection table every time a certain period of time elapses.
  • the selection table held by the CDN server confirmation unit 12a is referred to and used by the CDN vendor scheduled to acquire data. It may be determined whether or not it is possible.
  • communication between the DNS server 12 and the distribution server 7 can be reduced while suppressing the distribution cost as much as possible.
  • FIG. 7 In the third modification, in the distribution server 7, the performance measurement unit 7f measures and evaluates the performance of the CDN server based on the log information from the vehicle-side system 3.
  • FIG. The operation when the DNS server 12 receives an IP address inquiry for a URL from the vehicle-side system 3 is the same as in the second modification.
  • the CDN vendor management DB in the third modification also has a selection table.
  • the vehicle-side system 3 includes a log transmission unit 3a. After completing the download of the update data from the CDN server, the log transmission unit 3a transmits the log information related to the download, including the download time indicating the time required for the download, to the performance measurement unit 7f of the distribution server 7.
  • the log information related to the download may include information such as identification information of the downloaded package, data size, maximum throughput during download, etc., in addition to the download time.
  • the performance measurement unit 7f When the performance measurement unit 7f receives the log information about the download from the log transmission unit 3a, it calculates the throughput from the download time, and inputs the determination result based on the calculated throughput into the selection table.
  • the performance measuring unit 7f sets the distribution flag of the CDN server to ON (TRUE) when the throughput is equal to or higher than the specified value, and turns off (FALSE) the distribution flag of the CDN server when the throughput is less than the specified value. set to
  • FIG. (19-8) Processing of log transmission unit 3a (see FIG. 203) After completing the download of the update package from the CDN server (A1981), the log transmission unit 3a transmits log information related to the download including the download time indicating the time required for the download to the distribution server 7 (A1982).
  • the performance measurement unit 7f determines that the calculated throughput is equal to or greater than the specified value (A1993: YES), it determines that the CDN server is a server that can be used for distribution, and sets the distribution flag to ON (A1994 ). When the performance measurement unit 7f determines that the calculated throughput is less than the specified value (A1993: NO), it determines that the CDN server is a server that cannot be used for distribution, and sets the distribution flag to OFF ( A1995).
  • the performance determination unit 7f periodically performs restoration processing of the CDN server whose distribution flag is turned off.
  • the performance measurement unit 7f notifies the CDN vendor management DB of the information request of the CDN server whose distribution flag is set to OFF, identifies the CDN server whose distribution flag is set to OFF (A19101),
  • the subsequent processing is repeated (A19102 to A19107).
  • the performance measuring unit 7f executes the subsequent processes at regular intervals or at arbitrary timings by the administrator of the distribution server 7 while the distribution server 7 is running.
  • the performance measuring unit 7f notifies the CDN server of the test file distribution request, calculates the throughput from the download time of the file distributed from the CDN server (A19103), and determines whether the calculated throughput is equal to or greater than the specified value. Judge (A19104).
  • the performance measurement unit 7f determines that the calculated throughput is equal to or greater than the specified value (A19104: YES), it changes the distribution flag from off to on (A19105). When the performance measurement unit 7f determines that the calculated throughput is less than the specified value (A19104: NO), it keeps the distribution flag off (A19106). Note that the performance measuring unit 7f may turn on the distribution flag that is set to off in the CDN vendor management DB when the system of the distribution server is started or at predetermined intervals.
  • the campaign notification distributed from the distribution server 7 may include the URL of a backup CDN server to be connected when the throughput of this CDN server is low.
  • the spare CDN server is, for example, a CDN server with the next lowest distribution cost or a pre-determined spare CDN server.
  • the vehicle-side system 3 measures the throughput and checks whether or not a throughput equal to or higher than the specified value is obtained.
  • the vehicle and both sides system 3 determines that a throughput equal to or higher than the specified value is not obtained, it inquires the DNS server 12 about the IP address of the backup CDN server indicated in the campaign notification, change the connection to a different CDN server. Since identification information is added to each packet of the distributed data, even if the CDN server is changed during the download of the update package, the update package can be continuously downloaded.
  • FIG. 207 A fourth modification of the nineteenth embodiment will be described with reference to FIGS. 206 to 207.
  • a round robin system is adopted to designate different CDN servers.
  • the campaign notification generation unit 7c acquires the CDN vendor information (A195), it generates a campaign notification for each CDN vendor (A19111). That is, the campaign notification generation unit 7c generates two or more campaign notifications for one campaign.
  • the campaign notification generation unit 7c distributes the campaign notification so that the CDN server changes in the round robin method (A19112). For example, when two CDN servers CDN11 and CDN12 are selected, the campaign notification generation unit 7c distributes the campaign notification including the URL of the CDN11 to the first vehicle when distributing the campaign notification, and distributes the campaign notification to the next vehicle.
  • a campaign notification including the URL of the CDN 12 is delivered to the next vehicle, and a campaign notification including the URL of the CDN 11 is delivered to the next vehicle.
  • the CDN vendor selection unit 7a selects the CDN vendor with the lowest distribution cost in the nineteenth embodiment, but selects a plurality of CDN vendors in descending order of distribution cost in the fourth modification (A19121).
  • FIG. A fourth modification selects a plurality of CDN vendors to suppress distribution costs, generates a plurality of campaign notifications with different CDN server information, and sends campaign notifications to the vehicle side so that the CDN server is changed in a round-robin manner. It is distributed to system 3.
  • the fifth modification selects a plurality of CDN vendors that suppress distribution costs, generates one campaign notification, and distributes it to the vehicle-side system 3 .
  • the DNS server 12 acquires an inquiry about the IP address corresponding to the URL indicated in the campaign notice from the vehicle side system 3, the CDN server that responds to the vehicle side system 3 is changed for each vehicle side system 3. In other words, the DNS server 12 selects CDN servers in a round-robin fashion.
  • the DNS server 12 has a switching unit 12b. Upon receiving an IP address inquiry from the vehicle system 3, the switching unit 12b sequentially changes the IP address to be answered to the vehicle system 3 in a round-robin manner.
  • the distribution server has a DNS setting unit 7e.
  • the DNS setting unit 7e of the fifth modification transmits the round robin records shown in FIG. 209 to the DNS server 12.
  • the CDN vendor selection unit 7a selects a plurality of CDN vendors in descending order of distribution cost (A19121) and sets a round robin record (A19131) as in the fourth modification.
  • FIG. 212 to 224 A twentieth embodiment will be described with reference to FIGS. 212 to 224.
  • FIG. 212 to 224 A twentieth embodiment will be described with reference to FIGS. 212 to 224.
  • FIG. 212 to 224 A twentieth embodiment will be described with reference to FIGS. 212 to 224.
  • FIG. 212 to 224 A twentieth embodiment will be described with reference to FIGS. 212 to 224.
  • FIG. 212 to 224 when information about multiple campaigns in a predetermined period can be acquired, multiple CDN vendors are selected as locations to place update packages in the CDN 8 according to the distribution method, the OTA target area, which is the distribution area, and the distribution data size. to control distribution costs.
  • the predetermined period is, for example, the next month.
  • the CDN vendor with the lowest distribution cost is selected for one campaign.
  • campaigns may be registered from the OEM server for a given period of time, for example, multiple campaigns scheduled to start distribution in the next month.
  • a CDN vendor is selected for each campaign as in the 19th embodiment.
  • a different CDN vendor may be the CDN vendor with the lowest delivery costs.
  • the OTA center 2 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, a CDN distribution unit 7d, and a progress information management unit 7g.
  • the progress information management unit 7g holds a predicted value indicating how much of the campaign will be distributed to the vehicle-side system 3 within a predetermined period. Even if the campaign is registered in the OTA center 2 and the campaign notification is delivered to the vehicle-side system 3, not all vehicles immediately apply the campaign and download the update package from the CDN server.
  • the progress information management unit 7g saves a predicted value in order to more accurately predict the distribution data size of the update package from the CDN server to the vehicle-side system 3.
  • the predetermined period is described as one month, but other periods may be used.
  • the billing amount of the CDN vendor is calculated by three calculation methods as described later.
  • the first calculation method selects the CDN vendor with the lowest delivery cost for each campaign. In this case, different CDN vendors may be selected for each campaign.
  • FIG. 213 illustrates a case where CDN1 is selected for campaign 1, CDN2 is selected for campaign 2, and CDN3 is selected for campaign 3.
  • FIG. 213 illustrates a case where CDN1 is selected for campaign 1, CDN2 is selected for campaign 2, and CDN3 is selected for campaign 3.
  • the total distribution data size of all campaigns is calculated, and the CDN vendor with the lowest distribution cost is selected based on the calculated total distribution data size of all campaigns. In this case, select the same CDN vendor for all campaigns.
  • FIG. 213 illustrates a case where CDN1 is selected for campaigns 1-3.
  • the distribution total data size of the campaign for each distribution method is calculated, and the CDN vendor with the lowest distribution cost is selected based on the calculated total distribution data size of the campaign for each distribution method.
  • CDN vendors are selected for each of the streaming method and the storage method for each distribution method.
  • FIG. 213 illustrates a case where campaign 1 and campaigns 2 and 3 have different distribution methods, CDN1 is selected for campaign 1 and CDN2 is selected for campaigns 2 and 3.
  • FIG. (20-1) Processing of Campaign Notification Generation Unit 7c (See FIG. 214)
  • the campaign notification generation unit 7c acquires campaign information scheduled to be distributed from outside such as an OEM server, for example, from an OEM server (A201).
  • the campaign information to be distributed includes information on the distribution start date, the data size of the target campaign, the number of vehicles targeted for distribution of the target campaign, the region, and the distribution method.
  • the campaign notification generation unit 7c stores the acquired campaign information in the data storage unit 7b (A202).
  • the campaign notification generation unit 7c notifies the CDN vendor selection unit 7a of the CDN vendor selection request (A203), and waits for acquisition of the selection notification from the CDN vendor selection unit 7a.
  • the campaign notification generation unit 7c acquires the selection notification from the CDN vendor selection unit 7a (A204)
  • the campaign notification generation unit 7c accesses the data storage unit 7b and acquires the identification information of the CDN vendor selected by the CDN vendor selection unit 7a (A205 ).
  • the campaign notification generation unit 7c generates a parameter file containing the URL of the selected CDN based on the identification information of the CDN vendor as a campaign notification to be distributed (A206).
  • the campaign notification generation unit 7c distributes the generated campaign notification scheduled to be distributed to the vehicle-side system 3 (A207).
  • the selection information is acquired (A2012).
  • the selection information includes information on the data size of all target campaigns to be distributed, the number of target vehicles for distribution, the region, the distribution method, and the distribution start date of each campaign.
  • the CDN vendor selection unit 7a acquires the predicted delivery value from the progress information management unit 7g (A2013).
  • the CDN vendor selection unit 7a calculates the distribution data size for each campaign (A2014). Specifically, the CDN vendor selection unit 7a multiplies the data size of the campaign, the number of vehicles targeted for distribution of the campaign, and the predicted distribution value, and further multiplies by a correction value according to the distribution period.
  • the distribution period may be short, such as when the distribution start date is set at the end of next month. Therefore, the correction value is adjusted according to the distribution period. For example, if the delivery start date is delayed and the delivery period is only 10 days, 0.3 or the like is set as the correction value because 10 days out of 30 days are the delivery period.
  • the CDN vendor selection unit 7a shifts to the second CDN selection process (A2015).
  • the CDN vendor selection unit 7a sequentially shifts to the charge amount calculation process by the first calculation method, the charge amount calculation process by the second calculation method, and the charge amount calculation process by the third calculation method. (A2021 to A2023).
  • the CDN vendor selection unit 7a selects the CDN vendor with the lowest distribution cost for each campaign in the process of calculating the billing amount by the first calculation method.
  • the subsequent processing is repeated for each campaign (A2031 to A2041), and further repeated for each CDN vendor (A2032 to A2039).
  • the CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the distribution data size and region information (A2033).
  • the CDN vendor selection unit 7a refers to the charge information based on the distribution data size, and calculates the distribution billing amount (A2034).
  • the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount of the CDN vendor (A2035 ⁇ A2038). The CDN vendor selection unit 7a repeats the calculation of the distribution billing amount for each CDN vendor and each campaign. After calculating the billing amounts of all CDN vendors for one campaign, the CDN vendor selection unit 7a selects the CDN vendor with the lowest distribution cost for that campaign (A2040).
  • the CDN vendor selection unit 7a When the CDN vendor selection unit 7a completes the calculation of the distribution charge amount and the selection of the CDN vendor for all campaigns, it totals the distribution charge amount of all the campaigns, calculates the total amount (A2042), and uses the first calculation method. , and shifts to the calculation process of the charge amount by the second calculation method.
  • the CDN vendor selection unit 7a selects one CDN vendor based on the total distribution data size of all campaigns scheduled to be distributed in the process of calculating the billing amount by the second calculation method.
  • the CDN vendor selection unit 7a starts the billing amount calculation processing by the second calculation method, it totals the distribution data size of each campaign to calculate the distribution total data size (A2051), and performs the subsequent processing for each CDN vendor. (A2052 to A2059).
  • the CDN vendor selection unit 7a acquires charge information from the CDN vendor management DB based on the distribution total data size and region information (A2053).
  • the CDN vendor selection unit 7a refers to the charge information based on the total distribution data size, and calculates the charge for distribution (A2054).
  • the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount of the CDN vendor (A2055 ⁇ A2058).
  • the CDN vendor selection unit 7a repeats the calculation of the delivery billing amount for each CDN vendor.
  • the CDN vendor selection unit 7a selects a CDN vendor with the lowest distribution cost (A2060). Add up the distribution billing amounts of all campaigns to be distributed, calculate the total amount (A2061), end the billing amount calculation processing by the second calculation method, and shift to the billing amount calculation processing by the third calculation method. .
  • the CDN vendor selection unit 7a selects a CDN vendor after summarizing campaigns for each distribution method in the process of calculating the billing amount by the third calculation method.
  • the CDN vendor selection unit 7a starts the process of calculating the billing amount by the third calculation method, it determines whether or not the distribution methods of the campaigns to be distributed are all the same (A2071).
  • the CDN vendor selection unit 7a determines that all the campaigns to be distributed have the same distribution method, that is, all the campaigns to be distributed are of the streaming method or all of them are the storage method (A2071: YES), the above-mentioned Since it is the same as the billing amount calculation processing by the second calculation method, the billing amount calculation processing by the third calculation method ends.
  • the campaigns to be distributed include both the streaming method and the storage method (A2071: NO)
  • the campaigns are grouped according to the distribution method. (A2072), the streaming method group is shifted to the streaming method billing amount calculation process (A2073), and the storage method group is shifted to the storage method billing amount calculation process (A2074).
  • the CDN vendor selection unit 7a When the CDN vendor selection unit 7a starts the charging amount calculation processing in the streaming method, it calculates the total value of the distribution data size of each campaign distributed in the streaming method (A2081), and repeats the subsequent processing for each CDN vendor. (A2082-A2089).
  • the CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total distribution data size and the region information (A2083).
  • the CDN vendor selection unit 7a refers to the fee information based on the total value of the distribution data size, and calculates the distribution billing amount (A2084).
  • the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount of the CDN vendor (A2085 ⁇ A2088). The CDN vendor selection unit 7a repeats the calculation of the delivery billing amount for each CDN vendor. The CDN vendor selection unit 7a selects a CDN vendor that minimizes the delivery cost in the streaming method (A2090), and terminates the billing amount calculation processing in the streaming method.
  • the CDN vendor selection unit 7a when the CDN vendor selection unit 7a starts the billing amount calculation processing in the storage method, it calculates the total value of the distribution data size of each campaign distributed in the storage method (A2091), and performs the subsequent processing for each CDN vendor. (A2092 to A2099).
  • the CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total distribution data size and the region information (A2093).
  • the CDN vendor selection unit 7a refers to the fee information based on the total value of the distribution data size, and calculates the distribution billing amount (A2094).
  • the CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests, and determines the charge amount of the CDN vendor (A2095 ⁇ A2098). The CDN vendor selection unit 7a repeats the calculation of the delivery billing amount for each CDN vendor. The CDN vendor selection unit 7a selects a CDN vendor that minimizes the distribution cost in the storage method (A20100), and terminates the billing amount calculation processing in the storage method.
  • the CDN vendor selection unit 7a calculates the minimum delivery cost.
  • a method is determined (A2024), a CDN vendor for each campaign is selected (A2025), and the second CDN selection process ends.
  • the CDN vendor selection unit 7a saves the selection result, that is, the identification information for identifying the selected CDN vendor in the data storage unit 7b (A2016).
  • the CDN vendor selection unit 7a stores the identification information for identifying the CDN vendor of the campaign to be distributed in the data storage unit 7b.
  • the CDN vendor selection unit 7a notifies the campaign notification generation unit 7c of the selection notification (A2017).
  • the progress information management unit 7g stores a predicted value indicating how many campaigns will be delivered to the vehicle system 3 in a predetermined period. It is assumed that this predicted value is updated according to the actual distribution status transmitted from the OEM server.
  • the progress information management unit 7g acquires the distribution status from the OEM server (A20111). The progress information management unit 7g determines whether or not the difference between the distribution status and the stored predicted value is equal to or greater than a predetermined value (A20112). When the progress information management unit 7g determines that the difference between the delivery status and the stored predicted value is not equal to or greater than the predetermined value (A20112: NO), the process ends.
  • the progress information management unit 7g determines that the difference between the distribution status and the stored predicted value is equal to or greater than the predetermined value (A20112: YES)
  • the progress information management unit 7g updates the saved predicted value (A20113), is updated to the CDN vendor selection unit 7a (A20114).
  • the progress information management unit 7g may have one prediction value common to all campaigns, or may have different prediction values for each campaign, each vehicle to be updated, or each type of campaign.
  • the CDN vendor selection unit 7a shifts to the second CDN selection process (A20125), and upon completion of the second CDN selection process, determines whether or not there is a change in the CDN vendor (A20126).
  • the CDN vendor selection unit 7a determines that there is no change in the CDN vendor (A20126: NO)
  • the process ends. If there is a change in the CDN vendor, the selection result in the data storage unit 7b is updated.
  • the CDN vendor selection unit 7a determines that there is a change in the CDN vendor (A20126: YES)
  • the CDN vendor selection unit 7a may check at predetermined intervals whether or not the predicted value stored in the progress information management unit 7g has been changed.
  • a CDN 8 with a superior distribution cost is selected from multiple CDNs 8 with different distribution costs according to the distribution method, OTA target area, and distribution data size, and the update package is placed on the selected CDN 8. It was configured to The distribution cost when the OTA master 4 downloads the update package from the OTA center 2 can be suppressed appropriately.
  • the campaign notification is transmitted from the OTA center 2 to the OTA master 4 after TLS communication is established.
  • the campaign notification may be sent from the OTA center 2 to the OTA master 4 after TLS communication is established. Security can be further enhanced by establishing TLS communication.
  • the campaign notification may be sent from the OTA center 2 to the OTA master 4 without establishing TLS communication.
  • the vehicle-side system 3 of this embodiment may have the following configuration.
  • the vehicle-side system 3 may include a DCM (Data Communication Module) and a CGW (Central Gateway), and the DCM and CGW may be connected via a bus so as to be capable of data communication.
  • CGW is also called central ECU.
  • the bus may be, for example, Ethernet or CAN (registered trademark) bus.
  • a part or all of the functions of the OTA master 4 may be implemented in the CGW.
  • the DCM may perform data communication with the outside such as the CDN 8 or the OTA center 2, and all the functions of the OTA master 4 may be implemented in the CGW. In this case, the DCM forwards all data received by wireless communication with the outside to the CGW.
  • the DCM may function as a downloader for the OTA master 4 in addition to data communication with the outside.
  • the functions of the downloader are, for example, vehicle configuration information generation, metadata verification, package verification, and campaign information verification.
  • the functionality of the OTA master 4 may be implemented in the DCM.
  • the CGW implements functions other than the OTA master 4 .
  • the DCM and CGW may be integrated.
  • a configuration in which the CGW has part or all of the functions of the DCM, or a configuration in which the DCM has part or all of the functions of the CGW may be used. That is, in the OTA master 4, the DCM and the CGW may be configured in any way to share the functions.
  • the OTA master 4 may be composed of two ECUs, DCM and CGW, or may be composed of one integrated ECU having the functions of DCM and CGW.
  • 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 control unit is provided by an electronic circuit, which 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 controller 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 may be implemented by a combination of a processor and memory programmed to perform one or more functions and a processor configured with 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 storage medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Power Engineering (AREA)
  • Mechanical Engineering (AREA)
  • Information Transfer Between Computers (AREA)
  • Exhaust Gas After Treatment (AREA)

Abstract

データ通信システム（１）は、更新データをマスタ装置へ配信するセンター装置（２）と、センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）と、を備える。更新データの暗号方式及び復号方式としてカウンター（ＣＴＲ）モードを採用した。

Description

データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラム 関連出願の相互参照
　本出願は、２０２１年９月３０日に出願された日本出願番号２０２１－１６１２１２号に基づくもので、ここにその記載内容を援用する。
　本開示は、データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラムに関する。
　近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。又、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムをリプログする機会も増えつつある。リプログは、プログラム更新と称される場合もある。一方、通信ネットワークの進展等に伴い、コネクテッドカーの技術も普及している。このような事情から、例えば特許文献１には、更新データがパッケージ化された更新パッケージをＯＴＡ（Over The Air）の技術によりセンター装置から車両側のマスタ装置へ配信する技術が開示されている。マスタ装置は、ＥＣＵのアプリプログラムのリプログを統括する装置である。センター装置からマスタ装置へ配信される更新データは、例えば自動運転、先進運転支援システム（ＡＤＡＳ（Advanced Driver-Assistance Systems））、マルチメディア等のアプリプログラムやデータを含む。
特開２０２０－２７６４２４号公報
　近年では、車両のユーザエクスペリエンス（以下、ＵＸ（User Experience）と称する）を高めるべく、センター装置からマスタ装置へ配信される更新パッケージのデータサイズが大容量化して数ＧＢオーダー以上となっている。又、アプリプログラムの更新を頻繁に行うことで更新頻度を高めることも検討されている。
　しかしながら、マスタ装置に搭載されているマイコンのハードウェアの制約を考慮すると、先進的暗号化標準（以下、ＡＥＳ（Advanced Encryption Standard）と略称する）の復号化処理がボトルネックとなっている。そのため、暗号方式及び復号方式として一般的なブロック暗号の暗号ブロック連鎖モード（以下、ＣＢＣモード（Cipher Block Chaining Mode）と称する）を採用した場合に、スループットが１０Ｍｂｐｓ程度となってしまう見込みである。マスタ装置においては、スループットが１０Ｍｂｐｓ程度では、データサイズが数ＧＢオーダー以上の更新パッケージをセンター装置からダウンロードする場合に、例えばデータサイズが２ＧＢでは更新パッケージをダウンロードするのに３０分弱の時間を要し、データサイズが２０ＧＢでは更新パッケージをダウンロードするのに５時間弱の時間を要することになる。このように更新パッケージをダウンロードするのに要する時間が長くなると、利用シーンによっては更新パッケージのダウンロード中にドライバーを必要以上に待たせてしまう事態になり、ドライバーのＵＸを逆に損ねてしまう可能性がある。
　本開示は、マスタ装置が更新データをセンター装置からダウンロードする際のスループットを適切に高めることを目的とする。
　本開示の一態様によれば、更新データをマスタ装置へ配信するセンター装置と、センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置と、を備える。更新データの暗号方式及び復号方式としてカウンター（ＣＴＲ）モードを採用した。
　暗号方式及び復号方式としてＣＢＣモードを採用した構成では、暗号化及び復号化の前準備ができない、暗号化の並列処理ができない等のデメリットがある。一方、暗号方式及び復号方式としてＣＴＲモードを採用した構成では、暗号化及び復号化の前準備ができる、暗号化及び復号化の並列処理ができる等のスループットの向上に寄与するメリットがある。ＣＢＣモードを採用した従来に対し、上記したスループットの向上に寄与するメリットを有するＣＴＲモードを採用した。マスタ装置が更新データをセンター装置からダウンロードする際のスループットを適切に高めることができる。
　本開示の一態様によれば、更新データをマスタ装置へ配信するセンター装置と、センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置と、を備える。更新データの暗号方式及び復号方式として出力フィードバック（ＯＦＢ）モードを採用した。
　暗号方式及び復号方式としてＣＢＣモードを採用した構成では、暗号化及び復号化の前準備ができない、暗号化の並列処理ができない等のデメリットがある。一方、暗号方式及び復号方式としてＯＦＢモードを採用した構成では、暗号化及び復号化の前準備ができる等のスループットの向上に寄与するメリットがある。ＣＢＣモードを採用した従来に対し、上記したスループットの向上に寄与するメリットを有するＯＦＢモードを採用した。マスタ装置が更新データをセンター装置からダウンロードする際のスループットを適切に高めることができる。
　本開示についての上記目的及びその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図１は、第１実施形態のシステム全体における処理の流れを示す図であり、 図２は、ＯＴＡセンター及びＯＴＡマスタの機能ブロック図であり、 図３は、ＣＴＲモードの暗号化処理を説明する図であり、 図４は、ＣＴＲモードの復号化処理を説明する図であり、 図５は、ＣＢＣモードとＣＴＲモードのメリット及びデメリットの比較を示す図であり、 図６は、ＣＢＣモードとＣＴＲモードのスループットの比較を示す図であり、 図７は、ＣＢＣモードの復号化処理を説明する図であり、 図８は、ＣＴＲモードの復号化処理を説明する図であり、 図９は、ＯＴＡセンターの処理を示す図であり、 図１０は、センターの処理を示す図であり、 図１１は、ＯＴＡセンターの処理を示す図であり、 図１２は、ＯＴＡマスタの処理を示す図であり、 図１３は、ＯＴＡマスタの処理を示す図であり、 図１４は、ＯＴＡマスタの処理を示す図であり、 図１５は、第２実施形態のＯＦＢモードの暗号化処理を説明する図であり、 図１６は、ＯＦＢモードの復号化処理を説明する図であり、 図１７は、ＣＢＣモードとＯＦＢモードのメリット及びデメリットの比較を示す図であり、 図１８は、ＣＢＣモードとＯＦＢモードのスループットの比較を示す図であり、 図１９は、ＣＴＲモードの復号化処理を説明する図であり、 図２０は、ＯＦＢモードの復号化処理を説明する図であり、 図２１は、ＯＴＡセンターの処理を示す図であり、 図２２は、ＯＴＡセンターの処理を示す図であり、 図２３は、ＯＴＡセンターの処理を示す図であり、 図２４は、ＯＴＡマスタの処理を示す図であり、 図２５は、ＯＴＡマスタの処理を示す図であり、 図２６は、ＯＴＡマスタの処理を示す図であり、 図２７は、第３実施形態のシステム全体における処理の流れを示す図であり、 図２８は、ＯＴＡセンターの処理を示す図であり、 図２９は、ＯＴＡセンターの処理を示す図であり、 図３０は、ＯＴＡセンターの処理を示す図であり、 図３１は、ＯＴＡマスタの処理を示す図であり、 図３２は、ＯＴＡマスタの処理を示す図であり、 図３３は、ＯＴＡマスタの処理を示す図であり、 図３４は、第４実施形態のシステム全体における処理の流れを示す図であり、 図３５は、ＯＴＡセンター及びＯＴＡマスタの機能ブロック図であり、 図３６は、ＯＴＡマスタの処理を示す図であり、 図３７は、ＯＴＡマスタの処理を示す図であり、 図３８は、ＯＴＡマスタの処理を示す図であり、 図３９は、第５実施形態のＯＴＡマスタの処理を示す図であり、 図４０は、ＯＴＡマスタの処理を示す図であり、 図４１は、ＯＴＡマスタの処理を示す図であり、 図４２は、メモリ容量とアクセス速度との関係を示す図であり、 図４３は、第６実施形態のシステム全体における処理の流れを示す図であり、 図４４は、ＯＴＡセンター及びＯＴＡマスタの機能ブロック図であり、 図４５は、ＲＰメタデータが送信される態様を示す図であり、 図４６は、ＲＰメタデータの構成を示す図であり、 図４７は、ＲＰメタデータの構成を示す図であり、 図４８は、ＯＴＡセンターの処理を示す図であり、 図４９は、ＯＴＡセンターの処理を示す図であり、 図５０は、ＯＴＡセンターの処理を示す図であり、 図５１は、ＯＴＡセンターの処理を示す図であり、 図５２は、ＯＴＡマスタの処理を示す図であり、 図５３は、ＯＴＡマスタの処理を示す図であり、 図５４は、ＯＴＡマスタの処理を示す図であり、 図５５は、第７実施形態のシステム全体における処理の流れを示す図であり、 図５６は、ＣＣＭＰモードの機能であり、 図５７は、ＣＣＭＰモードによるスループットの見積もりを説明する図であり、 図５８は、従来方式の機能ブロック図であり、 図５９は、従来方式によるスループットの見積もりを説明する図であり、 図６０は、ＣＣＭＰモードと従来方式のスループットの比較を示す図であり、 図６１は、ＯＴＡセンター及びＯＴＡマスタの機能ブロック図であり、 図６２は、ＯＴＡセンターの処理を示す図であり、 図６３は、ＯＴＡセンターの処理を示す図であり、 図６４は、ＯＴＡセンターの処理を示す図であり、 図６５は、ＯＴＡマスタの処理を示す図であり、 図６６は、ＯＴＡマスタの処理を示す図であり、 図６７は、ＯＴＡマスタの処理を示す図であり、 図６８は、第８実施形態のシステム全体における処理の流れを示す図であり、 図６９は、ＧＣＭＰモードの機能ブロック図であり、 図７０は、ＧＣＭＰモードによるスループットの見積もりを説明する図であり、 図７１は、ＧＣＭＰモードと従来方式のスループットの比較を示す図であり、 図７２は、ＯＴＡセンターの処理を示す図であり、 図７３は、ＯＴＡセンターの処理を示す図であり、 図７４は、ＯＴＡセンターの処理を示す図であり、 図７５は、ＯＴＡマスタの処理を示す図であり、 図７６は、ＯＴＡマスタの処理を示す図であり、 図７７は、ＯＴＡマスタの処理を示す図であり、 図７８は、第９実施形態のシステム全体における処理の流れを示す図であり、 図７９は、ＯＴＡセンターの処理を示す図であり、 図８０は、ＯＴＡセンターの処理を示す図であり、 図８１は、ＯＴＡセンターの処理を示す図であり、 図８２は、ＯＴＡセンターの処理を示す図であり、 図８３は、ＯＴＡマスタの処理を示す図であり、 図８４は、ＯＴＡマスタの処理を示す図であり、 図８５は、ＯＴＡマスタの処理を示す図であり、 図８６は、ＯＴＡマスタの処理を示す図であり、 図８７は、第１０実施形態のシステム全体における処理の流れを示す図であり、 図８８は、ＣＤＮのコスト比較を示す図であり、 図８９は、ＣＤＮのコスト比較を示す図であり、 図９０は、各クラウドサービスのＣＤＮ価格テーブルを示す図であり、 図９１は、各クラウドサービス事業者のストレージ方式の価格テーブルを示す図であり、 図９２は、クラウドサービス事業者のストリーミング方式における、ストリーミングサイズ毎の価格テーブルを示す図であり、 図９３は、各クラウドサービス事業者のストリーミング方式における、ストリーミングサイズ毎の価格テーブルを示す図であり、 図９４は、ＯＴＡセンター及びＯＴＡマスタの機能ブロック図であり、 図９５は、ＯＴＡセンターの処理を示す図であり、 図９６は、ＯＴＡセンターの処理を示す図であり、 図９７は、ＯＴＡセンターの処理を示す図であり、 図９８は、ＯＴＡセンターの処理を示す図であり、 図９９は、第１１実施形態のシステム全体における処理の流れを示す図であり、 図１００は、ＤＨＥ又はＥＣＤＨＥで鍵共有可能な共通鍵を示す図であり、 図１０１は、ＯＴＡセンターの処理を示す図であり、 図１０２は、ＯＴＡセンターの処理を示す図であり、 図１０３は、ＯＴＡセンターの処理を示す図であり、 図１０４は、ＯＴＡセンターの処理を示す図であり、 図１０５は、ＯＴＡマスタの処理を示す図であり、 図１０６は、ＯＴＡマスタの処理を示す図であり、 図１０７は、ＯＴＡマスタの処理を示す図であり、 図１０８は、ＯＴＡマスタの処理を示す図であり、 図１０９は、第１２実施形態のシステム全体における処理の流れを示す図であり、 図１１０は、ＯＴＡセンターの処理を示す図であり、 図１１１は、ＯＴＡセンターの処理を示す図であり、 図１１２は、ＯＴＡセンターの処理を示す図であり、 図１１３は、ＯＴＡマスタの処理を示す図であり、 図１１４は、ＯＴＡマスタの処理を示す図であり、 図１１５は、ＯＴＡマスタの処理を示す図であり、 図１１６は、第１３実施形態のシステム全体における処理の流れを示す図であり、 図１１７は、ＣＴＲモードの暗号化処理を説明する図であり、 図１１８は、ＣＴＲモードの復号化処理を説明する図であり、 図１１９は、ＯＴＡセンターの処理を示す図であり、 図１２０は、ＯＴＡセンターの処理を示す図であり、 図１２１は、ＯＴＡセンターの処理を示す図であり、 図１２２は、ＯＴＡマスタの処理を示す図であり、 図１２３は、ＯＴＡマスタの処理を示す図であり、 図１２４は、ＯＴＡマスタの処理を示す図であり、 図１２５は、第１４実施形態のシステム全体における処理の流れを示す図であり、 図１２６は、ＡＥＳ個別鍵を説明する図であり、 図１２７は、ＯＴＡセンターの処理を示す図であり、 図１２８は、ＯＴＡセンターの処理を示す図であり、 図１２９は、ＯＴＡセンターの処理を示す図であり、 図１３０は、ＯＴＡマスタの処理を示す図であり、 図１３１は、ＯＴＡマスタの処理を示す図であり、 図１３２は、ＯＴＡマスタの処理を示す図であり、 図１３３は、第１５実施形態のシステム全体における処理の流れを示す図であり、 図１３４は、ＯＴＡセンターの処理を示す図であり、 図１３５は、ＯＴＡセンターの処理を示す図であり、 図１３６は、ＯＴＡマスタの処理を示す図であり、 図１３７は、ＯＴＡマスタの処理を示す図であり、 図１３８は、第１６実施形態のシステム全体における処理の流れを示す図であり、 図１３９は、中間攻撃者からの攻撃を示す図であり、 図１４０は、デジタル署名を付与する態様を示す図であり、 図１４１は、ＯＴＡセンターの処理を示す図であり、 図１４２は、ＯＴＡセンターの処理を示す図であり、 図１４３は、ＯＴＡセンターの処理を示す図であり、 図１４４は、ＯＴＡマスタの処理を示す図であり、 図１４５は、ＯＴＡマスタの処理を示す図であり、 図１４６は、第１７実施形態のシステム全体における処理の流れを示す図であり、 図１４７は、ＯＴＡセンターの処理を示す図であり、 図１４８は、ＯＴＡセンターの処理を示す図であり、 図１４９は、ＯＴＡマスタの処理を示す図であり、 図１５０は、ＯＴＡマスタの処理を示す図であり、 図１５１は、ＯＴＡマスタの処理を示す図であり、 図１５２は、第１８実施形態のシステム全体における処理の流れを示す図であり、 図１５３は、各クラウドサービスのＣＤＮ価格テーブルを示す図であり、 図１５４は、各クラウドサービスのＣＤＮ価格テーブルを示す図であり、 図１５５は、各クラウドサービス事業者のストレージ方式の価格テーブルを示す図であり、 図１５６は、各クラウドサービス事業者のストレージ方式の価格テーブルを示す図であり、 図１５７は、各クラウドサービス事業者のストリーミング方式における、ストリーミングサイズ毎の価格テーブルを示す図であり、 図１５８は、各クラウドサービス事業者のストリーミング方式における、ストリーミングサイズ毎の価格テーブルを示す図であり、 図１５９は、各クラウドサービス事業者のストリーミング方式における、ストリーミングサイズ毎の価格テーブルを示す図であり、 図１６０は、各クラウドサービス事業者のストリーミング方式における、ストリーミングサイズ毎の価格テーブルを示す図であり、 図１６１は、各クラウドサービス事業者の品質情報を示す図であり、 図１６２は、ＣＤＮベンダの選定を説明する図であり、 図１６３は、ＯＴＡセンターの処理を示す図であり、 図１６４は、ＯＴＡセンターの処理を示す図であり、 図１６５は、ＯＴＡセンターの処理を示す図であり、 図１６６は、第１１実施形態の変形例を示し、システム全体における処理の流れの一部を示す図であり、 図１６７は、システム全体における処理の流れの一部を示す図であり、 図１６８は、システム全体における処理の流れの一部を示す図であり、 図１６９は、システム全体における処理の流れの一部を示す図であり、 図１７０は、ＯＴＡマスタの処理を示す図であり、 図１７１は、ＰＣの処理を示す図であり、 図１７２は、ＯＴＡセンターの処理を示す図であり、 図１７３は、ＯＴＡマスタの処理を示す図であり、 図１７４は、第１２実施形態の変形例を示し、システム全体における処理の流れの一部を示す図であり、 図１７５は、システム全体における処理の流れの一部を示す図であり、 図１７６は、システム全体における処理の流れの一部を示す図であり、 図１７７は、システム全体における処理の流れの一部を示す図であり、 図１７８は、ＯＴＡマスタの処理を示す図であり、 図１７９は、ＰＣの処理を示す図であり、 図１８０は、ＯＴＡセンターの処理を示す図であり、 図１８１は、ＯＴＡマスタの処理を示す図であり、 図１８２は、第１６実施形態の変形例を示し、システム全体における処理の流れの一部を示す図であり、 図１８３は、システム全体における処理の流れの一部を示す図であり、 図１８４は、システム全体における処理の流れの一部を示す図であり、 図１８５は、システム全体における処理の流れの一部を示す図であり、 図１８６は、ＯＴＡマスタの処理を示す図であり、 図１８７は、ＰＣの処理を示す図であり、 図１８８は、ＯＴＡセンターの処理を示す図であり、 図１８９は、ＯＴＡマスタの処理を示す図であり、 図１９０は、第１９実施形態のシステム全体における処理の流れを示す図であり、 図１９１は、キャンペーン通知生成部の処理を示す図であり、 図１９２は、ＣＤＮベンダ選定部の処理を示す図であり、 図１９３は、ＣＤＮベンダ選定部の処理を示す図であり、 図１９４は、第１９実施形態の第１変形例のシステム全体における処理の流れを示す図であり、 図１９５は、ＣＤＮベンダ選定部の処理を示す図であり、 図１９６は、第１９実施形態の第２変形例のシステム全体における処理の流れを示す図であり、 図１９７は、選択テーブルを示す図であり、 図１９８は、ＣＤＮベンダ選定部の処理を示す図であり、 図１９９は、ＣＤＮベンダ選定部の処理を示す図であり、 図２００は、性能測定部の処理を示す図であり、 図２０１は、ＣＤＮサーバ確認部の処理を示す図であり、 図２０２は、第１９実施形態の第３変形例のシステム全体における処理の流れを示す図であり、 図２０３は、ログ送信部３ａの処理を示す図 図２０４は、性能測定部の処理を示す図であり、 図２０５は、性能測定部の処理を示す図であり、 図２０６は、第１９実施形態の第４変形例を示し、ＣＤＮベンダ選定部７ａの処理を示す図 図２０７は、キャンペーン通知生成部の処理を示す図 図２０８は、第１９実施形態の第５変形例のシステム全体における処理の流れを示す図であり、 図２０９は、ラウンドロビンレコードを示す図であり、 図２１０は、ＣＤＮベンダ選定部７ａの処理を示す図であり、 図２１１は、切替部の処理を示す図であり、 図２１２は、第２０実施形態のシステム全体における処理の流れを示す図であり、 図２１３は、計算方法を示す図であり、 図２１４は、キャンペーン通知生成部の処理を示す図であり、 図２１５は、ＣＤＮベンダ選定部の処理を示す図であり、 図２１６は、ＣＤＮベンダ選定部の処理を示す図であり、 図２１７は、ＣＤＮベンダ選定部の処理を示す図であり、 図２１８は、ＣＤＮベンダ選定部の処理を示す図であり、 図２１９は、ＣＤＮベンダ選定部の処理を示す図であり、 図２２０は、ＣＤＮベンダ選定部の処理を示す図であり、 図２２１は、ＣＤＮベンダ選定部の処理を示す図であり、 図２２２は、進捗情報管理部の処理を示す図であり、 図２２３は、ＣＤＮベンダ選定部の処理を示す図であり、 図２２４は、キャンペーン通知生成部の処理を示す図である。
　以下、複数の実施形態について図面を参照して説明する。尚、後続する実施形態において、先行する実施形態と重複する内容について説明を省略することがある。
　（第１実施形態）
　第１実施形態について図１から図１４を参照して説明する。図１に示すように、データ通信システム１は、ＯＴＡセンター２と、車両に搭載されている車両側システム３とを備え、ＯＴＡセンター２と車両側システム３とがデータ通信可能に構成されている。ＯＴＡセンター２はセンター装置に相当する。ＯＴＡセンター２と車両側システム３は、１対複数の関係にあり、ＯＴＡセンター２が不特定多数の車両側システム３との間でデータ通信可能である。
　車両側システム３は、ＯＴＡマスタ４と、ターゲットＥＣＵ５とを備える。ＯＴＡマスタ４はマスタ装置に相当する。ＯＴＡマスタ４とターゲットＥＣＵ５は、例えばＣＡＮ（Controller Area Network）（登録商標）等の車載ネットワークに接続されており、車載ネットワークを介してデータ通信可能に接続されている。車載ネットワークは、ＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ（登録商標）、ＣＡＮ　ＦＤ（CAN Flexible Data rate）（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）等であっても良い。ターゲットＥＣＵ５は、アプリプログラムのリプログ対象となるＥＣＵであり、例えば自動運転系の制御を行うＥＣＵ、ＡＤＡＳ系の制御を行うＥＣＵ、マルチメディア系の制御を行うＥＣＵ等の何れであっても良い。アプリプログラムは、アプリケーションの実行に関わるプログラムであって、例えばアプリケーションプログラム、ファームウェアプログラム、オペレーティングシステムプログラムを含む。
　ＯＴＡセンター２は、パッケージ生成サーバ６と、配信サーバ７とを備える。パッケージ生成サーバ６は、更新データをパッケージ化して更新パッケージを生成する機能を有するサーバである。更新パッケージは、例えば更新データを格納した複数のファイルが圧縮されて格納されているｚｉｐファイルである。配信サーバ７は、パッケージ生成サーバ６により生成された更新パッケージを車両側システム３へ配信する機能を有するサーバである。
　ＯＴＡセンター２は、例えば機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムのリプログ要求が発生すると、キャンペーン通知を車両側システム３やユーザが所有するスマートフォン等の携帯情報端末へ配信する。ＯＴＡセンター２は、ユーザからのダウンロード承諾が得られたことを条件とし、更新パッケージをコンテンツ・デリバリー・ネットワーク（以下、ＣＤＮ（Content Delivery Network）と称する）８に配置し、ＣＤＮ８を介して更新パッケージをＯＴＡマスタ４へ配信する。或いは更新パッケージがＣＤＮ８に既に配置済みの場合は、ＯＴＡセンター２は、ユーザからのダウンロード承諾が得られたことを条件とし、ＣＤＮ８から更新パッケージをＯＴＡマスタ４へ配信させる。
　ＯＴＡマスタ４は、更新パッケージをＯＴＡセンター２からダウンロードすると、ユーザからのインストール承諾が得られたことを条件とし、更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする。ＣＤＮ８をサービスとして提供する事業者をＣＤＮベンダと称する。又、ＯＴＡマスタ４は、ＣＤＮ８のＣＤＮサーバにアクセスすることで更新パッケージを取得する。
　本実施形態では、車両側システム３における先進的暗号化標準（以下、ＡＥＳ（Advanced Encryption Standard）と略称する）の復号化処理の高速化を図るべく、暗号化モードとして、一般的なブロック暗号の暗号ブロック連鎖モード（以下、ＣＢＣモード（Cipher Block Chaining Mode）と称する）ではなく、ストリーミング暗号の代表であるカウンターモード（以下、ＣＴＲモード（Counter Mode）と称する）を採用している。本実施形態では、ＯＴＡセンター２は、更新パッケージをＡＥＳ鍵によりＣＴＲモードで暗号化する。又、車両側システム３は、更新パッケージをＡＥＳ鍵によりＣＴＲモードで暗号化する。尚、ＯＴＡセンター２は、車両毎にＲＳＡ（Rivest-Shamir-Adleman cryptosystem）公開鍵を備えている。ＯＴＡマスタ４は、車両製造段階でＲＳＡ秘密鍵が書込まれる。
　図２に示すように、ＯＴＡセンター２は、暗号化に係る機能ブロックとして、共通鍵生成部２ａと、更新パッケージ暗号化部２ｂと、共通鍵暗号化部２ｃと、共通鍵格納部２ｄと、暗号化パッケージ配置部２ｅと、キャンペーン通知送信部２ｆとを備える。更新パッケージ暗号化部２ｂは更新データ暗号化に相当する。暗号化パッケージ配置部２ｅは暗号化データ配置部に相当する。各部２ａ～２ｆは、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、Ｉ／Ｏ（Input/Output）等を有するマイクロコンピュータのハードウェア及びソフトウェアの協働により実現されている。ＣＰＵは、ＲＯＭに格納されている暗号化プログラム、更新データ配置プログラム、秘密情報共有プログラム等を含む各種プログラムを実行することで、ＯＴＡセンター２の機能を実現する。
　共通鍵生成部２ａは、更新パッケージを暗号化するための共通鍵としてＡＥＳ鍵を生成する。パッケージ暗号化部２ｂは、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する。パッケージ暗号化部２ｂは、カウンター値に対するＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する。パッケージ暗号化部２ｂは、暗号化されたカウンター値と、更新パッケージとを排他的論理和（ＸＯＲ）演算し、複数の暗号化された断片を結合し、ＡＥＳ鍵により暗号化された更新パッケージを生成する。尚、カウンター値は、例えば８桁の数字であって、ＡＥＳブロック毎に「１」ずつ増加する。
　共通鍵暗号化部２ｃは、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化する。共通鍵格納部２ｄは、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵をキャンペーン通知の中に格納する。暗号化パッケージ配置部２ｅは、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する。キャンペーン通知送信部２ｆは、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する。キャンペーン通知送信部２ｆは、キャンペーン通知をユーザが所有するスマートフォン等の携帯情報端末へ配信しても良い。
　ＯＴＡマスタ４は、復号化に係る機能ブロックとして、共通鍵取得部４ａと、共通鍵復号化部４ｂと、暗号化パッケージ取得部４ｃと、ブロック暗号処理部４ｄと、暗号化パッケージ復号化部４ｅと、インストール処理部４ｆとを備える。暗号化パッケージ取得部４ｃは暗号化データ取得部に相当する。暗号化パッケージ復号化部４ｅは暗号化データ復号化部に相当する。各部４ａ～４ｆは、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ等を有するマイクロコンピュータのハードウェア及びソフトウェアの協働により実現されている。ＣＰＵは、ＲＯＭに格納されている復号化プログラム、更新データ取得プログラム、秘密情報共有プログラム等を含む各種プログラムを実行することで、ＯＴＡマスタ４の機能を実現する。
　共通鍵取得部４ａは、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中から暗号化されたＡＥＳ鍵を取得する。共通鍵復号化部４ｂは、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す。暗号化パッケージ取得部４ｃは、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する。このとき、ブロック暗号処理部４ｄは、暗号化された更新パッケージを暗号化パッケージ取得部４ｃがＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する。暗号化パッケージ復号化部４ｅは、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとを排他的論理和（以下、ＸＯＲ（Exclusively-OR）演算して復号化する。インストール処理部４ｆは、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする。
　ＣＴＲモードの暗号化処理は図３に示す通りであり、ＣＴＲモードの復号化処理は図４に示す通りである。図５に示すように、ＣＢＣモードのデメリットとして「暗号化及び復号化の前準備ができない」、「暗号化の並列処理ができない」に対し、ＣＴＲモードのメリットとして「暗号化及び復号化の前準備ができるため、高速化可能」、「暗号化及び復号化の並列処理ができる」を挙げることができる。即ち、暗号化モードとしてＣＴＲモードを採用することでスループットの向上に寄与するメリットとして、図６に示すように、一般的なブロック暗号のＣＢＣモードを採用した場合と比較すると、スループットを約４０％向上させることができる。
　図７に示すように、ＣＢＣモードの復号化処理では、入力が暗号文であるので、暗号文である更新パッケージを受信してからでないと、復号化処理を開始することができない。これに対し、図８に示すように、ＣＴＲモードの復号化処理では、入力がカウンター値であるので、暗号文である更新パッケージを受信する前から復号化処理を開始することができる。又、相互に依存関係がないので、複数の暗号演算を同時に並列実行することもできる。
　次に、上記した構成の作用について図９から図１４を参照して説明する。
　（１－１）ＯＴＡセンター２の処理（図９から図１１参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ０１１、共通鍵生成手順に相当する）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する（Ａ０１２、更新データ暗号化手順に相当する）。ＯＴＡセンター２は、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化する（Ａ０１３、共通鍵暗号化手順に相当する）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵をキャンペーン通知の中に格納する（Ａ０１４、共通鍵格納手順に相当する）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ０１５、暗号化データ配置手順に相当する）。更新パッケージをＣＤＮ８に配置するとは、更新パッケージをＣＤＮ８のオリジンサーバに配置することを示す。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０１６、キャンペーン通知送信手順に相当する）。
　（１－２）ＯＴＡマスタ４の処理（図１２から図１４参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する（Ｂ０１１、共通鍵取得手順に相当する）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ０１２、共通鍵復号化手順に相当する）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０１３、暗号化データ取得手順に相当する）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ０１４、ブロック暗号処理手順に相当する）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０１５、暗号化データ復号化手順に相当する）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０１６、インストール処理手順に相当する）。尚、更新パッケージ内の差分プログラムをＣＢＣモードで暗号化及び復号化するのではなく、ＣＴＲモードで暗号化及び復号化することで、ターゲットＥＣＵ５における復号化処理についてもスループットを約４０％向上させることができる。
　以上に説明したように第１実施形態によれば、以下の作用効果を得ることができる。
　更新パッケージの暗号方式及び復号方式としてＣＴＲモードを採用する構成とした。ＣＢＣモードを採用した従来に対し、ＣＴＲモードを採用したことで、暗号化及び復号化の前準備を行うことができ、暗号化及び復号化の並列処理を行うことができる。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際に、ＣＴＲモードのメリットを享受することができ、スループットを適切に高めることができる。
　（第２実施形態）
　第２実施形態について図１５から図２６を参照して説明する。第１実施形態は、暗号化モードとしてＣＴＲモードを採用している構成であるが、第２実施形態は、暗号化モードとして出力フィードバックモード（以下、ＯＦＢモード（Output-FeedBack mode）と称する）を採用している。
　この場合、パッケージ暗号化部２ｂは、更新パッケージを、生成されたＡＥＳ鍵によりＯＦＢモードで暗号化する。ブロック暗号処理部４ｄは、暗号化された更新パッケージを暗号化パッケージ取得部４ｃがＣＤＮ８からダウンロードして取得することと並行し、ＩＶ（Initialization Vector）値ベースのＡＥＳストリーム暗号処理をＡＥＳ鍵により実行してＩＶ値を暗号化する。ＩＶ値とは、初期化ベクトル値であり、例えばランダムに生成されたビット列を示す。暗号化パッケージ復号化部４ｅは、暗号化されたＩＶ値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する。
　ＯＦＢモードの暗号化処理は図１５に示す通りであり、ＯＦＢモードの復号化処理は図１６に示す通りである。図１７に示すように、ＣＢＣモードのデメリットとして「暗号化及び復号化の前準備ができない」、「暗号化の並列処理ができない」に対し、ＯＦＢモードのメリットとして「暗号化及び復号化の前準備ができるため、高速化可能」を挙げることができる。即ち、暗号化モードとしてＯＦＢモードを採用することによるスループットの向上に寄与するメリットとして、図１８に示すように、一般的なブロック暗号のＣＢＣモードを採用した場合と比較すると、スループットを約２５％向上させることができる。
　図１９に示すように、ＣＴＲモードの復号化処理では、入力がカウンター値であるので、暗号文である更新パッケージを受信する前から復号化処理を開始することができる。又、相互に依存関係がないので、複数の暗号演算を同時に並列実行することもできる。これに対し、図２０に示すように、ＯＦＢモードの復号化処理では、相互に依存関係があるので、複数の暗号演算を同時に並列実行することができない。ただし、暗号化されたＩＶ値と暗号化された更新パッケージとをＸＯＲ演算して復号化する処理は並列実行することができる。そのため、ＯＦＢモードの復号化処理では、第１実施形態で説明したＣＴＲモードの復号化処理ほどまではスループットを向上させることはできないが、ＣＢＣモードを採用した場合と比較すると、スループットを向上させることができる。
　次に、上記した構成の作用について図２１から図２６を参照して説明する。
　（２－１）ＯＴＡセンター２の処理（図２１から図２３参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ０２１、共通鍵生成手順に相当する）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＯＦＢモードで暗号化する（Ａ０２２、更新データ暗号化手順に相当する）。ＯＴＡセンター２は、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化する（Ａ０２３、共通鍵暗号化手順に相当する）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵をキャンペーン通知の中に格納する（Ａ０２４、共通鍵格納手順に相当する）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ０２５、暗号化データ配置手順に相当する）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０２６、キャンペーン通知送信手順に相当する）。
　（２－２）ＯＴＡマスタ４の処理（図２４から図２６参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する（Ｂ０２１、共通鍵取得手順に相当する）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ０２２、共通鍵復号化手順に相当する）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０２３、暗号化データ取得手順に相当する）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージＣＤＮ８からダウンロードして取得することと並行し、ＩＶ値ベースのＡＥＳストリーム暗号処理をＡＥＳ鍵により実行してＩＶ値を暗号化する（Ｂ０２４、ブロック暗号処理手順に相当する）。ＯＴＡマスタ４は、暗号化されたＩＶ値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０２５、暗号化データ復号化手順に相当する）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０２６、インストール処理手順に相当する）。尚、更新パッケージ内の差分プログラムＣＢＣモードで暗号化及び復号化するのではなく、ＯＦＢモードで暗号化及び復号化することで、ターゲットＥＣＵ５における復号化処理についてもスループットを約２５％向上させることができる。
　以上に説明したように第２実施形態によれば、以下の作用効果を得ることができる。
　更新パッケージの暗号方式及び復号方式としてＯＦＢモードを採用する構成とした。ＣＢＣモードを採用した従来に対し、ＯＦＢモードを採用したことで、暗号化及び復号化の前準備を行うことができる。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際に、ＯＦＢモードのメリットを享受することができ、スループットを適切に高めることができる。
　（第３実施形態）
　第３実施形態について図２７から図３３を参照して説明する。第３実施形態は、ＣＤＮ８とＯＴＡマスタ４との間の通信プロトコルとしてハイパーテキスト・トランスファー・プロトコル（以下、ＨＴＴＰ（Hypertext Transfer Protocol）と称する）を採用し、レンジリクエストをＣＤＮ８へ送信し、更新パッケージをストリーミング方式でダウンロードすることで、ハイパーテキスト・トランスファー・プロトコル・セキュア（以下、ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）と称する）を採用した場合よりも配信コストの抑制を図っている。ＣＤＮベンダによっては、ＣＤＮ８への通信プロトコルにＨＴＴＰを使う場合とＨＴＴＰＳを使う場合とでＣＤＮ８の配信料金を差別化している場合がある。ＨＴＴＰＳを使う場合、ＣＤＮ８は、トランスポート・レイヤー・セキュリティ（以下、ＴＬＳ（Transport Layer Security）と称する）で定められているハンドシェーク処理や暗号鍵交換処理や暗号演算処理を行う必要があり、ＣＤＮ８のＣＰＵの処理負荷が増大するため、ＨＴＴＰＳの配信料金はＨＴＴＰに比べて約３割高額な料金テーブルとなっている。このため、更新パッケージのダウンロードにはＨＴＴＰを使うことで配信コストの抑制を実現する。第３実施形態では、ＣＤＮ８から車両側システム３へ更新パッケージを配信する際にＨＴＴＰＳを使わない。
　この場合、キャンペーン通知送信部２ｆは、ＯＴＡセンター４とＯＴＡマスタ４との間でＴＬＳ通信を確立した上で、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する。共通鍵取得部４ａは、ＴＬＳ通信が確立された上で、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する。暗号化パッケージ取得部４ｃは、レンジリクエストをＣＤＮ８へ送信してダウンロード対象のデータ範囲を指定し、暗号化された更新パッケージをＣＤＮ８からストリーミング方式でダウンロードして取得する。インストール処理部４ｆは、復号化された更新パッケージをターゲットＥＣＵ５へストリーミング方式で転送し、更新パッケージをターゲットＥＣＵ５にインストールする。
　尚、本実施形態では、ＯＴＡマスタ４において、暗号化された更新パッケージをＣＤＮ８からストリーミング方式で取得することを説明しているが、暗号化された更新パッケージをＣＤＮ８からストレージ方式で取得しても良い。ストリーミング方式では、通信時にヘッダ情報を含むため、ＨＴＴＰを使うことで配信コストを更に抑制することができる。
　次に、上記した構成の作用について図２８から図３３を参照して説明する。
　（３－１）ＯＴＡセンター２の処理（図２８から図３０参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ０３１）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する（Ａ０３２）。ＯＴＡセンター２は、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化する（Ａ０３３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵をキャンペーン通知の中に格納する（Ａ０３４）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ０３５）。ＯＴＡセンター２は、ＯＴＡセンター４とＯＴＡマスタ４との間でＴＬＳ通信を確立した上で、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０３６）。
　（３－２）ＯＴＡマスタ４の処理（図３１から図３３参照）
　ＯＴＡマスタ４は、ＴＬＳ通信が確立された上で、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する（Ｂ０３１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ０３２）。ＯＴＡマスタ４は、レンジリクエストをＣＤＮ８へ送信してダウンロード対象のデータ範囲を指定し、暗号化された更新パッケージをＣＤＮ８からストリーミング方式でダウンロードして取得する（Ｂ０３３）。即ち、ＯＴＡマスタ４は、ダウンロード対象のデータ範囲を指定することで、更新パッケージをＣＤＮ８から分割ストリーミング方式でダウンロードして取得する。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージを暗号化パッケージ取得部４ｃがＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ０３４）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０３５）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へストリーミング方式で転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０３６）。
　以上に説明したように第３実施形態によれば、以下の作用効果を得ることができる。
　ＣＤＮ８とＯＴＡマスタ４との間の通信プロトコルとしてＨＴＴＰを採用し、ＯＴＡマスタ４がレンジリクエストをＣＤＮ８へ送信することで当該ＣＤＮ８から更新パッケージをストリーミング方式でダウンロードする構成とした。これにより、通信プロトコルとしてＨＴＴＰＳを採用した従来に対し、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制することができる。
　（第４実施形態）
　第４実施形態について図３４から図３８を参照して説明する。第４実施形態は、ユーザからのダウンロード承諾が得られる前に全ての鍵ストリームの計算を事前にバックグラウンドで実行することで、更新パッケージのダウンロード時の復号化処理の高速化を図っている。
　この場合、図３５に示すように、ＯＴＡマスタ４は、共通鍵取得部４ａと、共通鍵復号化部４ｂと、暗号化パッケージ取得部４ｃと、ブロック暗号処理部４ｄと、暗号化パッケージ復号化部４ｅと、インストール処理部４ｆとに加え、鍵ストリーム計算部４ｇを備える。鍵ストリーム計算部４ｇは、ユーザからのダウンロード承諾が得られる前に全ての鍵ストリームの計算を事前にバックグラウンドで実行する。暗号化パッケージ取得部４ｃは、ユーザからのダウンロード承諾が得られたことを条件とし、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する。暗号化パッケージ復号化部４ｅは、計算された鍵ストリームと、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する。
　次に、上記した構成の作用について図３６から図３８を参照して説明する。
　（４－１）ＯＴＡセンター２の処理
　ＯＴＡセンター２の処理は、第１実施形態で説明したＯＴＡセンター２の処理（図９から図１１）と同様である。
　（４－２）ＯＴＡマスタ４の処理（図３６から図３８参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する（Ｂ０４１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ０４２）。ＯＴＡマスタ４は、ユーザからのダウンロード承諾が得られる前に全ての鍵ストリームの計算を事前にバックグラウンドで実行する（Ｂ０４３）。それぞれの鍵ストリームには識別情報が付与されており、暗号化された更新パッケージに対する適用順序が示されている。
　ＯＴＡマスタ４は、キャンペーン通知を車両側システム３やユーザが所有するスマートフォン等の携帯情報端末へ配信することで、ダウンロード承諾画面をＨＭＩ（Human Machine Interface）に表示する（Ｂ０４４）。ＯＴＡマスタ４は、ユーザからのダウンロード承諾が得られたことを条件とし、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０４５）。ＯＴＡマスタ４は、事前に計算された鍵ストリームと、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０４６）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０４７）。
　以上に説明したように第４実施形態によれば、以下の作用効果を得ることができる。
　ユーザからのダウンロード承諾が得られる前に全ての鍵ストリームの計算を事前にバックグラウンドで実行する構成とした。これにより、ＯＴＡマスタ４における更新パッケージの復号化処理を高速化することができ、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際のスループットを高めることができる。
　（第５実施形態）
　第５実施形態について図３９から図４２を参照して説明する。第４実施形態は、ユーザからのダウンロード承諾が得られる前に全ての鍵ストリームの計算を事前にバックグラウンドで実行しているが、第５実施形態は、ユーザからのダウンロード承諾が得られる前に一部の鍵ストリームの計算を事前にバックグラウンドで実行する。計算の対象とする一部の鍵ストリームは、ＣＰＵのキャッシュメモリのメモリ容量とＡＥＳ暗号演算のスループットを考慮して決定され、キャッシュメモリに保存可能なサイズとする。
　この場合、鍵ストリーム計算部４ｇは、ユーザからのダウンロード承諾が得られる前に一部の鍵ストリームの計算を事前にバックグラウンドで実行する。鍵ストリーム計算部４ｇは、暗号化された更新パッケージを暗号化パッケージ取得部４ｃがＣＤＮ８からダウンロードして取得することと並行し、鍵ストリームを生成してキャッシュメモリに追加する。
　次に、上記した構成の作用について図３９から図４２を参照して説明する。
　（５－１）ＯＴＡセンター２の処理
　ＯＴＡセンター２の処理は、第１実施形態で説明したＯＴＡセンター２の処理（図９から図１１）と同様である。
　（５－２）ＯＴＡマスタ４の処理（図３９から図４１参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する（Ｂ０５１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ０５２）。ＯＴＡマスタ４は、ユーザからのダウンロード承諾が得られる前に一部の鍵ストリームの計算を事前にバックグラウンドで実行する（Ｂ０５３）。
　ＯＴＡマスタ４は、キャンペーン通知を車両側システム３やユーザが所有するスマートフォン等の携帯情報端末へ配信することで、ダウンロード承諾画面をＨＭＩに表示する（Ｂ０５４）。ＯＴＡマスタ４は、ユーザからのダウンロード承諾が得られたことを条件とし、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０５５）。ＯＴＡマスタ４は、事前に計算された鍵ストリームと、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０５６）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージＣＤＮ８からダウンロードして取得することと並行し、鍵ストリームを生成してキャッシュメモリに追加し（Ｂ０５７）、残りの鍵ストリームを計算する。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０５８）。尚、メモリ容量とアクセス速度との関係は図４２に示す通りであり、要求されるアクセス速度に応じてキャッシュメモリのサイズを決定すれば良い。
　以上に説明したように第５実施形態によれば、以下の作用効果を得ることができる。
　ユーザからのダウンロード承諾が得られる前に一部の鍵ストリームの計算を事前にバックグラウンドで実行する構成とした。これにより、ＯＴＡマスタ４のメモリ使用量を節約しながら、ＯＴＡマスタ４における更新パッケージの復号化処理を高速化することができ、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際のスループットを高めることができる。
　（第６実施形態）
　第６実施形態について図４３から図５４を参照して説明する。第６実施形態は、暗号方式をリプロポリシーメタデータ（以下、ＲＰメタデータと称する）等に含めてＯＴＡセンター２からＯＴＡマスタ４へ送信することにより、ＯＴＡマスタ４が暗号方式を特定している。ＯＴＡセンター２からＯＴＡマスタ４へ送信される暗号方式は、暗号化アルゴリズム、暗号鍵長、暗号化モード、メッセージ認証コード（以下、ＭＡＣ（Message Authentication Code）と称する）アルゴリズム等を含む。
　ＲＰメタデータは、更新パッケージの構成情報、即ち、更新パッケージの構成種別を表す情報を含み、そのデータ内容をＯＴＡマスタ４がチェックすることで更新パッケージの配信ミスを防止するためのデータである。ＲＰメタデータを、配信、マスタ及びターゲットの３層構造とすることで、転送方式、プラットフォームのタイプ、更新パッケージの種類等が増大した場合でも、それらを柔軟に定義して対応することができ、ターゲットＥＣＵ５のリプログを行うことが可能になる。尚、暗号方式をダウンロードメタデータ（以下、ＤＬメタデータと称する）等に含めてＯＴＡセンター２からＯＴＡマスタ４へ送信することにより、ＯＴＡマスタ４が暗号方式を特定しても良い。ＤＬメタデータは、複数のターゲットＥＣＵ５毎の更新パッケージをダウンロードするための情報を含み、ＯＴＡマスタ４が把握すべき内容を規定するデータである。
　図４４に示すように、ＯＴＡセンター２は、共通鍵生成部２ａと、更新パッケージ暗号化部２ｂと、共通鍵暗号化部２ｃと、共通鍵格納部２ｄと、暗号化パッケージ配置部２ｅと、キャンペーン通知送信部２ｆとに加え、ＲＰメタデータ生成部２ｇと、ＲＰメタデータ暗号化部２ｈとを備える。ＲＰメタデータ生成部２ｇは、共通鍵暗号方式を含むＲＰメタデータを生成する。ＲＰメタデータ暗号化部２ｈは、ＲＰメタデータをＲＳＡ公開鍵により暗号化する。
　ＯＴＡマスタ４は、共通鍵取得部４ａと、共通鍵復号化部４ｂと、暗号化パッケージ取得部４ｃと、ブロック暗号処理部４ｄと、暗号化パッケージ復号化部４ｅと、インストール処理部４ｆとに加え、ＲＰメタデータ取得部４ｈと、ＲＰメタデータ復号化部４ｉと、共通鍵暗号方式特定部４ｊとを備える。ＲＰメタデータ取得部４ｈは、暗号化されたＲＰメタデータをＣＤＮ８からダウンロードして取得する。ＲＰメタデータ復号化部４ｉは、暗号化されたＲＰメタデータＲＳＡ秘密鍵により復号化してＲＰメタデータを取出す。共通鍵暗号方式特定部４ｊは、ＲＰメタデータの内容を解釈して共通鍵暗号方式を特定する。
　尚、ＣＤＮ８からＯＴＡセンター２への更新パッケージの配信までの流れは次のようになる。ＯＴＡセンター２からＯＴＡマスタ４或いはユーザが所有する携帯情報端末にキャンペーン通知が送信される。その後、ＯＴＡマスタ４がＣＤＮ８にアクセスすることで、ＣＤＮ８からＯＴＡマスタ４へＲＰメタデータ及びＤＬメタデータが送信され、ＣＤＮ８からＯＴＡセンター２へ更新パッケージが配信される。
　図４５に示すように、ＲＰメタデータ及びＤＬメタデータは、更新パッケージのダウンロードに先立ってＯＴＡセンター２からＯＴＡマスタ４へ送信される。図４６から図４７に示すように、ＲＰメタデータは、ＲＰメタデータバージョン、配信レイヤ、マスタレイヤ、ターゲットレイヤの情報を含む。各情報は以下の通りである。
　（ａ）ＲＰメタデータバージョン
　ＲＰメタデータのバージョンであり、例えば「１．０．０」や「２．０．０」等のバージョン情報である。
　（ｂ）配信レイヤ
　（ｂ－１）通信プロトコル
　ＯＴＡセンター２との通信に使用されるプロトコルであり、例えばＵｐｔａｎｅ（登録商標）、ＯＭＡ－ＤＭ（Open Mobile Alliance-Device Management）等を示す情報である。
　（ｂ－２）通信手段
　更新パッケージの配信経路であり、ＯＴＡマスタ４であることを示すセルラー、スマートフォン、ＵＳＢメモリ等を示す情報である。
　（ｃ）マスタレイヤ
　ＯＴＡマスタ４に関する情報である
　（ｃ－１）ＰＦ
　ＯＴＡマスタ４のプラットフォーム（ＰＦ）が例えばＡＰ（AUTOSAR Adaptive Platform）、ＣＰ（AUTOSAR Classic Platform）、ＡＧＬ（Automotive Grade Linux）、Ａｎｄｒｏｉｄ（登録商標）であること等を示す情報である。ＥＣＵのプラットフォームに応じた更新パッケージを配信するためのパッケージ構造について、一般社団法人ＪＡＳＰＡＲの仕様では、標準化団体ＡＵＴＯＳＡＲの静的ＯＳで動作するクラシックプラットフォーム（ＣＰ）に適用可能なデータ要件が規定されている。又、ＡＵＴＯＳＡＲでは、動的ＯＳで動作する新たなタイプのアダプティブプラットフォーム（ＡＰ）に適用可能なデータ要件が規定されている。ＡＧＬは、車載Ｌｉｎｕｘ（登録商標）であり、Ａｎｄｒｏｉｄは、Android Automotive OSである。ＡＰ及びＣＰはソフトウェアプラットフォームを示す。ソフトウェアプラットフォームは、ソフトウェアアーキテクチャとも称される。ＡＰ及びＣＰにおいては、使用されるオペレーティングシステムや開発言語が異なる。ＣＰ仕様書に準拠して動作するＥＣＵとＡＰ仕様書に準拠して動作するＥＣＵとでは、受信可能な更新パッケージの構造が異なる。これらの更新パッケージの構造の違いは、主にＥＣＵの処理性能の違いに起因する。一般的に、ＣＰ仕様書に準拠して動作するＥＣＵの処理性能は比較的低いので、更新パッケージに含まれる諸元データ等もバイナリデータで記載されており、処理性能の低いＥＣＵでも解釈及び処理し易いデータ構造となっている。一方、ＡＰ仕様書に準拠して動作するＥＣＵの処理性能は比較的高いので、何らかの言語で記述された構造的な文字データを解析してプログラムで扱えるデータ構造に変換するパーサー機能を搭載することが可能であり、データ構造には単純なバイナリデータではなく、例えばＪＳＯＮ（JavaScript Object Notation）のようにオブジェクト指向のデータ形式を採用できるので、柔軟なデータ構造となっている。
　（ｃ－２）制御方式
　特定のフォーマットにしたがって設定されたパラメータに応じて処理するパラメータ、特定のフォーマットがなく、より自由な記載形式で処理するスクリプト等の情報である。
　（ｃ－３）暗号方式
　暗号アルゴリズム、暗号鍵長、暗号化モード、Ｐａｄｄｉｎｇ方式、暗号鍵ＩＤ、署名アルゴリズム、署名鍵ＩＤ、署名モード、ハッシュアルゴリズム、領域指定有無、オフセットサイズ、保護データサイズを含む情報である。
　（ｄ）ターゲットレイヤ
　ターゲットＥＣＵ５に関する情報である。
　（ｄ－１）ＰＦ
　マスタレイヤと同様である。
　（ｄ－２）転送方式
　ストレージ方式、ストリーミングの何れかである
　（ｄ－３）制御方式
　マスタレイヤと同様である。
　（ｄ－４）ターゲットＩＤ
　オプションである。
　（ｄ－５）暗号方式
　マスタレイヤと同様である。
　次に、上記した構成の作用について図４８から図５４を参照して説明する。
　（６－１）ＯＴＡセンター２の処理（図４８から図５１参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するための共通鍵を生成する（Ａ０６１）。ＯＴＡセンター２は、更新パッケージを、生成された共通鍵により特定の暗号化モードで暗号化する（Ａ０６２）。ＯＴＡセンター２は、共通鍵をＲＳＡ公開鍵により暗号化する（Ａ０６３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化された共通鍵をキャンペーン通知の中に格納する（Ａ０６４）。ＯＴＡセンター２は、共通鍵暗号方式を含むＲＰメタデータを生成する（Ａ０６５）。ＯＴＡセンター２は、ＲＰメタデータをＲＳＡ公開鍵により暗号化する（Ａ０６６）。ＯＴＡセンター２は、共通鍵により暗号化された更新パッケージとＲＳＡ公開鍵により暗号化されたＲＰメタデータをＣＤＮ８に配置する（Ａ０６７）。ＯＴＡセンター２は、暗号化された共通鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０６８）。
　（６－２）ＯＴＡマスタ４の処理（図５２から図５４参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中から共通鍵を取得する（Ｂ０６１）。ＯＴＡマスタ４は、暗号化された共通鍵をＲＳＡ秘密鍵により復号化して共通鍵を取出す（Ｂ０６２）。ＯＴＡマスタ４は、暗号化されたＲＰメタデータをＣＤＮ８からダウンロードして取得する（Ｂ０６３）。ＯＴＡマスタ４は、暗号化されたＲＰメタデータＲＳＡ秘密鍵により復号化してＲＰメタデータを取出す（Ｂ０６４）。ＯＴＡマスタ４は、ＲＰメタデータの内容を解釈して共通鍵暗号方式を特定する（Ｂ０６５）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０６６）。これ以降、ＯＴＡマスタ４は、特定の暗号化モードとしてＣＴＲモードを採用した場合であれば第１実施形態で説明したステップＢ０１４以降の処理を行い、特定の暗号化モードとしてＯＦＢモードを採用した場合であれば第２実施形態で説明したステップＢ０２４以降の処理を行う。それ以外の暗号化モードの場合も同様に、暗号化モードに対応した手順にしたがい、更新パッケージの復号と、ターゲットＥＣＵへのデータの転送を行う。
　以上に説明したように第６実施形態によれば、以下の作用効果を得ることができる。
　暗号方式をＲＰメタデータやＤＬメタデータに含めてＯＴＡセンター２からＯＴＡマスタ４へ送信する構成とした。これにより、ＯＴＡマスタ４において暗号方式を特定することができる。
　（第７実施形態）
　第７実施形態について図５５から図６７を参照して説明する。第７実施形態は、通信路暗号化とデータ改竄対策としてＣＣＭＰモード（Counter mode with Cipher-block chaining Message authentication code Protocol）を採用している。
　この場合、図５６から図６０に示すように、ＣＣＭＰモードを採用した構成と、従来方式としてＡＥＳ　ＣＢＣ－ＨＭＡＣ（Hashed Message Authentication Mode Code）　ＳＨＡ（Secure Hash Algorithm）２の復号化及び署名検証を採用した構成とを比較すると、何れもメインコアの処理時間よりもハードウェアアクセラレータの処理時間の方が支配的であるが、ＣＣＭＰモードを採用したことでスループットを向上させることができる。
　図６１に示すように、ＯＴＡセンター２は、共通鍵生成部２ａと、更新パッケージ暗号化部２ｂと、共通鍵暗号化部２ｃと、共通鍵格納部２ｄと、暗号化パッケージ配置部２ｅと、キャンペーン通知送信部２ｆとに加え、ＭＡＣ鍵生成部２ｉを備える。ＭＡＣ鍵生成部２ｉは、更新パッケージの改竄を防止するためのＭＡＣを生成する。
　ＯＴＡマスタ４は、共通鍵取得部４ａと、共通鍵復号化部４ｂと、暗号化パッケージ取得部４ｃと、ブロック暗号処理部４ｄと、暗号化パッケージ復号化部４ｅと、インストール処理部４ｆとに加え、ＭＡＣ鍵取得部４ｋを備える。ＭＡＣ鍵取得部４ｋは、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＭＡＣ鍵を取得する。
　次に、上記した構成の作用について図６２から図６７を参照して説明する。
　（７－１）ＯＴＡセンター２の処理（図６２から図６４参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵と、更新パッケージの改竄を防止するためのＭＡＣ鍵とを生成する（Ａ０７１）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵とＭＡＣ鍵によりＣＣＭＰモードで暗号化し、ＭＡＣを付与する（Ａ０７２）。ＯＴＡセンター２は、ＡＥＳ鍵とＭＡＣ鍵をＲＳＡ公開鍵により暗号化する（Ａ０７３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵とＭＡＣ鍵をキャンペーン通知の中に格納する（Ａ０７４）。ＯＴＡセンター２は、ＡＥＳ鍵とＭＡＣ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ０７５）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵とＭＡＣ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０７６）。
　（７－２）ＯＴＡマスタ４の処理（図６５から図６７参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵とＭＡＣを取得する（Ｂ０７１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵とＭＡＣ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵とＭＡＣ鍵を取出す（Ｂ０１７）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０７３）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ０７４）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０７５）。ＯＴＡマスタ４は、復号化された更新パッケージの平文からＭＡＣ鍵を用いてＡＥＳ－ＣＢＣモードでＭＡＣを生成して検証する（Ｂ０７６）。ＯＴＡマスタ４は、ＭＡＣが一致すると、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０７７）。ＯＴＡマスタ４は、ＭＡＣが一致しないと、処理を終了する。この場合、ＯＴＡマスタ４は、ＭＡＣの不一致により処理を終了すると、ＭＡＣの不一致により処理を終了したことを示すログを記録すると共に、図示しないＨＭＩにエラー表示しても良い。或いは、ＯＴＡマスタ４は、暗号化された更新パッケージをＸＯＲ演算して復号化すると同時に、復号化された更新パッケージをターゲットＥＣＵ５へ転送しても良い。この場合、ＯＴＡマスタ４は、復号化された更新パッケージの平文からＭＡＣ鍵を用いてＡＥＳ－ＣＢＣモードでＭＡＣを生成して検証し、ＭＡＣが不一致と判定した場合には、ターゲットＥＣＵ５へインストールの中止を通知するように構成しても良い。
　以上に説明したように第７実施形態によれば、以下の作用効果を得ることができる。
　ＯＴＡセンター２とＯＴＡマスタ４との間の通信路暗号化とデータ改竄対策としてＣＣＭＰモードを採用する構成とした。ＣＣＭＰモードを採用したことで、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際に通信路暗号化に加えてデータ改竄対策を備えることができる。これにより、セキュリティを高めることができ、よりセキュアなＯＴＡ配信を実現することができる。
　（第８実施形態）
　第８実施形態について図６８から図７７を参照して説明する。第８実施形態は、通信路暗号化とデータ改竄対策としてＧＣＭＰモード（Galois/Counter Mode Protocol）を採用している。
　この場合、図６９から図７１に示すように、ＧＣＭＰモードを採用した構成と、ＣＣＭＰモードを採用した構成や従来方式としてＡＥＳ　ＣＢＣ－ＨＭＡＣ　ＳＨＡ２の復号化及び署名検証を採用した構成とを比較すると、何れもメインコアの処理時間よりもハードウェアアクセラレータの処理時間の方が支配的であるが、ＧＣＭＰモードを採用したことでスループットを更に向上させることができる。
　次に、上記した構成の作用について図７２から図７７を参照して説明する。
　（８－１）ＯＴＡセンター２の処理（図７２から図７４参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵と、更新パッケージの改竄を防止するためのＭＡＣ鍵とを生成する（Ａ０８１）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵とＭＡＣ鍵によりＧＣＭＰモードで暗号化し、ＭＡＣを付与する（Ａ０８２）。ＯＴＡセンター２は、ＡＥＳ鍵とＭＡＣ鍵をＲＳＡ公開鍵により暗号化する（Ａ０８３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵とＭＡＣ鍵をキャンペーン通知の中に格納する（Ａ０８４）。ＯＴＡセンター２は、ＡＥＳ鍵とＭＡＣ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ０８５）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵とＭＡＣ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０８６）。
　（８－２）ＯＴＡマスタ４の処理（図７５から図７７参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵とＭＡＣを取得する（Ｂ０８１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵とＭＡＣ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵とＭＡＣ鍵を取出す（Ｂ０８２）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ０８３）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ０８４）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ０８５）。ＯＴＡマスタ４は、復号化された更新パッケージの平文からＭＡＣ鍵を用いてＧＭＡＣモードでＭＡＣを生成して検証する（Ｂ０８６）。ＯＴＡマスタは、ＭＡＣが一致すると、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ０８７）。
　以上に説明したように第８実施形態によれば、以下の作用効果を得ることができる。
　ＯＴＡセンター２とＯＴＡマスタ４との間の通信路暗号化とデータ改竄対策としてＧＣＭＰモードを採用する構成とした。ＧＣＭＰモードを採用したことで、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際に通信路暗号化に加えてデータ改竄対策を備えることができる。これにより、セキュリティを高めることができ、よりセキュアなＯＴＡ配信を実現することができる。
　（第９実施形態）
　第９実施形態について図７８から図８６を参照して説明する。第９実施形態は、更新データの配信経路をＣＤＮ８だけでなく、スマートフォンやＵＳＢメモリ等を採用し、配信経路の多様性に対応することで、ユーザのＯＴＡ更新方式の自由度を高める。スマートフォンやＵＳＢメモリは記録媒体に相当する。これ以降は、記憶媒体としてスマートフォンやＵＳＢメモリを例示して説明するが、記憶媒体としてＳＤカード、マイクロＳＤカード、コンパクトフラッシュ等を採用しても良い。
　次に、上記した構成の作用について図７９から図８６を参照して説明する。
　（９－１）ＯＴＡセンター２の処理（図７９から図８２参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するための共通鍵を生成する（Ａ０９１）。ＯＴＡセンター２は、更新パッケージを、生成された共通鍵により特定の暗号化モードで暗号化する（Ａ０９２）。ＯＴＡセンター２は、共通鍵をＲＳＡ公開鍵により暗号化する（Ａ０９３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化された共通鍵をキャンペーン通知の中に格納する（Ａ０９４）。ＯＴＡセンター２は、共通鍵暗号方式と配信経路を含むＲＰメタデータを生成する（Ａ０９５）。ＯＴＡセンター２は、ＲＰメタデータをＲＳＡ公開鍵により暗号化する（Ａ０９６）。ＯＴＡセンター２は、共通鍵により暗号化された更新パッケージとＲＳＡ公開鍵により暗号化されたＲＰメタデータをＣＤＮ８に配置する（Ａ０９７）。ＯＴＡセンター２は、暗号化された共通鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ０９８）。
　（９－２）ＯＴＡマスタ４の処理（図８３から図８６参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中から暗号化された共通鍵を取得する（Ｂ０９１）。ＯＴＡマスタ４は、暗号化された共通鍵をＲＳＡ秘密鍵により復号化して共通鍵を取出す（Ｂ０９２）。ＯＴＡマスタ４は、暗号化されたＲＰメタデータをＣＤＮ８からダウンロードして取得する（Ｂ０９３）。ＯＴＡマスタ４は、暗号化されたＲＰメタデータＲＳＡ秘密鍵により復号化してＲＰメタデータを取出す（Ｂ０９４）。ＯＴＡマスタ４は、ＲＰメタデータの内容を解釈して共通鍵暗号方式と配信経路を特定する（Ｂ０９５）。ＯＴＡマスタ４は、暗号化された更新パッケージを、その特定した配信経路により取得する（Ｂ０９６）。即ち、ＯＴＡマスタ４は、配信経路としてスマートフォンを特定した場合には、暗号化された更新パッケージをＣＤＮ８からスマートフォンを経由して一括ストレージ方式でダウンロードする。ＯＴＡマスタ４は、配信経路としてＵＳＢメモリを特定した場合には、暗号化された更新パッケージをＣＤＮ８からＵＳＢメモリを経由して一括ストレージ方式でダウンロードする。これ以降、ＯＴＡマスタ４は、特定の暗号化モードとしてＣＴＲモードを採用した場合であれば第１実施形態で説明したステップＢ０１４以降の処理を行い、特定の暗号化モードとしてＯＦＢモードを採用した場合であれば第２実施形態で説明したステップＢ０２４以降の処理を行う。
　以上に説明したように第９実施形態によれば、以下の作用効果を得ることができる。
　更新パッケージをＣＤＮ８からスマートフォンやＵＳＢメモリ等の記録媒体を経由して取得するようにした。更新パッケージの配信経路に多様性を持たせることができ、配信コストやユーザビリティが優位な配信経路を選択することができる。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制すると共に、ユーザ体験価値を向上することができる。尚、上記した実施形態では、ＯＴＡマスタ４は、ステップＢ０９５においてＲＰメタデータの内容を解釈して共通鍵暗号方式と配信経路を特定するが、ＲＰメタデータに複数の配信経路が記載されている場合には、複数の配信経路の中から何れかを選択可能でも良い。
　（第１０実施形態）
　第１０実施形態について図８７から図９８を参照して説明する。第１０実施形態は、更新パッケージのＣＤＮ８への配置先として複数のＣＤＮベンダを配信方式、配信エリアであるＯＴＡ対象エリア、配信データサイズに応じてダイナミックに選定して配信コストを抑制する。ＣＤＮのコスト比較は図８８から図８９に示す通りである。価格テーブルは図９０から図９３に示す通りである。各ＣＤＮベンダは、日本や北米等の配信エリアや配信データサイズ等により価格の優劣が異なっており、例えば図９０を参照すると、月間１００ＴＢのデータサイズを配信する場合、日本ではＣＤＮ２が最安であるが、北米やＥＵにはＣＤＮ１が最安である。この事実をベースに配信方式、ＯＴＡ対象エリア、配信データサイズに応じて配信コストが最安となるＣＤＮベンダを選定する。
　図９４に示すように、ＯＴＡセンター２は、共通鍵生成部２ａと、更新パッケージ暗号化部２ｂと、共通鍵暗号化部２ｃと、共通鍵格納部２ｄと、暗号化パッケージ配置部２ｅと、キャンペーン通知送信部２ｆとに加え、ＣＤＮベンダ選定部２ｊを備える。ＣＤＮベンダ選定部２ｊは、ＣＤＮベンダ管理データベースを参照してＣＤＮベンダを選定する。
　次に、上記した構成の作用について図９５から図９８を参照して説明する。
　（１０－１）ＯＴＡセンター２の処理（図９５から図９８参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ１０１）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する（Ａ１０２）。ＯＴＡセンター２は、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化する（Ａ１０３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵をキャンペーン通知の中に格納する（Ａ１０４）。ＯＴＡセンター２は、配信方式を特定し（Ａ１０５）、ＯＴＡ対象エリアを特定し（Ａ１０６）、配信データサイズを特定し（Ａ１０７）、ＣＤＮベンダ管理データベースから配信方式、ＯＴＡ対象エリア及び配信データサイズをキーにして価格テーブルを参照する（Ａ１０８）。この場合、ＯＴＡセンター２は、ストレージ方式やストリーミング方式といった配信方式、日本や北米やＥＵ（European Union）といったＯＴＡ対象エリア、ＧＢやＴＢやＰＢといった配信データサイズのうち少なくとも何れか一つをキーにして価格テーブルを参照しても良い。ＯＴＡセンター２は、エリア毎に配信コストが最小となるＣＤＮベンダを選定し、ＡＥＳ鍵により暗号化された更新パッケージを当該選定したＣＤＮ８に配置する（Ａ１０９、ＣＤＮベンダ選定手順に相当する）。或いは、ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージを各ＣＤＮ８に配置しても良い。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵と、選定されたＣＤＮベンダにアクセスできるように更新パッケージのデータ格納先やＵＲＩ情報が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１１０）。
　（１０－２）ＯＴＡマスタ４の処理
　ＯＴＡマスタ４の処理は、第１実施形態で説明したＯＴＡマスタ４の処理（図１２から図１４）と同様である。
　以上に説明したように第１０実施形態によれば、以下の作用効果を得ることができる。
　ＣＤＮベンダ管理データベースを参照し、配信コストが異なる複数のＣＤＮ８の中から配信方式、ＯＴＡ対象エリア及び配信データサイズに応じて配信コストが優位なＣＤＮ８を選定し、更新パッケージを当該選定したＣＤＮ８に配置する構成とした。ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制することができる。又、更新パッケージをＯＴＡセンター２にて暗号化することにより、原理的には途中経路をゼロトラストであってもセキュリティ上は支障がなくなる。このため、ＣＤＮ８のエッジ側で更新データを暗号化する必要性がなくなり、ＣＤＮ８の処理負荷やセキュリティ機能を削減することが可能となる。更新パッケージがＯＴＡセンター２からＯＴＡマスタ４に到達するまでに、途中経路でデータ改竄やＣＤＮ８がＤＤｏＳ攻撃を受けたとしてもＯＴＡシステムとしては影響が無く、途中経路に介在するシステムにはインテリジェントなセキュリティ対策、例えばウェブアプリケーションファイアウォールやＴＬＳ通信、配信対象となるＯＴＡマスタ４を限定する署名付きＵＲＬ等の多層防御の安全補助対策を不要にすることが可能である。これにより、原価ベースでＯＴＡシステムのランニングコストを低減することができ、いかなるシステム構成においても配信コストを抑制することができる。
　（第１１実施形態）
　第１１実施形態について図９９から図１０８を参照して説明する。第１１実施形態は、ＯＴＡセンター２とＯＴＡマスタ４との間の鍵配送にディフィー・ヘルマン鍵共有（以下、ＤＨＥ（Diffie-Hellman key exchange）と称する）又は楕円曲線ディフィー・ヘルマン鍵共有（以下、ＥＣＤＨＥ（Elliptic curve Diffie-Hellman key exchange）と称する）を採用すると共に、ＯＴＡセンター２では共有された車両毎に異なる秘密情報に基づいてＡＥＳ鍵を暗号化してＯＴＡマスタ４へ配信することにより、ＥＣＤＨＥの前方秘匿性を確保することができるというメリットを享受しながら、ＣＤＮ８に適用可能な車両モデル又は特定の車両群毎に適用可能な更新パッケージを配信する。
　図１００に示すように、両者でそれぞれの公開鍵（Ａ、Ｂ）を乱数（＝秘密鍵：ａ、ｂ）から生成及び交換し、自身の秘密鍵と組み合わせて計算を行うことで、秘密裏に秘密情報（Ｓ）を共有する。秘密鍵及び公開鍵ペア（ａ／Ａ、ｂ／Ｂ）は、秘密情報（Ｓ）を共有した後は破棄可能であり、ＯＴＡセンター２とＯＴＡマスタ４との双方でＨＳＭ（ハードウェアセキュリティモジュール）に格納しておく必要がないため、非常にセキュアに秘密情報（Ｓ）を共有することができる。この共有した秘密情報（Ｓ）は、共通鍵暗号の鍵等に活用可能であるが、元データが乱数のため（ａ、ｂ）、ＯＴＡマスタ４毎に異なる鍵となる。
　次に、上記した構成の作用について図１０１から図１０８を参照して説明する。
　（１１－１）ＯＴＡセンター２の処理（図１０１から図１０４参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ１１１）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する（Ａ１１２）。ＯＴＡセンター２は、乱数からＥＣＤＨＥの鍵ペアを生成する（Ａ１１３）。ＯＴＡセンター２は、ＥＣＤＨＥのアルゴリズムでＯＴＡマスタ４と秘密鍵を共有する（Ａ１１４、秘密情報共有手順に相当する）。ＯＴＡセンター２は、ＡＥＳ鍵を秘密鍵により暗号化する（Ａ１１５）。ＯＴＡセンター２は、秘密鍵により暗号化されたＡＥＳ鍵をキャンペーン通知の中に格納する（Ａ１１６）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ１１７）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１１８、暗号鍵配信手順に相当する）。
　ここで、ステップＡ１１４について説明する。車両のイグニッションがオンされ、前回の車両構成情報の同期から所定期間が経過していると、ＯＴＡマスタ４は、車両に搭載されたＥＣＵにプログラムバージョンを問合せて車両構成情報を収集する。或いはＯＴＡマスタ４は、ＯＴＡセンター２からキャンペーンに関するプッシュ通知を受信すると、ＥＣＵにプログラムバージョンを問合せて車両構成情報を収集する。ＯＴＡマスタ４は、車両構成情報を収集すると、ＯＴＡセンター２との間でＴＬＳ通信を確立し、車両構成情報をＯＴＡセンター２へ送信する。このとき、ＯＴＡマスタ４は、車両構成情報を収集すると共に、ＥＣＤＨＥの鍵ペアを生成しており、ＯＴＡセンター２との間でＴＬＳ通信を確立すると、鍵ペアのうちＯＴＡマスタ４の公開鍵をＯＴＡセンター２へ送信する。尚、ＯＴＡマスタ４が車両構成情報を収集する工程は、他の実施形態にも適用される。ＯＴＡセンター２は、ＯＴＡマスタ４から取得したＯＴＡマスタ４の公開鍵とＯＴＡセンター２の秘密鍵に基づいてＥＣＤＨＥのアルゴリズムでの秘密鍵を取得する。
　（１１－２）ＯＴＡマスタ４の処理（図１０５から図１０８参照）
　ＯＴＡマスタ４は、乱数からＥＣＤＨＥの鍵ペアを生成する（Ｂ１１１）。ＯＴＡマスタ４は、ＥＣＤＨＥのアルゴリズムでＯＴＡセンター２と秘密鍵を共有する（Ｂ１１２、秘密情報共有手順に相当する）。ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵を取得する（Ｂ１１３）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵を秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ１１４）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ１１５）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ１１６）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ１１７）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１１８）。
　以上に説明したように第１１実施形態によれば、以下の作用効果を得ることができる。
　ＯＴＡセンター２とＯＴＡマスタ４との間の鍵配送にＤＨＥ又はＥＣＤＨＥを採用し、ＯＴＡセンター２では共有された車両毎に異なる秘密情報に基づいてＡＥＳ鍵を暗号化してＯＴＡマスタ４へ配信する構成とした。これにより、ＥＣＤＨＥの前方秘匿性を適切に確保しつつ、ＣＤＮ８による更新データの効率的な配信を適切に実現することができる。
　（第１１実施形態の変形例）
　第１１実施形態の変形例について図１６６から図１７３を参照して説明する。第１１実施形態では、車両に無線通信装置が搭載され、ＯＴＡマスタ４がＯＴＡセンター２やＣＤＮ８と無線通信回線を介してデータを送受信可能であることを前提として説明した。しかしながら、車両に無線通信装置が搭載されていない場合や、ユーザが無線通信回線の使用を好まない場合もある。第１１実施形態の変形例では、ＯＴＡマスタ４がＯＴＡセンター２やＣＤＮ８と無線通信回線を介してデータを送受信せず、代わりに例えばＳＤカード等の記憶媒体を用いてプログラム更新を実施する状況を説明する。
　ＯＴＡマスタ４及びＯＴＡセンター２は、外部とのデータ転送に記憶媒体を用いる。ＯＴＡマスタ４と記憶媒体との間のデータ転送は、車両に設置されている記憶媒体のためのポートを用いる。車両に設置されているポートは、例えばカーナビゲーション装置、センターディスプレイ装置、その他の車両制御装置に設置されているポート等である。
　ＯＴＡセンター２と記憶媒体との間のデータ転送は、記憶媒体をパーソナルコンピュータ（以下、ＰＣと称する）に接続して行う。例えば記憶媒体をＰＣに接続し、ＯＴＡセンター２やＣＤＮ８のウェブサイトにアクセスし、記憶媒体に保存されているデータを、ＰＣを操作することでＯＴＡセンター２へアップロードしたり、ＯＴＡセンター２に保存されているデータを、ＰＣを操作することで記憶媒体へダウンロードしたりする。尚、記憶媒体に対応したスマートフォン、タブレット端末等をＰＣの代わりに用いることもできる。記憶媒体に対応したＰＣ、スマートフォン、タブレット端末等を操作端末とも称する。
　図１６６から図１６９を参照し、記憶媒体としてＳＤカードを使用した場合について説明する。この場合、ＯＴＡマスタ４からＳＤカード１１へのデータの転送、ＳＤカード１１からＯＴＡセンター２へのデータのアップロード、ＯＴＡセンター２からＳＤカード１１へのデータのダウンロード、ＳＤカード１１からＯＴＡマスタ４へのデータの転送の順序で処理を行う。
　図１６６を参照し、ＯＴＡマスタ４からＳＤカード１１へのデータの転送を説明する。ＯＴＡマスタ４は、ターゲットＥＣＵ５からソフトウェアバージョン情報等を取得し、その取得したソフトウェアバージョン情報等を車両構成情報としてＳＤカード１１へ転送して保存する。ＯＴＡマスタ４は、乱数からＥＣＤＨＥの鍵ペアを生成し、ＥＣＤＨＥ公開鍵をＳＤカード１１へ転送して保存する。ＳＤカード１１は、ＯＴＡマスタ４から転送された車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を保存する。
　図１６７を参照し、ＳＤカード１１が接続されたＰＣからＯＴＡセンター２へのデータのアップロードを説明する。ＰＣは、ＳＤカード１１が接続されると、ＳＤカード１１に保存されている車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を読出し、その読出した車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＯＴＡセンター２へアップロードする。ＯＴＡセンター２へアップロードされた車両構成情報はＰＫＧ生成サーバ６においてキャンペーン有無の判定に用いられる。ＯＴＡセンター２へアップロードされたＯＴＡマスタ４のＥＣＤＨＥ公開鍵は配信サーバ７においてＥＣＤＨＥのアルゴリズムに基づいて秘密鍵を共有する。この場合の秘密鍵は、車両毎に異なる秘密鍵である。
　図１６８を参照し、ＯＴＡセンター２からＳＤカード１１へのデータのダウンロードについて説明する。ここでは、キャンペーンがある場合を示している。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＳＤカード１１へダウンロードして保存する。ＯＴＡセンター２は、乱数からＥＣＤＨＥの鍵ペアを生成し、ＯＴＡマスタ４と共有すべき鍵（ＯＴＡセンター２のＥＣＤＨＥ公開鍵）をＳＤカード１１へダウンロードして保存する。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をＳＤカード１１へダウンロードして保存する。ＳＤカード１１は、ＯＴＡセンター２からダウンロードされた更新パッケージ、ＯＴＡセンター２のＥＣＤＨＥ公開鍵及び暗号化されたＡＥＳ鍵を保存する。
　図１６９を参照し、ＳＤカード１１からＯＴＡマスタ４へのデータの転送を説明する。ＯＴＡマスタ４は、ＳＤカード１１に保存されている暗号化された更新パッケージ、ＯＴＡセンター２のＥＣＤＨＥ公開鍵及び暗号化されたＡＥＳ鍵をＳＤカード１１から読出して取得する。
　次に、上記した構成の作用について図１７０から図１７４を参照して説明する。
　（１１－３）ＯＴＡマスタ４の処理（図１７０参照）
　ＯＴＡマスタ４は、ＳＤカード１１が車両側システム３に接続されており、所定条件が満たされると、ソフトウェアバージョン情報等の構成情報の送信をターゲットＥＣＵ５へ要求し、ターゲットＥＣＵ５から送信されたソフトウェアバージョン情報等の構成情報を車両構成情報として取得する（Ｂ１１１１）。ＯＴＡマスタ４は、車両構成情報を取得すると、その取得した車両構成情報をＳＤカード１１へ転送して保存する（Ｂ１１１２）。ＯＴＡマスタ４は、乱数からＥＣＤＨＥの鍵ペアを生成する（Ｂ１１１３）。この場合、鍵ペアはＯＴＡマスタ４のＥＣＤＨＥ公開鍵とＥＣＤＨＥ秘密鍵とを含む。ＯＴＡマスタ４は、ＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＳＤカード１１へ転送して保存する（Ｂ１１１４）。ＳＤカード１１は、このようにして車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵が保存されると、車両側システム３との接続が解除され、ＰＣに接続される。
　（１１－４）ＰＣの処理（図１７１参照）
　ＰＣは、ＳＤカード１１が接続されていると、ＳＤカード１１に保存されている車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を読出し、その読出した車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＯＴＡセンター２へアップロードする（Ｃ１１１１）。ＰＣは、ＯＴＡセンター２からＯＴＡマスタ４のＥＣＤＨＥ公開鍵、ＡＥＳ鍵が格納されているキャンペーン通知、暗号化された更新パッケージの受信を待機すると共に、キャンペーンなし通知の受信を待機する（Ｃ１１１２、Ｃ１１１３）。ＰＣは、ＯＴＡセンター２からＯＴＡマスタ４のＥＣＤＨＥ公開鍵、ＡＥＳ鍵が格納されているキャンペーン通知、暗号化された更新パッケージを受信したと判定すると（Ｃ１１１２：ＹＥＳ）、又はキャンペーンなし通知を受信したと判定すると（Ｃ１１１３：ＹＥＳ）、処理を終了する。
　（１１－５）ＯＴＡセンター２の処理（図１７２参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成し、更新パッケージをＡＥＳ鍵によりＣＴＲモードにて暗号化する。ＯＴＡセンター２は、ＳＤカード１１が接続されているＰＣからアップロードされた車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を取得する（Ａ１１１１）。ＯＴＡセンター２は、車両構成情報に基づいてキャンペーンがあるか否かを判定する（Ａ１１１２）。ＯＴＡセンター２は、キャンペーンがないと判定すると（Ａ１１１２：ＮＯ）、キャンペーンなし通知をＰＣへ送信し（Ａ１１１３）、処理を終了する。
　ＯＴＡセンター２は、キャンペーンがあると判定すると（Ａ１１１２：ＹＥＳ）、乱数からＥＣＤＨＥの鍵ペアを生成する（Ａ１１１４）。この場合、鍵ペアはＯＴＡセンター２のＥＣＤＨＥ公開鍵とＥＣＤＨＥ秘密鍵である。ＯＴＡセンター２は、ＯＴＡセンター２のＥＣＤＨＥ公開鍵をＳＤカード１１へダウンロードして保存する（Ａ１１１５）。ＯＴＡセンター２は、ＯＴＡセンター２のＥＣＤＨＥ秘密鍵とＯＴＡマスタ４のＥＣＤＨＥ公開鍵からＥＣＤＨＥ共通鍵（秘密鍵）を生成し（Ａ１１１６）、その生成したＥＣＤＨＥ共通鍵（秘密鍵）によりＡＥＳ鍵を暗号化する（Ａ１１１７）。ＯＴＡセンター２は、その暗号化したＡＥＳ鍵をキャンペーン通知に格納し、その暗号化したＡＥＳ鍵を格納したキャンペーン通知をＳＤカード１１へダウンロードして保存する（Ａ１１１８）。ＯＴＡセンター２は、暗号化された更新パッケージをＳＤカード１１へダウンロードして保存する（Ａ１１１９）。
　（１１－６）ＯＴＡマスタ４の処理（図１７３参照）
　ＯＴＡマスタ４は、ＳＤカード１１が車両側システム３に接続されていると、ＳＤカード１１からＯＴＡセンター２のＥＣＤＨＥ公開鍵、キャンペーン通知、更新パッケージを取得する（Ｂ１１２１）。ＯＴＡマスタ４は、ＯＴＡマスタ４のＥＣＤＨＥ秘密鍵とＯＴＡセンター２のＥＣＤＨＥ公開鍵からＥＣＤＨＥ共通鍵（秘密鍵）を生成する（Ｂ１１２２）。ＯＴＡマスタ４は、キャンペーン通知から暗号化されたＡＥＳ鍵を取出し、ＥＣＤＨＥ共通鍵（秘密鍵）により復号化する（Ｂ１１２３）。ＯＴＡマスタ４は、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ１１２４）。ＯＴＡマスタ４は、暗号化されたカウンター値と、暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ１１２５）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１１２６）。
　このような構成によれば、車両側システム３の無線通信機能に依存することなく、ＥＣＤＨＥの前方秘匿性を適切に確保しつつ、ＣＤＮ８による更新データの効率的な配信を適切に実現することができる。又、ＯＴＡマスタ４とＳＤカード１１との間のデータ転送と、ＯＴＡセンター２とＳＤカード１１との間のアップロードやダウンロードの回数を抑制することで、ユーザにとっての利便性を高めることができる。
　（第１２実施形態）
　第１２実施形態について図１０９から図１１５を参照して説明する。第１２実施形態は、ＥＣＤＨＥの鍵共有において、ＯＴＡセンター２で生成する乱数ａを、車両モデル毎の乱数（特定のルールにしたがった乱数）とし、ＯＴＡマスタ４で生成する乱数ｂを、車両モデル毎の固定値、カウントアップ値、又はＯＴＡマスタ４のソフトウェアバージョンのハッシュ値の何れか一つ、或いはこれらの組み合わせを利用することにより、ＥＣＤＨＥで共有する秘密鍵を車両モデル毎に共通とし、ＥＣＤＨＥの前方秘匿性を確保するメリットを享受しながら、鍵を配送する処理を省略し、車両モデル又は特定の車両群毎に適用可能な暗号化パッケージをＣＤＮ配信する。
　次に、上記した構成の作用について図１１０から図１１５を参照して説明する。
　（１２－１）ＯＴＡセンター２の処理（図１１０から図１１２参照）
　ＯＴＡセンター２は、車両モデル毎又は車両群毎に共通となる乱数からＥＣＤＨＥの鍵ペアを生成する（Ａ１２１）。ＯＴＡセンター２は、ＥＣＤＨＥのアルゴリズムでＯＴＡマスタ４と秘密鍵を共有する（Ａ１２２、秘密情報共有手順に相当する）。本実施形態では、ＥＣＤＨＥのアルゴリズムでＯＴＡマスタ４と共有する秘密鍵を、更新パッケージを暗号化するためのＡＥＳ鍵として使用する。更に、ＯＴＡマスタ４は、暗号化された更新パッケージを復号化するためのＡＥＳ鍵としてＯＴＡセンター２と共有した秘密鍵を使用する。ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ１２３）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する（Ａ１２４）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ１２５）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１２６、暗号鍵配信手順に相当する）。
　（１２－２）ＯＴＡマスタ４の処理（図１１３から図１１５参照）
　ＯＴＡマスタ４は、上記で説明した特定のルールにしたがって生成した乱数からＥＣＤＨＥの鍵ペアを生成する（Ｂ１２１）。ＯＴＡセンター２は、ＥＣＤＨＥのアルゴリズムでＯＴＡセンター２と秘密鍵を共有する（Ｂ１２２、秘密情報共有手順に相当する）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ１２３）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ１２４）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ１２５）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１２６）。
　以上に説明したように第１２実施形態によれば、以下の作用効果を得ることができる。
　ＯＴＡセンター２とＯＴＡマスタ４との間の鍵配送にＤＨＥ又はＥＣＤＨＥを採用し、ＥＣＤＨＥで共有する秘密鍵を車両モデル毎に共通とする構成とした。これにより、ＥＣＤＨＥの前方秘匿性を適切に確保しつつ、第１１実施形態と比べて鍵配送の手間を簡略化しながら、ＣＤＮ８による更新データの効率的な配信を適切に実現することができる。
　（第１２実施形態の変形例）
　第１２実施形態の変形例について図１７４から図１８１を参照して説明する。第１２実施形態の変形例でも、第１１実施形態の変形例と同様に、ＯＴＡマスタ４がＯＴＡセンター２やＣＤＮ８と無線通信回線を介してデータを送受信せず、代わりに例えばＳＤカード等の記憶媒体を用いてプログラム更新を実施する状況を説明する。
　図１７４を参照し、ＯＴＡマスタ４からＳＤカード１１へのデータの転送を説明する。ＯＴＡマスタ４は、ターゲットＥＣＵ５からソフトウェアバージョン情報等を取得し、その取得したソフトウェアバージョン情報等を車両構成情報としてＳＤカード１１へ転送して保存する。ＯＴＡマスタ４は、車両モデル毎の固定値、カウントアップ値、又はＯＴＡマスタ４のソフトウェアバージョンのハッシュ値の何れか一つ、或いはこれらの組み合わせを利用して車両モデル毎に共通するＥＣＤＨＥの鍵ペアを生成し、ＯＴＡセンター２と共有すべき鍵（ＯＴＡマスタ４のＥＣＤＨＥ公開鍵）をＳＤカード１１へ転送して保存する。車両モデル毎の固定値、カウントアップ値、又はＯＴＡマスタ４のソフトウェアバージョンのハッシュ値の何れか一つ、或いはこれらの組み合わせは特定のルールに相当する。ＳＤカード１１は、ＯＴＡマスタ４から転送された車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を保存する。
　図１７５を参照し、ＳＤカード１１が接続されたＰＣからＯＴＡセンター２へのデータのアップロードを説明する。ＰＣは、ＳＤカード１１が接続されると、ＳＤカード１１に保存されている車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を読出し、その読出した車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＯＴＡセンター２へアップロードする。ＯＴＡセンター２へアップロードされた車両構成情報はＰＫＧ生成サーバ６においてキャンペーン有無の判定に用いられる。又、ＯＴＡセンター２へアップロードされたＯＴＡマスタ４のＥＣＤＨＥ公開鍵は配信サーバ７においてＥＣＤＨＥのアルゴリズムに基づいて秘密鍵を共有する。この場合の秘密鍵は、車両モデル毎に共通する秘密鍵である。
　図１７６を参照して、ＯＴＡセンター２からＳＤカード１１へのデータのダウンロードについて説明する。ＯＴＡセンター２は、車両モデル毎又は車両群毎に共通となる乱数からＥＣＤＨＥの鍵ペアを生成し、ＯＴＡマスタ４と共有すべき鍵（ＯＴＡセンター２のＥＣＤＨＥ公開鍵）をＳＤカード１１へダウンロードして保存する。ＯＴＡセンター２は、ＥＣＤＨＥで共有できた秘密鍵をＡＥＳ鍵として用いることで更新パッケージを暗号化し、暗号化された更新パッケージをＳＤカード１１へダウンロードして保存する。ＳＤカード１１は、ＯＴＡセンター２からダウンロードされたＯＴＡセンター２のＥＣＤＨＥ公開鍵、更新パッケージを保存する。
　図１７７を参照し、ＳＤカード１１からＯＴＡマスタ４へのデータの転送を説明する。ＯＴＡマスタ４は、ＳＤカード１１に保存されている暗号化された更新パッケージ及びＯＴＡセンター２のＥＣＤＨＥ公開鍵を読出して取得する。ＯＴＡマスタ４は、ＥＣＤＨＥのアルゴリズムに基づいて秘密鍵を共有する。ＯＴＡマスタ４は、ＥＣＤＨＥで共有できた秘密鍵をＡＥＳ鍵として用い、暗号化された更新パッケージを復号化する。
　次に、上記した構成の作用について図１７８から図１８１を参照して説明する。
　（１２－３）ＯＴＡマスタ４の処理（図１７８参照）
　ＯＴＡマスタ４は、ＳＤカード１１が車両側システム３に接続されており、所定条件が満たされると、ソフトウェアバージョン情報等の構成情報の送信をターゲットＥＣＵ５へ要求し、ターゲットＥＣＵ５から送信されたソフトウェアバージョン情報等の構成情報を車両構成情報として取得する（Ｂ１２１１）。ＯＴＡマスタ４は、車両構成情報を取得すると、その取得した車両構成情報をＳＤカード１１へ転送して保存する（Ｂ１２１２）。ＯＴＡマスタ４は、特定のルールにしたがって生成した乱数からＥＣＤＨＥの鍵ペアを生成する（Ｂ１２１３）。この場合、鍵ペアはＯＴＡマスタ４のＥＣＤＨＥ公開鍵とＥＣＤＨＥ秘密鍵とを含む。ＯＴＡマスタ４は、ＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＳＤカード１１へ転送して保存する（Ｂ１２１４）。ＥＣＤＨＥの鍵ペアは、第１２実施形態と同様に特定のルールにしたがって生成された乱数であって車両モデル毎に共通となる。ＳＤカード１１は、このようにして車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵が保存されると、車両側システム３との接続が解除され、ＰＣに接続される。
　（１２－４）ＰＣの処理（図１７９参照）
　ＰＣは、ＳＤカード１１が接続されていると、ＳＤカード１１に保存されている車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を読出し、その読出した車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＯＴＡセンター２へアップロードする（Ｃ１２１１）。ＰＣは、ＯＴＡセンター２からＯＴＡマスタ４のＥＣＤＨＥ公開鍵が格納されているキャンペーン通知、暗号化された更新パッケージの受信を待機すると共に、キャンペーンなし通知の受信を待機する（Ｃ１２１２、Ｃ１２１３）。ＰＣは、ＯＴＡセンター２からＯＴＡマスタ４のＥＣＤＨＥ公開鍵が格納されているキャンペーン通知、暗号化された更新パッケージを受信したと判定すると（Ｃ１２１２：ＹＥＳ）、又はキャンペーンなし通知を受信したと判定すると（Ｃ１２１３：ＹＥＳ）、処理を終了する。
　（１２－５）ＯＴＡセンター２の処理（図１８０参照）
　ＯＴＡセンター２は、ＳＤカード１１が接続されているＰＣからアップロードされた車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を取得する（Ａ１２１１）。ＯＴＡセンター２は、車両構成情報に基づいてキャンペーンがあるか否かを判定する（Ａ１２１２）。ＯＴＡセンター２は、キャンペーンがないと判定すると（Ａ１２１２：ＮＯ）、キャンペーンなし通知をＰＣへ送信し（Ａ１２１３）、処理を終了する。
　ＯＴＡセンター２は、キャンペーンがあると判定すると（Ａ１２１２：ＹＥＳ）、車両モデル毎又は車両群毎に共通となる乱数からＥＣＤＨＥの鍵ペアを生成する（Ａ１２１４）。この場合、鍵ペアはＯＴＡセンター２のＥＣＤＨＥ公開鍵とＥＣＤＨＥ秘密鍵である。ＯＴＡセンター２は、ＯＴＡセンター２のＥＣＤＨＥ公開鍵をＳＤカード１１へダウンロードして保存する（Ａ１２１５）。ＯＴＡセンター２は、ＯＴＡセンター２のＥＣＤＨＥ秘密鍵とＯＴＡマスタ４のＥＣＤＨＥ公開鍵からＥＣＤＨＥ共通鍵（秘密鍵）を生成し（Ａ１２１６）、その生成したＥＣＤＨＥ共通鍵（秘密鍵）により更新パッケージを暗号化する（Ａ１２１７）。ＯＴＡセンター２は、暗号化された更新パッケージをＳＤカード１１へダウンロードして保存する（Ａ１２１８）。
　（１２－６）ＯＴＡマスタ４の処理（図１８１参照）
　ＯＴＡマスタ４は、ＳＤカード１１が車両側システム３に接続されていると、ＳＤカード１１からＯＴＡセンター２のＥＣＤＨＥ公開鍵、更新パッケージを取得する（Ｂ１２２１）。ＯＴＡマスタ４は、ＯＴＡマスタ４のＥＣＤＨＥ秘密鍵とＯＴＡセンター２のＥＣＤＨＥ公開鍵からＥＣＤＨＥ共通鍵（秘密鍵）を生成する（Ｂ１２２２）。ＯＴＡマスタ４は、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ１２２３）。ＯＴＡマスタ４は、暗号化されたカウンター値と、暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ１２２４）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１２２５）。
　このような構成によれば、車両側システム３の無線通信機能に依存することなく、ＥＣＤＨＥの前方秘匿性を適切に確保しつつ、第１１実施形態と比べて鍵配送の手間を簡略化しながら、ＣＤＮ８による更新データの効率的な配信を適切に実現することができる。又、ＯＴＡマスタ４とＳＤカード１１との間のデータ転送と、ＯＴＡセンター２とＳＤカード１１との間のアップロードやダウンロードの回数を抑制することで、ユーザにとっての利便性を高めることができる。
　（第１３実施形態）
　第１３実施形態について図１１６から図１２４を参照して説明する。第１３実施形態は、ＣＴＲモードを単純に適用するのではなく、カウンター値に工夫を持たせることで、よりセキュアにする。具体的には、ＯＴＡセンター２とＯＴＡマスタ４との間で最初に通信するキャンペーン通知の中にノンスを入れ込み、ノンスをカウンター値に入れ込むことで、ＣＴＲモードの安全化を図る。ＣＴＲモードのノンスを入れ込む暗号化処理は図１１７に示す通りであり、ＣＴＲモードのノンスを入れ込む復号化処理は図１１８に示す通りである。
　次に、上記した構成の作用について図１１９から図１２４を参照して説明する。
　（１３－１）ＯＴＡセンター２の処理（図１１９から図１２１参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ１３１）。ＯＴＡセンター２は、乱数によるノンスを生成する（Ａ１３２）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵とノンスによりＣＴＲモードで暗号化する（Ａ１３３）。ＯＴＡセンター２は、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化する（Ａ１３４）。ＯＴＡセンター２は、ＡＥＳ鍵をＲＳＡ公開鍵により暗号化すると同時に、ノンスもＲＳＡ公開鍵により暗号化しても良い。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ鍵とノンスをキャンペーン通知の中に格納する（Ａ１３５）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ１３６）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵とノンスが格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１３７）。
　（１３－２）ＯＴＡマスタ４の処理（図１２２から図１２４参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ鍵とノンスを取得する（Ｂ１３１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ鍵をＲＳＡ秘密鍵により復号化してＡＥＳ鍵を取出す（Ｂ１３２）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ１３３）。ＯＴＡマスタ４は、ＣＤＮ８からダウンロードされている暗号化された更新パッケージをＡＥＳ鍵とノンスにより復号化する（Ｂ１３４）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１３５）。
　以上に説明したように第１３実施形態によれば、以下の作用効果を得ることができる。
　ＯＴＡセンター２とＯＴＡマスタ４との間で最初に通信するキャンペーン通知の中にノンスを入れ込み、ノンスをカウンター値に入れ込む構成とした。これにより、ノンスをカウンター値に入れ込むことで、ＣＴＲモードの安全化を図ることができる。
　（第１４実施形態）
　第１４実施形態について図１２５から図１３２を参照して説明する。第１４実施形態は、暗号化に使用する鍵について、鍵危殆化時の影響範囲を狭めるために全ての車両で共通の鍵を使うのではなく、特定の車両群の単位毎に個別化した派生鍵を使用することで、ＣＤＮ８の配信キャッシュ効率を維持しながら鍵漏洩時の損失を局所化し、よりセキュアにＯＴＡ配信する。図１２６に示すように、同一の車両モデル及び年式に対してＶＩＮ番号を複数に区分し、区分毎に異なるＡＥＳ個別鍵を使用する。例えばＶＩＮ番号ＡＡＡ～ＣＣＣ、ＶＩＮ番号ＤＤＤ～ＫＫＫ、ＶＩＮ番号ＳＳＳ～ＺＺＺで区分し、異なるＡＥＳ個別鍵を使用する。個別鍵データベースは、例えばＯＥＭコード、車両モデル、年式、ＡＥＳマスタ鍵、シード値、ＶＩＮ番号で区切られたＡＥＳ個別鍵を含む。
　次に、上記した構成の作用について図１２７から図１３２を参照して説明する。
　（１４－１）ＯＴＡセンター２の処理（図１２７から図１２９参照）
　ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ個別鍵を、ＡＥＳマスタ鍵とシード値から生成する（Ａ１４１）。シード値は、例えば乱数、カウンター値、タイムスタンプ等である。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ個別鍵の一つとノンスによりＣＴＲモードで暗号化する（Ａ１４２）。ＯＴＡセンター２は、ＡＥＳ個別鍵をＲＳＡ公開鍵により暗号化する（Ａ１４３）。ＯＴＡセンター２は、ＲＳＡ公開鍵により暗号化されたＡＥＳ個別鍵とノンスをキャンペーン通知の中に格納する（Ａ１４４）。ＯＴＡセンター２は、ＡＥＳ個別鍵の一つとノンスにより暗号化された更新パッケージをＣＤＮ８に配置する（Ａ１４５）。ＯＴＡセンター２は、暗号化されたＡＥＳ個別鍵とノンスが格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１４６）。
　（１４－２）ＯＴＡマスタ４の処理（図１３０から図１３２参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されたことでキャンペーン通知を取得すると、その取得したキャンペーン通知の中からＡＥＳ個別鍵とノンスを取得する（Ｂ１４１）。ＯＴＡマスタ４は、暗号化されたＡＥＳ個別鍵をＲＳＡ秘密鍵により復号化してＡＥＳ個別鍵を取出す（Ｂ１４２）。ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得する（Ｂ１４３）。ＯＴＡマスタ４は、ＣＤＮ８からダウンロードされている暗号化された更新パッケージをＡＥＳ個別鍵とノンスにより復号化する（Ｂ１４４）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１４５）。
　以上に説明したように第１４実施形態によれば、以下の作用効果を得ることができる。
　暗号化に使用する鍵について全ての車両で共通の鍵を使うのではなく、特定の車両群の単位毎に個別化した派生鍵を使用する構成とした。ＣＤＮ８の配信キャッシュ効率を維持しながら鍵漏洩時の損失を局所化することができる。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際のセキュリティ性を高めることができ、よりセキュアなＯＴＡ配信を実現することができる。
　（第１５実施形態）
　第１５実施形態について図１３３から図１３７を参照して説明する。第１５実施形態は、最悪の事態である秘密鍵漏洩のケースに備えてＯＴＡで鍵更新可能なように鍵バージョンを付与してＯＴＡセンター２で管理すると共に、鍵更新用鍵をＯＴＡマスタのＨＳＭ領域に格納する。ＯＴＡセンター２は、ＡＥＳ鍵の暗号化に用いるＲＳＡ公開鍵とその復号化に用いられるＲＳＡ秘密鍵のバージョン情報を管理している。バージョン情報を管理することで、ＲＳＡ秘密鍵及びＲＳＡ公開鍵を更新する際にダウングレードされないようにする。ＯＴＡセンター２とＯＴＡマスタ４は、秘密鍵の更新の際に用いる鍵更新用鍵を備える。ＯＴＡセンター２において、秘密鍵漏洩時又は定期間隔で新しい秘密鍵ペアを生成すると共に、鍵更新用鍵を用いて鍵更新パッケージを生成し、鍵更新パッケージをＯＴＡマスタ４へ送信することで、秘密鍵の鍵更新を実現する。
　次に、上記した構成の作用について図１３４から図１３７を参照して説明する。
　（１５－１）ＯＴＡセンター２の処理（図１３４から図１３５参照）
　ＯＴＡセンター２は、新ＲＳＡ秘密鍵と新ＲＳＡ公開鍵の新しい鍵ペアを生成する（Ａ１５１）。ＯＴＡセンター２は、生成された新ＲＳＡ秘密鍵を鍵更新用鍵によりＣＴＲモードで暗号化及びＭＡＣ演算し、鍵更新パッケージを生成する（Ａ１５２）。ＯＴＡセンター２は、旧ＲＳＡ公開鍵を新ＲＳＡ公開鍵に切替える（Ａ１５３）。ＯＴＡセンター２は、鍵更新パッケージをリプログ対象の車両側システム３へ送信する（Ａ１５４）。
　（１５－２）ＯＴＡマスタ４の処理（図１３６から図１３７参照）
　ＯＴＡマスタ４は、鍵更新パッケージを取得し、新ＲＳＡ秘密鍵を鍵更新用鍵によりＣＴＲモードで復号化及びＭＡＣ検証する（Ｂ１５１）。ＯＴＡマスタ４は、旧ＲＳＡ秘密鍵を、復号化された新ＲＳＡ秘密鍵に切替える（Ｂ１５２）。
　以上に説明したように第１５実施形態によれば、以下の作用効果を得ることができる。
　秘密鍵漏洩時又は定期間隔で新しい秘密鍵ペアを生成すると共に、鍵更新用鍵を用いて鍵更新パッケージを生成し、鍵更新パッケージをＯＴＡマスタ４へ送信する構成とした。これにより、秘密鍵の鍵更新を行うことで、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際のセキュリティ性を高めることができ、よりセキュアなＯＴＡ配信を実現することができる。
　（第１６実施形態）
　第１６実施形態について図１３８から図１４５を参照して説明する。第１６実施形態は、ＥＣＤＨＥの鍵共有において、中間者攻撃に対抗するようにデジタル署名を付与して暗号化パッケージに適用可能な鍵をセキュアにＯＴＡセンター２とＯＴＡマスタ４との間の鍵共有を実現する。図１３９から図１４０に示すように、ＤＨＥは中間攻撃者からの攻撃に対して脆弱であるが、デジタル署名を付与することで中間攻撃者からの攻撃に対抗する。デジタル署名としてはＲＳＡ又は楕円曲線ＤＳＡの暗号アルゴリズムを用いたデジタル署名を用いる。
　次に、上記した構成の作用について図１４１から図１４５を参照して説明する。
　（１６－１）ＯＴＡセンター２の処理（図１４１から図１４３参照）
　ＯＴＡセンター２は、車両モデル毎又は車両群毎に作成した乱数からＥＣＤＨＥの鍵ペアを生成する（Ａ１６１）。ＯＴＡセンター２は、ＥＣＤＨＥ鍵をＲＳＡ秘密鍵でデジタル署名を付与する（Ａ１６２）。ここでは、ＲＳＡ秘密鍵としているが、ＲＳＡ秘密鍵に限定するものではなく、公開鍵暗号方式であれば代替可能であり、例えばＥＣＤＳＡ（Elliptic Curve Digital Signature Algorithm）秘密鍵でも良い。ＯＴＡセンター２は、デジタル署名が付与されたＥＣＤＨＥ公開鍵をリプログ対象の車両側システム３へ送信する（Ａ１６３）。ＯＴＡセンター２は、ＥＣＤＨＥのアルゴリズムでＯＴＡマスタ４と秘密鍵を共有する（Ａ１６４）。ＯＴＡセンター２は、更新パッケージを暗号化するためのＡＥＳ鍵を生成する（Ａ１６５）。ＯＴＡセンター２は、更新パッケージを、生成されたＡＥＳ鍵によりＣＴＲモードで暗号化する（Ａ１６６）。ＯＴＡセンター２は、ＡＥＳ鍵により暗号化された更新パッケージをＣＤＮ８に配置する（Ａ１６７）。ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１６８）。
　（１６－２）ＯＴＡマスタ４の処理（図１４４から図１４５参照）
　ＯＴＡマスタ４は、特定のルールにしたがって生成した乱数からＥＣＤＨＥの鍵ペアを生成する（Ｂ１６１）。ＯＴＡマスタ４は、ＯＴＡセンター２から受信したＥＣＤＨＥ公開鍵をＲＳＡ公開鍵でデジタル署名検証する（Ｂ１６２）。ここでも、ＯＴＡセンター２と同様に、ＲＳＡ公開鍵に限定するものではなく、公開鍵暗号方式であれば代替可能であり、例えばＥＣＤＳＡ公開鍵でも良い。ＯＴＡマスタ４は、検証結果が正であれば、ＥＣＤＨＥのアルゴリズムでＯＴＡセンター２と秘密鍵を共有する（Ｂ１６３）。これ以降、ＯＴＡマスタ４は、第１１実施形態で説明したステップＢ１１３以降の処理を行う。
　以上に説明したように第１６実施形態によれば、以下の作用効果を得ることができる。
　ＥＣＤＨＥの鍵共有においてデジタル署名を付与する構成とした。これにより、デジタル署名を付与することで、中間攻撃者からの攻撃に対抗することができ、よりセキュアなＯＴＡ配信を実現することができる。
　（第１６実施形態の変形例）
　第１６実施形態の変形例について図１８２から図１８９を参照して説明する。第１６実施形態の変形例でも、第１１実施形態及び第１２実施形態の変形例と同様に、ＯＴＡマスタ４がＯＴＡセンター２やＣＤＮ８と無線通信回線を介してデータを送受信せず、代わりに例えばＳＤカード等の記憶媒体を用いてプログラム更新を実施する状況を説明する。第１６実施形態の変形例における第１２実施形態の変形例との主な違いは、ＯＴＡセンター２のＥＣＤＨＥ公開鍵を公開鍵暗号方式の鍵にてデジタル署名を施すことで中間攻撃者からの攻撃に対抗する点にある。
　図１８２から図１８５では、それぞれＯＴＡマスタ４からＳＤカード１１へのデータの転送、ＳＤカード１１が接続されたＰＣからＯＴＡセンター２へのデータのアップロード、ＯＴＡセンター２からＳＤカード１１へのデータのダウンロード、ＳＤカード１１からＯＴＡマスタ４へのデータの転送を示している。第１２実施形態の変形例との主な違いは、図１８４に示すように、ＯＴＡセンター２は、ＯＴＡマスタ４と共有すべき鍵（ＯＴＡセンター２のＥＣＤＨＥ公開鍵）を公開鍵暗号方式の鍵、例えばＲＳＡ秘密鍵やＥＣＤＳＡ秘密鍵でデジタル署名を付与する。ＯＴＡセンター２は、署名付きのＥＣＤＨＥ公開鍵をＳＤカード１１へ転送して保存する。又、図１８５に示すように、ＯＴＡマスタ４は、署名付きのＥＣＤＨＥ公開鍵をＳＤカード１１から読出し、車両側システム３に保存されているＲＳＡ公開鍵を用いて検証する。
　次に、上記した構成の作用について図１８６から図１８９を参照して説明する。
　（１６－３）ＯＴＡマスタ４の処理（図１８６参照）
　ＯＴＡマスタ４は、ＳＤカード１１が車両側システム３に接続されており、所定条件が満たされると、ソフトウェアバージョン情報等の構成情報の送信をターゲットＥＣＵ５へ要求し、ターゲットＥＣＵ５から送信されたソフトウェアバージョン情報等の構成情報を車両構成情報として取得する（Ｂ１６１１）。ＯＴＡマスタ４は、車両構成情報を取得すると、その取得した車両構成情報をＳＤカード１１へ転送して保存する（Ｂ１６１２）。ＯＴＡマスタ４は、特定のルールにしたがって生成した乱数からＥＣＤＨＥの鍵ペアを生成する（Ｂ１６１３）。この場合、鍵ペアはＯＴＡマスタ４のＥＣＤＨＥ公開鍵とＥＣＤＨＥ秘密鍵とを含む。ＯＴＡマスタ４は、ＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＳＤカード１１へ転送して保存する（Ｂ１６１４）。ＥＣＤＨＥの鍵ペアは、第１２実施形態と同様に特定のルールにしたがって生成された乱数であって車両モデル毎に共通となる。ＳＤカード１１は、このようにして車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵が保存されると、車両側システム３との接続が解除され、ＰＣに接続される。
　（１６－４）ＰＣの処理（図１８７参照）
　ＰＣは、ＳＤカード１１が接続されていると、ＳＤカード１１に保存されている車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を読出し、その読出した車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵をＯＴＡセンター２へアップロードする（Ｃ１６１１）。ＰＣは、ＯＴＡセンター２からＯＴＡマスタ４のＥＣＤＨＥ公開鍵が格納されているキャンペーン通知、暗号化された更新パッケージの受信を待機すると共に、キャンペーンなし通知の受信を待機する（Ｃ１６１２、Ｃ１６１３）。ＰＣは、ＯＴＡセンター２からＯＴＡマスタ４のＥＣＤＨＥ公開鍵が格納されているキャンペーン通知、暗号化された更新パッケージを受信したと判定すると（Ｃ１６１２：ＹＥＳ）、又はキャンペーンなし通知を受信したと判定すると（Ｃ１６１３：ＹＥＳ）、処理を終了する。
　（１６－５）ＯＴＡセンター２の処理（図１８８参照）
　ＯＴＡセンター２は、ＳＤカード１１が接続されているＰＣからアップロードされた車両構成情報及びＯＴＡマスタ４のＥＣＤＨＥ公開鍵を取得する（Ａ１６１１）。ＯＴＡセンター２は、車両構成情報に基づいてキャンペーンがあるか否かを判定する（Ａ１６１２）。ＯＴＡセンター２は、キャンペーンがないと判定すると（Ａ１６１２：ＮＯ）、キャンペーンなし通知をＰＣへ送信し（Ａ１６１３）、処理を終了する。
　ＯＴＡセンター２は、キャンペーンがあると判定すると（Ａ１６１２：ＹＥＳ）、車両モデル毎又は車両群毎に共通となる乱数からＥＣＤＨＥの鍵ペアを生成する（Ａ１６１４）。この場合、鍵ペアはＯＴＡセンター２のＥＣＤＨＥ公開鍵とＥＣＤＨＥ秘密鍵である。ＯＴＡセンター２は、ＯＴＡセンター２のＥＣＤＨＥ公開鍵をＲＳＡ秘密鍵で署名し（Ａ１６１５）、署名済みのＯＴＡセンター２のＥＣＤＨＥ公開鍵をＳＤカード１１へダウンロードして保存する（Ａ１６１６）。ＯＴＡセンター２は、ＯＴＡセンター２のＥＣＤＨＥ秘密鍵とＯＴＡマスタ４のＥＣＤＨＥ公開鍵からＥＣＤＨＥ共通鍵（秘密鍵）を生成し（Ａ１６１７）、その生成したＥＣＤＨＥ共通鍵（秘密鍵）により更新パッケージを暗号化する（Ａ１６１８）。ＯＴＡセンター２は、暗号化された更新パッケージをＳＤカード１１へダウンロードして保存する（Ａ１６１９）。
　（１６－６）ＯＴＡマスタ４の処理（図１８９参照）
　ＯＴＡマスタ４は、ＳＤカード１１が車両側システム３に接続されていると、ＳＤカード１１から署名済みのＯＴＡセンター２のＥＣＤＨＥ公開鍵、更新パッケージを取得する（Ｂ１６２１）。ＯＴＡマスタ４は、署名済みのＯＴＡセンター２のＥＣＤＨＥ公開鍵をＲＳＡ公開鍵で検証する（Ｂ１６２２）。ＯＴＡマスタ４は、検証結果が正常であるか否かを判定し（Ｂ１６２３）、検証結果が正常でなく異常であると判定すると（Ｂ１６２３：ＮＯ）、エラー通知を行う（Ｂ１６２４）。
　ＯＴＡマスタ４は、検証結果が正常であると判定すると（Ｂ１６２３：ＹＥＳ）、ＯＴＡマスタ４のＥＣＤＨＥ秘密鍵とＯＴＡセンター２のＥＣＤＨＥ公開鍵からＥＣＤＨＥ共通鍵（秘密鍵）を生成する（Ｂ１６２５）。ＯＴＡマスタ４は、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ１６２６）。ＯＴＡマスタ４は、暗号化されたカウンター値と、暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ１６２７）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１６２８）。
　このような構成によれば、車両側システム３の無線通信機能に依存することなく、中間攻撃者からの攻撃に対抗することができ、よりセキュアなＯＴＡ配信を実現することができる。又、ＯＴＡマスタ４とＳＤカード１１との間のデータ転送と、ＯＴＡセンター２とＳＤカード１１との間のアップロードやダウンロードの回数を抑制することで、ユーザにとっての利便性を高めることができる。
　（第１７実施形態）
　第１７実施形態について図１４６から図１５１を参照して説明する。第１０実施形態は、複数のＣＤＮベンダから配信コストが最小となるＣＤＮベンダをエリア毎に選定する構成であるが、第１７実施形態は、複数のＣＤＮベンダから配信コストを低減可能なＣＤＮベンダを静的に選定する構成である。具体的には、第１０実施形態は、更新パッケージをＯＴＡセンター２で暗号化した上で、配信方式、ＯＴＡ対象エリア、配信データサイズに応じて配信コストを最小にするが、第１７実施形態は、更新パッケージをＯＴＡセンター２で暗号化せず、ＣＤＮ８とＯＴＡマスタ４との間をＴＬＳ通信で保護した上で、配信方式、ＯＴＡ対象エリア、配信データサイズに応じて配信コストを最小とする。
　次に、上記した構成の作用について図１４７から図１５１を参照して説明する。
　（１７－１）ＯＴＡセンター２の処理（図１４７から図１４８参照）
　ＯＴＡセンター２は、配信方式を特定し（Ａ１７１）、ＯＴＡ対象エリアを特定し（Ａ１７２）、車両への通信プロトコルにＴＬＳの使用有無を特定し（Ａ１７３）、配信データサイズを特定し（Ａ１７４）、ＣＤＮベンダ管理データベースから配信方式、ＯＴＡ対象エリア、通信プロトコル及び配信データサイズをキーにして価格テーブルを参照する（Ａ１７５）。この場合、ＯＴＡセンター２は、配信方式、ＯＴＡ対象エリア、通信プロトコル及び配信データサイズのうち少なくとも何れか一つをキーにして価格テーブルを参照しても良い。ＯＴＡセンター２は、エリア毎に配信コストが最小となるＣＤＮベンダを選定し、更新パッケージを当該選定したＣＤＮ８に配置する（Ａ１７６）。ＯＴＡセンター２は、キャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１７７）。
　（１７－２）ＯＴＡマスタ４の処理（図１４９から図１５１参照）
　ＯＴＡマスタ４は、ＯＴＡセンター２から送信されたキャンペーン通知がＯＴＡマスタ４に受信されることによりキャンペーン通知を取得する（Ｂ１７１）。ＯＴＡマスタ４は、更新パッケージを取得するためにキャンペーン通知に記載されているＣＤＮベンダとＴＬＳ通信を確立する（Ｂ１７２）。尚、キャンペーン通知にはＵＲＩ情報が記載されていれば、ＣＤＮベンダの情報は記載されていなくても良い。ＯＴＡマスタ４は、ＴＬＳ通信を確立した後に、ＴＬＳ通信プロトコルでＡＥＳの共通鍵を交換する。暗号モードとしてはＡＥＳ－ＣＴＲモードを選択するようにネゴシエーションする。ＯＴＡマスタ４は、ＴＬＳのＡＥＳ共通鍵により暗号化された更新パッケージを、ＵＲＩ情報に基づいてＣＤＮ８からダウンロードして取得する（Ｂ１７３、更新データ取得手順に相当する）。
　このとき、ＯＴＡマスタ４は、暗号化された更新パッケージをＣＤＮ８からダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化する（Ｂ１７４）。ＯＴＡマスタ４は、暗号化されたカウンター値と、ＣＤＮ８からダウンロードされている暗号化された更新パッケージとをＸＯＲ演算して復号化する（Ｂ１７５）。ＯＴＡマスタ４は、復号化された更新パッケージをターゲットＥＣＵ５へ転送し、更新パッケージをターゲットＥＣＵ５にインストールする（Ｂ１７６）。
　以上に説明したように第１７実施形態によれば、以下の作用効果を得ることができる。
　更新パッケージをＯＴＡセンター２で暗号化せず、ＣＤＮ８とＯＴＡマスタ４との間をＴＬＳ通信で保護した上で、配信方式、ＯＴＡ対象エリア、通信プロトコル及び配信データサイズに応じて配信コストを最小とする構成とした。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制することができる。
　（第１８実施形態）
　第１８実施形態について図１５２から図１６５を参照して説明する。第１８実施形態は、配信コストだけでなく、ＣＤＮベンダのスループットや応答遅延時間等を総合的に勘案の上、最適なＣＤＮベンダを選定し、且つＣＤＮベンダの価格テーブルと品質特性を定期的にチェックし、常にＣＤＮベンダ管理データベースを最新の状態に保持し、常に市場において最も競争優位性のあるＣＤＮベンダを選定する。価格テーブルは図１５３から図１６０に示す通りであり、各クラウドサービス事業者の品質情報は図１６１に示す通りである。図１６２に示すように、ＣＤＮベンダＡとＣＤＮベンダＢとを比較すると、配信コストの点ではＣＤＮベンダＢがＣＤＮベンダＡよりも優位であるが、スループットの重み付け及び応答遅延時間の重み付けの点ではＣＤＮベンダＡがＣＤＮベンダＢよりも優位である。配信コストだけでなく、ＣＤＮベンダのスループットや応答遅延時間等を総合的に勘案すると、配信コストだけで優位なＣＤＮベンダＢではなく、ＣＤＮベンダのスループットや応答遅延時間等を総合的に勘案した上で優位なＣＤＮベンダＡを選定すべきとする結論を導くことができる。
　次に、上記した構成の作用について図１６３から図１６５を参照して説明する。
　（１８－１）ＯＴＡセンター２の処理（図１６３から図１６５参照）
　ＯＴＡセンター２は、配信方式を特定し（Ａ１８１）、ＯＴＡ対象エリアを特定し（Ａ１８２）、ＣＤＮベンダ管理データベースから配信方式及びＯＴＡ対象エリアをキーにして価格テーブルを参照する（Ａ１８３）。この場合、ＯＴＡセンター２は、配信方式及びＯＴＡ対象エリアのうち少なくとも何れか一つをキーにして価格テーブルを参照しても良い。ＯＴＡセンター２は、ＣＤＮベンダ管理データベースから各ＣＤＮベンダの品質特性を特定する（Ａ１８４）。ＯＴＡセンター２は、エリア毎のＣＤＮベンダの配信コスト及び品質特性に基づいてＣＤＮベンダ選定ロジックデータベースに登録されているＣＤＮベンダ選定ロジックから最適なＣＤＮベンダをエリア毎に選定し、ＡＥＳ鍵により暗号化された更新パッケージを当該選定したＣＤＮ８に配置する（Ａ１８５）。ＯＴＡセンター２は、ＯＴＡセンター２は、暗号化されたＡＥＳ鍵が格納されたキャンペーン通知をリプログ対象の車両側システム３へ送信する（Ａ１８６）。
　ＯＴＡセンター２は、各ＣＤＮベンダの価格テーブルをＷｅｂサイトから自動取得し、ＣＤＮベンダ管理データベースを更新する（Ａ１８７）。ＯＴＡセンター２は、各ＣＤＮベンダのスループット及び応答遅延時間を計測し、ＣＤＮベンダ管理データベースを更新する（Ａ１８８）。例えば配信サーバ７は、定期的に各ＣＤＮベンダのＷｅｂサイトを巡回して最新の価格テーブルをダウンロードする。或いは、配信サーバ７は、ＣＤＮベンダがＷｅｂサイトの更新情報を配信する場合に、その配信サービスに登録することで、最新の価格テーブルをダウンロードする。
　（１８－２）ＯＴＡマスタ４の処理
　ＯＴＡマスタ４の処理は、第１実施形態で説明したＯＴＡマスタ４の処理（図１２から図１４）と同様である。
　以上に説明したように第１８実施形態によれば、以下の作用効果を得ることができる。
　配信コストだけでなく、ＣＤＮベンダのスループットや応答遅延時間等を総合的に勘案の上、最適なＣＤＮベンダを選定し、且つＣＤＮベンダの価格テーブルと品質特性を定期的にチェックし、常にＣＤＮベンダ管理データベースを最新の状態に保持し、常に市場において最も競争優位性のあるＣＤＮベンダを選定するようにした。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制することができる。
　尚、ＣＤＮの品質特性として、スループットや応答遅延時間に限定するものではなく、コンテンツのキャッシュヒット率や過去のトラブル実績等も考慮することが可能であり、それらをＣＤＮベンダ管理データベースに含めることが可能である。又、ＯＴＡセンター２の接続先のＣＤＮベンダの追加や削除について定期的に見直しを実施し、市場競争力のあるＣＤＮベンダと接続することも可能である。
　（第１９実施形態）
　第１９実施形態について図９０、図１９０から図１９３を参照して説明する。前述した第１０実施形態は、複数のＣＤＮベンダから配信コストが最小となるＣＤＮベンダをエリア毎に選定する構成である。第１９実施形態では、ＣＤＮベンダの選定について具体的に説明する。第１９実施形態では、更新パッケージのＣＤＮ８への配置先として複数のＣＤＮベンダの中から配信データサイズ、配信エリアであるＯＴＡ対象エリア（リージョンとも称する場合がある）、配信方式に応じて配信コストが最小となるＣＤＮベンダをダイナミックに選定する。第１９実施形態では、前述した図９０で例示した価格テーブルを参照して説明する。価格テーブルは図９０とは異なる様式でも良い。
　図１９０に示すように、ＯＴＡセンター２において、配信サーバ７は、ＣＤＮベンダ管理ＤＢに加え、ＣＤＮベンダ選定部７ａと、データ保存部７ｂと、キャンペーン通知生成部７ｃと、ＣＤＮ配信部７ｄとを備える。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダの選定に必要な情報である選定情報及び更新パッケージの情報に基づいてＣＤＮベンダを選定する。選定情報には、対象キャンペーンのデータサイズ、対象キャンペーンの配信対象車両の台数、リージョン、配信方式に関する情報等が含まれる。データ保存部７ｂは、キャンペーン情報を保存する他、ＣＤＮベンダ選定部７ａにより選定されたＣＤＮベンダを識別可能な識別情報を保存する。識別情報には、例えばＣＤＮベンダの名称、ＣＤＮベンダを特定する識別番号又はＣＤＮベンダを示すＵＲＬ等が含まれる。キャンペーン通知生成部７ｃは、データ保存部７ｂから情報を取得して車両等へ配信するキャンペーン通知を生成する。
　ＣＤＮ配信部７ｄは、各ＣＤＮベンダに対応するストレージ領域を備える。例えばストレージ領域は、ストレージ領域Ａ、ストレージ領域Ｂ、ストレージ領域Ｃを備える。ＣＤＮ配信部７ｄの各ストレージ領域とＣＤＮサーバとは同期している。即ち、ＣＤＮ配信部７ｄは、例えばデータをＣＤＮサーバＡから車両側システム３へ配信させる場合には、データをストレージ領域Ａに配置してＣＤＮサーバＡへ転送する。ＣＤＮサーバＡは、ＣＤＮ配信部７ｄからデータが転送されると、その転送されたデータを車両側システム３へ配信する。ＣＤＮ配信部７ｄの各ストレージ領域は、各ＣＤＮサーバのオリジンサーバと称する場合がある。
　次に、上記した構成の作用について図１９１から図１９３を参照して説明する。尚、ＯＴＡセンター２による更新パッケージの暗号等の処理は、第１０実施形態或いは他の実施形態と同様である。又、ＯＴＡマスタ４の処理は、第１実施形態或いは他の実施形態と同様である。第１９実施形態では、ＣＤＮベンダの選定を主に説明する。
　（１９－１）キャンペーン通知生成部７ｃの処理（図１９１参照）
　キャンペーン通知生成部７ｃは、キャンペーンが発生すると、例えばＯＥＭサーバ等の外部からキャンペーン情報を取得する（Ａ１９１）。キャンペーン情報には、対象キャンペーンのデータサイズ、対象キャンペーンの配信対象車両の台数、リージョン、配信方式に関する情報が含まれる。キャンペーン通知生成部７ｃは、その取得したキャンペーン情報をデータ保存部７ｂに保存する（Ａ１９２）。キャンペーン情報を保存することを、キャンペーン情報を配置すると称する場合がある。
　キャンペーン通知生成部７ｃは、ＣＤＮベンダの選定要求をＣＤＮベンダ選定部７ａへ通知し（Ａ１９３）、ＣＤＮベンダ選定部７ａからの選定通知の取得を待機する。キャンペーン通知生成部７ｃは、ＣＤＮベンダ選定部７ａから選定通知を取得すると（Ａ１９４）、データ保存部７ｂにアクセスし、そのＣＤＮベンダ選定部７ａにより選定されたＣＤＮベンダの識別情報を取得する（Ａ１９５）。
　キャンペーン通知生成部７ｃは、ＣＤＮベンダの識別情報に基づいて当該選定されたＣＤＮのＵＲＬを含むパラメータファイルをキャンペーン通知として生成する（Ａ１９６）。キャンペーン通知生成部７ｃは、その生成したキャンペーン通知を車両側システム３へ配信する（Ａ１９７）。
　（１９－２）ＣＤＮベンダ選定部７ａの処理（図１９２から図１９３参照）
　ＣＤＮベンダ選定部７ａは、キャンペーン通知生成部７から通知されたＣＤＮベンダの選定要求を取得すると（Ａ１９１１）、データ保存部７ｂにアクセスし、選定情報を取得し（Ａ１９１２）、第１ＣＤＮ選定処理に移行する（Ａ１９１３）。
　ＣＤＮベンダ選定部７ａは、第１ＣＤＮ選定処理を開始すると、ＣＤＮサーバから更新対象車両へ配信されるデータサイズを示す配信データサイズを算出する（Ａ１９２１）。具体的には、ＣＤＮベンダ選定部７ａは、対象キャンペーンのデータサイズと当該対象キャンペーンの配信対象車両の台数とを乗算し、ＣＤＮサーバから配信される予定の配信データサイズを算出する。
　ＣＤＮベンダ選定部７ａは、ＣＤＮベンダ毎に以降の処理を繰り返す（Ａ１９２２～Ａ１９２９）。ＣＤＮベンダ選定部７ａは、先に算出した配信データサイズ及びリージョンに関するリージョン情報に基づいてＣＤＮベンダ管理ＤＢから料金情報を取得する（Ａ１９２３）。ＣＤＮベンダ選定部７ａは、例えば北米を対象とする３０ＴＢのキャンペーンの場合、「北米」リージョンの「～１０ＴＢ」と「～４０ＴＢ」の料金情報を取得する。料金情報は全てのデータサイズについて取得しても良い。
　ＣＤＮベンダ選定部７ａは、配信データサイズに基づいて料金情報を参照し、配信課金額を算出する（Ａ１９２４）。配信課金額の算出はＣＤＮベンダ毎に異なる可能性があり、ＣＤＮベンダでの配信課金額の算出方法により決まる。例えば図９０の価格テーブルでＣＤＮ１について配信課金額を算出する場合、リージョンが「北米」であり、配信データサイズが３０ＴＢの場合、「～１０ＴＢ」と「～４０ＴＢ」との価格テーブルを参照する。
　ＣＤＮベンダ選定部７ａは、検討対象のＣＤＮベンダがリクエスト数に応じた課金を行うＣＤＮベンダであるか否かを判定する（Ａ１９２５）。ＣＤＮベンダ選定部７ａは、リクエスト数に応じた課金を行わないＣＤＮベンダであると判定すると（Ａ１９２５：ＮＯ）、配信課金額をＣＤＮベンダの課金額として決定し（Ａ１９２８）、当該ＣＤＮベンダについての課金額の算出を終了し、次のＣＤＮベンダの課金額を算出する。
　ＣＤＮベンダ選定部７ａは、リクエスト数に応じた課金を行うＣＤＮベンダであると判定すると（Ａ１９２５：ＹＥＳ）、リクエスト数を算出する（Ａ１９２６）。リクエスト数は配信方式により異なる。配信方式がストレージ方式の場合は、キャンペーンの配信対象車両の台数をリクエスト数とする。配信方式がストリーミング方式の場合は、対象キャンペーンのデータサイズをストリーミング時のチャンクサイズで除算し、キャンペーンの配信対象車両の台数を乗算してリクエスト数を算出する。
　ＣＤＮベンダ選定部７ａは、リクエスト数を算出すると、その算出したリクエスト数に基づいて課金額（リクエスト課金額と称する場合がある）を算出する（Ａ１９２７）。リクエスト課金額はリクエスト当たりの課金額とリクエスト数との乗算である。ＣＤＮベンダ選定部７ａは、配信課金額とリクエスト課金額とを合算した合算額をＣＤＮベンダの課金額として決定し（Ａ１９２８）、検討対象のＣＤＮベンダについての課金額の算出を終了し、次のＣＤＮベンダの課金額を算出する。
　ＣＤＮベンダ選定部７ａは、全てのＣＤＮベンダについて課金額を算出すると、
配信コストが最小となるＣＤＮベンダ、即ち、課金額が最安となるＣＤＮベンダを選定し（Ａ１９３０）、第１ＣＤＮ選定処理を終了する。ＣＤＮベンダ選定部７ａは、第１ＣＤＮ選定処理を終了すると、その選定結果、即ち、選定したＣＤＮベンダの識別情報をデータ保存部７ｂに保存し（Ａ１９１４）、選定結果をキャンペーン通知生成部７ｃへ通知する（Ａ１９１５）。
　以上に説明したように第１９実施形態によれば、以下の作用効果を得ることができる。
　配信サーバ７において、ＣＤＮベンダ管理ＤＢを参照し、配信コストが異なる複数のＣＤＮ８の中から配信方式、ＯＴＡ対象エリア及び配信データサイズに応じて配信コストが優位なＣＤＮ８を選定し、更新パッケージを当該選定したＣＤＮ８に配置する構成とした。これにより、ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制することができる。
　（第１９実施形態の変形例）
　第１９実施形態の変形例について図１９４から図２１１を参照して説明する。ここでは、第１変形例から第５変形例について説明する。
　（第１９実施形態の第１変形例）
　第１９実施形態の第１変形例について図１９４から図１９５を参照して説明する。第１変形例は、ＤＮＳ（ドメインネームシステム）サーバを使うことで、車両側システム３へ配信されるキャンペーン通知に含まれるＣＤＮサーバのＵＲＬを変更しない構成である。第１９実施形態では、キャンペーン毎に配信コストが最小となるＣＤＮベンダを選定する。キャンペーン通知にはＣＤＮサーバのＵＲＬが含まれる。そのため、配信コストが最小となるＣＤＮベンダが変更になると、キャンペーン通知に記載されるＵＲＬが変更される。キャンペーン通知生成部７ｃは、キャンペーン通知を生成する毎にデータ保存部７ｂにアクセスしてＣＤＮベンダの情報を取得する必要がある。
　これに対し、第１変形例では、ＤＮＳ設定部７ｅによりＤＮＳに登録されているＵＲＬとＩＰアドレスの変換情報を更新することで、キャンペーン通知生成部７ｃが常に同じＵＲＬをキャンペーン通知に記載することができる。配信コストが最小となるＣＤＮベンダが変更になる場合は、ＤＮＳサーバ１２の情報を変更することで、選定したＣＤＮサーバへ車両側システム３がアクセスすることができる。換言すると、第１９実施形態では、各ＣＤＮサーバは固有のＩＰアドレスを持ち、固有のＵＲＬを持っている。これに対し、第１変形例では、各ＣＤＮサーバは固有のＩＰアドレスを持つが、ＣＤＮサーバで共通したＵＲＬを持つことを特徴とする。
　図１９４に示すように、ＯＴＡセンター２において、配信サーバ７は、ＣＤＮベンダ管理ＤＢと、ＣＤＮベンダ選定部７ａと、データ保存部７ｂと、キャンペーン通知生成部７ｃと、ＣＤＮ配信部７ｄとに加え、ＤＮＳ設定部７ｅとを備える。以下では第１９実施形態と相違する点について主に説明する。
　ＤＮＳサーバ１２は、ドメイン名とＩＰアドレスを変換する仕組みを提供するサーバである。車両側システム３が受信するキャンペーン通知には、データをダウンロードするためにアクセスするＣＤＮサーバのＵＲＬが含まれている。車両側システム３は、キャンペーン通知を受信すると、その受信したキャンペーン通知に示されたＵＲＬについてＤＮＳサーバ１２に問合せる。ＤＮＳサーバ１２は、問合せを取得したＵＲＬに対するＩＰアドレスを車両側システム３へ送信するか、或いは接続先をＩＰアドレスで指定されるアドレスへ転送する。
　ＤＮＳ設定部７ｅは、ＣＤＮベンダの識別情報とＩＰアドレスを保存している。ＤＮＳ設定部７ｅは、ＣＤＮベンダ選定部７ａによりＣＤＮベンダが選定されると、ＩＰアドレス設定要求をＤＮＳサーバ１２へ送信し、ＤＮＳでの登録情報を設定する。
　次に、上記した構成の作用について図１９５を参照して説明する。
　（１９－３）ＣＤＮベンダ選定部７ａの処理（図１９５参照）
　ＣＤＮベンダ選定部７ａは、第１ＣＤＮ選定処理を終了し、選定結果をデータ保存部７ｂに保存すると（Ａ１９１４）、ＩＰアドレス設定要求をＤＮＳ設定部７ｅからＤＮＳサーバ１２へ送信させ、ＤＮＳ設定部７ｅによりＤＮＳでの登録情報を設定する（Ａ１９３１）。これにより、車両側システム３へ配信されるキャンペーン通知に含まれるＵＲＬはＣＤＮベンダが変更になっても変更されない。車両側システム３がＵＲＬで示されるＣＤＮサーバにアクセスする際に、ＤＮＳサーバ１２がＩＰアドレスの問合せを取得し、選定されたＣＤＮサーバのＩＰアドレスを車両側システム３へ送信する。
　尚、ＤＮＳ設定部７ｅは、ＤＮＳサーバ１２の情報を取得するか、前回のＤＮＳサーバ１２への設定情報を保存し、ＤＮＳサーバ１２に登録されているＣＤＮサーバとＣＤＮベンダ選定部７ａが選定したＣＤＮサーバとが異なる場合に、ＩＰアドレスの更新要求をＤＮＳサーバ１２へ送信しても良い。キャンペーン通知生成部７ｃは、ＣＤＮベンダ選定部７ａから選定通知を取得すると、固定されたＵＲＬを含むキャンペーン通知を生成する。
　このような構成によれば、第１９実施形態と同様の作用効果を得ることに加え、キャンペーン通知に含まれるＣＤＮのＵＲＬ情報を常に同じとすることができ、セキュリティを高めることができる。
　（第１９実施形態の第２変形例）
　第１９実施形態の第２変形例について図１９６から図２０１を参照して説明する。更新パッケージの配信コストが最小となるＣＤＮベンダを選択しても、ＣＤＮサーバのメンテナンスやトラブル、アクセス集中等により通信速度が遅くなっている虞がある。本願発明者らは、配信コストと配信性能に基づいてＣＤＮベンダを選択することに着目した。
　第２変形例では、車両側システム３がキャンペーン通知に示されたＵＲＬに対応するＩＰアドレスを取得するためにＤＮＳサーバ１２に問合せた際に、ＤＮＳサーバ１２がＣＤＮサーバの配信状況を確認し、配信不可と判定すると、配信コストが次に安いＣＤＮサーバのＩＰアドレスを車両側システム３へ回答する。
　図１９６に示すように、ＯＴＡセンター２において、配信サーバ７は、ＣＤＮベンダ管理ＤＢと、ＣＤＮベンダ選定部７ａと、データ保存部７ｂと、キャンペーン通知生成部７ｃと、ＣＤＮ配信部７ｄと、ＤＮＳ設定部７ｅとに加え、性能測定部７ｆとを備える。ＤＮＳサーバ１２は、ＣＤＮサーバ確認部１２ａを備える。ＣＤＮ配信部７ｄのストレージ領域には、ＣＤＮサーバの性能を測定するためのテストファイルが配置されている。性能測定部７ｆは、テストファイルの配信要求をＣＤＮサーバへ送信し、ＣＤＮサーバからテストファイルを配信させ、テストファイルの配信に要した時間を配信時間として測定する。配信時間は、例えばテストファイルの配信を開始した時刻からテストファイルの受信完了を特定した時刻までの時間である。
　ＣＤＮベンダ管理ＤＢは、図１９７に示すように、ＣＤＮサーバの選択テーブルを備えている。選択テーブルは、ＣＤＮベンダ選定部７ａにより決定されたコスト順位と、性能測定部７ｆにより判定された配信フラグとを含む。
　性能測定部７ｆは、各ＣＤＮサーバについて、テストファイルの配信に要した時間から応答速度を算出し、その算出した応答速度に基づいた判定結果を選択テーブルに入力する。性能測定部７ｆは、応答速度が規定値以上の場合は、そのＣＤＮサーバの配信フラグをオン（ＴＲＵＥ）に設定し、応答速度が規定値未満の場合は、そのＣＤＮサーバの配信フラグをオフ（ＦＡＬＳＥ）に設定する。
　ＣＤＮサーバ確認部１２ａは、車両側システム３からＵＲＬに対応するＩＰアドレスの問合せを取得した際に、ＵＲＬにより指定されたＣＤＮサーバが配信可能な状態であるか否かを判定し、配信不可を判定すると、別のＣＤＮサーバのＩＰアドレスを回答する。
　次に、上記した構成の作用について図１９８から図２０１を参照して説明する。
　（１９－４）ＣＤＮベンダ選定部７ａの処理（図１９８から図１９９参照）
　ＣＤＮベンダ選定部７ａは、第１ＣＤＮ選定処理では、ＣＤＮベンダ毎に課金額を算出すると（Ａ１９２１～Ａ１９２９）、ＣＤＮベンダのコスト順位を決定する（Ａ１９５１）。即ち、ＣＤＮベンダ選定部７ａは、配信コストが最小となるＣＤＮベンダの順位を第１位として決定し、配信コストが次に安いＣＤＮベンダの順位を第２位として決定する。ＣＤＮベンダ選定部７ａは、選定結果をデータ保存部７ｂに保存すると（Ａ１９１４）、ＣＤＮベンダ管理ＤＢの選択テーブルにコスト順位を保存する（Ａ１９４１）。
　（１９－５）性能測定部７ｆの処理（図２００参照）
　性能測定部７ｆは、ＣＤＮベンダ毎に以降の処理を繰り返す（Ａ１９６１～Ａ１９６６）。性能測定部７ｆは、配信サーバ７が起動中に一定間隔毎又は配信サーバ７の管理者により任意のタイミングで以降の処理を実行する。
　性能測定部７ｆは、ＣＤＮサーバにアクセスし（Ａ１９６２）、テストファイルの配信要求をＣＤＮサーバへ送信する。性能測定部７ｆは、テストファイルの配信に要した時間に基づいて応答速度を算出し、その算出した応答速度が規定値以上であるか否かを判定する（Ａ１９６３）。尚、応答速度を算出せずに配信に要した時間を規定値と比較しても良いし、単位時間当たりの配信データサイズを規定値と比較しても良い。
　性能測定部７ｆは、応答速度が規定値以上あると判定すると（Ａ１９６３：ＹＥＳ）、そのＣＤＮサーバが、配信に利用可能なサーバであると判定し、配信フラグをオンに設定する（Ａ１９６４）。性能測定部７ｆは、その算出した応答速度が規定値未満であると判定すると（Ａ１９６３：ＮＯ）、そのＣＤＮサーバが、配信に利用不能なサーバであると判定し、配信フラグをオフに設定する（Ａ１９６５）。
　（１９－６）ＣＤＮサーバ確認部１２ａの処理（図２０１参照）
　キャンペーン通知には、更新データをダウンロードするためにアクセスするＵＲＬが示されている。車両側システム３は、更新パッケージをダウンロードするためにアクセスすべきＩＰアドレスについてＤＮＳサーバ１２に問合せる。
　ＣＤＮサーバ確認部１２ａは、車両側システム３からキャンペーン通知に示されたＵＲＬについてＩＰアドレスの問合せを取得する（Ａ１９７１）。ＣＤＮサーバ確認部１２ａは、配信サーバ７のＣＤＮベンダ管理ＤＢにキャンペーン通知で示されたＣＤＮサーバの配信状況を照会する（Ａ１９７２）。この場合、ＣＤＮサーバはデータ取得予定のＣＤＮベンダに相当し、配信状況は配信フラグに相当する。ＣＤＮサーバ確認部１２ａは、配信サーバからデータ取得予定のＣＤＮベンダの配信フラグを取得すると、データ取得予定のＣＤＮベンダが使用可能であるか否かを判定する（Ａ１９７３）。即ち、ＣＤＮサーバ確認部１２ａは、その取得した配信フラグがオン又はオフの何れであるかを判定する。
　ＣＤＮサーバ確認部１２ａは、配信フラグがオンであると判定すると（Ａ１９７３：ＹＥＳ）、そのＣＤＮベンダに対応するＩＰアドレスを車両側システム３へ回答するか、又は車両側システム３との接続を当該ＩＰアドレスへ転送し、キャンペーン通知のＵＲＬに対応しているＣＤＮベンダに切替える（Ａ１９７４）。ＣＤＮサーバ確認部１２ａは、配信フラグがオフであると判定すると（Ａ１９７３：ＮＯ）、コスト順位が次に高いＣＤＮベンダを次の優先度のＣＤＮベンダとし、次の優先度のＣＤＮベンダを、データ取得予定のＣＤＮベンダとして設定し（Ａ１９７５）、ステップＡ１９７３に戻る。
　このような構成によれば、配信コストを極力抑制しつつ、正常に稼働しているＣＤＮサーバを選択することができる。尚、ＣＤＮサーバ確認部１２ａは、一定期間経過する毎に、ＣＤＮベンダ管理ＤＢにアクセスし、選択テーブルの送信を要求しても良い。この場合、車両側システム３からＩＰアドレスの問合せを取得した場合は、ＣＤＮベンダ管理ＤＢにアクセスする代わりに、ＣＤＮサーバ確認部１２ａが保持する選択テーブルを参照してデータ取得予定のＣＤＮベンダが使用可能であるか否かを判定しても良い。又、配信コストを極力抑制しつつ、正常に稼働しているＣＤＮサーバを選択することに加え、ＤＮＳサーバ１２と配信サーバ７との間の通信を減らすことができる。
　（第１９実施形態の第３変形例）
　第１９実施形態の第３変形例について図２０２から図２０５を参照して説明する。第３変形例は、配信サーバ７において、性能測定部７ｆは、車両側システム３からのログ情報に基づいてＣＤＮサーバの性能を測定して評価する。尚、ＤＮＳサーバ１２が車両側システム３からＵＲＬに対するＩＰアドレスの問合せを取得した場合の動作は第２変形例と同様である。第３変形例でも第２変形例と同様に、ＣＤＮベンダ管理ＤＢは選択テーブルを備えている。
　車両側システム３は、ログ送信部３ａを備える。ログ送信部３ａは、ＣＤＮサーバからの更新データのダウンロードを終了すると、ダウンロードに要した時間を示すダウンロード時間を含むダウンロードに関するログ情報を配信サーバ７の性能測定部７ｆへ送信する。ダウンロードに関するログ情報は、ダウンロード時間の他に、ダウンロードしたパッケージの識別情報、データサイズ、ダウンロード中の最大スループット等の情報を含んでいても良い。
　性能測定部７ｆは、ログ送信部３ａからダウンロードに関するログ情報を受信すると、ダウンロード時間からスループットを算出し、その算出したスループットに基づいた判定結果を選択テーブルに入力する。性能測定部７ｆは、スループットが規定値以上の場合は、そのＣＤＮサーバの配信フラグをオン（ＴＲＵＥ）に設定し、スループットが規定値未満の場合は、そのＣＤＮサーバの配信フラグをオフ（ＦＡＬＳＥ）に設定する。
　次に、上記した構成の作用について図２０３から図２０５を参照して説明する。
　（１９－８）ログ送信部３ａの処理（図２０３参照）
　ログ送信部３ａは、ＣＤＮサーバからの更新パッケージのダウンロードを終了すると（Ａ１９８１）、ダウンロードに要した時間を示すダウンロード時間を含むダウンロードに関するログ情報を配信サーバ７へ送信する（Ａ１９８２）。
　（１９－９）性能判定部７ｆの処理（図２０４参照）
　性能判定部７ｆは、ログ送信部３ａからダウンロードに関するログ情報を受信すると（Ａ１９９１）、ダウンロード時間からスループットを算出し（Ａ１９９２）、その算出したスループットが規定値以上であるか否かを判定する（Ａ１９９３）。
　性能測定部７ｆは、その算出したスループットが規定値以上あると判定すると（Ａ１９９３：ＹＥＳ）、そのＣＤＮサーバが、配信に利用可能なサーバであると判定し、配信フラグをオンに設定する（Ａ１９９４）。性能測定部７ｆは、その算出したスループットが規定値未満であると判定すると（Ａ１９９３：ＮＯ）、そのＣＤＮサーバが、配信に利用不能なサーバであると判定し、配信フラグをオフに設定する（Ａ１９９５）。
　（１９－１０）性能判定部７ｆの処理（図２０５参照）
　性能判定部７ｆは、配信フラグをオフにしたＣＤＮサーバの復帰処理を定期的に行う。性能測定部７ｆは、配信フラグがオフに設定されているＣＤＮサーバの情報要求をＣＤＮベンダ管理ＤＢへ通知し、配信フラグがオフに設定されているＣＤＮサーバを特定し（Ａ１９１０１）、ＣＤＮベンダ毎に以降の処理を繰り返す（Ａ１９１０２～Ａ１９１０７）。性能測定部７ｆは、配信サーバ７が起動中に、一定間隔毎又は配信サーバ７の管理者により任意のタイミングで以降の処理を実行する。
　性能測定部７ｆは、テストファイルの配信要求ＣＤＮサーバへ通知し、ＣＤＮサーバから配信されるファイルのダウンロード時間からスループットを算出し（Ａ１９１０３）、その算出したスループットが規定値以上であるか否かを判定する（Ａ１９１０４）。
　性能測定部７ｆは、その算出したスループットが規定値以上あると判定すると（Ａ１９１０４：ＹＥＳ）、その配信フラグをオフからオンへ変更する（Ａ１９１０５）。性能測定部７ｆは、その算出したスループットが規定値未満であると判定すると（Ａ１９１０４：ＮＯ）、その配信フラグのオフを維持する（Ａ１９１０６）。尚、性能測定部７ｆは、配信サーバのシステム起動時や所定期間毎に、ＣＤＮベンダ管理ＤＢのオフに設定されている配信フラグをオンにしても良い。
　このように構成によれば、ＣＤＮサーバの応答を特定するためにテストファイルの配信要求をＣＤＮサーバへ送信する第２変形例とは異なり、テストファイルの配信要求をＣＤＮサーバへ送信することを不要とし、通信ネットワークへの負荷やコストを抑制することができる。尚、車両側システム３に更新パッケージのダウンロード速度を測定する機能を設けることで、スループットが規定値未満であると判定すると、別のＣＤＮサーバへ接続を変更しても良い。
　配信サーバ７から配信されるキャンペーン通知に最初に接続するＣＤＮサーバのＵＲＬに加え、このＣＤＮサーバのスループットが低い場合に接続する予備のＣＤＮサーバのＵＲＬを含めても良い。予備のＣＤＮサーバは、例えば次に配信コストが安いＣＤＮサーバや、事前に決定された予備のＣＤＮサーバである。予備のＣＤＮサーバとして複数のＣＤＮサーバを指定する場合は、接続順序を示す情報を加えても良い。
　車両側システム３は、更新パッケージのダウンロードが開始すると、スループットを測定し、規定値以上のスループットが得られているか否かを確認する。車、両側システム３は、規定値以上のスループットが得られていないと判定すると、キャンペーン通知に示されている予備のＣＤＮサーバのＵＲＬについてＤＮＳサーバ１２にＩＰアドレスを問合せ、当初のＣＤＮサーバから新たなＣＤＮサーバへと接続を変更する。尚、配信されるデータには、パケット毎に識別情報が付加されているので、更新パッケージのダウンロードの途中でＣＤＮサーバを変更しても継続して更新パッケージをダウンロードすることができる。
　（第１９実施形態の第４変形例）
　第１９実施形態の第４変形例について図２０６から図２０７を参照して説明する。第４変形例は、複数のＣＤＮベンダをＣＤＮベンダ選定部７ａにより選定し、キャンペーン通知生成部７ｃは、ＣＤＮベンダ毎に複数のキャンペーン通知を生成する。キャンペーン通知を車両側システム３へ配信する際にラウンドロビン方式を採用して異なるＣＤＮサーバを指定する。
　（１９－１１）キャンペーン通知生成部７ｃの処理（図２０６参照）
　キャンペーン通知生成部７ｃは、ＣＤＮベンダの情報を取得すると（Ａ１９５）、ＣＤＮベンダ毎にキャンペーン通知を生成する（Ａ１９１１１）。即ち、キャンペーン通知生成部７ｃは、１つのキャンペーンに対して２つ以上のキャンペーン通知を生成する。キャンペーン通知生成部７ｃは、ＣＤＮサーバがラウンドロビン方式で変更するようにキャンペーン通知を配信する（Ａ１９１１２）。キャンペーン通知生成部７ｃは、例えばＣＤＮ１１とＣＤＮ１２の２つのＣＤＮサーバが選択された場合、キャンペーン通知を配信する際に、最初の車両に対してＣＤＮ１１のＵＲＬを含むキャンペーン通知を配信し、次の車両に対してＣＤＮ１２のＵＲＬを含むキャンペーン通知を配信し、更に次の車両に対してＣＤＮ１１のＵＲＬを含むキャンペーン通知を配信する。
　（１９－１２）ＣＤＮベンダ選定部７ａの処理（図２０７参照）
　ＣＤＮベンダ選定部７ａは、第１９実施形態では配信コストが最小となるＣＤＮベンダを選定するが、第４変形例では配信コストが安い順に複数のＣＤＮベンダを選定する（Ａ１９１２１）。
　このような構成によれば、ＣＤＮサーバからの配信コストを抑制しつつ、特定のＣＤＮサーバにアクセスが集中することを防ぐことができ、アクセスの集中を防ぐことで、スループットの低下を防ぐことができる。
　（第１９実施形態の第５変形例）
　第１９実施形態の第５変形例について図２０８から図２１１を参照して説明する。第４変形例は、配信コストを抑制する複数のＣＤＮベンダを選択し、ＣＤＮサーバの情報が異なる複数のキャンペーン通知を生成し、ＣＤＮサーバがラウンドロビン方式で変更されるようにキャンペーン通知を車両側システム３へ配信している。これに対し、第５変形例は、配信コストを抑制する複数のＣＤＮベンダを選択し、１つのキャンペーン通知を生成し、車両側システム３へ配信する。ＤＮＳサーバ１２が車両側システム３からキャンペーン通知に示されたＵＲＬに対応するＩＰアドレスの問合せを取得した際に、車両側システム３へ回答するＣＤＮサーバを車両側システム３毎に変更する。換言すると、ＤＮＳサーバ１２において、ラウンドロビン方式にＣＤＮサーバを選択する。
　図２０８に示すように、ＤＮＳサーバ１２は、切替部１２ｂを備えている。切替部１２ｂは、車両側システム３からＩＰアドレスの問合せを取得した際に、ラウンドロビン方式で車両側システム３へ回答するＩＰアドレスを順次変更する。配信サーバは、ＤＮＳ設定部７ｅを備えている。第５変形例のＤＮＳ設定部７ｅは、図２０９に示すラウンドロビンレコードをＤＮＳサーバ１２へ送信する。
　（１９－１３）ＣＤＮベンダ選定部７ａの処理（図２１０参照）
　ＣＤＮベンダ選定部７ａは、第４変形例と同様に配信コストが安い順に複数のＣＤＮベンダを選定し（Ａ１９１２１）、ラウンドロビンレコードを設定する（Ａ１９１３１）。
　（１９－１４）切替部１２ｂの処理（図２１１参照）
　ＤＮＳサーバ１２は、車両側システム３からＩＰアドレスの問合せを取得すると（Ａ１９１４１）、ラウンドロビンレコードを参照し（Ａ１９１４２）、記載されているＣＤＮサーバに対応するＩＰアドレスを車両側システム３へ送信する（Ａ１９１４３）。ＤＮＳサーバ１２は、車両側システム３からＩＰアドレスの問合せを取得する毎に上記した処理を繰り返し、別の車両側システム３からＩＰアドレスの問合せを取得すると、ラウンドロビンレコードを参照し、前回とは異なるＣＤＮサーバに対応するＩＰアドレスを車両側システム３へ送信する。即ち、ＤＮＳサーバ１２は、ラウンドロビン方式にしたがってＣＤＮサーバのＩＰアドレスを順繰りに車両側システム３へ送信する。
　このような構成によれば、ＣＤＮサーバからの配信コストを抑制しつつ、特定のＣＤＮサーバにアクセスが集中することを防ぐことができ、アクセスの集中を防ぐことで、スループットの低下を防ぐことができる。
　（第２０実施形態）
　第２０実施形態について図２１２から図２２４を参照して説明する。
　第２０実施形態は、所定期間における複数のキャンペーンについて情報が取得できる場合において、更新パッケージのＣＤＮ８への配置先として複数のＣＤＮベンダを配信方式、配信エリアであるＯＴＡ対象エリア、配信データサイズに応じてダイナミックに選定して配信コストを抑制する。所定期間とは、例えば翌月である。
　前述した第１９実施形態では、１つのキャンペーンに対して配信コストが最小となるＣＤＮベンダを選定している。しかしながら、キャンペーンは、所定期間、例えば翌月に配信開始予定の複数のキャンペーンについてＯＥＭサーバから登録されることも想定される。このように事前に複数のキャンペーンについて、各キャンペーンのデータサイズ、配信対象車両の台数、ＯＴＡ対象エリア、配信方式に関する情報が取得される場合は、第１９実施形態のようにキャンペーン毎にＣＤＮベンダを選定した場合とは異なるＣＤＮベンダが、配信コストが最小となるＣＤＮベンダとなる可能性がある。
　図２１２に示すように、ＯＴＡセンター２は、ＣＤＮベンダ管理ＤＢと、ＣＤＮベンダ選定部７ａと、データ保存部７ｂと、キャンペーン通知生成部７ｃと、ＣＤＮ配信部７ｄと、進捗情報管理部７ｇとを備える。進捗情報管理部７ｇは、キャンペーンが所定期間内にどの程度、車両側システム３へ配信されるかを示す予測値を保持している。キャンペーンがＯＴＡセンター２に登録され、車両側システム３へキャンペーン通知が配信されたとしても全ての車両が直ちにキャンペーンを適用し、更新パッケージをＣＤＮサーバからダウンロードするとは限らない。進捗情報管理部７ｇは、ＣＤＮサーバから車両側システム３への更新パッケージの配信データサイズをより正確に予測するため予測値を保存する。本実施形態では、所定期間を１か月として説明するが、他の期間でも良い。
　図２１３を参照し、第２０実施形態での計算方法について説明する。第２０実施形態では後述するように３つの計算方法によりＣＤＮベンダの課金額を算出する。第１計算方法では、各キャンペーンで配信コストが最小となるＣＤＮベンダを選定する。この場合は、キャンペーン毎に異なるＣＤＮベンダを選定する可能性がある。図２１３では、キャンペーン１に対してＣＤＮ１を選定し、キャンペーン２対してＣＤＮ２を選定し、キャンペーン３に対してＣＤＮ３を選定した場合を例示している。
　第２計算方法では、全てのキャンペーンの配信総データサイズを算出し、その算出した全てのキャンペーンの配信総データサイズに基づいて配信コストが最小となるＣＤＮベンダを選定する。この場合は、全てのキャンペーンで同一のＣＤＮベンダを選定する。図２１３では、キャンペーン１～３に対してＣＤＮ１を選定した場合を例示している。第３計算方法では、配信方式別のキャンペーンの配信総データサイズを算出し、その算出した配信方式別のキャンペーンの配信総データサイズに基づいて配信コストが最小となるＣＤＮベンダを選定する。配信方式別として、ストリーミング方式とストレージ方式とのそれぞれについてＣＤＮベンダを選定する。図２１３では、キャンペーン１とキャンペーン２，３とで配信方式が異なり、キャンペーン１に対してＣＤＮ１を選定し、キャンペーン２，３に対してＣＤＮ２を選定した場合を例示している。
　次に、上記した構成の作用について図２１４から図２２４を参照して説明する。
　（２０－１）キャンペーン通知生成部７ｃの処理（図２１４参照）
　キャンペーン通知生成部７ｃは、例えばＯＥＭサーバ等の外部から配信予定のキャンペーン情報をＯＥＭサーバから取得する（Ａ２０１）。配信予定のキャンペーン情報には、配信開始日、対象キャンペーンのデータサイズ、対象キャンペーンの配信対象車両の台数、リージョン、配信方式に関する情報が含まれている。キャンペーン通知生成部７ｃは、その取得したキャンペーン情報をデータ保存部７ｂに保存する（Ａ２０２）。
　キャンペーン通知生成部７ｃは、ＣＤＮベンダの選定要求をＣＤＮベンダ選定部７ａへ通知し（Ａ２０３）、ＣＤＮベンダ選定部７ａからの選定通知の取得を待機する。キャンペーン通知生成部７ｃは、ＣＤＮベンダ選定部７ａから選定通知を取得すると（Ａ２０４）、データ保存部７ｂにアクセスし、そのＣＤＮベンダ選定部７ａにより選定されたＣＤＮベンダの識別情報を取得する（Ａ２０５）。
　キャンペーン通知生成部７ｃは、ＣＤＮベンダの識別情報に基づいて当該選定されたＣＤＮのＵＲＬを含むパラメータファイルを配信予定のキャンペーン通知として生成する（Ａ２０６）。キャンペーン通知生成部７ｃは、その生成した配信予定のキャンペーン通知を車両側システム３へ配信する（Ａ２０７）。
　（２０－２）ＣＤＮベンダ選定部７ａの処理（図２１５から図２２１参照）
　ＣＤＮベンダ選定部７ａは、キャンペーン通知生成部７から通知されたＣＤＮベンダの選定要求を取得すると（Ａ２０１１）、データ保存部７ｂにアクセスし、
選定情報を取得する（Ａ２０１２）。この場合、選定情報には、配信予定の全ての対象キャンペーンのデータサイズ、配信対象車両の台数、リージョン、配信方式、各キャンペーンの配信開始日の情報が含まれている。
　ＣＤＮベンダ選定部７ａは、進捗情報管理部７ｇから配信予測値を取得する（Ａ２０１３）。ＣＤＮベンダ選定部７ａは、キャンペーン毎に配信データサイズを算出する（Ａ２０１４）。具体的には、ＣＤＮベンダ選定部７ａは、キャンペーンのデータサイズとキャンペーンの配信対象車両の台数と配信予測値とを乗算し、更に配信期間に応じた補正値を乗算する。キャンペーンによっては、配信開始日を来月下旬に設定する場合等の配信期間が短い場合があるので、配信期間に応じた補正値により調整する。例えば配信開始日を遅らせる結果、配信期間が１０日間しかない場合であれば、３０日間のうち１０日間が配信可能な期間であることから補正値として０．３等を設定する。
　ＣＤＮベンダ選定部７ａは、第２ＣＤＮ選定処理に移行する（Ａ２０１５）。ＣＤＮベンダ選定部７ａは、第２ＣＤＮ選定処理を開始すると、第１計算方法による課金額の算出処理、第２計算方法による課金額の算出処理、第３計算方法による課金額の算出処理に順次移行する（Ａ２０２１～Ａ２０２３）。
　ＣＤＮベンダ選定部７ａは、第１計算方法による課金額の算出処理では、キャンペーン毎に配信コストが最小となるＣＤＮベンダを選定する。ＣＤＮベンダ選定部７ａは、第１計算方法による課金額の算出処理を開始すると、これ以降の処理をキャンペーン毎に繰り返し（Ａ２０３１～Ａ２０４１）、更にＣＤＮベンダ毎に繰り返す（Ａ２０３２～Ａ２０３９）。ＣＤＮベンダ選定部７ａは、配信データサイズ及びリージョン情報に基づいてＣＤＮベンダ管理ＤＢから料金情報を取得する（Ａ２０３３）。ＣＤＮベンダ選定部７ａは、配信データサイズに基づいて料金情報を参照し、配信課金額を算出する（Ａ２０３４）。
　ＣＤＮベンダ選定部７ａは、第１９実施形態と同様に、検討対象のＣＤＮベンダがリクエスト数に応じた課金を行うＣＤＮベンダであるか否かを判定し、ＣＤＮベンダの課金額を決定する（Ａ２０３５～Ａ２０３８）。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダ毎及びキャンペーン毎に配信課金額の算出を繰り返す。尚、ＣＤＮベンダ選定部７ａは、１つのキャンペーンに対して全てのＣＤＮベンダの課金額が算出すると、そのキャンペーンに対して配信コストが最小となるＣＤＮベンダを選定する（Ａ２０４０）。
　ＣＤＮベンダ選定部７ａは、全てのキャンペーンについて配信課金額の算出とＣＤＮベンダの選定とを終了すると、全てのキャンペーンの配信課金額を合計し、合計額を算出し（Ａ２０４２）、第１計算方法による課金額の算出処理を終了し、第２計算方法による課金額の算出処理に移行する。
　ＣＤＮベンダ選定部７ａは、第２計算方法による課金額の算出処理では、配信予定の全てのキャンペーンの総配信データサイズに基づいて１つのＣＤＮベンダを選定する。ＣＤＮベンダ選定部７ａは、第２計算方法による課金額の算出処理を開始すると、各キャンペーンの配信データサイズを合計し、配信総データサイズを算出し（Ａ２０５１）、これ以降の処理をＣＤＮベンダ毎に繰り返す（Ａ２０５２～Ａ２０５９）。ＣＤＮベンダ選定部７ａは、配信総データサイズ及びリージョン情報に基づいてＣＤＮベンダ管理ＤＢから料金情報を取得する（Ａ２０５３）。ＣＤＮベンダ選定部７ａは、配信総データサイズに基づいて料金情報を参照し、配信課金額を算出する（Ａ２０５４）。
　ＣＤＮベンダ選定部７ａは、第１９実施形態と同様に、検討対象のＣＤＮベンダがリクエスト数に応じた課金を行うＣＤＮベンダであるか否かを判定し、ＣＤＮベンダの課金額を決定する（Ａ２０５５～Ａ２０５８）。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダ毎に配信課金額の算出を繰り返す。ＣＤＮベンダ選定部７ａは、配信コストが最小となるＣＤＮベンダを選定し（Ａ２０６０）。配信予定の全てのキャンペーンの配信課金額を合計し、合計額を算出し（Ａ２０６１）、第２計算方法による課金額の算出処理を終了し、第３計算方法による課金額の算出処理に移行する。
　ＣＤＮベンダ選定部７ａは、第３計算方法による課金額の算出処理では、配信方式毎にキャンペーンを纏めた上でＣＤＮベンダを選定する。ＣＤＮベンダ選定部７ａは、第３計算方法による課金額の算出処理を開始すると、配信予定のキャンペーンの配信方式が全て同じであるか否かを判定する（Ａ２０７１）。ＣＤＮベンダ選定部７ａは、配信予定のキャンペーンの配信方式が全て同じである、即ち、配信予定のキャンペーンが全てストリーミング方式である、又は全てストレージ方式であると判定すると（Ａ２０７１：ＹＥＳ）、前述した第２計算方法による課金額の算出処理と同じになるので、第３計算方法による課金額の算出処理を終了する。
　ＣＤＮベンダ選定部７ａは、配信予定のキャンペーンの配信方式が全て同じでない、即ち、配信予定のキャンペーンとしてストリーミング方式とストレージ方式とが混在すると判定すると（Ａ２０７１：ＮＯ）、キャンペーンを配信方式にしたがってグループ分けし（Ａ２０７２）、ストリーミング方式のグループについてストリーミング方式での課金額計算処理に移行し（Ａ２０７３）、ストレージ方式のグループについてストレージ方式での課金額計算処理に移行する（Ａ２０７４）。
　ＣＤＮベンダ選定部７ａは、ストリーミング方式での課金額計算処理を開始すると、ストリーミング方式で配信する各キャンペーンの配信データサイズの合計値を算出し（Ａ２０８１）、これ以降の処理をＣＤＮベンダ毎に繰り返す（Ａ２０８２～Ａ２０８９）。ＣＤＮベンダ選定部７ａは、配信データサイズの合計値及びリージョン情報に基づいてＣＤＮベンダ管理ＤＢから料金情報を取得する（Ａ２０８３）。ＣＤＮベンダ選定部７ａは、配信データサイズの合計値に基づいて料金情報を参照し、配信課金額を算出する（Ａ２０８４）。
　ＣＤＮベンダ選定部７ａは、第１９実施形態と同様に、検討対象のＣＤＮベンダがリクエスト数に応じた課金を行うＣＤＮベンダであるか否かを判定し、ＣＤＮベンダの課金額を決定する（Ａ２０８５～Ａ２０８８）。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダ毎に配信課金額の算出を繰り返す。ＣＤＮベンダ選定部７ａは、ストリーミング方式での配信コストが最小となるＣＤＮベンダを選定し（Ａ２０９０）、ストリーミング方式での課金額計算処理を終了する。
　一方、ＣＤＮベンダ選定部７ａは、ストレージ方式での課金額計算処理を開始すると、ストレージ方式で配信する各キャンペーンの配信データサイズの合計値を算出し（Ａ２０９１）、これ以降の処理をＣＤＮベンダ毎に繰り返す（Ａ２０９２～Ａ２０９９）。ＣＤＮベンダ選定部７ａは、配信データサイズの合計値及びリージョン情報に基づいてＣＤＮベンダ管理ＤＢから料金情報を取得する（Ａ２０９３）。ＣＤＮベンダ選定部７ａは、配信データサイズの合計値に基づいて料金情報を参照し、配信課金額を算出する（Ａ２０９４）。
　ＣＤＮベンダ選定部７ａは、第１９実施形態と同様に、検討対象のＣＤＮベンダがリクエスト数に応じた課金を行うＣＤＮベンダであるか否かを判定し、ＣＤＮベンダの課金額を決定する（Ａ２０９５～Ａ２０９８）。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダ毎に配信課金額の算出を繰り返す。ＣＤＮベンダ選定部７ａは、ストレージ方式での配信コストが最小となるＣＤＮベンダを選定し（Ａ２０１００）、ストレージ方式での課金額計算処理を終了する。
　ＣＤＮベンダ選定部７ａは、第１計算方法による課金額の算出処理、第２計算方法による課金額の算出処理、第３計算方法による課金額の算出処理を終了すると、配信コストが最小となる計算方法を決定し（Ａ２０２４）、各キャンペーンのＣＤＮベンダを選定し（Ａ２０２５）、第２ＣＤＮ選定処理を終了する。ＣＤＮベンダ選定部７ａは、第２ＣＤＮ選定処理を終了すると、その選定結果、即ち、選定したＣＤＮベンダを識別する識別情報をデータ保存部７ｂに保存する（Ａ２０１６）。ここでは、ＣＤＮベンダ選定部７ａは、配信予定のキャンペーンのＣＤＮベンダを識別する識別情報をデータ保存部７ｂに保存する。ＣＤＮベンダ選定部７ａは、選定通知をキャンペーン通知生成部７ｃへ通知する（Ａ２０１７）。
　（２０－３）進捗情報管理部７ｇの処理（図２２２参照）
　進捗情報管理部７ｇは、所定期間にどの程度のキャンペーンが車両側システム３へ配信されるかを示す予測値を保存する。この予測値は、ＯＥＭサーバから送信される実際の配信状況に応じて更新されることが想定される。
　進捗情報管理部７ｇは、ＯＥＭサーバから配信状況を取得する（Ａ２０１１１）。進捗情報管理部７ｇは、配信状況と当該保存している予測値との差が所定値以上であるか否かを判定する（Ａ２０１１２）。進捗情報管理部７ｇは、配信状況と当該保存している予測値との差が所定値以上でないと判定すると（Ａ２０１１２：ＮＯ）、処理を終了する。
　進捗情報管理部７ｇは、配信状況と当該保存している予測値との差が所定値以上であると判定すると（Ａ２０１１２：ＹＥＳ）、保存している予測値を更新し（Ａ２０１１３）、予測値の更新をＣＤＮベンダ選定部７ａへ通知する（Ａ２０１１４）。進捗情報管理部７ｇは、全てのキャンペーンに共通した１つの予測値を持っても良いし、キャンペーン毎や更新対象車両毎、キャンペーンの種類毎に異なる予測値を持っても良い。
　（２０－４）ＣＤＮベンダ選定部７ａの処理（図２２３参照）
　ＣＤＮベンダ選定部７ａは、進捗情報管理部７ｇから通知された予測値の更新を取得すると（Ａ２０１２１）、選定情報を取得し（Ａ２０１２２）、進捗情報管理部７ｇから配信予測値を取得し（Ａ２０１２３）、キャンペーン毎に配信データサイズを算出する（Ａ２０１２４）。この場合、ＣＤＮベンダ選定部７ａは、配信データサイズを算出する際には、配信日数を考慮した補正値とする。
　ＣＤＮベンダ選定部７ａは、第２ＣＤＮ選定処理に移行し（Ａ２０１２５）、、第２ＣＤＮ選定処理を終了すると、ＣＤＮベンダに変更があるか否かを判定する（Ａ２０１２６）。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダに変更がないと判定すると（Ａ２０１２６：ＮＯ）、処理を終了する。ＣＤＮベンダに変更がある場合は、データ保存部７ｂでの選定結果を更新する。ＣＤＮベンダ選定部７ａは、ＣＤＮベンダに変更があると判定すると（Ａ２０１２６：ＹＥＳ）、選定結果を更新し（Ａ２０１２７）、ＣＤＮ変更通知をキャンペーン通知生成部７ｃへ送信する（Ａ２０１２８）。尚、ＣＤＮベンダ選定部７ａは、進捗情報管理部７ｇに保存された予測値が変更されているか否かを所定間隔で確認しても良い。
　（２０－５）キャンペーン通知生成部７ｃの処理（図２２４参照）
　キャンペーン通知生成部７ｃは、ＣＤＮベンダ選定部７ａから通知されたＣＤＮ変更通知を取得すると（Ａ２０１３１）、データ保存部７ｂにアクセスし、更新後のＣＤＮベンダの情報を取得し（Ａ２０１３２）、その取得した更新後のＣＤＮベンダ情報に基づいて配信予定のキャンペーン通知を再生成する（Ａ２０１３３）。
　以上に説明したように第２０実施形態によれば、以下の作用効果を得ることができる。
　ＣＤＮベンダ管理データベースを参照し、配信コストが異なる複数のＣＤＮ８の中から配信方式、ＯＴＡ対象エリア及び配信データサイズに応じて配信コストが優位なＣＤＮ８を選定し、更新パッケージを当該選定したＣＤＮ８に配置する構成とした。ＯＴＡマスタ４が更新パッケージをＯＴＡセンター２からダウンロードする際の配信コストを適切に抑制することができる。
　（その他の実施形態）
　上記した実施形態において、ストリーミング方式或いはストレージ方式と明記されていない実施形態は、ストリーミング方式とストレージ方式の何れの方式にも適用することができる。
　上記した一部の実施形態では、ＴＬＳ通信が確立された上でキャンペーン通知がＯＴＡセンター２からＯＴＡマスタ４へ送信されることが記載されている。しかしながら、全ての実施形態において、ＴＬＳ通信が確立された上でキャンペーン通知がＯＴＡセンター２からＯＴＡマスタ４へ送信されても良い。ＴＬＳ通信を確立することで、よりセキュリティを高めることができる。或いは、ＴＬＳ通信が確立されずにキャンペーン通知がＯＴＡセンター２からＯＴＡマスタ４へ送信されても良い。
　本実施形態の車両側システム３は以下の構成でも良い。車両側システム３は、ＤＣＭ（データコミュニケーションモジュール）とＣＧＷ（セントラルゲートウェイ）とを備え、ＤＣＭとＣＧＷとがバスを介してデータ通信可能に接続されている構成でも良い。ＣＧＷはセントラルＥＣＵとも称される。バスは、例えばイーサネットやＣＡＮ（登録商標）バス等であれば良い。
　ＯＴＡマスタ４の機能の一部又は全体がＣＧＷにおいて実現されても良い。一例としては、ＤＣＭがＣＤＮ８やＯＴＡセンター２等の外部とデータ通信し、ＯＴＡマスタ４の機能の全てがＣＧＷにおいて実施されても良い。この場合、ＤＣＭは、外部との無線通信により受信した全てのデータをＣＧＷへ転送する。或いは、ＤＣＭが外部とデータ通信することに加え、ＯＴＡマスタ４のダウンローダとして機能しても良い。ダウンローダの機能とは、例えば車両構成情報の生成、メタデータ検証、パッケージ検証、キャンペーン情報の検証である。或いは、ＯＴＡマスタ４の機能がＤＣＭにおいて実現されても良い。この場合、ＣＧＷにはＯＴＡマスタ４以外の機能が実装される。或いは、ＤＣＭとＣＧＷとが一体化していても良い。
　ＤＣＭの機能の一部又は全体をＣＧＷが有する構成でも良いし、ＣＧＷの機能の一部又は全体をＤＣＭが有する構成でも良い。即ち、ＯＴＡマスタ４において、ＤＣＭとＣＧＷとの機能分担がどのように構成されていても良い。ＯＴＡマスタ４は、ＤＣＭ及びＣＧＷの２つのＥＣＵから構成されても良いし、ＤＣＭの機能とＣＧＷの機能とを有する１つの統合ＥＣＵで構成されても良い。
　本開示は、実施形態に準拠して記述されたが、本開示は当該実施形態や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、更には、それらに一要素のみ、それ以上、或いはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
　各装置等が提供する手段や機能は、実体的なメモリ装置に記録されたソフトウェア及びそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、或いはそれらの組み合わせにより提供することができる。例えば制御部がハードウェアである電子回路により提供される場合、それは多数の論理回路を含むデジタル回路、又はアナログ回路により提供することができる。
　本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することにより提供された専用コンピュータにより実現されても良い。或いは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によりプロセッサを構成することにより提供された専用コンピュータにより実現されても良い。又、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路により構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより実現されても良い。又、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていても良い。

Claims (23)

  1. 　更新データをマスタ装置へ配信するセンター装置（２）と、前記センター装置からダウンロードした前記更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）と、を備えるデータ通信システムであって、
    　前記センター装置及び前記マスタ装置は、前記更新データの暗号方式及び復号方式としてカウンター（ＣＴＲ）モードを採用したデータ通信システム。
  2. 　前記マスタ装置は、前記更新データの復号化処理を並列に実行する請求項１に記載したデータ通信システム。
  3. 　前記センター装置及び前記マスタ装置は、カウンターにノンスを含める請求項１又は２に記載したデータ通信システム。
  4. 　更新データをマスタ装置へ配信するセンター装置（２）と、前記センター装置からダウンロードした前記更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）と、を備えるデータ通信システムであって、
    　前記センター装置及び前記マスタ装置は、前記更新データの暗号方式及び復号方式として出力フィードバック（ＯＦＢ）モードを採用したデータ通信システム。
  5. 　前記マスタ装置は、前記センター装置から前記更新データをダウンロードすることとは別に、前記更新データの復号化処理の前準備をバックグラウンドで開始する請求項１から４の何れか一項に記載したデータ通信システム。
  6. 　前記マスタ装置は、前記センター装置から送信されたキャンペーン通知を受信したタイミングで、前記更新データの復号化処理の前準備をバックグラウンドで開始する請求項５に記載したデータ通信システム。
  7. 　前記マスタ装置は、ユーザからのダウンロード承諾が得られる前に、前記更新データの復号化処理の前準備をバックグラウンドで開始する請求項５又は６に記載したデータ通信システム。
  8. 　前記マスタ装置は、前記更新データの復号化処理の前準備として、全ての鍵ストリームを計算する請求項５から７の何れか一項に記載したデータ通信システム。
  9. 　前記マスタ装置は、前記更新データの復号化処理の前準備として、一部の鍵ストリームを計算する請求項５から７の何れか一項に記載したデータ通信システム。
  10. 　前記センター装置は、暗号鍵として特定の車両群で個別化した鍵を使用する請求項１から９の何れか一項に記載したデータ通信システム。
  11. 　前記センター装置及び前記マスタ装置は、秘密鍵を鍵更新するための鍵更新用鍵を保持し、
    　前記センター装置は、前記鍵更新用鍵を用いて秘密鍵更新パッケージを生成し、その生成した前記秘密鍵更新パッケージを前記マスタ装置へ送信する請求項１から１０の何れか一項に記載したデータ通信システム。
  12. 　前記センター装置及び前記マスタ装置は、メッセージ認証コード（ＭＡＣ）として暗号ブロック連鎖（ＣＢＣ）モードを採用した請求項１から１１の何れか一項に記載したデータ通信システム。
  13. 　前記センター装置及び前記マスタ装置は、メッセージ認証コード（ＭＡＣ）としてガロアメッセージ認証コード（ＧＭＡＣ）モードを採用した請求項１から１１の何れか一項に記載したデータ通信システム。
  14. 　前記センター装置及び前記マスタ装置は、前記メッセージ認証コードを付与するデータサイズ単位を認識し合う請求項１２又は１３に記載したデータ通信システム。
  15. 　前記センター装置は、暗号方式をリプロポリシーメタデータ及びダウンロードメタデータのうち少なくとも何れか一つに含めて前記マスタ装置へ送信する請求項１から１４の何れか一項に記載したデータ通信システム。
  16. 　更新データをマスタ装置へ配信するセンター装置（２）であって、
    　更新データを暗号化するための共通鍵を生成する共通鍵生成部（２ａ）と、
    　前記更新データを前記共通鍵によりカウンター（ＣＴＲ）モードで暗号化する更新データ暗号化部（２ｂ）と、
    　前記共通鍵をＲＳＡ公開鍵により暗号化する共通鍵暗号化部（２ｃ）と、
    　前記ＲＳＡ公開鍵により暗号化された前記共通鍵をキャンペーン通知の中に格納する共通鍵格納部（２ｄ）と、
    　前記共通鍵により暗号化された前記更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）に配置する暗号化データ配置部（２ｅ）と、
    　暗号化された前記共通鍵が格納されたキャンペーン通知をリプログ対象の車両側システムへ送信するキャンペーン通知送信部（２ｆ）と、を備えるセンター装置。
  17. 　更新データをマスタ装置へ配信するセンター装置（２）であって、
    　更新データを暗号化するための共通鍵を生成する共通鍵生成部（２ａ）と、
    　前記更新データを前記共通鍵により出力フィードバック（ＯＦＢ）モードで暗号化する更新データ暗号化部（２ｂ）と、
    　前記共通鍵をＲＳＡ公開鍵により暗号化する共通鍵暗号化部（２ｃ）と、
    　前記ＲＳＡ公開鍵により暗号化された前記共通鍵をキャンペーン通知の中に格納する共通鍵格納部（２ｄ）と、
    　前記共通鍵により暗号化された前記更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）に配置する暗号化データ配置部（２ｅ）と、
    　暗号化された前記共通鍵が格納されたキャンペーン通知をリプログ対象の車両側システムへ送信するキャンペーン通知送信部（２ｆ）と、を備えるセンター装置。
  18. 　センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）であって、
    　センター装置から取得したキャンペーン通知の中から共通鍵を取得する共通鍵取得部（４ａ）と、
    　暗号化された前記共通鍵をＲＳＡ秘密鍵により復号化して前記共通鍵を取出す共通鍵復号化部（４ｂ）と、
    　暗号化された更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）からダウンロードして取得する暗号化データ取得部（４ｃ）と、
    　暗号化された更新データを前記暗号化データ取得部が前記ＣＤＮからダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化するブロック暗号処理部（４ｄ）と、
    　暗号化された前記カウンター値と、前記ＣＤＮからダウンロードされている暗号化された前記更新データとを排他的論理和演算して復号化する暗号化データ復号化部（４ｅ）と、
    　復号化された前記更新データをリプログ対象の電子制御装置へ転送し、更新データを前記電子制御装置にインストールするインストール処理部（４ｆ）と、を備えるマスタ装置。
  19. 　センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）であって、
    　センター装置から取得したキャンペーン通知の中から共通鍵を取得する共通鍵取得部（４ａ）と、
    　暗号化された前記共通鍵をＲＳＡ秘密鍵により復号化して前記共通鍵を取出す共通鍵復号化部（４ｂ）と、
    　暗号化された更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）からダウンロードして取得する暗号化データ取得部（４ｃ）と、
    　暗号化された更新データを前記暗号化データ取得部が前記ＣＤＮからダウンロードして取得することと並行し、ＩＶ値ベースの共通ストリーム暗号処理をＡＥＳ鍵により実行してＩＶ値を暗号化するブロック暗号処理部（４ｄ）と、
    　暗号化された前記ＩＶ値と、前記ＣＤＮからダウンロードされている暗号化された前記更新データとを排他的論理和演算して復号化する暗号化データ復号化部（４ｅ）と、
    　復号化された前記更新データをリプログ対象の電子制御装置へ転送し、更新データを前記電子制御装置にインストールするインストール処理部（４ｆ）と、を備えるマスタ装置。
  20. 　更新データをマスタ装置へ配信するセンター装置（２）に、
    　更新データを暗号化するための共通鍵を生成する共通鍵生成手順と、
    　前記更新データを前記共通鍵によりカウンター（ＣＴＲ）モードで暗号化する更新データ暗号化手順と、
    　前記共通鍵をＲＳＡ公開鍵により暗号化する共通鍵暗号化手順と、
    　前記ＲＳＡ公開鍵により暗号化された前記共通鍵をキャンペーン通知の中に格納する共通鍵格納手順と、
    　前記共通鍵により暗号化された前記更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）に配置する暗号化データ配置手順と、
    　暗号化された前記共通鍵が格納されたキャンペーン通知をリプログ対象の車両側システムへ送信するキャンペーン通知送信手順と、を実行させる暗号化プログラム。
  21. 　更新データをマスタ装置へ配信するセンター装置（２）に、
    　更新データを暗号化するための共通鍵を生成する共通鍵生成手順と、
    　前記更新データを前記共通鍵により出力フィードバック（ＯＦＢ）モードで暗号化する更新データ暗号化手順と、
    　前記共通鍵をＲＳＡ公開鍵により暗号化する共通鍵暗号化手順と、
    　前記ＲＳＡ公開鍵により暗号化された前記共通鍵をキャンペーン通知の中に格納する共通鍵格納手順と、
    　前記共通鍵により暗号化された前記更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）に配置する暗号化データ配置手順と、
    　暗号化された前記共通鍵が格納されたキャンペーン通知をリプログ対象の車両側システムへ送信するキャンペーン通知送信手順と、を実行させる暗号化プログラム。
  22. 　センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）に、
    　センター装置から取得したキャンペーン通知の中から共通鍵を取得する共通鍵取得手順と、
    　暗号化された前記共通鍵をＲＳＡ秘密鍵により復号化して前記共通鍵を取出す共通鍵復号化手順と、
    　暗号化された更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）からダウンロードして取得する暗号化データ取得手順と、
    　暗号化された更新データを前記暗号化データ取得手順により前記ＣＤＮからダウンロードして取得することと並行し、カウンター値のＡＥＳブロック暗号処理をＡＥＳ鍵により実行してカウンター値を暗号化するブロック暗号処理手順と、
    　暗号化された前記カウンター値と、前記ＣＤＮからダウンロードされている暗号化された前記更新データとを排他的論理和演算して復号化する暗号化データ復号化手順と、
    　復号化された前記更新データをリプログ対象の電子制御装置へ転送し、更新データを前記電子制御装置にインストールするインストール処理手順と、を実行させる復号化プログラム。
  23. 　センター装置からダウンロードした更新データをリプログ対象の電子制御装置にインストールするマスタ装置（４）に、
    　センター装置から取得したキャンペーン通知の中から共通鍵を取得する共通鍵取得手順と、
    　暗号化された前記共通鍵をＲＳＡ秘密鍵により復号化して前記共通鍵を取出す共通鍵復号化手順と、
    　暗号化された更新データをコンテンツ・デリバリー・ネットワーク（ＣＤＮ）からダウンロードして取得する暗号化データ取得手順と、
    　暗号化された更新データを前記暗号化データ取得手順により前記ＣＤＮからダウンロードして取得することと並行し、ＩＶ値ベースの共通ストリーム暗号処理をＡＥＳ鍵により実行してＩＶ値を暗号化するブロック暗号処理手順と、
    　暗号化された前記ＩＶ値と、前記ＣＤＮからダウンロードされている暗号化された前記更新データとを排他的論理和演算して復号化する暗号化データ復号化手順と、
    　復号化された前記更新データをリプログ対象の電子制御装置へ転送し、更新データを前記電子制御装置にインストールするインストール処理手順と、を実行させる復号化プログラム。
PCT/JP2022/024875 2021-09-30 2022-06-22 データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラム WO2023053621A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202280065002.1A CN118140454A (zh) 2021-09-30 2022-06-22 数据通信系统、中心装置、主机装置、加密程序以及解密程序
JP2023550370A JPWO2023053621A1 (ja) 2021-09-30 2022-06-22
DE112022004670.8T DE112022004670T5 (de) 2021-09-30 2022-06-22 Datenkommunikationssystem, zentrumsvorrichtung, mastervorrichtung, verschlüsselungsprogramm und entschlüsselungsprogramm
US18/618,840 US20240267221A1 (en) 2021-09-30 2024-03-27 Data communication system, center device, master device, storage medium storing encryption program, and storage medium storing decryption program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021161212 2021-09-30
JP2021-161212 2021-09-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/618,840 Continuation US20240267221A1 (en) 2021-09-30 2024-03-27 Data communication system, center device, master device, storage medium storing encryption program, and storage medium storing decryption program

Publications (1)

Publication Number Publication Date
WO2023053621A1 true WO2023053621A1 (ja) 2023-04-06

Family

ID=85780540

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/024875 WO2023053621A1 (ja) 2021-09-30 2022-06-22 データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラム

Country Status (5)

Country Link
US (1) US20240267221A1 (ja)
JP (1) JPWO2023053621A1 (ja)
CN (1) CN118140454A (ja)
DE (1) DE112022004670T5 (ja)
WO (1) WO2023053621A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014088062A (ja) * 2012-10-29 2014-05-15 Denso Corp 通信システム、車載ｅｃｕ、およびリモートリプログラム装置
WO2015034020A1 (ja) * 2013-09-06 2015-03-12 日本放送協会 送信装置、受信装置、限定受信システムおよび限定受信方法
US20200267547A1 (en) * 2019-02-20 2020-08-20 Coretigo Ltd. Secure Key Exchange Mechanism In A Wireless Communication System
WO2020170732A1 (ja) * 2019-02-22 2020-08-27 株式会社デンソー センター装置、データ配信システム及び配信制御プログラム
US20200389289A1 (en) * 2019-06-05 2020-12-10 Sameer KHANNA Cryptographic systems with variable layout cryptography
JP2021072047A (ja) * 2019-11-01 2021-05-06 株式会社東芝 セキュリティ管理システム及びセキュリティ管理方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03276424A (ja) 1990-03-26 1991-12-06 Toppan Printing Co Ltd 光カードの記録再生装置
JP7448282B2 (ja) 2020-03-31 2024-03-12 住鉱潤滑剤株式会社 耐熱性グリース組成物

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014088062A (ja) * 2012-10-29 2014-05-15 Denso Corp 通信システム、車載ｅｃｕ、およびリモートリプログラム装置
WO2015034020A1 (ja) * 2013-09-06 2015-03-12 日本放送協会 送信装置、受信装置、限定受信システムおよび限定受信方法
US20200267547A1 (en) * 2019-02-20 2020-08-20 Coretigo Ltd. Secure Key Exchange Mechanism In A Wireless Communication System
WO2020170732A1 (ja) * 2019-02-22 2020-08-27 株式会社デンソー センター装置、データ配信システム及び配信制御プログラム
US20200389289A1 (en) * 2019-06-05 2020-12-10 Sameer KHANNA Cryptographic systems with variable layout cryptography
JP2021072047A (ja) * 2019-11-01 2021-05-06 株式会社東芝 セキュリティ管理システム及びセキュリティ管理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HAKATA, KEISUKE ET AL.: "Current status and issues of control system security: Toward realization of encryption communication function for controllers", JOURNAL OF THE SOCIETY OF INSTRUMENT AND CONTROL ENGINEERS, vol. 53, no. 10, 10 October 2014 (2014-10-10), pages 936 - 942, XP009544932 *
MIZOGUCHI, SEIICHIRO ET AL.: "Implementation of Secure Remote Re-programming Schemes", PROCEEDINGS OF COMPUTER SECURITY SYMPOSIUM 2016, vol. 2 E1-2, 4 October 2016 (2016-10-04), pages 379 - 383, XP055654169 *

Also Published As

Publication number Publication date
JPWO2023053621A1 (ja) 2023-04-06
CN118140454A (zh) 2024-06-04
DE112022004670T5 (de) 2024-08-01
US20240267221A1 (en) 2024-08-08

Similar Documents

Publication Publication Date Title
US11706025B2 (en) Secure firmware transfer for an integrated universal integrated circuit card (iUICC)
WO2021093334A1 (zh) 车辆升级包处理方法和装置
WO2019184924A1 (zh) 身份管理方法、设备、通信网络及存储介质
US11947681B2 (en) Cryptographic secret generation and provisioning
US8924715B2 (en) Methods and apparatus for storage and execution of access control clients
US20040161110A1 (en) Server apparatus, key management apparatus, and encrypted communication method
EP3590242B1 (en) Communication interface for a low power wide area network, wireless device and server using such communication interface
WO2011134807A1 (en) Dynamic encryption and decryption for network communication
WO2003107626A2 (en) Method for establishing secure network communications
JP4283699B2 (ja) コンテンツ転送制御装置、コンテンツ配信装置およびコンテンツ受信装置
US20170213054A1 (en) Secure transactions in a memory fabric
US20170302454A1 (en) Encryption for transactions in a memory fabric
KR102266654B1 (ko) Mqtt-sn 프로토콜의 보안을 위한 mqtt-sn 보안 관리 방법 및 시스템
US11997192B2 (en) Technologies for establishing device locality
WO2023053621A1 (ja) データ通信システム、センター装置、マスタ装置、暗号化プログラム及び復号化プログラム
WO2023053622A1 (ja) データ通信システム、センター装置、マスタ装置及び秘密情報共有プログラム
WO2023053623A1 (ja) データ通信システム、センター装置、マスタ装置、更新データ配置プログラム及び更新データ取得プログラム
KR102295400B1 (ko) 블록체인 네트워크 및 분산 노드에 의한 패킷 우회 전송 시스템 및 방법
Guštin CAN Bus Security Protocol: lightweight message confidentiality, authentication, and freshness on an automotive bus
Bamberger et al. Mobile Phones as Secure Gateways for Message-Based Ubiquitous Communication (Revised)

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: 22875500

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023550370

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 202280065002.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 112022004670

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22875500

Country of ref document: EP

Kind code of ref document: A1