Data communication system, central equipment, and confidential information sharing program

Abstract

A data communication system (1) includes a center device (2) that distributes update data to a master device (4) and the master device (4) that installs the update data downloaded from the center device in an electronic control device to be reprogrammed. The center device and the master device exchange random secret information by using an algorithm of Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) for key delivery. The center device encrypts an encryption key for encrypting the update data on the basis of the exchanged secret information and delivers the encrypted encryption key to the master device.

Description

Cross - reference to related applications

[0001] This application is based on Japanese Application No. 2021 - 161214 filed on September 30, 2021, the contents of which are incorporated herein by reference.

Technical Field

[0002] The present disclosure relates to a data communication system, a center device, a master device, and a secret information sharing program.

Background Art

[0003] In recent years, with the diversification of vehicle control such as driving support functions and autonomous driving functions, the scale of application programs for vehicle control and diagnosis mounted on an electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) has been increasing. Also, with version upgrades due to function improvements and the like, the opportunity to reprogram the application program of the ECU is also increasing. Reprogramming is sometimes referred to as program update. On the other hand, with the development of communication networks and the like, the technology of connected cars has also become widespread. Under such circumstances, for example, Patent Document 1 discloses a technology 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 supervises the reprogramming of the application program of the ECU. The update data distributed from the center device to the master device includes, for example, application programs and data for autonomous driving, advanced driver - assistance systems (ADAS (Advanced Driver - Assistance Systems)), multimedia, and the like.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] When using RSA (Rivest-Shamir-Adleman cryptosystem) for key distribution to share the encryption key of an update package between the central device and the master device, forward secrecy of the encryption key cannot be ensured. Therefore, the use of RSA as the encryption algorithm for key exchange is not recommended. As an alternative to RSA, Diffie-Hellman key exchange (hereinafter referred to as DHE) and elliptic curve Diffie-Hellman key exchange (hereinafter referred to as ECDHE) are recommended as they can ensure forward secrecy.

[0006] However, both DHE and ECDHE generate the shared key seed from random numbers generated by both the central and master devices, resulting in a random key value for each vehicle for which a key can be shared. Therefore, if the update package is encrypted using that key, each vehicle will have a different encrypted update package, meaning that, for example, vehicles of different models or groups of specific vehicles will not have the same update package. As a result, efficient distribution of update packages via a Content Delivery Network (CDN) cannot be achieved.

[0007] This disclosure aims to ensure proper forward confidentiality while appropriately realizing the efficient distribution of update data via a CDN.

[0008] According to one aspect of this disclosure, the system comprises a central device that distributes update data to a master device, and a master device that installs the update data downloaded from the central device into an electronic control unit to be reprogrammed. The central device and the master device share random secret information using the Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm for key distribution. The central device encrypts an encryption key for encrypting the update data based on the shared secret information, stores the encrypted encryption key in a campaign notification, places the update data encrypted with the encryption key in a Content Delivery Network (CDN), and places the campaign notification containing the encrypted encryption key in a reprogrammed electronic control unit. The aforementioned electronic control device is included. Vehicle System The master device Send to:

[0009] The central device and master device share random secret information using the DHE or ECDHE algorithm for key distribution. The central device encrypts the encryption key for encrypting update data based on the shared secret information, stores the encrypted encryption key in the campaign notification, places the updated data encrypted with the encryption key on the Content Delivery Network (CDN), and the campaign notification containing the encrypted encryption key is targeted for repromotion. Includes electronic control unit Vehicle System Master device The system is configured to send data to [destination]. By employing the DHE or ECDHE algorithm for key distribution and sharing confidential information between the central device and the master device, it is possible to appropriately ensure forward confidentiality while efficiently distributing updated data via the CDN. [Brief explanation of the drawing]

[0012] The above-mentioned and other purposes, features, and benefits of this disclosure will be further clarified by the following detailed description with reference to the attached drawings. Those drawings are: [Figure 1] Figure 1 is a diagram showing the processing flow of the entire system in the first embodiment. [Figure 2]Figure 2 is a functional block diagram of the OTA center and OTA master. [Figure 3] Figure 3 is a diagram illustrating the encryption process in CTR mode. [Figure 4] Figure 4 is a diagram illustrating the decoding process in CTR mode. [Figure 5] Figure 5 shows a comparison of the advantages and disadvantages of CBC mode and CTR mode. [Figure 6] Figure 6 shows a comparison of throughput between CBC mode and CTR mode. [Figure 7] Figure 7 is a diagram illustrating the decoding process in CBC mode. [Figure 8] Figure 8 is a diagram illustrating the decoding process in CTR mode. [Figure 9] Figure 9 shows the processing at the OTA center. [Figure 10] Figure 10 is a diagram showing the processing at the center. [Figure 11] Figure 11 is a diagram showing the processing at the OTA center. [Figure 12] Figure 12 is a diagram illustrating the processing of the OTA master. [Figure 13] Figure 13 is a diagram illustrating the processing of the OTA master. [Figure 14] Figure 14 is a diagram illustrating the processing of the OTA master. [Figure 15] Figure 15 is a diagram illustrating the encryption process in OFB mode of the second embodiment. [Figure 16] Figure 16 is a diagram illustrating the decoding process in OFB mode. [Figure 17] Figure 17 shows a comparison of the advantages and disadvantages of CBC mode and OFB mode. [Figure 18] Figure 18 shows a comparison of throughput between CBC mode and OFB mode. [Figure 19] Figure 19 is a diagram illustrating the decoding process in CTR mode. [Figure 20] Figure 20 is a diagram illustrating the decoding process in OFB mode. [Figure 21] Figure 21 is a diagram showing the processing of the OTA center, [Figure 22] Figure 22 is a diagram showing the processing of the OTA center, [Figure 23] Figure 23 is a diagram showing the processing of the OTA center, [Figure 24] Figure 24 is a diagram showing the processing of the OTA master, [Figure 25] Figure 25 is a diagram showing the processing of the OTA master, [Figure 26] Figure 26 is a diagram showing the processing of the OTA master, [Figure 27] Figure 27 is a diagram showing the processing flow of the entire system according to the third embodiment, [Figure 28] Figure 28 is a diagram showing the processing of the OTA center, [Figure 29] Figure 29 is a diagram showing the processing of the OTA center, [Figure 30] Figure 30 is a diagram showing the processing of the OTA center, [Figure 31] Figure 31 is a diagram showing the processing of the OTA master, [Figure 32] Figure 32 is a diagram showing the processing of the OTA master, [Figure 33] Figure 33 is a diagram showing the processing of the OTA master, [Figure 34] Figure 34 is a diagram showing the processing flow of the entire system according to the fourth embodiment, [Figure 35] Figure 35 is a functional block diagram of the OTA center and the OTA master, [Figure 36] Figure 36 is a diagram showing the processing of the OTA master, [Figure 37] Figure 37 is a diagram showing the processing of the OTA master, [Figure 38] Figure 38 is a diagram showing the processing of the OTA master, [Figure 39] Figure 39 is a diagram showing the processing of the OTA master according to the fifth embodiment, [Figure 40]Figure 40 is a diagram illustrating the processing of the OTA master. [Figure 41] Figure 41 is a diagram illustrating the processing of the OTA master. [Figure 42] Figure 42 shows the relationship between memory capacity and access speed. [Figure 43] Figure 43 is a diagram showing the processing flow of the entire system in the sixth embodiment. [Figure 44] Figure 44 is a functional block diagram of the OTA center and OTA master. [Figure 45] Figure 45 is a diagram showing how RP metadata is transmitted. [Figure 46] Figure 46 is a diagram showing the configuration of RP metadata. [Figure 47] Figure 47 is a diagram showing the configuration of RP metadata. [Figure 48] Figure 48 is a diagram showing the processing at the OTA center. [Figure 49] Figure 49 is a diagram showing the processing at the OTA center. [Figure 50] Figure 50 is a diagram showing the processing at the OTA center. [Figure 51] Figure 51 is a diagram showing the processing at the OTA center. [Figure 52] Figure 52 is a diagram showing the processing of the OTA master. [Figure 53] Figure 53 is a diagram illustrating the processing of the OTA master. [Figure 54] Figure 54 is a diagram showing the processing of the OTA master. [Figure 55] Figure 55 is a diagram showing the processing flow of the entire system in the seventh embodiment. [Figure 56] Figure 56 shows the functions of CCMP mode. [Figure 57] Figure 57 illustrates the throughput estimation using CCMP mode. [Figure 58] Figure 58 is a functional block diagram of the conventional method. [Figure 59]Figure 59 is a diagram illustrating the estimation of throughput using the conventional method. [Figure 60] Figure 60 shows a comparison of the throughput of the CCMP mode and the conventional method. [Figure 61] Figure 61 is a functional block diagram of the OTA center and OTA master. [Figure 62] Figure 62 is a diagram showing the processing at the OTA center. [Figure 63] Figure 63 is a diagram showing the processing at the OTA center. [Figure 64] Figure 64 is a diagram showing the processing at the OTA center. [Figure 65] Figure 65 is a diagram illustrating the processing of the OTA master. [Figure 66] Figure 66 is a diagram illustrating the processing of the OTA master. [Figure 67] Figure 67 is a diagram illustrating the processing of the OTA master. [Figure 68] Figure 68 is a diagram showing the processing flow of the entire system in the eighth embodiment. [Figure 69] Figure 69 is a functional block diagram of the GCMP mode. [Figure 70] Figure 70 illustrates the throughput estimation using GCMP mode. [Figure 71] Figure 71 shows a comparison of throughput between GCMP mode and the conventional method. [Figure 72] Figure 72 is a diagram showing the processing at the OTA center. [Figure 73] Figure 73 is a diagram showing the processing at the OTA center. [Figure 74] Figure 74 is a diagram showing the processing at the OTA center. [Figure 75] Figure 75 is a diagram illustrating the processing of the OTA master. [Figure 76] Figure 76 is a diagram showing the processing of the OTA master. [Figure 77] Figure 77 is a diagram showing the processing of the OTA master. [Figure 78]Figure 78 is a diagram showing the processing flow of the entire system in the ninth embodiment. [Figure 79] Figure 79 is a diagram showing the processing at the OTA center. [Figure 80] Figure 80 is a diagram showing the processing at the OTA center. [Figure 81] Figure 81 is a diagram showing the processing at the OTA center. [Figure 82] Figure 82 is a diagram showing the processing at the OTA center. [Figure 83] Figure 83 is a diagram illustrating the processing of the OTA master. [Figure 84] Figure 84 is a diagram illustrating the processing of the OTA master. [Figure 85] Figure 85 is a diagram illustrating the processing of the OTA master. [Figure 86] Figure 86 is a diagram illustrating the processing of the OTA master. [Figure 87] Figure 87 is a diagram showing the processing flow of the entire system in the 10th embodiment. [Figure 88] Figure 88 shows a cost comparison of CDNs. [Figure 89] Figure 89 shows a cost comparison of CDNs. [Figure 90] Figure 90 shows the CDN pricing table for each cloud service. [Figure 91] Figure 91 is a diagram showing the price table for storage methods of each cloud service provider. [Figure 92] Figure 92 shows a price table for each streaming size in the streaming methods of cloud service providers. [Figure 93] Figure 93 shows a price table for each streaming size for each cloud service provider's streaming method. [Figure 94] Figure 94 is a functional block diagram of the OTA center and OTA master. [Figure 95] Figure 95 is a diagram showing the processing at the OTA center. [Figure 96] Figure 96 is a diagram showing the processing at the OTA center. [Figure 97] Figure 97 is a diagram showing the processing at the OTA center. [Figure 98] Figure 98 is a diagram showing the processing at the OTA center. [Figure 99] Figure 99 is a diagram showing the processing flow of the entire system in the 11th embodiment. [Figure 100] Figure 100 is a diagram showing a common key that can be shared using DHE or ECDHE. [Figure 101] Figure 101 is a diagram showing the processing at the OTA center. [Figure 102] Figure 102 is a diagram showing the processing at the OTA center. [Figure 103] Figure 103 is a diagram showing the processing at the OTA center. [Figure 104] Figure 104 is a diagram showing the processing at the OTA center. [Figure 105] Figure 105 is a diagram illustrating the processing of the OTA master. [Figure 106] Figure 106 is a diagram illustrating the processing of the OTA master. [Figure 107] Figure 107 is a diagram illustrating the processing of the OTA master. [Figure 108] Figure 108 is a diagram illustrating the processing of the OTA master. [Figure 109] Figure 109 is a diagram showing the processing flow of the entire system in the 12th embodiment. [Figure 110] Figure 110 is a diagram showing the processing at the OTA center. [Figure 111] Figure 111 is a diagram showing the processing at the OTA center. [Figure 112] Figure 112 is a diagram showing the processing at the OTA center. [Figure 113] Figure 113 is a diagram illustrating the processing of the OTA master. [Figure 114] Figure 114 is a diagram illustrating the processing of the OTA master. [Figure 115]Figure 115 is a diagram illustrating the processing of the OTA master. [Figure 116] Figure 116 is a diagram showing the processing flow of the entire system in the 13th embodiment. [Figure 117] Figure 117 is a diagram illustrating the encryption process in CTR mode. [Figure 118] Figure 118 is a diagram illustrating the decoding process in CTR mode. [Figure 119] Figure 119 is a diagram showing the processing at the OTA center. [Figure 120] Figure 120 is a diagram showing the processing at the OTA center. [Figure 121] Figure 121 is a diagram showing the processing at the OTA center. [Figure 122] Figure 122 is a diagram illustrating the processing of the OTA master. [Figure 123] Figure 123 is a diagram illustrating the processing of the OTA master. [Figure 124] Figure 124 is a diagram illustrating the processing of the OTA master. [Figure 125] Figure 125 is a diagram showing the processing flow of the entire system in the 14th embodiment. [Figure 126] Figure 126 is a diagram illustrating AES individual keys. [Figure 127] Figure 127 is a diagram showing the processing at the OTA center. [Figure 128] Figure 128 is a diagram showing the processing at the OTA center. [Figure 129] Figure 129 is a diagram showing the processing at the OTA center. [Figure 130] Figure 130 is a diagram illustrating the processing of the OTA master. [Figure 131] Figure 131 is a diagram illustrating the processing of the OTA master. [Figure 132] Figure 132 is a diagram illustrating the processing of the OTA master. [Figure 133] Figure 133 is a diagram showing the processing flow of the entire system in the 15th embodiment. [Figure 134]Figure 134 is a diagram showing the processing at the OTA center. [Figure 135] Figure 135 is a diagram showing the processing at the OTA center. [Figure 136] Figure 136 is a diagram illustrating the processing of the OTA master. [Figure 137] Figure 137 is a diagram illustrating the processing of the OTA master. [Figure 138] Figure 138 is a diagram showing the processing flow of the entire system in the 16th embodiment. [Figure 139] Figure 139 illustrates an attack from a middle attacker. [Figure 140] Figure 140 is a diagram illustrating the process of applying a digital signature. [Figure 141] Figure 141 is a diagram showing the processing at the OTA center. [Figure 142] Figure 142 is a diagram showing the processing at the OTA center. [Figure 143] Figure 143 is a diagram showing the processing at the OTA center. [Figure 144] Figure 144 is a diagram illustrating the processing of the OTA master. [Figure 145] Figure 145 is a diagram illustrating the processing of the OTA master. [Figure 146] Figure 146 is a diagram showing the processing flow of the entire system in the 17th embodiment. [Figure 147] Figure 147 is a diagram showing the processing at the OTA center. [Figure 148] Figure 148 is a diagram showing the processing at the OTA center. [Figure 149] Figure 149 is a diagram illustrating the processing of the OTA master. [Figure 150] Figure 150 is a diagram illustrating the processing of the OTA master. [Figure 151] Figure 151 is a diagram illustrating the processing of the OTA master. [Figure 152] Figure 152 is a diagram showing the processing flow of the entire system in the 18th embodiment. [Figure 153]Figure 153 shows the CDN pricing table for each cloud service. [Figure 154] Figure 154 shows the CDN pricing table for each cloud service. [Figure 155] Figure 155 is a diagram showing the price table for storage methods of each cloud service provider. [Figure 156] Figure 156 is a diagram showing the price table for storage methods of each cloud service provider. [Figure 157] Figure 157 shows a price table for each streaming size for each cloud service provider's streaming method. [Figure 158] Figure 158 shows a price table for each streaming size for each cloud service provider's streaming method. [Figure 159] Figure 159 shows a price table for each streaming size for each cloud service provider's streaming method. [Figure 160] Figure 160 shows a price table for each streaming size for each cloud service provider's streaming method. [Figure 161] Figure 161 is a diagram showing the quality information of each cloud service provider. [Figure 162] Figure 162 is a diagram illustrating the selection of a CDN vendor. [Figure 163] Figure 163 is a diagram showing the processing at the OTA center. [Figure 164] Figure 164 is a diagram showing the processing at the OTA center. [Figure 165] Figure 165 is a diagram showing the processing at the OTA center. [Figure 166] Figure 166 shows a modified example of the 11th embodiment and illustrates a part of the processing flow in the entire system. [Figure 167] Figure 167 is a diagram showing a part of the processing flow in the entire system. [Figure 168]Figure 168 is a diagram showing a part of the processing flow in the entire system. [Figure 169] Figure 169 is a diagram showing a part of the processing flow in the entire system. [Figure 170] Figure 170 is a diagram illustrating the processing of the OTA master. [Figure 171] Figure 171 is a diagram illustrating the processing performed by the PC. [Figure 172] Figure 172 is a diagram showing the processing at the OTA center. [Figure 173] Figure 173 is a diagram illustrating the processing of the OTA master. [Figure 174] Figure 174 shows a modified example of the 12th embodiment and illustrates a part of the processing flow in the entire system. [Figure 175] Figure 175 is a diagram showing a part of the processing flow in the entire system. [Figure 176] Figure 176 is a diagram showing a part of the processing flow in the entire system. [Figure 177] Figure 177 is a diagram showing a part of the processing flow in the entire system. [Figure 178] Figure 178 is a diagram illustrating the processing of the OTA master. [Figure 179] Figure 179 is a diagram illustrating the processing performed by the PC. [Figure 180] Figure 180 is a diagram showing the processing at the OTA center. [Figure 181] Figure 181 is a diagram illustrating the processing of the OTA master. [Figure 182] Figure 182 shows a modified example of the 16th embodiment and illustrates a part of the processing flow in the entire system. [Figure 183] Figure 183 is a diagram showing a part of the processing flow in the entire system. [Figure 184] Figure 184 is a diagram showing a part of the processing flow in the entire system. [Figure 185] Figure 185 is a diagram showing a part of the processing flow in the entire system. [Figure 186]Figure 186 is a diagram illustrating the processing of the OTA master. [Figure 187] Figure 187 is a diagram illustrating the processing performed by the PC. [Figure 188] Figure 188 is a diagram showing the processing at the OTA center. [Figure 189] Figure 189 is a diagram illustrating the processing of the OTA master. [Figure 190] Figure 190 is a diagram showing the processing flow of the entire system in the 19th embodiment. [Figure 191] Figure 191 is a diagram showing the processing of the campaign notification generation unit. [Figure 192] Figure 192 is a diagram showing the processing of the CDN vendor selection section. [Figure 193] Figure 193 is a diagram showing the processing of the CDN vendor selection section. [Figure 194] Figure 194 is a diagram showing the overall processing flow of the first modified example of the 19th embodiment. [Figure 195] Figure 195 shows the processing of the CDN vendor selection section. [Figure 196] Figure 196 is a diagram showing the overall processing flow of the second modified example of the 19th embodiment. [Figure 197] Figure 197 is a diagram showing a selection table. [Figure 198] Figure 198 shows the processing of the CDN vendor selection section. [Figure 199] Figure 199 is a diagram showing the processing of the CDN vendor selection section. [Figure 200] Figure 200 is a diagram showing the processing of the performance measurement unit. [Figure 201] Figure 201 is a diagram showing the processing of the CDN server verification section. [Figure 202] Figure 202 is a diagram showing the overall processing flow of the third modified example of the 19th embodiment. [Figure 203] Figure 203 shows the processing of the log transmission unit 3a. [Figure 204] Figure 204 shows the processing of the performance measurement unit. [Figure 205] Figure 205 shows the processing of the performance measurement unit. [Figure 206] Figure 206 shows a fourth modified example of the 19th embodiment, illustrating the processing of the CDN vendor selection unit 7a. [Figure 207] Figure 207 shows the processing of the campaign notification generation unit. [Figure 208] Figure 208 is a diagram showing the overall processing flow of the fifth modified example of the 19th embodiment. [Figure 209] Figure 209 is a diagram showing round-robin records. [Figure 210] Figure 210 shows the processing of the CDN vendor selection unit 7a. [Figure 211] Figure 211 is a diagram showing the process of the switching section. [Figure 212] Figure 212 is a diagram showing the processing flow of the entire system in the 20th embodiment. [Figure 213] Figure 213 is a diagram illustrating the calculation method. [Figure 214] Figure 214 is a diagram showing the processing of the campaign notification generation unit. [Figure 215] Figure 215 is a diagram showing the processing of the CDN vendor selection section. [Figure 216] Figure 216 shows the processing of the CDN vendor selection section. [Figure 217] Figure 217 is a diagram showing the processing of the CDN vendor selection section. [Figure 218] Figure 218 shows the processing of the CDN vendor selection section. [Figure 219] Figure 219 shows the processing of the CDN vendor selection section. [Figure 220] Figure 220 shows the processing of the CDN vendor selection section. [Figure 221] Figure 221 is a diagram showing the processing of the CDN vendor selection section. [Figure 222] Figure 222 is a diagram showing the processing of the progress information management unit. [Figure 223]Figure 223 shows the processing of the CDN vendor selection section. [Figure 224] Figure 224 shows the processing of the campaign notification generation unit. [Modes for carrying out the invention]

