CENTER DEVICE, VEHICLE SIDE SYSTEM, CONTENT PROTECTION METHOD, AND CONTENT PROTECTION PROGRAM

Abstract

In one embodiment of the present disclosure, an OTA center 1 comprises a content key generating function unit 5 that generates a content key Kc for protecting paid content, and a user key generating function unit 6 that generates a user key Ku associated with a user of the paid content. A content encryption unit encrypts content using the content key Kc, and a content key encrypting function unit 10 encrypts the content key Kc using a device key Kd associated with each vehicle. A file encrypting function unit 8 uses the user key Ku to encrypt a license file containing at least a condition for using the paid content.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2021-129943 filed on August 6, 2021, the contents of which are incorporated herein by reference. [Technical field]

[0002] The present disclosure relates to a center device that distributes content to a vehicle, a vehicle-side system that communicates with the center device, a content protection method, and a content protection program. [Background technology]

[0003] In recent years, with the diversification of vehicle control such as driving assistance functions and automatic driving functions, the scale of application programs such as vehicle control and diagnosis mounted on the vehicle's electronic control unit (hereinafter referred to as ECU (Electronic Control Unit)) is increasing. In addition, with version upgrades for function improvements and the like, there are also increasing opportunities to rewrite ECU application programs, that is, to perform so-called reprogramming. Meanwhile, with the development of communication networks, connected car technology is also becoming widespread. In light of these circumstances, for example, Patent Document 1 discloses a technology in which an ECU update program is delivered from a server to an in-vehicle device by OTA (Over The Air) and the update program is rewritten on the vehicle side.

[0004] In addition to update programs, digital content that users can use for a fee is also distributed to devices by OTA. Content that is subject to usage restrictions as described above is called paid content. In currently operated systems, all software is distributed to vehicles, regardless of whether it is paid content or not. A user who uses paid content activates a charging flag managed by the center that distributes the content by paying through a specified procedure. A vehicle to which paid content has been distributed then inquires of the center, and if the charging flag is activated, the paid content becomes available for use. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2020-27624 A Summary of the Invention

[0006] In the current system, it is assumed that an inquiry about the charging status is made to the center, so unless the vehicle is in a state where it can communicate with the center, it is not possible to make the charged content available.

[0007] The present disclosure has been made in consideration of the above circumstances, and its purpose is to provide a center device that can make content that is subject to usage restrictions available in a more flexible manner, a vehicle-side system that communicates with the center device, a content protection method, and a content protection program.

[0008] According to the center device of claim 1, the content key generation unit generates a content key for protecting content that can be restricted when used, and the user key generation unit generates a user key corresponding to a user of the content. The content encryption unit encrypts the content using the content key, and the content key encryption unit encrypts the content key using a device key corresponding to each vehicle. Then, the file encryption unit encrypts a license file including at least conditions for using the content using the user key.

[0009] Therefore, the center device can flexibly and reliably protect the content that is subject to usage restrictions. In addition, by using the license file, the conditions for using the content can be flexibly set. In addition, the vehicle can use the content even if it is not able to communicate with the center device. In addition, the compressed file generator generates a compressed file that includes the encrypted license file and the encrypted license key.

[0010] Therefore, the center device can flexibly and reliably protect the content that is subject to usage restrictions. In addition, by using the license file, the conditions for using the content can be flexibly set. In addition, the vehicle can use the content even if it is not able to communicate with the center device. In addition, the compressed file generator generates a compressed file that includes the encrypted license file and the encrypted license key.

[0011] According to the center device described in claim 2, the user key encryption unit encrypts the user key using the device key, so that the content is protected by three keys, thereby further improving the level of protection of the content.

[0012] According to the center device of claim 3, the license file includes the permission conditions for using the content, the content key encrypted using the device key, and the identification information for identifying the content. Thus, by decrypting the license file using the user key, the permission conditions for using the content can be confirmed. Then, by decrypting the content key using the device key after satisfying the permission conditions, the content corresponding to the identification information can be decrypted using the key.

[0013] According to the center device of claim 4, the license file further includes encryption parameters, which are information for performing encryption. This makes it possible to obtain detailed information about encryption performed using each key from the license file. [Brief description of the drawings]

[0014] 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 functional block diagram illustrating a first embodiment, focusing on an OTA center. [Diagram 2] FIG. 2 is a functional block diagram mainly showing the vehicle-side system. [Diagram 3] FIG. 3 is a diagram for explaining a usage case of billable content. [Figure 4] FIG. 4 is a diagram conceptually illustrating the process performed by the OTA center. [Diagram 5] FIG. 5 is a diagram conceptually illustrating the processing performed between the OTA center, the OTA master, and the target ECU. [Figure 6] FIG. 6 is a flowchart showing a process performed by the OTA center. [Figure 7] FIG. 7 is a diagram showing an example of encryption parameters; [Figure 8] FIG. 8 is a diagram showing an example of repro policy metadata. [Figure 9] FIG. 9 is a diagram showing an example of download metadata corresponding to a storage method. [Figure 10] FIG. 10 is a diagram showing an example of download metadata corresponding to a streaming method. [Figure 11] FIG. 11 is a flowchart showing a process performed by the OTA master. [Figure 12] FIG. 12 is a flowchart (part 1) showing the process performed by the target ECU. [Figure 13] FIG. 13 is a flowchart (part 2) showing the process performed by the target ECU. [Figure 14] FIG. 14 is a functional block diagram showing the OTA center in the second embodiment. [Figure 15] FIG. 15 is a functional block diagram mainly showing the vehicle-side system. [Figure 16] FIG. 16 is a diagram conceptually illustrating the processing performed among the OTA center, the OTA master, and the target ECU. [Figure 17] FIG. 17 is a flowchart showing a process performed by the OTA center. [Figure 18] FIG. 18 is a flowchart showing a process performed by the OTA master. [Figure 19]FIG. 19 is a functional block diagram mainly showing a vehicle-side system in the third embodiment. [Figure 20] FIG. 20 is a diagram conceptually illustrating the processing performed between the OTA center, the OTA master, and the target ECU. [Figure 21] FIG. 21 is a flowchart showing a process performed by the OTA center. [Figure 22] FIG. 22 is a flowchart showing a process performed by the OTA master. [Figure 23] FIG. 23 is a flowchart showing the processing performed by the target ECU. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] (First embodiment) As shown in Fig. 1, an OTA center 1 in this embodiment, which is a center device, includes a PKG generation server 2 and a distribution server 3. The PKG generation server 2 is roughly divided into a functional part that generates keys used for encryption, data packages, etc., and a functional part that performs encryption and signing. The former includes a license file generation functional unit 4, a content key generation functional unit 5, a user key generation functional unit 6, and a PKG generation functional unit 7. The latter includes a content encryption functional unit 8, a license file encryption functional unit 9, a content key encryption functional unit 10, and a user key encryption functional unit 11. It should be noted that "PKG" means "package."

