WO2023013471A1

WO2023013471A1 - センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム

Info

Publication number: WO2023013471A1
Application number: PCT/JP2022/028744
Authority: WO
Inventors: 英朗吉見; 基誠二神; 朝也小川; 真晃安部; 古都東松
Original assignee: 株式会社デンソー
Priority date: 2021-08-06
Filing date: 2022-07-26
Publication date: 2023-02-09
Also published as: JPWO2023013471A1; CN117597683A; DE112022003868T5; US20240169076A1

Abstract

本開示の一態様は、ＯＴＡセンタ１において、コンテンツ鍵生成機能部５は、課金コンテンツを保護するためのコンテンツ鍵Ｋｃを生成し、ユーザ鍵生成機能部６は、課金コンテンツのユーザに対応するユーザ鍵Ｋｕを生成する。コンテンツ暗号化部は、コンテンツ鍵Ｋｃを用いてコンテンツを暗号化し、コンテンツ鍵暗号化機能部１０は、コンテンツ鍵Ｋｃを、各車両に対応するデバイス鍵Ｋｄを用いて暗号化する。ファイル暗号化機能部８は、少なくとも課金コンテンツを利用するための条件を含むライセンスファイルを、ユーザ鍵Ｋｕを用いて暗号化する。

Description

センタ装置、車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラム

関連出願の相互参照

　本出願は、２０２１年８月６日に出願された日本出願番号２０２１－１２９９４３号に基づくもので、ここにその記載内容を援用する。

　本開示は、車両にコンテンツを配信するセンタ装置、そのセンタ装置と通信を行なう車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラムに関する。

　近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムを書換える，所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献１には、サーバよりＥＣＵの更新プログラムをＯＴＡ（Over The Air）により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。

　また、更新プログラムに限ることなく、ユーザが有料で利用できるデジタルコンテンツについても、同様にＯＴＡによって装置に配信することも行われている。上記のように利用制限がかけられているコンテンツを、課金コンテンツと称する。現在運用されているシステムでは、課金コンテンツか、それ以外のコンテンツかに関らず、全てのソフトウェアを車両に配信している。課金コンテンツを利用するユーザは、所定の手続を経て課金を行うことで、コンテンツの配信元であるセンタが管理している課金フラグを有効にしておく。そして、課金コンテンツが配信された車両はセンタに問い合わせを行い、課金フラグが有効になっていれば課金コンテンツが利用可能になる。

特開２０２０－２７６４２４号公報

　現状のシステムでは、センタに課金状態の問い合わせを行うことが前提となっているため、車両がセンタと通信可能な状態になければ、課金コンテンツを利用可能にすることができない。

　本開示は上記事情に鑑みてなされたものであり、その目的は、利用制限がかけられているコンテンツを、より柔軟な形態で利用可能にできるセンタ装置、そのセンタ装置と通信を行なう車両側システム、コンテンツの保護方法及びコンテンツ保護用プログラムを提供することにある。

　請求項１記載のセンタ装置によれば、コンテンツ鍵生成部は、利用に際して利用制限をかけることが可能なコンテンツを保護するためのコンテンツ鍵を生成し、ユーザ鍵生成部は、コンテンツのユーザに対応するユーザ鍵を生成する。コンテンツ暗号化部は、コンテンツ鍵を用いてコンテンツを暗号化し、コンテンツ鍵暗号化部は、コンテンツ鍵を、各車両に対応するデバイス鍵を用いて暗号化する。そして、ファイル暗号化部は、少なくともコンテンツを利用するための条件を含むライセンスファイルを、ユーザ鍵を用いて暗号化する。

　このように構成すれば、センタ装置は、各車両に対応するデバイス鍵だけを管理すれば良いので、管理する鍵の数が少なくなる。また、利用制限をかけることが可能なコンテンツは、コンテンツ鍵によって保護され、そのコンテンツ鍵を利用するには、コンテンツのユーザに紐付いているユーザ鍵と各車両に紐付いているデバイス鍵とが必要になる。つまり、コンテンツは２重の鍵によって保護されることになる。そして、利用制限がかけられているコンテンツを車両側で利用する際には、予め利用条件を満たす手続きを行ない、車両側でデバイス鍵を用いて順次必要な復号化を行うようにすれば良い。

　したがって、センタ装置は、利用制限がかけられたコンテンツを柔軟且つ確実に保護することができる。また、ライセンスファイルを用いることで、コンテンツを利用するための条件を柔軟に設定できる。加えて、車両側では、センタ装置との通信が可能な状態でなくても、コンテンツの利用が可能になる。

　請求項２記載のセンタ装置によれば、ユーザ鍵暗号化部は、デバイス鍵を用いてユーザ鍵を暗号化するので、コンテンツは３重の鍵によって保護されることになり、コンテンツの保護レベルを更に向上させることができる。

　請求項３記載のセンタ装置によれば、ライセンスファイルには、コンテンツを利用するための許諾条件と、デバイス鍵を用いて暗号化されたコンテンツ鍵と、コンテンツを識別するための識別情報とが含まれる。これにより、ユーザ鍵を用いてライセンスファイルを復号化すれば、コンテンツを利用するための許諾条件を確認することができる。そして、許諾条件を満たした上で、デバイス鍵を用いてコンテンツ鍵を復号化すれば、その鍵を用いて識別情報に対応したコンテンツを復号化できる。

　請求項４記載のセンタ装置によれば、ライセンスファイルには、更に暗号化を行なうための情報である暗号化パラメータが含まれる。これにより、それぞれの鍵を用いて行われた暗号化に関する詳細な情報を、ライセンスファイルより得ることができる。

　本開示についての上記目的およびその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図１は、第１実施形態において、ＯＴＡセンタを中心に示す機能ブロック図であり、図２は、車両側システムを中心に示す機能ブロック図であり、図３は、課金コンテンツの利用ケースを説明する図であり、図４は、ＯＴＡセンタ側で行う処理を概念的に示す図であり、図５は、ＯＴＡセンタ、ＯＴＡマスタ、ターゲットＥＣＵ間で行われる処理を概念的に示す図であり、図６は、ＯＴＡセンタが行う処理を示すフローチャートであり、図７は、暗号化パラーメータの一例を示す図であり、図８は、リプロポリシーメタデータの一例を示す図であり、図９は、ストレージ方式に対応したダウンロードメタデータの一例を示す図であり、図１０は、ストリーミング方式に対応したダウンロードメタデータの一例を示す図であり、図１１は、ＯＴＡマスタが行う処理を示すフローチャートであり、図１２は、ターゲットＥＣＵが行う処理を示すフローチャート（その１）であり、図１３は、ターゲットＥＣＵが行う処理を示すフローチャート（その２）であり、図１４は、第２実施形態において、ＯＴＡセンタを中心に示す機能ブロック図であり、図１５は、車両側システムを中心に示す機能ブロック図であり、図１６は、ＯＴＡセンタ、ＯＴＡマスタ、ターゲットＥＣＵ間で行われる処理を概念的に示す図であり、図１７は、ＯＴＡセンタが行う処理を示すフローチャートであり、図１８は、ＯＴＡマスタが行う処理を示すフローチャートであり、図１９は、第３実施形態において、車両側システムを中心に示す機能ブロック図であり、図２０は、ＯＴＡセンタ、ＯＴＡマスタ、ターゲットＥＣＵ間で行われる処理を概念的に示す図であり、図２１は、ＯＴＡセンタが行う処理を示すフローチャートであり、図２２は、ＯＴＡマスタが行う処理を示すフローチャートであり、図２３は、ターゲットＥＣＵが行う処理を示すフローチャートである。

　　（第１実施形態）
　図１に示すように、センタ装置である本実施形態のＯＴＡセンタ１は、ＰＫＧ生成サーバ２及び配信サーバ３を備えている。ＰＫＧ生成サーバ２は、大別して暗号化に用いる鍵やデータパッケージ等を生成する機能部分と、暗号化・署名を行う機能部分とがある。前者には、ライセンスファイル生成機能部４、コンテンツ鍵生成機能部５、ユーザ鍵生成機能部６、ＰＫＧ生成機能部７がある。また、後者には、コンテンツ暗号化機能部８、ライセンスファイル暗号化機能部９、コンテンツ鍵暗号化機能部１０、ユーザ鍵暗号化機能部１１がある。尚、「ＰＫＧ」は「パッケージ」を意味する。