[0013] Several embodiments will be described below with reference to the drawings. Note that in subsequent embodiments, explanations of content that overlaps with earlier embodiments may be omitted.

[0014] (First Embodiment) The first embodiment will be described with reference to Figures 1 to 14. As shown in Figure 1, the data communication system 1 comprises an OTA center 2 and a vehicle-side system 3 installed in a vehicle, and the OTA center 2 and the vehicle-side system 3 are configured to communicate data. The OTA center 2 corresponds to a central device. The OTA center 2 and the vehicle-side system 3 have a one-to-many relationship, and the OTA center 2 can communicate data with an unspecified number of vehicle-side systems 3.

[0015] The vehicle-side system 3 comprises 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 in a way that enables data communication via the in-vehicle network. The in-vehicle network may also be LIN (Local Interconnect Network), FlexRay (registered trademark), CAN FD (CAN Flexible Data rate) (registered trademark), Ethernet (registered trademark), etc. The target ECU 5 is the ECU to which the application program is reprogrammed, and may be any of the following: an ECU that controls the autonomous driving system, an ECU that controls the ADAS system, an ECU that controls the multimedia system, etc. The application program is a program related to the execution of an application, and includes, for example, an application program, a firmware program, and an operating system program.

[0016] OTA Center 2 comprises a package generation server 6 and a distribution server 7. Package generation server 6 is a server that has the function of packaging update data and generating update packages. The update package is, for example, a zip file containing multiple files that store update data, compressed together. Distribution server 7 is a server that has the function of distributing the update packages generated by package generation server 6 to the vehicle-side system 3.

[0017] OTA Center 2, for example, when a reprogramming request for the ECU's application program occurs due to a version upgrade such as a functional improvement, distributes a campaign notification to the vehicle-side system 3 and the user's mobile information terminal, such as a smartphone. Subject to obtaining the user's consent to download, OTA Center 2 places the update package on the Content Delivery Network (CDN) 8 and distributes the update package to OTA Master 4 via CDN 8. Alternatively, if the update package is already placed on CDN 8, OTA Center 2, subject to obtaining the user's consent to download, has the CDN 8 distribute the update package to OTA Master 4.

[0018] OTA Master 4 downloads the update package from OTA Center 2, and, provided that user consent for installation is obtained, transfers the update package to Target ECU 5 and installs it on Target ECU 5. The company that provides CDN 8 as a service is called the CDN vendor. OTA Master 4 also obtains the update package by accessing the CDN 8 CDN server.

[0019] In this embodiment, in order to speed up the decryption process of the Advanced Encryption Standard (hereinafter abbreviated as AES) in the vehicle-side system 3, the encryption mode is not the general block cipher chaining mode (hereinafter referred to as CBC mode), but rather the counter mode (hereinafter referred to as CTR mode), which is representative of streaming encryption. In this embodiment, the OTA center 2 encrypts the update package in CTR mode using the AES key. The vehicle-side system 3 also encrypts the update package in CTR mode using the AES key. The OTA center 2 has an RSA (Rivest-Shamir-Adleman cryptosystem) public key for each vehicle. The OTA master 4 has the RSA private key written to it during the vehicle manufacturing stage.

[0020] As shown in Figure 2, the OTA Center 2 comprises the following 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. The update package encryption unit 2b corresponds to the encryption of update data. The encrypted package placement unit 2e corresponds to the encrypted data placement unit. Each unit 2a to 2f is realized through the collaboration of hardware and software of a microcomputer having a CPU (Central Processing Unit), RAM (Random Access Memory), ROM (Read Only Memory), I / O (Input / Output), etc. The CPU realizes the functions of the OTA Center 2 by executing various programs, including an encryption program, an update data placement program, and a secret information sharing program, which are stored in ROM.

[0021] The shared key generation unit 2a generates an AES key as a shared 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 performing AES block cipher processing on the counter value using the AES key. The package encryption unit 2b performs an exclusive OR (XOR) operation on the encrypted counter value and the update package, combines the multiple encrypted fragments, and generates an update package encrypted with the AES key. The counter value is, for example, an 8-digit number, and increases by "1" for each AES block.

[0022] The symmetric key encryption unit 2c encrypts the AES key using an RSA public key. The symmetric 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 on the CDN8. The campaign notification transmission unit 2f sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed. The campaign notification transmission unit 2f may also deliver the campaign notification to a mobile information terminal such as a smartphone owned by the user.

[0023] The OTA Master 4 comprises a common key acquisition unit 4a, a common key decryption unit 4b, an encryption package acquisition unit 4c, a block cipher processing unit 4d, an encryption package decryption unit 4e, and an installation processing unit 4f as functional blocks related to decryption. The encryption package acquisition unit 4c corresponds to the encryption data acquisition unit. The encryption package decryption unit 4e corresponds to the encryption data decryption unit. Each unit 4a to 4f is realized through the cooperation of hardware and software of a microcomputer having a CPU, RAM, ROM, I / O, etc. The CPU realizes the functions of the OTA Master 4 by executing various programs, including a decryption program, an update data acquisition program, and a secret information sharing program, which are stored in ROM.

[0024] The shared key acquisition unit 4a acquires the campaign notification when it is received by the OTA master 4 from the OTA center 2, and then acquires the encrypted AES key from the acquired campaign notification. The shared key decryption unit 4b decrypts the encrypted AES key using an RSA secret key to extract the AES key. The encrypted package acquisition unit 4c acquires the encrypted update package by downloading it from CDN 8. At this time, the block cipher processing unit 4d performs AES block cipher processing on the counter value using the AES key in parallel with the encrypted package acquisition unit 4c acquiring the encrypted update package from CDN 8, thereby encrypting the counter value. The encrypted package decryption unit 4e decrypts the encrypted counter value and the encrypted update package downloaded from CDN 8 by performing an exclusive OR (XOR) operation. The installation processing unit 4f transfers the decrypted update package to the target ECU 5 and installs the update package to the target ECU 5.

[0025] The encryption process in CTR mode is shown in Figure 3, and the decryption process in CTR mode is shown in Figure 4. As shown in Figure 5, the disadvantages of CBC mode are that "preparation for encryption and decryption cannot be done" and "parallel processing of encryption cannot be done," while the advantages of CTR mode are that "preparation for encryption and decryption can be done, so it can be done faster" and "parallel processing of encryption and decryption can be done." In other words, as shown in Figure 6, the advantage of adopting CTR mode as the encryption mode is that it can improve throughput by about 40% compared to adopting the CBC mode of a typical block cipher.

[0026] As shown in Figure 7, in CBC mode decryption, the input is ciphertext, so the decryption process cannot begin until the ciphertext update package is received. In contrast, as shown in Figure 8, in CTR mode decryption, the input is a counter value, so the decryption process can begin even before the ciphertext update package is received. Furthermore, since there are no interdependencies, multiple cryptographic operations can be executed simultaneously in parallel.

[0027] Next, the operation of the above configuration will be explained with reference to Figures 9 to 14. (1-1) Processing at OTA Center 2 (See Figures 9 to 11) OTA Center 2 generates an AES key to encrypt the update package (A011, equivalent to the symmetric key generation procedure). OTA Center 2 encrypts the update package in CTR mode using the generated AES key (A012, equivalent to the update data encryption procedure). OTA Center 2 encrypts the AES key using an RSA public key (A013, equivalent to the symmetric key encryption procedure). OTA Center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A014, equivalent to the symmetric key storage procedure). OTA Center 2 places the update package encrypted with the AES key on the CDN8 (A015, equivalent to the encrypted data placement procedure). Placing the update package on the CDN8 means placing the update package on the CDN8's origin server. OTA Center 2 sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A016, equivalent to the campaign notification sending procedure).

[0028] (1-2) Processing of OTA Master 4 (See Figures 12 to 14) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it obtains the campaign notification and then retrieves the AES key from the obtained campaign notification (B011, corresponding to the symmetric key acquisition procedure). OTA Master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B012, corresponding to the symmetric key decryption procedure). OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B013, corresponding to the encrypted data acquisition procedure).

[0029] At this time, OTA Master 4 downloads and obtains the encrypted update package from CDN 8, and simultaneously encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B014, corresponding to the block cipher processing procedure). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN 8 (B015, corresponding to the encrypted data decryption procedure). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B016, corresponding to the installation procedure). Furthermore, by encrypting and decrypting the differential program within the update package in CTR mode instead of CBC mode, the throughput of the decryption process on Target ECU 5 can be improved by approximately 40%.

[0030] As described above, the first embodiment provides the following effects and advantages. The update package uses the CTR mode as its encryption and decryption method. Compared to the previous configuration which used the CBC mode, adopting the CTR mode allows for pre-processing of encryption and decryption, and enables parallel processing of encryption and decryption. As a result, when the OTA master 4 downloads the update package from the OTA center 2, it can enjoy the benefits of the CTR mode and appropriately increase throughput.

[0031] (Second Embodiment) The second embodiment will be described with reference to Figures 15 to 26. The first embodiment employs CTR mode as the encryption mode, while the second embodiment employs output feedback mode (hereinafter referred to as OFB mode (Output-FeedBack mode)) as the encryption mode.

[0032] In this case, the package encryption unit 2b encrypts the update package in OFB mode using the generated AES key. The block cipher processing unit 4d performs AES stream cipher processing based on the Initialization Vector (IV) value using the AES key, in parallel with the encrypted update package acquisition unit 4c downloading and acquiring the encrypted update package from CDN8. The IV value is an initialization vector value, which for example represents a randomly generated bit sequence. The encrypted package decryption unit 4e decrypts the package by performing an XOR operation on the encrypted IV value and the encrypted update package downloaded from CDN8.

[0033] The encryption process in OFB mode is shown in Figure 15, and the decryption process in OFB mode is shown in Figure 16. As shown in Figure 17, the disadvantages of CBC mode are that "preparation for encryption and decryption cannot be done" and "parallel processing of encryption cannot be done," while the advantage of OFB mode is that "preparation for encryption and decryption can be done, so it can be done quickly." In other words, as shown in Figure 18, the advantage of adopting OFB mode as the encryption mode is that throughput can be improved by about 25% compared to when the CBC mode of a typical block cipher is adopted.

[0034] As shown in Figure 19, in the CTR mode decryption process, since the input is a counter value, the decryption process can start even before receiving the update package, which is the ciphertext. Also, since there are no interdependencies, multiple cryptographic operations can be executed simultaneously in parallel. In contrast, as shown in Figure 20, in the OFB mode decryption process, there are interdependencies, so multiple cryptographic operations cannot be executed simultaneously in parallel. However, the process of decrypting by performing an XOR operation on the encrypted IV value and the encrypted update package can be executed in parallel. Therefore, although the throughput of the OFB mode decryption process cannot be improved to the same extent as the CTR mode decryption process described in the first embodiment, it can improve throughput compared to the case where CBC mode is adopted.

[0035] Next, the operation of the above configuration will be explained with reference to Figures 21 to 26. (2-1) Processing at OTA Center 2 (See Figures 21 to 23) OTA Center 2 generates an AES key to encrypt the update package (A021, equivalent to the symmetric key generation procedure). OTA Center 2 encrypts the update package in OFB mode using the generated AES key (A022, equivalent to the update data encryption procedure). OTA Center 2 encrypts the AES key using an RSA public key (A023, equivalent to the symmetric key encryption procedure). OTA Center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A024, equivalent to the symmetric key storage procedure). OTA Center 2 places the update package encrypted with the AES key on the CDN8 (A025, equivalent to the encrypted data placement procedure). OTA Center 2 sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A026, equivalent to the campaign notification transmission procedure).

[0036] (2-2) Processing of OTA Master 4 (See Figures 24 to 26) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it obtains the campaign notification and then retrieves the AES key from the obtained campaign notification (B021, corresponding to the symmetric key acquisition procedure). OTA Master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B022, corresponding to the symmetric key decryption procedure). OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B023, corresponding to the encrypted data acquisition procedure).

[0037] At this time, OTA Master 4 downloads and retrieves the encrypted update package from CDN8, and simultaneously performs IV value-based AES stream cipher processing using the AES key to encrypt the IV value (B024, equivalent to block cipher processing procedure). OTA Master 4 decrypts the encrypted IV value by performing an XOR operation on the encrypted update package downloaded from CDN8 (B025, equivalent to encrypted data decryption procedure). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B026, equivalent to installation procedure). Furthermore, by encrypting and decrypting in OFB mode instead of CBC mode for the differential program within the update package, the throughput of the decryption process on Target ECU 5 can be improved by approximately 25%.

[0038] As described above, the second embodiment provides the following effects and advantages. The update package uses OFB mode as its encryption and decryption method. Compared to the previous configuration which used CBC mode, adopting OFB mode allows for pre-encryption and decryption preparation. As a result, when OTA Master 4 downloads the update package from OTA Center 2, it can benefit from OFB mode and appropriately increase throughput.

[0039] (Third embodiment) The third embodiment will be described with reference to Figures 27 to 33. In the third embodiment, the Hypertext Transfer Protocol (hereinafter referred to as HTTP) is adopted as the communication protocol between CDN8 and OTA Master 4, a range request is sent to CDN8, and the update package is downloaded using a streaming method, thereby reducing delivery costs compared to when Hypertext Transfer Protocol Secure (hereinafter referred to as HTTPS) is adopted. Some CDN vendors differentiate the CDN8's delivery fees depending on whether HTTP or HTTPS is used as the communication protocol to CDN8. When HTTPS is used, CDN8 needs to perform handshake processing, encryption key exchange processing, and cryptographic calculation processing as defined by Transport Layer Security (hereinafter referred to as TLS), which increases the processing load on CDN8's CPU, and therefore the delivery fee for HTTPS is approximately 30% higher than that for HTTP. For this reason, delivery costs are reduced by using HTTP for downloading the update package. In the third embodiment, HTTPS is not used when distributing the update package from CDN8 to the vehicle-side system 3.

[0040] In this case, the campaign notification transmission unit 2f establishes TLS communication between the OTA center 4 and the OTA master 4, and then sends a 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 when it is received by the OTA master 4 after TLS communication has been established and the campaign notification sent from the OTA center 2 has been acquired, and then acquires the AES key from the acquired campaign notification. The encrypted package acquisition unit 4c sends a range request to the CDN 8 to specify the data range to be downloaded, and then downloads and acquires the encrypted update package from the CDN 8 using a streaming method. The installation processing unit 4f transfers the decrypted update package to the target ECU 5 using a streaming method and installs the update package to the target ECU 5.

[0041] In this embodiment, the OTA master 4 is described as obtaining the encrypted update package from the CDN 8 via streaming; however, the encrypted update package may also be obtained from the CDN 8 via storage. Since the streaming method includes header information during communication, using HTTP can further reduce delivery costs.

[0042] Next, the operation of the above configuration will be explained with reference to Figures 28 to 33. (3-1) Processing at OTA Center 2 (See Figures 28 to 30) OTA Center 2 generates an AES key to encrypt the update package (A031). OTA Center 2 encrypts the update package in CTR mode using the generated AES key (A032). OTA Center 2 encrypts the AES key using an RSA public key (A033). OTA Center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A034). OTA Center 2 places the update package encrypted with the AES key on CDN8 (A035). OTA Center 2 establishes TLS communication with OTA Center 4 and OTA Master 4, and then sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A036).