[0016] The content key generation function unit 5 generates a content key Kc corresponding to an ID, which is identification information of the chargeable content, for example, by using a random number. Hereinafter, the chargeable content will be referred to as "chargeable content". The user key generation function unit 6 generates a user key Ku corresponding to the user of the chargeable content, for example, by using a random number. The license file generation function unit 4 generates a license file that stores the ID of the chargeable content, the content key Kc, and the license conditions for using the chargeable content. The PKG generation function unit 7 generates a distribution package that includes the encrypted chargeable content, etc. Note that one way of restricting the use of the content is to require that the content be charged when the content is used by a user.

[0017] Chargeable content may be content itself that is charged for, or may be content that is charged for only a part of the content, such as in-content charging. Note that content refers to, for example, an app, data used by the app, or a service provided to a passenger via the app. Thus, content refers to, for example, videos and music viewed in the vehicle cabin, game apps, vehicle control apps related to vehicle control, map data, navigation apps, and service usage rights.

[0018] The content encryption function unit 8 encrypts billing content using a content key Kc in accordance with a predetermined encryption method. The content key encryption function unit 10 encrypts the content key Kc using a device key Kd. The user key encryption function unit 11 encrypts the user key Ku using the device key Kd. The license file encryption function unit 9 encrypts the license file using the user key Ku.

[0019] The distribution server 3 includes a distribution management function unit 12, a campaign management function unit 13, a software management function unit 14, and a device unique key management function unit 15. The device unique key management function unit 15 manages a device key Kd that is uniquely assigned in correspondence with identification information given to each vehicle, such as a VIN (Vehicle Identification Number). The software management function unit 14 manages software such as billable content together with an ID. The campaign management function unit 13 manages campaign information, which is information related to program updates including billable content, etc. The distribution management function unit 12 distributes distribution packages, etc. generated by the PKG generation function unit 7 to an OTA master 22 on the vehicle side via a communication carrier, a CDN (Contents Delivery Network) 21, etc.

[0020] 2, the vehicle-side system 23 includes an OTA master 22 and a target ECU 24. The OTA master 22 includes a DCM (Data Communication Module) 22A shown in FIG. 3 that communicates with the distribution server 3 and the like, and a central ECU 22B that communicates with the target ECU 24. The OTA master 22 includes a download function unit 25, an unpack function unit 26, a license file decryption function unit 27, a user key decryption function unit 28, a content key decryption function unit 29, and a device unique key management function unit 30.

[0021] The download function unit 25 downloads data files, packages, etc. by communicating directly with the distribution server 3 of the OTA center 1 or via the CDN 21. If the received data package is a compressed file, the unpack function unit 26 decompresses it and extracts the necessary data. A device key Kd corresponding to the vehicle's VIN is written in the device unique key management function unit 30 at the manufacturing stage. The user key decryption function unit 28 decrypts the user key Ku using the device key Kd. The license file decryption function unit 27 decrypts the license file using the user key Ku. The content key decryption function unit 29 decrypts the content key Kc using the device key Kd.

[0022] The OTA master 22 transfers the encrypted data package including the content and the license file to the target ECU 24. There is one or more target ECUs 24, each of which includes a content decryption function unit 31 and a license condition check function unit 32. The license condition check function unit 32 checks whether the license conditions of the content included in the license file are met. When the license conditions are met, the content decryption function unit 31 decrypts the content using the content key Kc included in the license file. Each of the functional blocks in the OTA center 1 and the OTA master 22 described above is realized by cooperation between computer hardware and software.

[0023] There is no particular restriction on how the functions of the functional units of the OTA master 22 are shared between the DCM 22A and the central ECU 22B. The central ECU 22B may have a part or all of the functions of the OTA master 22, or the DCM 22A may have a part or all of the functions of the OTA master 22. That is, in the OTA master 22, the functions of the DCM 22A and the central ECU 22B may be shared in any manner. The OTA master 22 may be composed of two ECUs, the DCM 22A and the central ECU 22B, or may be composed of one integrated ECU having the functions of the DCM 22A and the central ECU 22B.