　コンテンツ鍵生成機能部５は、課金対象コンテンツの識別情報であるＩＤに対応したコンテンツ鍵Ｋｃを例えば乱数によって生成する。以下、課金対象コンテンツを「課金コンテンツ」と称する。ユーザ鍵生成機能部６は、課金コンテンツのユーザに対応するユーザ鍵Ｋｕを例えば乱数によって生成する。ライセンスファイル生成機能部４は、課金コンテンツのＩＤやコンテンツ鍵Ｋｃ、及び課金コンテンツを利用するための許諾条件等が格納されたライセンスファイルを生成する。ＰＫＧ生成機能部７は、暗号化された課金コンテンツ等を含む配信パッケージを生成する。尚、ユーザがコンテンツを利用する際に、課金が行われていることを条件とすることは、その利用を制限する一態様である。

　課金コンテンツには、コンテンツそのものが課金される場合もあれば、コンテンツ内課金のように、コンテンツの一部について課金が行われていることを条件とする場合も含む。尚、コンテンツとは、例えば、アプリ、アプリが使用するデータ、またはアプリを介して乗員に提供されるサービスを意味する。よって、コンテンツとは、例えば、車室内にて視聴するビデオや音楽、ゲームアプリ、車両制御に関わる車両制御アプリ、地図データ、ナビゲーションアプリ、及びサービスの利用権限等である。

　コンテンツ暗号化機能部８は、課金コンテンツを所定の暗号化方式に従い、コンテンツ鍵Ｋｃを用いて暗号化する。コンテンツ鍵暗号化機能部１０は、コンテンツ鍵Ｋｃを、デバイス鍵Ｋｄを用いて暗号化する。ユーザ鍵暗号化機能部１１は、ユーザ鍵Ｋｕを、同じくデバイス鍵Ｋｄを用いて暗号化する。ライセンスファイル暗号化機能部９は、ライセンスファイルを、ユーザ鍵Ｋｕを用いて暗号化する。

　配信サーバ３は、配信管理機能部１２、キャンペーン管理機能部１３、ソフトウェア管理機能部１４、デバイスユニーク鍵管理機能部１５を備えている。デバイスユニーク鍵管理機能部１５は、例えばＶＩＮ（Vehicle Identification Number）のように各車両に付与されている識別情報に対応してユニークに割り当てられたデバイス鍵Ｋｄを管理する。ソフトウェア管理機能部１４は、課金コンテンツ等のソフトウェアをＩＤと共に管理する。キャンペーン管理機能部１３は、課金コンテンツ等を含むプログラム更新に関する情報であるキャンペーン情報を管理する。配信管理機能部１２は、ＰＫＧ生成機能部７により生成された配信パッケージ等を、通信キャリアやＣＤＮ（Contents Delivery Network）２１等を介して車両側のＯＴＡマスタ２２に配信する。

　図２に示すように、車両側システム２３は、ＯＴＡマスタ２２及びターゲットＥＣＵ２４を備えている。ＯＴＡマスタ２２は、配信サーバ３等と通信を行う図３に示すＤＣＭ（Data Communication Module）２２Ａや、ターゲットＥＣＵ２４と通信を行なうセントラルＥＣＵ２２Ｂを含んで構成される。ＯＴＡマスタ２２は、ダウンロード機能部２５、アンパック機能部２６、ライセンスファイル復号化機能部２７、ユーザ鍵復号化機能部２８、コンテンツ鍵復号化機能部２９及びデバイスユニーク鍵管理機能部３０を備えている。

　ダウンロード機能部２５は、ＯＴＡセンタ１の配信サーバ３と直接、又はＣＤＮ２１を介して通信を行なうことで、データファイルやパッケージ等をダウンロードする。アンパック機能部２６は、受信したデータパッケージが圧縮ファイルであれば解凍して必要なデータを抽出する。デバイスユニーク鍵管理機能部３０には、車両のＶＩＮに対応したデバイス鍵Ｋｄが製造段階で書き込まれている。ユーザ鍵復号化機能部２８は、デバイス鍵Ｋｄを用いてユーザ鍵Ｋｕを復号化する。ライセンスファイル復号化機能部２７は、ユーザ鍵Ｋｕを用いてライセンスファイルを復号化する。コンテンツ鍵復号化機能部２９は、デバイス鍵Ｋｄを用いてコンテンツ鍵Ｋｃを復号化する。

　ＯＴＡマスタ２２は、コンテンツを含む暗号化された状態のデータパッケージと、ライセンスファイルとをターゲットＥＣＵ２４に転送する。ターゲットＥＣＵ２４は、１つ以上存在しており、コンテンツ復号化機能部３１及び許諾条件チェック機能部３２を備えている。許諾条件チェック機能部３２は、ライセンスファイルに含まれているコンテンツの許諾条件を満たしているか否かをチェックする。コンテンツ復号化機能部３１は、前記の許諾条件を満たしている際に、ライセンスファイルに含まれているコンテンツ鍵Ｋｃを用いてコンテンツを復号化する。
　以上のＯＴＡセンタ１及びＯＴＡマスタ２２における各機能ブロックは、コンピュータのハードウェア及びソフトウェアの協働により実現されている。

　尚、ＯＴＡマスタ２２の各機能部を、ＤＣＭ２２ＡとセントラルＥＣＵ２２Ｂの間でどのように機能分担するかは特に制限がない。ＯＴＡマスタ２２の機能の一部又は全体をセントラルＥＣＵ２２Ｂが有する構成でも良いし、ＯＴＡマスタ２２の機能の一部又は全体をＤＣＭ２２Ａが有する構成でも良い。即ち、ＯＴＡマスタ２２において、ＤＣＭ２２ＡとセントラルＥＣＵ２２Ｂとの機能分担がどのように構成されていても良い。ＯＴＡマスタ２２は、ＤＣＭ２２Ａ及びセントラルＥＣＵ２２Ｂの２つのＥＣＵから構成されても良いし、ＤＣＭ２２Ａの機能とセントラルＥＣＵ２２Ｂの機能とを有する１つの統合ＥＣＵで構成されても良い。

　図３に示すように、ユーザは、課金コンテンツを利用する際には、スマートホンや車両側システム２３のＨＭＩ（Human Machine Interface）を介して課金処理センタ３３と通信を行なう。課金処理センタ３３は、課金システム３４や会員情報データベース３５、車両情報データベース３６等を備えている。ユーザは、課金コンテンツを購入する手続きを行なうと、課金コンテンツをダウンロードする方式を選択する。例えばＯＴＡマスタ２１にダウンロードするか、スマートホンやＳＤカードにダウンロードするか等を選択する。ＳＤカードは、外部記憶媒体の一例に相当する。

　課金処理センタ３３は、ユーザが購入した課金コンテンツのＩＤと対応する車両のＶＩＮとをＯＴＡセンタ１に送信する。ＯＴＡセンタ１では、前述のように課金コンテンツ及びライセンスファイルを暗号化して、ダウンロード方式が「ＯＴＡ」であれば車両側システム２３にそれらをダウンロードさせる。図中の「ネットワークキャリア」は、通信を配信サーバ３と直接、又はＣＤＮ２１を介して行なうケースを含んでいる。尚、同図では、ＯＴＡマスタ２２を、ＤＣＭ２２Ａ及びＣ－ＥＣＵ２２Ｂとして示している。

　ＯＴＡセンタ１において、課金処理センタ３３は、ユーザが購入した課金コンテンツのＩＤと対応する車両のＶＩＮとを受信すると、課金コンテンツ及びライセンスファイルの暗号化を行う。加えて、ＰＫＧ生成サーバ２は、車両側システム２３の、例えばＤＣＭ２２Ａに対してプッシュ通知を行う。ＤＣＭ２２Ａは、イグニッションがオフされた状態でもプッシュ通知を受け取ることができるように構成されている。よって、ＤＣＭ２２Ａは、イグニッションの状態に関係なくＯＴＡセンタ１からプッシュ通知を受信する。このプッシュ通知は、ＯＴＡマスタ２２が車両構成情報をＯＴＡセンタ１と同期するトリガとなる。