[0043] (3-2) Processing of OTA Master 4 (See Figures 31 to 33) Once TLS communication is established, OTA Master 4 receives the campaign notification sent from OTA Center 2 and obtains it. From this notification, OTA Master 4 retrieves the AES key (B031). OTA Master 4 decrypts the encrypted AES key using its RSA private key to extract the AES key (B032). OTA Master 4 sends a range request to CDN 8 to specify the data range to be downloaded and retrieves the encrypted update package from CDN 8 using a streaming method (B033). In other words, OTA Master 4 retrieves the update package from CDN 8 using a segmented streaming method by specifying the data range to be downloaded.

[0044] At this time, while the encrypted update package acquisition unit 4c downloads and acquires the encrypted update package from CDN8, the OTA master 4 performs AES block cipher processing on the counter value using the AES key to encrypt the counter value (B034). The OTA master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN8 (B035). The OTA master 4 streams the decrypted update package to the target ECU 5 and installs the update package on the target ECU 5 (B036).

[0045] As described above, the third embodiment provides the following effects and advantages. HTTP is used as the communication protocol between CDN8 and OTA Master 4, and the configuration allows OTA Master 4 to send a range request to CDN8, from which the update package is downloaded via streaming. This allows for appropriate reduction of the distribution cost when OTA Master 4 downloads the update package from OTA Center 2, compared to the conventional method which used HTTPS as the communication protocol.

[0046] (Fourth Embodiment) The fourth embodiment will be described with reference to Figures 34 to 38. The fourth embodiment aims to speed up the decryption process when downloading the update package by performing the calculation of all key streams in the background before obtaining download consent from the user.

[0047] In this case, as shown in Figure 35, 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, an installation processing unit 4f, and a key stream calculation unit 4g. The key stream calculation unit 4g performs the calculation of all key streams in the background before obtaining download consent from the user. The encrypted package acquisition unit 4c obtains the encrypted update package by downloading it from the CDN8, provided that download consent has been obtained from the user. The encrypted package decryption unit 4e decrypts the package by performing an XOR operation on the calculated key stream and the encrypted update package downloaded from the CDN8.

[0048] Next, the operation of the above-described configuration will be explained with reference to Figures 36 to 38. (4-1) Processing at OTA Center 2 The processing at OTA Center 2 is the same as the processing at OTA Center 2 described in the first embodiment (Figures 9 to 11).

[0049] (4-2) Processing of OTA Master 4 (See Figures 36 to 38) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it retrieves the AES key from the received campaign notification (B041). OTA Master 4 decrypts the encrypted AES key using its RSA private key to extract the AES key (B042). OTA Master 4 performs the calculation of all key streams in the background before obtaining download consent from the user (B043). Each key stream is assigned identification information indicating the order in which it should be applied to the encrypted update package.

[0050] OTA Master 4 delivers campaign notifications to the vehicle-side system 3 and the user's mobile information terminal, such as a smartphone, and displays a download consent screen on the HMI (Human Machine Interface) (B044). Conditional on obtaining download consent from the user, OTA Master 4 downloads and obtains an encrypted update package from CDN 8 (B045). OTA Master 4 decrypts the encrypted update package downloaded from CDN 8 by performing an XOR operation between a pre-calculated key stream and the encrypted update package (B046). OTA Master 4 transfers the decrypted update package to the target ECU 5 and installs the update package on the target ECU 5 (B047).

[0051] As described above, the fourth embodiment provides the following effects and advantages. The system is configured to perform the calculation of all key streams in the background before obtaining user consent for download. This speeds up the decryption process of update packages on OTA Master 4, and increases the throughput when OTA Master 4 downloads update packages from OTA Center 2.

[0052] (Fifth embodiment) The fifth embodiment will be described with reference to Figures 39 to 42. In the fourth embodiment, all key stream calculations are performed in the background before obtaining user consent for download, but in the fifth embodiment, some key stream calculations are performed in the background before obtaining user consent for download. The some key streams to be calculated are determined considering the memory capacity of the CPU cache memory and the throughput of AES cryptographic operations, and are sized to be storable in the cache memory.

[0053] In this case, the key stream calculation unit 4g performs some key stream calculations in the background before obtaining user consent for download. The key stream calculation unit 4g generates key streams and adds them to cache memory in parallel with the encrypted update package acquisition unit 4c downloading and acquiring the encrypted update package from CDN8.

[0054] Next, the operation of the above-described configuration will be explained with reference to Figures 39 to 42. (5-1) Processing at OTA Center 2 The processing at OTA Center 2 is the same as the processing at OTA Center 2 described in the first embodiment (Figures 9 to 11).

[0055] (5-2) Processing of OTA Master 4 (See Figures 39 to 41) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it retrieves the AES key from the retrieved campaign notification (B051). OTA Master 4 decrypts the encrypted AES key using its RSA private key to extract the AES key (B052). OTA Master 4 performs some key stream calculations in the background before obtaining download consent from the user (B053).

[0056] OTA Master 4 delivers campaign notifications to the vehicle-side system 3 and mobile information terminals such as smartphones owned by the user, and displays a download consent screen on the HMI (B054). Conditional on obtaining download consent from the user, OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B055). OTA Master 4 decrypts the encrypted update package downloaded from CDN 8 by performing an XOR operation on a pre-calculated key stream (B056).

[0057] At this time, OTA Master 4 downloads and retrieves the encrypted update package from CDN8, while simultaneously generating a key stream and adding it to the cache memory (B057), and then calculates the remaining key stream. OTA Master 4 then transfers the decrypted update package to the target ECU 5 and installs the update package on the target ECU 5 (B058). The relationship between memory capacity and access speed is shown in Figure 42, and the size of the cache memory should be determined according to the required access speed.

[0058] As described above, the fifth embodiment provides the following effects and advantages. The system is configured to perform some key stream calculations in the background before obtaining user consent for download. This allows for faster decryption of update packages on OTA Master 4 while saving memory usage on OTA Master 4, thereby increasing the throughput when OTA Master 4 downloads update packages from OTA Center 2.

[0059] (Sixth Embodiment) The sixth embodiment will be described with reference to Figures 43 to 54. In the sixth embodiment, the encryption method is included in the repro policy metadata (hereinafter referred to as RP metadata) and transmitted from the OTA center 2 to the OTA master 4, thereby allowing the OTA master 4 to identify the encryption method. The encryption method transmitted from the OTA center 2 to the OTA master 4 includes the encryption algorithm, encryption key length, encryption mode, message authentication code (hereinafter referred to as MAC (Message Authentication Code)) algorithm, etc.

[0060] RP metadata contains configuration information for the update package, specifically information representing the configuration type of the update package. The OTA master 4 checks the contents of this data to prevent errors in the delivery of the update package. By using a three-tier structure for RP metadata—distribution, master, and target—it is possible to flexibly define and handle an increase in the number of transfer methods, platform types, and update package types, enabling reprogramming of the target ECU 5. Alternatively, the encryption method can be included in the download metadata (hereinafter referred to as DL metadata) and sent from the OTA center 2 to the OTA master 4, allowing the OTA master 4 to identify the encryption method. DL metadata contains information for downloading update packages for multiple target ECU 5s and defines the contents that the OTA master 4 should be aware of.

[0061] As shown in Figure 44, 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, and a campaign notification transmission unit 2f, in addition to an RP metadata generation unit 2g and an RP metadata encryption unit 2h. The RP metadata generation unit 2g generates RP metadata including a common key encryption scheme. The RP metadata encryption unit 2h encrypts the RP metadata using an RSA public key.

[0062] The OTA master 4 includes a common key acquisition unit 4a, a common key decryption unit 4b, an encryption package acquisition unit 4c, a block cipher processing unit 4d, an encryption package decryption unit 4e, and an installation processing unit 4f, in addition to an RP metadata acquisition unit 4h, an RP metadata decryption unit 4i, and a common key encryption scheme identification unit 4j. The RP metadata acquisition unit 4h acquires encrypted RP metadata by downloading it from CDN8. The RP metadata decryption unit 4i decrypts the encrypted RP metadata using the RSA secret key to extract the RP metadata. The common key encryption scheme identification unit 4j interprets the contents of the RP metadata to identify the common key encryption scheme.

[0063] The process for delivering the update package from CDN8 to OTA Center 2 is as follows: OTA Center 2 sends a campaign notification to OTA Master 4 or the user's mobile device. Subsequently, OTA Master 4 accesses CDN8, which sends RP metadata and DL metadata to OTA Master 4, and then the update package is delivered from CDN8 to OTA Center 2.

[0064] As shown in Figure 45, the RP metadata and DL metadata are sent from OTA Center 2 to OTA Master 4 prior to the download of the update package. As shown in Figures 46 to 47, the RP metadata includes information on the RP metadata version, distribution layer, master layer, and target layer. The information for each layer is as follows:

[0065] (a) RP metadata version This is the RP metadata version, such as version information like "1.0.0" or "2.0.0". (b) Distribution layer (b-1) Communication Protocol This refers to the protocol used for communication with OTA Center 2, and includes information such as Uptane®, OMA-DM (Open Mobile Alliance-Device Management), etc. (b-2) Means of communication This information indicates the distribution route for the update package and identifies the device as an OTA Master 4, such as a cellular device, smartphone, or USB memory stick.

[0066] (c) Master Layer This is information regarding OTA Master 4. (c-1) PF This information indicates that the platform (PF) of OTA Master 4 is, for example, AP (AUTOSAR Adaptive Platform), CP (AUTOSAR Classic Platform), AGL (Automotive Grade Linux), or Android®. Regarding the package structure for delivering update packages according to the ECU platform, the JASPAR (Japan Automotive Standards and Programmers Association) specifications define data requirements applicable to the Classic Platform (CP), which operates on a static OS, as defined by the standardization body AUTOSAR. AUTOSAR also defines data requirements applicable to a new type of Adaptive Platform (AP), which operates on a dynamic OS. AGL is Automotive Linux®, and Android is Android Automotive OS. AP and CP refer to software platforms. A software platform is also called a software architecture. AP and CP differ in the operating systems and development languages ​​used. The structure of the update packages that can be received differs between ECUs operating in accordance with the CP specification and those operating in accordance with the AP specification. These differences in update package structure are mainly due to differences in the processing performance of the ECUs. Generally, ECUs operating in accordance with CP specifications have relatively low processing performance, so the specification data included in update packages is written in binary data, resulting in a data structure that is easy for even low-performance ECUs to interpret and process. On the other hand, ECUs operating in accordance with AP specifications have relatively high processing performance, so it is possible to incorporate a parser function that can analyze structured character data written in some language and convert it into a data structure that can be handled by the program. Furthermore, the data structure can adopt an object-oriented data format such as JSON (JavaScript Object Notation) rather than simple binary data, resulting in a flexible data structure.

[0067] (c-2) Control method This includes information such as parameters that are processed according to parameters set in a specific format, and scripts that are processed in a more flexible format without a specific format. (c-3) Encryption method This information includes the encryption algorithm, encryption key length, encryption mode, padding method, encryption key ID, signature algorithm, signature key ID, signature mode, hash algorithm, whether or not a region is specified, offset size, and protected data size.

[0068] (d) Target layer This is information regarding target ECU5. (d-1) PF It is similar to the master layer. (d-2) Transfer method It is either a storage method or a streaming method. (d-3) Control method It is similar to the master layer. (d-4) Target ID It is an option. (d-5) Encryption method It is similar to the master layer.

[0069] Next, the operation of the above configuration will be explained with reference to Figures 48 to 54. (6-1) Processing at OTA Center 2 (See Figures 48 to 51) OTA Center 2 generates a shared key for encrypting the update package (A061). OTA Center 2 encrypts the update package using the generated shared key in a specific encryption mode (A062). OTA Center 2 encrypts the shared key using an RSA public key (A063). OTA Center 2 stores the RSA-encrypted shared key in the campaign notification (A064). OTA Center 2 generates RP metadata including the shared key encryption scheme (A065). OTA Center 2 encrypts the RP metadata using an RSA public key (A066). OTA Center 2 places the update package encrypted with the shared key and the RSA-encrypted RP metadata on the CDN8 (A067). OTA Center 2 sends the campaign notification containing the encrypted shared key to the vehicle-side system 3 targeted for reprogramming (A068).

[0070] (6-2) Processing of OTA Master 4 (See Figures 52 to 54) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it obtains the campaign notification and retrieves the common key from the obtained campaign notification (B061). OTA Master 4 decrypts the encrypted common key using its RSA private key to extract the common key (B062). OTA Master 4 downloads and obtains the encrypted RP metadata from CDN 8 (B063). OTA Master 4 decrypts the encrypted RP metadata using its RSA private key to extract the RP metadata (B064). OTA Master 4 interprets the contents of the RP metadata to identify the common key encryption method (B065). OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B066). From here on, if CTR mode is adopted as the specific encryption mode, OTA Master 4 performs the processing from step B014 onwards as described in the first embodiment, and if OFB mode is adopted as the specific encryption mode, it performs the processing from step B024 onwards as described in the second embodiment. Similarly, for other encryption modes, follow the procedure corresponding to the encryption mode to decrypt the update package and transfer the data to the target ECU.

[0071] As described above, the sixth embodiment provides the following effects and advantages. The encryption method is included in the RP metadata and DL metadata and transmitted from OTA Center 2 to OTA Master 4. This allows OTA Master 4 to identify the encryption method.

[0072] (Seventh Embodiment) The seventh embodiment will be described with reference to Figures 55 to 67. The seventh embodiment employs CCMP mode (Counter mode with Cipher-block chaining Message authentication code Protocol) as a measure against communication channel encryption and data tampering.

[0073] In this case, as shown in Figures 56 to 60, when comparing a configuration employing CCMP mode with a configuration employing the conventional method of AES CBC-HMAC (Hashed Message Authentication Mode Code) SHA (Secure Hash Algorithm)2 decryption and signature verification, in both cases the processing time of the hardware accelerator is dominant over the processing time of the main core. However, by adopting CCMP mode, throughput can be improved.

[0074] As shown in Figure 61, 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, a campaign notification transmission unit 2f, and a MAC key generation unit 2i. The MAC key generation unit 2i generates a MAC to prevent tampering with the update package.

[0075] 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, an installation processing unit 4f, and a MAC key acquisition unit 4k. When the campaign notification sent from the OTA center 2 is received by the OTA master 4, the MAC key acquisition unit 4k acquires the campaign notification and then acquires the MAC key from the acquired campaign notification.

[0076] Next, the operation of the above-described configuration will be explained with reference to Figures 62 to 67. (7-1) Processing at OTA Center 2 (See Figures 62 to 64) OTA Center 2 generates an AES key for encrypting the update package and a MAC key to prevent tampering with the update package (A071). OTA Center 2 encrypts the update package in CCMP mode using the generated AES key and MAC key and assigns a MAC (A072). OTA Center 2 encrypts the AES key and MAC key using an RSA public key (A073). OTA Center 2 stores the AES key and MAC key encrypted with the RSA public key in a campaign notification (A074). OTA Center 2 places the update package encrypted with the AES key and MAC key on CDN8 (A075). OTA Center 2 sends the campaign notification containing the encrypted AES key and MAC key to the vehicle-side system 3 to be reprogrammed (A076).

[0077] (7-2) Processing of OTA Master 4 (See Figures 65 to 67) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it retrieves the campaign notification and then extracts the AES key and MAC address from it (B071). OTA Master 4 decrypts the encrypted AES key and MAC address using its RSA private key to extract them (B017). OTA Master 4 then downloads and retrieves the encrypted update package from CDN 8 (B073).

[0078] At this time, OTA Master 4 downloads and obtains the encrypted update package from CDN 8, and simultaneously encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B074). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN 8 (B075). OTA Master 4 generates a MAC in AES-CBC mode using the MAC key from the plaintext of the decrypted update package and verifies it (B076). If the MAC matches, OTA Master 4 transfers the decrypted update package to the target ECU 5 and installs the update package on the target ECU 5 (B077). If the MAC does not match, OTA Master 4 terminates the process. In this case, if OTA Master 4 terminates the process due to a MAC mismatch, it may record a log indicating that the process was terminated due to a MAC mismatch and may also display an error on an HMI (not shown). Alternatively, the OTA master 4 may decrypt the encrypted update package by performing an XOR operation and simultaneously transfer the decrypted update package to the target ECU 5. In this case, the OTA master 4 may be configured to generate and verify a MAC in AES-CBC mode using the MAC key from the plaintext of the decrypted update package, and if it determines that the MAC does not match, it may notify the target ECU 5 to abort the installation.

[0079] As described above, the following effects can be obtained according to the seventh embodiment. The configuration employs CCMP mode to encrypt the communication channel between OTA Center 2 and OTA Master 4 and to protect against data tampering. By adopting CCMP mode, OTA Master 4 can implement data tampering protection in addition to communication channel encryption when downloading update packages from OTA Center 2. This enhances security and enables more secure OTA delivery.

[0080] (Eighth embodiment) The eighth embodiment will be described with reference to Figures 68 to 77. The eighth embodiment employs GCMP mode (Galois / Counter Mode Protocol) for communication channel encryption and data tampering prevention.

[0081] In this case, as shown in Figures 69 to 71, when comparing a configuration employing GCMP mode with a configuration employing CCMP mode or a configuration employing the conventional method of AES CBC-HMAC SHA2 decryption and signature verification, in all cases the processing time of the hardware accelerator is dominant over the processing time of the main core. However, by adopting GCMP mode, throughput can be further improved.

[0082] Next, the operation of the above-described configuration will be explained with reference to Figures 72 to 77. (8-1) Processing at OTA Center 2 (See Figures 72 to 74) OTA Center 2 generates an AES key for encrypting the update package and a MAC key to prevent tampering with the update package (A081). OTA Center 2 encrypts the update package in GCMP mode using the generated AES key and MAC key and assigns a MAC (A082). OTA Center 2 encrypts the AES key and MAC key using an RSA public key (A083). OTA Center 2 stores the AES key and MAC key encrypted with the RSA public key in a campaign notification (A084). OTA Center 2 places the update package encrypted with the AES key and MAC key on CDN8 (A085). OTA Center 2 sends the campaign notification containing the encrypted AES key and MAC key to the vehicle-side system 3 to be reprogrammed (A086).