[0024] As shown in Fig. 3, when a user uses charged content, the user communicates with charging processing center 33 via an HMI (Human Machine Interface) of a smartphone or vehicle-side system 23. Charge processing center 33 includes a charging system 34, a member information database 35, a vehicle information database 36, etc. When the user completes the procedure to purchase charged content, the user selects a method for downloading the charged content. For example, the user selects whether to download the charged content to OTA master 21, or to a smartphone or SD card. The SD card corresponds to an example of an external storage medium.

[0025] The billing processing center 33 transmits the ID of the billing content purchased by the user and the VIN of the corresponding vehicle to the OTA center 1. The OTA center 1 encrypts the billing content and license file as described above, and downloads them to the vehicle-side system 23 if the download method is "OTA." The "network carrier" in the figure includes cases where communication is performed directly with the distribution server 3 or via the CDN 21. In the figure, the OTA master 22 is shown as a DCM 22A and a C-ECU 22B.

[0026] In the OTA center 1, when the billing processing center 33 receives the ID of the billing content purchased by the user and the VIN of the corresponding vehicle, it encrypts the billing content and the license file. In addition, the PKG generation server 2 sends a push notification to, for example, the DCM 22A of the vehicle side system 23. The DCM 22A is configured to be able to receive the push notification even when the ignition is turned off. Therefore, the DCM 22A receives the push notification from the OTA center 1 regardless of the ignition state. This push notification triggers the OTA master 22 to synchronize the vehicle configuration information with the OTA center 1.

[0027] As shown in Fig. 4, the license file generated at the OTA center includes a content key Kc encrypted with a device key Kd, an ID of the charged content, license conditions, and encryption parameters. The license conditions include, for example, that the charging process has been completed, the usage period of the charged content, the remaining number of times it can be used, and that transfer to other vehicles is not possible. The encryption parameters shown in Fig. 7 are parameters related to encryption and digital signatures. The encryption parameters include encryption parameters related to the content key Kc and encryption parameters related to the user key Ku. · Encryption type information: (shared key) AES (Advanced Encryption Standard), Triple-DES(Data Encryption Standard), (Public key) RSA (Rivest-Shamir-Adleman cryptosystem), ECC (Elliptic Curve Cryptography) Signature type information: (shared key) CBC-MAC (Message Authentication Code),CMAC(Common MAC) (Public key) DSA (Digital Signature Algorithm), ECDSA (Elliptic Curve DSA) Key ID information: Used to identify the key · Encryption mode type information: Enc (Encrypt) then MAC, MAC then, ENC - Information to be protected: Specify specific files or data -Protection area designation information: Designates the whole or part of the above file - Offset size information: Specifies the number of bytes from the beginning to be protected -Protection data size information: Specify how many bytes to protect

[0028] Next, the operation of this embodiment will be described. As shown in Fig. 6, the PKG generation server 2 of the OTA center 1 generates a content key Kc corresponding to the ID of the content to be charged using random numbers (S1), and encrypts the charged content using the content key Kc according to a predetermined encryption method (S2). The file name of the encrypted charged content is Contents.zip. Next, the device key Kd is obtained from the distribution server 3 (S3), and the content key Kc is encrypted using the device key Kd (S4). The encrypted content key Kc is designated as Kcd.

[0029] Next, when a file describing the license conditions for the billable content is obtained from the software management function unit 14 of the distribution server 3 (S5), a license file including encryption parameters, a content key Kcd, a content ID, and the license conditions is generated (S6). When a user key Ku is generated using random numbers (S7), the license file is encrypted using the user key Ku (S8), and the user key Ku is encrypted using the device key Kd (S9). The encrypted user key Ku is called Kud. The encrypted license file and the user key Kud are then archived (S10). The file name is called Licence.zip.

[0030] Then, a parameter indicating that the distribution package of the target layer is billable content is embedded in the repro policy metadata (S11), and URI (Uniform Resource Identifier) ​​information for downloading the billable content file Contents.zip and URI information for downloading the license file Licence.zip are embedded in the download metadata (S12).

[0031] Here, the repro policy metadata and the download metadata will be described. Hereinafter, the former will be referred to as RP metadata, and the latter as DL metadata. The RP metadata is information including configuration information of the distribution package, in other words, information indicating the configuration type of the package, and is information that mainly aims to prevent package distribution errors by checking the contents of the data on the vehicle side. The DL metadata stores control information for acquiring data, in other words, information that specifies the contents for allowing the OTA master 22 to grasp information for downloading update data for each of the multiple target ECUs 24. By making these metadata into a three-layer structure of distribution, master, and target, even if the transfer method, platform type, and types of distribution packages increase, they can be flexibly defined and dealt with, and data updates for the target device can be performed.

[0032] <Reproduction Policy Metadata> The RP metadata shown in FIG. 8 is transmitted from the OTA center 1 to the OTA master 22 prior to downloading of the distribution package. <RPメタデータバージョン> This is the version of the RP metadata. For example, version information such as "1.0.0" or "2.0.0" is stored.

[0033] <Communication Layer> The protocol used for communication with the OTA center 1, such as Uptane (registered trademark) or OMA-DM (Open Mobile Alliance-Device Management), information indicating the communication means is the OTA master 22, "Cellular", and other information such as a smartphone or USB memory as described below, are stored.

[0034] <Master Layer> For the OTA master 22, information is stored indicating that its platform (PF) is, for example, AP, CP, AGL (Automotive Grade Linux), Android (registered trademark), etc. Regarding the package structure for distributing update programs according to the ECU platform, the specifications of the general incorporated association JASPAR prescribe data requirements applicable to classic platforms (CPs) that run 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.

