WO2023013471A1 - センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム - Google Patents
センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム Download PDFInfo
- Publication number
- WO2023013471A1 WO2023013471A1 PCT/JP2022/028744 JP2022028744W WO2023013471A1 WO 2023013471 A1 WO2023013471 A1 WO 2023013471A1 JP 2022028744 W JP2022028744 W JP 2022028744W WO 2023013471 A1 WO2023013471 A1 WO 2023013471A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- content
- key
- vehicle
- identification information
- license file
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 46
- 230000006870 function Effects 0.000 claims description 83
- 238000009826 distribution Methods 0.000 claims description 25
- 238000012546 transfer Methods 0.000 claims description 20
- 238000004891 communication Methods 0.000 claims description 16
- 238000007726 management method Methods 0.000 claims description 15
- 238000012545 processing Methods 0.000 description 24
- 238000010586 diagram Methods 0.000 description 14
- 238000003860 storage Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 230000003044 adaptive effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000013478 data encryption standard Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000011900 installation process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- VIEYMVWPECAOCY-UHFFFAOYSA-N 7-amino-4-(chloromethyl)chromen-2-one Chemical compound ClCC1=CC(=O)OC2=CC(N)=CC=C21 VIEYMVWPECAOCY-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000008672 reprogramming Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000003892 spreading Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
Definitions
- the present disclosure relates to a center device that distributes content to vehicles, a vehicle-side system that communicates with the center device, a content protection method, and a content protection program.
- Patent Literature 1 discloses a technique for distributing an ECU update program from a server to an in-vehicle device by OTA (Over The Air) and rewriting the update program on the vehicle side.
- the present disclosure has been made in view of the above circumstances, and aims to provide a center device and a vehicle-side system that communicates with the center device that enables use of restricted content in a more flexible manner. , to provide a content protection method and a content protection program.
- the content key generation section generates a content key for protecting content whose use can be restricted, and the user key generation section corresponds to the user of the content.
- Generate a user key to A content encryption unit encrypts content using a content key, and a content key encryption unit encrypts the content key using a device key corresponding to each vehicle.
- the file encryption unit then encrypts the license file, which includes at least the conditions for using the content, using the user key.
- the center device only needs to manage device keys corresponding to each vehicle, so the number of keys to be managed is reduced.
- content whose use can be restricted is protected by a content key, and in order to use the content key, a user key tied to the user of the content and a device key tied to each vehicle are required. Become. In other words, the content is protected by double keys. Then, when using the restricted content on the vehicle side, it is sufficient to perform procedures to satisfy the usage conditions in advance, and to sequentially perform necessary decryption using the device key on the vehicle side.
- the center device can flexibly and reliably protect content whose use is restricted.
- a license file it is possible to flexibly set conditions for using content.
- the content can be used even if communication with the center device is not possible.
- the user key encryption unit encrypts the user key using the device key, the content is protected by triple keys, and the content protection level is set to can be further improved.
- the license file includes the license conditions for using the content, the content key encrypted using the device key, and the identification information for identifying the content.
- the license file further includes an encryption parameter, which is information for performing encryption. This allows detailed information about the encryption performed with each key to be obtained from the license file.
- FIG. 1 is a functional block diagram mainly showing the OTA center in the first embodiment
- FIG. 2 is a functional block diagram mainly showing the vehicle side system
- FIG. 3 is a diagram for explaining usage cases of billing content.
- FIG. 4 is a diagram conceptually showing the processing performed on the OTA center side.
- FIG. 5 is a diagram conceptually showing the processing performed among the OTA center, OTA master, and target ECU.
- FIG. 6 is a flowchart showing the processing performed by the OTA center
- FIG. 7 is a diagram showing an example of encryption parameters
- FIG. 8 is a diagram showing an example of repro policy metadata
- FIG. 1 is a functional block diagram mainly showing the OTA center in the first embodiment
- FIG. 2 is a functional block diagram mainly showing the vehicle side system
- FIG. 3 is a diagram for explaining usage cases of billing content.
- FIG. 4 is a diagram conceptually showing the processing performed on the OTA center side.
- FIG. 5 is a diagram conceptually showing the processing performed among the
- FIG. 9 is a diagram showing an example of download metadata corresponding to the storage method.
- FIG. 10 is a diagram showing an example of download metadata corresponding to the streaming method.
- FIG. 11 is a flowchart showing the processing performed by the OTA master;
- FIG. 12 is a flowchart (part 1) showing the processing performed by the target ECU;
- FIG. 13 is a flowchart (part 2) showing the processing performed by the target ECU;
- FIG. 14 is a functional block diagram mainly showing the OTA center in the second embodiment;
- FIG. 15 is a functional block diagram mainly showing the vehicle side system,
- FIG. 16 is a diagram conceptually showing the processing performed among the OTA center, OTA master, and target ECU;
- FIG. 17 is a flowchart showing the processing performed by the OTA center;
- FIG. 11 is a flowchart showing the processing performed by the OTA master;
- FIG. 12 is a flowchart (part 1) showing the processing performed by the target ECU;
- FIG. 13
- FIG. 18 is a flowchart showing the processing performed by the OTA master
- FIG. 19 is a functional block diagram mainly showing the vehicle side system in the third embodiment
- FIG. 20 is a diagram conceptually showing the processing performed among the OTA center, OTA master, and target ECU
- FIG. 21 is a flowchart showing the processing performed by the OTA center
- FIG. 22 is a flowchart showing the processing performed by the OTA master
- FIG. 23 is a flowchart showing processing performed by the target ECU.
- an OTA center 1 of the present embodiment which is a center device, includes a PKG generation server 2 and a distribution server 3 .
- the PKG generation server 2 is broadly divided into a functional portion that generates keys and data packages used for encryption, and a functional portion that performs encryption and signing.
- the former includes a license file generation function unit 4, a content key generation function unit 5, a user key generation function unit 6, and a PKG generation function unit .
- the latter includes a content encryption function unit 8, a license file encryption function unit 9, a content key encryption function unit 10, and a user key encryption function unit 11.
- FIG. "PKG” means "package”.
- the content key generation function unit 5 generates the content key Kc corresponding to the ID, which is the identification information of the chargeable content, using, for example, random numbers.
- the billable content is hereinafter referred to as "billed content".
- the user key generation function unit 6 generates a user key Ku corresponding to the user of billing content, for example, using a random number.
- the license file generation function unit 4 generates a license file in which the ID of the chargeable content, the content key Kc, and the license conditions for using the chargeable content are stored.
- the PKG generation function unit 7 generates a distribution package including encrypted billable contents and the like. It should be noted that, when the user uses the content, making it a condition that the user is charged is one aspect of restricting the use of the content.
- Charged content includes cases in which the content itself is charged, and cases in which a part of the content is subject to charging, such as in-content charging.
- the content means, for example, an application, data used by the application, or a service provided to the occupant via the application. Therefore, the content includes, for example, videos and music viewed in the vehicle, game applications, vehicle control applications related to vehicle control, map data, navigation applications, service usage rights, and the like.
- the content encryption function unit 8 encrypts the charged content using the content key Kc according to a predetermined encryption method.
- the content key encryption function unit 10 encrypts the content key Kc using the device key Kd.
- the user key encryption function unit 11 also 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.
- the distribution server 3 includes a distribution management function section 12, a campaign management function section 13, a software management function section 14, and a device unique key management function section 15.
- the device unique key management function unit 15 manages a device key Kd uniquely assigned corresponding to identification information given to each vehicle, such as VIN (Vehicle Identification Number).
- the software management function unit 14 manages software such as billing contents together with IDs.
- the campaign management function unit 13 manages campaign information, which is information related to program updates including charged content and the like.
- the distribution management function unit 12 distributes the distribution package generated by the PKG generation function unit 7 to the OTA master 22 on the vehicle side via a communication carrier, a CDN (Contents Delivery Network) 21, or the like.
- 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.
- 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. .
- 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 unpacking function unit 26 decompresses it to extract necessary data. A device key Kd corresponding to the VIN of the vehicle 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.
- the OTA master 22 transfers the encrypted data package containing the content and the license file to the target ECU 24 .
- One or more target ECUs 24 exist, and each includes a content decryption function unit 31 and a license condition check function unit 32 .
- the license condition check function unit 32 checks whether or not the content license conditions included in the license file are satisfied.
- the content decryption function unit 31 decrypts the content using the content key Kc included in the license file when the license conditions are satisfied.
- Each functional block in the OTA center 1 and the OTA master 22 described above is realized by cooperation of computer hardware and software.
- the functions of the OTA master 22 are shared between the DCM 22A and the central ECU 22B.
- a configuration in which the central ECU 22B has some or all of the functions of the OTA master 22, or a configuration in which the DCM 22A has some or all of the functions of the OTA master 22 may be used. That is, in the OTA master 22, the functions may be shared between the DCM 22A and the central ECU 22B 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.
- the user communicates with the billing processing center 33 via the smartphone or HMI (Human Machine Interface) of the vehicle-side system 23 when using billing content.
- the billing processing center 33 includes a billing system 34, a member information database 35, a vehicle information database 36, and the like.
- the user selects a method of downloading the charged content when performing the procedure for purchasing the charged content. For example, whether to download to the OTA master 21 or to a smart phone or SD card is selected.
- An SD card corresponds to an example of an external storage medium.
- 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 charged content and the 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 .
- the OTA master 22 is shown as a DCM 22A and a C-ECU 22B.
- the charge processing center 33 when the charge processing center 33 receives the ID of the charge content purchased by the user and the VIN of the corresponding vehicle, it encrypts the charge content and the license file.
- the PKG generation server 2 sends a push notification to the vehicle-side system 23, for example, the DCM 22A.
- the DCM 22A is configured to receive push notifications even when the ignition is turned off. Therefore, the DCM 22A receives push notifications from the OTA center 1 regardless of the ignition state. This push notification serves as a trigger for the OTA master 22 to synchronize the vehicle configuration information with the OTA center 1 .
- the license file generated by the OTA center includes the content key Kc encrypted with the device key Kd, the billing content ID, license conditions, and encryption parameters.
- the permission conditions include, for example, the completion of charging processing, the usage period of the charged content, the remaining number of usages, and the prohibition of transfer to other vehicles.
- 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 (common key) AES (Advanced Encryption Standard), Triple-DES (Data Encryption Standard), (public key) RSA (Rivest-Shamir-Adleman cryptosystem), ECC (Elliptic Curve Cryptography) ⁇ Signature type information: (common 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 ⁇ Protection target information: Specify a specific file or data ⁇ Protection area specification information: Specify all or part of the above file ⁇ Offset size information: Specify the number of bytes from the beginning to be protected ⁇ Protection data size information: Specify how many bytes to protect
- the PKG generation server 2 of the OTA center 1 when the PKG generation server 2 of the OTA center 1 generates a content key Kc corresponding to the ID of content to be billed from random numbers (S1), the content key Kc is encrypted according to a predetermined encryption method for the billing content. (S2). Let Contents.zip be the file name of the encrypted billable content. Subsequently, when the device key Kd is obtained from the distribution server 3 (S3), the content key Kc is encrypted using the device key Kd (S4). Let Kcd be the encrypted content key Kc.
- a parameter indicating that the distribution package of the target layer is charged content is embedded (S11)
- URI Uniform Resource Identifier
- S12 URI information for downloading the license file License.zip
- the RP metadata is information that includes distribution package configuration information, in other words, information that indicates the type of package configuration. The main purpose of this is to prevent package delivery errors by checking the content of the data on the vehicle side. It is information to do.
- the DL metadata stores control information for acquiring data. This is information that defines the content for By making these metadata into a three-layer structure of distribution, master, and target, even if the transfer method, platform type, and distribution package type increase, they can be flexibly defined and handled. It becomes possible to update the data of the target device.
- RP metadata version> This is the version of RP metadata, and version information such as "1.0.0" and "2.0.0" is stored.
- Uptane registered trademark
- OMA-DM Open Mobile Alliance-Device Management
- JASPAR's specifications stipulate the data requirements applicable to the classic platform (CP) that runs on the static OS of the standardization organization AUTOSAR.
- AUTOSAR also specifies data requirements applicable to a new type of adaptive platform (AP) running on a dynamic OS.
- AGL is in-vehicle Linux (registered trademark)
- Android is Android Automotive OS.
- AP and CP stand for software platform.
- a software platform is also called a software architecture.
- CP stands for AUTOSAR Classic Platform
- AP stands for AUTOSAR Adaptive Platform.
- an ECU that operates in compliance with the CP specifications is sometimes referred to as a CP ECU or CP ECU
- an ECU that operates in compliance with the AP specifications is referred to as an AP ECU or an AP ECU.
- the operating systems used in AP and CP are different.
- the structure of the package that can be received differs between the CP ECU and the AP ECU.
- the difference in the structure of these packages is mainly due to the difference in the processing performance of the ECU.
- the processing performance of the CP ECU is low, so the specification data included in the package is also described in binary data. It has a package data structure that is easy to interpret and process even for ECUs with low processing performance.
- AP ECUs have high processing performance, it is possible to install a parser function that analyzes structural character data written in some language and converts it into a data structure that can be handled by a program.
- the data structure is not simple binary data, but an object-oriented data format such as JSON (JavaScript Object Notation) can be adopted, resulting in a flexible package data structure.
- JSON JavaScript Object Notation
- control method information such as "parameters” that are processed according to parameters set according to a specific format, and "scripts” that are processed in a more free description format without a specific format are stored.
- ⁇ Target layer> It is information corresponding to the target ECU 33 .
- the PF and the control method are the same as those described above.
- the transfer method is either storage or streaming.
- the billing method indicates whether the usage of the content is charged or free.
- the target ID is an ID corresponding to the target ECU 24, but storing it here is optional.
- FIGS. 9 and 10 are transmitted from the OTA center 1 to the OTA master 22 following the RP metadata. They respectively show the cases where the transfer method is storage and streaming.
- ⁇ Distribution layer> For example, if the communication protocol is Uptane, it is information for acquiring Uptane metadata, and stores corresponding URI, data name, data size, hash value, target ID, transfer method, and the like.
- the master layer is information for obtaining the license file License.zip
- the target layer is information for obtaining the content file Contents.zip.
- information for obtaining both files is embedded in the master layer, so the target layer is not essential.
- a target layer may be provided, but the information is null or blank.
- Each item is the same as the delivery layer. It should be noted that, in each item, "xxx", “zzz”, etc. may be described redundantly, but they do not indicate the same value.
- the distribution server 3 receives the Contents.zip file, License.zip file, DL metadata and RP metadata from the PKG generation server 2 (S13).
- the License.zip file differs for each vehicle, but other files and data are common to all vehicle models.
- the distribution server 3 stores the Contents.zip file, DL metadata and RP metadata in the server connected to the CDN 21 (S14).
- the vehicle configuration information is identification information related to hardware and software of ECUs installed in the vehicle, and includes identification information of a system configuration composed of a plurality of ECUs and identification information of a vehicle configuration composed of a plurality of systems.
- the "notification for synchronization" is a notification for matching, that is, synchronizing the content of the configuration information held on the vehicle side with the content of the configuration information held on the OTA center 1 side. .
- the OTA master 22 checks the elapsed time after synchronizing the vehicle configuration information with the OTA center 1 at the timing when the ignition is turned on. synchronization is required. Alternatively, the OTA master 22 checks whether or not it has received a push notification from the OTA center 1, and if it has received a push notification, determines that synchronization of vehicle configuration information with the OTA center 1 is necessary. In these cases, the ECU mounted on the vehicle is requested to transmit the vehicle configuration information to the OTA master 22 . The OTA master 22 notifies the collected vehicle configuration information to the OTA center 1 .
- the OTA center 1 is notified of the billing content ID purchased by the user and the corresponding vehicle VIN from the billing processing center 33 and stores the ID.
- an OEM server (not shown) notifies and stores the VIN of a vehicle to be updated for software other than chargeable content, which is also referred to as non-chargeable content.
- S15 based on the VIN, (1) non-chargeable content is updated, (2) chargeable content is updated, (3) chargeable content and non-chargeable content are updated, or (4) no update is determined. to decide. In the present disclosure, only the case where billing content is updated will be described.
- the URI information of the DL metadata and RP metadata is embedded in the notification (S16).
- the License.zip file is transmitted to the vehicle (S17). Note that the user key Ku and the content key Kc may be erased in step S14, for example.
- the OTA master 22 when the OTA master 22 receives the campaign notification from the distribution server 3 of the OTA center 1 (S21), it acquires the RP metadata from the CDN 21 according to the URI information described in the campaign notification, and distributes it. A check is made to see if the scheduled package includes charged content (S22). If the charged content is not included (S23; NO), the OTA master 22 updates the software for the target ECU 24 according to the method disclosed in Japanese Patent Application No. 2021-32593, for example (S33).
- the License.zip file is acquired from the distribution server 3 (S24), and when the License.zip file is decompressed, the encrypted license file and user key Kud are obtained. Take out (S25). Then, the user key Kud is decrypted with the device key Kd held by the OTA master 22, and the user key Ku is extracted (S26). Then, the user key Ku is used to decrypt the encrypted license file (S27).
- the content key Kcd contained in the license file is decrypted with the device key Kd to extract the content key Kc (S28), the content key Kcd in the license file is replaced with the content key Kc (S29). .
- the content key Kcd in the license file is overwritten with the content key Kc.
- the target ECU 24 to which the content is delivered is specified from the DL metadata.
- the target ECU 24 is notified that the software to be updated is charged content, and the Contents.zip file and license file are transferred (S32).
- step S41 the receipt of the Contents.zip file and the license file from the OTA master 22 may be notified by the OTA master 22 that the software to be updated is chargeable content.
- the target ECU 24 determines that there is charged content, and performs the processing from step S42 onward.
- 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 the notification is not received (NO), it updates its own software according to the method disclosed in Japanese Patent Application No. 2021-32593, for example (S46). On the other hand, when the notification is received (S41; YES), the Contents.zip file and license file are received from the OTA master 22 (S42). Then, the content key Kc is extracted from the license file, and the charged content is decrypted with the content key Kc (S43).
- the license conditions included in the license file are read, and it is determined whether or not the conditions are satisfied (S44). If the license conditions are satisfied (YES), the charged content installation process is executed (S45). If the permission conditions are not satisfied (NO), an error response to the effect that the permission conditions are not satisfied is returned to the OTA master 22 (S47).
- the license conditions include, for example, the completion of billing processing, the period of use of the billed content, and the remaining number of times of use. There may be one permission condition, or there may be more than one. If there is more than one, all license conditions must be satisfied. However, if at least one license condition is satisfied, it may be possible to use the charged content.
- the target ECU 24 checks whether or not the license conditions are satisfied at the time when the installed billing content application is activated (S48). If the license conditions are satisfied (YES), the application is started and executed (S49). If the permission conditions are not satisfied (NO), the same processing as in step S47 is performed (S50).
- the number of target ECUs 24 is one, but if there are a plurality of target ECUs 24, the same processing may be performed for each target ECU 24. FIG. The same applies to subsequent embodiments.
- information about the plurality of target ECUs 24 is described in the RP metadata and DL metadata.
- the content key generation function unit 5 generates the content key Kc for protecting billed content
- the user key generation function unit 6 controls the user of the billed content.
- the content encryption unit encrypts the content using the content key Kc
- the content key encryption function unit 10 encrypts the content key Kc using the device key Kd corresponding to each vehicle.
- the file encryption function unit 8 encrypts the license file, which includes at least the conditions for using the charged content, using the user key Ku.
- the content key Kc and the user key Ku are erased without being stored at the OTA center 1 .
- the OTA center 1 only has to manage the device key Kd corresponding to each vehicle, so the number of keys to manage is reduced.
- charged content is protected by a content key Kc, and in order to use the content key Kc, a user key Ku linked to the user of the content and a device key Kd linked to each vehicle are required.
- Content is triple key protected. Then, when the charged content is used on the vehicle side, procedures to satisfy usage conditions are performed in advance, and the necessary decryption is sequentially performed on the vehicle side using the device key Kd.
- the OTA center 1 can flexibly and reliably protect charged content.
- a license file it is possible to flexibly set conditions for using content.
- the content can be used by acquiring the content via, for example, a smart phone.
- the user key encryption function unit 11 encrypts the user key Kc using the device key Kd, it is possible to further improve the content protection level.
- 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.
- the license file contains encryption parameters, detailed information about the encryption performed with each key can be obtained from the license file.
- the unpacking function unit 26 of the OTA master 22 when the unpacking function unit 26 of the OTA master 22 receives the License.zip file, it decompresses the file to extract the encrypted license file and user key Kud.
- the user key decryption function unit 28 decrypts the user key Ku from the user key Kud 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 uses the device key Kd to decrypt the content key Kc included in the license file. Then, when receiving the Contents.zip file, it transfers the file and the license file including the content key Kc to the target ECU 24 .
- the target ECU 24 decrypts the charged content using the content key Kc. As a result, necessary decryption is performed on the vehicle system 23 side, and the charged content can be used in the target ECU 24 .
- SOTA Software OTA
- multiple applications such as a navigation app (ver1.0), a game app (ver2.0), and a video app (ver3.5)
- each application is individually can be updated to
- the billing content application is an agent service application (ver1.0)
- the license file may be checked for tampering.
- some items such as the licensing conditions of the license file may be checked for tampering.
- the OTA center 1 calculates a MAC value from the data to be checked for falsification, and puts the calculated MAC value in the license file together with or in the license file.
- the target ECU 24 may also calculate the MAC value and compare it with the MAC value provided by the OTA center 1 to check whether it has been tampered with. As a result, it is possible to avoid a situation in which a malicious third party tampered with the license conditions and the charged content became available even though the license conditions were not satisfied.
- vehicle A Since vehicle A has a user key and a device key corresponding to vehicle A, content keys A and B are obtained from the license file. Since the key C is not included in the license file, even if the encrypted content C is received, it cannot be used. On the other hand, since vehicle B has a user key and a device key corresponding to vehicle B, it can acquire content key C from the license file and use content C only.
- an ECU device key Kde is generated and used instead 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.
- 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, from the device key Kd and the ID of the target ECU 24, an ECU device key Kde unique to the target ECU 24 is generated at runtime by execution processing inside the PKG generation server 2 (S52).
- the ECU device key Kde is generated, for example, 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 . Also, instead of addition, a hash function may be applied to a concatenation of both values.
- the ECU device key Kde corresponds to a device-corresponding device key. Then, the content key Kcde is generated by encrypting the content key Kc using the ECU device key Kde (S53).
- the method of generating the ECU device key Kde may be hard-coded, also called on-coding, in the ECU device key generation function units 33 and 34, for example.
- one method for generating the ECU device key Kde is designated as how to process the value of the device key Kd and the value of the ID of the target ECU 24 and apply the hash function.
- the method of generating the ECU device key Kde may be described in the item of the master layer of the RP metadata.
- step S5 to S8 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 user key Kude are archived to generate a License.zip file (S55). In step S6a, the encrypted content key becomes Kcde. Then, steps S11 to S17 are executed.
- the OTA master 22A executes steps S21 to S25a.
- the user key to be taken out is Kude.
- it generates an ECU device key Kde by applying a hash function to the result of adding the value of the ID of the target ECU 24 to the value of the device key Kd held by itself (S56).
- the ECU device key Kde is used to decrypt and extract the user key Ku from the user key Kude (S57).
- step S27 the encrypted content key Kcde is decrypted with the ECU device key Kde to extract the content key Kc (S58). Then, steps S29a-S32 are executed. In step S29a, the content key Kcde is replaced with the content key Kc.
- the processing performed by the target ECU 24 is the same as that of the first 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 .
- 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.
- necessary encryption is performed using the ECU device key Kde instead of the device key Kd of the first embodiment.
- the OTA master 22A also generates the ECU device key Kde similarly to the OTA center 1A, and performs necessary decryption.
- the OTA center 1A 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 device key Kd values for the number of OTA masters 22A. In a situation in which a plurality of ECUs are installed in one vehicle, the management cost significantly differs depending on whether the keys for the number of vehicles or the keys for the number of ECUs are managed.
- 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 each target ECU 24 in advance.
- the license file decryption function unit 27 and the user key decryption function unit 28 are removed from the OTA master 22B.
- a license file decryption function unit 35 and a user key decryption function unit 36 are provided on the target ECU 24B side.
- the PKG generation server 2 of the OTA center 1 executes steps S1 and S2
- the device key Kdt prepared for each target ECU 24 is generated by the device unique key management function unit 15 of the distribution server 2. (S61).
- the content key Kc is encrypted using the device key Kdt to generate the content key Kcdt (S62).
- steps S5 and S6b are executed.
- step S6b the content key Kcd is replaced with Kcdt.
- 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 user key Kudt are archived, and the file name is License.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.
- the target ECU 24 when the target ECU 24 receives notification from the OTA master 22B that the software to be updated is chargeable content (S41; YES), it receives the Contents.zip file and the License.zip file from the OTA master 22B. (S65). Then, when the License.zip file is decompressed, the encrypted license file and user key Kudt are taken out (S66).
- the user key Kudt is decrypted with the device key Kdt held by itself to extract the user key Ku (S67)
- the user key Ku is used to decrypt the encrypted license file (S68).
- the content key Kcdt is extracted from the license file and decrypted with the device key Kdt to extract the content key Kc (S69), and the charged content is decrypted with the content key Kc (S70).
- the license conditions included in the license file are read, and if the conditions are satisfied (S48; YES), the charged content installation process is executed (S45). If the permission conditions are not satisfied (NO), an error response to the effect that the permission conditions are not satisfied is returned to the OTA master 22B (S47).
- the process for activating the installed billing content application is the same as in the first embodiment.
- step S66 the decompression of the License.zip file performed in step S66 may be performed by the OTA master 22B, and the encrypted license file and user key Kudt may be transferred to the target ECU 24. Also, when there are a plurality of target ECUs 24B, a license file is created for each target ECU 24B.
- the device unique key management function unit 15 of the OTA center 1 holds the device key Kdt prepared for each target ECU 24 .
- the target ECU 24 decrypts the user key Ku using the device key Kdt from the user key Kudt. Then, the user key Ku is used to decrypt the license file.
- the content key Kc is decrypted from the content key Kcdt included in the license file. Furthermore, the content key Kc is used to decrypt the encrypted charged content.
- the charged content is transferred to the target ECU 24 in an encrypted state and decrypted in the target ECU 24, so that the security level can be further improved.
- the process of encrypting the user key Ku using the device key Kd may be performed as required.
- Content usage restrictions are not limited to the presence or absence of charging.
- use of content may be restricted according to vehicle type or vehicle grade.
- each device can be provided by software recorded in a physical memory device and a computer that executes it, software only, hardware only, or a combination thereof.
- the controller is provided by an electronic circuit that is hardware, it can be provided by a digital circuit, including a number of logic circuits, or an analog circuit.
- the controller and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring a processor and memory programmed to perform one or more functions embodied by the computer program.
- the controls and techniques described in this disclosure may be implemented by a dedicated computer provided by configuring the processor with one or more dedicated hardware logic circuits.
- the control units and techniques described in this disclosure can be implemented by a combination of a processor and memory programmed to perform one or more functions and a processor configured by one or more hardware logic circuits. It may also be implemented by one or more dedicated computers configured.
- the computer program may also be stored as computer-executable instructions on a computer-readable non-transitional tangible recording medium.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Technology Law (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本開示の一態様は、OTAセンタ1において、コンテンツ鍵生成機能部5は、課金コンテンツを保護するためのコンテンツ鍵Kcを生成し、ユーザ鍵生成機能部6は、課金コンテンツのユーザに対応するユーザ鍵Kuを生成する。コンテンツ暗号化部は、コンテンツ鍵Kcを用いてコンテンツを暗号化し、コンテンツ鍵暗号化機能部10は、コンテンツ鍵Kcを、各車両に対応するデバイス鍵Kdを用いて暗号化する。ファイル暗号化機能部8は、少なくとも課金コンテンツを利用するための条件を含むライセンスファイルを、ユーザ鍵Kuを用いて暗号化する。
Description
本出願は、2021年8月6日に出願された日本出願番号2021-129943号に基づくもので、ここにその記載内容を援用する。
本開示は、車両にコンテンツを配信するセンタ装置、そのセンタ装置と通信を行なう車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラムに関する。
近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置(以下、ECU(Electronic Control Unit)と称する)に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ECUのアプリプログラムを書換える,所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献1には、サーバよりECUの更新プログラムをOTA(Over The Air)により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。
また、更新プログラムに限ることなく、ユーザが有料で利用できるデジタルコンテンツについても、同様にOTAによって装置に配信することも行われている。上記のように利用制限がかけられているコンテンツを、課金コンテンツと称する。現在運用されているシステムでは、課金コンテンツか、それ以外のコンテンツかに関らず、全てのソフトウェアを車両に配信している。課金コンテンツを利用するユーザは、所定の手続を経て課金を行うことで、コンテンツの配信元であるセンタが管理している課金フラグを有効にしておく。そして、課金コンテンツが配信された車両はセンタに問い合わせを行い、課金フラグが有効になっていれば課金コンテンツが利用可能になる。
現状のシステムでは、センタに課金状態の問い合わせを行うことが前提となっているため、車両がセンタと通信可能な状態になければ、課金コンテンツを利用可能にすることができない。
本開示は上記事情に鑑みてなされたものであり、その目的は、利用制限がかけられているコンテンツを、より柔軟な形態で利用可能にできるセンタ装置、そのセンタ装置と通信を行なう車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラムを提供することにある。
請求項1記載のセンタ装置によれば、コンテンツ鍵生成部は、利用に際して利用制限をかけることが可能なコンテンツを保護するためのコンテンツ鍵を生成し、ユーザ鍵生成部は、コンテンツのユーザに対応するユーザ鍵を生成する。コンテンツ暗号化部は、コンテンツ鍵を用いてコンテンツを暗号化し、コンテンツ鍵暗号化部は、コンテンツ鍵を、各車両に対応するデバイス鍵を用いて暗号化する。そして、ファイル暗号化部は、少なくともコンテンツを利用するための条件を含むライセンスファイルを、ユーザ鍵を用いて暗号化する。
このように構成すれば、センタ装置は、各車両に対応するデバイス鍵だけを管理すれば良いので、管理する鍵の数が少なくなる。また、利用制限をかけることが可能なコンテンツは、コンテンツ鍵によって保護され、そのコンテンツ鍵を利用するには、コンテンツのユーザに紐付いているユーザ鍵と各車両に紐付いているデバイス鍵とが必要になる。つまり、コンテンツは2重の鍵によって保護されることになる。そして、利用制限がかけられているコンテンツを車両側で利用する際には、予め利用条件を満たす手続きを行ない、車両側でデバイス鍵を用いて順次必要な復号化を行うようにすれば良い。
したがって、センタ装置は、利用制限がかけられたコンテンツを柔軟且つ確実に保護することができる。また、ライセンスファイルを用いることで、コンテンツを利用するための条件を柔軟に設定できる。加えて、車両側では、センタ装置との通信が可能な状態でなくても、コンテンツの利用が可能になる。
請求項2記載のセンタ装置によれば、ユーザ鍵暗号化部は、デバイス鍵を用いてユーザ鍵を暗号化するので、コンテンツは3重の鍵によって保護されることになり、コンテンツの保護レベルを更に向上させることができる。
請求項3記載のセンタ装置によれば、ライセンスファイルには、コンテンツを利用するための許諾条件と、デバイス鍵を用いて暗号化されたコンテンツ鍵と、コンテンツを識別するための識別情報とが含まれる。これにより、ユーザ鍵を用いてライセンスファイルを復号化すれば、コンテンツを利用するための許諾条件を確認することができる。そして、許諾条件を満たした上で、デバイス鍵を用いてコンテンツ鍵を復号化すれば、その鍵を用いて識別情報に対応したコンテンツを復号化できる。
請求項4記載のセンタ装置によれば、ライセンスファイルには、更に暗号化を行なうための情報である暗号化パラメータが含まれる。これにより、それぞれの鍵を用いて行われた暗号化に関する詳細な情報を、ライセンスファイルより得ることができる。
本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図1は、第1実施形態において、OTAセンタを中心に示す機能ブロック図であり、
図2は、車両側システムを中心に示す機能ブロック図であり、
図3は、課金コンテンツの利用ケースを説明する図であり、
図4は、OTAセンタ側で行う処理を概念的に示す図であり、
図5は、OTAセンタ、OTAマスタ、ターゲットECU間で行われる処理を概念的に示す図であり、
図6は、OTAセンタが行う処理を示すフローチャートであり、
図7は、暗号化パラーメータの一例を示す図であり、
図8は、リプロポリシーメタデータの一例を示す図であり、
図9は、ストレージ方式に対応したダウンロードメタデータの一例を示す図であり、
図10は、ストリーミング方式に対応したダウンロードメタデータの一例を示す図であり、
図11は、OTAマスタが行う処理を示すフローチャートであり、
図12は、ターゲットECUが行う処理を示すフローチャート(その1)であり、
図13は、ターゲットECUが行う処理を示すフローチャート(その2)であり、
図14は、第2実施形態において、OTAセンタを中心に示す機能ブロック図であり、
図15は、車両側システムを中心に示す機能ブロック図であり、
図16は、OTAセンタ、OTAマスタ、ターゲットECU間で行われる処理を概念的に示す図であり、
図17は、OTAセンタが行う処理を示すフローチャートであり、
図18は、OTAマスタが行う処理を示すフローチャートであり、
図19は、第3実施形態において、車両側システムを中心に示す機能ブロック図であり、
図20は、OTAセンタ、OTAマスタ、ターゲットECU間で行われる処理を概念的に示す図であり、
図21は、OTAセンタが行う処理を示すフローチャートであり、
図22は、OTAマスタが行う処理を示すフローチャートであり、
図23は、ターゲットECUが行う処理を示すフローチャートである。
(第1実施形態)
図1に示すように、センタ装置である本実施形態のOTAセンタ1は、PKG生成サーバ2及び配信サーバ3を備えている。PKG生成サーバ2は、大別して暗号化に用いる鍵やデータパッケージ等を生成する機能部分と、暗号化・署名を行う機能部分とがある。前者には、ライセンスファイル生成機能部4、コンテンツ鍵生成機能部5、ユーザ鍵生成機能部6、PKG生成機能部7がある。また、後者には、コンテンツ暗号化機能部8、ライセンスファイル暗号化機能部9、コンテンツ鍵暗号化機能部10、ユーザ鍵暗号化機能部11がある。尚、「PKG」は「パッケージ」を意味する。
図1に示すように、センタ装置である本実施形態のOTAセンタ1は、PKG生成サーバ2及び配信サーバ3を備えている。PKG生成サーバ2は、大別して暗号化に用いる鍵やデータパッケージ等を生成する機能部分と、暗号化・署名を行う機能部分とがある。前者には、ライセンスファイル生成機能部4、コンテンツ鍵生成機能部5、ユーザ鍵生成機能部6、PKG生成機能部7がある。また、後者には、コンテンツ暗号化機能部8、ライセンスファイル暗号化機能部9、コンテンツ鍵暗号化機能部10、ユーザ鍵暗号化機能部11がある。尚、「PKG」は「パッケージ」を意味する。
コンテンツ鍵生成機能部5は、課金対象コンテンツの識別情報であるIDに対応したコンテンツ鍵Kcを例えば乱数によって生成する。以下、課金対象コンテンツを「課金コンテンツ」と称する。ユーザ鍵生成機能部6は、課金コンテンツのユーザに対応するユーザ鍵Kuを例えば乱数によって生成する。ライセンスファイル生成機能部4は、課金コンテンツのIDやコンテンツ鍵Kc、及び課金コンテンツを利用するための許諾条件等が格納されたライセンスファイルを生成する。PKG生成機能部7は、暗号化された課金コンテンツ等を含む配信パッケージを生成する。尚、ユーザがコンテンツを利用する際に、課金が行われていることを条件とすることは、その利用を制限する一態様である。
課金コンテンツには、コンテンツそのものが課金される場合もあれば、コンテンツ内課金のように、コンテンツの一部について課金が行われていることを条件とする場合も含む。尚、コンテンツとは、例えば、アプリ、アプリが使用するデータ、またはアプリを介して乗員に提供されるサービスを意味する。よって、コンテンツとは、例えば、車室内にて視聴するビデオや音楽、ゲームアプリ、車両制御に関わる車両制御アプリ、地図データ、ナビゲーションアプリ、及びサービスの利用権限等である。
コンテンツ暗号化機能部8は、課金コンテンツを所定の暗号化方式に従い、コンテンツ鍵Kcを用いて暗号化する。コンテンツ鍵暗号化機能部10は、コンテンツ鍵Kcを、デバイス鍵Kdを用いて暗号化する。ユーザ鍵暗号化機能部11は、ユーザ鍵Kuを、同じくデバイス鍵Kdを用いて暗号化する。ライセンスファイル暗号化機能部9は、ライセンスファイルを、ユーザ鍵Kuを用いて暗号化する。
配信サーバ3は、配信管理機能部12、キャンペーン管理機能部13、ソフトウェア管理機能部14、デバイスユニーク鍵管理機能部15を備えている。デバイスユニーク鍵管理機能部15は、例えばVIN(Vehicle Identification Number)のように各車両に付与されている識別情報に対応してユニークに割り当てられたデバイス鍵Kdを管理する。ソフトウェア管理機能部14は、課金コンテンツ等のソフトウェアをIDと共に管理する。キャンペーン管理機能部13は、課金コンテンツ等を含むプログラム更新に関する情報であるキャンペーン情報を管理する。配信管理機能部12は、PKG生成機能部7により生成された配信パッケージ等を、通信キャリアやCDN(Contents Delivery Network)21等を介して車両側のOTAマスタ22に配信する。
図2に示すように、車両側システム23は、OTAマスタ22及びターゲットECU24を備えている。OTAマスタ22は、配信サーバ3等と通信を行う図3に示すDCM(Data Communication Module)22Aや、ターゲットECU24と通信を行なうセントラルECU22Bを含んで構成される。OTAマスタ22は、ダウンロード機能部25、アンパック機能部26、ライセンスファイル復号化機能部27、ユーザ鍵復号化機能部28、コンテンツ鍵復号化機能部29及びデバイスユニーク鍵管理機能部30を備えている。
ダウンロード機能部25は、OTAセンタ1の配信サーバ3と直接、又はCDN21を介して通信を行なうことで、データファイルやパッケージ等をダウンロードする。アンパック機能部26は、受信したデータパッケージが圧縮ファイルであれば解凍して必要なデータを抽出する。デバイスユニーク鍵管理機能部30には、車両のVINに対応したデバイス鍵Kdが製造段階で書き込まれている。ユーザ鍵復号化機能部28は、デバイス鍵Kdを用いてユーザ鍵Kuを復号化する。ライセンスファイル復号化機能部27は、ユーザ鍵Kuを用いてライセンスファイルを復号化する。コンテンツ鍵復号化機能部29は、デバイス鍵Kdを用いてコンテンツ鍵Kcを復号化する。
OTAマスタ22は、コンテンツを含む暗号化された状態のデータパッケージと、ライセンスファイルとをターゲットECU24に転送する。ターゲットECU24は、1つ以上存在しており、コンテンツ復号化機能部31及び許諾条件チェック機能部32を備えている。許諾条件チェック機能部32は、ライセンスファイルに含まれているコンテンツの許諾条件を満たしているか否かをチェックする。コンテンツ復号化機能部31は、前記の許諾条件を満たしている際に、ライセンスファイルに含まれているコンテンツ鍵Kcを用いてコンテンツを復号化する。
以上のOTAセンタ1及びOTAマスタ22における各機能ブロックは、コンピュータのハードウェア及びソフトウェアの協働により実現されている。
以上のOTAセンタ1及びOTAマスタ22における各機能ブロックは、コンピュータのハードウェア及びソフトウェアの協働により実現されている。
尚、OTAマスタ22の各機能部を、DCM22AとセントラルECU22Bの間でどのように機能分担するかは特に制限がない。OTAマスタ22の機能の一部又は全体をセントラルECU22Bが有する構成でも良いし、OTAマスタ22の機能の一部又は全体をDCM22Aが有する構成でも良い。即ち、OTAマスタ22において、DCM22AとセントラルECU22Bとの機能分担がどのように構成されていても良い。OTAマスタ22は、DCM22A及びセントラルECU22Bの2つのECUから構成されても良いし、DCM22Aの機能とセントラルECU22Bの機能とを有する1つの統合ECUで構成されても良い。
図3に示すように、ユーザは、課金コンテンツを利用する際には、スマートホンや車両側システム23のHMI(Human Machine Interface)を介して課金処理センタ33と通信を行なう。課金処理センタ33は、課金システム34や会員情報データベース35、車両情報データベース36等を備えている。ユーザは、課金コンテンツを購入する手続きを行なうと、課金コンテンツをダウンロードする方式を選択する。例えばOTAマスタ21にダウンロードするか、スマートホンやSDカードにダウンロードするか等を選択する。SDカードは、外部記憶媒体の一例に相当する。
課金処理センタ33は、ユーザが購入した課金コンテンツのIDと対応する車両のVINとをOTAセンタ1に送信する。OTAセンタ1では、前述のように課金コンテンツ及びライセンスファイルを暗号化して、ダウンロード方式が「OTA」であれば車両側システム23にそれらをダウンロードさせる。図中の「ネットワークキャリア」は、通信を配信サーバ3と直接、又はCDN21を介して行なうケースを含んでいる。尚、同図では、OTAマスタ22を、DCM22A及びC-ECU22Bとして示している。
OTAセンタ1において、課金処理センタ33は、ユーザが購入した課金コンテンツのIDと対応する車両のVINとを受信すると、課金コンテンツ及びライセンスファイルの暗号化を行う。加えて、PKG生成サーバ2は、車両側システム23の、例えばDCM22Aに対してプッシュ通知を行う。DCM22Aは、イグニッションがオフされた状態でもプッシュ通知を受け取ることができるように構成されている。よって、DCM22Aは、イグニッションの状態に関係なくOTAセンタ1からプッシュ通知を受信する。このプッシュ通知は、OTAマスタ22が車両構成情報をOTAセンタ1と同期するトリガとなる。
図4に示すように、OTAセンタで生成されるライセンスファイルには、デバイス鍵Kdで暗号化されたコンテンツ鍵Kc、課金コンテンツのID、許諾条件と共に暗号化パラメータが含まれている。許諾条件は、例えば課金処理が完了していることや課金コンテンツの利用期間、残りの利用回数や他車両への転送が不可であること、等である。図7に示す暗号化パラメータは、暗号化及びデジタル署名に関連したパラメータである。暗号化パラメータは、コンテンツ鍵Kcに関する暗号化パラメータと、ユーザ鍵Kuに関する暗号化パラメータを含む。
・暗号化種別情報 :(共通鍵)AES(Advanced Encryption Standard),
Triple-DES(Data Encryption Standard),
(公開鍵)RSA(Rivest-Shamir-Adleman cryptosystem),
ECC(Elliptic Curve Cryptography)
・署名種別情報 :(共通鍵)CBC-MAC
(Message Authentication Code),CMAC(Common MAC)
(公開鍵)DSA(Digital Signature Algorithm),
ECDSA(Elliptic Curve DSA)
・鍵ID情報 :鍵の特定に使用
・暗号モード種別情報 :Enc(Encrypt) then MAC,
MAC then,ENC
・保護対象情報 :特定のファイル又はデータを指定
・保護領域指定情報 :上記ファイルの全体又は一部を指定
・オフセットサイズ情報:先頭より何Byte目から保護対象とするか指定
・保護データサイズ情報:何Byteを保護するか指定
・暗号化種別情報 :(共通鍵)AES(Advanced Encryption Standard),
Triple-DES(Data Encryption Standard),
(公開鍵)RSA(Rivest-Shamir-Adleman cryptosystem),
ECC(Elliptic Curve Cryptography)
・署名種別情報 :(共通鍵)CBC-MAC
(Message Authentication Code),CMAC(Common MAC)
(公開鍵)DSA(Digital Signature Algorithm),
ECDSA(Elliptic Curve DSA)
・鍵ID情報 :鍵の特定に使用
・暗号モード種別情報 :Enc(Encrypt) then MAC,
MAC then,ENC
・保護対象情報 :特定のファイル又はデータを指定
・保護領域指定情報 :上記ファイルの全体又は一部を指定
・オフセットサイズ情報:先頭より何Byte目から保護対象とするか指定
・保護データサイズ情報:何Byteを保護するか指定
次に、本実施形態の作用について説明する。図6に示すように、OTAセンタ1のPKG生成サーバ2は、課金対象コンテンツのIDに対応したコンテンツ鍵Kcを乱数によって生成すると(S1)、課金コンテンツを所定の暗号化方式に従い、コンテンツ鍵Kcを用いて暗号化する(S2)。暗号化された課金コンテンツのファイル名を、Contents.zipとする。続いて、配信サーバ3よりデバイス鍵Kdを取得すると(S3)、コンテンツ鍵Kcを、デバイス鍵Kdを用いて暗号化する(S4)。暗号化されたコンテンツ鍵KcをKcdとする。
次に、課金コンテンツの許諾条件が記載されたファイルを、配信サーバ3のソフトウェア管理機能部14より取得すると(S5)、暗号化パラメータ、コンテンツ鍵Kcd、コンテンツID及び許諾条件を含むライセンスファイルを生成する(S6)。ユーザ鍵Kuを乱数によって生成すると(S7)、ユーザ鍵Kuを用いてライセンスファイルを暗号化し(S8)、ユーザ鍵Kuを、デバイス鍵Kdを用いて暗号化する(S9)。暗号化されたユーザ鍵KuをKudとする。そして、暗号化されたライセンスファイルとユーザ鍵Kudとをアーカイブする(S10)。そのファイル名をLicence.zipとする。
それから、リプロポリシーメタデータに、ターゲットレイヤの配信パッケージが課金コンテンツであることを示すパラメータを埋め込み(S11)、ダウンロードメタデータに、課金コンテンツのファイルContents.zipをダウンロードするURI(Uniform Resource Identifier)情報と、ライセンスファイルLicence.zipをダウンロードするURI情報とを埋め込む(S12)。
ここで、リプロポリシーメタデータ及びダウンロードメタデータについて説明する。以下、前者をRPメタデータと称し、後者をDLメタデータと称する。RPメタデータは、配信パッケージの構成情報、言い換えればパッケージの構成種別を表す情報を含んだ情報であり、車両側でそのデータの内容をチェックすることでパッケージの配信ミスを防止することを主眼とする情報である。また、DLメタデータは、データを取得するための制御情報が格納されており、言い換えれば、複数のターゲットとなるECU24ごとの更新データをダウンロードするための情報を、OTAマスタ22が把握できるようにするための内容を規定する情報である。これらのメタデータを、配信,マスタ及びターゲットの3層構造にすることで、転送方式やプラットフォームのタイプ、配信パッケージの種類が増大した場合でも、それらを柔軟に定義して対応することができ、ターゲット装置のデータ更新を行うことが可能になる。
≪リプロポリシーメタデータ≫
図8に示すRPメタデータは、配信パッケージのダウンロードに先立って、OTAセンタ1よりOTAマスタ22に送信される。
<RPメタデータバージョン>
RPメタデータのバージョンであり、例えば「1.0.0」や「2.0.0」などのバージョン情報が格納される。
図8に示すRPメタデータは、配信パッケージのダウンロードに先立って、OTAセンタ1よりOTAマスタ22に送信される。
<RPメタデータバージョン>
RPメタデータのバージョンであり、例えば「1.0.0」や「2.0.0」などのバージョン情報が格納される。
<通信レイヤ>
OTAセンタ1との通信に使用されるプロトコル,例えばUptane(登録商標)やOMA-DM(Open Mobile Alliance-Device Management)等を示す情報や、通信手段がOTAマスタ22であることを示す「セルラー」や、その他後述するスマートホンやUSBメモリであること等の情報が格納される。
OTAセンタ1との通信に使用されるプロトコル,例えばUptane(登録商標)やOMA-DM(Open Mobile Alliance-Device Management)等を示す情報や、通信手段がOTAマスタ22であることを示す「セルラー」や、その他後述するスマートホンやUSBメモリであること等の情報が格納される。
<マスタレイヤ>
OTAマスタ22について、そのプラットフォーム(PF)が、例えばAP,CP,AGL(Automotive Grade Linux),Android(登録商標)であること等を示す情報が格納される。ECUのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人JASPARの仕様では、標準化団体AUTOSARの静的OSで動作するクラシックプラットフォーム(CP)に適用可能なデータ要件が規定されている。また、AUTOSARでは、動的OSで動作する新たなタイプのアダプティブプラットフォーム(AP)に適用可能なデータ要件が規定されている。AGLは、車載Linux(登録商標)であり、Androidは、Android Automotive OSである。
OTAマスタ22について、そのプラットフォーム(PF)が、例えばAP,CP,AGL(Automotive Grade Linux),Android(登録商標)であること等を示す情報が格納される。ECUのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人JASPARの仕様では、標準化団体AUTOSARの静的OSで動作するクラシックプラットフォーム(CP)に適用可能なデータ要件が規定されている。また、AUTOSARでは、動的OSで動作する新たなタイプのアダプティブプラットフォーム(AP)に適用可能なデータ要件が規定されている。AGLは、車載Linux(登録商標)であり、Androidは、Android Automotive OSである。
ここで、APとCPとの違いについて説明する。AP及びCPはソフトウェアプラットフォームを表している。ソフトウェアプラットフォームは、ソフトウェアアーキテクチャとも呼ばれる。CPは、AUTOSAR Classic Platformを表し、APはAUTOSAR Adaptive Platformを表す。さらに、CP仕様書に準拠して動作するECUをCP ECU又はCPのECUと表記し、AP仕様書に準拠して動作するECUをAP ECU又はAPのECUと表記することがある。
AP及びCPにおいては、使用されるオペレーティングシステム,いわゆるOSや開発言語が異なる。CP ECUとAP ECUは、受信できるパッケージの構造が異なる。これらのパッケージの構造の違いは、主にECUの処理性能の違いに起因するものであり、一般的にCPのECUの処理性能は低いため、パッケージに含まれる諸元データなどもバイナリデータで記載されており、処理性能の低いECUでも解釈・処理しやすいパッケージデータ構造となっている。
一方、APのECUは処理性能が高いものが用いられるため、何らかの言語で記述された構造的な文字データを解析してプログラムで扱えるデータ構造に変換するパーサー機能を搭載することが可能であり、データ構造には単純なバイナリデータではなく、例えばJSON(JavaScript Object Notation)のようなオブジェクト指向のデータ形式を採用できるため、柔軟なパッケージデータ構造となっている。
制御方式については、特定のフォーマットに従い設定されたパラメータに応じて処理する「パラメータ」や、特定のフォーマットがなくより自由な記載形式で処理する「スクリプト」等の情報が格納される。
<ターゲットレイヤ>
ターゲットECU33に対応した情報である。PF,制御方式については、前述したものと同様である。転送方式は、ストレージ、ストリーミングの何れかである。課金方式は、当該コンテンツの利用が有料、無料の何れであるかを示す。ターゲットIDは、ターゲットECU24に対応したIDであるが、ここに格納するのはオプションである。
ターゲットECU33に対応した情報である。PF,制御方式については、前述したものと同様である。転送方式は、ストレージ、ストリーミングの何れかである。課金方式は、当該コンテンツの利用が有料、無料の何れであるかを示す。ターゲットIDは、ターゲットECU24に対応したIDであるが、ここに格納するのはオプションである。
≪ダウンロードメタデータ≫
図9及び図10に示すDLメタデータは、RPメタデータに続いてOTAセンタ1よりOTAマスタ22に送信される。それぞれ、転送方式がストレージ、ストリーミングの場合を示す。
図9及び図10に示すDLメタデータは、RPメタデータに続いてOTAセンタ1よりOTAマスタ22に送信される。それぞれ、転送方式がストレージ、ストリーミングの場合を示す。
<配信レイヤ>
例えば通信プロトコルがUptaneであれば、Uptaneメタデータを取得するための情報であり、それに対応したURI,データ名,データサイズ,ハッシュ値,ターゲットID,転送方式等が格納される。
例えば通信プロトコルがUptaneであれば、Uptaneメタデータを取得するための情報であり、それに対応したURI,データ名,データサイズ,ハッシュ値,ターゲットID,転送方式等が格納される。
<マスタ/ターゲットレイヤ>
図10に示すストリーミング方式の場合、マスタレイヤはライセンスファイルLicence.zipを取得するための情報であり、ターゲットレイヤはコンテンツファイルContents.zipを取得するための情報である。一方、図9に示すストレージ方式の場合は、マスタレイヤにおいて双方のファイルを取得するための情報が埋め込まれるので、ターゲットレイヤは必須ではない。ターゲットレイヤを設けても良いが、情報としてはnull又はブランクとなる。各項目は配信レイヤと同様である。尚、各項目には、「xxx」や「zzz」等が重複的に記載されているものがあるが、それらが同一の値を示しているわけではない。
図10に示すストリーミング方式の場合、マスタレイヤはライセンスファイルLicence.zipを取得するための情報であり、ターゲットレイヤはコンテンツファイルContents.zipを取得するための情報である。一方、図9に示すストレージ方式の場合は、マスタレイヤにおいて双方のファイルを取得するための情報が埋め込まれるので、ターゲットレイヤは必須ではない。ターゲットレイヤを設けても良いが、情報としてはnull又はブランクとなる。各項目は配信レイヤと同様である。尚、各項目には、「xxx」や「zzz」等が重複的に記載されているものがあるが、それらが同一の値を示しているわけではない。
再び、図6を参照する。配信サーバ3は、PKG生成サーバ2から、Contents.zipファイル、Licence.zipファイル、DLメタデータは及びRPメタデータを受け取る(S13)。尚、Licence.zipファイルは車両毎に異なるが、その他のファイル、データは車両モデルで共通である。次に、配信サーバ3は、CDN21に接続されているサーバに、Contents.zipファイル、DLメタデータ及びRPメタデータを格納する(S14)。
それから、OTAマスタ22から車両構成情報を同期させるための通知を受け取ったタイミングで、対応する車両が課金コンテンツの配信対象であることをVINから特定する(S15)。車両構成情報は、車両に搭載されるECUのハードウェア及びソフトウェアに関する識別情報であり、複数のECUから成るシステム構成の識別情報や、複数のシステムから成る車両構成の識別情報も含まれる。「同期させるための通知」とは、車両側に保持されている構成情報の内容と、OTAセンタ1側が保持している構成情報の内容とを一致させる、つまり同期させるために行われる通知である。
例えば、OTAマスタ22は、イグニッションがオンされたタイミングでOTAセンタ1と車両構成情報を同期させた後の経過時間を調べ、所定期間が経過している場合は、OTAセンタ1との車両構成情報の同期が必要であると判断する。または、OTAマスタ22は、OTAセンタ1からプッシュ通知を受けているか否かを調べ、プッシュ通知を受けている場合は、OTAセンタ1との車両構成情報の同期が必要であると判断する。これらの場合に、車両に搭載されるECUに対して、車両構成情報をOTAマスタ22に送信するように要求する。OTAマスタ22は、収集した車両構成情報をOTAセンタ1に通知する。
OTAセンタ1は、課金処理センタ33から、ユーザが購入した課金コンテンツのIDと対応する車両のVINを通知され、保存している。また、図示しないOEMサーバから、非課金コンテンツとも称する課金コンテンツ以外のソフトウェアについて、ソフトウェア更新の対象となる車両のVINを通知され、保存している。
S15では、VINに基づいて、(1)非課金コンテンツの更新あり、(2)課金コンテンツの更新あり、(3)課金コンテンツの更新と非課金コンテンツの更新あり、または(4)更新なし、を判断する。本開示では、課金コンテンツの更新があった場合のみを説明する。
S15では、VINに基づいて、(1)非課金コンテンツの更新あり、(2)課金コンテンツの更新あり、(3)課金コンテンツの更新と非課金コンテンツの更新あり、または(4)更新なし、を判断する。本開示では、課金コンテンツの更新があった場合のみを説明する。
そして、対象車両に、車両側システム23やユーザのスマートホンに表示させるプログラム更新に関する情報であるキャンペーン通知を配信する際に、その通知にDLメタデータ及びRPメタデータのURI情報を埋め込む(S16)。対象車両からのアクセスがあれば当該車両にLicence.zipファイルを送信する(S17)。尚、ユーザ鍵Kuとコンテンツ鍵Kcとは、例えばステップS14において消去しても良い。
図11に示すように、OTAマスタ22は、OTAセンタ1の配信サーバ3よりキャンペーン通知を受信すると(S21)、キャンペーン通知に記載されたURI情報に従いRPメタデータをCDN21から取得して、配信の予定があるパッケージに課金コンテンツが含まれているかチェックする(S22)。課金コンテンツが含まれていなければ(S23;NO)、OTAマスタ22は、例えば特願2021-32593号に開示されている方式に従い、ターゲットECU24に対するソフトウェアの更新を行う(S33)。
一方、課金コンテンツが含まれていれば(S23;YES)Licence.zipファイルを配信サーバ3より取得し(S24)、Licence.zipファイルを解凍すると、暗号化されたライセンスファイルとユーザ鍵Kudとを取り出す(S25)。そして、OTAマスタ22が保持しているデバイス鍵Kdでユーザ鍵Kudを復号化して、ユーザ鍵Kuを取り出す(S26)。すると、ユーザ鍵Kuを用いて、暗号化されたライセンスファイルを復号化する(S27)。
次に、ライセンスファイルに含まれているコンテンツ鍵Kcdを、デバイス鍵Kdで復号化してコンテンツ鍵Kcを取り出すと(S28)、ライセンスファイル中のコンテンツ鍵Kcdを、コンテンツ鍵Kcに置換える(S29)。ここでは、ライセンスファイル中のコンテンツ鍵Kcdを、コンテンツ鍵Kcに上書きする。そして、DLメタデータ及びContents.zipファイルをCDN21から取得すると(S30,S31)、DLメタデータから、コンテンツの配信先であるターゲットECU24を特定する。そのターゲットECU24に、更新対象のソフトウェアが課金コンテンツであることを通知して、Contents.zipファイル及びライセンスファイルを転送する(S32)。
尚、ステップS41に替えて、OTAマスタ22からContents.zipファイル及びライセンスファイルを受信したことを、OTAマスタ22から更新対象ソフトウェアが課金コンテンツであることの通知としても良い。この場合、OTAマスタ22からContents.zipファイル及びライセンスファイルを受信すれば、ターゲットECU24は、課金コンテンツがあると判断してステップS42以降の処理を行う。
図12に示すように、ターゲットECU24は、OTAマスタ22から更新対象ソフトウェアが課金コンテンツであることの通知を受信したか否かを判断する(S41)。通知を受信しなければ(NO)、例えば特願2021-32593に開示されている方式に従い、自身のソフトウェア更新を行う(S46)。一方、前記の通知を受信すると(S41;YES)、OTAマスタ22からContents.zipファイル及びライセンスファイルを受信する(S42)。そして、ライセンスファイルからコンテンツ鍵Kcを取り出し、コンテンツ鍵Kcで課金コンテンツを復号化する(S43)。
次に、ライセンスファイルに含まれている許諾条件を読み取り、その条件を満たしているか否かを判断する(S44)。許諾条件を満たしていれば(YES)、課金コンテンツのインストール処理を実行する(S45)。許諾条件を満たしていなければ(NO)、OTAマスタ22に許諾条件を満たしていない旨のエラー応答を返す(S47)。許諾条件は、例えば課金処理が完了していることや、課金コンテンツの利用期間、残りの利用回数などである。許諾条件は1つであっても良いし、複数あっても良い。複数ある場合は、全ての許諾条件が満たされていることが要求される。但し、少なくとも1つの許諾条件が満たされていれば、課金コンテンツを利用できるとしても良い。
図13に示すように、ターゲットECU24は、インストールした課金コンテンツのアプリケーションを起動する際には、その時点で許諾条件を満たしているか否かをチェックする(S48)。許諾条件を満たしていれば(YES)、そのままアプリケーションを起動して実行する(S49)。許諾条件を満たしていなければ(NO)、ステップS47と同様の処理を行う(S50)。
尚、説明の都合上ターゲットECU24を1つとしたが、ターゲットECU24が複数ある場合には、各ターゲットECU24について同様の処理を行えば良い。以降の実施形態についても同様である。ターゲットECU24が複数ある場合には、RPメタデータ、DLメタデータにおいて、複数のターゲットECU24に関する情報が記載される。
以上のように本実施形態によれば、OTAセンタ1において、コンテンツ鍵生成機能部5は、課金コンテンツを保護するためのコンテンツ鍵Kcを生成し、ユーザ鍵生成機能部6は、課金コンテンツのユーザに対応するユーザ鍵Kuを生成する。コンテンツ暗号化部は、コンテンツ鍵Kcを用いてコンテンツを暗号化し、コンテンツ鍵暗号化機能部10は、コンテンツ鍵Kcを、各車両に対応するデバイス鍵Kdを用いて暗号化する。そして、ファイル暗号化機能部8は、少なくとも課金コンテンツを利用するための条件を含むライセンスファイルを、ユーザ鍵Kuを用いて暗号化する。コンテンツ鍵Kcとユーザ鍵Kuとは、OTAセンタ1にて保存されることなく消去される。
このように構成すれば、OTAセンタ1は、各車両に対応するデバイス鍵Kdだけを管理すれば良いので、管理する鍵の数が少なくなる。また、課金コンテンツはコンテンツ鍵Kcによって保護され、そのコンテンツ鍵Kcを利用するには、コンテンツのユーザに紐付いているユーザ鍵Kuと各車両に紐付いているデバイス鍵Kdとが必要になるから、課金コンテンツは3重の鍵で保護される。そして、課金コンテンツを車両側で利用する際には、予め利用条件を満たす手続きを行ない、車両側でデバイス鍵Kdを用いて順次必要な復号化を行うようにすれば良い。
したがって、OTAセンタ1は、課金コンテンツを柔軟且つ確実に保護することができる。また、ライセンスファイルを用いることで、コンテンツを利用するための条件を柔軟に設定できる。加えて、車両側では、OTAセンタ1との通信が可能な状態でなくても、例えばスマートホンを経由させてコンテンツを取得することで利用が可能になる。また、ユーザ鍵暗号化機能部11は、デバイス鍵Kdを用いてユーザ鍵Kcを暗号化するので、コンテンツの保護レベルを更に向上させることができる。
そして、ライセンスファイルには、課金コンテンツを利用するための許諾条件と、デバイス鍵Kdを用いて暗号化されたコンテンツ鍵Kcと、課金コンテンツのIDとが含まれる。これにより、ユーザ鍵Kuを用いてライセンスファイルを復号化すれば、課金コンテンツを利用するための許諾条件を確認することができる。そして、許諾条件を満たした上で、デバイス鍵Kdを用いてコンテンツ鍵Kcを復号化すれば、その鍵Kcを用いて課金コンテンツを復号化できる。更に、ライセンスファイルには暗号化パラメータが含まれるので、それぞれの鍵を用いて行われた暗号化に関する詳細な情報を、ライセンスファイルより得ることができる。
また、OTAマスタ22のアンパック機能部26は、Licence.zipファイルを受信すると、そのファイルを解凍して暗号化されたライセンスファイル及びユーザ鍵Kudを取り出す。ユーザ鍵復号化機能部28は、デバイス鍵Kdを用いて、ユーザ鍵Kudからユーザ鍵Kuを復号化する。ライセンスファイル復号化機能部27は、ユーザ鍵Kuを用いてライセンスファイルを復号化する。コンテンツ鍵復号化機能部29は、デバイス鍵Kdを用いて、ライセンスファイルに含まれているコンテンツ鍵Kcを復号化する。そして、Contents.zipファイルを受信すると、そのファイル及びコンテンツ鍵Kcを含むライセンスファイルをターゲットECU24に転送する。
ターゲットECU24は、コンテンツ鍵Kcをもちいて課金コンテンツを復号化する。これにより、車両システム23側で必要な復号化を行ない、ターゲットECU24において課金コンテンツを利用できる。
尚、車両側システムがSOTA(Software OTA)に対応することも想定される。SOTAでは、例えば1つのECU上に、ナビアプリ(ver1.0)やゲームアプリ(ver2.0)、ビデオアプリ(ver3.5)等複数のアプリケーションが搭載されている状態で、それぞれのアプリケーションを個別にアップデートできるようになる。例えば、課金コンテンツアプリがエージェントサービスアプリ(ver1.0)であれば、課金ユーザのみに対して、エージェントアプリ(ver1.0→ver2.0)だけをアップデートをすることが可能になる。
尚、課金コンテンツの経済的価値等の属性に応じて、ライセンスファイルが改竄されていないかチェックするようにしても良い。ライセンスファイルに対して、改竄チェックができるようにしても良い。または、ライセンスファイルの許諾条件など一部の項目に対して、改竄チェックができるようにしてもよい。例えば、OTAセンタ1において、改竄チェック対象のデータからMAC値を算出し、ライセンスファイルとともに、またはライセンスファイルの中に算出したMAC値を入れる。そして、ターゲットECU24でも、MAC値を算出し、OTAセンタ1より提供されたMAC値と比較することで改竄されていないか確認しても良い。これにより、悪意のある第3者が許諾条件を改竄し、許諾条件を満たしていないにもかかわらず課金コンテンツが利用できるようになる事態を回避できる。
本実施形態の方式とSOTAとを組み合わせることで、例えば下記のようなことが実現できる。車両AがコンテンツA及びBを契約し、車両BがコンテンツCを契約しているとする。OTAセンタでパッケージを生成する際に、コンテンツA(ナビアプリ)、コンテンツB(ゲームアプリ)、コンテンツC(ビデオアプリ)を纏めて、1つのパッケージとする。この時、コンテンツA~Cは、それぞれコンテンツ鍵A~Cで暗号化する。
パッケージは車両モデル共通で、複数の車両が同じパッケージをCDN経由で受信する。つまり、車両A、B共に同じファイルを受信する。DLメタデータの「3.マスタレイヤ」のlincense.zipにおいて、車両が契約しているアプリに対応して指定を行う。車両AならコンテンツA及びBに対応して、2つのlicense.zipで指定する。車両BならコンテンツCに対応して1つのlicense.zipで指定する。DLメタデータに従い、車両AはコンテンツAのlicense.zip及びコンテンツBのlicense.zipを取得し、車両BはコンテンツCのlicense.zipを取得する。
パッケージは車両モデル共通で、複数の車両が同じパッケージをCDN経由で受信する。つまり、車両A、B共に同じファイルを受信する。DLメタデータの「3.マスタレイヤ」のlincense.zipにおいて、車両が契約しているアプリに対応して指定を行う。車両AならコンテンツA及びBに対応して、2つのlicense.zipで指定する。車両BならコンテンツCに対応して1つのlicense.zipで指定する。DLメタデータに従い、車両AはコンテンツAのlicense.zip及びコンテンツBのlicense.zipを取得し、車両BはコンテンツCのlicense.zipを取得する。
車両Aは、車両Aに対応するユーザ鍵とデバイス鍵とを持つので、ライセンスファイルからコンテンツ鍵A及びBを取得する。鍵Cはライセンスファイルに含まれないので、暗号化されたコンテンツCを受信しても利用できない。一方、車両Bは、車両Bに対応するユーザ鍵とデバイス鍵とを持つので、ライセンスファイルからコンテンツ鍵Cを取得し、コンテンツCのみ利用できる。
(第2実施形態)
以下、第1実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。第2実施形態では、デバイス鍵Kdに替えて、ECUデバイス鍵Kdeを生成して使用する。そのため、図14に示すOTAセンタ1AのPKG生成サーバ2と、図15に示すOTAマスタ22Aとは、それぞれECUデバイス鍵生成機能部33、34を備えている。
以下、第1実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。第2実施形態では、デバイス鍵Kdに替えて、ECUデバイス鍵Kdeを生成して使用する。そのため、図14に示すOTAセンタ1AのPKG生成サーバ2と、図15に示すOTAマスタ22Aとは、それぞれECUデバイス鍵生成機能部33、34を備えている。
図17に示すように、OTAセンタ1AのPKG生成サーバ2は、ステップS1~S3を実行すると、更新対象であるターゲットECU24のIDをDLメタデータから取得する(S51)。そして、デバイス鍵KdとターゲットECU24のIDとから、ターゲットECU24に特有のECUデバイス鍵KdeをランタイムでPKG生成サーバ2内部の実行処理により生成する(S52)。
ECUデバイス鍵Kdeは、例えばデバイス鍵Kdの値とターゲットECU24のIDの値とを加算した結果に、ハッシュ関数を適用する等して生成する。また、加算に替えて、両者の値を連結したものにハッシュ関数を適用しても良い。ECUデバイス鍵Kdeは、装置対応デバイス鍵に相当する。それから、ECUデバイス鍵Kdeを用いてコンテンツ鍵Kcを暗号化することで、コンテンツ鍵Kcdeを生成する(S53)。
ECUデバイス鍵Kdeの生成方法は、例えば、ECUデバイス鍵生成機能部33、34にオンコーディングとも称するハードコーディングしてもよい。この場合、デバイス鍵Kdの値とターゲットECU24のIDの値を、どのように処理してハッシュ関数を適用するかについて、ECUデバイス鍵Kdeを生成する方法が1つ指定される。または、RPメタデータのマスタレイヤの項目に、ECUデバイス鍵Kdeを生成する方法を記載しても良い。
続いて、ステップS5~S8を実行すると、ユーザ鍵Kuを、ECUデバイス鍵Kdeを用いて暗号化してユーザ鍵Kudeを生成する(S54)。そして、暗号化されたライセンスファイルとユーザ鍵Kudeとをアーカイブして、Licence.zipファイルを生成する(S55)。尚、ステップS6aでは、暗号化されたコンテンツ鍵がKcdeとなる。それから、ステップS11~S17を実行する。
図18に示すように、OTAマスタ22Aは、ステップS21~S25aを実行する。ステップS25aでは、取り出すユーザ鍵がKudeとなる。そして、自身が保持しているデバイス鍵Kdの値にターゲットECU24のIDの値を加算した結果に、ハッシュ関数を適用してECUデバイス鍵Kdeを生成する(S56)。そのECUデバイス鍵Kdeを用いて、ユーザ鍵Kudeからユーザ鍵Kuを復号化して取り出す(S57)。
続いて、ステップS27を実行すると、暗号化されたコンテンツ鍵KcdeをECUデバイス鍵Kdeで復号化してコンテンツ鍵Kcを取り出す(S58)。それから、ステップS29a~S32を実行する。ステップS29aでは、コンテンツ鍵Kcdeをコンテンツ鍵Kcに置き換える。尚、ターゲットECU24で行う処理は、第1実施形態と同じである。
以上のように第2実施形態によれば、OTAセンタ1AのECUデバイス鍵生成機能部33は、デバイス鍵Kdと、ターゲットECU24のIDとに基づいてECUデバイス鍵Kdeを生成する。具体的には、デバイス鍵Kdの値とターゲットECU24のIDの値とを加算した結果、又は両者の値を連結したものにハッシュ関数を適用してECUデバイス鍵Kdeを生成する。そして、第1実施形態のデバイス鍵Kdに替えて、ECUデバイス鍵Kdeを用いて必要な暗号化を行なう。それに応じて、OTAマスタ22AでもOTAセンタ1Aと同様にECUデバイス鍵Kdeを生成し、必要な復号化を行なう。このように、各ターゲットECU24に対応して生成されたECUデバイス鍵Kdeを用いることで、セキュリティレベルをより向上させることができる。
ECUデバイス鍵Kdeは、ターゲットECU24のIDとデバイス鍵Kdの値に基づいて生成されるので、OTAセンタ1Aにおいては、OTAマスタ22Aの台数分のデバイス鍵Kdの値を管理するだけで済む。1台の車両に複数のECUが搭載される状況では、車両台数分の鍵を管理するのか、ECU台数分の鍵を管理するのかでは、管理コストが顕著に異なる。
(第3実施形態)
第3実施形態では、デバイス鍵Kdに替えて、予めターゲットECU24毎に用意されているデバイス鍵Kdtを使用する。デバイス鍵Kdtは、予め各ターゲットECU24に書き込まれている。図19に示す車両側システム23Bでは、OTAマスタ22Bよりライセンスファイル復号化機能部27及びユーザ鍵復号化機能部28が削除されている。それに替えてターゲットECU24B側に、ライセンスファイル復号化機能部35及びユーザ鍵復号化機能部36が設けられている。
第3実施形態では、デバイス鍵Kdに替えて、予めターゲットECU24毎に用意されているデバイス鍵Kdtを使用する。デバイス鍵Kdtは、予め各ターゲットECU24に書き込まれている。図19に示す車両側システム23Bでは、OTAマスタ22Bよりライセンスファイル復号化機能部27及びユーザ鍵復号化機能部28が削除されている。それに替えてターゲットECU24B側に、ライセンスファイル復号化機能部35及びユーザ鍵復号化機能部36が設けられている。
図21に示すように、OTAセンタ1のPKG生成サーバ2は、ステップS1及びS2を実行すると、配信サーバ2のデバイスユニーク鍵管理機能部15より、ターゲットECU24毎に用意されているデバイス鍵Kdtを取得する(S61)。そして、コンテンツ鍵Kcを、デバイス鍵Kdtを用いて暗号化し、コンテンツ鍵Kcdtを生成する(S62)。
続いて、ステップS5及びS6bを実行する。ステップS6bは、コンテンツ鍵KcdがKcdtに置き変わっている。更に、ステップS7及びS8を実行すると、ユーザ鍵Kuを、デバイス鍵Kdtを用いて暗号化し、ユーザ鍵Kudtとする(S63)。そして、暗号化されたライセンスファイルとユーザ鍵Kudtとをアーカイブし、そのファイル名をLicence.zipとする(S64)。それから、ステップS11~S17を実行する。
図22に示すように、OTAマスタ22Bは、ステップS21~S24を実行すると、次にステップS30~S32を実行する。
図22に示すように、OTAマスタ22Bは、ステップS21~S24を実行すると、次にステップS30~S32を実行する。
図23に示すように、ターゲットECU24は、OTAマスタ22Bから更新対象ソフトウェアが課金コンテンツであることの通知を受信すると(S41;YES)、OTAマスタ22BからContents.zipファイル及びLicence.zipファイルを受信する(S65)。そして、Licence.zipファイルを解凍すると、暗号化されたライセンスファイルと、ユーザ鍵Kudtとを取り出す(S66)。
次に、ユーザ鍵Kudtを、自身が保持しているデバイス鍵Kdtで復号化してユーザ鍵Kuを取り出すと(S67)、ユーザ鍵Kuを用いて、暗号化されたライセンスファイルを復号化する(S68)。そして、ライセンスファイルからコンテンツ鍵Kcdtを取り出し、デバイス鍵Kdtで復号化してコンテンツ鍵Kcを取り出すと(S69)、コンテンツ鍵Kcで課金コンテンツを復号化する(S70)。
ライセンスファイルに含まれている許諾条件を読み取り、その条件を満たしていれば(S48;YES)、課金コンテンツのインストール処理を実行する(S45)。許諾条件を満たしていなければ(NO)、OTAマスタ22Bに許諾条件を満たしていない旨のエラー応答を返す(S47)。インストールした課金コンテンツのアプリケーションを起動する際の処理は、第1実施形態と同様である。
尚、ステップS66で行うLicence.zipファイルの解凍をOTAマスタ22Bで行い、暗号化されたライセンスファイルとユーザ鍵KudtとをターゲットECU24に転送しても良い。また、複数のターゲットECU24Bがある場合には、ターゲットECU24B毎にライセンスファイルが作成される。
以上のように第3実施形態によれば、OTAセンタ1のデバイスユニーク鍵管理機能部15は、ターゲットECU24毎に用意されているデバイス鍵Kdtを保持する。ターゲットECU24は、暗号化されたライセンスファイル及びユーザ鍵Kudtを受信すると、ユーザ鍵Kudtよりデバイス鍵Kdtを用いてユーザ鍵Kuを復号化する。そして、ユーザ鍵Kuを用いてライセンスファイルを復号化する。また、デバイス鍵Kdtを用いて、ライセンスファイルに含まれているコンテンツ鍵Kcdtよりコンテンツ鍵Kcを復号化する。更に、コンテンツ鍵Kcを用いて暗号化された課金コンテンツを復号化する。
すなわち、課金コンテンツは、暗号化された状態でターゲットECU24に転送されて、ターゲットECU24において復号化されるので、セキュリティレベルを更に向上させることができる。
(その他の実施形態)
ユーザ鍵Kuを、デバイス鍵Kdを用いて暗号化する処理は、必要に応じて行えば良い。
コンテンツの利用制限は、課金の有無に限らない。例えば、車種や車両グレードに応じてコンテンツの利用に制限をかけても良い。
コンテンツの利用制限は、ユーザの利用に際して利用制限をかけることのほか、車両に搭載されたシステムやアプリケーションがコンテンツを利用する際に利用制限をかけても良い。
ユーザ鍵Kuを、デバイス鍵Kdを用いて暗号化する処理は、必要に応じて行えば良い。
コンテンツの利用制限は、課金の有無に限らない。例えば、車種や車両グレードに応じてコンテンツの利用に制限をかけても良い。
コンテンツの利用制限は、ユーザの利用に際して利用制限をかけることのほか、車両に搭載されたシステムやアプリケーションがコンテンツを利用する際に利用制限をかけても良い。
本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
各装置等が提供する手段および/または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。
本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。
Claims (37)
- コンテンツを保護するためのコンテンツ鍵を生成するコンテンツ鍵生成部(5)と、
前記コンテンツを利用するユーザに対応するユーザ鍵を生成するユーザ鍵生成部(6)と、
各車両に対応するデバイス鍵を管理するデバイス鍵管理部(15)と、
前記コンテンツを、前記コンテンツ鍵を用いて暗号化するコンテンツ暗号化部(8)と、
前記コンテンツ鍵を、前記デバイス鍵を用いて暗号化するコンテンツ鍵暗号化部(10)と、
少なくとも前記コンテンツを利用するための条件を含むライセンスファイルを、前記ユーザ鍵を用いて暗号化するファイル暗号化部(9)とを備えるセンタ装置。 - 前記ユーザ鍵を、前記デバイス鍵を用いて暗号化するユーザ鍵暗号化部(11)を備える請求項1記載のセンタ装置。
- 前記ライセンスファイルには、前記コンテンツを利用するための許諾条件と、
前記デバイス鍵を用いて暗号化されたコンテンツ鍵と、
前記コンテンツを識別するための識別情報とが含まれている請求項1又は2記載のセンタ装置。 - 前記ライセンスファイルには、暗号化を行なうための情報である暗号化パラメータが含まれている請求項3記載のセンタ装置。
- 車両に送信する配信パッケージを生成するパッケージ生成部(2)を備え、
前記パッケージ生成部は、前記コンテンツ鍵生成部、前記ユーザ鍵生成部、前記コンテンツ暗号化部、前記コンテンツ鍵暗号化部及び前記ファイル暗号化部としての機能も備えている請求項1から4の何れか一項に記載のセンタ装置。 - 暗号化された前記ライセンスファイル及び暗号化された前記ユーザ鍵を含む圧縮ファイルを生成する圧縮ファイル生成部(4)を備える請求項1から5の何れか一項に記載のセンタ装置。
- 暗号化されたコンテンツを、CDN(Contents Delivery Network;21)を経由して車両に配信するコンテンツ配信部(12)を備える請求項1から6の何れか一項に記載のセンタ装置。
- 前記デバイス鍵管理部は、前記デバイス鍵を、各車両に付与されている車両識別情報毎に保持する請求項1から7の何れか一項に記載のセンタ装置。
- 前記車両識別情報毎に保持しているデバイス鍵と、各車両に配置されている電子制御装置であり前記コンテンツの転送先である対象装置の識別情報とに基づいて、装置対応デバイス鍵を生成するデバイス鍵生成部(33)を備える請求項8記載のセンタ装置。
- 前記デバイス鍵生成部は、前記車両識別情報毎に保持しているデバイス鍵の値に、前記識別情報の値を加算した結果にハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項9記載のセンタ装置。
- 前記デバイス鍵生成部は、前記車両識別情報毎に保持しているデバイス鍵と、前記識別情報とを連結したデータにハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項9記載のセンタ装置。
- 前記デバイス鍵管理部は、前記デバイス鍵を、各車両に配置されている電子制御装置であり、前記コンテンツの転送先である対象装置毎に保持する請求項1から7の何れか一項に記載のセンタ装置。
- 車両に配置され、請求項8記載のセンタ装置と通信を行う通信部(25)と、
この通信部が受信したデータを、電子制御装置であり前記コンテンツの転送先である対象装置に転送するマスタ装置(22)と、
前記対象装置(24)とを備え、
前記マスタ装置は、前記デバイス鍵を保持しており、
暗号化されたライセンスファイル及びユーザ鍵を受信すると、前記ユーザ鍵を用いてライセンスファイルを復号化するライセンスファイル復号部(27)と、
前記デバイス鍵を用いて、前記ライセンスファイルに含まれているコンテンツ鍵を復号化するコンテンツ鍵復号部(29)と、
前記コンテンツを含むデータファイルを受信すると、前記データファイル及びコンテンツ鍵を含むライセンスファイルを前記対象装置に転送する転送部とを備える車両側システム。 - 車両に配置され、請求項9から11の何れか一項に記載のセンタ装置と通信を行う通信部(25)と、
この通信部が受信したデータを、電子制御装置であり前記コンテンツの転送先である対象装置に転送するマスタ装置(22)と、
前記対象装置とを備え、
前記マスタ装置は、前記デバイス鍵と前記対象装置の識別情報とに基づいて、装置対応デバイス鍵を生成するデバイス鍵生成部(34)を備え、
暗号化されたライセンスファイル及びユーザ鍵を受信すると、前記ユーザ鍵を用いてライセンスファイルを復号化するライセンスファイル復号部(27)と、
前記装置対応デバイス鍵を用いて、前記ライセンスファイルに含まれているコンテンツ鍵を復号化するコンテンツ鍵復号部(29)と、
前記コンテンツを含むデータファイルを受信すると、前記データファイル及びコンテンツ鍵を含むライセンスファイルを前記対象装置に転送する転送部とを備える車両側システム。 - 車両に配置され、請求項12記載のセンタ装置と通信を行う通信部(25)と、
この通信部が受信したデータを、電子制御装置であり前記コンテンツの転送先である対象装置に転送するマスタ装置(22)と、
前記対象装置(24)とを備え、
前記対象装置は、前記デバイス鍵を保持しており、
暗号化されたライセンスファイル及びユーザ鍵を受信すると、前記ユーザ鍵を用いてライセンスファイルを復号化するライセンスファイル復号部(35)と、
前記デバイス鍵を用いて、前記ライセンスファイルに含まれているコンテンツ鍵を復号化するコンテンツ鍵復号部(36)と、
前記コンテンツを含むデータファイルを受信すると、前記コンテンツ鍵を用いて前記コンテンツを復号化するコンテンツを復号部(31)とを備える車両側システム。 - コンテンツを保護するためのコンテンツ鍵を生成し、
前記コンテンツを利用するユーザに対応するユーザ鍵を生成し、
前記コンテンツを、前記コンテンツ鍵を用いて暗号化し、
前記コンテンツ鍵を、前記各車両に対応するデバイス鍵を用いて暗号化し、
少なくとも前記コンテンツを利用するための条件を含むライセンスファイルを、前記ユーザ鍵を用いて暗号化するコンテンツの保護方法。 - 前記ユーザ鍵を、前記デバイス鍵を用いて暗号化する請求項16記載のコンテンツの保護方法。
- 前記ライセンスファイルに、前記コンテンツを利用するための許諾条件と、
前記デバイス鍵を用いて暗号化されたコンテンツ鍵と、
前記コンテンツを識別するための識別情報とを含む請求項16又は17記載のコンテンツの保護方法。 - 前記ライセンスファイルに、更に暗号化を行なうための情報である暗号化パラメータを含む請求項18記載のコンテンツの保護方法。
- 暗号化された前記ライセンスファイル及び暗号化された前記ユーザ鍵を含む圧縮ファイルを生成する請求項16から19の何れか一項に記載のコンテンツの保護方法。
- 暗号化されたコンテンツを、CDN(Contents Delivery Network)を経由して車両に配信する請求項16から20の何れか一項に記載のコンテンツの保護方法。
- 前記デバイス鍵は、各車両に付与されている車両識別情報毎にある請求項16から21の何れか一項に記載のコンテンツの保護方法。
- 前記車両識別情報毎にあるデバイス鍵と、各車両に配置されている電子制御装置であり前記コンテンツの転送先である対象装置の識別情報とに基づいて装置対応デバイス鍵を生成する請求項22記載のコンテンツの保護方法。
- 前記車両識別情報毎にあるデバイス鍵の値に、前記識別情報の値を加算した結果にハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項23記載のコンテンツの保護方法。
- 前記車両識別情報毎にあるデバイス鍵と、前記識別情報とを連結したデータにハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項23記載のコンテンツの保護方法。
- 前記デバイス鍵は、各車両に配置されている電子制御装置であり、前記コンテンツの転送先である対象装置毎にある請求項16から21の何れか一項に記載のコンテンツの保護方法。
- 車両と通信を行いコンテンツを配信するセンタ装置が備えるコンピュータにより実行されるコンテンツ保護用プログラムであって、
コンテンツを保護するためのコンテンツ鍵を生成させ、
前記コンテンツを利用するユーザに対応するユーザ鍵を生成させ、
前記コンテンツを、前記コンテンツ鍵を用いて暗号化させ、
前記コンテンツ鍵を、前記各車両に対応するデバイス鍵を用いて暗号化させ、
少なくとも前記コンテンツを利用するための条件を含むライセンスファイルを、前記ユーザ鍵を用いて暗号化させるコンテンツ保護用プログラム。 - 前記ユーザ鍵を、前記デバイス鍵を用いて暗号化させる請求項27記載のコンテンツ保護用プログラム。
- 前記ライセンスファイルに、前記コンテンツを利用するための許諾条件と、
前記デバイス鍵を用いて暗号化されたコンテンツ鍵と、
前記コンテンツを識別するための識別情報とを含ませる請求項28記載のコンテンツ保護用プログラム。 - 前記ライセンスファイルに、暗号化を行なうための情報である暗号化パラメータを含ませる請求項29記載のコンテンツ保護用プログラム。
- 暗号化された前記ライセンスファイル及び暗号化された前記ユーザ鍵を含む圧縮ファイルを生成させる請求項27から30の何れか一項に記載のコンテンツ保護用プログラム。
- 暗号化されたコンテンツを、CDN(Contents Delivery Network)を経由して車両に配信させる請求項27から31の何れか一項に記載のコンテンツ保護用プログラム。
- 前記デバイス鍵は、各車両に付与されている車両識別情報毎にある請求項27から32の何れか一項に記載のコンテンツ保護用プログラム。
- 前記車両識別情報毎にあるデバイス鍵と、各車両に配置されている電子制御装置であり前記コンテンツの転送先である対象装置の識別情報とに基づいて装置対応デバイス鍵を生成させる請求項33記載のコンテンツ保護用プログラム。
- 前記車両識別情報毎にあるデバイス鍵の値に、前記識別情報の値を加算した結果にハッシュ関数を適用して前記装置対応デバイス鍵を生成させる請求項34記載のコンテンツ保護用プログラム。
- 前記車両識別情報毎にあるデバイス鍵と、前記識別情報とを連結したデータにハッシュ関数を適用して前記装置対応デバイス鍵を生成させる請求項34記載のコンテンツ保護用プログラム。
- 前記デバイス鍵は、各車両に配置されている電子制御装置であり、前記コンテンツの転送先である対象装置毎にある請求項27から32の何れか一項に記載のコンテンツ保護用プログラム。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202280047292.7A CN117597683A (zh) | 2021-08-06 | 2022-07-26 | 中心装置、车辆侧***、内容的保护方法以及内容保护用程序 |
DE112022003868.3T DE112022003868T5 (de) | 2021-08-06 | 2022-07-26 | Zentrumsgerät, fahrzeugseitiges System, Inhaltsschutzverfahren und Inhaltsschutzprogramm |
JP2023540273A JPWO2023013471A1 (ja) | 2021-08-06 | 2022-07-26 | |
US18/425,796 US20240169076A1 (en) | 2021-08-06 | 2024-01-29 | Center apparatus, vehicle-side system, content protection method, and storage medium storing content protection program |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021129943 | 2021-08-06 | ||
JP2021-129943 | 2021-08-06 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/425,796 Continuation US20240169076A1 (en) | 2021-08-06 | 2024-01-29 | Center apparatus, vehicle-side system, content protection method, and storage medium storing content protection program |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023013471A1 true WO2023013471A1 (ja) | 2023-02-09 |
Family
ID=85154499
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/028744 WO2023013471A1 (ja) | 2021-08-06 | 2022-07-26 | センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム |
Country Status (5)
Country | Link |
---|---|
US (1) | US20240169076A1 (ja) |
JP (1) | JPWO2023013471A1 (ja) |
CN (1) | CN117597683A (ja) |
DE (1) | DE112022003868T5 (ja) |
WO (1) | WO2023013471A1 (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013088845A (ja) * | 2011-10-13 | 2013-05-13 | Sony Corp | 情報処理装置、情報処理方法およびコンピュータプログラム |
JP2013142994A (ja) * | 2012-01-10 | 2013-07-22 | Clarion Co Ltd | 情報配信方法、情報配信システムおよび車載端末 |
JP2020092289A (ja) * | 2018-12-03 | 2020-06-11 | 大日本印刷株式会社 | 機器統合システム及び更新管理システム |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH03276424A (ja) | 1990-03-26 | 1991-12-06 | Toppan Printing Co Ltd | 光カードの記録再生装置 |
JP7163886B2 (ja) | 2019-08-19 | 2022-11-01 | 株式会社デンソー | 測定装置 |
JP2021129943A (ja) | 2020-02-21 | 2021-09-09 | 株式会社三共 | 遊技機 |
-
2022
- 2022-07-26 DE DE112022003868.3T patent/DE112022003868T5/de active Pending
- 2022-07-26 JP JP2023540273A patent/JPWO2023013471A1/ja active Pending
- 2022-07-26 WO PCT/JP2022/028744 patent/WO2023013471A1/ja active Application Filing
- 2022-07-26 CN CN202280047292.7A patent/CN117597683A/zh active Pending
-
2024
- 2024-01-29 US US18/425,796 patent/US20240169076A1/en active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013088845A (ja) * | 2011-10-13 | 2013-05-13 | Sony Corp | 情報処理装置、情報処理方法およびコンピュータプログラム |
JP2013142994A (ja) * | 2012-01-10 | 2013-07-22 | Clarion Co Ltd | 情報配信方法、情報配信システムおよび車載端末 |
JP2020092289A (ja) * | 2018-12-03 | 2020-06-11 | 大日本印刷株式会社 | 機器統合システム及び更新管理システム |
Also Published As
Publication number | Publication date |
---|---|
JPWO2023013471A1 (ja) | 2023-02-09 |
CN117597683A (zh) | 2024-02-23 |
DE112022003868T5 (de) | 2024-05-29 |
US20240169076A1 (en) | 2024-05-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11895109B2 (en) | Securely provisioning a target device | |
US10855460B2 (en) | In-vehicle computer system, vehicle, key generation device, management method, key generation method, and computer program | |
CN109787774B (zh) | 基于数字签名校验的升级下载方法、装置、服务器及终端 | |
EP3334085B1 (en) | Management device, management system, key generation device, key generation system, key management system, vehicle, management method, key generation method, and computer program | |
CN105706048B (zh) | 使用硬件信任根的媒体客户端装置鉴权 | |
CN111279310A (zh) | 一种车载设备升级方法及相关设备 | |
WO2021093334A1 (zh) | 车辆升级包处理方法和装置 | |
CA3116067A1 (en) | Techniques for improving security of encrypted vehicle software updates | |
CN103677891A (zh) | 用于选择性软件回退的方法 | |
CN102662692A (zh) | 一种电子控制单元中应用程序的更新方法及*** | |
EP2345000A1 (en) | Technique for content management using group rights | |
CN102163153A (zh) | 用户终端、服务器及其控制方法 | |
WO2023142385A1 (zh) | 一种仪表***与娱乐主机***多屏传输方法、装置及车辆 | |
CN114880011A (zh) | Ota升级方法、装置、电子设备及可读存储介质 | |
CN112311799B (zh) | 一种Tbox固件的OTA安全升级方法 | |
CN111064723B (zh) | 一种基于备份***的空中下载升级方法及*** | |
WO2023013471A1 (ja) | センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム | |
US20140133650A1 (en) | License Administration Device and License Administration Method | |
CN114339676A (zh) | 一种针对无人驾驶设备的更新***、方法及装置 | |
US20240119763A1 (en) | In-vehicle communication system, data structure of reprogramming policy metadata, and data structure of download metadata | |
US20240069889A1 (en) | Systems and methods for automatically updating system firmware | |
JP2013046122A (ja) | 端末、アプリ保護方法及びプログラム | |
US20240111519A1 (en) | Onboard communication system, center device, vehicle-side system, and method for verifying update data of onboard communication | |
JP7464013B2 (ja) | センタ、otaマスタ、方法、プログラム、及び車両 | |
RU2812276C2 (ru) | Способ установки вычислительного компонента и сопутствующее электронное устройство |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22852894 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2023540273 Country of ref document: JP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 202280047292.7 Country of ref document: CN |