[0083] (8-2) Processing of OTA Master 4 (See Figures 75 to 77) When OTA Master 4 receives a campaign notification sent from OTA Center 2, it retrieves the campaign notification and then extracts the AES key and MAC address from the retrieved campaign notification (B081). OTA Master 4 decrypts the encrypted AES key and MAC address using its RSA private key to extract the AES key and MAC address (B082). OTA Master 4 then downloads and retrieves the encrypted update package from CDN 8 (B083).

[0084] At this time, OTA Master 4 downloads and obtains the encrypted update package from CDN 8, and simultaneously encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B084). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN 8 (B085). OTA Master 4 generates a MAC in GMAC mode using the MAC key from the plaintext of the decrypted update package and verifies it (B086). If the MAC matches, OTA Master transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B087).

[0085] As described above, the following effects and advantages can be obtained according to the eighth embodiment. The configuration employs GCMP mode for communication channel encryption and data tampering prevention between OTA Center 2 and OTA Master 4. By adopting GCMP mode, OTA Master 4 can implement data tampering prevention in addition to communication channel encryption when downloading update packages from OTA Center 2. This enhances security and enables more secure OTA delivery.

[0086] (Ninth Embodiment) The ninth embodiment will be described with reference to Figures 78 to 86. The ninth embodiment increases the user's flexibility in OTA update methods by adopting not only CDN8 but also smartphones and USB memory as distribution paths for update data, thereby supporting diversity in distribution paths. Smartphones and USB memory correspond to recording media. Hereafter, smartphones and USB memory will be used as examples of storage media, but SD cards, microSD cards, CompactFlash, etc. may also be used as storage media.

[0087] Next, the operation of the above-described configuration will be explained with reference to Figures 79 to 86. (9-1) Processing at OTA Center 2 (See Figures 79 to 82) OTA Center 2 generates a shared key for encrypting the update package (A091). OTA Center 2 encrypts the update package using the generated shared key in a specific encryption mode (A092). OTA Center 2 encrypts the shared key using an RSA public key (A093). OTA Center 2 stores the RSA-encrypted shared key in the campaign notification (A094). OTA Center 2 generates RP metadata including the shared key encryption method and delivery path (A095). OTA Center 2 encrypts the RP metadata using an RSA public key (A096). OTA Center 2 places the update package encrypted with the shared key and the RSA-encrypted RP metadata on the CDN8 (A097). OTA Center 2 sends the campaign notification containing the encrypted shared key to the vehicle-side system 3 targeted for reprogramming (A098).

[0088] (9-2) Processing of OTA Master 4 (See Figures 83 to 86) OTA Master 4 receives a campaign notification sent from OTA Center 2 and retrieves it. From this notification, OTA Master 4 obtains the encrypted symmetric key (B091). OTA Master 4 decrypts the encrypted symmetric key using its RSA private key to extract the symmetric key (B092). OTA Master 4 downloads and obtains the encrypted RP metadata from CDN 8 (B093). OTA Master 4 decrypts the encrypted RP metadata using its RSA private key to extract the RP metadata (B094). OTA Master 4 interprets the contents of the RP metadata to identify the symmetric key encryption method and delivery path (B095). OTA Master 4 obtains the encrypted update package via the identified delivery path (B096). In other words, if OTA Master 4 identifies a smartphone as the delivery path, it downloads the encrypted update package from CDN 8 via the smartphone using a batch storage method. If OTA Master 4 identifies a USB memory as the distribution path, it downloads the encrypted update package from CDN8 via the USB memory using a batch storage method. From this point onward, if CTR mode is adopted as the specific encryption mode, OTA Master 4 performs the processing from step B014 onward as described in the first embodiment, and if OFB mode is adopted as the specific encryption mode, it performs the processing from step B024 onward as described in the second embodiment.

[0089] As described above, the ninth embodiment provides the following effects and advantages. The update package is now obtained from CDN8 via a storage medium such as a smartphone or USB memory. This allows for diversity in the distribution paths of the update package, enabling the selection of a distribution path that is advantageous in terms of distribution cost and usability. This appropriately suppresses the distribution cost when OTA Master 4 downloads the update package from OTA Center 2, and improves the user experience value. In the above embodiment, OTA Master 4 interprets the contents of the RP metadata in step B095 to identify the symmetric key encryption method and distribution path, but if multiple distribution paths are described in the RP metadata, it may be possible to select any of the multiple distribution paths.

[0090] (Tenth embodiment) The tenth embodiment will be described with reference to Figures 87 to 98. In the tenth embodiment, multiple CDN vendors are dynamically selected as the destination for the update package to CDN8 according to the distribution method, the OTA target area (distribution area), and the size of the data to be distributed, thereby suppressing distribution costs. A comparison of CDN costs is shown in Figures 88 to 89. The price table is shown in Figures 90 to 93. Each CDN vendor has different price advantages depending on the distribution area (such as Japan or North America) and the size of the data to be distributed. For example, referring to Figure 90, when distributing a monthly data size of 100TB, CDN2 is the cheapest in Japan, but 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, the OTA target area, and the size of the data to be distributed.

[0091] As shown in Figure 94, 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, a campaign notification transmission unit 2f, and a CDN vendor selection unit 2j. The CDN vendor selection unit 2j selects a CDN vendor by referring to the CDN vendor management database.

[0092] Next, the operation of the above-described configuration will be explained with reference to Figures 95 to 98. (10-1) Processing at OTA Center 2 (See Figures 95 to 98) OTA Center 2 generates an AES key to encrypt the update package (A101). OTA Center 2 encrypts the update package in CTR mode using the generated AES key (A102). OTA Center 2 encrypts the AES key using an RSA public key (A103). OTA Center 2 stores the AES key encrypted with the RSA public key in the campaign notification (A104). OTA Center 2 identifies the delivery method (A105), identifies the OTA target area (A106), identifies the delivery data size (A107), and refers to the price table from the CDN vendor management database using the delivery method, OTA target area, and delivery data size as keys (A108). In this case, OTA Center 2 may also refer to the price table using at least one of the following as keys: delivery method such as storage method or streaming method, OTA target area such as Japan, North America, or EU (European Union), or delivery data size such as GB, TB, or PB. OTA Center 2 selects the CDN vendor with the lowest distribution cost for each area and places the update package encrypted with an AES key on the selected CDN 8 (corresponding to A109, CDN vendor selection procedure). Alternatively, OTA Center 2 may place the update package encrypted with an AES key on each CDN 8. OTA Center 2 sends the encrypted AES key and a campaign notification containing the data storage location and URI information of the update package so that it can access the selected CDN vendor to the vehicle system 3 to be reprogrammed (A110).

[0093] (10-2) Processing of OTA Master 4 The processing of the OTA master 4 is the same as the processing of the OTA master 4 described in the first embodiment (Figures 12 to 14).

[0094] As described above, the following effects can be obtained according to the tenth embodiment. By referring to the CDN vendor management database, the system selects the CDN8 with the most favorable delivery cost from among several CDN8s with different delivery costs, based on the delivery method, OTA target area, and delivery data size, and places the update package on the selected CDN8. This configuration allows for appropriate suppression of the delivery cost when OTA Master 4 downloads the update package from OTA Center 2. Furthermore, by encrypting the update package at OTA Center 2, in principle, there is no security issue even if the intermediate path is zero-trust. Therefore, there is no need to encrypt the update data on the edge side of CDN8, making it possible to reduce the processing load and security functions of CDN8. Even if data tampering occurs or CDN8 is subjected to a DDoS attack along the path between OTA Center 2 and OTA Master 4, the OTA system will not be affected, and it becomes possible to eliminate the need for intelligent security measures in the systems intervening in the path, such as web application firewalls, TLS communication, and multi-layered security support measures such as signed URLs that limit the target OTA Master 4 to be delivered to. This allows for a reduction in the running costs of the OTA system on a cost basis, and enables the suppression of delivery costs in any system configuration.

[0095] (11th embodiment) The 11th embodiment will be described with reference to Figures 99 to 108. The 11th embodiment employs Diffie-Hellman key exchange (hereinafter referred to as DHE) or elliptic curve Diffie-Hellman key exchange (hereinafter referred to as ECDHE) for key distribution between OTA Center 2 and OTA Master 4. In addition, OTA Center 2 encrypts the AES key based on different confidential information for each shared vehicle and distributes it to OTA Master 4, thereby enjoying the advantage of ensuring forward confidentiality of ECDHE, while distributing update packages applicable to each vehicle model or specific vehicle group applicable to CDN8.

[0096] As shown in Figure 100, both parties generate and exchange their respective public keys (A, B) from random numbers (= private keys: a, b), and then combine them with their own private keys to perform calculations and secretly share confidential information (S). Since the private key and public key pair (a / A, b / B) can be discarded after sharing the confidential information (S), and there is no need to store them in the HSM (Hardware Security Module) on either the OTA Center 2 or the OTA Master 4, the confidential information (S) can be shared very securely. This shared confidential information (S) can be used as a key for symmetric-key cryptography, etc., but because the original data is random numbers (a, b), each OTA Master 4 will have a different key.

[0097] Next, the operation of the above-described configuration will be explained with reference to Figures 101 to 108. (11-1) Processing at OTA Center 2 (See Figures 101 to 104) OTA Center 2 generates an AES key to encrypt the update package (A111). OTA Center 2 encrypts the update package in CTR mode using the generated AES key (A112). OTA Center 2 generates an ECDHE key pair from random numbers (A113). OTA Center 2 shares the secret key with OTA Master 4 using the ECDHE algorithm (A114, equivalent to the secret information sharing procedure). OTA Center 2 encrypts the AES key with the secret key (A115). OTA Center 2 stores the AES key encrypted with the secret key in the campaign notification (A116). OTA Center 2 places the update package encrypted with the AES key on CDN 8 (A117). OTA Center 2 sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A118, equivalent to the encryption key distribution procedure).

[0098] Step A114 is described below. When the vehicle's ignition is turned on and a predetermined period has elapsed since the last synchronization of vehicle configuration information, the OTA master 4 queries the ECU installed in the vehicle for the program version and collects vehicle configuration information. Alternatively, when the OTA master 4 receives a push notification regarding a campaign from the OTA center 2, it queries the ECU for the program version and collects vehicle configuration information. Once the OTA master 4 has collected the vehicle configuration information, it establishes TLS communication with the OTA center 2 and sends the vehicle configuration information to the OTA center 2. At this time, the OTA master 4 has collected the vehicle configuration information and generated an ECDHE key pair, and once TLS communication is established with the OTA center 2, it sends the public key of the OTA master 4 from the key pair to the OTA center 2. Note that the process by which the OTA master 4 collects vehicle configuration information also applies to other embodiments. The OTA center 2 obtains a private key using the ECDHE algorithm based on the public key of the OTA master 4 obtained from the OTA master 4 and the private key of the OTA center 2.

[0099] (11-2) Processing of OTA Master 4 (See Figures 105 to 108) OTA Master 4 generates an ECDHE key pair from random numbers (B111). OTA Master 4 shares a private key with OTA Center 2 using the ECDHE algorithm (B112, equivalent to the secret information sharing procedure). When OTA Master 4 receives a campaign notification sent from OTA Center 2, it obtains the campaign notification and retrieves the AES key from it (B113). OTA Master 4 decrypts the encrypted AES key using the private key to extract the AES key (B114). OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B115).

[0100] At this time, OTA Master 4 downloads and obtains the encrypted update package from CDN 8, and simultaneously encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B116). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN 8 (B117). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B118).

[0101] As described above, the following effects can be obtained according to the 11th embodiment. DHE or ECDHE is used for key distribution between OTA Center 2 and OTA Master 4. OTA Center 2 encrypts the AES key based on confidential information unique to each vehicle and distributes it to OTA Master 4. This configuration ensures the forward confidentiality of ECDHE while enabling efficient distribution of update data via CDN8.

[0102] (Modified version of the 11th embodiment) Modifications of the 11th embodiment will be described with reference to Figures 166 to 173. The 11th embodiment was described on the premise that a wireless communication device is installed in the vehicle and that the OTA master 4 can send and receive data with the OTA center 2 and CDN 8 via a wireless communication line. However, there are cases where a wireless communication device is not installed in the vehicle, or where the user does not prefer to use a wireless communication line. Modifications of the 11th embodiment will describe a situation in which the OTA master 4 does not send and receive data with the OTA center 2 and CDN 8 via a wireless communication line, but instead performs program updates using a storage medium such as an SD card.

[0103] The OTA Master 4 and OTA Center 2 use a storage medium for data transfer with the outside world. Data transfer between the OTA Master 4 and the storage medium is performed using a port for the storage medium installed in the vehicle. Ports installed in the vehicle include, for example, ports installed in the car navigation system, center display system, and other vehicle control devices.

[0104] Data transfer between OTA Center 2 and the storage medium is performed by connecting the storage medium to a personal computer (hereinafter referred to as PC). For example, by connecting the storage medium to a PC and accessing the OTA Center 2 or CDN8 website, data stored on the storage medium can be uploaded to OTA Center 2 by operating the PC, or data stored on OTA Center 2 can be downloaded to the storage medium by operating the PC. Note that a smartphone, tablet, etc., compatible with the storage medium can also be used instead of a PC. A PC, smartphone, tablet, etc., compatible with the storage medium is also referred to as an operating terminal.

[0105] Referring to Figures 166 to 169, the case where an SD card is used as the storage medium will be explained. In this case, the process is carried out in the following order: data transfer from OTA master 4 to SD card 11, data upload from SD card 11 to OTA center 2, data download from OTA center 2 to SD card 11, and data transfer from SD card 11 to OTA master 4.

[0106] Referring to Figure 166, the transfer of data from the OTA master 4 to the SD card 11 will be explained. The OTA master 4 obtains software version information, etc., from the target ECU 5 and transfers and saves this obtained software version information, etc., to the SD card 11 as vehicle configuration information. The OTA master 4 generates an ECDHE key pair from random numbers and transfers and saves the ECDHE public key to the SD card 11. 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.

[0107] Referring to Figure 167, the upload of data from the PC to which the SD card 11 is connected to the OTA center 2 will be explained. When the SD card 11 is connected to the PC, the PC reads the vehicle configuration information and the ECDHE public key of the OTA master 4 stored on the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2. The vehicle configuration information uploaded to the OTA center 2 is used by the PKG generation server 6 to determine whether or not there is a campaign. The ECDHE public key of the OTA master 4 uploaded to the OTA center 2 is shared as a private key by the distribution server 7 based on the ECDHE algorithm. In this case, the private key is different for each vehicle.

[0108] Referring to Figure 168, the data download from OTA Center 2 to SD card 11 is explained. This example shows a scenario with a campaign. OTA Center 2 downloads and saves the update package encrypted with an AES key to SD card 11. OTA Center 2 generates an ECDHE key pair from random numbers and downloads and saves the key to be shared with OTA Master 4 (OTA Center 2's ECDHE public key) to SD card 11. OTA Center 2 downloads and saves the campaign notification containing the encrypted AES key to SD card 11. SD card 11 stores the update package downloaded from OTA Center 2, OTA Center 2's ECDHE public key, and the encrypted AES key.

[0109] Referring to Figure 169, the transfer of data from SD card 11 to OTA master 4 is explained. OTA master 4 reads and obtains the encrypted update package, the ECDHE public key of OTA center 2, and the encrypted AES key stored on SD card 11.

[0110] Next, the operation of the above configuration will be explained with reference to Figures 170 to 174. (11-3) Processing of OTA Master 4 (See Figure 170) When the SD card 11 is connected to the vehicle-side system 3 and predetermined conditions are met, the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information, and acquires the configuration information such as software version information transmitted from the target ECU 5 as vehicle configuration information (B1111). Once the OTA master 4 has acquired the vehicle configuration information, it transfers and saves the acquired vehicle configuration information to the SD card 11 (B1112). The OTA master 4 generates an ECDHE key pair from random numbers (B1113). In this case, the key pair includes the ECDHE public key and ECDHE private key of the OTA master 4. The OTA master 4 transfers and saves the ECDHE public key of the OTA master 4 to the SD card 11 (B1114). Once the vehicle configuration information and the ECDHE public key of the OTA master 4 are saved on the SD card 11, the connection with the vehicle-side system 3 is disconnected, and the SD card 11 is connected to the PC.

[0111] (11-4) PC processing (see Figure 171) If the SD card 11 is connected, the PC reads the vehicle configuration information and the ECDHE public key of the OTA master 4 stored on the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2 (C1111). The PC waits for the OTA center 2 to receive a campaign notification and an encrypted update package containing the ECDHE public key and AES key of the OTA master 4, as well as a notification of no campaign (C1112, C1113). When the PC determines that it has received the campaign notification and an encrypted update package containing the ECDHE public key and AES key of the OTA master 4 from the OTA center 2 (C1112: YES), or when it determines that it has received a notification of no campaign (C1113: YES), it terminates the process.

[0112] (11-5) Processing at OTA Center 2 (See Figure 172) OTA Center 2 generates an AES key to encrypt the update package and encrypts the update package in CTR mode using the AES key. OTA Center 2 obtains the vehicle configuration information uploaded from the PC to which the SD card 11 is connected and the ECDHE public key of OTA Master 4 (A1111). OTA Center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1112). If OTA Center 2 determines that there is no campaign (A1112: NO), it sends a no-campaign notification to the PC (A1113) and terminates the process.

[0113] If OTA Center 2 determines that there is a campaign (A1112: YES), it generates an ECDHE key pair from random numbers (A1114). In this case, the key pair consists of OTA Center 2's ECDHE public key and ECDHE private key. OTA Center 2 downloads and saves its ECDHE public key to SD card 11 (A1115). OTA Center 2 generates an ECDHE shared key (private key) from OTA Center 2's ECDHE private key and OTA Master 4's ECDHE public key (A1116), and encrypts the AES key using the generated ECDHE shared key (private key) (A1117). 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 SD card 11 (A1118). OTA Center 2 downloads and saves the encrypted update package to SD card 11 (A1119).

[0114] (11-6) Processing of OTA Master 4 (See Figure 173) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 retrieves the ECDHE public key, campaign notification, and update package from the OTA center 2 (B1121). The OTA master 4 generates an ECDHE shared key (private key) from the OTA master 4's ECDHE private key and the OTA center 2's ECDHE public key (B1122). The OTA master 4 extracts the encrypted AES key from the campaign notification and decrypts it using the ECDHE shared key (private key) (B1123). The OTA master 4 encrypts the counter value by performing 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 performing an XOR operation (B1125). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package on the target ECU 5 (B1126).