[0035] Here, we will explain the difference between AP and CP. AP and CP stand for software platform. Software platform is also called software architecture. CP stands for AUTOSAR Classic Platform, and AP stands for AUTOSAR Adaptive Platform. Furthermore, an ECU that operates in accordance with the CP specification is sometimes referred to as a CP ECU or CP ECU, and an ECU that operates in accordance with the AP specification is sometimes referred to as an AP ECU or AP ECU.

[0036] AP and CP use different operating systems, or OS, and development languages. CP ECUs and AP ECUs have different package structures that they can receive. These differences in package structure are mainly due to differences in the processing performance of the ECUs. Since the processing performance of CP ECUs is generally low, the specification data included in the packages is written as binary data, and the package data structure is easy to interpret and process even for ECUs with low processing performance.

[0037] On the other hand, since AP ECUs have high processing power, they can be equipped 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.The data structure can be a flexible package data structure, as it can use an object-oriented data format such as JSON (JavaScript Object Notation) rather than simple binary data.

[0038] Regarding the control method, information such as "parameters" that process according to parameters set according to a specific format, and "scripts" that process in a more free description format without a specific format is stored.

[0039] <Target Layer> This is information corresponding to the target ECU 33. The PF and control method are the same as those described above. The transfer method is either storage or streaming. The billing method indicates whether the use of the content is free or charged. The target ID is an ID corresponding to the target ECU 24, but storing it here is optional.

[0040] <Download Metadata> 9 and 10 are transmitted from the OTA center 1 to the OTA master 22 following the RP metadata. The cases where the transfer method is storage and streaming are shown, respectively.

[0041] <Distribution Layer> For example, if the communication protocol is Uptane, this is information for acquiring Uptane metadata, and the corresponding URI, data name, data size, hash value, target ID, transfer method, etc. are stored.

[0042] <Master / Target Layer> In the case of the streaming method shown in Figure 10, the master layer is information for acquiring the license file Licence.zip, and the target layer is information for acquiring the content file Contents.zip. On the other hand, in the case of the storage method shown in Figure 9, the target layer is not required because information for acquiring both files is embedded in the master layer. A target layer may be provided, but the information will be null or blank. Each item is the same as the distribution layer. Note that some items have "xxx" or "zzz" written multiple times, but these do not indicate the same value.

[0043] Referring again to Fig. 6, the distribution server 3 receives the Contents.zip file, the Licence.zip file, the DL metadata and the RP metadata from the PKG generation server 2 (S13). Note that the Licence.zip file is different for each vehicle, but the other files and data are common to all vehicle models. Next, the distribution server 3 stores the Contents.zip file, the DL metadata and the RP metadata in a server connected to the CDN 21 (S14).

[0044] Then, when a notification for synchronizing the vehicle configuration information is received from the OTA master 22, it is identified from the VIN that the corresponding vehicle is a target for distribution of billable content (S15). The vehicle configuration information is identification information related to the hardware and software of the ECU mounted on the vehicle, and also includes identification information of the system configuration consisting of multiple ECUs and identification information of the vehicle configuration consisting of multiple systems. The "notification for synchronization" is a notification sent to match the contents of the configuration information held on the vehicle side with the contents of the configuration information held on the OTA center 1 side, that is, to synchronize them.

[0045] For example, the OTA master 22 checks the time that has elapsed since the vehicle configuration information was synchronized with the OTA center 1 when the ignition was turned on, and if a predetermined period of time has elapsed, determines that the vehicle configuration information needs to be synchronized with the OTA center 1. Alternatively, the OTA master 22 checks whether a push notification has been received from the OTA center 1, and if a push notification has been received, determines that the vehicle configuration information needs to be synchronized with the OTA center 1. In these cases, the OTA master 22 requests the ECU mounted on the vehicle to transmit the vehicle configuration information to the OTA master 22. The OTA master 22 notifies the OTA center 1 of the collected vehicle configuration information.

[0046] The OTA center 1 is notified of and stores the ID of the charged content purchased by the user and the VIN of the corresponding vehicle from the charging processing center 33. In addition, the OTA center 1 is notified of and stores the VIN of the vehicle that is the target of software update for software other than the charged content, also called non-chargeable content, from an OEM server (not shown). In S15, it is determined based on the VIN whether (1) the non-chargeable content has been updated, (2) the charged content has been updated, (3) the charged content and the non-chargeable content have been updated, or (4) there has been no update. In this disclosure, only the case where the charged content has been updated will be described.

[0047] Then, when a campaign notification, which is information about program updates to be displayed on the vehicle-side system 23 and the user's smartphone, is distributed to the target vehicle, the URI information of the DL metadata and the RP metadata is embedded in the notification (S16). If there is access from the target vehicle, the Licence.zip file is transmitted to the vehicle (S17). The user key Ku and the content key Kc may be erased, for example, in step S14.

[0048] 11, when the OTA master 22 receives a campaign notification from the distribution server 3 of the OTA center 1 (S21), it acquires RP metadata from the CDN 21 according to the URI information described in the campaign notification and checks whether the package scheduled for distribution contains billable content (S22). If billable content is not included (S23; NO), the OTA master 22 updates the software for the target ECU 24 (S33) according to the method disclosed in, for example, Japanese Patent Application No. 2021-32593.

[0049] On the other hand, if billing content is included (S23; YES), the Licence.zip file is obtained from the distribution server 3 (S24), and the Licence.zip file is decompressed to extract the encrypted license file and the user key Kud (S25). The user key Kud is then decrypted with the device key Kd held by the OTA master 22 to extract the user key Ku (S26). The encrypted license file is then decrypted using the user key Ku (S27).

