Data communication system, center device, master device, and secret information sharing program

Abstract

To appropriately achieve the efficient distribution of update data by a CDN while appropriately ensuring forward secrecy.SOLUTION: A center device and a master device adopt Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm. The center device shares secret information with the master device using a common random number for each vehicle model or vehicle fleet, as a secret key used for the DHE or ECDHE algorithm, uses the shared secret information as an encryption key to encrypt update data based on the encryption key, and places the encrypted update data encrypted with the encryption key on a CDN. The master device shares the secret information with the center device using a random number according to specific rules, as a secret key used for the DHE or ECDHE algorithm, downloads the encrypted update data from the CDN, decrypts it using the encryption key, and transfers the decrypted update data to an electronic control device that is to be re-programmed.SELECTED DRAWING: Figure 109

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 technology]

[0003] In recent years, with the diversification of vehicle control, such as driving assistance functions and autonomous driving functions, the scale of application programs installed in electronic control units (hereinafter referred to as ECUs (Electronic Control Units)) for vehicle control, diagnosis, etc. is increasing. Furthermore, with version upgrades for functional improvements, etc., there are also increasing opportunities to reprogram ECU application programs. Reprogramming is sometimes referred to as program update. Meanwhile, with the advancement of communication networks, connected car technology is also becoming widespread. In light of this, for example, Patent Document 1 discloses a technology in which an update package containing packaged update data is distributed from a center device to a master device in the vehicle using OTA (Over The Air) technology. The master device is a device that oversees the reprogramming of ECU application programs. The update data distributed from the center device to the master device includes application programs and data for, for example, autonomous driving, advanced driver-assistance systems (ADAS), multimedia, etc. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2020-276424 Summary of the Invention [Problem to be solved by the invention]

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

[0006] However, in both DHE and ECDHE, the seed of the shared key is generated from random numbers generated by both the center device and the master device, and the encryption key that can be shared is a random key value for each vehicle. Therefore, if the update package is encrypted using that encryption key, the encrypted update package will be different for each vehicle, and the same update package will not be available for groups divided by vehicle model or specific vehicle fleet, for example. As a result, it is not possible to efficiently distribute update packages via a content delivery network (hereinafter referred to as CDN).

[0007] The present disclosure aims to appropriately realize efficient distribution of update data by a CDN while appropriately ensuring forward secrecy. [Means for solving the problem]

[0008] According to one aspect of the present disclosure, a system includes a center device that distributes update data to a master device, and a master device that installs the update data downloaded from the center device in an electronic control device to be reprogrammed. The center device and the master device employ a Diffie-Hellman key exchange (DHE) or an elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm. The center device shares secret information with the master device using a random number common to each vehicle model or each vehicle group as a secret key used in the DHE or ECDHE algorithm, encrypts update data based on the shared secret information as an encryption key, and places the encrypted update data on a content delivery network (CDN). The master device shares the secret information with the center device using a random number according to specific rules as a secret key used in the DHE or ECDHE algorithm, downloads the encrypted update data from the CDN, decrypts it using the encryption key, transfers the decrypted update data to the electronic control device to be reprogrammed, and installs the update data on the electronic control device.

[0009] The center device and master device employ the DHE or ECDHE algorithm. The center device shares secret information with the master device using a common random number for each vehicle model or vehicle fleet as a secret key for the DHE or ECDHE algorithm. The shared secret information is used as an encryption key to encrypt update data based on the encryption key, and the encrypted update data is placed on a content delivery network (CDN). The master device shares secret information with the center device using a random number according to specific rules as a secret key for the DHE or ECDHE algorithm. The encrypted update data is downloaded from the CDN, decrypted using the encryption key, and then transmitted to the electronic control device to be reprogrammed, where it is installed. By employing the DHE or ECDHE algorithm and sharing secret information between the center device and master device, efficient delivery of update data via the CDN can be achieved while ensuring appropriate forward secrecy. [Brief explanation of the drawings]

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

[0011] Hereinafter, several embodiments will be described with reference to the drawings. Note that in subsequent embodiments, descriptions of contents that overlap with the preceding embodiments may be omitted.

[0012] (First embodiment) The first embodiment will be described with reference to Fig. 1 to Fig. 14. As shown in Fig. 1, a data communication system 1 includes an OTA center 2 and a vehicle-side system 3 mounted on a vehicle, and is configured so that the OTA center 2 and the vehicle-side system 3 can communicate with each other via data. The OTA center 2 corresponds to a center device. The OTA center 2 and the vehicle-side system 3 have a one-to-many relationship, and the OTA center 2 can communicate with an unspecified number of vehicle-side systems 3.

[0013] The vehicle-side system 3 includes an OTA master 4 and a target ECU 5. The OTA master 4 corresponds to a master device. The OTA master 4 and the target ECU 5 are connected to an in-vehicle network such as a Controller Area Network (CAN) (registered trademark) and are connected to each other so as to be able to communicate data via the in-vehicle network. The in-vehicle network may be a Local Interconnect Network (LIN), FlexRay (registered trademark), CAN FD (CAN Flexible Data rate) (registered trademark), Ethernet (registered trademark), or the like. The target ECU 5 is an ECU to which an application program is to be reprogrammed, and may be, for example, an ECU that controls an autonomous driving system, an ECU that controls an ADAS system, or an ECU that controls a multimedia system. 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.

[0014] The OTA center 2 includes a package generation server 6 and a distribution server 7. The package generation server 6 has the function of packaging update data to generate an update package. The update package is, for example, a zip file in which multiple files containing update data are compressed and stored. The distribution server 7 has the function of distributing the update package generated by the package generation server 6 to the vehicle-side system 3.

[0015] When a request to reprogram an ECU application program occurs, for example, due to a version upgrade resulting from functional improvements, the OTA center 2 distributes a campaign notification to the vehicle system 3 and the user's mobile information terminal, such as a smartphone. The OTA center 2 places the update package in a content delivery network (hereinafter referred to as CDN) 8 and distributes the update package to the OTA master 4 via the CDN 8, provided that the user has given consent for the download. Alternatively, if the update package has already been placed in the CDN 8, the OTA center 2 distributes the update package from the CDN 8 to the OTA master 4, provided that the user has given consent for the download.

[0016] When the OTA master 4 downloads the update package from the OTA center 2, it transfers the update package to the target ECU 5 and installs the update package in the target ECU 5, provided that the user has given consent for installation. A company that provides the CDN 8 as a service is called a CDN vendor. The OTA master 4 also obtains the update package by accessing the CDN server of the CDN 8.

[0017] 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, a counter mode (hereinafter abbreviated as CTR mode), which is a representative streaming encryption, is adopted as the encryption mode rather than the cipher block chaining mode (hereinafter abbreviated as CBC mode) of a general block encryption. In this embodiment, the OTA center 2 encrypts the update package in CTR mode using an AES key. Also, the vehicle-side system 3 encrypts the update package in CTR mode using an AES key. Note that the OTA center 2 is provided with an RSA (Rivest-Shamir-Adleman cryptosystem) public key for each vehicle. An RSA private key is written to the OTA master 4 during the vehicle manufacturing stage.

[0018] As shown in FIG. 2, the OTA center 2 includes encryption-related functional blocks, such as a shared key generation unit 2a, an update package encryption unit 2b, a shared key encryption unit 2c, a shared key storage unit 2d, an encrypted package deployment unit 2e, and a campaign notification transmission unit 2f. The update package encryption unit 2b corresponds to the update data encryption unit. The encrypted package deployment unit 2e corresponds to the encrypted data deployment unit. Each of the units 2a to 2f is realized by cooperation between 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 stored in the ROM, including an encryption program, an update data deployment program, and a secret information sharing program.

[0019] The common key generation unit 2a generates an AES key as a common key for encrypting the update package. The package encryption unit 2b encrypts the update package in CTR mode using the generated AES key. The package encryption unit 2b encrypts the counter value by performing AES block encryption 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 multiple encrypted fragments, and generates an update package encrypted using the AES key. The counter value is, for example, an eight-digit number, and is incremented by "1" for each AES block.

[0020] The common key encryption unit 2c encrypts the AES key using the RSA public key. The common key storage unit 2d stores the AES key encrypted using the RSA public key in the campaign notification. The encrypted package placement unit 2e places the update package encrypted using the AES key on the CDN 8. The campaign notification sending unit 2f sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed. The campaign notification sending unit 2f may also deliver the campaign notification to a mobile information terminal such as a smartphone owned by the user.

[0021] The OTA master 4 includes the following functional blocks related to decryption: a shared key acquisition unit 4a, a shared key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, and an installation processing unit 4f. The encrypted package acquisition unit 4c corresponds to the encrypted data acquisition unit. The encrypted package decryption unit 4e corresponds to the encrypted data decryption unit. Each of the units 4a to 4f is realized by cooperation of hardware and software of a microcomputer having a CPU, RAM, ROM, I / O, etc. The CPU realizes the functions of the OTA master 4 by executing various programs stored in the ROM, including a decryption program, an update data acquisition program, and a secret information sharing program.

[0022] When the OTA master 4 receives a campaign notification sent from the OTA center 2, the shared key acquisition unit 4a acquires the encrypted AES key from the acquired campaign notification. The shared key decryption unit 4b decrypts the encrypted AES key using the RSA private key to extract the AES key. The encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8. At this time, the block cipher processing unit 4d performs AES block cipher processing on the counter value using the AES key to encrypt the counter value, while the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8. The encrypted package decryption unit 4e decrypts the encrypted counter value by performing an exclusive OR (hereinafter, referred to as XOR) operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8. The installation processing unit 4f transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5.

[0023] 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 performed" and "parallel encryption processing cannot be performed," while the advantages of CTR mode include "preparation for encryption and decryption can be performed, allowing for faster processing" and "parallel encryption and decryption processing is possible." In other words, the advantage of adopting CTR mode as the encryption mode is that it contributes to improving throughput, as shown in Figure 6, when compared to using the CBC mode of a general block cipher, it can improve throughput by approximately 40%.

[0024] As shown in Figure 7, in the decryption process in CBC mode, the input is ciphertext, so the decryption process cannot start until the update package, which is ciphertext, is received. In contrast, as shown in Figure 8, in the decryption process in CTR mode, the input is a counter value, so the decryption process can start before the update package, which is ciphertext, is received. In addition, since there is no mutual dependency, multiple cryptographic operations can be executed simultaneously in parallel.

[0025] Next, the operation of the above-described configuration will be described with reference to FIGS. (1-1) Processing at OTA Center 2 (see Figures 9 to 11) The OTA center 2 generates an AES key for encrypting the update package (A011, corresponding to the common key generation procedure). The OTA center 2 encrypts the update package in CTR mode using the generated AES key (A012, corresponding to the update data encryption procedure). The OTA center 2 encrypts the AES key using the RSA public key (A013, corresponding to the common key encryption procedure). The OTA center 2 stores the AES key encrypted using the RSA public key in the campaign notification (A014, corresponding to the common key storage procedure). The OTA center 2 places the update package encrypted using the AES key on the CDN 8 (A015, corresponding to the encrypted data placement procedure). Placing the update package on the CDN 8 means placing the update package on the origin server of the CDN 8. The OTA center 2 sends the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A016, corresponding to the campaign notification transmission procedure).

[0026] (1-2) OTA Master 4 Processing (See Figures 12 to 14) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B011, corresponding to the common key acquisition procedure). The OTA master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B012, corresponding to the common key decryption procedure). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B013, corresponding to the encrypted data acquisition procedure).

[0027] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs AES block cipher processing on the counter value using the AES key to encrypt the counter value (B014, corresponding to the block cipher processing step). The OTA master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 (B015, corresponding to the encrypted data decryption step). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B016, corresponding to the installation processing step). Note that by encrypting and decrypting the difference program in the update package in CTR mode instead of CBC mode, the throughput of the decryption process in the target ECU 5 can also be improved by approximately 40%.

[0028] As described above, according to the first embodiment, the following advantageous effects can be obtained. The system is configured to use CTR mode as the encryption and decryption method for the update package. Unlike the conventional method that used CBC mode, the adoption of CTR mode allows for preparations to be made before encryption and decryption, and enables encryption and decryption to be processed in parallel. This allows the OTA master 4 to enjoy the benefits of CTR mode when downloading the update package from the OTA center 2, and appropriately increases throughput.

[0029] (Second embodiment) The second embodiment will be described with reference to Fig. 15 to Fig. 26. The first embodiment is configured to employ the CTR mode as the encryption mode, but the second embodiment employs the output feedback mode (hereinafter referred to as OFB mode (Output-Feedback mode)) as the encryption mode.

[0030] In this case, the package encryption unit 2b encrypts the update package in OFB mode using the generated AES key. While the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8, the block cipher processing unit 4d executes IV (Initialization Vector) value-based AES stream encryption processing using the AES key to encrypt the IV value. The IV value is an initialization vector value, and represents, for example, a randomly generated bit string. The encrypted package decryption unit 4e performs an XOR operation on the encrypted IV value and the encrypted update package downloaded from the CDN 8 to decrypt it.

[0031] 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 performed" and "parallel encryption processing cannot be performed," while the advantage of OFB mode is that "preparation for encryption and decryption can be performed, allowing for faster processing." In other words, as an advantage of using OFB mode as the encryption mode, it can improve throughput by approximately 25% compared to using the CBC mode of a general block cipher, as shown in Figure 18.