　図４に示すように、ＯＴＡセンタで生成されるライセンスファイルには、デバイス鍵Ｋｄで暗号化されたコンテンツ鍵Ｋｃ、課金コンテンツのＩＤ、許諾条件と共に暗号化パラメータが含まれている。許諾条件は、例えば課金処理が完了していることや課金コンテンツの利用期間、残りの利用回数や他車両への転送が不可であること、等である。図７に示す暗号化パラメータは、暗号化及びデジタル署名に関連したパラメータである。暗号化パラメータは、コンテンツ鍵Ｋｃに関する暗号化パラメータと、ユーザ鍵Ｋｕに関する暗号化パラメータを含む。
・暗号化種別情報　　　：（共通鍵）ＡＥＳ（Advanced Encryption Standard），
　　　　　　　　　　　　　Ｔｒｉｐｌｅ－ＤＥＳ（Data Encryption Standard），
　　　　　　　　　（公開鍵）ＲＳＡ（Rivest-Shamir-Adleman cryptosystem），
　　　　　　　　　　　　　　ＥＣＣ（Elliptic Curve Cryptography）
・署名種別情報　　　　：（共通鍵）ＣＢＣ－ＭＡＣ
　　　　　　　　　　（Message Authentication Code），ＣＭＡＣ（Common MAC）
　　　　　　　　　　　　（公開鍵）ＤＳＡ（Digital Signature Algorithm）,
　　　　　　　　　　　　　　　　　ＥＣＤＳＡ（Elliptic Curve DSA）
・鍵ＩＤ情報　　　　　：鍵の特定に使用
・暗号モード種別情報　：Ｅｎｃ（Encrypt）　ｔｈｅｎ　ＭＡＣ，
　　　　　　　　　　　　ＭＡＣ　ｔｈｅｎ，ＥＮＣ
・保護対象情報　　　　：特定のファイル又はデータを指定
・保護領域指定情報　　：上記ファイルの全体又は一部を指定
・オフセットサイズ情報：先頭より何Byte目から保護対象とするか指定
・保護データサイズ情報：何Byteを保護するか指定

　次に、本実施形態の作用について説明する。図６に示すように、ＯＴＡセンタ１のＰＫＧ生成サーバ２は、課金対象コンテンツのＩＤに対応したコンテンツ鍵Ｋｃを乱数によって生成すると（Ｓ１）、課金コンテンツを所定の暗号化方式に従い、コンテンツ鍵Ｋｃを用いて暗号化する（Ｓ２）。暗号化された課金コンテンツのファイル名を、Contents.zipとする。続いて、配信サーバ３よりデバイス鍵Ｋｄを取得すると（Ｓ３）、コンテンツ鍵Ｋｃを、デバイス鍵Ｋｄを用いて暗号化する（Ｓ４）。暗号化されたコンテンツ鍵ＫｃをＫｃｄとする。

　次に、課金コンテンツの許諾条件が記載されたファイルを、配信サーバ３のソフトウェア管理機能部１４より取得すると（Ｓ５）、暗号化パラメータ、コンテンツ鍵Ｋｃｄ、コンテンツＩＤ及び許諾条件を含むライセンスファイルを生成する（Ｓ６）。ユーザ鍵Ｋｕを乱数によって生成すると（Ｓ７）、ユーザ鍵Ｋｕを用いてライセンスファイルを暗号化し（Ｓ８）、ユーザ鍵Ｋｕを、デバイス鍵Ｋｄを用いて暗号化する（Ｓ９）。暗号化されたユーザ鍵ＫｕをＫｕｄとする。そして、暗号化されたライセンスファイルとユーザ鍵Ｋｕｄとをアーカイブする（Ｓ１０）。そのファイル名をLicence.zipとする。

　それから、リプロポリシーメタデータに、ターゲットレイヤの配信パッケージが課金コンテンツであることを示すパラメータを埋め込み（Ｓ１１）、ダウンロードメタデータに、課金コンテンツのファイルContents.zipをダウンロードするＵＲＩ（Uniform Resource Identifier）情報と、ライセンスファイルLicence.zipをダウンロードするＵＲＩ情報とを埋め込む（Ｓ１２）。

　ここで、リプロポリシーメタデータ及びダウンロードメタデータについて説明する。以下、前者をＲＰメタデータと称し、後者をＤＬメタデータと称する。ＲＰメタデータは、配信パッケージの構成情報、言い換えればパッケージの構成種別を表す情報を含んだ情報であり、車両側でそのデータの内容をチェックすることでパッケージの配信ミスを防止することを主眼とする情報である。また、ＤＬメタデータは、データを取得するための制御情報が格納されており、言い換えれば、複数のターゲットとなるＥＣＵ２４ごとの更新データをダウンロードするための情報を、ＯＴＡマスタ２２が把握できるようにするための内容を規定する情報である。これらのメタデータを、配信，マスタ及びターゲットの３層構造にすることで、転送方式やプラットフォームのタイプ、配信パッケージの種類が増大した場合でも、それらを柔軟に定義して対応することができ、ターゲット装置のデータ更新を行うことが可能になる。

　　≪リプロポリシーメタデータ≫
　図８に示すＲＰメタデータは、配信パッケージのダウンロードに先立って、ＯＴＡセンタ１よりＯＴＡマスタ２２に送信される。
　　＜ＲＰメタデータバージョン＞
　ＲＰメタデータのバージョンであり、例えば「１．０．０」や「２．０．０」などのバージョン情報が格納される。

　　＜通信レイヤ＞
　ＯＴＡセンタ１との通信に使用されるプロトコル，例えばＵｐｔａｎｅ（登録商標）やＯＭＡ－ＤＭ（Open Mobile Alliance-Device Management）等を示す情報や、通信手段がＯＴＡマスタ２２であることを示す「セルラー」や、その他後述するスマートホンやＵＳＢメモリであること等の情報が格納される。

　　＜マスタレイヤ＞
　ＯＴＡマスタ２２について、そのプラットフォーム（ＰＦ）が、例えばＡＰ，ＣＰ，ＡＧＬ(Automotive Grade Linux)，Ａｎｄｒｏｉｄ（登録商標）であること等を示す情報が格納される。ＥＣＵのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人ＪＡＳＰＡＲの仕様では、標準化団体ＡＵＴＯＳＡＲの静的ＯＳで動作するクラシックプラットフォーム（ＣＰ）に適用可能なデータ要件が規定されている。また、ＡＵＴＯＳＡＲでは、動的ＯＳで動作する新たなタイプのアダプティブプラットフォーム（ＡＰ）に適用可能なデータ要件が規定されている。ＡＧＬは、車載Ｌｉｎｕｘ（登録商標）であり、Ａｎｄｒｏｉｄは、Android Automotive OSである。

　ここで、ＡＰとＣＰとの違いについて説明する。ＡＰ及びＣＰはソフトウェアプラットフォームを表している。ソフトウェアプラットフォームは、ソフトウェアアーキテクチャとも呼ばれる。ＣＰは、AUTOSAR Classic Platformを表し、ＡＰはAUTOSAR Adaptive Platformを表す。さらに、ＣＰ仕様書に準拠して動作するＥＣＵをＣＰ　ＥＣＵ又はＣＰのＥＣＵと表記し、ＡＰ仕様書に準拠して動作するＥＣＵをＡＰ　ＥＣＵ又はＡＰのＥＣＵと表記することがある。

　ＡＰ及びＣＰにおいては、使用されるオペレーティングシステム，いわゆるＯＳや開発言語が異なる。ＣＰ　ＥＣＵとＡＰ　ＥＣＵは、受信できるパッケージの構造が異なる。これらのパッケージの構造の違いは、主にＥＣＵの処理性能の違いに起因するものであり、一般的にＣＰのＥＣＵの処理性能は低いため、パッケージに含まれる諸元データなどもバイナリデータで記載されており、処理性能の低いＥＣＵでも解釈・処理しやすいパッケージデータ構造となっている。