[0115] With this configuration, it is possible to properly ensure the forward confidentiality of ECDHE without relying on the wireless communication function of the vehicle-side system 3, while also enabling efficient distribution of update data by CDN 8. Furthermore, by reducing the number of data transfers between OTA master 4 and SD card 11, and between OTA center 2 and SD card 11, convenience for the user can be enhanced.

[0116] (12th embodiment) The 12th embodiment will be described with reference to Figures 109 to 115. In the 12th embodiment, in ECDHE key sharing, the random number a generated by the OTA center 2 is a random number for each vehicle model (a random number according to a specific rule), and the random number b generated by the OTA master 4 is one of the following: a fixed value for each vehicle model, a count-up value, or the hash value of the software version of the OTA master 4, or a combination thereof. This makes the secret key shared in ECDHE common for each vehicle model, allowing the benefits of ensuring ECDHE's forward confidentiality to be enjoyed while omitting the key distribution process and delivering an encryption package applicable to each vehicle model or specific group of vehicles via CDN.

[0117] Next, the operation of the above-described configuration will be described with reference to FIGS. 110 to 115. (12-1) Processing of OTA Center 2 (see FIGS. 110 to 112) OTA Center 2 generates a key pair for ECDHE from a random number common to each vehicle model or each vehicle group (A121). OTA Center 2 shares a secret key with OTA Master 4 using the ECDHE algorithm (A122, corresponding to the secret information sharing procedure). In the present embodiment, the secret key shared with OTA Master 4 using the ECDHE algorithm is used as the AES key for encrypting the update package. Further, OTA Master 4 uses the secret key shared with OTA Center 2 as the AES key for decrypting the encrypted update package. OTA Center 2 generates an AES key for encrypting the update package (A123). OTA Center 2 encrypts the update package in CTR mode using the generated AES key (A124). OTA Center 2 places the update package encrypted with the AES key in CDN8 (A125). OTA Center 2 transmits a campaign notification storing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A126, corresponding to the encryption key distribution procedure).

[0118] (12-2) Processing of OTA Master 4 (see FIGS. 113 to 115) OTA Master 4 generates a key pair for ECDHE from a random number generated according to the specific rules described above (B121). OTA Center 2 shares a secret key with OTA Center 2 using the ECDHE algorithm (B122, corresponding to the secret information sharing procedure). OTA Master 4 downloads and acquires the encrypted update package from CDN8 (B123).

[0119] At this time, OTA Master 4 downloads and obtains the encrypted update package from CDN 8, and simultaneously encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B124). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN 8 (B125). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B126).

[0120] As described above, the following effects can be obtained according to the 12th embodiment. DHE or ECDHE is used for key distribution between OTA Center 2 and OTA Master 4, and the secret key shared via ECDHE is common to each vehicle model. This allows for proper forward confidentiality of ECDHE, simplifies the key distribution process compared to the 11th embodiment, and enables efficient distribution of update data via CDN8.

[0121] (Modified version of the 12th embodiment) A modified version of the 12th embodiment will be described with reference to Figures 174 to 181. In the modified version of the 12th embodiment, as with the modified version of the 11th embodiment, the OTA master 4 does not send and receive data with the OTA center 2 or CDN 8 via a wireless communication line, but instead performs program updates using a storage medium such as an SD card.

[0122] Referring to Figure 174, the transfer of data from the OTA master 4 to the SD card 11 will be explained. The OTA master 4 obtains software version information, etc., from the target ECU 5 and transfers and stores the obtained software version information, etc., as vehicle configuration information on the SD card 11. The OTA master 4 generates a common ECDHE key pair for each vehicle model using one of the following: a fixed value for each vehicle model, a count-up value, or the hash value of the software version of the OTA master 4, or a combination thereof. It then transfers and stores the key to be shared with the OTA center 2 (the ECDHE public key of the OTA master 4) on the SD card 11. One of the fixed value for each vehicle model, a count-up value, or the hash value of the software version of the OTA master 4, or a combination thereof, corresponds to a specific rule. 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.

[0123] Referring to Figure 175, the upload of data from the PC to which the SD card 11 is connected to the OTA Center 2 will be explained. When the SD card 11 is connected to the PC, the PC reads the vehicle configuration information and the ECDHE public key of the OTA Master 4 stored on the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA Master 4 to the OTA Center 2. The vehicle configuration information uploaded to the OTA Center 2 is used by the PKG generation server 6 to determine whether or not there is a campaign. In addition, the ECDHE public key of the OTA Master 4 uploaded to the OTA Center 2 is shared as a private key by the distribution server 7 based on the ECDHE algorithm. In this case, the private key is a private key common to each vehicle model.

[0124] Referring to Figure 176, the download of data from OTA Center 2 to SD card 11 will be explained. OTA Center 2 generates an ECDHE key pair from a random number common to each vehicle model or vehicle group, and downloads and saves the key to be shared with OTA Master 4 (OTA Center 2's ECDHE public key) to SD card 11. OTA Center 2 encrypts the update package using the private key shared via ECDHE as the AES key, and downloads and saves the encrypted update package to SD card 11. SD card 11 stores the ECDHE public key of OTA Center 2 and the update package downloaded from OTA Center 2.

[0125] Referring to Figure 177, the transfer of data from SD card 11 to OTA master 4 is explained. OTA master 4 reads and obtains the encrypted update package and the ECDHE public key of OTA center 2 stored on SD card 11. OTA master 4 shares a private key based on the ECDHE algorithm. OTA master 4 uses the private key that was shared via ECDHE as an AES key to decrypt the encrypted update package.

[0126] Next, the operation of the above-described configuration will be explained with reference to Figures 178 to 181. (12-3) Processing of OTA Master 4 (See Figure 178) When the SD card 11 is connected to the vehicle-side system 3 and predetermined conditions are met, the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information, and acquires the configuration information such as software version information transmitted from the target ECU 5 as vehicle configuration information (B1211). Once the OTA master 4 has acquired the vehicle configuration information, it transfers and stores the acquired vehicle configuration information on the SD card 11 (B1212). The OTA master 4 generates an ECDHE key pair from random numbers generated according to a specific rule (B1213). In this case, the key pair includes the ECDHE public key and ECDHE private key of the OTA master 4. The OTA master 4 transfers and stores the ECDHE public key of the OTA master 4 on the SD card 11 (B1214). The ECDHE key pair is a random number generated according to a specific rule, similar to the 12th embodiment, and is common to each vehicle model. Once the vehicle configuration information and the ECDHE public key of the OTA master 4 are stored on the SD card 11 in this manner, the connection with the vehicle-side system 3 is disconnected, and the SD card 11 is connected to the PC.

[0127] (12-4) PC processing (see Figure 179) If the SD card 11 is connected, the PC reads the vehicle configuration information and the ECDHE public key of the OTA master 4 stored on the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2 (C1211). The PC waits for the OTA center 2 to receive a campaign notification and an encrypted update package containing the ECDHE public key of the OTA master 4, as well as a notification of no campaign (C1212, C1213). When the PC determines that it has received a campaign notification and an encrypted update package containing the ECDHE public key of the OTA master 4 from the OTA center 2 (C1212: YES), or when it determines that it has received a notification of no campaign (C1213: YES), it terminates the process.

[0128] (12-5) Processing at OTA Center 2 (See Figure 180) OTA Center 2 obtains the vehicle configuration information and the ECDHE public key of OTA Master 4 uploaded from the PC to which SD card 11 is connected (A1211). OTA Center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1212). If OTA Center 2 determines that there is no campaign (A1212: NO), it sends a no-campaign notification to the PC (A1213) and terminates the process.

[0129] If OTA Center 2 determines that a campaign exists (A1212: YES), it generates an ECDHE key pair from a random number common to each vehicle model or vehicle group (A1214). In this case, the key pair consists of OTA Center 2's ECDHE public key and ECDHE private key. OTA Center 2 downloads and saves its ECDHE public key to SD card 11 (A1215). OTA Center 2 generates an ECDHE shared key (private key) from OTA Center 2's ECDHE private key and OTA Master 4's ECDHE public key (A1216), and encrypts the update package using the generated ECDHE shared key (private key) (A1217). OTA Center 2 downloads and saves the encrypted update package to SD card 11 (A1218).

[0130] (12-6) Processing of OTA Master 4 (See Figure 181) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 obtains the ECDHE public key and update package from the OTA center 2 from the SD card 11 (B1221). The OTA master 4 generates an ECDHE shared key (private key) from the OTA master 4's ECDHE private key and the OTA center 2's ECDHE public key (B1222). The OTA master 4 encrypts the counter value by performing AES block cipher 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 performing an XOR operation (B1224). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package on the target ECU 5 (B1225).

[0131] With this configuration, it is possible to appropriately ensure the forward confidentiality of ECDHE without relying on the wireless communication function of the vehicle-side system 3, simplify the key distribution process compared to the 11th embodiment, and appropriately realize the efficient distribution of update data by CDN8. Furthermore, by reducing the number of data transfers between OTA master 4 and SD card 11, and uploads and downloads between OTA center 2 and SD card 11, convenience for the user can be improved.

[0132] (13th embodiment) The 13th embodiment will be described with reference to Figures 116 to 124. The 13th embodiment makes the CTR mode more secure by modifying the counter value rather than simply applying the CTR mode. Specifically, the CTR mode is made more secure by embedding a nonce in the campaign notification that is first communicated between the OTA center 2 and the OTA master 4, and by incorporating the nonce into the counter value. The encryption process for embedding the CTR mode nonce is shown in Figure 117, and the decryption process for embedding the CTR mode nonce is shown in Figure 118.

[0133] Next, the operation of the above-described configuration will be explained with reference to Figures 119 to 124. (13-1) Processing at OTA Center 2 (See Figures 119 to 121) OTA Center 2 generates an AES key to encrypt the update package (A131). OTA Center 2 generates a random nonce (A132). OTA Center 2 encrypts the update package in CTR mode using the generated AES key and nonce (A133). OTA Center 2 encrypts the AES key using an RSA public key (A134). OTA Center 2 may encrypt the nonce using an RSA public key at the same time as encrypting the AES key. OTA Center 2 stores the AES key and nonce encrypted with the RSA public key in the campaign notification (A135). OTA Center 2 places the update package encrypted with the AES key on CDN8 (A136). OTA Center 2 sends the campaign notification containing the encrypted AES key and nonce to the vehicle-side system 3 to be reprogrammed (A137).

[0134] (13-2) Processing of OTA Master 4 (See Figures 122 to 124) OTA Master 4 receives the campaign notification sent from OTA Center 2 and obtains it. From the obtained campaign notification, OTA Master 4 retrieves the AES key and nonce (B131). OTA Master 4 decrypts the encrypted AES key using its RSA private key to extract the AES key (B132). OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B133). OTA Master 4 decrypts the encrypted update package downloaded from CDN 8 using the AES key and nonce (B134). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B135).

[0135] As described above, the following effects can be obtained according to the 13th embodiment. A nonce is inserted into the campaign notification that first communicates between the OTA center 2 and the OTA master 4, and the nonce is inserted into the counter value. By doing so, the security of the CTR mode can be enhanced by inserting the nonce into the counter value.

[0136] (Embodiment 14) Embodiment 14 will be described with reference to FIGS. 125 to 132. In Embodiment 14, regarding the key used for encryption, instead of using a common key for all vehicles to narrow the scope of influence when the key is compromised, by using a derived key individualized for each specific vehicle group unit, while maintaining the delivery cache efficiency of the CDN8, the loss at the time of key leakage is localized, and OTA delivery is made more secure. As shown in FIG. 126, for the same vehicle model and model year, the VIN numbers are divided into a plurality, and different AES individual keys are used for each division. For example, they are divided by VIN numbers AAA~CCC, VIN numbers DDD~KKK, VIN numbers SSS~ZZZ, and different AES individual keys are used. The individual key database includes, for example, an AES individual key delimited by an OEM code, a vehicle model, a model year, an AES master key, a seed value, and a VIN number.

[0137] Next, the operation of the above-described configuration will be described with reference to FIGS. 127 to 132. (14-1) Processing of the OTA center 2 (see FIGS. 127 to 129) OTA Center 2 generates an individual AES key for encrypting the update package from the AES master key and seed value (A141). The seed value can be a random number, a counter value, a timestamp, etc. OTA Center 2 encrypts the update package in CTR mode using one of the generated individual AES keys and a nonce (A142). OTA Center 2 encrypts the individual AES key using an RSA public key (A143). OTA Center 2 stores the AES key and nonce encrypted with the RSA public key in the campaign notification (A144). OTA Center 2 places the update package encrypted with one of the individual AES keys and a nonce on CDN8 (A145). OTA Center 2 sends the campaign notification containing the encrypted individual AES key and nonce to the vehicle-side system 3 to be reprogrammed (A146).

[0138] (14-2) Processing of OTA Master 4 (See Figures 130 to 132) OTA Master 4 receives the campaign notification sent from OTA Center 2 and obtains it. From the obtained campaign notification, OTA Master 4 retrieves the AES individual key and nonce (B141). OTA Master 4 decrypts the encrypted AES individual key using its RSA private key to extract the AES individual key (B142). OTA Master 4 downloads and obtains the encrypted update package from CDN 8 (B143). OTA Master 4 decrypts the encrypted update package downloaded from CDN 8 using the AES individual key and nonce (B144). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B145).

[0139] As described above, the following effects can be obtained according to the 14th embodiment. Instead of using a common key for encryption across all vehicles, the system employs a configuration that uses individualized derived keys for each specific group of vehicles. This allows for localization of losses in the event of a key leak while maintaining the delivery cache efficiency of CDN8. As a result, the security of OTA Master 4 when downloading update packages from OTA Center 2 is enhanced, enabling more secure OTA delivery.

[0140] (15th Embodiment) The 15th embodiment will be described with reference to Figures 133 to 137. In the 15th embodiment, key versions are assigned to enable OTA key updates in preparation for the worst-case scenario of private key leakage, and these are managed by the OTA Center 2. The key update key is also stored in the HSM area of ​​the OTA Master. The OTA Center 2 manages version information of the RSA public key used for encrypting AES keys and the RSA private key used for decryption. By managing version information, downgrades are prevented when updating the RSA private key and RSA public key. The OTA Center 2 and the OTA Master 4 are equipped with a key update key used when updating private keys. In the OTA Center 2, a new private key pair is generated when a private key is leaked or at periodic intervals, and a key update package is generated using the key update key. The key update package is then sent to the OTA Master 4 to realize the private key update.

[0141] Next, the operation of the above-described configuration will be explained with reference to Figures 134 to 137. (15-1) Processing at OTA Center 2 (See Figures 134 to 135) OTA Center 2 generates a new key pair consisting of a new RSA private key and a new RSA public key (A151). OTA Center 2 encrypts the generated new RSA private key in CTR mode using the key update key and performs MAC calculations to generate a key update package (A152). OTA Center 2 switches the old RSA public key to the new RSA public key (A153). OTA Center 2 sends the key update package to the vehicle-side system 3 to be reprogrammed (A154).

[0142] (15-2) Processing of OTA Master 4 (See Figures 136 to 137) OTA Master 4 obtains the key update package and decrypts the new RSA private key in CTR mode using the key update key and performs MAC verification (B151). OTA Master 4 switches the old RSA private key to the decrypted new RSA private key (B152).

[0143] As described above, the following effects can be obtained according to the 15th embodiment. The system is configured to generate a new private key pair when a private key is leaked or at regular intervals, generate a key update package using the key update key, and send the key update package to OTA Master 4. This enhances the security of OTA Master 4 when it downloads the update package from OTA Center 2 by updating the private key, thereby enabling more secure OTA delivery.

[0144] (16th Embodiment) The 16th embodiment will be described with reference to Figures 138 to 145. In the 16th embodiment, a digital signature is added to the ECDHE key exchange to counter man-in-the-middle attacks, thereby enabling secure key exchange between the OTA center 2 and the OTA master 4 for keys applicable to the encryption package. As shown in Figures 139 to 140, DHE is vulnerable to attacks from man-in-the-middle attackers, but these attacks are countered by adding a digital signature. A digital signature using the RSA or elliptic curve DSA cryptographic algorithm is used as the digital signature.

[0145] Next, the operation of the above configuration will be explained with reference to Figures 141 to 145. (16-1) Processing at OTA Center 2 (See Figures 141 to 143) OTA Center 2 generates an ECDHE key pair from random numbers created for each vehicle model or vehicle group (A161). OTA Center 2 digitally signs the ECDHE key with an RSA private key (A162). Although an RSA private key is used here, it is not limited to an RSA private key; any public-key cryptography scheme can be used as a substitute, for example, an ECDSA (Elliptic Curve Digital Signature Algorithm) private key. OTA Center 2 sends the digitally signed ECDHE public key to the vehicle-side system 3 to be reprogrammed (A163). OTA Center 2 shares the private key with OTA Master 4 using the ECDHE algorithm (A164). OTA Center 2 generates an AES key to encrypt the update package (A165). OTA Center 2 encrypts the update package in CTR mode using the generated AES key (A166). OTA Center 2 places the update package encrypted with the AES key on CDN8 (A167). OTA Center 2 sends a campaign notification containing an encrypted AES key to the vehicle system 3 to be reprogrammed (A168).

[0146] (16-2) Processing of OTA Master 4 (See Figures 144 to 145) OTA Master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B161). OTA Master 4 digitally verifies the ECDHE public key received from OTA Center 2 using an RSA public key (B162). Here, as with OTA Center 2, it is not limited to an RSA public key; any public-key cryptography scheme is acceptable, for example, an ECDSA public key. If the verification result is positive, OTA Master 4 shares the private key with OTA Center 2 using the ECDHE algorithm (B163). From here on, OTA Master 4 performs the processing from step B113 onwards as described in the 11th embodiment.

[0147] As described above, the following effects can be obtained according to the 16th embodiment. The ECDHE key sharing configuration now includes digital signatures. This allows for protection against attacks from attackers in the middle, enabling more secure OTA delivery.

[0148] (Modified version of the 16th embodiment) A modified version of the 16th embodiment will be described with reference to Figures 182 to 189. In the modified version of the 16th embodiment, as with the modified versions of the 11th and 12th embodiments, the OTA master 4 does not send or receive data with the OTA center 2 or CDN 8 via a wireless communication line, but instead performs program updates using a storage medium such as an SD card. The main difference between the modified version of the 16th embodiment and the modified version of the 12th embodiment is that the ECDHE public key of the OTA center 2 is digitally signed with a public-key cryptography key to counter attacks from attackers in the middle.