[0032] As shown in Figure 19, in the decryption process in CTR mode, the input is a counter value, so the decryption process can start before the update package, which is ciphertext, is received. Furthermore, since there is no mutual dependency, multiple cryptographic operations can be executed simultaneously in parallel. In contrast, as shown in Figure 20, in the decryption process in OFB mode, there is a mutual dependency, so multiple cryptographic operations cannot be executed simultaneously in parallel. However, the process of decrypting by XORing the encrypted IV value and the encrypted update package can be executed in parallel. Therefore, in the decryption process in OFB mode, the throughput cannot be improved as much as in the decryption process in CTR mode described in the first embodiment, but it can be improved compared to when CBC mode is used.

[0033] Next, the operation of the above-described configuration will be described with reference to FIGS. (2-1) Processing at OTA Center 2 (see Figures 21 to 23) The OTA center 2 generates an AES key for encrypting the update package (A021, corresponding to the common key generation procedure). The OTA center 2 encrypts the update package in OFB mode using the generated AES key (A022, corresponding to the update data encryption procedure). The OTA center 2 encrypts the AES key using an RSA public key (A023, corresponding to the common key encryption procedure). The OTA center 2 stores the AES key encrypted using the RSA public key in the campaign notification (A024, corresponding to the common key storage procedure). The OTA center 2 places the update package encrypted using the AES key in the CDN 8 (A025, corresponding to the encrypted data placement procedure). The OTA center 2 transmits the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A026, corresponding to the campaign notification transmission procedure).

[0034] (2-2) OTA Master 4 Processing (See Figures 24 to 26) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B021, corresponding to the common key acquisition procedure). The OTA master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B022, corresponding to the common key decryption procedure). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B023, corresponding to the encrypted data acquisition procedure).

[0035] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs an IV-based AES stream encryption process using an AES key to encrypt the IV value (B024, corresponding to the block encryption process step). The OTA master 4 performs an XOR operation on the encrypted IV value and the encrypted update package downloaded from the CDN 8 to decrypt it (B025, corresponding to the encrypted data decryption process step). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B026, corresponding to the installation process step). Note that by encrypting and decrypting the difference program in the update package in OFB mode instead of CBC mode, the throughput of the decryption process in the target ECU 5 can also be improved by approximately 25%.

[0036] As described above, according to the second embodiment, the following advantageous effects can be obtained. The OFB mode is used as the encryption and decryption method for the update package. Unlike the conventional method that used CBC mode, the OFB mode allows for preparations to be made before encryption and decryption. This allows the OTA master 4 to enjoy the benefits of the OFB mode when downloading the update package from the OTA center 2, and appropriately increases throughput.

[0037] (Third embodiment) The third embodiment will be described with reference to FIGS. 27 to 33. In the third embodiment, the Hypertext Transfer Protocol (hereinafter referred to as HTTP) is used as the communication protocol between the CDN 8 and the OTA master 4. A range request is sent to the CDN 8, and the update package is downloaded in a streaming manner. This reduces delivery costs compared to when Hypertext Transfer Protocol Secure (hereinafter referred to as HTTPS) is used. Some CDN vendors charge different delivery fees for the CDN 8 depending on whether HTTP or HTTPS is used as the communication protocol to the CDN 8. When HTTPS is used, the CDN 8 must 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 the CDN 8's CPU. Therefore, the delivery fee for HTTPS is approximately 30% higher than that for HTTP. For this reason, using HTTP to download the update package reduces delivery costs. In the third embodiment, HTTPS is not used when distributing an update package from the CDN 8 to the vehicle-side system 3.

[0038] In this case, the campaign notification sending unit 2f establishes TLS communication between the OTA center 2 and the OTA master 4, and then transmits the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed. After TLS communication is established, the campaign notification sent from the OTA center 2 is received by the OTA master 4, and the common key obtaining unit 4a obtains the campaign notification and obtains the AES key from the obtained campaign notification. The encrypted package obtaining unit 4c sends a range request to the CDN 8 to specify the data range to be downloaded, and obtains the encrypted update package by streaming download from the CDN 8. The installation processing unit 4f transfers the decrypted update package to the target ECU 5 by streaming, and installs the update package in the target ECU 5.

[0039] In this embodiment, the OTA master 4 acquires the encrypted update package from the CDN 8 by streaming, but the encrypted update package may also be acquired by storage from the CDN 8. In the streaming method, header information is included during communication, so using HTTP can further reduce distribution costs.

[0040] Next, the operation of the above-described configuration will be described with reference to FIGS. (3-1) Processing at OTA Center 2 (see Figures 28 to 30) The OTA center 2 generates an AES key for encrypting the update package (A031). The OTA center 2 encrypts the update package in CTR mode using the generated AES key (A032). The OTA center 2 encrypts the AES key using an RSA public key (A033). The OTA center 2 stores the AES key encrypted using the RSA public key in the campaign notification (A034). The OTA center 2 places the update package encrypted using the AES key in the CDN 8 (A035). The OTA center 2 establishes TLS communication between the OTA center 4 and the OTA master 4, and then transmits the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A036).

[0041] (3-2) OTA Master 4 Processing (See Figures 31 to 33) After TLS communication is established, the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, and then acquires the AES key from the acquired campaign notification (B031). The OTA master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B032). The OTA master 4 sends a range request to the CDN 8 to specify the data range to be downloaded, and acquires the encrypted update package by downloading it from the CDN 8 using a streaming method (B033). In other words, by specifying the data range to be downloaded, the OTA master 4 acquires the update package by downloading it from the CDN 8 using a divided streaming method.

[0042] At this time, while the encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption 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 the CDN 8 (B035). The OTA master 4 transfers the decrypted update package to the target ECU 5 by streaming and installs the update package in the target ECU 5 (B036).

[0043] As described above, according to the third embodiment, the following advantageous effects can be obtained. HTTP is used as the communication protocol between the CDN 8 and the OTA master 4, and the OTA master 4 sends a range request to the CDN 8, causing the update package to be downloaded by streaming from the CDN 8. This makes it possible to appropriately reduce the delivery costs when the OTA master 4 downloads the update package from the OTA center 2, compared to the conventional method in which HTTPS was used as the communication protocol.

[0044] (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 an update package by performing calculations of all key streams in advance in the background before obtaining download consent from the user.

[0045] In this case, as shown in FIG. 35, the OTA master 4 includes a key stream calculation unit 4g in addition to a common key acquisition unit 4a, a common key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, and an installation processing unit 4f. The key stream calculation unit 4g calculates all key streams in advance in the background before obtaining download consent from the user. The encrypted package acquisition unit 4c downloads and acquires the encrypted update package from the CDN 8, provided that download consent has been obtained from the user. The encrypted package decryption unit 4e decrypts the calculated key stream with the encrypted update package downloaded from the CDN 8 by performing an XOR operation.

[0046] Next, the operation of the above-described configuration will be described with reference to FIGS. (4-1) Processing at OTA Center 2 The processing of the OTA center 2 is similar to the processing of the OTA center 2 described in the first embodiment (FIGS. 9 to 11).

[0047] (4-2) OTA Master 4 Processing (See Figures 36 to 38) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B041). The OTA master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B042). The OTA master 4 performs calculations of all key streams in advance in the background before obtaining download consent from the user (B043). Each key stream is assigned identification information that indicates the order in which they will be applied to the encrypted update package.

[0048] The OTA master 4 distributes the campaign notification 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). The OTA master 4, on the condition that the user consents to the download, downloads and acquires the encrypted update package from the CDN 8 (B045). The OTA master 4 decrypts the encrypted update package downloaded from the CDN 8 by performing an XOR operation on the pre-calculated key stream (B046). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B047).

[0049] As described above, according to the fourth embodiment, the following advantageous effects can be obtained. The system is configured to perform all keystream calculations in advance in the background before obtaining download consent from the user. This speeds up the decryption process of the update package in the OTA master 4, and increases the throughput when the OTA master 4 downloads the update package from the OTA center 2.

[0050] (Fifth embodiment) The fifth embodiment will be described with reference to Figures 39 to 42. In the fourth embodiment, calculation of all key streams is performed in advance in the background before download consent is obtained from the user, but in the fifth embodiment, calculation of some key streams is performed in advance in the background before download consent is obtained from the user. The part of key streams to be calculated is determined taking into consideration the memory capacity of the CPU cache memory and the throughput of the AES encryption operation, and is of a size that can be stored in the cache memory.

[0051] In this case, the key stream calculation unit 4g performs calculation of a part of the key stream in advance in the background before obtaining the download consent from the user. The key stream calculation unit 4g generates a key stream and adds it to the cache memory in parallel with the encrypted package acquisition unit 4c downloading and acquiring the encrypted update package from the CDN 8.

[0052] Next, the operation of the above-described configuration will be described with reference to FIGS. (5-1) Processing at OTA Center 2 The processing of the OTA center 2 is similar to the processing of the OTA center 2 described in the first embodiment (FIGS. 9 to 11).

[0053] (5-2) OTA Master 4 Processing (See Figures 39 to 41) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the AES key from the acquired campaign notification (B051). The OTA master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B052). The OTA master 4 performs calculations of a portion of the key stream in advance in the background before obtaining download consent from the user (B053).

[0054] The OTA master 4 distributes the campaign notification 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 (B054). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8, provided that the user consents to the download (B055). The OTA master 4 decrypts the encrypted update package downloaded from the CDN 8 by performing an XOR operation on the pre-calculated key stream and the encrypted update package (B056).

[0055] At this time, while downloading and acquiring the encrypted update package from CDN 8, the OTA master 4 generates a key stream and adds it to the cache memory (B057), and calculates the remaining key stream. The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B058). The relationship between memory capacity and access speed is as shown in Figure 42, and the size of the cache memory can be determined depending on the required access speed.

[0056] As described above, according to the fifth embodiment, the following advantageous effects can be obtained. The system is configured to perform calculations of some keystreams in advance in the background before obtaining download consent from the user. This enables the OTA master 4 to speed up the decryption process of the update package while saving memory usage, thereby increasing the throughput when the OTA master 4 downloads the update package from the OTA center 2.

[0057] (Sixth embodiment) The sixth embodiment will be described with reference to Fig. 43 to Fig. 54. In the sixth embodiment, the OTA master 4 identifies the encryption method by including the encryption method in repro policy metadata (hereinafter referred to as RP metadata) or the like and transmitting it from the OTA center 2 to the OTA master 4. The encryption method transmitted from the OTA center 2 to the OTA master 4 includes an encryption algorithm, an encryption key length, an encryption mode, a message authentication code (hereinafter referred to as MAC (Message Authentication Code)) algorithm, and the like.

[0058] The RP metadata includes configuration information of the update package, i.e., information indicating the configuration type of the update package. The OTA master 4 checks the data content to prevent delivery errors of the update package. The three-layer structure of the RP metadata (distribution, master, and target) allows for flexible definition and response even when the number of transfer methods, platform types, and update package types increases, making it possible to reprogram the target ECU 5. The encryption method may be included in download metadata (hereinafter referred to as DL metadata) and transmitted from the OTA center 2 to the OTA master 4, allowing the OTA master 4 to identify the encryption method. The DL metadata includes information for downloading update packages for each of multiple target ECUs 5 and specifies the content that the OTA master 4 should understand.

[0059] 44, the OTA center 2 includes a shared key generation unit 2a, an update package encryption unit 2b, a shared key encryption unit 2c, a shared key storage unit 2d, an encrypted package placement unit 2e, and a campaign notification transmission unit 2f, as well as an RP metadata generation unit 2g and an RP metadata encryption unit 2h. The RP metadata generation unit 2g generates RP metadata including a shared key encryption method. The RP metadata encryption unit 2h encrypts the RP metadata using an RSA public key.

[0060] The OTA master 4 includes a shared key acquisition unit 4a, a shared key decryption unit 4b, an encrypted package acquisition unit 4c, a block cipher processing unit 4d, an encrypted package decryption unit 4e, and an installation processing unit 4f, as well as an RP metadata acquisition unit 4h, an RP metadata decryption unit 4i, and a shared key cryptography method identification unit 4j. The RP metadata acquisition unit 4h downloads and acquires encrypted RP metadata from the CDN 8. The RP metadata decryption unit 4i decrypts the encrypted RP metadata using the RSA private key to extract the RP metadata. The shared key cryptography method identification unit 4j interprets the contents of the RP metadata and identifies the shared key cryptography method.

[0061] The process for distributing the update package from the CDN 8 to the OTA center 2 is as follows: The OTA center 2 sends a campaign notification to the OTA master 4 or the user's mobile information terminal. After that, the OTA master 4 accesses the CDN 8, which sends RP metadata and DL metadata from the CDN 8 to the OTA master 4, and the update package is distributed from the CDN 8 to the OTA center 2.

[0062] As shown in Figure 45, the RP metadata and DL metadata are transmitted from the OTA center 2 to the OTA master 4 prior to downloading the update package. As shown in Figures 46 and 47, the RP metadata includes information on the RP metadata version, distribution layer, master layer, and target layer. Each piece of information is as follows:

[0063] (a) RP Metadata Version The version of the RP metadata, such as "1.0.0" or "2.0.0". (b) Delivery Layer (b-1) Communication protocol This is information indicating a protocol used for communication with the OTA center 2, such as Uptane (registered trademark) or OMA-DM (Open Mobile Alliance-Device Management). (b-2) Means of communication This is the distribution route of the update package, and is information indicating a cellular device, smartphone, USB memory, etc. that indicates that it is an OTA master 4.