　一方、ＡＰのＥＣＵは処理性能が高いものが用いられるため、何らかの言語で記述された構造的な文字データを解析してプログラムで扱えるデータ構造に変換するパーサー機能を搭載することが可能であり、データ構造には単純なバイナリデータではなく、例えばＪＳＯＮ（JavaScript Object Notation）のようなオブジェクト指向のデータ形式を採用できるため、柔軟なパッケージデータ構造となっている。

　制御方式については、特定のフォーマットに従い設定されたパラメータに応じて処理する「パラメータ」や、特定のフォーマットがなくより自由な記載形式で処理する「スクリプト」等の情報が格納される。

　　＜ターゲットレイヤ＞
　ターゲットＥＣＵ３３に対応した情報である。ＰＦ，制御方式については、前述したものと同様である。転送方式は、ストレージ、ストリーミングの何れかである。課金方式は、当該コンテンツの利用が有料、無料の何れであるかを示す。ターゲットＩＤは、ターゲットＥＣＵ２４に対応したＩＤであるが、ここに格納するのはオプションである。

　　≪ダウンロードメタデータ≫
　図９及び図１０に示すＤＬメタデータは、ＲＰメタデータに続いてＯＴＡセンタ１よりＯＴＡマスタ２２に送信される。それぞれ、転送方式がストレージ、ストリーミングの場合を示す。

　　＜配信レイヤ＞
　例えば通信プロトコルがＵｐｔａｎｅであれば、Ｕｐｔａｎｅメタデータを取得するための情報であり、それに対応したＵＲＩ，データ名，データサイズ，ハッシュ値，ターゲットＩＤ,転送方式等が格納される。

　　＜マスタ／ターゲットレイヤ＞
　図１０に示すストリーミング方式の場合、マスタレイヤはライセンスファイルLicence.zipを取得するための情報であり、ターゲットレイヤはコンテンツファイルContents.zipを取得するための情報である。一方、図９に示すストレージ方式の場合は、マスタレイヤにおいて双方のファイルを取得するための情報が埋め込まれるので、ターゲットレイヤは必須ではない。ターゲットレイヤを設けても良いが、情報としてはｎｕｌｌ又はブランクとなる。各項目は配信レイヤと同様である。尚、各項目には、「ｘｘｘ」や「ｚｚｚ」等が重複的に記載されているものがあるが、それらが同一の値を示しているわけではない。

　再び、図６を参照する。配信サーバ３は、ＰＫＧ生成サーバ２から、Contents.zipファイル、Licence.zipファイル、ＤＬメタデータは及びＲＰメタデータを受け取る（Ｓ１３）。尚、Licence.zipファイルは車両毎に異なるが、その他のファイル、データは車両モデルで共通である。次に、配信サーバ３は、ＣＤＮ２１に接続されているサーバに、Contents.zipファイル、ＤＬメタデータ及びＲＰメタデータを格納する（Ｓ１４）。

　それから、ＯＴＡマスタ２２から車両構成情報を同期させるための通知を受け取ったタイミングで、対応する車両が課金コンテンツの配信対象であることをＶＩＮから特定する（Ｓ１５）。車両構成情報は、車両に搭載されるＥＣＵのハードウェア及びソフトウェアに関する識別情報であり、複数のＥＣＵから成るシステム構成の識別情報や、複数のシステムから成る車両構成の識別情報も含まれる。「同期させるための通知」とは、車両側に保持されている構成情報の内容と、ＯＴＡセンタ１側が保持している構成情報の内容とを一致させる、つまり同期させるために行われる通知である。

　例えば、ＯＴＡマスタ２２は、イグニッションがオンされたタイミングでＯＴＡセンタ１と車両構成情報を同期させた後の経過時間を調べ、所定期間が経過している場合は、ＯＴＡセンタ１との車両構成情報の同期が必要であると判断する。または、ＯＴＡマスタ２２は、ＯＴＡセンタ１からプッシュ通知を受けているか否かを調べ、プッシュ通知を受けている場合は、ＯＴＡセンタ１との車両構成情報の同期が必要であると判断する。これらの場合に、車両に搭載されるＥＣＵに対して、車両構成情報をＯＴＡマスタ２２に送信するように要求する。ＯＴＡマスタ２２は、収集した車両構成情報をＯＴＡセンタ１に通知する。

　ＯＴＡセンタ１は、課金処理センタ３３から、ユーザが購入した課金コンテンツのＩＤと対応する車両のＶＩＮを通知され、保存している。また、図示しないＯＥＭサーバから、非課金コンテンツとも称する課金コンテンツ以外のソフトウェアについて、ソフトウェア更新の対象となる車両のＶＩＮを通知され、保存している。
　Ｓ１５では、ＶＩＮに基づいて、（１）非課金コンテンツの更新あり、（２）課金コンテンツの更新あり、（３）課金コンテンツの更新と非課金コンテンツの更新あり、または（４）更新なし、を判断する。本開示では、課金コンテンツの更新があった場合のみを説明する。

　そして、対象車両に、車両側システム２３やユーザのスマートホンに表示させるプログラム更新に関する情報であるキャンペーン通知を配信する際に、その通知にＤＬメタデータ及びＲＰメタデータのＵＲＩ情報を埋め込む（Ｓ１６）。対象車両からのアクセスがあれば当該車両にLicence.zipファイルを送信する（Ｓ１７）。尚、ユーザ鍵Ｋｕとコンテンツ鍵Ｋｃとは、例えばステップＳ１４において消去しても良い。

　図１１に示すように、ＯＴＡマスタ２２は、ＯＴＡセンタ１の配信サーバ３よりキャンペーン通知を受信すると（Ｓ２１）、キャンペーン通知に記載されたＵＲＩ情報に従いＲＰメタデータをＣＤＮ２１から取得して、配信の予定があるパッケージに課金コンテンツが含まれているかチェックする（Ｓ２２）。課金コンテンツが含まれていなければ（Ｓ２３；ＮＯ）、ＯＴＡマスタ２２は、例えば特願２０２１－３２５９３号に開示されている方式に従い、ターゲットＥＣＵ２４に対するソフトウェアの更新を行う（Ｓ３３）。

　一方、課金コンテンツが含まれていれば（Ｓ２３；ＹＥＳ）Licence.zipファイルを配信サーバ３より取得し（Ｓ２４）、Licence.zipファイルを解凍すると、暗号化されたライセンスファイルとユーザ鍵Ｋｕｄとを取り出す（Ｓ２５）。そして、ＯＴＡマスタ２２が保持しているデバイス鍵Ｋｄでユーザ鍵Ｋｕｄを復号化して、ユーザ鍵Ｋｕを取り出す（Ｓ２６）。すると、ユーザ鍵Ｋｕを用いて、暗号化されたライセンスファイルを復号化する（Ｓ２７）。

　次に、ライセンスファイルに含まれているコンテンツ鍵Ｋｃｄを、デバイス鍵Ｋｄで復号化してコンテンツ鍵Ｋｃを取り出すと（Ｓ２８）、ライセンスファイル中のコンテンツ鍵Ｋｃｄを、コンテンツ鍵Ｋｃに置換える（Ｓ２９）。ここでは、ライセンスファイル中のコンテンツ鍵Ｋｃｄを、コンテンツ鍵Ｋｃに上書きする。そして、ＤＬメタデータ及びContents.zipファイルをＣＤＮ２１から取得すると（Ｓ３０，Ｓ３１）、ＤＬメタデータから、コンテンツの配信先であるターゲットＥＣＵ２４を特定する。そのターゲットＥＣＵ２４に、更新対象のソフトウェアが課金コンテンツであることを通知して、Contents.zipファイル及びライセンスファイルを転送する（Ｓ３２）。