[0149] Figures 182 to 185 show, respectively, the transfer of data from the OTA master 4 to the SD card 11, the upload of data from the PC to which the SD card 11 is connected to the OTA center 2, the download of data from the OTA center 2 to the SD card 11, and the transfer of data from the SD card 11 to the OTA master 4. The main difference from the modified version of the 12th embodiment is that, as shown in Figure 184, the OTA center 2 digitally signs the key to be shared with the OTA master 4 (the ECDHE public key of the OTA center 2) with a public-key cryptography key, such as an RSA private key or an ECDSA private key. The OTA center 2 transfers and stores the signed ECDHE public key on the SD card 11. Also, as shown in Figure 185, 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.

[0150] Next, the operation of the above-described configuration will be explained with reference to Figures 186 to 189. (16-3) Processing of OTA Master 4 (See Figure 186) When the SD card 11 is connected to the vehicle system 3 and predetermined conditions are met, the OTA master 4 requests the target ECU 5 to transmit configuration information such as software version information, and acquires the configuration information such as software version information transmitted from the target ECU 5 as vehicle configuration information (B1611). Once the OTA master 4 has acquired the vehicle configuration information, it transfers and stores the acquired vehicle configuration information on the SD card 11 (B1612). The OTA master 4 generates an ECDHE key pair from random numbers generated according to a specific rule (B1613). In this case, the key pair includes the ECDHE public key and ECDHE private key of the OTA master 4. The OTA master 4 transfers and stores the ECDHE public key of the OTA master 4 on the SD card 11 (B1614). The ECDHE key pair is a random number generated according to a specific rule, similar to the 12th embodiment, and is common to each vehicle model. Once the vehicle configuration information and the ECDHE public key of the OTA master 4 are stored on the SD card 11 in this manner, the connection with the vehicle-side system 3 is disconnected, and the SD card 11 is connected to the PC.

[0151] (16-4) PC processing (see Figure 187) If the SD card 11 is connected, the PC reads the vehicle configuration information and the ECDHE public key of the OTA master 4 stored on the SD card 11, and uploads the read vehicle configuration information and the ECDHE public key of the OTA master 4 to the OTA center 2 (C1611). The PC waits for the OTA center 2 to receive a campaign notification and an encrypted update package containing the ECDHE public key of the OTA master 4, as well as a notification of no campaign (C1612, C1613). When the PC determines that it has received a campaign notification and an encrypted update package containing the ECDHE public key of the OTA master 4 from the OTA center 2 (C1612: YES), or when it determines that it has received a notification of no campaign (C1613: YES), it terminates the process.

[0152] (16-5) Processing at OTA Center 2 (See Figure 188) OTA Center 2 obtains the vehicle configuration information and the ECDHE public key of OTA Master 4 uploaded from the PC to which SD card 11 is connected (A1611). OTA Center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1612). If 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.

[0153] If OTA Center 2 determines that a campaign exists (A1612: YES), it generates an ECDHE key pair from a random number common to each vehicle model or vehicle group (A1614). In this case, the key pair consists of OTA Center 2's ECDHE public key and ECDHE private key. OTA Center 2 signs its ECDHE public key with its RSA private key (A1615), and downloads and saves the signed ECDHE public key to SD card 11 (A1616). OTA Center 2 generates an ECDHE symmetric key (private key) from OTA Center 2's ECDHE private key and OTA Master 4's ECDHE public key (A1617), and encrypts the update package using the generated ECDHE symmetric key (private key) (A1618). OTA Center 2 downloads and saves the encrypted update package to SD card 11 (A1619).

[0154] (16-6) Processing of OTA Master 4 (See Figure 189) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 retrieves the signed ECDHE public key and update package of the OTA center 2 from the SD card 11 (B1621). The OTA master 4 verifies the signed ECDHE public key of the OTA center 2 with an RSA public key (B1622). The OTA master 4 determines whether the verification result is normal or not (B1623), and if it determines that the verification result is abnormal (B1623:NO), it issues an error notification (B1624).

[0155] If OTA Master 4 determines that the verification result is normal (B1623: YES), it generates an ECDHE shared key (private key) from OTA Master 4's ECDHE private key and OTA Center 2's ECDHE public key (B1625). OTA Master 4 encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B1626). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package (B1627). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B1628).

[0156] This configuration allows for protection against attacks from attackers in the middle without relying on the wireless communication function of the vehicle-side system 3, thereby achieving more secure OTA delivery. Furthermore, by reducing the number of data transfers between the OTA master 4 and the SD card 11, and between the OTA center 2 and the SD card 11, user convenience can be enhanced.

[0157] (17th Embodiment) The 17th embodiment will be described with reference to Figures 146 to 151. The 10th embodiment is configured to select the CDN vendor with the lowest delivery cost from multiple CDN vendors for each area, while the 17th embodiment is configured to statically select a CDN vendor capable of reducing delivery costs from multiple CDN vendors. Specifically, the 10th embodiment encrypts the update package at OTA Center 2 and then minimizes the delivery cost according to the delivery method, OTA target area, and delivery data size, while the 17th embodiment does not encrypt the update package at OTA Center 2, protects the communication between CDN 8 and OTA Master 4 with TLS communication, and then minimizes the delivery cost according to the delivery method, OTA target area, and delivery data size.

[0158] Next, the operation of the above-described configuration will be explained with reference to Figures 147 to 151. (17-1) Processing at OTA Center 2 (See Figures 147 to 148) OTA Center 2 identifies the delivery method (A171), identifies the OTA target area (A172), identifies whether TLS is used as the communication protocol to the vehicle (A173), identifies the size of the delivery data (A174), and refers to a price table from the CDN vendor management database using the delivery method, OTA target area, communication protocol, and delivery data size as keys (A175). In this case, OTA Center 2 may refer to the price table using at least one of the delivery method, OTA target area, communication protocol, and delivery data size as keys. OTA Center 2 selects the CDN vendor with the lowest delivery cost for each area and places the update package on the selected CDN 8 (A176). OTA Center 2 sends a campaign notification to the vehicle-side system 3 that is to be reprogrammed (A177).

[0159] (17-2) Processing of OTA Master 4 (See Figures 149 to 151) OTA Master 4 receives the campaign notification when it is sent from OTA Center 2 (B171). OTA Master 4 establishes TLS communication with the CDN vendor listed in the campaign notification in order to obtain the update package (B172). Note that the campaign notification does not need to include CDN vendor information as long as it contains URI information. After establishing TLS communication, OTA Master 4 exchanges AES symmetric keys using the TLS communication protocol. Negotiations are made to select AES-CTR mode as the encryption mode. OTA Master 4 downloads and obtains the update package encrypted with the TLS AES symmetric key from CDN 8 based on the URI information (B173, corresponding to the update data acquisition procedure).

[0160] At this time, OTA Master 4 downloads and obtains the encrypted update package from CDN 8, and simultaneously encrypts the counter value by performing AES block cipher processing on the counter value using the AES key (B174). OTA Master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from CDN 8 (B175). OTA Master 4 transfers the decrypted update package to Target ECU 5 and installs the update package on Target ECU 5 (B176).

[0161] As described above, the following effects can be obtained according to the 17th embodiment. The update package is not encrypted at OTA Center 2, and the communication between CDN8 and OTA Master 4 is protected by TLS. The configuration minimizes the delivery cost depending on the delivery method, OTA target area, communication protocol, and delivery data size. This allows for appropriate suppression of the delivery cost when OTA Master 4 downloads the update package from OTA Center 2.

[0162] (18th embodiment) The 18th embodiment will be described with reference to Figures 152 to 165. The 18th embodiment selects the optimal CDN vendor by comprehensively considering not only the delivery cost but also the throughput and response delay time of the CDN vendor, and regularly checks the CDN vendor's price table and quality characteristics, keeping the CDN vendor management database up to date and always selecting the CDN vendor with the greatest competitive advantage in the market. The price tables are shown in Figures 153 to 160, and the quality information of each cloud service provider is shown in Figure 161. As shown in Figure 162, when comparing CDN vendor A and CDN vendor B, CDN vendor B is superior to CDN vendor A in terms of delivery cost, but CDN vendor A is superior to CDN vendor B in terms of throughput weighting and response delay time weighting. When considering not only delivery costs but also the throughput and response latency of the CDN vendor, we can conclude that CDN vendor A, which is superior when considering throughput, response latency, and other factors, should be selected rather than CDN vendor B, which is superior only in terms of delivery costs.

[0163] Next, the operation of the above-described configuration will be explained with reference to Figures 163 to 165. (18-1) Processing at OTA Center 2 (See Figures 163 to 165) OTA Center 2 identifies the delivery method (A181), identifies the OTA target area (A182), and refers to the price table from the CDN vendor management database using the delivery method and OTA target area as keys (A183). In this case, OTA Center 2 may refer to the price table using at least one of the delivery method and OTA target area as a key. OTA Center 2 identifies the quality characteristics of each CDN vendor from the CDN vendor management database (A184). Based on the delivery cost and quality characteristics of the CDN vendors for each area, 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, and places the update package encrypted with an AES key on the selected CDN 8 (A185). OTA Center 2 sends a campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A186).

[0164] OTA Center 2 automatically retrieves pricing tables from each CDN vendor's website and updates the CDN vendor management database (A187). OTA Center 2 measures the throughput and response delay time of each CDN vendor and updates the CDN vendor management database (A188). For example, distribution server 7 periodically visits each CDN vendor's website to download the latest pricing tables. Alternatively, distribution server 7 downloads the latest pricing tables by registering with the distribution service when a CDN vendor distributes website update information.

[0165] (18-2) Processing of OTA Master 4 The processing of the OTA master 4 is the same as the processing of the OTA master 4 described in the first embodiment (Figures 12 to 14).

[0166] As described above, the following effects can be obtained according to the 18th embodiment. In addition to delivery costs, we comprehensively consider factors such as the CDN vendor's throughput and response latency to select the optimal CDN vendor. Furthermore, we regularly check the CDN vendor's pricing table and quality characteristics, keep the CDN vendor management database up-to-date, and always select the CDN vendor with the greatest competitive advantage in the market. This allows us to appropriately control the delivery costs when OTA Master 4 downloads update packages from OTA Center 2.

[0167] Furthermore, CDN quality characteristics are not limited to throughput and response latency; content cache hit rate and past trouble records can also be considered, and these can be included in the CDN vendor management database. In addition, the addition and removal of CDN vendors connected to OTA Center 2 can be reviewed periodically, and connections can be made with CDN vendors that are competitive in the market.

[0168] (19th embodiment) The 19th embodiment will be described with reference to Figures 90 and 190 to 193. The 10th embodiment described above is configured to select the CDN vendor with the lowest delivery cost from among multiple CDN vendors for each area. The 19th embodiment will specifically describe the selection of CDN vendors. In the 19th embodiment, the CDN vendor with the lowest delivery cost is dynamically selected from among multiple CDN vendors as the destination for CDN8 of the update package, according to the delivery data size, the delivery area (OTA target area, sometimes also called a region), and the delivery method. The 19th embodiment will be described with reference to the price table exemplified in Figure 90 described above. The price table may be in a different format than that in Figure 90.

[0169] As shown in Figure 190, in the OTA Center 2, 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, which are necessary information for selecting a CDN vendor. The selection information includes information such as the data size of the target campaign, the number of vehicles to be delivered to the target campaign, the region, and the delivery method. The data storage unit 7b stores campaign information and also stores 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 that identifies the CDN vendor, or a URL that indicates the CDN vendor. The campaign notification generation unit 7c retrieves information from the data storage unit 7b and generates a campaign notification to be delivered to vehicles, etc.

[0170] The CDN distribution unit 7d has storage areas corresponding to each CDN vendor. For example, the storage areas include storage area A, storage area B, and storage area C. Each storage area of ​​the CDN distribution unit 7d is synchronized with the CDN server. That is, for example, when the CDN distribution unit 7d distributes data from CDN server A to the vehicle-side system 3, it places the data in storage area A and transfers it to CDN server A. When CDN server A receives the data from the CDN distribution unit 7d, it distributes the transferred data to the vehicle-side system 3. Each storage area of ​​the CDN distribution unit 7d may be referred to as the origin server of each CDN server.

[0171] Next, the operation of the above-described configuration will be explained with reference to Figures 191 to 193. The processing of the update package by OTA Center 2, including encryption, is the same as in the 10th embodiment or other embodiments. Furthermore, the processing of OTA Master 4 is the same as in the 1st embodiment or other embodiments. In the 19th embodiment, the selection of the CDN vendor will be mainly explained.

[0172] (19-1) Processing of campaign notification generation unit 7c (see Figure 191) When a campaign occurs, the campaign notification generation unit 7c obtains campaign information from an external source, such as an OEM server (A191). The campaign information includes information about the data size of the target campaign, the number of vehicles targeted for delivery of the campaign, the region, and the delivery method. The campaign notification generation unit 7c saves the obtained campaign information to the data storage unit 7b (A192). Saving the campaign information is sometimes referred to as placing the campaign information.

[0173] The campaign notification generation unit 7c notifies the CDN vendor selection unit 7a of the request to select a CDN vendor (A193) and waits to receive a selection notification from the CDN vendor selection unit 7a. When the campaign notification generation unit 7c receives a selection notification from the CDN vendor selection unit 7a (A194), it accesses the data storage unit 7b and obtains the identification information of the CDN vendor selected by the CDN vendor selection unit 7a (A195).

[0174] The campaign notification generation unit 7c generates a parameter file containing the URL of the selected CDN as a campaign notification based on the CDN vendor's identification information (A196). The campaign notification generation unit 7c then distributes the generated campaign notification to the vehicle-side system 3 (A197).

[0175] (19-2) Processing of CDN vendor selection unit 7a (see Figures 192 to 193) When the CDN vendor selection unit 7a receives the CDN vendor selection request notified by the campaign notification generation unit 7 (A1911), it accesses the data storage unit 7b, obtains the selection information (A1912), and proceeds to the first CDN selection process (A1913).

[0176] When the CDN vendor selection unit 7a starts the first CDN selection process, it calculates the distribution data size, which indicates the size of the data to be delivered from the CDN server to the vehicles to be updated (A1921). Specifically, the CDN vendor selection unit 7a calculates the distribution data size that is scheduled to be delivered from the CDN server by multiplying the data size of the target campaign by the number of vehicles to be delivered for that campaign.

[0177] The CDN vendor selection unit 7a repeats the following process for each CDN vendor (A1922~A1929). Based on the previously calculated delivery data size and region information, the CDN vendor selection unit 7a retrieves pricing information from the CDN vendor management DB (A1923). For example, in the case of a 30TB campaign targeting North America, the CDN vendor selection unit 7a retrieves pricing information for "~10TB" and "~40TB" in the "North America" ​​region. Pricing information may be retrieved for all data sizes.

[0178] The CDN vendor selection unit 7a calculates the delivery charge based on the size of the delivered data by referring to pricing information (A1924). The calculation of the delivery charge may differ for each CDN vendor and is determined by the CDN vendor's method of calculating the delivery charge. For example, when calculating the delivery charge for CDN1 using the price table in Figure 90, if the region is "North America" ​​and the delivered data size is 30TB, the price tables for "~10TB" and "~40TB" are referred to.

[0179] The CDN vendor selection unit 7a determines whether the CDN vendor under consideration charges based on the number of requests (A1925). If the CDN vendor selection unit 7a determines that the CDN vendor does not charge based on the number of requests (A1925: NO), it determines the delivery charge amount as the charge amount for the CDN vendor (A1928), finishes calculating the charge amount for that CDN vendor, and calculates the charge amount for the next CDN vendor.

[0180] If the CDN vendor selection unit 7a determines that the CDN vendor charges based on 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 storage-based, the number of requests is the number of vehicles targeted for delivery in the campaign. If the delivery method is streaming-based, the number of requests is calculated by dividing the data size of the target campaign by the chunk size during streaming and multiplying by the number of vehicles targeted for delivery in the campaign.

[0181] The CDN vendor selection unit 7a calculates the number of requests and then calculates the charge amount (sometimes referred to as the request charge amount) based on the calculated number of requests (A1927). The request charge amount is the product of the charge amount per request and the number of requests. The CDN vendor selection unit 7a determines the total amount obtained by adding the delivery charge amount and the request charge amount as the charge amount for the CDN vendor (A1928), and finishes calculating the charge amount for the CDN vendor under consideration, and then calculates the charge amount for the next CDN vendor.

[0182] The CDN vendor selection unit 7a calculates the charge amount for all CDN vendors, The CDN vendor with the lowest delivery cost, i.e., the CDN vendor with the lowest charge, is selected (A1930), and the first CDN selection process is terminated. When the CDN vendor selection unit 7a has completed the first CDN selection process, it stores the selection result, i.e., 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).

[0183] As described above, the 19th embodiment provides the following effects and advantages. The distribution server 7 refers to the CDN vendor management database and selects the CDN 8 with the most favorable distribution cost from among several CDNs 8 with different distribution costs, based on the distribution method, OTA target area, and distribution data size. The update package is then placed on the selected CDN 8. This allows the distribution cost when the OTA master 4 downloads the update package from the OTA center 2 to be appropriately suppressed.

[0184] (Modified version of the 19th embodiment) Modifications of the 19th embodiment will be described with reference to Figures 194 to 211. Here, the first to fifth modifications will be described.

[0185] (First modified example of the 19th embodiment) A first modification of the 19th embodiment will be described with reference to Figures 194 to 195. The first modification is a configuration in which the URL of the CDN server included in the campaign notification delivered to the vehicle-side system 3 is not changed by using a DNS (Domain Name System) server. In the 19th embodiment, a CDN vendor with the lowest delivery cost is selected for each campaign. The campaign notification includes the URL of the CDN server. Therefore, if the CDN vendor with the lowest delivery cost changes, the URL described in the campaign notification will change. The campaign notification generation unit 7c needs to access the data storage unit 7b to obtain CDN vendor information each time a campaign notification is generated.

[0186] In contrast, in the first modified example, the campaign notification generation unit 7c can always include the same URL in the campaign notification by updating the conversion information between the URL and IP address registered in the DNS using the DNS setting unit 7e. If the CDN vendor with the lowest delivery cost changes, the vehicle-side system 3 can access the selected CDN server by changing the information of the DNS server 12. In other words, in the 19th embodiment, each CDN server has a unique IP address and a unique URL. In contrast, in the first modified example, each CDN server has a unique IP address, but is characterized by having a common URL across CDN servers.