[0064] (c) Master Layer Information about OTA Master 4 (c-1)PF This information indicates whether the platform (PF) of the OTA master 4 is, for example, an AP (AUTOSAR Adaptive Platform), a CP (AUTOSAR Classic Platform), an AGL (Automotive Grade Linux), or Android (registered trademark). Regarding the package structure for distributing update packages according to the ECU platform, the specifications of the general incorporated association JASPAR prescribe data requirements applicable to the classic platform (CP) that runs on a static OS of the standardization organization AUTOSAR. AUTOSAR also prescribes data requirements applicable to a new type of adaptive platform (AP) that runs on a dynamic OS. AGL is Automotive Linux (registered trademark), and Android is Android Automotive OS. AP and CP refer to software platforms. Software platforms are also called software architectures. APs and CPs use different operating systems and development languages. The update package structures that can be received differ between ECUs that operate in accordance with the CP specification and those that operate in accordance with the AP specification. These differences in update package structure are primarily due to differences in the processing performance of the ECUs. Generally, the processing performance of ECUs that operate in accordance with the CP specification is relatively low, so the specification data included in the update package is written in binary data, which has a data structure that is easy to interpret and process even for ECUs with low processing performance.On the other hand, the processing performance of ECUs that operate in accordance with the AP specification is relatively high, so it is possible to equip them with a parser function that analyzes structured character data written in some language and converts it into a data structure that can be handled by a program, and the data structure is flexible because it can use object-oriented data formats such as JSON (JavaScript Object Notation) rather than simple binary data.

[0065] (c-2) Control method This information includes parameters that are processed according to parameters set in a specific format, and scripts that are processed in a more free description 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 an area is specified, offset size, and protected data size.

[0066] (d) Target Layer This is information about the target ECU 5. (d-1)PF Same as the master layer. (d-2) Transfer method Either storage or streaming (d-3) Control method Same as the master layer. (d-4) Target ID It is optional. (d-5) Encryption method Same as the master layer.

[0067] Next, the operation of the above-described configuration will be described with reference to FIGS. (6-1) Processing at OTA Center 2 (see Figures 48 to 51) The OTA center 2 generates a common key for encrypting the update package (A061). The OTA center 2 encrypts the update package using the generated common key in a specific encryption mode (A062). The OTA center 2 encrypts the common key using the RSA public key (A063). The OTA center 2 stores the common key encrypted using the RSA public key in the campaign notification (A064). The OTA center 2 generates RP metadata including a common key encryption method (A065). The OTA center 2 encrypts the RP metadata using the RSA public key (A066). The OTA center 2 places the update package encrypted using the common key and the RP metadata encrypted using the RSA public key in the CDN 8 (A067). The OTA center 2 transmits the campaign notification containing the encrypted common key to the vehicle-side system 3 to be reprogrammed (A068).

[0068] (6-2) OTA Master 4 Processing (See Figures 52 to 54) When the OTA master 4 receives the campaign notification transmitted from the OTA center 2 and acquires the campaign notification, it acquires the common key from the acquired campaign notification (B061). The OTA master 4 decrypts the encrypted common key using the RSA private key to extract the common key (B062). The OTA master 4 downloads and acquires the encrypted RP metadata from the CDN 8 (B063). The OTA master 4 decrypts the encrypted RP metadata using the RSA private key to extract the RP metadata (B064). The OTA master 4 interprets the contents of the RP metadata and identifies the common key encryption method (B065). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B066). After this, if the CTR mode is adopted as the specific encryption mode, the OTA master 4 performs the processes from step B014 onward described in the first embodiment, and if the OFB mode is adopted as the specific encryption mode, it performs the processes from step B024 onward described in the second embodiment. Similarly, for other encryption modes, the update package is decrypted and the data is transferred to the target ECU according to the procedure corresponding to the encryption mode.

[0069] As described above, according to the sixth embodiment, the following advantageous effects can be obtained. The encryption method is included in the RP metadata and DL metadata and transmitted from the OTA center 2 to the OTA master 4. This allows the OTA master 4 to identify the encryption method.

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

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

[0072] 61, the OTA center 2 includes a shared key generation unit 2a, an update package encryption unit 2b, a shared key encryption unit 2c, a shared 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.

[0073] 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 OTA master 4 receives a campaign notification transmitted from the OTA center 2, the MAC key acquisition unit 4k acquires the campaign notification and acquires the MAC key from the acquired campaign notification.

[0074] Next, the operation of the above-described configuration will be described with reference to FIGS. (7-1) Processing at OTA Center 2 (see Figures 62 to 64) The OTA center 2 generates an AES key for encrypting the update package and a MAC key for preventing tampering with the update package (A071). The OTA center 2 encrypts the update package in CCMP mode using the generated AES key and MAC key, and assigns a MAC (A072). The OTA center 2 encrypts the AES key and MAC key using an RSA public key (A073). The OTA center 2 stores the AES key and MAC key encrypted using the RSA public key in a campaign notification (A074). The OTA center 2 places the update package encrypted using the AES key and MAC key in the CDN 8 (A075). The OTA center 2 transmits the campaign notification containing the encrypted AES key and MAC key to the vehicle-side system 3 to be reprogrammed (A076).

[0075] (7-2) OTA Master 4 Processing (See Figures 65 to 67) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the AES key and MAC from the acquired campaign notification (B071). The OTA master 4 decrypts the encrypted AES key and MAC key using the RSA private key to extract the AES key and MAC key (B017). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B073).

[0076] At this time, while downloading and acquiring the encrypted update package from the CDN 8, the OTA master 4 performs AES block cipher processing on the counter value using the AES key to encrypt the counter value (B074). The OTA master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from the CDN 8 (B075). The 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, the OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B077). If the MACs do not match, the OTA master 4 terminates the processing. In this case, when the OTA master 4 terminates the processing due to a MAC mismatch, it may record a log indicating that the processing was terminated due to a MAC mismatch and may also display an error on an HMI (not shown). Alternatively, the OTA master 4 may perform an XOR operation to decrypt the encrypted update package, and at the same time, 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 a MAC key from the plaintext of the decrypted update package, and if it determines that the MACs do not match, notify the target ECU 5 to cancel the installation.

[0077] As described above, according to the seventh embodiment, the following advantageous effects can be obtained. The system is configured to use CCMP mode to encrypt the communication path between the OTA center 2 and the OTA master 4 and to protect against data tampering. By using CCMP mode, it is possible to encrypt the communication path and also protect against data tampering when the OTA master 4 downloads the update package from the OTA center 2. This enhances security and enables more secure OTA distribution.

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

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

[0080] Next, the operation of the above-described configuration will be described with reference to FIGS. (8-1) Processing of OTA Center 2 (see Figures 72 to 74) The OTA center 2 generates an AES key for encrypting the update package and a MAC key for preventing tampering with the update package (A081). The OTA center 2 encrypts the update package in GCMP mode using the generated AES key and MAC key, and assigns a MAC (A082). The OTA center 2 encrypts the AES key and MAC key using an RSA public key (A083). The OTA center 2 stores the AES key and MAC key encrypted using the RSA public key in a campaign notification (A084). The OTA center 2 places the update package encrypted using the AES key and MAC key in the CDN 8 (A085). The OTA center 2 transmits the campaign notification containing the encrypted AES key and MAC key to the vehicle-side system 3 to be reprogrammed (A086).

[0081] (8-2) OTA Master 4 Processing (See Figures 75 to 77) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the AES key and MAC from the acquired campaign notification (B081). The OTA master 4 decrypts the encrypted AES key and MAC key using the RSA private key to extract the AES key and MAC key (B082). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B083).

[0082] At this time, while downloading and obtaining the encrypted update package from the CDN 8, the OTA master 4 performs AES block cipher processing on the counter value using the AES key to encrypt the counter value (B084). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt it (B085). The OTA master 4 generates and verifies a MAC in GMAC mode from the plaintext of the decrypted update package using the MAC key (B086). If the MACs match, the OTA master transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B087).

[0083] As described above, according to the eighth embodiment, the following advantageous effects can be obtained. The system is configured to use GCMP mode to encrypt the communication path between the OTA center 2 and the OTA master 4 and to protect against data tampering. By using GCMP mode, it is possible to provide data tampering protection in addition to encrypting the communication path when the OTA master 4 downloads the update package from the OTA center 2. This enhances security and enables more secure OTA distribution.

[0084] (Ninth embodiment) The ninth embodiment will be described with reference to FIGS. 78 to 86. In the ninth embodiment, the update data distribution route is not limited to CDN 8, but also includes smartphones, USB memory sticks, etc., and by supporting a variety of distribution routes, the degree of freedom of the user's OTA update method is increased. Smartphones and USB memory sticks correspond to recording media. From here on, a smartphone and USB memory stick will be used as examples of storage media, but an SD card, micro SD card, compact flash, etc. may also be used as the storage medium.

[0085] Next, the operation of the above-described configuration will be described with reference to FIGS. (9-1) Processing at OTA Center 2 (see Figures 79 to 82) The OTA center 2 generates a common key for encrypting the update package (A091). The OTA center 2 encrypts the update package using the generated common key in a specific encryption mode (A092). The OTA center 2 encrypts the common key using the RSA public key (A093). The OTA center 2 stores the common key encrypted with the RSA public key in the campaign notification (A094). The OTA center 2 generates RP metadata including the common key encryption method and distribution route (A095). The OTA center 2 encrypts the RP metadata using the RSA public key (A096). The OTA center 2 places the update package encrypted with the common key and the RP metadata encrypted with the RSA public key in the CDN 8 (A097). The OTA center 2 transmits the campaign notification containing the encrypted common key to the vehicle-side system 3 to be reprogrammed (A098).

[0086] (9-2) OTA Master 4 Processing (See Figures 83 to 86) When the OTA master 4 receives a campaign notification sent from the OTA center 2 and acquires the campaign notification, it acquires an encrypted common key from the acquired campaign notification (B091). The OTA master 4 decrypts the encrypted common key using the RSA private key to extract the common key (B092). The OTA master 4 downloads and acquires the encrypted RP metadata from the CDN 8 (B093). The OTA master 4 decrypts the encrypted RP metadata using the RSA private key to extract the RP metadata (B094). The OTA master 4 interprets the contents of the RP metadata to identify the common key encryption method and the distribution route (B095). The OTA master 4 acquires the encrypted update package via the identified distribution route (B096). In other words, if the OTA master 4 identifies a smartphone as the distribution route, it downloads the encrypted update package from the CDN 8 via the smartphone using the bulk storage method. If the OTA master 4 identifies the USB memory as the delivery path, it downloads the encrypted update package from the CDN 8 via the USB memory using the bulk storage method. After this, if the OTA master 4 adopts the CTR mode as the specific encryption mode, it performs the processes from step B014 onwards described in the first embodiment, and if the OTA master 4 adopts the OFB mode as the specific encryption mode, it performs the processes from step B024 onwards described in the second embodiment.

[0087] As described above, according to the ninth embodiment, the following advantageous effects can be obtained. The update package is acquired from the CDN 8 via a smartphone, a recording medium such as a USB memory stick, or the like. This allows for a variety of update package distribution routes, making it possible to select a distribution route that is advantageous in terms of distribution cost and usability. This allows for appropriate reduction in distribution costs when the OTA master 4 downloads the update package from the OTA center 2, and also improves the user experience value. In the above-described embodiment, the OTA master 4 interprets the contents of the RP metadata in step B095 to identify the symmetric key cryptography method and distribution route. However, if multiple distribution routes are described in the RP metadata, it may be possible to select one of the multiple distribution routes.

[0088] (Tenth embodiment) A tenth embodiment will be described with reference to FIGS. 87 to 98. In the tenth embodiment, multiple CDN vendors are dynamically selected as destinations for distributing update packages to the CDN 8 depending on the distribution method, the OTA target area (distribution area), and the distribution data size, thereby reducing distribution costs. A comparison of CDN costs is shown in FIGS. 88 to 89. Price tables are shown in FIGS. 90 to 93. The price advantages of each CDN vendor vary depending on the distribution area (e.g., Japan, North America, etc.) and the distribution data size. For example, referring to FIG. 90, when distributing a monthly data size of 100 TB, 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 depending on the distribution method, OTA target area, and distribution data size.

[0089] 94, the OTA center 2 includes a shared key generation unit 2a, an update package encryption unit 2b, a shared key encryption unit 2c, a shared 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 a CDN vendor management database.

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

[0091] (10-2) OTA Master 4 Processing The processing of the OTA master 4 is similar to the processing of the OTA master 4 described in the first embodiment (FIGS. 12 to 14).

[0092] As described above, according to the tenth embodiment, the following advantageous effects can be obtained. The system references a CDN vendor management database and selects the CDN 8 with the most advantageous delivery cost based on the delivery method, OTA target area, and delivery data size from among multiple CDNs 8 with different delivery costs. The system then deploys the update package to the selected CDN 8. This appropriately reduces the delivery cost when the OTA master 4 downloads the update package from the OTA center 2. Furthermore, by encrypting the update package at the OTA center 2, security issues can be eliminated, even if the intermediate route is zero-trust. This eliminates the need to encrypt the update data at the CDN 8 edge, reducing the processing load and security functions of the CDN 8. Even if data tampering or a DDoS attack on the CDN 8 occurs along the update package route from the OTA center 2 to the OTA master 4, the OTA system remains unaffected. This eliminates the need for intelligent security measures in systems along the intermediate route, such as web application firewalls, TLS communication, and signed URLs that limit the OTA master 4 to which the package is delivered. This reduces the running costs of the OTA system on a cost basis, and keeps distribution costs down regardless of the system configuration.