[0050] Next, the content key Kcd included in the license file is decrypted with the device key Kd to extract the content key Kc (S28), and the content key Kcd in the license file is replaced with the content key Kc (S29). Here, the content key Kcd in the license file is overwritten with the content key Kc. Then, the DL metadata and the Contents.zip file are acquired from the CDN 21 (S30, S31), and the target ECU 24 to which the content is to be distributed is identified from the DL metadata. The target ECU 24 is notified that the software to be updated is chargeable content, and the Contents.zip file and the license file are transferred (S32).

[0051] Instead of step S41, the reception of the Contents.zip file and the license file from the OTA master 22 may be treated as a notification from the OTA master 22 that the software to be updated is a charged content. In this case, when the target ECU 24 receives the Contents.zip file and the license file from the OTA master 22, the target ECU 24 determines that the software includes a charged content and performs the processes from step S42 onward.

[0052] As shown in FIG. 12, the target ECU 24 determines whether or not it has received a notification from the OTA master 22 that the software to be updated is chargeable content (S41). If it has not received a notification (NO), it updates its own software (S46) according to the method disclosed in Japanese Patent Application No. 2021-32593, for example. On the other hand, if it has received the notification (S41; YES), it receives a Contents.zip file and a license file from the OTA master 22 (S42). Then, it extracts the content key Kc from the license file and decrypts the chargeable content with the content key Kc (S43).

[0053] Next, the license conditions included in the license file are read, and it is determined whether or not the conditions are met (S44). If the license conditions are met (YES), the installation process for the charged content is executed (S45). If the license conditions are not met (NO), an error response is returned to the OTA master 22 indicating that the license conditions are not met (S47). The license conditions include, for example, that the charging process has been completed, the usage period of the charged content, and the remaining number of times it can be used. There may be one license condition or multiple license conditions. If there are multiple license conditions, all of the license conditions must be met. However, it may be possible to use the charged content if at least one license condition is met.

[0054] As shown in Fig. 13, when the target ECU 24 launches an application of the installed billable content, it checks whether the license conditions are met at that point in time (S48). If the license conditions are met (YES), the application is launched and executed as is (S49). If the license conditions are not met (NO), the same process as in step S47 is performed (S50).

[0055] For convenience of explanation, the number of target ECUs 24 is one, but if there are multiple target ECUs 24, similar processing may be performed for each target ECU 24. The same applies to the following embodiments. If there are multiple target ECUs 24, information on the multiple target ECUs 24 is described in the RP metadata and DL metadata.

[0056] As described above, according to this embodiment, in the OTA center 1, the content key generation function unit 5 generates a content key Kc for protecting charged content, and the user key generation function unit 6 generates a user key Ku corresponding to the user of the charged content. The content encryption unit encrypts the content using the content key Kc, and the content key encryption function unit 10 encrypts the content key Kc using a device key Kd corresponding to each vehicle. Then, the file encryption function unit 8 encrypts a license file including at least the conditions for using the charged content using the user key Ku. The content key Kc and the user key Ku are deleted without being stored in the OTA center 1.

[0057] With this configuration, the OTA center 1 only needs to manage the device key Kd corresponding to each vehicle, so the number of keys to be managed is reduced. Furthermore, the charged content is protected by the content key Kc, and in order to use the content key Kc, a user key Ku linked to the content user and a device key Kd linked to each vehicle are required, so that the charged content is protected by three keys. When the charged content is to be used on the vehicle side, a procedure for satisfying the usage conditions is carried out in advance, and the vehicle side can sequentially perform the necessary decryption using the device key Kd.

[0058] Therefore, the OTA center 1 can flexibly and reliably protect billing content. Furthermore, by using a license file, conditions for using content can be flexibly set. In addition, even if the vehicle is not in a state where communication with the OTA center 1 is possible, the content can be used by obtaining the content via a smartphone, for example. Furthermore, the user key encryption function unit 11 encrypts the user key Kc using the device key Kd, thereby further improving the protection level of the content.

[0059] The license file includes the license conditions for using the charged content, the content key Kc encrypted using the device key Kd, and the ID of the charged content. Thus, by decrypting the license file using the user key Ku, the license conditions for using the charged content can be confirmed. If the license conditions are satisfied and the content key Kc is decrypted using the device key Kd, the charged content can be decrypted using the key Kc. Furthermore, since the license file includes encryption parameters, detailed information regarding the encryption performed using each key can be obtained from the license file.

[0060] Furthermore, when the unpacking function unit 26 of the OTA master 22 receives the Licence.zip file, it unpacks the file and extracts the encrypted license file and the user key Kud. The user key decryption function unit 28 uses the device key Kd to decrypt the user key Ku from the user key Kud. The license file decryption function unit 27 uses the user key Ku to decrypt the license file. The content key decryption function unit 29 uses the device key Kd to decrypt the content key Kc included in the license file. Then, when the Contents.zip file is received, it transfers the file and the license file including the content key Kc to the target ECU 24.

[0061] The target ECU 24 decrypts the charged content using the content key Kc, whereby the vehicle system 23 performs the necessary decryption, and the charged content can be used in the target ECU 24.

[0062] It is also expected that the vehicle-side system will support SOTA (Software OTA). With SOTA, for example, when multiple applications such as a navigation app (ver1.0), a game app (ver2.0), and a video app (ver3.5) are installed on one ECU, each application will be able to be updated individually. For example, if the paid content app is an agent service app (ver1.0), it will be possible to update only the agent app (ver1.0 to ver2.0) for paying users only.