　尚、ステップＳ４１に替えて、ＯＴＡマスタ２２からContents.zipファイル及びライセンスファイルを受信したことを、ＯＴＡマスタ２２から更新対象ソフトウェアが課金コンテンツであることの通知としても良い。この場合、ＯＴＡマスタ２２からContents.zipファイル及びライセンスファイルを受信すれば、ターゲットＥＣＵ２４は、課金コンテンツがあると判断してステップＳ４２以降の処理を行う。

　図１２に示すように、ターゲットＥＣＵ２４は、ＯＴＡマスタ２２から更新対象ソフトウェアが課金コンテンツであることの通知を受信したか否かを判断する（Ｓ４１）。通知を受信しなければ（ＮＯ）、例えば特願２０２１－３２５９３に開示されている方式に従い、自身のソフトウェア更新を行う（Ｓ４６）。一方、前記の通知を受信すると（Ｓ４１；ＹＥＳ）、ＯＴＡマスタ２２からContents.zipファイル及びライセンスファイルを受信する（Ｓ４２）。そして、ライセンスファイルからコンテンツ鍵Ｋｃを取り出し、コンテンツ鍵Ｋｃで課金コンテンツを復号化する（Ｓ４３）。

　次に、ライセンスファイルに含まれている許諾条件を読み取り、その条件を満たしているか否かを判断する（Ｓ４４）。許諾条件を満たしていれば（ＹＥＳ）、課金コンテンツのインストール処理を実行する（Ｓ４５）。許諾条件を満たしていなければ（ＮＯ）、ＯＴＡマスタ２２に許諾条件を満たしていない旨のエラー応答を返す（Ｓ４７）。許諾条件は、例えば課金処理が完了していることや、課金コンテンツの利用期間、残りの利用回数などである。許諾条件は１つであっても良いし、複数あっても良い。複数ある場合は、全ての許諾条件が満たされていることが要求される。但し、少なくとも１つの許諾条件が満たされていれば、課金コンテンツを利用できるとしても良い。

　図１３に示すように、ターゲットＥＣＵ２４は、インストールした課金コンテンツのアプリケーションを起動する際には、その時点で許諾条件を満たしているか否かをチェックする（Ｓ４８）。許諾条件を満たしていれば（ＹＥＳ）、そのままアプリケーションを起動して実行する（Ｓ４９）。許諾条件を満たしていなければ（ＮＯ）、ステップＳ４７と同様の処理を行う（Ｓ５０）。

　尚、説明の都合上ターゲットＥＣＵ２４を１つとしたが、ターゲットＥＣＵ２４が複数ある場合には、各ターゲットＥＣＵ２４について同様の処理を行えば良い。以降の実施形態についても同様である。ターゲットＥＣＵ２４が複数ある場合には、ＲＰメタデータ、ＤＬメタデータにおいて、複数のターゲットＥＣＵ２４に関する情報が記載される。

　以上のように本実施形態によれば、ＯＴＡセンタ１において、コンテンツ鍵生成機能部５は、課金コンテンツを保護するためのコンテンツ鍵Ｋｃを生成し、ユーザ鍵生成機能部６は、課金コンテンツのユーザに対応するユーザ鍵Ｋｕを生成する。コンテンツ暗号化部は、コンテンツ鍵Ｋｃを用いてコンテンツを暗号化し、コンテンツ鍵暗号化機能部１０は、コンテンツ鍵Ｋｃを、各車両に対応するデバイス鍵Ｋｄを用いて暗号化する。そして、ファイル暗号化機能部８は、少なくとも課金コンテンツを利用するための条件を含むライセンスファイルを、ユーザ鍵Ｋｕを用いて暗号化する。コンテンツ鍵Ｋｃとユーザ鍵Ｋｕとは、ＯＴＡセンタ１にて保存されることなく消去される。

　このように構成すれば、ＯＴＡセンタ１は、各車両に対応するデバイス鍵Ｋｄだけを管理すれば良いので、管理する鍵の数が少なくなる。また、課金コンテンツはコンテンツ鍵Ｋｃによって保護され、そのコンテンツ鍵Ｋｃを利用するには、コンテンツのユーザに紐付いているユーザ鍵Ｋｕと各車両に紐付いているデバイス鍵Ｋｄとが必要になるから、課金コンテンツは３重の鍵で保護される。そして、課金コンテンツを車両側で利用する際には、予め利用条件を満たす手続きを行ない、車両側でデバイス鍵Ｋｄを用いて順次必要な復号化を行うようにすれば良い。

　したがって、ＯＴＡセンタ１は、課金コンテンツを柔軟且つ確実に保護することができる。また、ライセンスファイルを用いることで、コンテンツを利用するための条件を柔軟に設定できる。加えて、車両側では、ＯＴＡセンタ１との通信が可能な状態でなくても、例えばスマートホンを経由させてコンテンツを取得することで利用が可能になる。また、ユーザ鍵暗号化機能部１１は、デバイス鍵Ｋｄを用いてユーザ鍵Ｋｃを暗号化するので、コンテンツの保護レベルを更に向上させることができる。

　そして、ライセンスファイルには、課金コンテンツを利用するための許諾条件と、デバイス鍵Ｋｄを用いて暗号化されたコンテンツ鍵Ｋｃと、課金コンテンツのＩＤとが含まれる。これにより、ユーザ鍵Ｋｕを用いてライセンスファイルを復号化すれば、課金コンテンツを利用するための許諾条件を確認することができる。そして、許諾条件を満たした上で、デバイス鍵Ｋｄを用いてコンテンツ鍵Ｋｃを復号化すれば、その鍵Ｋｃを用いて課金コンテンツを復号化できる。更に、ライセンスファイルには暗号化パラメータが含まれるので、それぞれの鍵を用いて行われた暗号化に関する詳細な情報を、ライセンスファイルより得ることができる。

　また、ＯＴＡマスタ２２のアンパック機能部２６は、Licence.zipファイルを受信すると、そのファイルを解凍して暗号化されたライセンスファイル及びユーザ鍵Ｋｕｄを取り出す。ユーザ鍵復号化機能部２８は、デバイス鍵Ｋｄを用いて、ユーザ鍵Ｋｕｄからユーザ鍵Ｋｕを復号化する。ライセンスファイル復号化機能部２７は、ユーザ鍵Ｋｕを用いてライセンスファイルを復号化する。コンテンツ鍵復号化機能部２９は、デバイス鍵Ｋｄを用いて、ライセンスファイルに含まれているコンテンツ鍵Ｋｃを復号化する。そして、Contents.zipファイルを受信すると、そのファイル及びコンテンツ鍵Ｋｃを含むライセンスファイルをターゲットＥＣＵ２４に転送する。

ターゲットＥＣＵ２４は、コンテンツ鍵Ｋｃをもちいて課金コンテンツを復号化する。これにより、車両システム２３側で必要な復号化を行ない、ターゲットＥＣＵ２４において課金コンテンツを利用できる。

　尚、車両側システムがＳＯＴＡ（Software OTA）に対応することも想定される。ＳＯＴＡでは、例えば１つのＥＣＵ上に、ナビアプリ（ver1.0）やゲームアプリ（ver2.0）、ビデオアプリ（ver3.5）等複数のアプリケーションが搭載されている状態で、それぞれのアプリケーションを個別にアップデートできるようになる。例えば、課金コンテンツアプリがエージェントサービスアプリ（ver1.0）であれば、課金ユーザのみに対して、エージェントアプリ（ver1.0→ver2.0）だけをアップデートをすることが可能になる。

　尚、課金コンテンツの経済的価値等の属性に応じて、ライセンスファイルが改竄されていないかチェックするようにしても良い。ライセンスファイルに対して、改竄チェックができるようにしても良い。または、ライセンスファイルの許諾条件など一部の項目に対して、改竄チェックができるようにしてもよい。例えば、ＯＴＡセンタ１において、改竄チェック対象のデータからＭＡＣ値を算出し、ライセンスファイルとともに、またはライセンスファイルの中に算出したＭＡＣ値を入れる。そして、ターゲットＥＣＵ２４でも、ＭＡＣ値を算出し、ＯＴＡセンタ１より提供されたＭＡＣ値と比較することで改竄されていないか確認しても良い。これにより、悪意のある第３者が許諾条件を改竄し、許諾条件を満たしていないにもかかわらず課金コンテンツが利用できるようになる事態を回避できる。