[0093] (Eleventh embodiment) An eleventh embodiment will be described with reference to Figures 99 to 108. The eleventh embodiment employs Diffie-Hellman key exchange (hereinafter referred to as DHE (Diffie-Hellman key exchange)) or elliptic curve Diffie-Hellman key exchange (hereinafter referred to as ECDHE (Elliptic curve Diffie-Hellman key exchange)) for key distribution between the OTA center 2 and the OTA master 4, and the OTA center 2 encrypts the AES key based on shared secret information that differs for each vehicle and distributes it to the OTA master 4, thereby enjoying the benefit of ensuring forward secrecy of ECDHE and distributing update packages that are applicable to each vehicle model that is applicable to the CDN 8 or to a specific vehicle group.

[0094] 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 perform calculations in combination with their own private keys to secretly share secret information (S). The private key and public key pair (a / A, b / B) can be discarded after the secret information (S) is shared, and there is no need to store it in an HSM (Hardware Security Module) on both the OTA center 2 and the OTA master 4, so the secret information (S) can be shared very securely. This shared secret information (S) can be used as a key for symmetric key encryption, etc., but because the original data is random numbers (a, b), it will be a different key for each OTA master 4.

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

[0096] Step A114 will now be described. When the vehicle ignition is turned on and a predetermined period of time has elapsed since the previous synchronization of vehicle configuration information, the OTA master 4 queries the ECU installed in the vehicle for the program version and collects the vehicle configuration information. Alternatively, when the OTA master 4 receives a push notification related to a campaign from the OTA center 2, it queries the ECU for the program version and collects the vehicle configuration information. After collecting the vehicle configuration information, the OTA master 4 establishes TLS communication with the OTA center 2 and transmits the vehicle configuration information to the OTA center 2. At this time, the OTA master 4 generates an ECDHE key pair while collecting the vehicle configuration information. After establishing TLS communication with the OTA center 2, it transmits the public key of the OTA master 4 from the key pair to the OTA center 2. Note that the process of the OTA master 4 collecting vehicle configuration information is also applicable to other embodiments. The OTA center 2 obtains a private key for the ECDHE algorithm based on the public key of the OTA master 4 and the private key of the OTA center 2 obtained from the OTA master 4.

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

[0098] At this time, while downloading and obtaining the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B116). The OTA master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from the CDN 8 (B117). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B118).

[0099] As described above, according to the eleventh embodiment, the following advantageous effects can be obtained. DHE or ECDHE is used for key distribution between the OTA center 2 and the OTA master 4, and the OTA center 2 encrypts the AES key based on shared secret information that differs for each vehicle and distributes it to the OTA master 4. This makes it possible to appropriately ensure the forward secrecy of ECDHE while also appropriately realizing efficient distribution of update data by the CDN 8.

[0100] (Modification of the eleventh embodiment) A modified example of the eleventh embodiment will be described with reference to Figs. 166 to 173. In the eleventh embodiment, the description was given on the assumption 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 the CDN 8 via a wireless communication line. However, there are cases where the vehicle is not installed with a wireless communication device or where the user does not prefer to use a wireless communication line. In the modified example of the eleventh embodiment, a situation will be described in which the OTA master 4 does not send and receive data with the OTA center 2 and the CDN 8 via a wireless communication line, but instead performs a program update using a storage medium such as an SD card.

[0101] The OTA master 4 and the OTA center 2 use a storage medium for data transfer with the outside. Data transfer between the OTA master 4 and the storage medium uses a port for the storage medium installed in the vehicle. The port installed in the vehicle is, for example, a port installed in a car navigation device, a center display device, or another vehicle control device.

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

[0103] A case where an SD card is used as the storage medium will be described with reference to Figures 166 to 169. In this case, processing is performed in the following order: data transfer from the OTA master 4 to the SD card 11, data upload from the SD card 11 to the OTA center 2, data download from the OTA center 2 to the SD card 11, and data transfer from the SD card 11 to the OTA master 4.

[0104] With reference to Figure 166, the transfer of data from the OTA master 4 to the SD card 11 will be described. The OTA master 4 acquires software version information, etc. from the target ECU 5, and transfers and stores the acquired software version information, etc. as vehicle configuration information to the SD card 11. The OTA master 4 generates an ECDHE key pair from random numbers, and transfers and stores 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.

[0105] With reference to Figure 167, the uploading of data from a PC connected to the SD card 11 to the OTA center 2 will be described. 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 in 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 a campaign is running. The ECDHE public key of the OTA master 4 uploaded to the OTA center 2 shares a private key based on the ECDHE algorithm in the distribution server 7. In this case, the private key is a different private key for each vehicle.

[0106] Referring to Figure 168, the download of data from the OTA center 2 to the SD card 11 will be described. Here, the case where a campaign is running is shown. The OTA center 2 downloads and stores an update package encrypted with an AES key to the SD card 11. The OTA center 2 generates an ECDHE key pair from random numbers, and downloads and stores the key to be shared with the OTA master 4 (the OTA center 2's ECDHE public key) to the SD card 11. The OTA center 2 downloads and stores a campaign notification containing the encrypted AES key to the SD card 11. The SD card 11 stores the update package downloaded from the OTA center 2, the OTA center 2's ECDHE public key, and the encrypted AES key.

[0107] 169, a description will be given of the transfer of data from the SD card 11 to the OTA master 4. The OTA master 4 reads and acquires from the SD card 11 the encrypted update package, the ECDHE public key of the OTA center 2, and the encrypted AES key stored in the SD card 11.

[0108] Next, the operation of the above-described configuration will be described with reference to FIGS. 170 to 174. (11-3) OTA Master 4 Processing (See Figure 170) When the SD card 11 is connected to the vehicle-side system 3 and a predetermined condition is 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). After acquiring the vehicle configuration information, the OTA master 4 transfers the acquired vehicle configuration information to the SD card 11 and stores it (B1112). The OTA master 4 generates an ECDHE key pair from random numbers (B1113). In this case, the key pair includes an ECDHE public key and an ECDHE private key of the OTA master 4. The OTA master 4 transfers the ECDHE public key of the OTA master 4 to the SD card 11 and stores it (B1114). After the vehicle configuration information and the ECDHE public key of the OTA master 4 are stored in this way, the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.

[0109] (11-4) PC processing (see Figure 171) When 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 to receive from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 and the AES key are stored, and an encrypted update package, as well as a notification that there is no campaign (C1112, C1113). If the PC determines that it has received from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 and the AES key are stored, and an encrypted update package (C1112: YES), or if it determines that it has received a notification that there is no campaign (C1113: YES), it ends the processing.

[0110] (11-5) Processing at OTA Center 2 (see Figure 172) The OTA center 2 generates an AES key for encrypting the update package and encrypts the update package in CTR mode with the AES key. The OTA center 2 acquires the vehicle configuration information uploaded from the PC to which the SD card 11 is connected and the ECDHE public key of the OTA master 4 (A1111). The OTA center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1112). If the OTA center 2 determines that there is no campaign (A1112: NO), it sends a notification that there is no campaign to the PC (A1113) and ends the process.

[0111] When the OTA center 2 determines that a campaign is running (A1112: YES), it generates an ECDHE key pair from random numbers (A1114). In this case, the key pair is the OTA center 2's ECDHE public key and ECDHE private key. The OTA center 2 downloads and stores the OTA center 2's ECDHE public key to the SD card 11 (A1115). The OTA center 2 generates an ECDHE common key (private key) from the OTA center 2's ECDHE private key and the OTA master 4's ECDHE public key (A1116) and encrypts the AES key with the generated ECDHE common key (private key) (A1117). The OTA center 2 stores the encrypted AES key in the campaign notification, and downloads and stores the campaign notification containing the encrypted AES key to the SD card 11 (A1118). The OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1119).

[0112] (11-6) OTA Master 4 Processing (See Figure 173) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 obtains the ECDHE public key, campaign notification, and update package of the OTA center 2 from the SD card 11 (B1121). The OTA master 4 generates an ECDHE common 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 common key (private key) (B1123). The OTA master 4 encrypts the counter value by performing AES block encryption 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 in the target ECU 5 (B1126).

[0113] This configuration makes it possible to appropriately ensure the forward secrecy of ECDHE and to appropriately achieve efficient distribution of update data by the CDN 8 without relying on the wireless communication function of the vehicle-side system 3. Furthermore, by reducing the number of data transfers between the OTA master 4 and the SD card 11 and the number of uploads and downloads between the OTA center 2 and the SD card 11, convenience for the user can be improved.

[0114] (Twelfth embodiment) The twelfth embodiment will be described with reference to Figures 109 to 115. In the twelfth 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 a fixed value for each vehicle model, a count-up value, or a hash value of the software version of the OTA master 4, or a combination of these. This makes it possible to make the secret key shared by ECDHE common for each vehicle model, and to enjoy the benefit of ensuring forward secrecy of ECDHE, while omitting the process of distributing the key and distributing an encryption package applicable to each vehicle model or a specific group of vehicles via a CDN.

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

[0116] (12-2) OTA Master 4 Processing (See Figures 113 to 115) The OTA master 4 generates an ECDHE key pair from random numbers generated according to the specific rules described above (B121). The OTA center 2 shares a secret key with the OTA center 2 using the ECDHE algorithm (B122, corresponding to the secret information sharing procedure). The OTA master 4 downloads and obtains the encrypted update package from the CDN 8 (B123).

[0117] At this time, while downloading and obtaining the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B124). The OTA master 4 performs an XOR operation on the encrypted counter value and the encrypted update package downloaded from the CDN 8 to decrypt it (B125). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B126).

[0118] As described above, according to the twelfth embodiment, the following advantageous effects can be obtained. DHE or ECDHE is adopted for key distribution between the OTA center 2 and the OTA master 4, and the secret key shared by ECDHE is configured to be common for each vehicle model. This makes it possible to appropriately ensure forward secrecy of ECDHE, simplify the work of key distribution compared to the eleventh embodiment, and appropriately realize efficient distribution of update data by the CDN 8.

[0119] (Modification of the twelfth embodiment) A modified example of the twelfth embodiment will be described with reference to Fig. 174 to Fig. 181. In the modified example of the twelfth embodiment, as in the modified example of the eleventh embodiment, the OTA master 4 does not transmit and receive data to and from the OTA center 2 or the CDN 8 via a wireless communication line, but instead performs a program update using a storage medium such as an SD card.

[0120] Referring to Figure 174, the transfer of data from the OTA master 4 to the SD card 11 will be described. The OTA master 4 acquires software version information and the like from the target ECU 5, and transfers and stores the acquired software version information and the like to the SD card 11 as vehicle configuration information. The OTA master 4 generates an ECDHE key pair common to each vehicle model using one or a combination of a fixed value for each vehicle model, a count-up value, or a hash value of the OTA master 4's software version, and transfers and stores the key to be shared with the OTA center 2 (the OTA master 4's ECDHE public key) to the SD card 11. One or a combination of a fixed value for each vehicle model, a count-up value, or a hash value of the OTA master 4's software version corresponds to a specific rule. The SD card 11 stores the vehicle configuration information and the OTA master 4's ECDHE public key transferred from the OTA master 4.

[0121] With reference to Figure 175, the uploading of data from a PC to which the SD card 11 is connected to the OTA center 2 will be described. When the SD card 11 is connected, the PC reads the vehicle configuration information and the ECDHE public key of the OTA master 4 stored in 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 a campaign is running. Furthermore, the ECDHE public key of the OTA master 4 uploaded to the OTA center 2 shares a secret key based on the ECDHE algorithm in the distribution server 7. In this case, the secret key is a secret key common to each vehicle model.

[0122] With reference to Figure 176, the downloading of data from the OTA center 2 to the SD card 11 will be described. The OTA center 2 generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group, and downloads and stores the key to be shared with the OTA master 4 (the OTA center 2's ECDHE public key) to the SD card 11. The OTA center 2 encrypts the update package using the private key shared by ECDHE as an AES key, and downloads and stores the encrypted update package to the SD card 11. The SD card 11 stores the OTA center 2's ECDHE public key and the update package downloaded from the OTA center 2.

[0123] Referring to Figure 177, the transfer of data from the SD card 11 to the OTA master 4 will be described. The OTA master 4 reads and acquires the encrypted update package stored in the SD card 11 and the ECDHE public key of the OTA center 2. The OTA master 4 shares a secret key based on the ECDHE algorithm. The OTA master 4 uses the secret key shared by ECDHE as an AES key to decrypt the encrypted update package.

[0124] Next, the operation of the above-described configuration will be described with reference to FIGS. 178 to 181. (12-3) OTA Master 4 Processing (See Figure 178) When the SD card 11 is connected to the vehicle-side system 3 and a predetermined condition is satisfied, 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). After acquiring the vehicle configuration information, the OTA master 4 transfers the acquired vehicle configuration information to the SD card 11 and stores it (B1212). The OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B1213). In this case, the key pair includes an ECDHE public key and an ECDHE private key of the OTA master 4. The OTA master 4 transfers the ECDHE public key of the OTA master 4 to the SD card 11 and stores it (B1214). The ECDHE key pair is random numbers generated according to specific rules, as in the twelfth embodiment, and is common to each vehicle model. Once the vehicle configuration information and the ECDHE public key of the OTA master 4 are saved in the SD card 11 in this manner, the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.