[0063] It is also possible to check whether the license file has been tampered with depending on attributes such as the economic value of the charged content. It is also possible to check whether the license file has been tampered with. Alternatively, it is also possible to check whether some items such as the license conditions of the license file have been tampered with. For example, the OTA center 1 calculates a MAC value from data to be checked for tampering and inserts the calculated MAC value together with the license file or into the license file. The target ECU 24 may also calculate a MAC value and check whether the MAC value has been tampered with by comparing it with the MAC value provided by the OTA center 1. This makes it possible to prevent a malicious third party from tampering with the license conditions and allowing the charged content to be used even if the license conditions are not satisfied.

[0064] By combining the method of this embodiment with SOTA, for example, the following can be realized. Suppose vehicle A has contracted for contents A and B, and vehicle B has contracted for content C. When generating a package at the OTA center, content A (navigation application), content B (game application), and content C (video application) are combined into one package. At this time, contents A to C are encrypted with content keys A to C, respectively. The package is common to all vehicle models, and multiple vehicles receive the same package via CDN. In other words, both vehicles A and B receive the same file. In the license.zip in "3. Master Layer" of the DL metadata, the application that the vehicle has a contract for is specified. For vehicle A, two license.zips are specified corresponding to contents A and B. For vehicle B, one license.zip is specified corresponding to content C. According to the DL metadata, vehicle A obtains the license.zip for content A and the license.zip for content B, and vehicle B obtains the license.zip for content C.

[0065] Vehicle A has a user key and device key corresponding to vehicle A, so it obtains content keys A and B from the license file. Key C is not included in the license file, so it cannot use encrypted content C even if it receives it. On the other hand, vehicle B has a user key and device key corresponding to vehicle B, so it can obtain content key C from the license file and use only content C.

[0066] Second embodiment Hereinafter, the same parts as those in the first embodiment are denoted by the same reference numerals and the description thereof will be omitted, and the different parts will be described. In the second embodiment, an ECU device key Kde is generated and used in place of the device key Kd. Therefore, the PKG generation server 2 of the OTA center 1A shown in Fig. 14 and the OTA master 22A shown in Fig. 15 are provided with ECU device key generation function units 33 and 34, respectively.

[0067] 17, when the PKG generation server 2 of the OTA center 1A executes steps S1 to S3, it acquires the ID of the target ECU 24 to be updated from the DL metadata (S51). Then, it generates an ECU device key Kde specific to the target ECU 24 at runtime by execution processing within the PKG generation server 2 from the device key Kd and the ID of the target ECU 24 (S52).

[0068] The ECU device key Kde is generated, for example, by adding the value of the device key Kd and the value of the ID of the target ECU 24 and applying a hash function to the result. Alternatively, instead of addition, the hash function may be applied to the concatenation of the two values. The ECU device key Kde corresponds to an apparatus-specific device key. Then, the content key Kcde is generated by encrypting the content key Kc using the ECU device key Kde (S53).

[0069] The method of generating the ECU device key Kde may be, for example, hard-coded, also called on-coding, in the ECU device key generation function units 33 and 34. In this case, one method of generating the ECU device key Kde is specified as to how to process the value of the device key Kd and the value of the ID of the target ECU 24 and apply a hash function to them. Alternatively, the method of generating the ECU device key Kde may be written in the item of the master layer of the RP metadata.

[0070] Next, when steps S5 to S8 are executed, the user key Ku is encrypted using the ECU device key Kde to generate the user key Kude (S54). Then, the encrypted license file and the user key Kude are archived to generate a Licence.zip file (S55). In step S6a, the encrypted content key becomes Kcde. Then, steps S11 to S17 are executed.

[0071] As shown in Fig. 18, the OTA master 22A executes steps S21 to S25a. In step S25a, the user key Kude is extracted. Then, the OTA master 22A adds the value of the ID of the target ECU 24 to the value of the device key Kd held by the OTA master 22A, and applies a hash function to the result to generate an ECU device key Kde (S56). The OTA master 22A uses the ECU device key Kde to decrypt and extract the user key Kude from the user key Kude (S57).

[0072] Next, when step S27 is executed, the encrypted content key Kcde is decrypted by the ECU device key Kde to extract the content key Kc (S58). Then, steps S29a to S32 are executed. In step S29a, the content key Kcde is replaced with the content key Kc. The process performed by the target ECU 24 is the same as that in the first embodiment.

[0073] As described above, according to the second embodiment, the ECU device key generation function unit 33 of the OTA center 1A generates the ECU device key Kde based on the device key Kd and the ID of the target ECU 24. Specifically, the ECU device key Kde is generated by applying a hash function to the result of adding the value of the device key Kd and the value of the ID of the target ECU 24, or to the concatenation of both values. Then, necessary encryption is performed using the ECU device key Kde instead of the device key Kd of the first embodiment. In response to this, the OTA master 22A also generates the ECU device key Kde in the same manner as the OTA center 1A, and performs necessary decryption. In this way, by using the ECU device key Kde generated corresponding to each target ECU 24, the security level can be further improved.

[0074] Since the ECU device key Kde is generated based on the ID of the target ECU 24 and the value of the device key Kd, the OTA center 1A only needs to manage the values ​​of the device key Kd for the number of OTA masters 22A. In a situation where one vehicle is equipped with multiple ECUs, the management cost differs significantly depending on whether keys for the number of vehicles are managed or keys for the number of ECUs are managed.