　本実施形態の方式とＳＯＴＡとを組み合わせることで、例えば下記のようなことが実現できる。車両ＡがコンテンツＡ及びＢを契約し、車両ＢがコンテンツＣを契約しているとする。ＯＴＡセンタでパッケージを生成する際に、コンテンツＡ（ナビアプリ）、コンテンツＢ（ゲームアプリ）、コンテンツＣ（ビデオアプリ）を纏めて、１つのパッケージとする。この時、コンテンツＡ～Ｃは、それぞれコンテンツ鍵Ａ～Ｃで暗号化する。
　パッケージは車両モデル共通で、複数の車両が同じパッケージをＣＤＮ経由で受信する。つまり、車両Ａ、Ｂ共に同じファイルを受信する。ＤＬメタデータの「３．マスタレイヤ」のlincense.zipにおいて、車両が契約しているアプリに対応して指定を行う。車両ＡならコンテンツＡ及びＢに対応して、２つのlicense.zipで指定する。車両ＢならコンテンツＣに対応して１つのlicense.zipで指定する。ＤＬメタデータに従い、車両ＡはコンテンツＡのlicense.zip及びコンテンツＢのlicense.zipを取得し、車両ＢはコンテンツＣのlicense.zipを取得する。

　車両Ａは、車両Ａに対応するユーザ鍵とデバイス鍵とを持つので、ライセンスファイルからコンテンツ鍵Ａ及びＢを取得する。鍵Ｃはライセンスファイルに含まれないので、暗号化されたコンテンツＣを受信しても利用できない。一方、車両Ｂは、車両Ｂに対応するユーザ鍵とデバイス鍵とを持つので、ライセンスファイルからコンテンツ鍵Ｃを取得し、コンテンツＣのみ利用できる。

　　（第２実施形態）
　以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。第２実施形態では、デバイス鍵Ｋｄに替えて、ＥＣＵデバイス鍵Ｋｄｅを生成して使用する。そのため、図１４に示すＯＴＡセンタ１ＡのＰＫＧ生成サーバ２と、図１５に示すＯＴＡマスタ２２Ａとは、それぞれＥＣＵデバイス鍵生成機能部３３、３４を備えている。

　図１７に示すように、ＯＴＡセンタ１ＡのＰＫＧ生成サーバ２は、ステップＳ１～Ｓ３を実行すると、更新対象であるターゲットＥＣＵ２４のＩＤをＤＬメタデータから取得する（Ｓ５１）。そして、デバイス鍵ＫｄとターゲットＥＣＵ２４のＩＤとから、ターゲットＥＣＵ２４に特有のＥＣＵデバイス鍵ＫｄｅをランタイムでＰＫＧ生成サーバ２内部の実行処理により生成する（Ｓ５２）。

　ＥＣＵデバイス鍵Ｋｄｅは、例えばデバイス鍵Ｋｄの値とターゲットＥＣＵ２４のＩＤの値とを加算した結果に、ハッシュ関数を適用する等して生成する。また、加算に替えて、両者の値を連結したものにハッシュ関数を適用しても良い。ＥＣＵデバイス鍵Ｋｄｅは、装置対応デバイス鍵に相当する。それから、ＥＣＵデバイス鍵Ｋｄｅを用いてコンテンツ鍵Ｋｃを暗号化することで、コンテンツ鍵Ｋｃｄｅを生成する（Ｓ５３）。

　ＥＣＵデバイス鍵Ｋｄｅの生成方法は、例えば、ＥＣＵデバイス鍵生成機能部３３、３４にオンコーディングとも称するハードコーディングしてもよい。この場合、デバイス鍵Ｋｄの値とターゲットＥＣＵ２４のＩＤの値を、どのように処理してハッシュ関数を適用するかについて、ＥＣＵデバイス鍵Ｋｄｅを生成する方法が１つ指定される。または、ＲＰメタデータのマスタレイヤの項目に、ＥＣＵデバイス鍵Ｋｄｅを生成する方法を記載しても良い。

　続いて、ステップＳ５～Ｓ８を実行すると、ユーザ鍵Ｋｕを、ＥＣＵデバイス鍵Ｋｄｅを用いて暗号化してユーザ鍵Ｋｕｄｅを生成する（Ｓ５４）。そして、暗号化されたライセンスファイルとユーザ鍵Ｋｕｄｅとをアーカイブして、Licence.zipファイルを生成する（Ｓ５５）。尚、ステップＳ６ａでは、暗号化されたコンテンツ鍵がＫｃｄｅとなる。それから、ステップＳ１１～Ｓ１７を実行する。

　図１８に示すように、ＯＴＡマスタ２２Ａは、ステップＳ２１～Ｓ２５ａを実行する。ステップＳ２５ａでは、取り出すユーザ鍵がＫｕｄｅとなる。そして、自身が保持しているデバイス鍵Ｋｄの値にターゲットＥＣＵ２４のＩＤの値を加算した結果に、ハッシュ関数を適用してＥＣＵデバイス鍵Ｋｄｅを生成する（Ｓ５６）。そのＥＣＵデバイス鍵Ｋｄｅを用いて、ユーザ鍵Ｋｕｄｅからユーザ鍵Ｋｕを復号化して取り出す（Ｓ５７）。

　続いて、ステップＳ２７を実行すると、暗号化されたコンテンツ鍵ＫｃｄｅをＥＣＵデバイス鍵Ｋｄｅで復号化してコンテンツ鍵Ｋｃを取り出す（Ｓ５８）。それから、ステップＳ２９ａ～Ｓ３２を実行する。ステップＳ２９ａでは、コンテンツ鍵Ｋｃｄｅをコンテンツ鍵Ｋｃに置き換える。尚、ターゲットＥＣＵ２４で行う処理は、第１実施形態と同じである。

　以上のように第２実施形態によれば、ＯＴＡセンタ１ＡのＥＣＵデバイス鍵生成機能部３３は、デバイス鍵Ｋｄと、ターゲットＥＣＵ２４のＩＤとに基づいてＥＣＵデバイス鍵Ｋｄｅを生成する。具体的には、デバイス鍵Ｋｄの値とターゲットＥＣＵ２４のＩＤの値とを加算した結果、又は両者の値を連結したものにハッシュ関数を適用してＥＣＵデバイス鍵Ｋｄｅを生成する。そして、第１実施形態のデバイス鍵Ｋｄに替えて、ＥＣＵデバイス鍵Ｋｄｅを用いて必要な暗号化を行なう。それに応じて、ＯＴＡマスタ２２ＡでもＯＴＡセンタ１Ａと同様にＥＣＵデバイス鍵Ｋｄｅを生成し、必要な復号化を行なう。このように、各ターゲットＥＣＵ２４に対応して生成されたＥＣＵデバイス鍵Ｋｄｅを用いることで、セキュリティレベルをより向上させることができる。

　ＥＣＵデバイス鍵Ｋｄｅは、ターゲットＥＣＵ２４のＩＤとデバイス鍵Ｋｄの値に基づいて生成されるので、ＯＴＡセンタ１Ａにおいては、ＯＴＡマスタ２２Ａの台数分のデバイス鍵Ｋｄの値を管理するだけで済む。１台の車両に複数のＥＣＵが搭載される状況では、車両台数分の鍵を管理するのか、ＥＣＵ台数分の鍵を管理するのかでは、管理コストが顕著に異なる。

　　（第３実施形態）
　第３実施形態では、デバイス鍵Ｋｄに替えて、予めターゲットＥＣＵ２４毎に用意されているデバイス鍵Ｋｄｔを使用する。デバイス鍵Ｋｄｔは、予め各ターゲットＥＣＵ２４に書き込まれている。図１９に示す車両側システム２３Ｂでは、ＯＴＡマスタ２２Ｂよりライセンスファイル復号化機能部２７及びユーザ鍵復号化機能部２８が削除されている。それに替えてターゲットＥＣＵ２４Ｂ側に、ライセンスファイル復号化機能部３５及びユーザ鍵復号化機能部３６が設けられている。