[0125] (12-4) PC processing (see Figure 179) When 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 to receive from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package, and also waits to receive a notification that there is no campaign (C1212, C1213). When the PC determines that it has received from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package (C1212: YES) or a notification that there is no campaign (C1213: YES), it ends the processing.

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

[0127] When the OTA center 2 determines that a campaign is running (A1212: YES), it generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group (A1214). In this case, the key pair is the OTA center 2's ECDHE public key and ECDHE private key. The OTA center 2 downloads and stores the OTA center 2's ECDHE public key to the SD card 11 (A1215). The OTA center 2 generates an ECDHE common key (private key) from the OTA center 2's ECDHE private key and the OTA master 4's ECDHE public key (A1216), and encrypts the update package with the generated ECDHE common key (private key) (A1217). The OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1218).

[0128] (12-6) OTA Master 4 Processing (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 of the OTA center 2 from the SD card 11 (B1221). The OTA master 4 generates an ECDHE common 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 encryption processing with 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 in the target ECU 5 (B1225).

[0129] According to this configuration, it is possible to appropriately ensure forward secrecy of ECDHE without relying on the wireless communication function of the vehicle-side system 3, while simplifying the work of key distribution compared to the eleventh embodiment and appropriately realizing efficient distribution of update data by the CDN 8. Furthermore, by reducing the number of data transfers between the OTA master 4 and the SD card 11 and the number of uploads and downloads between the OTA center 2 and the SD card 11, it is possible to improve convenience for the user.

[0130] (Thirteenth embodiment) The thirteenth embodiment will be described with reference to Figs. 116 to 124. The thirteenth embodiment does not simply apply the CTR mode, but rather improves security by incorporating a counter value. Specifically, the CTR mode is made safer by incorporating a nonce into the counter value in the campaign notification that is first communicated between the OTA center 2 and the OTA master 4. The encryption process for inserting the CTR mode nonce is as shown in Fig. 117, and the decryption process for inserting the CTR mode nonce is as shown in Fig. 118.

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

[0132] (13-2) OTA Master 4 Processing (See Figures 122 to 124) When the OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2, it acquires the AES key and nonce from the acquired campaign notification (B131). The OTA master 4 decrypts the encrypted AES key using the RSA private key to extract the AES key (B132). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B133). The OTA master 4 decrypts the encrypted update package downloaded from the CDN 8 using the AES key and nonce (B134). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B135).

[0133] As described above, according to the thirteenth embodiment, the following advantageous effects can be obtained. The configuration is such that a nonce is included in the campaign notification that is first communicated between the OTA center 2 and the OTA master 4, and the nonce is then included in the counter value. By including the nonce in the counter value, the CTR mode can be made safer.

[0134] (Fourteenth embodiment) The fourteenth embodiment will be described with reference to Figures 125 to 132. In the fourteenth embodiment, instead of using a common key for all vehicles to narrow the scope of impact in the event of key compromise, a derived key individualized for each specific vehicle group is used for encryption. This localizes the loss in the event of a key leak while maintaining the efficiency of the CDN8 distribution cache, thereby achieving more secure OTA distribution. As shown in Figure 126, VIN numbers are divided into multiple categories for the same vehicle model and year, and different AES individual keys are used for each category. For example, VIN numbers are divided into categories based on VIN numbers AAA to CCC, VIN numbers DDD to KKK, and VIN numbers SSS to ZZZ, and different AES individual keys are used for each category. The individual key database includes, for example, an OEM code, vehicle model, year, AES master key, seed value, and AES individual keys divided by VIN number.

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

[0136] (14-2) OTA Master 4 Processing (See Figures 130 to 132) When the OTA master 4 receives the campaign notification sent from the OTA center 2, it acquires the campaign notification and obtains the AES individual key and nonce from the acquired campaign notification (B141). The OTA master 4 decrypts the encrypted AES individual key using the RSA private key to extract the AES individual key (B142). The OTA master 4 downloads and acquires the encrypted update package from the CDN 8 (B143). The OTA master 4 decrypts the encrypted update package downloaded from the CDN 8 using the AES individual key and nonce (B144). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B145).

[0137] As described above, according to the fourteenth embodiment, the following advantageous effects can be obtained. Instead of using a common key for all vehicles, the encryption key is configured to use a derived key that is individualized for each specific vehicle group. This makes it possible to localize the loss that occurs when a key is leaked while maintaining the efficiency of the CDN8 distribution cache. This improves security when the OTA master 4 downloads update packages from the OTA center 2, enabling more secure OTA distribution.

[0138] (Fifteenth embodiment) The fifteenth embodiment will be described with reference to FIGS. 133 to 137. In the fifteenth embodiment, in preparation for the worst-case scenario of private key leakage, key versions are assigned and managed at the OTA center 2 so that keys can be updated over the air, and a key update key is stored in the HSM area of ​​the OTA master. The OTA center 2 manages version information of the RSA public key used to encrypt the AES key and the RSA private key used to decrypt it. Managing the version information prevents downgrading when updating the RSA private key and RSA public key. The OTA center 2 and the OTA master 4 each have a key update key used when updating the private key. The OTA center 2 generates a new private key pair when the private key is leaked or at regular intervals, generates a key update package using the key update key, and transmits the key update package to the OTA master 4, thereby realizing private key update.

[0139] Next, the operation of the above-described configuration will be described with reference to FIGS. (15-1) Processing at OTA Center 2 (see Figures 134 and 135) The OTA center 2 generates a new key pair consisting of a new RSA private key and a new RSA public key (A151). The OTA center 2 encrypts and MACs the generated new RSA private key using the key update key in CTR mode to generate a key update package (A152). The OTA center 2 switches the old RSA public key to the new RSA public key (A153). The OTA center 2 transmits the key update package to the vehicle-side system 3 to be reprogrammed (A154).

[0140] (15-2) OTA Master 4 Processing (See Figures 136 and 137) The OTA master 4 acquires the key update package, decrypts the new RSA private key in CTR mode using the key update key, and verifies the MAC (B151). The OTA master 4 switches the old RSA private key to the decrypted new RSA private key (B152).

[0141] As described above, according to the fifteenth embodiment, the following advantageous effects can be obtained. The system is configured to generate a new private key pair when the private key is leaked or at regular intervals, generate a key update package using a key update key, and transmit the key update package to the OTA master 4. By updating the private key in this way, it is possible to improve security when the OTA master 4 downloads an update package from the OTA center 2, thereby realizing more secure OTA distribution.

[0142] (16th embodiment) The sixteenth embodiment will be described with reference to Fig. 138 to Fig. 145. In the sixteenth embodiment, in ECDHE key agreement, a digital signature is added to counter man-in-the-middle attacks, and a key applicable to an encrypted package is securely agreed upon between the OTA center 2 and the OTA master 4. As shown in Fig. 139 to Fig. 140, DHE is vulnerable to attacks from man-in-the-middle attackers, but adding a digital signature counters these attacks. As the digital signature, a digital signature using an RSA or elliptic curve DSA encryption algorithm is used.

[0143] Next, the operation of the above-described configuration will be described with reference to FIGS. (16-1) Processing at OTA Center 2 (see Figures 141 to 143) The OTA center 2 generates an ECDHE key pair from random numbers created for each vehicle model or vehicle fleet (A161). The OTA center 2 digitally signs the ECDHE key using an RSA private key (A162). While an RSA private key is used here, it is not limited to an RSA private key and can be replaced by any public key cryptosystem, such as an ECDSA (Elliptic Curve Digital Signature Algorithm) private key. The OTA center 2 transmits the digitally signed ECDHE public key to the vehicle-side system 3 to be reprogrammed (A163). The OTA center 2 shares the private key with the OTA master 4 using the ECDHE algorithm (A164). The OTA center 2 generates an AES key for encrypting the update package (A165). The OTA center 2 encrypts the update package in CTR mode using the generated AES key (A166). The OTA center 2 places the update package encrypted with the AES key on the CDN 8 (A167). The OTA center 2 transmits the campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A168).

[0144] (16-2) OTA Master 4 Processing (See Figure 144 to Figure 145) The OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B161). The OTA master 4 verifies the digital signature of the ECDHE public key received from the OTA center 2 using the RSA public key (B162). Here, as with the OTA center 2, the key is not limited to an RSA public key, and any public key cryptosystem can be used, such as an ECDSA public key. If the verification result is positive, the OTA master 4 shares the private key with the OTA center 2 using the ECDHE algorithm (B163). Thereafter, the OTA master 4 performs the processes from step B113 onwards described in the eleventh embodiment.

[0145] As described above, according to the sixteenth embodiment, the following advantageous effects can be obtained. A digital signature is added to the ECDHE key exchange, which makes it possible to counter man-in-the-middle attacks and achieve more secure OTA distribution.

[0146] (Modification of the 16th embodiment) A modification of the sixteenth embodiment will be described with reference to Figures 182 to 189. As with the modifications of the eleventh and twelfth embodiments, the modification of the sixteenth embodiment also describes a situation in which the OTA master 4 does not transmit or receive data to or from the OTA center 2 or CDN 8 via a wireless communication line, but instead performs a program update using a storage medium such as an SD card. The main difference between the modification of the sixteenth embodiment and the modification of the twelfth embodiment is that a digital signature is applied to the ECDHE public key of the OTA center 2 using a public key cryptography key to counter man-in-the-middle attacks.

[0147] 182 to 185 respectively show data transfer from the OTA master 4 to the SD card 11, data upload from a PC connected to the SD card 11 to the OTA center 2, data download from the OTA center 2 to the SD card 11, and data transfer from the SD card 11 to the OTA master 4. The main difference from the modified example of the twelfth embodiment is that, as shown in FIG. 184, the OTA center 2 digitally signs a key to be shared with the OTA master 4 (the OTA center 2's ECDHE public key) using a public key cryptography key, such as an RSA private key or an ECDSA private key. The OTA center 2 transfers the signed ECDHE public key to the SD card 11 and stores it. Furthermore, as shown in FIG. 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.

[0148] Next, the operation of the above-described configuration will be described with reference to FIGS. (16-3) OTA Master 4 Processing (See Figure 186) When the SD card 11 is connected to the vehicle-side system 3 and a predetermined condition is satisfied, 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). After acquiring the vehicle configuration information, the OTA master 4 transfers the acquired vehicle configuration information to the SD card 11 and stores it (B1612). The OTA master 4 generates an ECDHE key pair from random numbers generated according to specific rules (B1613). In this case, the key pair includes an ECDHE public key and an ECDHE private key of the OTA master 4. The OTA master 4 transfers the ECDHE public key of the OTA master 4 to the SD card 11 and stores it (B1614). The ECDHE key pair is random numbers generated according to specific rules, as in the twelfth embodiment, and is common to each vehicle model. Once the vehicle configuration information and the ECDHE public key of the OTA master 4 are saved in the SD card 11 in this manner, the SD card 11 is disconnected from the vehicle-side system 3 and connected to the PC.

[0149] (16-4) PC processing (see Figure 187) When 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 to receive from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package, and also waits to receive a notification that there is no campaign (C1612, C1613). When the PC determines that it has received from the OTA center 2 a campaign notification in which the ECDHE public key of the OTA master 4 is stored and an encrypted update package (C1612: YES) or a notification that there is no campaign (C1613: YES), it ends the processing.

[0150] (16-5) Processing at OTA Center 2 (see Figure 188) The OTA center 2 acquires the vehicle configuration information and the ECDHE public key of the OTA master 4 uploaded from the PC to which the SD card 11 is connected (A1611). The OTA center 2 determines whether or not there is a campaign based on the vehicle configuration information (A1612). If the OTA center 2 determines that there is no campaign (A1612: NO), it sends a notification that there is no campaign to the PC (A1613) and ends the process.

[0151] When the OTA center 2 determines that a campaign is running (A1612: YES), it generates an ECDHE key pair from a random number that is common to each vehicle model or each vehicle group (A1614). In this case, the key pair consists of the OTA center 2's ECDHE public key and ECDHE private key. The OTA center 2 signs the OTA center 2's ECDHE public key with its RSA private key (A1615) and downloads and stores the signed OTA center 2's ECDHE public key to the SD card 11 (A1616). The OTA center 2 generates an ECDHE common key (private key) from the OTA center 2's ECDHE private key and the OTA master 4's ECDHE public key (A1617) and encrypts the update package with the generated ECDHE common key (private key) (A1618). The OTA center 2 downloads and stores the encrypted update package to the SD card 11 (A1619).

[0152] (16-6) OTA Master 4 Processing (See Figure 189) When the SD card 11 is connected to the vehicle-side system 3, the OTA master 4 acquires the signed ECDHE public key of the OTA center 2 and the update package from the SD card 11 (B1621). The OTA master 4 verifies the signed ECDHE public key of the OTA center 2 with the RSA public key (B1622). The OTA master 4 determines whether 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).

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

[0154] This configuration makes it possible to counter attacks from man-in-the-middle attackers and achieve more secure OTA distribution without relying on the wireless communication function of the vehicle-side system 3. Furthermore, by reducing the number of data transfers between the OTA master 4 and the SD card 11 and the number of uploads and downloads between the OTA center 2 and the SD card 11, convenience for users can be improved.