[0075] Third embodiment In the third embodiment, a device key Kdt prepared in advance for each target ECU 24 is used instead of the device key Kd. The device key Kdt is written in advance to each target ECU 24. In a vehicle-side system 23B shown in Fig. 19, the license file decryption function unit 27 and the user key decryption function unit 28 are deleted from the OTA master 22B. Instead, a license file decryption function unit 35 and a user key decryption function unit 36 ​​are provided on the target ECU 24B side.

[0076] 21, when the PKG generation server 2 of the OTA center 1 executes steps S1 and S2, it acquires a device key Kdt prepared for each target ECU 24 from the device unique key management function unit 15 of the distribution server 2 (S61). Then, it encrypts the content key Kc using the device key Kdt to generate a content key Kcdt (S62).

[0077] Next, steps S5 and S6b are executed. In step S6b, the content key Kcd is replaced with Kcdt. Furthermore, when steps S7 and S8 are executed, the user key Ku is encrypted using the device key Kdt to obtain the user key Kudt (S63). Then, the encrypted license file and the user key Kudt are archived, and the file name is set to Licence.zip (S64). Then, steps S11 to S17 are executed. As shown in FIG. 22, after executing steps S21 to S24, the OTA master 22B then executes steps S30 to S32.

[0078] 23, when the target ECU 24 receives a notification from the OTA master 22B that the software to be updated is a billable content (S41; YES), the target ECU 24 receives a Contents.zip file and a Licence.zip file from the OTA master 22B (S65). Then, the target ECU 24 unzips the Licence.zip file to extract an encrypted license file and a user key Kudt (S66).

[0079] Next, the user key Kudt is decrypted with the device key Kdt held by the device to extract the user key Ku (S67), and the encrypted license file is decrypted using the user key Ku (S68).Then, the content key Kcdt is extracted from the license file, and the content key Kc is extracted by decrypting the content with the device key Kdt (S69), and the billing content is decrypted with the content key Kc (S70).

[0080] The license conditions included in the license file are read, and if the conditions are met (S48; YES), the installation process for the billing content is executed (S45). If the license conditions are not met (NO), an error response indicating that the license conditions are not met is returned to the OTA master 22B (S47). The process for starting the application for the installed billing content is the same as in the first embodiment.

[0081] The OTA master 22B may decompress the Licence.zip file in step S66 and transfer the encrypted license file and the user key Kudt to the target ECU 24. In addition, when there are multiple target ECUs 24B, a license file is created for each target ECU 24B.

[0082] As described above, according to the third embodiment, the device unique key management function unit 15 of the OTA center 1 holds a device key Kdt prepared for each target ECU 24. When the target ECU 24 receives the encrypted license file and user key Kudt, it decrypts the user key Ku from the user key Kudt using the device key Kdt. Then, it decrypts the license file using the user key Ku. It also decrypts the content key Kc from the content key Kcdt included in the license file using the device key Kdt. It also decrypts the encrypted billing content using the content key Kc.

[0083] That is, the billing content is transferred to the target ECU 24 in an encrypted state and is decrypted in the target ECU 24, thereby further improving the security level.

[0084] (Other embodiments) The process of encrypting the user key Ku with the device key Kd may be performed as necessary. The restriction on the use of the content is not limited to whether or not there is a charge. For example, the restriction on the use of the content may be imposed depending on the vehicle type or grade. The content usage restriction may be imposed not only on the user but also on the system or application installed in the vehicle using the content.

[0085] Although the present disclosure has been described based on the embodiment, it is understood that the present disclosure is not limited to the embodiment or structure. The present disclosure also includes various modifications and modifications within the equivalent range. In addition, various combinations and forms, and other combinations and forms including only one element, more than one element, or less than one element, are also within the scope and concept of the present disclosure.

[0086] The means and / or functions provided by each device, etc., can be provided by software recorded in a tangible memory device and a computer that executes the software, software alone, hardware alone, or a combination of these. For example, when a control device is provided by an electronic circuit that is hardware, it can be provided by a digital circuit including a large number of logic circuits, or an analog circuit.

[0087] The control unit and the method described in the present disclosure may be realized by a special-purpose computer provided by configuring a processor and a memory programmed to execute one or more functions embodied in a computer program. Alternatively, the control unit and the method described in the present disclosure may be realized by a special-purpose computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the control unit and the method described in the present disclosure may be realized by one or more special-purpose computers configured by a combination of a processor and a memory programmed to execute one or more functions and a processor configured with one or more hardware logic circuits. In addition, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions executed by a computer.

Claims

1. a content key generating unit (5) for generating a content key for protecting content that can be restricted in use; a user key generating unit (6) for generating a user key corresponding to a user of the content; A device key management unit (15) that manages device keys corresponding to each vehicle; a content encryption unit (8) for encrypting the content using the content key; a content key encryption unit (10) for encrypting the content key using the device key; a file encryption unit (9) for encrypting a license file including at least a condition for using the content using the user key; A center device includes a compressed file generating unit (4) that generates a compressed file including an encrypted license file and an encrypted license key.

2. 2. The center device according to claim 1, further comprising a user key encryption unit (11) for encrypting the user key by using the device key.

3. The license file includes the license conditions for using the content, a content key encrypted using the device key; and 2. The center device according to claim 1, further comprising identification information for identifying said content.

4. 4. The center device according to claim 3, wherein said license file further includes encryption parameters which are information for performing encryption.

5. A package generation unit (2) for generating a distribution package to be transmitted to a vehicle, 5. The center device according to claim 1, wherein the package generation section also functions as the content key generation section, the user key generation section, the content encryption section, the content key encryption section, and the file encryption section.