　図２１に示すように、ＯＴＡセンタ１のＰＫＧ生成サーバ２は、ステップＳ１及びＳ２を実行すると、配信サーバ２のデバイスユニーク鍵管理機能部１５より、ターゲットＥＣＵ２４毎に用意されているデバイス鍵Ｋｄｔを取得する（Ｓ６１）。そして、コンテンツ鍵Ｋｃを、デバイス鍵Ｋｄｔを用いて暗号化し、コンテンツ鍵Ｋｃｄｔを生成する（Ｓ６２）。

　続いて、ステップＳ５及びＳ６ｂを実行する。ステップＳ６ｂは、コンテンツ鍵ＫｃｄがＫｃｄｔに置き変わっている。更に、ステップＳ７及びＳ８を実行すると、ユーザ鍵Ｋｕを、デバイス鍵Ｋｄｔを用いて暗号化し、ユーザ鍵Ｋｕｄｔとする（Ｓ６３）。そして、暗号化されたライセンスファイルとユーザ鍵Ｋｕｄｔとをアーカイブし、そのファイル名をLicence.zipとする（Ｓ６４）。それから、ステップＳ１１～Ｓ１７を実行する。
　図２２に示すように、ＯＴＡマスタ２２Ｂは、ステップＳ２１～Ｓ２４を実行すると、次にステップＳ３０～Ｓ３２を実行する。

　図２３に示すように、ターゲットＥＣＵ２４は、ＯＴＡマスタ２２Ｂから更新対象ソフトウェアが課金コンテンツであることの通知を受信すると（Ｓ４１；ＹＥＳ）、ＯＴＡマスタ２２ＢからContents.zipファイル及びLicence.zipファイルを受信する（Ｓ６５）。そして、Licence.zipファイルを解凍すると、暗号化されたライセンスファイルと、ユーザ鍵Ｋｕｄｔとを取り出す（Ｓ６６）。

　次に、ユーザ鍵Ｋｕｄｔを、自身が保持しているデバイス鍵Ｋｄｔで復号化してユーザ鍵Ｋｕを取り出すと（Ｓ６７）、ユーザ鍵Ｋｕを用いて、暗号化されたライセンスファイルを復号化する（Ｓ６８）。そして、ライセンスファイルからコンテンツ鍵Ｋｃｄｔを取り出し、デバイス鍵Ｋｄｔで復号化してコンテンツ鍵Ｋｃを取り出すと（Ｓ６９）、コンテンツ鍵Ｋｃで課金コンテンツを復号化する（Ｓ７０）。

　ライセンスファイルに含まれている許諾条件を読み取り、その条件を満たしていれば（Ｓ４８；ＹＥＳ）、課金コンテンツのインストール処理を実行する（Ｓ４５）。許諾条件を満たしていなければ（ＮＯ）、ＯＴＡマスタ２２Ｂに許諾条件を満たしていない旨のエラー応答を返す（Ｓ４７）。インストールした課金コンテンツのアプリケーションを起動する際の処理は、第１実施形態と同様である。

　尚、ステップＳ６６で行うLicence.zipファイルの解凍をＯＴＡマスタ２２Ｂで行い、暗号化されたライセンスファイルとユーザ鍵ＫｕｄｔとをターゲットＥＣＵ２４に転送しても良い。また、複数のターゲットＥＣＵ２４Ｂがある場合には、ターゲットＥＣＵ２４Ｂ毎にライセンスファイルが作成される。

　以上のように第３実施形態によれば、ＯＴＡセンタ１のデバイスユニーク鍵管理機能部１５は、ターゲットＥＣＵ２４毎に用意されているデバイス鍵Ｋｄｔを保持する。ターゲットＥＣＵ２４は、暗号化されたライセンスファイル及びユーザ鍵Ｋｕｄｔを受信すると、ユーザ鍵Ｋｕｄｔよりデバイス鍵Ｋｄｔを用いてユーザ鍵Ｋｕを復号化する。そして、ユーザ鍵Ｋｕを用いてライセンスファイルを復号化する。また、デバイス鍵Ｋｄｔを用いて、ライセンスファイルに含まれているコンテンツ鍵Ｋｃｄｔよりコンテンツ鍵Ｋｃを復号化する。更に、コンテンツ鍵Ｋｃを用いて暗号化された課金コンテンツを復号化する。

　すなわち、課金コンテンツは、暗号化された状態でターゲットＥＣＵ２４に転送されて、ターゲットＥＣＵ２４において復号化されるので、セキュリティレベルを更に向上させることができる。

　　（その他の実施形態）
　ユーザ鍵Ｋｕを、デバイス鍵Ｋｄを用いて暗号化する処理は、必要に応じて行えば良い。
　コンテンツの利用制限は、課金の有無に限らない。例えば、車種や車両グレードに応じてコンテンツの利用に制限をかけても良い。
　コンテンツの利用制限は、ユーザの利用に際して利用制限をかけることのほか、車両に搭載されたシステムやアプリケーションがコンテンツを利用する際に利用制限をかけても良い。

　本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

　各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。

　本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

Claims