[0155] (17th embodiment) The seventeenth embodiment will be described with reference to Figures 146 to 151. The tenth embodiment is configured to select, for each area, a CDN vendor from multiple CDN vendors that minimizes delivery costs, while the seventeenth embodiment is configured to statically select, from multiple CDN vendors, a CDN vendor that can reduce delivery costs. Specifically, the tenth embodiment encrypts the update package at the OTA center 2 and then minimizes delivery costs depending on the delivery method, OTA target area, and delivery data size, while the seventeenth embodiment does not encrypt the update package at the OTA center 2, and protects communication between the CDN 8 and the OTA master 4 with TLS communication, and then minimizes delivery costs depending on the delivery method, OTA target area, and delivery data size.

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

[0157] (17-2) OTA Master 4 Processing (See Figure 149 to Figure 151) The OTA master 4 acquires the campaign notification by receiving the campaign notification sent from the OTA center 2 (B171). The OTA master 4 establishes TLS communication with the CDN vendor listed in the campaign notification to acquire the update package (B172). Note that as long as the campaign notification contains URI information, it does not have to contain CDN vendor information. After establishing TLS communication, the OTA master 4 exchanges AES common keys using the TLS communication protocol. Negotiations are performed to select AES-CTR mode as the encryption mode. The OTA master 4 downloads and acquires the update package encrypted with the TLS AES common key from the CDN 8 based on the URI information (B173, corresponding to the update data acquisition procedure).

[0158] At this time, while downloading and obtaining the encrypted update package from the CDN 8, the OTA master 4 performs AES block encryption processing on the counter value using the AES key to encrypt the counter value (B174). The OTA master 4 decrypts the encrypted counter value by performing an XOR operation on the encrypted update package downloaded from the CDN 8 (B175). The OTA master 4 transfers the decrypted update package to the target ECU 5 and installs the update package in the target ECU 5 (B176).

[0159] As described above, according to the seventeenth embodiment, the following advantageous effects can be obtained. The update package is not encrypted at the OTA center 2, and is protected by TLS communication between the CDN 8 and the OTA master 4, with the configuration minimizing distribution costs depending on the distribution method, OTA target area, communication protocol, and distribution data size. This makes it possible to appropriately suppress distribution costs when the OTA master 4 downloads the update package from the OTA center 2.

[0160] (18th embodiment) The eighteenth embodiment will be described with reference to Figures 152 to 165. The eighteenth embodiment selects the optimal CDN vendor by comprehensively considering not only delivery costs but also the CDN vendor's throughput, response delay time, and other factors. The CDN vendor's price table and quality characteristics are regularly checked, the CDN vendor management database is always kept up to date, and the CDN vendor with the most competitive advantage in the market is always selected. The price tables are as shown in Figures 153 to 160, and the quality information of each cloud service provider is as shown in Figure 161. As shown in Figure 162, when CDN vendors A and B are compared, CDN vendor B is superior to CDN vendor A in terms of delivery costs, but CDN vendor A is superior to CDN vendor B in terms of throughput weighting and response delay time weighting. If we take into consideration not only the delivery cost but also the CDN vendor's throughput, response delay time, etc., we can conclude that we should select CDN vendor A, which has an advantage after comprehensively considering the CDN vendor's throughput, response delay time, etc., rather than CDN vendor B, which has an advantage solely in terms of delivery cost.

[0161] Next, the operation of the above-described configuration will be described with reference to FIGS. (18-1) Processing at OTA Center 2 (see Figures 163 to 165) The OTA center 2 identifies a distribution method (A181) and an OTA target area (A182), and references a price table from the CDN vendor management database using the distribution method and the OTA target area as keys (A183). In this case, the OTA center 2 may reference the price table using at least one of the distribution method and the OTA target area as keys. The OTA center 2 identifies the quality characteristics of each CDN vendor from the CDN vendor management database (A184). The OTA center 2 selects the optimal CDN vendor for each area from the CDN vendor selection logic registered in the CDN vendor selection logic database based on the distribution cost and quality characteristics of the CDN vendor for each area, and places the update package encrypted with the AES key in the selected CDN 8 (A185). The OTA center 2 then transmits a campaign notification containing the encrypted AES key to the vehicle-side system 3 to be reprogrammed (A186).

[0162] The OTA center 2 automatically obtains the price table of each CDN vendor from their website and updates the CDN vendor management database (A187). The OTA center 2 measures the throughput and response delay time of each CDN vendor and updates the CDN vendor management database (A188). For example, the distribution server 7 periodically visits each CDN vendor's website and downloads the latest price table. Alternatively, when a CDN vendor distributes updated information on its website, the distribution server 7 registers with that distribution service and downloads the latest price table.

[0163] (18-2) OTA Master 4 Processing The processing of the OTA master 4 is similar to the processing of the OTA master 4 described in the first embodiment (FIGS. 12 to 14).

[0164] As described above, according to the eighteenth embodiment, the following advantageous effects can be obtained. The optimal CDN vendor is selected by comprehensively considering not only the delivery cost but also the CDN vendor's throughput, response delay time, etc., and the CDN vendor's price table and quality characteristics are regularly checked to keep the CDN vendor management database up to date at all times, ensuring that the CDN vendor with the most competitive advantage in the market is always selected. This makes it possible to appropriately suppress the delivery cost when the OTA master 4 downloads update packages from the OTA center 2.

[0165] CDN quality characteristics are not limited to throughput and response delay time, but can also take into account content cache hit rates and past trouble records, and these can be included in the CDN vendor management database. Also, it is possible to periodically review the addition and deletion of CDN vendors to which OTA Center 2 connects, and to connect with CDN vendors that are competitive in the market.

[0166] (19th embodiment) The 19th embodiment will be described with reference to Fig. 90 and Fig. 190 to Fig. 193. The above-mentioned 10th embodiment is configured to select, for each area, a CDN vendor with the lowest delivery cost from multiple CDN vendors. The 19th embodiment will specifically describe the selection of a CDN vendor. In the 19th embodiment, a CDN vendor with the lowest delivery cost is dynamically selected from multiple CDN vendors as the destination for disposing an update package on the CDN 8, depending on the delivery data size, the OTA target area (sometimes referred to as a region) that is the delivery area, and the delivery method. The 19th embodiment will be described with reference to the price table exemplified in Fig. 90 above. The price table may be in a format different from that of Fig. 90.

[0167] As shown in FIG. 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 information necessary for selecting a CDN vendor. The selection information includes the data size of the target campaign, the number of vehicles to which the target campaign is to be distributed, the region, information about the distribution method, etc. 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 obtains information from the data storage unit 7b and generates a campaign notification to be distributed to vehicles, etc.

[0168] 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, when the CDN distribution unit 7d distributes data from CDN server A to the vehicle-side system 3, for example, the CDN distribution unit 7d places the data in storage area A and transfers it to the CDN server A. When the CDN distribution unit 7d transfers the data, the CDN server A 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 the corresponding CDN server.

[0169] Next, the operation of the above-described configuration will be described with reference to Fig. 191 to Fig. 193. Note that the processing of encryption of the update package by the OTA center 2 is the same as in the tenth embodiment or other embodiments. Also, the processing of the OTA master 4 is the same as in the first embodiment or other embodiments. In the 19th embodiment, the selection of a CDN vendor will be mainly described.

[0170] (19-1) Processing of the Campaign Notification Generator 7c (See FIG. 191) When a campaign occurs, the campaign notification generation unit 7c acquires campaign information from an external source, such as an OEM server (A191). The campaign information includes information regarding the data size of the target campaign, the number of vehicles to which the target campaign is to be distributed, the region, and the distribution method. The campaign notification generation unit 7c stores the acquired campaign information in the data storage unit 7b (A192). Storing campaign information is sometimes referred to as arranging campaign information.

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

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

[0173] (19-2) Processing of the CDN vendor selection unit 7a (see Figures 192 and 193) When the CDN vendor selection unit 7a receives a 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).

[0174] When the CDN vendor selection unit 7a starts the first CDN selection process, it calculates a distribution data size indicating the size of data to be distributed from the CDN server to the vehicles to be updated (A1921). Specifically, the CDN vendor selection unit 7a multiplies the data size of the target campaign by the number of vehicles to be distributed for the target campaign, and calculates the distribution data size to be distributed from the CDN server.

[0175] The CDN vendor selection unit 7a repeats the following process for each CDN vendor (A1922 to A1929). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the previously calculated distribution data size and region information (A1923). For example, in the case of a 30TB campaign targeting North America, the CDN vendor selection unit 7a acquires fee information for "up to 10TB" and "up to 40TB" for the "North America" ​​region. Fee information may also be acquired for all data sizes.

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

[0177] The CDN vendor selection unit 7a determines whether the CDN vendor under consideration is a CDN vendor that charges according to the number of requests (A1925). If the CDN vendor selection unit 7a determines that the CDN vendor does not charge according to the number of requests (A1925: NO), it determines the delivery charge amount as the CDN vendor's charge amount (A1928), ends calculation of the charge amount for the CDN vendor, and calculates the charge amount for the next CDN vendor.

[0178] When the CDN vendor selection unit 7a determines that the CDN vendor charges according to the number of requests (A1925: YES), it calculates the number of requests (A1926). The number of requests varies depending on the distribution method. If the distribution method is a storage method, the number of requests is the number of vehicles to which the campaign is to be distributed. If the distribution method is a streaming method, the number of requests is calculated by dividing the data size of the target campaign by the chunk size when streaming and multiplying it by the number of vehicles to which the campaign is to be distributed.

[0179] After calculating the number of requests, the CDN vendor selection unit 7a calculates a charge amount (sometimes referred to as a 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 up the delivery charge amount and the request charge amount as the charge amount for the CDN vendor (A1928), terminates calculation of the charge amount for the CDN vendor under consideration, and calculates the charge amount for the next CDN vendor.

[0180] After calculating the charges for all CDN vendors, the CDN vendor selection unit 7a The CDN vendor with the lowest delivery cost, i.e., the CDN vendor with the lowest billing amount, is selected (A1930), and the first CDN selection process is terminated. Upon completing the first CDN selection process, the CDN vendor selection unit 7a 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).

[0181] As described above, according to the 19th embodiment, the following advantageous effects can be obtained. The distribution server 7 is configured to refer to the CDN vendor management DB, select the CDN 8 with the most advantageous distribution cost from among multiple CDNs 8 with different distribution costs according to the distribution method, OTA target area, and distribution data size, and place the update package in the selected CDN 8. This makes it possible to appropriately suppress the distribution cost when the OTA master 4 downloads the update package from the OTA center 2.

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

[0183] (First modified example of the 19th embodiment) A first modified example of the 19th embodiment will be described with reference to Figures 194 and 195. The first modified example is configured to use a DNS (Domain Name System) server so that the URL of the CDN server included in the campaign notification delivered to the vehicle-side system 3 is not changed. 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 included in the campaign notification will also change. The campaign notification generation unit 7c needs to access the data storage unit 7b to obtain CDN vendor information every time a campaign notification is generated.

[0184] In contrast, in the first modified example, the DNS setting unit 7e updates the URL and IP address conversion information registered in the DNS, allowing the campaign notification generation unit 7c to always include the same URL in the campaign notification.If the CDN vendor with the lowest delivery cost is changed, the vehicle-side system 3 can access the selected CDN server by changing the information in 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, the first modified example is characterized in that each CDN server has a unique IP address but a common URL.

[0185] 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 mainly describes the differences from the 19th embodiment.

[0186] The DNS server 12 is a server that provides a mechanism for converting domain names and IP addresses. The campaign notification received by the vehicle-side system 3 includes the URL of the CDN server to be accessed to download data. When the vehicle-side system 3 receives the campaign notification, it queries the DNS server 12 about the URL indicated in the received campaign notification. The DNS server 12 either transmits the IP address for the URL received from the query to the vehicle-side system 3, or transfers the connection destination to the address specified by the IP address.

[0187] The DNS setting unit 7e stores the identification information and IP address of the CDN vendor. When the CDN vendor selection unit 7a selects a CDN vendor, the DNS setting unit 7e sends an IP address setting request to the DNS server 12 and sets the registration information in the DNS.

[0188] Next, the operation of the above-described configuration will be explained with reference to FIG. (19-3) Processing of CDN vendor selection unit 7a (see Figure 195) The CDN vendor selection unit 7a ends the first CDN selection process and stores the selection result in the data storage unit 7b (A1914), then 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 receives an IP address query and sends the IP address of the selected CDN server to the vehicle-side system 3.

[0189] The DNS setting unit 7e may acquire information about the DNS server 12 or save the previous setting information for the DNS server 12, and if the CDN server registered in the DNS server 12 differs from the CDN server selected by the CDN vendor selection unit 7a, may send an IP address update request to the DNS server 12. Upon acquiring the selection notification from the CDN vendor selection unit 7a, the campaign notification generation unit 7c generates a campaign notification including a fixed URL.

[0190] According to this configuration, in addition to obtaining the same effects as those of the 19th embodiment, the CDN URL information included in the campaign notification can always be the same, thereby improving security.

[0191] (Second modified example of the 19th embodiment) A second modified example of the 19th embodiment will be described with reference to Figures 196 to 201. Even if a CDN vendor with the lowest update package delivery cost is selected, there is a risk that communication speed may be slowed down due to CDN server maintenance or trouble, access concentration, etc. The inventors of the present application focused on selecting a CDN vendor based on delivery cost and delivery performance.