6. 5. The center device according to claim 1, further comprising a content distribution unit (12) that distributes encrypted content to vehicles via a CDN (Contents Delivery Network; 21).

7. 5. The center apparatus according to claim 1, wherein the device key management unit holds the device key for each piece of vehicle identification information assigned to each vehicle.

8. The center device according to claim 7, further comprising a device key generating unit (33) that generates a device-corresponding device key based on a device key stored for each of the vehicle identification information and identification information of a target device, which is an electronic control device installed in each vehicle and is a destination of the content transfer.

9. 9. The center device according to claim 8, wherein the device key generation unit generates the device corresponding device key by applying a hash function to a result of adding a value of the identification information to a value of a device key held for each of the vehicle identification information.

10. 9. The center device according to claim 8, wherein the device key generation unit generates the device corresponding device key by applying a hash function to data obtained by concatenating a device key held for each of the vehicle identification information and the identification information.

11. 5. The center device according to claim 1, wherein the device key management unit is an electronic control unit arranged in each vehicle, and holds the device key for each target device to which the content is to be transferred.

12. a communication unit (25) arranged in the vehicle and communicating with the center device according to claim 7; a master device (22) that transfers the data received by the communication unit to a target device that is an electronic control device and is a transfer destination of the content; The target device (24), the master device holds the device key; a license file decryption unit (27) that, upon receiving an encrypted license file and a user key, decrypts the license file using the user key; a content key decryption unit (29) for decrypting a content key included in the license file using the device key; a transfer unit that, upon receiving a data file including the content, transfers the data file and a license file including a content key to the target device.

13. a communication unit (25) arranged in the vehicle and communicating with the center device according to claim 8; a master device (22) that transfers the data received by the communication unit to a target device that is an electronic control device and is a transfer destination of the content; The target device, the master device includes a device key generating unit (34) that generates a device corresponding device key based on the device key and identification information of the target device; a license file decryption unit (27) that, upon receiving an encrypted license file and a user key, decrypts the license file using the user key; a content key decryption unit (29) for decrypting a content key included in the license file using the device key; a transfer unit that, upon receiving a data file including the content, transfers the data file and a license file including a content key to the target device.

14. A method executed by a computer constituting a center device, comprising: generating a content key for protecting content that can be restricted in use; generating a user key corresponding to a user of the content; encrypting the content with the content key; encrypting the content key using a device key corresponding to each vehicle; encrypting a license file including at least a condition for using the content with the user key; A method for protecting content that generates a compressed file that includes an encrypted license file and an encrypted license key.

15. 15. The method of claim 14, further comprising encrypting the user key using the device key.

16. The license file includes a license condition for using the content. a content key encrypted using the device key; and 16. The method for protecting content according to claim 14, further comprising identification information for identifying the content.

17. 17. The method for protecting content according to claim 16, wherein the license file further includes encryption parameters which are information for performing encryption.

18. 16. The content protection method according to claim 14, further comprising the step of delivering the encrypted content to the vehicle via a Content Delivery Network (CDN).

19. 16. The method for protecting content according to claim 14, wherein the device key is provided for each vehicle identification information assigned to each vehicle.

20. A content protection method as described in claim 19, further comprising generating a device-corresponding device key based on a device key for each vehicle identification information and identification information of a target device which is an electronic control device installed in each vehicle and is a destination of the content transfer.

21. The method for protecting content according to claim 20 , further comprising the step of adding a value of the identification information to a value of a device key for each of the vehicle identification information, and applying a hash function to the result to generate the apparatus-corresponding device key.

22. 21. The method for protecting content according to claim 20, further comprising the step of applying a hash function to data obtained by concatenating a device key, which is provided for each of the vehicle identification information, with the identification information, thereby generating the apparatus-corresponding device key.

23. 16. The method for protecting content according to claim 14, wherein the device key is an electronic control unit disposed in each vehicle, and is provided for each target device to which the content is to be transferred.

24. A content protection program executed by a computer included in a center device that communicates with a vehicle and distributes content, generating a content key for protecting content that can be restricted in use; generating a user key corresponding to a user of the content; encrypting the content with the content key; encrypting the content key using a device key corresponding to each vehicle; encrypting a license file including at least a condition for using the content with the user key; A program for content protection that generates a compressed file including an encrypted license file and an encrypted license key.

25. 25. The program for protecting contents according to claim 24, wherein the user key is encrypted using the device key.

26. The license file includes a license condition for using the content. a content key encrypted using the device key; and 26. The content protection program according to claim 25, further comprising identification information for identifying the content.

27. 27. The program for protecting contents according to claim 26, wherein the license file further includes encryption parameters which are information for performing encryption.

28. 28. The content protection program according to claim 24, wherein the encrypted content is delivered to the vehicle via a Content Delivery Network (CDN).

29. 28. The content protection program according to claim 24, wherein the device key is provided for each vehicle identification information assigned to each vehicle.

30. 30. The content protection program of claim 29, which generates a device-corresponding device key based on a device key for each vehicle identification information and identification information of a target device which is an electronic control device installed in each vehicle and is a destination of the content transfer.

31. 31. The content protection program according to claim 30, further comprising: adding a value of the identification information to a value of a device key for each of the vehicle identification information, and applying a hash function to the result to generate the apparatus-corresponding device key.

32. 31. The content protection program according to claim 30, further comprising: applying a hash function to data obtained by concatenating a device key for each of the vehicle identification information and the identification information, thereby generating the apparatus-corresponding device key.

33. 28. The content protection program according to claim 24, wherein the device key is an electronic control unit disposed in each vehicle, and is provided for each target device to which the content is to be transferred.

Images