[0187] As shown in Figure 194, in the OTA Center 2, 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, and a DNS setting unit 7e. The following will mainly describe the differences from the 19th embodiment.

[0188] DNS server 12 is a server that provides a mechanism for translating domain names and IP addresses. Campaign notifications received by the vehicle-side system 3 include the URL of a CDN server to access in order to download data. When the vehicle-side system 3 receives a campaign notification, it queries DNS server 12 for the URL indicated in the received campaign notification. DNS server 12 either sends the IP address corresponding to the queried URL to the vehicle-side system 3, or forwards the connection to the address specified by the IP address.

[0189] The DNS configuration unit 7e stores the CDN vendor's identification information and IP address. When a CDN vendor is selected by the CDN vendor selection unit 7a, the DNS configuration unit 7e sends an IP address configuration request to the DNS server 12 and configures the registration information in DNS.

[0190] Next, the operation of the above configuration will be explained with reference to Figure 195. (19-3) Processing of CDN vendor selection unit 7a (see Figure 195) When the CDN vendor selection unit 7a finishes the first CDN selection process and saves the selection results to the data storage unit 7b (A1914), it causes the DNS setting unit 7e to send an IP address setting request to the DNS server 12, and the DNS setting unit 7e sets the registration information in DNS (A1931). As a result, the URL included in the campaign notification delivered to the vehicle-side system 3 will not change even if the CDN vendor changes. When the vehicle-side system 3 accesses the CDN server indicated by the URL, the DNS server 12 obtains an IP address query and sends the IP address of the selected CDN server to the vehicle-side system 3.

[0191] Furthermore, the DNS setting unit 7e may either obtain information from the DNS server 12 or save the previous setting information for the DNS server 12, and if the CDN server registered with the DNS server 12 is different from the CDN server selected by the CDN vendor selection unit 7a, it may send an IP address update request to the DNS server 12. When the campaign notification generation unit 7c obtains the selection notification from the CDN vendor selection unit 7a, it generates a campaign notification that includes a fixed URL.

[0192] With this configuration, in addition to obtaining the same effects as in the 19th embodiment, the CDN URL information included in the campaign notification can always be the same, thereby enhancing security.

[0193] (Second modified example of the 19th embodiment) A second modification of the 19th embodiment will be described with reference to Figures 196 to 201. Even if a CDN vendor is selected that minimizes the cost of delivering update packages, there is a risk that communication speed may be slow due to CDN server maintenance, problems, or concentrated access. The inventors of the present invention focused on selecting a CDN vendor based on delivery cost and delivery performance.

[0194] In the second modified example, when the vehicle-side system 3 queries the DNS server 12 to obtain the IP address corresponding to the URL shown in the campaign notification, the DNS server 12 checks the delivery status of the CDN server. If it determines that delivery is not possible, it returns the IP address of the CDN server with the next lowest delivery cost to the vehicle-side system 3.

[0195] As shown in Figure 196, in the OTA center 2, 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 setting unit 7e, and a performance measurement unit 7f. The DNS server 12 includes a CDN server verification unit 12a. Test files for measuring the performance of the CDN server are placed in the storage area of ​​the CDN distribution unit 7d. The performance measurement unit 7f sends a request for distribution of the test files to the CDN server, causes the CDN server to distribute the test files, and measures the time required for distribution of the test files as the distribution time. The distribution time is, for example, the time from the time when the distribution of the test files started to the time when the completion of receiving the test files was identified.

[0196] The CDN vendor management database includes a CDN server selection table, as shown in Figure 197. The selection table includes cost rankings determined by the CDN vendor selection unit 7a and delivery flags determined by the performance measurement unit 7f.

[0197] The performance measurement unit 7f calculates the response speed for each CDN server from the time required to deliver the test file, and inputs the judgment result based on the calculated response speed into the selection table. If the response speed is above a specified value, the performance measurement unit 7f sets the delivery flag of that CDN server to ON (TRUE), and if the response speed is below a specified value, it sets the delivery flag of that CDN server to OFF (FALSE).

[0198] When the CDN server verification unit 12a receives a query from the vehicle-side system 3 for the IP address corresponding to the URL, it determines whether the CDN server specified by the URL is available for delivery. If it determines that delivery is not possible, it returns the IP address of another CDN server.

[0199] Next, the operation of the above configuration will be explained with reference to Figures 198 to 201. (19-4) Processing of CDN vendor selection unit 7a (see Figures 198 to 199) In the first CDN selection process, the CDN vendor selection unit 7a calculates the charge amount for each CDN vendor (A1921-A1929) and then determines the cost ranking of the CDN vendors (A1951). Specifically, the CDN vendor selection unit 7a determines the CDN vendor with the lowest delivery cost as the first-ranked vendor, and the CDN vendor with the next lowest delivery cost as the second-ranked vendor. The CDN vendor selection unit 7a then saves the selection results to the data storage unit 7b (A1914) and stores the cost ranking in the selection table of the CDN vendor management DB (A1941).

[0200] (19-5) Processing of the performance measurement unit 7f (see Figure 200) The performance measurement unit 7f repeats the following processes for each CDN vendor (A1961~A1966). The performance measurement unit 7f executes the following processes at regular intervals while the distribution server 7 is running, or at any time at the discretion of the administrator of the distribution server 7.

[0201] The performance measurement unit 7f accesses the CDN server (A1962) and sends a request for the delivery of a test file to the CDN server. The performance measurement unit 7f calculates the response speed based on the time required to deliver the test file and determines whether the calculated response speed is equal to or greater than a specified value (A1963). Alternatively, the time required for delivery may be compared to a specified value without calculating the response speed, or the size of the delivered data per unit time may be compared to a specified value.

[0202] If the performance measurement unit 7f determines that the response speed is above a specified value (A1963:YES), it determines that the CDN server is available for distribution and sets the distribution flag to ON (A1964). If the performance measurement unit 7f determines that the calculated response speed is below a specified value (A1963:NO), it determines that the CDN server is not available for distribution and sets the distribution flag to OFF (A1965).

[0203] (19-6) Processing of CDN server verification unit 12a (see Figure 201) The campaign notification contains a URL to access in order to download the update data. The vehicle-side system 3 queries the DNS server 12 for the IP address to access in order to download the update package.

[0204] The CDN server verification unit 12a obtains an IP address query from the vehicle-side system 3 for the URL indicated in the campaign notification (A1971). The CDN server verification unit 12a queries the CDN vendor management DB of the distribution server 7 for the distribution status of the CDN server indicated in the campaign notification (A1972). In this case, the CDN server corresponds to the CDN vendor from which data is to be acquired, and the distribution status corresponds to the distribution flag. When the CDN server verification unit 12a obtains the distribution flag of the CDN vendor from which data is to be acquired from the distribution server, it determines whether the CDN vendor from which data is to be acquired is available or not (A1973). That is, the CDN server verification unit 12a determines whether the acquired distribution flag is on or off.

[0205] If the CDN server verification unit 12a determines that the delivery flag is on (A1973:YES), it either returns the IP address corresponding to that CDN vendor to the vehicle-side system 3, or forwards the connection with the vehicle-side system 3 to that IP address and switches to the CDN vendor corresponding to the campaign notification URL (A1974). If the CDN server verification unit 12a determines that the delivery flag is off (A1973:NO), it sets the CDN vendor with the next highest cost ranking as the next priority CDN vendor, sets the next priority CDN vendor as the CDN vendor from which data is to be acquired (A1975), and returns to step A1973.

[0206] This configuration allows for the selection of a properly functioning CDN server while minimizing delivery costs. The CDN server verification unit 12a may also access the CDN vendor management DB and request the transmission of the selection table at regular intervals. In this case, if an IP address query is obtained from the vehicle-side system 3, instead of accessing the CDN vendor management DB, the CDN server verification unit 12a may refer to the selection table it holds to determine whether the CDN vendor from which data is to be retrieved is available. Furthermore, in addition to minimizing delivery costs and selecting a properly functioning CDN server, this configuration reduces communication between the DNS server 12 and the delivery server 7.

[0207] (Third modified example of the 19th embodiment) A third modification of the 19th embodiment will be described with reference to Figures 202 to 205. In the third modification, the performance measurement unit 7f in the distribution server 7 measures and evaluates the performance of the CDN server based on log information from the vehicle-side system 3. The operation when the DNS server 12 obtains an IP address query for a URL from the vehicle-side system 3 is the same as in the second modification. In the third modification, as in the second modification, the CDN vendor management DB includes a selection table.

[0208] The vehicle-side system 3 includes a log transmission unit 3a. When the log transmission unit 3a finishes downloading the update data from the CDN server, it sends log information related to the download, including the download time, to the performance measurement unit 7f of the distribution server 7. In addition to the download time, the log information related to the download may also include information such as the identification information of the downloaded package, the data size, and the maximum throughput during the download.

[0209] When the performance measurement unit 7f receives log information related to downloads from the log transmission unit 3a, it calculates the throughput from the download time and inputs the judgment result based on the calculated throughput into the selection table. If the throughput is above a specified value, the performance measurement unit 7f sets the distribution flag of the CDN server to ON (TRUE), and if the throughput is below a specified value, it sets the distribution flag of the CDN server to OFF (FALSE).

[0210] Next, the operation of the above configuration will be explained with reference to Figures 203 to 205. (19-8) Processing of log transmission unit 3a (see Figure 203) When the log transmission unit 3a finishes downloading the update package from the CDN server (A1981), it sends log information about the download, including the download time, to the distribution server 7 (A1982).

[0211] (19-9) Processing of the performance determination unit 7f (see Figure 204) When the performance determination unit 7f receives log information related to downloads from the log transmission unit 3a (A1991), it calculates the throughput from the download time (A1992) and determines whether the calculated throughput is equal to or greater than a specified value (A1993).

[0212] If the performance measurement unit 7f determines that the calculated throughput is above a specified value (A1993:YES), it determines that the CDN server is available for distribution and sets the distribution flag to ON (A1994). If the performance measurement unit 7f determines that the calculated throughput is below a specified value (A1993:NO), it determines that the CDN server is not available for distribution and sets the distribution flag to OFF (A1995).

[0213] (19-10) Processing of the performance determination unit 7f (see Figure 205) The performance determination unit 7f periodically performs the recovery process for CDN servers whose distribution flags have been turned off. The performance measurement unit 7f notifies the CDN vendor management DB of a request for information on CDN servers whose distribution flags are set to off, identifies the CDN servers whose distribution flags are set to off (A19101), and repeats the following processes for each CDN vendor (A19102~A19107). The performance measurement unit 7f executes the following processes at regular intervals or at any time at the discretion of the administrator of the distribution server 7 while the distribution server 7 is running.

[0214] The performance measurement unit 7f notifies the CDN server of a request to deliver a test file, calculates the throughput from the download time of the file delivered from the CDN server (A19103), and determines whether the calculated throughput is equal to or greater than a specified value (A19104).

[0215] If 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). If the performance measurement unit 7f determines that the calculated throughput is less than the specified value (A19104:NO), it maintains the distribution flag as off (A19106). The performance measurement unit 7f may also turn on the distribution flag, which is set to off in the CDN vendor management DB, when the distribution server system starts up or at predetermined intervals.

[0216] This configuration, unlike the second variation which sends a test file delivery request to the CDN server to determine the CDN server's response, eliminates the need to send a test file delivery request to the CDN server, thereby reducing the load and cost on the communication network. Furthermore, by providing a function in the vehicle-side system 3 to measure the download speed of the update package, if it determines that the throughput is below a specified value, the connection may be changed to a different CDN server.

[0217] In addition to the URL of the CDN server that is initially connected to when campaign notifications are delivered from delivery server 7, the URL of a backup CDN server that is connected to in case the throughput of this CDN server is low may also be included. The backup CDN server may be, for example, the CDN server with the next lowest delivery cost, or a pre-determined backup CDN server. If multiple CDN servers are specified as backup CDN servers, information indicating the connection order may also be added.

[0218] When the vehicle-side system 3 begins downloading the update package, it measures the throughput and checks whether it is above the specified value. If the vehicle-side system 3 determines that it is not above the specified value in throughput, it queries the DNS server 12 for the IP address of the backup CDN server URL shown in the campaign notification and changes the connection from the original CDN server to the new CDN server. Since identification information is attached to each packet of the delivered data, the update package can be downloaded continuously even if the CDN server is changed in the middle of the download.

[0219] (Fourth modified example of the 19th embodiment) A fourth modification of the 19th embodiment will be described with reference to Figures 206 to 207. In the fourth modification, multiple CDN vendors are selected by the CDN vendor selection unit 7a, and the campaign notification generation unit 7c generates multiple campaign notifications for each CDN vendor. When distributing the campaign notifications to the vehicle-side system 3, a round-robin method is used to specify different CDN servers.