[0192] In the second variant, when the vehicle-side system 3 queries the DNS server 12 to obtain the IP address corresponding to the URL indicated in the campaign notification, the DNS server 12 checks the delivery status of the CDN server, and if it determines that delivery is not possible, it responds to the vehicle-side system 3 with the IP address of the CDN server with the next lowest delivery cost.

[0193] As shown in FIG. 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 confirmation unit 12a. A test file for measuring the performance of the CDN server is stored in the storage area of ​​the CDN distribution unit 7d. The performance measurement unit 7f sends a test file distribution request to the CDN server, causes the CDN server to distribute the test file, and measures the time required to distribute the test file as the distribution time. The distribution time is, for example, the time from the start of distribution of the test file to the time when the completion of reception of the test file is determined.

[0194] The CDN vendor management DB includes a CDN server selection table as shown in Fig. 197. The selection table includes the cost ranking determined by the CDN vendor selection unit 7a and the delivery flag determined by the performance measurement unit 7f.

[0195] 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 equal to or greater than 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 less than the specified value, sets the delivery flag of that CDN server to off (FALSE).

[0196] When the CDN server confirmation unit 12a receives an inquiry for an IP address corresponding to a URL from the vehicle-side system 3, it determines whether the CDN server specified by the URL is in a state where delivery is possible, and if it determines that delivery is not possible, it responds with the IP address of another CDN server.

[0197] Next, the operation of the above-described configuration will be described with reference to FIGS. 198 to 201. (19-4) Processing of the 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 to A1929) and then determines the cost ranking of the CDN vendors (A1951). That is, the CDN vendor selection unit 7a ranks the CDN vendor with the lowest delivery cost as first, and the CDN vendor with the next lowest delivery cost as second. The CDN vendor selection unit 7a stores the selection results in the data storage unit 7b (A1914), and then stores the cost ranking in the selection table of the CDN vendor management DB (A1941).

[0198] (19-5) Processing of the performance measurement unit 7f (see Figure 200) The performance measurement unit 7f repeats the following process for each CDN vendor (A1961 to A1966). The performance measurement unit 7f executes the following process at regular intervals while the distribution server 7 is running, or at any timing determined by the administrator of the distribution server 7.

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

[0200] If the performance measurement unit 7f determines that the response speed is equal to or greater than a specified value (A1963: YES), it determines that the CDN server is available for delivery and sets the delivery flag to ON (A1964).If the performance measurement unit 7f determines that the calculated response speed is less than a specified value (A1963: NO), it determines that the CDN server is unavailable for delivery and sets the delivery flag to OFF (A1965).

[0201] (19-6) Processing of the CDN server confirmation unit 12a (see Figure 201) The campaign notification includes a URL to be accessed to download the update data. The vehicle-side system 3 queries the DNS server 12 for an IP address to be accessed to download the update package.

[0202] The CDN server confirmation unit 12a receives an inquiry about the IP address of the URL indicated in the campaign notification from the vehicle-side system 3 (A1971). The CDN server confirmation unit 12a inquires about the distribution status of the CDN server indicated in the campaign notification from the CDN vendor management DB of the distribution server 7 (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 confirmation unit 12a receives 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 (A1973). That is, the CDN server confirmation unit 12a determines whether the acquired distribution flag is on or off.

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

[0204] This configuration allows a CDN server that is operating normally to be selected while minimizing delivery costs. The CDN server confirmation unit 12a may access the CDN vendor management DB and request transmission of a selection table at regular intervals. In this case, when an IP address query is received from the vehicle-side system 3, the CDN server confirmation unit 12a may refer to the selection table stored therein instead of accessing the CDN vendor management DB to determine whether the CDN vendor from which data is to be acquired is available. In addition to selecting a CDN server that is operating normally while minimizing delivery costs, communication between the DNS server 12 and the delivery server 7 can be reduced.

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

[0206] The vehicle-side system 3 includes a log transmission unit 3a. Upon completing the download of update data from the CDN server, the log transmission unit 3a transmits log information related to the download, including a download time indicating the time required for the download, 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 identification information of the downloaded package, the data size, and the maximum throughput during the download.

[0207] 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 equal to or greater than a specified value, the performance measurement unit 7f sets the delivery flag of the CDN server to on (TRUE), and if the throughput is less than the specified value, it sets the delivery flag of the CDN server to off (FALSE).

[0208] Next, the operation of the above-described configuration will be described with reference to FIGS. (19-8) Processing of the log transmission unit 3a (see Figure 203) When the log transmission unit 3a has finished downloading the update package from the CDN server (A1981), it transmits log information relating to the download, including the download time indicating the time required for the download, to the distribution server 7 (A1982).

[0209] (19-9) Processing of the performance determination unit 7f (see Figure 204) When the performance determining section 7f receives log information relating to downloading from the log transmitting section 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).

[0210] If the performance measurement unit 7f determines that the calculated throughput is equal to or greater than a specified value (A1993: YES), it determines that the CDN server is available for delivery and sets the delivery flag to ON (A1994).If the performance measurement unit 7f determines that the calculated throughput is less than a specified value (A1993: NO), it determines that the CDN server is unavailable for delivery and sets the delivery flag to OFF (A1995).

[0211] (19-10) Processing of the performance determination unit 7f (see Figure 205) The performance determination unit 7f periodically performs restoration processing for CDN servers whose delivery flags have been set to off. The performance measurement unit 7f notifies the CDN vendor management DB of an information request for CDN servers whose delivery flags have been set to off, identifies CDN servers whose delivery flags have been set to off (A19101), and repeats the following processing for each CDN vendor (A19102 to A19107). While the delivery server 7 is running, the performance measurement unit 7f performs the following processing at regular intervals or at any timing determined by the administrator of the delivery server 7.

[0212] The performance measurement unit 7f notifies the CDN server of the test file delivery request, calculates the throughput from the download time of the file delivered from the CDN server (A19103), and determines whether the calculated throughput is above a specified value (A19104).

[0213] If the performance measurement unit 7f determines that the calculated throughput is equal to or greater than a specified value (A19104: YES), it changes the delivery flag from off to on (A19105).If the performance measurement unit 7f determines that the calculated throughput is less than a specified value (A19104: NO), it maintains the delivery flag as off (A19106).The performance measurement unit 7f may also turn on the delivery flag that is set to off in the CDN vendor management DB when the delivery server system is started or at predetermined intervals.

[0214] According to this configuration, unlike the second modification in which a test file distribution request is sent to the CDN server to identify the CDN server's response, it is not necessary to send a test file distribution request to the CDN server, thereby reducing the load and costs on the communication network. Note that by providing the vehicle-side system 3 with a function for measuring the download speed of the update package, if it is determined that the throughput is below a specified value, the connection may be changed to another CDN server.

[0215] In addition to the URL of the CDN server to be connected first, the campaign notification distributed from the distribution server 7 may also include the URL of a backup CDN server to be connected to if the throughput of the CDN server is low. The backup CDN server may be, for example, the CDN server with the next lowest delivery cost or a predetermined backup CDN server. If multiple CDN servers are specified as backup CDN servers, information indicating the connection order may be added.

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

[0217] (Fourth modified example of the 19th embodiment) A fourth modified example of the nineteenth embodiment will be described with reference to Figures 206 and 207. In the fourth modified example, a CDN vendor selection unit 7a selects multiple CDN vendors, and a 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 adopted to specify different CDN servers.

[0218] (19-11) Processing of the Campaign Notification Generator 7c (see Figure 206) When the campaign notification generation unit 7c acquires CDN vendor information (A195), it generates a campaign notification for each CDN vendor (A19111). That is, the campaign notification generation unit 7c generates two or more campaign notifications for one campaign. The campaign notification generation unit 7c distributes the campaign 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 including the URL of CDN11 to the first vehicle, distributes a campaign notification including the URL of CDN12 to the next vehicle, and distributes a campaign notification including the URL of CDN11 to the vehicle after that.

[0219] (19-12) Processing of CDN vendor selection unit 7a (see Figure 207) In the 19th embodiment, the CDN vendor selection unit 7a selects a 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).

[0220] With this configuration, it is possible to reduce delivery costs from the CDN server while preventing access from concentrating on a specific CDN server, and by preventing access concentration, it is possible to prevent a decrease in throughput.

[0221] (Fifth modified example of the 19th embodiment) A fifth modified example of the nineteenth embodiment will be described with reference to Figures 208 to 211. In the fourth modified example, multiple CDN vendors that reduce delivery costs are selected, multiple campaign notifications with different CDN server information are generated, and the campaign notifications are delivered to the vehicle-side system 3 so that the CDN server is changed in a round-robin manner. In contrast, in the fifth modified example, multiple CDN vendors that reduce delivery costs are selected, one campaign notification is generated, and delivered to the vehicle-side system 3. When the DNS server 12 receives a query for an IP address corresponding to the URL indicated in the campaign notification from the vehicle-side system 3, the CDN server that responds to the vehicle-side system 3 is changed for each vehicle-side system 3. In other words, the DNS server 12 selects a CDN server in a round-robin manner.

[0222] As shown in Fig. 208, the DNS server 12 includes a switching unit 12b. When receiving an IP address query from the vehicle-side system 3, the switching unit 12b sequentially changes the IP address to be sent to the vehicle-side system 3 in a round-robin manner. The distribution server includes a DNS setting unit 7e. The DNS setting unit 7e of the fifth modified example transmits the round-robin record shown in Fig. 209 to the DNS server 12.

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

[0224] (19-14) Processing of the switching unit 12b (see FIG. 211) When the DNS server 12 receives an IP address query from the vehicle-side system 3 (A19141), it refers to the round robin record (A19142) and transmits the IP address corresponding to the listed CDN server to the vehicle-side system 3 (A19143). The DNS server 12 repeats the above process each time it receives an IP address query from the 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 transmits an IP address corresponding to a CDN server different from the previous time to the vehicle-side system 3. That is, the DNS server 12 transmits the IP addresses of the CDN servers to the vehicle-side system 3 in order according to the round robin method.

[0225] With this configuration, it is possible to reduce delivery costs from the CDN server while preventing access from concentrating on a specific CDN server, and by preventing access concentration, it is possible to prevent a decrease in throughput.

[0226] (Twentyth embodiment) The twentieth embodiment will be described with reference to Figures 212 to 224. In the twentieth embodiment, when information on multiple campaigns for a predetermined period can be obtained, multiple CDN vendors are dynamically selected as destinations for distributing update packages to the CDN 8 according to the distribution method, the OTA target area as the distribution area, and the distribution data size, thereby reducing distribution costs. The predetermined period is, for example, the next month.

[0227] In the 19th embodiment described above, a CDN vendor with the lowest delivery cost is selected for one campaign. However, it is also assumed that multiple campaigns scheduled to start delivery over a predetermined period, for example, the next month, are registered from the OEM server. In this way, if information regarding the data size, number of target vehicles, OTA target area, and delivery method for each campaign is acquired in advance, a CDN vendor with the lowest delivery cost may be different from the CDN vendor selected for each campaign as in the 19th embodiment.

[0228] As shown in FIG. 212, the OTA center 2 includes a CDN vendor management DB, a CDN vendor selection unit 7a, a data storage unit 7b, a campaign notification generation unit 7c, a CDN distribution unit 7d, and a progress information management unit 7g. The progress information management unit 7g holds a predicted value indicating how much of a campaign will be distributed to the vehicle-side system 3 within a predetermined period. Even if a campaign is registered in the OTA center 2 and a campaign notification is distributed to the vehicle-side system 3, it is not guaranteed that all vehicles will immediately apply the campaign and download the update package from the CDN server. The progress information management unit 7g stores the predicted value to more accurately predict the data size of the update package 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 be used.

[0229] The calculation method in the 20th embodiment will be described with reference to FIG. 213. In the 20th embodiment, the CDN vendor's billing amount is calculated using three calculation methods, as will be described later. In the first calculation method, a CDN vendor with the lowest delivery cost is selected for each campaign. In this case, a different CDN vendor may be selected for each campaign. FIG. 213 illustrates an example in which CDN1 is selected for campaign 1, CDN2 is selected for campaign 2, and CDN3 is selected for campaign 3.

[0230] In the second calculation method, the total distribution data size of all campaigns is calculated, and a CDN vendor with the lowest distribution cost is selected based on the calculated total distribution data size of all campaigns. In this case, the same CDN vendor is selected for all campaigns. Figure 213 illustrates an example where CDN1 is selected for campaigns 1 to 3. In the third calculation method, the total distribution data size of campaigns for each delivery method is calculated, and a CDN vendor with the lowest distribution cost is selected based on the calculated total distribution data size of campaigns for each delivery method. For each delivery method, a CDN vendor is selected for each of the streaming method and the storage method. Figure 213 illustrates an example where the delivery methods are different between campaign 1 and campaigns 2 and 3, and CDN1 is selected for campaign 1 and CDN2 is selected for campaigns 2 and 3.

[0231] Next, the operation of the above-described configuration will be described with reference to FIGS. (20-1) Processing of the campaign notification generation unit 7c (see Figure 214) The campaign notification generation unit 7c acquires campaign information to be distributed from an external source, such as an OEM server (A201). The campaign information to be distributed includes information on the distribution start date, the data size of the target campaign, the number of vehicles to which the target campaign will be distributed, the region, and the distribution method. The campaign notification generation unit 7c stores the acquired campaign information in the data storage unit 7b (A202).