　コンテンツを保護するためのコンテンツ鍵を生成するコンテンツ鍵生成部（５）と、
　前記コンテンツを利用するユーザに対応するユーザ鍵を生成するユーザ鍵生成部（６）と、
　各車両に対応するデバイス鍵を管理するデバイス鍵管理部（１５）と、
　前記コンテンツを、前記コンテンツ鍵を用いて暗号化するコンテンツ暗号化部（８）と、
　前記コンテンツ鍵を、前記デバイス鍵を用いて暗号化するコンテンツ鍵暗号化部（１０）と、
　少なくとも前記コンテンツを利用するための条件を含むライセンスファイルを、前記ユーザ鍵を用いて暗号化するファイル暗号化部（９）とを備えるセンタ装置。
　前記ユーザ鍵を、前記デバイス鍵を用いて暗号化するユーザ鍵暗号化部（１１）を備える請求項１記載のセンタ装置。
　前記ライセンスファイルには、前記コンテンツを利用するための許諾条件と、
　前記デバイス鍵を用いて暗号化されたコンテンツ鍵と、
　前記コンテンツを識別するための識別情報とが含まれている請求項１又は２記載のセンタ装置。
　前記ライセンスファイルには、暗号化を行なうための情報である暗号化パラメータが含まれている請求項３記載のセンタ装置。
　車両に送信する配信パッケージを生成するパッケージ生成部（２）を備え、
　前記パッケージ生成部は、前記コンテンツ鍵生成部、前記ユーザ鍵生成部、前記コンテンツ暗号化部、前記コンテンツ鍵暗号化部及び前記ファイル暗号化部としての機能も備えている請求項１から４の何れか一項に記載のセンタ装置。
　暗号化された前記ライセンスファイル及び暗号化された前記ユーザ鍵を含む圧縮ファイルを生成する圧縮ファイル生成部（４）を備える請求項１から５の何れか一項に記載のセンタ装置。
　暗号化されたコンテンツを、ＣＤＮ（Contents Delivery Network；２１）を経由して車両に配信するコンテンツ配信部（１２）を備える請求項１から６の何れか一項に記載のセンタ装置。
　前記デバイス鍵管理部は、前記デバイス鍵を、各車両に付与されている車両識別情報毎に保持する請求項１から７の何れか一項に記載のセンタ装置。
　前記車両識別情報毎に保持しているデバイス鍵と、各車両に配置されている電子制御装置であり前記コンテンツの転送先である対象装置の識別情報とに基づいて、装置対応デバイス鍵を生成するデバイス鍵生成部（３３）を備える請求項８記載のセンタ装置。
　前記デバイス鍵生成部は、前記車両識別情報毎に保持しているデバイス鍵の値に、前記識別情報の値を加算した結果にハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項９記載のセンタ装置。
　前記デバイス鍵生成部は、前記車両識別情報毎に保持しているデバイス鍵と、前記識別情報とを連結したデータにハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項９記載のセンタ装置。
　前記デバイス鍵管理部は、前記デバイス鍵を、各車両に配置されている電子制御装置であり、前記コンテンツの転送先である対象装置毎に保持する請求項１から７の何れか一項に記載のセンタ装置。
　車両に配置され、請求項８記載のセンタ装置と通信を行う通信部（２５）と、
　この通信部が受信したデータを、電子制御装置であり前記コンテンツの転送先である対象装置に転送するマスタ装置（２２）と、
　前記対象装置（２４）とを備え、
　前記マスタ装置は、前記デバイス鍵を保持しており、
　暗号化されたライセンスファイル及びユーザ鍵を受信すると、前記ユーザ鍵を用いてライセンスファイルを復号化するライセンスファイル復号部（２７）と、
　前記デバイス鍵を用いて、前記ライセンスファイルに含まれているコンテンツ鍵を復号化するコンテンツ鍵復号部（２９）と、
　前記コンテンツを含むデータファイルを受信すると、前記データファイル及びコンテンツ鍵を含むライセンスファイルを前記対象装置に転送する転送部とを備える車両側システム。
　車両に配置され、請求項９から１１の何れか一項に記載のセンタ装置と通信を行う通信部（２５）と、
　この通信部が受信したデータを、電子制御装置であり前記コンテンツの転送先である対象装置に転送するマスタ装置（２２）と、
　前記対象装置とを備え、
　前記マスタ装置は、前記デバイス鍵と前記対象装置の識別情報とに基づいて、装置対応デバイス鍵を生成するデバイス鍵生成部（３４）を備え、
　暗号化されたライセンスファイル及びユーザ鍵を受信すると、前記ユーザ鍵を用いてライセンスファイルを復号化するライセンスファイル復号部（２７）と、
　前記装置対応デバイス鍵を用いて、前記ライセンスファイルに含まれているコンテンツ鍵を復号化するコンテンツ鍵復号部（２９）と、
　前記コンテンツを含むデータファイルを受信すると、前記データファイル及びコンテンツ鍵を含むライセンスファイルを前記対象装置に転送する転送部とを備える車両側システム。
　車両に配置され、請求項１２記載のセンタ装置と通信を行う通信部（２５）と、
　この通信部が受信したデータを、電子制御装置であり前記コンテンツの転送先である対象装置に転送するマスタ装置（２２）と、
　前記対象装置（２４）とを備え、
　前記対象装置は、前記デバイス鍵を保持しており、
　暗号化されたライセンスファイル及びユーザ鍵を受信すると、前記ユーザ鍵を用いてライセンスファイルを復号化するライセンスファイル復号部（３５）と、
　前記デバイス鍵を用いて、前記ライセンスファイルに含まれているコンテンツ鍵を復号化するコンテンツ鍵復号部（３６）と、
　前記コンテンツを含むデータファイルを受信すると、前記コンテンツ鍵を用いて前記コンテンツを復号化するコンテンツを復号部（３１）とを備える車両側システム。
　コンテンツを保護するためのコンテンツ鍵を生成し、
　前記コンテンツを利用するユーザに対応するユーザ鍵を生成し、
　前記コンテンツを、前記コンテンツ鍵を用いて暗号化し、
　前記コンテンツ鍵を、前記各車両に対応するデバイス鍵を用いて暗号化し、
　少なくとも前記コンテンツを利用するための条件を含むライセンスファイルを、前記ユーザ鍵を用いて暗号化するコンテンツの保護方法。
　前記ユーザ鍵を、前記デバイス鍵を用いて暗号化する請求項１６記載のコンテンツの保護方法。
　前記ライセンスファイルに、前記コンテンツを利用するための許諾条件と、
　前記デバイス鍵を用いて暗号化されたコンテンツ鍵と、
　前記コンテンツを識別するための識別情報とを含む請求項１６又は１７記載のコンテンツの保護方法。
　前記ライセンスファイルに、更に暗号化を行なうための情報である暗号化パラメータを含む請求項１８記載のコンテンツの保護方法。
　暗号化された前記ライセンスファイル及び暗号化された前記ユーザ鍵を含む圧縮ファイルを生成する請求項１６から１９の何れか一項に記載のコンテンツの保護方法。
　暗号化されたコンテンツを、ＣＤＮ（Contents Delivery Network）を経由して車両に配信する請求項１６から２０の何れか一項に記載のコンテンツの保護方法。
　前記デバイス鍵は、各車両に付与されている車両識別情報毎にある請求項１６から２１の何れか一項に記載のコンテンツの保護方法。
　前記車両識別情報毎にあるデバイス鍵と、各車両に配置されている電子制御装置であり前記コンテンツの転送先である対象装置の識別情報とに基づいて装置対応デバイス鍵を生成する請求項２２記載のコンテンツの保護方法。
　前記車両識別情報毎にあるデバイス鍵の値に、前記識別情報の値を加算した結果にハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項２３記載のコンテンツの保護方法。
　前記車両識別情報毎にあるデバイス鍵と、前記識別情報とを連結したデータにハッシュ関数を適用して前記装置対応デバイス鍵を生成する請求項２３記載のコンテンツの保護方法。
　前記デバイス鍵は、各車両に配置されている電子制御装置であり、前記コンテンツの転送先である対象装置毎にある請求項１６から２１の何れか一項に記載のコンテンツの保護方法。
　車両と通信を行いコンテンツを配信するセンタ装置が備えるコンピュータにより実行されるコンテンツ保護用プログラムであって、
　コンテンツを保護するためのコンテンツ鍵を生成させ、
　前記コンテンツを利用するユーザに対応するユーザ鍵を生成させ、
　前記コンテンツを、前記コンテンツ鍵を用いて暗号化させ、
　前記コンテンツ鍵を、前記各車両に対応するデバイス鍵を用いて暗号化させ、
　少なくとも前記コンテンツを利用するための条件を含むライセンスファイルを、前記ユーザ鍵を用いて暗号化させるコンテンツ保護用プログラム。
　前記ユーザ鍵を、前記デバイス鍵を用いて暗号化させる請求項２７記載のコンテンツ保護用プログラム。
　前記ライセンスファイルに、前記コンテンツを利用するための許諾条件と、
　前記デバイス鍵を用いて暗号化されたコンテンツ鍵と、
　前記コンテンツを識別するための識別情報とを含ませる請求項２８記載のコンテンツ保護用プログラム。
　前記ライセンスファイルに、暗号化を行なうための情報である暗号化パラメータを含ませる請求項２９記載のコンテンツ保護用プログラム。
　暗号化された前記ライセンスファイル及び暗号化された前記ユーザ鍵を含む圧縮ファイルを生成させる請求項２７から３０の何れか一項に記載のコンテンツ保護用プログラム。
　暗号化されたコンテンツを、ＣＤＮ（Contents Delivery Network）を経由して車両に配信させる請求項２７から３１の何れか一項に記載のコンテンツ保護用プログラム。
　前記デバイス鍵は、各車両に付与されている車両識別情報毎にある請求項２７から３２の何れか一項に記載のコンテンツ保護用プログラム。
　前記車両識別情報毎にあるデバイス鍵と、各車両に配置されている電子制御装置であり前記コンテンツの転送先である対象装置の識別情報とに基づいて装置対応デバイス鍵を生成させる請求項３３記載のコンテンツ保護用プログラム。
　前記車両識別情報毎にあるデバイス鍵の値に、前記識別情報の値を加算した結果にハッシュ関数を適用して前記装置対応デバイス鍵を生成させる請求項３４記載のコンテンツ保護用プログラム。
　前記車両識別情報毎にあるデバイス鍵と、前記識別情報とを連結したデータにハッシュ関数を適用して前記装置対応デバイス鍵を生成させる請求項３４記載のコンテンツ保護用プログラム。
　前記デバイス鍵は、各車両に配置されている電子制御装置であり、前記コンテンツの転送先である対象装置毎にある請求項２７から３２の何れか一項に記載のコンテンツ保護用プログラム。