[0220] (19-11) Processing of campaign notification generation unit 7c (see Figure 206) When the campaign notification generation unit 7c obtains information on CDN vendors (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 a single campaign. The campaign notification generation unit 7c distributes the campaign notifications so that the CDN servers change in a round-robin manner (A19112). For example, if two CDN servers, CDN11 and CDN12, are selected, the campaign notification generation unit 7c distributes a campaign notification containing the URL of CDN11 to the first vehicle, a campaign notification containing the URL of CDN12 to the next vehicle, and a campaign notification containing the URL of CDN11 to the next vehicle.

[0221] (19-12) Processing of CDN vendor selection unit 7a (see Figure 207) In the 19th embodiment, the CDN vendor selection unit 7a selects the CDN vendor with the lowest delivery cost, but in the fourth modified example, it selects multiple CDN vendors in order of lowest delivery cost (A19121).

[0222] This configuration allows for reduced delivery costs from CDN servers while preventing concentrated access to specific CDN servers, thereby preventing a decrease in throughput.

[0223] (Fifth variation of the 19th embodiment) A fifth modification of the 19th embodiment will be described with reference to Figures 208 to 211. The fourth modification selects multiple CDN vendors to reduce delivery costs, generates multiple campaign notifications with different CDN server information, and delivers the campaign notifications to the vehicle-side system 3 in a round-robin manner to change the CDN server. In contrast, the fifth modification selects multiple CDN vendors to reduce delivery costs, generates one campaign notification, and delivers it to the vehicle-side system 3. When the DNS server 12 obtains a query from the vehicle-side system 3 for the IP address corresponding to the URL shown in the campaign notification, it changes the CDN server that responds to the vehicle-side system 3 for each vehicle-side system 3. In other words, the DNS server 12 selects the CDN server in a round-robin manner.

[0224] As shown in Figure 208, the DNS server 12 includes a switching unit 12b. When the switching unit 12b receives an IP address query from the vehicle-side system 3, it sequentially changes the IP address it answers to the vehicle-side system 3 using a round-robin method. The distribution server includes a DNS setting unit 7e. In the fifth modified example, the DNS setting unit 7e sends the round-robin record shown in Figure 209 to the DNS server 12.

[0225] (19-13) Processing of CDN vendor selection unit 7a (see Figure 210) The CDN vendor selection unit 7a selects multiple CDN vendors in order of lowest delivery cost, similar to the fourth modified example (A19121), and sets up a round-robin record (A19131).

[0226] (19-14) Processing of the switching unit 12b (see Figure 211) When DNS server 12 receives an IP address query from vehicle-side system 3 (A19141), it refers to the round-robin record (A19142) and sends the IP address corresponding to the listed CDN server to vehicle-side system 3 (A19143). DNS server 12 repeats the above process each time it receives an IP address query from vehicle-side system 3, and when it receives an IP address query from another vehicle-side system 3, it refers to the round-robin record and sends the IP address corresponding to a different CDN server to vehicle-side system 3 than the previous one. In other words, DNS server 12 sends the IP addresses of CDN servers to vehicle-side system 3 in sequence according to the round-robin method.

[0227] This configuration allows for reduced delivery costs from CDN servers while preventing concentrated access to specific CDN servers, thereby preventing a decrease in throughput.

[0228] (20th embodiment) The 20th embodiment will be described with reference to Figures 212 to 224. The 20th embodiment suppresses delivery costs by dynamically selecting multiple CDN vendors as destinations for the update package on CDN8, according to the delivery method, the OTA target area (delivery area), and the size of the delivered data, when information can be obtained for multiple campaigns over a predetermined period. The predetermined period is, for example, the following month.

[0229] In the aforementioned 19th embodiment, a CDN vendor with the lowest delivery cost is selected for a single campaign. However, it is also conceivable that campaigns may be registered from the OEM server for multiple campaigns scheduled to start delivery in a predetermined period, for example, in the following month. In such cases, information regarding the data size of each campaign, the number of vehicles to be delivered, the OTA target area, and the delivery method is obtained in advance for multiple campaigns, and a different CDN vendor may be the one with the lowest delivery cost than the one selected for each campaign as in the 19th embodiment.

[0230] As shown in Figure 212, the OTA Center 2 comprises 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 predicted values ​​indicating how much of the campaign will be distributed to the vehicle-side system 3 within a predetermined period. Even if a campaign is registered with the OTA Center 2 and a campaign notification is distributed to the vehicle-side system 3, not all vehicles will immediately apply the campaign and download the update package from the CDN server. The progress information management unit 7g stores predicted values ​​to more accurately predict the size of the data to be distributed from the CDN server to the vehicle-side system 3. In this embodiment, the predetermined period is described as one month, but other periods may also be used.

[0231] Referring to Figure 213, the calculation method in the 20th embodiment will be explained. In the 20th embodiment, the CDN vendor charges are calculated using three calculation methods, as described later. In the first calculation method, the CDN vendor that minimizes the delivery cost for each campaign is selected. In this case, it is possible to select a different CDN vendor for each campaign. Figure 213 illustrates the case where CDN1 is selected for campaign 1, CDN2 is selected for campaign 2, and CDN3 is selected for campaign 3.

[0232] The second calculation method calculates the total delivery data size for all campaigns and selects the CDN vendor with the lowest delivery cost based on the calculated total delivery data size for all campaigns. In this case, the same CDN vendor is selected for all campaigns. Figure 213 shows an example where CDN1 is selected for campaigns 1-3. The third calculation method calculates the total delivery data size for each campaign by delivery method and selects the CDN vendor with the lowest delivery cost based on the calculated total delivery data size for each campaign by delivery method. CDN vendors are selected for both streaming and storage delivery methods. Figure 213 shows an example where campaign 1 and campaigns 2 and 3 use different delivery methods, with CDN1 selected for campaign 1 and CDN2 selected for campaigns 2 and 3.

[0233] Next, the operation of the above configuration will be explained with reference to Figures 214 to 224. (20-1) Processing of campaign notification generation unit 7c (see Figure 214) The campaign notification generation unit 7c obtains campaign information scheduled for distribution from an external source, such as an OEM server, from the OEM server (A201). The campaign information scheduled for distribution includes information on the distribution start date, the data size of the target campaign, the number of vehicles targeted for distribution in the target campaign, the region, and the distribution method. The campaign notification generation unit 7c stores the obtained campaign information in the data storage unit 7b (A202).

[0234] The campaign notification generation unit 7c notifies the CDN vendor selection unit 7a of the request to select a CDN vendor (A203) and waits to receive a selection notification from the CDN vendor selection unit 7a. When the campaign notification generation unit 7c receives a selection notification from the CDN vendor selection unit 7a (A204), it accesses the data storage unit 7b and obtains the identification information of the CDN vendor selected by the CDN vendor selection unit 7a (A205).

[0235] The campaign notification generation unit 7c generates a parameter file containing the URL of the selected CDN based on the CDN vendor's identification information as a campaign notification to be distributed (A206). The campaign notification generation unit 7c distributes the generated campaign notification to the vehicle-side system 3 (A207).

[0236] (20-2) Processing of CDN vendor selection unit 7a (see Figures 215 to 221) When the CDN vendor selection unit 7a receives the CDN vendor selection request notified by the campaign notification generation unit 7 (A2011), it accesses the data storage unit 7b, Retrieve selection information (A2012). In this case, the selection information includes data size, number of target vehicles, region, delivery method, and start date for each campaign for all target campaigns scheduled for distribution.

[0237] The CDN vendor selection unit 7a obtains the delivery forecast value from the progress information management unit 7g (A2013). The CDN vendor selection unit 7a calculates the delivery data size for each campaign (A2014). Specifically, the CDN vendor selection unit 7a multiplies the campaign data size by the number of vehicles targeted for delivery in the campaign and the delivery forecast value, and then multiplies that by a correction value according to the delivery period. In some campaigns, the delivery period may be short, such as when the delivery start date is set for the end of the next month, so the correction value according to the delivery period is used for adjustment. For example, if the delivery start date is delayed and the delivery period is only 10 days, then a correction value of 0.3 or similar is set because 10 days out of 30 days is the period during which delivery is possible.

[0238] The CDN vendor selection unit 7a moves on to the second CDN selection process (A2015). Once the second CDN selection process begins, the CDN vendor selection unit 7a sequentially moves on to the calculation of the charge amount using the first calculation method, the calculation of the charge amount using the second calculation method, and the calculation of the charge amount using the third calculation method (A2021~A2023).

[0239] The CDN vendor selection unit 7a, in the process of calculating the charge amount using the first calculation method, selects the CDN vendor that minimizes the delivery cost for each campaign. Once the CDN vendor selection unit 7a starts the process of calculating the charge amount using the first calculation method, it repeats the following process for each campaign (A2031~A2041), and then repeats it for each CDN vendor (A2032~A2039). The CDN vendor selection unit 7a obtains pricing information from the CDN vendor management DB based on the delivery data size and region information (A2033). The CDN vendor selection unit 7a refers to the pricing information based on the delivery data size and calculates the delivery charge amount (A2034).

[0240] The CDN vendor selection unit 7a, similar to the 19th embodiment, determines whether the CDN vendor under consideration charges based on the number of requests and determines the CDN vendor's charge amount (A2035~A2038). The CDN vendor selection unit 7a repeatedly calculates the delivery charge amount for each CDN vendor and for each campaign. Once the CDN vendor selection unit 7a has calculated the charge amounts for all CDN vendors for a single campaign, it selects the CDN vendor with the lowest delivery cost for that campaign (A2040).

[0241] Once the CDN vendor selection unit 7a has finished calculating the delivery charges and selecting CDN vendors for all campaigns, it totals the delivery charges for all campaigns to calculate the total amount (A2042), finishes the calculation of charges using the first calculation method, and moves on to the calculation of charges using the second calculation method.

[0242] In the calculation of the charge amount using the second calculation method, the CDN vendor selection unit 7a selects one CDN vendor based on the total delivery data size of all campaigns scheduled for delivery. When the CDN vendor selection unit 7a starts the calculation of the charge amount using the second calculation method, it sums up the delivery data size of each campaign to calculate the total delivery data size (A2051), and then repeats the following process for each CDN vendor (A2052~A2059). The CDN vendor selection unit 7a retrieves pricing information from the CDN vendor management DB based on the total delivery data size and region information (A2053). The CDN vendor selection unit 7a refers to the pricing information based on the total delivery data size and calculates the delivery charge amount (A2054).

[0243] The CDN vendor selection unit 7a, similar to the 19th embodiment, determines whether the CDN vendor under consideration is a CDN vendor that charges based on the number of requests, and determines the charge amount for the CDN vendor (A2055~A2058). The CDN vendor selection unit 7a repeatedly calculates the delivery charge amount for each CDN vendor. The CDN vendor selection unit 7a selects the CDN vendor with the lowest delivery cost (A2060). It then sums up the delivery charges for all campaigns scheduled to be delivered, calculates the total amount (A2061), terminates the charge amount calculation process using the second calculation method, and moves on to the charge amount calculation process using the third calculation method.

[0244] In the calculation of the charge amount using the third calculation method, the CDN vendor selection unit 7a selects a CDN vendor after grouping campaigns by delivery method. When the CDN vendor selection unit 7a starts the calculation of the charge amount using the third calculation method, it determines whether all the delivery methods of the campaigns to be delivered are the same (A2071). If the CDN vendor selection unit 7a determines that all the delivery methods of the campaigns to be delivered are the same, that is, all the campaigns to be delivered are either streaming or storage (A2071: YES), the calculation of the charge amount using the third calculation method becomes the same as the calculation of the charge amount using the second calculation method described above, and the calculation of the charge amount using the third calculation method is terminated.

[0245] If the CDN vendor selection unit 7a determines that the delivery methods of the campaigns to be delivered are not all the same, that is, that the campaigns to be delivered will be a mix of streaming and storage methods (A2071: NO), it will group the campaigns according to their delivery method (A2072), proceed to the streaming method billing calculation process for the streaming method group (A2073), and proceed to the storage method billing calculation process for the storage method group (A2074).

[0246] When the CDN vendor selection unit 7a starts the billing calculation process for the streaming method, it calculates the total size of the delivery data for each campaign delivered by the streaming method (A2081), and then repeats the process for each CDN vendor (A2082~A2089). The CDN vendor selection unit 7a retrieves pricing information from the CDN vendor management DB based on the total size of the delivery data and the region information (A2083). The CDN vendor selection unit 7a refers to the pricing information based on the total size of the delivery data and calculates the delivery charge (A2084).

[0247] The CDN vendor selection unit 7a, similar to the 19th embodiment, determines whether the CDN vendor under consideration charges based on the number of requests and determines the CDN vendor's charge amount (A2085~A2088). The CDN vendor selection unit 7a repeatedly calculates the delivery charge amount for each CDN vendor. The CDN vendor selection unit 7a selects the CDN vendor with the lowest delivery cost using the streaming method (A2090) and terminates the calculation process for the streaming method charge amount.

[0248] Meanwhile, when the CDN vendor selection unit 7a starts the billing calculation process for the storage method, it calculates the total size of the delivery data for each campaign delivered using the storage method (A2091), and repeats the subsequent processing for each CDN vendor (A2092~A2099). The CDN vendor selection unit 7a obtains pricing information from the CDN vendor management DB based on the total size of the delivery data and the region information (A2093). The CDN vendor selection unit 7a refers to the pricing information based on the total size of the delivery data and calculates the delivery billing amount (A2094).

[0249] The CDN vendor selection unit 7a, similar to the 19th embodiment, determines whether the CDN vendor under consideration is a CDN vendor that charges based on the number of requests, and determines the charge amount for the CDN vendor (A2095~A2098). The CDN vendor selection unit 7a repeatedly calculates the delivery charge amount for each CDN vendor. The CDN vendor selection unit 7a selects the CDN vendor with the lowest delivery cost using the storage method (A20100), and terminates the calculation process for the charge amount using the storage method.

[0250] After completing the calculation of the charge amount using the first calculation method, the calculation of the charge amount using the second calculation method, and the calculation of the charge amount using the third calculation method, the CDN vendor selection unit 7a determines the calculation method that minimizes the delivery cost (A2024), selects a CDN vendor for each campaign (A2025), and completes the second CDN selection process. After completing the second CDN selection process, the CDN vendor selection unit 7a stores the selection result, i.e., identification information that identifies the selected CDN vendor, in the data storage unit 7b (A2016). Here, the CDN vendor selection unit 7a stores identification information that identifies the CDN vendor for the campaign scheduled for delivery in the data storage unit 7b. The CDN vendor selection unit 7a notifies the campaign notification generation unit 7c of the selection (A2017).

[0251] (20-3) Processing by the progress information management unit 7g (see Figure 222) The progress information management unit 7g stores a predicted value indicating how many campaigns will be delivered to the vehicle-side system 3 within a predetermined period. This predicted value is expected to be updated according to the actual delivery status transmitted from the OEM server.

[0252] The progress information management unit 7g obtains the delivery status from the OEM server (A20111). The progress information management unit 7g determines whether the difference between the delivery status and the stored predicted value is greater than or equal to a predetermined value (A20112). If the progress information management unit 7g determines that the difference between the delivery status and the stored predicted value is not greater than or equal to a predetermined value (A20112: NO), it terminates the process.

[0253] If the progress information management unit 7g determines that the difference between the distribution status and the stored predicted value is greater than or equal to a predetermined value (A20112:YES), it updates the stored predicted value (A20113) and notifies the CDN vendor selection unit 7a of the update (A20114). The progress information management unit 7g may have one predicted value common to all campaigns, or it may have different predicted values ​​for each campaign, each vehicle to be updated, or each type of campaign.

[0254] (20-4) Processing of CDN vendor selection unit 7a (see Figure 223) When the CDN vendor selection unit 7a receives updated forecast values ​​notified by the progress information management unit 7g (A20121), it obtains selection information (A20122), obtains delivery forecast values ​​from the progress information management unit 7g (A20123), and calculates the delivery data size for each campaign (A20124). In this case, when the CDN vendor selection unit 7a calculates the delivery data size, it uses a corrected value that takes into account the number of delivery days.

[0255] The CDN vendor selection unit 7a proceeds to the second CDN selection process (A20125), and upon completion of the second CDN selection process, determines whether or not there has been a change in the CDN vendor (A20126). If the CDN vendor selection unit 7a determines that there has been no change in the CDN vendor (A20126: NO), it terminates the process. If there has been a change in the CDN vendor, it updates the selection result in the data storage unit 7b. If the CDN vendor selection unit 7a determines that there has been a change in the CDN vendor (A20126: YES), it updates the selection result (A20127) and sends a CDN change notification to the campaign notification generation unit 7c (A20128). The CDN vendor selection unit 7a may also check at predetermined intervals whether or not the predicted values ​​stored in the progress information management unit 7g have changed.

[0256] (20-5) Processing of campaign notification generation unit 7c (see Figure 224) When the campaign notification generation unit 7c receives a CDN change notification from the CDN vendor selection unit 7a (A20131), it accesses the data storage unit 7b to obtain information on the updated CDN vendor (A20132), and then regenerates the campaign notification to be delivered based on the obtained updated CDN vendor information (A20133).

[0257] As described above, the 20th embodiment provides the following effects and advantages. By referring to the CDN vendor management database, the system selects the CDN8 with the most favorable delivery cost from among several CDN8s with different delivery costs, based on the delivery method, OTA target area, and delivery data size, and then places the update package on the selected CDN8. This allows for appropriate suppression of the delivery cost when OTA Master 4 downloads the update package from OTA Center 2.

[0258] (Other embodiments) In the embodiments described above, embodiments that are not explicitly described as either a streaming method or a storage method can be applied to either a streaming method or a storage method.

[0259] In some of the embodiments described above, it is stated that the campaign notification is sent from OTA Center 2 to OTA Master 4 after TLS communication has been established. However, in all embodiments, the campaign notification may be sent from OTA Center 2 to OTA Master 4 after TLS communication has been established. Establishing TLS communication can enhance security. Alternatively, the campaign notification may be sent from OTA Center 2 to OTA Master 4 without TLS communication being established.

[0260] 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 to enable data communication. The CGW is also called a central ECU. The bus may be, for example, Ethernet or CAN® bus.

[0261] Some or all of the functions of OTA Master 4 may be implemented in CGW. For example, DCM may communicate data with external parties such as CDN8 or OTA Center 2, and all of the functions of OTA Master 4 may be implemented in CGW. In this case, DCM will transfer all data received via wireless communication with external parties to CGW. Alternatively, in addition to communicating data with external parties, DCM may also function as a downloader for OTA Master 4. Downloader functions include, for example, generating vehicle configuration information, metadata verification, package verification, and campaign information verification. Alternatively, the functions of OTA Master 4 may be implemented in DCM. In this case, functions other than OTA Master 4 will be implemented in CGW. Alternatively, DCM and CGW may be integrated.

[0262] The configuration may involve the CGW possessing some or all of the DCM's functions, or the DCM possessing some or all of the CGW's functions. In other words, the functional division between the DCM and CGW in the OTA Master 4 may be configured in any way. The OTA Master 4 may consist of two ECUs, the DCM and the CGW, or it may consist of one integrated ECU that possesses the functions of both the DCM and the CGW.

[0263] This disclosure is described in accordance with embodiments, but it is understood that this disclosure is not limited to such embodiments or structures. This disclosure also includes various modifications and variations within the scope of equivalents. In addition, various combinations and forms, as well as other combinations and forms that include only one, more, or fewer of those elements, fall within the scope and concept of this disclosure.

[0264] The means and functions provided by each device can be provided by software recorded in a physical memory device and the computer that executes it, by software alone, by hardware alone, or by a combination thereof. For example, if the control unit is provided by an electronic circuit which is hardware, it can be provided by a digital circuit including a large number of logic circuits, or by an analog circuit.

[0265] The control unit and its method described herein may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the control unit and its method described herein may be implemented by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Furthermore, the control unit and its method described herein may be implemented by one or more dedicated computers configured 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. The computer program may also be stored as instructions executed by the computer on a computer-readable non-transitional tangible recording medium.

Claims

1. A data communication system comprising a central device (2) that distributes update data to a master device, and a master device (4) that installs the update data downloaded from the central device into an electronic control unit to be reprogrammed, The aforementioned center device and master device share random secret information by employing the Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm for key distribution. The aforementioned central device is a data communication system that encrypts an encryption key for encrypting update data based on its shared secret information, stores the encrypted encryption key in a campaign notification, places the update data encrypted with the encryption key on a Content Delivery Network (CDN), and transmits the campaign notification containing the encrypted encryption key to the master device of the vehicle system which includes the electronic control unit to be reprogrammed.

2. The data communication system according to claim 1, wherein the central device is provided with a digital signature using public key cryptography for the key transmitted to the central device in DHE or ECDHE key sharing.

3. The data communication system according to claim 2, wherein the central device uses a digital signature that employs an RSA or elliptic curve DSA encryption algorithm as the digital signature.

4. A central device (2) that distributes update data to the master device, A central device that uses the Diffie-Hellman key sharing (DHE) or elliptic curve Diffie-Hellman key sharing (ECDHE) algorithm for key distribution to share random confidential information with the master device, encrypts an encryption key for encrypting update data based on the shared confidential information, stores the encrypted encryption key in a campaign notification, places the update data encrypted with the encryption key on a Content Delivery Network (CDN), and transmits the campaign notification containing the encrypted encryption key to the master device of the vehicle system including the electronic control unit to be reprogrammed.

5. The central device (2) that distributes the update data to the master device, A secret information sharing procedure that uses a Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm for key distribution and shares random secret information with the master device, A secret information sharing program that causes the execution of an encryption key distribution procedure which involves encrypting an encryption key for encrypting update data based on the shared secret information, storing the encrypted encryption key in a campaign notification, placing the update data encrypted with the encryption key in a Content Delivery Network (CDN), and transmitting the campaign notification containing the encrypted encryption key to the master device of the vehicle system which includes the electronic control unit to be reprogrammed.

6. A data communication system comprising: a central device (2) that distributes update data to a storage medium; the storage medium; and a master device (4) that installs the update data read from the storage medium into an electronic control device to be reprogrammed, The aforementioned center device and master device employ the Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm. The center device uses a first random number as a secret key to be used in the DHE or ECDHE algorithm, shares secret information with the master device via the storage medium, uses the shared secret information as an encryption key, encrypts the update data based on the encryption key, places the update data encrypted with the encryption key on the Content Delivery Network (CDN), stores the encrypted encryption key in the campaign notification, and transmits the campaign notification containing the encrypted encryption key to the master device of the vehicle system including the electronic control unit to be reprogrammed. A data communication system comprising: the master device sharing secret information with the center device via the storage medium using a second random number as a secret key for the DHE or ECDHE algorithm; obtaining an encryption key from campaign notifications obtained from the center device; decrypting the encrypted encryption key using the secret information to extract the encryption key; downloading and obtaining encrypted update data from a CDN and decrypting it; transferring the decrypted update data to the electronic control unit to be reprogrammed; and installing the update data into the electronic control unit.

7. The data communication system according to claim 6, wherein the central device encrypts the update data with an encryption key, encrypts the encryption key based on the shared secret information, and distributes the encrypted encryption key to the master device.

8. The data communication system according to claim 6, wherein the central device encrypts the update data using the shared secret information as an encryption key.

9. The data communication system according to claim 6, wherein the first random number and the second random number are each random random numbers.

10. The first random number is a common random number for each vehicle model or vehicle group. The data communication system according to claim 6, wherein the second random number is a random number that follows a specific rule.

11. The master device stores the key of the master device based on the algorithm in the storage medium. The central device receives the key of the master device stored from the storage medium, The center device stores the key of the center device based on the algorithm in the storage medium. The data communication system according to claim 6, wherein the master device receives the stored key of the center device from the storage medium.

12. The data communication system according to claim 6, wherein the master device shares confidential information by the algorithm via the storage medium without wireless communication with the center device.

Images