[0232] The campaign notification generation unit 7c notifies the CDN vendor selection unit 7a of a CDN vendor selection request (A203) and waits for a selection notification from the CDN vendor selection unit 7a. Upon receiving the selection notification from the CDN vendor selection unit 7a (A204), the campaign notification generation unit 7c accesses the data storage unit 7b and acquires the identification information of the CDN vendor selected by the CDN vendor selection unit 7a (A205).

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

[0234] (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 from the campaign notification generation unit 7 (A2011), it accesses the data storage unit 7b, The selection information is acquired (A2012). In this case, the selection information includes the data size of all target campaigns to be distributed, the number of target vehicles, region, distribution method, and distribution start date of each campaign.

[0235] The CDN vendor selection unit 7a obtains a distribution prediction value from the progress information management unit 7g (A2013). The CDN vendor selection unit 7a calculates the distribution data size for each campaign (A2014). Specifically, the CDN vendor selection unit 7a multiplies the campaign data size by the number of vehicles to which the campaign is to be distributed and the distribution prediction value, and then multiplies this by a correction value according to the distribution period. Depending on the campaign, the distribution period may be short, such as when the distribution start date is set to the end of next month, so adjustments are made using a correction value according to the distribution period. For example, if the distribution start date is delayed and the distribution period is only 10 days, then a correction value of 0.3 is set since 10 days out of 30 days are available for distribution.

[0236] The CDN vendor selection unit 7a transitions to the second CDN selection process (A2015). When the CDN vendor selection unit 7a starts the second CDN selection process, it sequentially transitions to the process of calculating the charge amount using the first calculation method, the process of calculating the charge amount using the second calculation method, and the process of calculating the charge amount using the third calculation method (A2021 to A2023).

[0237] In the process of calculating the charge amount using the first calculation method, the CDN vendor selection unit 7a selects a CDN vendor that minimizes the delivery cost for each campaign. After starting the process of calculating the charge amount using the first calculation method, the CDN vendor selection unit 7a repeats the subsequent processes for each campaign (A2031 to A2041) and then for each CDN vendor (A2032 to A2039). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the delivery data size and region information (A2033). The CDN vendor selection unit 7a references the fee information based on the delivery data size and calculates the delivery charge amount (A2034).

[0238] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration charges according to the number of requests and determines the CDN vendor's charge amount (A2035 to A2038). The CDN vendor selection unit 7a repeatedly calculates the delivery charge amount for each CDN vendor and for each campaign. After calculating the charge amounts for all CDN vendors for one campaign, the CDN vendor selection unit 7a selects the CDN vendor with the lowest delivery cost for that campaign (A2040).

[0239] When the CDN vendor selection unit 7a has completed calculating the delivery charge amount and selecting the CDN vendor for all campaigns, it adds up the delivery charge amounts for all campaigns to calculate the total amount (A2042), terminates the process of calculating the charge amount using the first calculation method, and moves on to the process of calculating the charge amount using the second calculation method.

[0240] In the process of calculating the charge amount using the second calculation method, the CDN vendor selection unit 7a selects one CDN vendor based on the total distribution data size of all campaigns scheduled for distribution. When the CDN vendor selection unit 7a starts the process of calculating the charge amount using the second calculation method, it adds up the distribution data sizes of each campaign to calculate the total distribution data size (A2051), and repeats this process for each CDN vendor (A2052 to A2059). The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total distribution data size and region information (A2053). The CDN vendor selection unit 7a references the fee information based on the total distribution data size and calculates the distribution charge amount (A2054).

[0241] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration charges according to the number of requests and determines the charge amount for the CDN vendor (A2055 to 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). The delivery charge amounts for all campaigns scheduled for delivery are added up to calculate the total amount (A2061), ending the process of calculating the charge amount using the second calculation method and proceeding to the process of calculating the charge amount using the third calculation method.

[0242] In the process of calculating 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 process of calculating the charge amount using the third calculation method, it determines whether the delivery methods of the campaigns to be distributed are all the same (A2071). If the CDN vendor selection unit 7a determines that the delivery methods of the campaigns to be distributed are all the same, that is, that all the campaigns to be distributed are streaming method or all storage method (A2071: YES), the process is the same as the process of calculating the charge amount using the second calculation method described above, and therefore ends the process of calculating the charge amount using the third calculation method.

[0243] If the CDN vendor selection unit 7a determines that the distribution methods of the campaigns to be distributed are not all the same, i.e., that the campaigns to be distributed include a mixture of streaming and storage methods (A2071: NO), it groups the campaigns according to the distribution method (A2072), and for the streaming method group, it proceeds to the streaming method billing amount calculation process (A2073), and for the storage method group, it proceeds to the storage method billing amount calculation process (A2074).

[0244] When the CDN vendor selection unit 7a starts the billing amount calculation process for streaming, it calculates the total value of the distribution data size of each campaign distributed by streaming (A2081), and repeats the subsequent process for each CDN vendor (A2082 to A2089).The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total value of the distribution data size and region information (A2083).The CDN vendor selection unit 7a refers to the fee information based on the total value of the distribution data size and calculates the distribution fee (A2084).

[0245] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration charges according to the number of requests and determines the charge amount for the CDN vendor (A2085 to 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 ends the streaming method charge amount calculation process.

[0246] Meanwhile, when the CDN vendor selection unit 7a starts the charge calculation process for the storage method, it calculates the total value of the distribution data size of each campaign distributed using the storage method (A2091), and repeats the subsequent process for each CDN vendor (A2092 to A2099).The CDN vendor selection unit 7a acquires fee information from the CDN vendor management DB based on the total value of the distribution data size and region information (A2093).The CDN vendor selection unit 7a refers to the fee information based on the total value of the distribution data size and calculates the distribution charge amount (A2094).

[0247] As in the 19th embodiment, the CDN vendor selection unit 7a determines whether the CDN vendor under consideration charges according to the number of requests and determines the charge amount for the CDN vendor (A2095 to 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 ends the charge amount calculation process using the storage method.

[0248] After the CDN vendor selection unit 7a has completed the process of calculating the charge amount using the first calculation method, the process of calculating the charge amount using the second calculation method, and the process of calculating the charge amount using the third calculation method, it determines the calculation method that minimizes the delivery cost (A2024), selects a CDN vendor for each campaign (A2025), and ends 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 identifying the selected CDN vendor, in the data storage unit 7b (A2016). Here, the CDN vendor selection unit 7a stores identification information identifying the CDN vendor of the campaign to be delivered in the data storage unit 7b. The CDN vendor selection unit 7a then notifies the campaign notification generation unit 7c of the selection (A2017).

[0249] (20-3) Processing of 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 distributed to the vehicle-side system 3 in a predetermined period. This predicted value is expected to be updated according to the actual distribution status transmitted from the OEM server.

[0250] The progress information management unit 7g acquires 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 equal to or greater than 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 equal to or greater than the predetermined value (A20112: NO), the process ends.

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

[0252] (20-4) Processing of CDN vendor selection unit 7a (see Figure 223) When the CDN vendor selection unit 7a receives an update to the predicted value notified from the progress information management unit 7g (A20121), it acquires selection information (A20122), acquires a distribution predicted value from the progress information management unit 7g (A20123), and calculates the distribution data size for each campaign (A20124). In this case, when calculating the distribution data size, the CDN vendor selection unit 7a uses an adjusted value that takes the number of distribution days into consideration.

[0253] The CDN vendor selection unit 7a proceeds to the second CDN selection process (A20125), and upon completing the second CDN selection process, determines whether 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 results 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 results (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 the predicted values ​​stored in the progress information management unit 7g have been changed.

[0254] (20-5) Processing of the Campaign Notification Generator 7c (See Figure 224) When the campaign notification generation unit 7c receives the CDN change notification from the CDN vendor selection unit 7a (A20131), it accesses the data storage unit 7b, obtains the updated CDN vendor information (A20132), and regenerates the campaign notification to be distributed based on the obtained updated CDN vendor information (A20133).

[0255] As described above, according to the twentieth embodiment, the following advantageous effects can be obtained. The CDN vendor management database is referenced, and the CDN 8 with the most advantageous delivery cost is selected from among multiple CDNs 8 with different delivery costs according to the delivery method, OTA target area, and delivery data size, and the update package is then placed on the selected CDN 8. This makes it possible to appropriately suppress the delivery cost when the OTA master 4 downloads the update package from the OTA center 2.

[0256] (Other embodiments) In the above-described embodiments, embodiments that are not specifically described as being based on the streaming method or the storage method can be applied to either the streaming method or the storage method.

[0257] In some of the above-described embodiments, it is described that the campaign notification is transmitted from the OTA center 2 to the OTA master 4 after TLS communication is established. However, in all embodiments, the campaign notification may be transmitted from the OTA center 2 to the OTA master 4 after TLS communication is established. Establishing TLS communication can further enhance security. Alternatively, the campaign notification may be transmitted from the OTA center 2 to the OTA master 4 without establishing TLS communication.

[0258] 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 a CAN (registered trademark) bus.

[0259] Some or all of the functions of the OTA master 4 may be implemented in the CGW. As an example, the DCM may communicate data with external parties such as the CDN 8 and the OTA center 2, and all of the functions of the OTA master 4 may be implemented in the CGW. In this case, the DCM transfers all data received via wireless communication with the external party to the CGW. Alternatively, in addition to communicating data with the external party, the DCM may also function as a downloader for the OTA master 4. Examples of the downloader functions include generating vehicle configuration information, verifying metadata, verifying packages, and verifying campaign information. Alternatively, the functions of the OTA master 4 may be implemented in the DCM. In this case, functions other than those of the OTA master 4 are implemented in the CGW. Alternatively, the DCM and CGW may be integrated.

[0260] The CGW may have some or all of the functions of the DCM, or the DCM may have some or all of the functions of the CGW. That is, the division of functions between the DCM and CGW may be configured in any way in the OTA master 4. The OTA master 4 may be configured with two ECUs, a DCM and a CGW, or may be configured with one integrated ECU that has the functions of the DCM and the CGW.

[0261] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and equivalent modifications. In addition, various combinations and forms, including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

[0262] The means and functions provided by each device can be provided by software recorded in a physical memory device and a computer that executes the software, software alone, hardware alone, or a combination of these. 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 an analog circuit.

[0263] The control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to perform one or more functions embodied in a computer program. Alternatively, the control unit and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Furthermore, the control unit and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to perform one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.

Claims

1. A data communication system comprising: a center device (2) that distributes update data to a master device; and a master device (4) that installs the update data downloaded from the center device into an electronic control device to be reprogrammed, the center device and the master device employ a Diffie-Hellman key agreement (DHE) or an elliptic curve Diffie-Hellman key agreement (ECDHE) algorithm; the center device shares secret information with the master device by using a random number common to each vehicle model or each vehicle group as a secret key used in the DHE or ECDHE algorithm, uses the shared secret information as an encryption key, encrypts update data based on the encryption key, and places the encrypted update data on a content delivery network (CDN); A data communication system in which the master device shares secret information with the center device using a random number according to specific rules as a secret key used in the DHE or ECDHE algorithm, downloads and obtains encrypted update data from a CDN, decrypts it using the encryption key, transfers the decrypted update data to the electronic control device to be reprogrammed, and installs the update data into the electronic control device.

2. 2. The data communication system according to claim 1, wherein the master device uses a specific rule for the secret key used in the DHE or ECDHE algorithm, which rule is one of a fixed value for each vehicle model, a count-up value, or a hash value of the software version of the master device, or a combination of these.

3. 3. The data communication system according to claim 1, wherein the center device adds a digital signature by public key cryptography to a key transmitted to the center device in DHE or ECDHE key sharing.

4. 4. The data communication system according to claim 3, wherein the center device uses a digital signature using an encryption algorithm such as RSA or elliptic curve DSA as the digital signature.

5. A center device (2) that distributes update data to a master device, A center device employs a Diffie-Hellman key exchange (DHE) or an elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm, shares secret information with the master device using a common random number for each vehicle model or each vehicle group as a secret key used in the DHE or ECDHE algorithm, uses the shared secret information as an encryption key, encrypts update data based on the encryption key, and places the encrypted update data on a content delivery network (CDN).

6. A master device (4) that installs update data downloaded from a center device into an electronic control device to be reprogrammed, A master device that adopts the Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm, shares secret information with the center device using random numbers according to specific rules as a secret key used in the DHE or ECDHE algorithm, downloads and obtains encrypted update data from a CDN, decrypts it using the encryption key, transfers the decrypted update data to the electronic control device to be reprogrammed, and installs the update data in the electronic control device.

7. A center device (2) that distributes update data to the master device, a secret information sharing procedure in which a Diffie-Hellman key exchange (DHE) or an Elliptic Curve Diffie-Hellman key exchange (ECDHE) algorithm is adopted, and secret information is shared with the master device using a random number common to each vehicle model or each vehicle group as a secret key used in the DHE or ECDHE algorithm; A secret information sharing program that executes the steps of using the shared secret information as an encryption key, encrypting update data based on the encryption key, and placing the update data encrypted with the encryption key on a content delivery network (CDN).

8. A master device (4) that installs the update data downloaded from the center device into the electronic control device to be reprogrammed. A secret information sharing program that employs a Diffie-Hellman key exchange (DHE) or elliptic curve Diffie-Hellman key exchange (ECDHE) algorithm, shares secret information with the center device using a random number according to specific rules as a secret key used in the DHE or ECDHE algorithm, downloads and obtains encrypted update data from a CDN, decrypts it using an encryption key, transfers the decrypted update data to an electronic control device to be reprogrammed, and installs the update data into the electronic control device.

Images