説明

コンテンツデータ再生システムおよびその利用履歴の収集システム

【課題】コンテンツデータの不正利用の防止に有利なコンテンツデータ再生システムおよびその利用履歴の収集システムを提供する。
【解決手段】実施形態によれば、コンテンツデータ再生システムは、コンテンツデータを利用するホスト装置2と、前記コンテンツデータをコンテンツ鍵データで暗号化してなる暗号化コンテンツデータを復号してコンテンツデータを前記ホスト装置において利用可能となるように構成される記憶装置1とを具備する。ホスト装置2は、ホスト装置ごとに固有に割り当てられるデバイスIDを有し、前記記憶装置は、メモリ4と前記メモリを制御するコントローラ3とを備える。前記コントローラ3は、前記ホスト装置から受信したメッセージ内の要素Kseedと前記デバイスIDとから暗号鍵を作成する暗号鍵生成部32と、送信するメッセージ内の要素を前記暗号鍵で暗号化し、暗号化されたメッセージを作成する暗号部31とを有する。

【発明の詳細な説明】
【技術分野】
【0001】
コンテンツデータ再生システムおよびその利用履歴の収集システムに関するものである。
【背景技術】
【0002】
近年、情報化社会の発展に伴い、書籍、新聞、音楽又は動画などを電子化したコンテンツデータをユーザ端末に配信し、コンテンツデータを閲覧可能とするコンテンツデータ再生システムが広く用いられてきている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2005−341156号公報
【特許文献2】国際公開番号WO/2010/119549
【非特許文献】
【0004】
【非特許文献1】CPRM Specification for SD Memory Card、4C Entity,LLC、(http://www.4centity.com)
【非特許文献2】CPXM Specification Introduction and Common Cryptographic Elements [URL:http://www.4centity.com/]
【発明の概要】
【発明が解決しようとする課題】
【0005】
コンテンツデータの不正利用の防止に有利なコンテンツデータ再生システムおよびその利用履歴の収集システムを提供する。
【課題を解決するための手段】
【0006】
実施形態によれば、一態様に係るコンテンツデータ再生システムは、コンテンツデータを利用するホスト装置と、前記コンテンツデータをコンテンツ鍵データで暗号化してなる暗号化コンテンツデータを復号してコンテンツデータを前記ホスト装置において利用可能となるように構成される記憶装置とを具備する。前記ホスト装置は、ホスト装置ごとに固有に割り当てられるデバイスIDを有し、前記記憶装置は、メモリと前記メモリを制御するコントローラとを備え、前記コントローラは、前記ホスト装置から受信したメッセージ内の要素と前記デバイスIDとから暗号鍵を作成する暗号鍵生成部と、送信するメッセージ内の要素を前記暗号鍵で暗号化し、暗号化されたメッセージを作成する暗号部とを有する。
【図面の簡単な説明】
【0007】
【図1】第1の実施形態に係るコンテンツデータ再生システムを示すブロック図。
【図2】第1の実施形態に係るIndexデータテーブルを示すブロック図。
【図3】第2の実施形態に係るコンテンツデータ再生システムの利用履歴収集システムを示すブロック図。
【図4】第2の実施形態に係るコンテンツデータ再生システムの利用履歴を示す図。
【図5】第3の実施形態に係るコンテンツデータ再生システムを示すブロック図。
【図6】第3の実施形態に係るコンテンツデータ再生システムのコンテンツ復号方法を示すフロー図。
【図7】第3の実施形態に係るコンテンツデータ再生システムのMKB処理を示すフロー図。
【図8】第3の実施形態に係るMKB(Media Key Block)の構成を示す図。
【図9】図8中の拡張Verify Media Key recordの構成を示す図。
【図10】図8中の拡張Media Key Data recordの構成を示す図。
【図11】第3の実施形態に係るコンテンツデータ再生システムの関数処理データを示す図。
【発明を実施するための形態】
【0008】
電子化したコンテンツ(以下、単にコンテンツという)は、容易に複製可能なため、著作権を無視する違法行為が生じ易い。このような違法行為からコンテンツを保護する観点から、コンテンツは、通常、暗号化鍵により、暗号化されて記録され、再生時に復号される。この種のコンテンツ保護技術の1つには、CPRM(Content Protection for Prerecorded Media)がある。
【0009】
また、コンテンツ鍵が2種類の鍵で二重に暗号化された暗号化二重鍵方式が考えられている。この種の暗号化二重鍵方式は、例えばMQbic(登録商標)に用いられている。暗号化鍵のうち、記録媒体に固有の鍵、例えばメディア固有鍵は、記憶媒体の秘匿領域にセキュアに記憶され、外部からは一切アクセスが不可能にされている。このため、例えば暗号化コンテンツ鍵データのみが違法にコピーされたとしても、違法コピー者は、メディア固有鍵がなければ、コンテンツデータを利用することができない。
【0010】
しかし、このようなメディア固有鍵が何らかの手法により不正に読み出され、正規なライセンスを受けていないホスト製造業者に渡されると、こうした流出情報に基づいて製造された不正装置により、コンテンツデータが違法に利用されることが起こり得る。
【0011】
そこで、以下、実施形態について図面を参照して説明する。尚、この説明においては、全図にわたり共通の部分には共通の参照符号を付す。
【0012】
[第1の実施形態]
第1の実施形態に係るコンテンツデータ再生システムを説明する。
<1.構成例>
1−1.全体構成
まず、図1を用いて第1の実施形態に係る全体構成(コンテンツ再生システム)について説明する。
【0013】
図示するように、本例に係るコンテンツデータ再生システムは、ホスト装置としての復号装置2と、記憶装置1とを具備する。
【0014】
復号装置2は、コンテンツデータを利用する記憶装置1のホスト装置である。換言すると、復号装置2は、記憶装置1と連携して後述する認証処理を実行した後、コンテンツ鍵を取得する。復号装置2は、取得したコンテンツ鍵を用いてコンテンツデータを複合、再生することが可能である。
【0015】
記憶装置1は、コンテンツデータをコンテンツ鍵で暗号化してなる暗号化コンテンツデータを記憶しており、暗号化コンテンツデータを複合したコンテンツデータが復号装置2において利用可能となるように構成される。換言すると、記憶装置1は、コンテンツデータを暗号化するコンテンツ鍵を記憶する。記憶装置1としては、例えば、SD(登録商標)カード等のメモリカードが用いられる。
【0016】
より具体的には、記憶装置(メモリカード)1は、コントローラ3と、メモリ4とを備える。コントローラ3は、K暗号部31、KID生成部32、検証部33、メッセージ復号部34を備える。メモリ4は、コントローラ3以外からのアクセス不可能、即ち記憶装置1外部からのアクセス不可能な秘匿領域41、コントローラ3を介して記憶装置1の外部から自由にアクセス可能なユーザ領域42を備える。
【0017】
ユーザ領域42にはEnc(Ksrv, Kseed || Kc || O1 || O2 || O3 || …)とEnc(Kd1, Kid1) || HoF1 || Enc(Kd2, Kid2) || HoF2 || Enc(Kd3, Kid3) || HoF3 … が記録される。秘匿領域41にはサービス鍵Ksrvが記録される。ここで、図中において、||はデータの連結を示す。
【0018】
復号装置2は、選択部11、関数処理部12、メッセージ生成部13、KID復号部14、K復号部15を備える。
【0019】
復号装置2は、内部でこの復号装置2ごとに固有に割り当てられたDeviceIDとデバイス鍵Kdiを保持する。
【0020】
復号装置2は、ユーザ領域42に記録されたデータを、コントローラ3を介して読み出す。選択部11は、読み出されたデータEnc(Kd1, Kid1) || HoF1 || Enc(Kd2, Kid2) || HoF2 || Enc(Kd3, Kid3) || HoF3 …から、当該復号装置2が保持するDeviceIDに基づいて、Enc(Kdi, Kidi)とHoFi とを選択する。
【0021】
選択されたHoFiは、関数処理部12により処理されて出力Oが計算される。そしてメッセージ生成部13にて出力O、DeviceID、ユーザ領域42より読み出したEnc(Ksrv, Kseed || Kc || O1 || O2 || O3 || …)を含むメッセージが生成され、記録装置1のコントローラ3へ渡される。このように、本例では、メッセージEnc(Ksrv, Kseed || Kc || O1 || O2 || O3 || …)に更に”要素Kseed”が加えられる。
【0022】
メッセージ復号部34は、秘匿領域41に記録されたサービス鍵Ksrvを読み出し、受け取ったメッセージ内のEnc(Ksrv, Kseed || Kc || O1 || O2 || O3 || …)を復号して、Kseed || Kc || O1 || O2 || O3 || …を得る。
【0023】
続いて、検証部33は、DeviceIDによってO1, O2, O3, …から選択されるOiとメッセージに含まれる出力Oとを比較して検証し、同じでない場合にはこの処理を中止にする。
【0024】
同じ場合は、続いてKid生成部32は、メッセージ内の要素Kseedと復号装置2ごとに固有に割り当てられたDeviceIDとからKidi(暗号鍵)を作成する。
【0025】
続いて、Kc暗号部31は、暗号鍵Kidiでコンテンツ鍵Kcを暗号化し、暗号化されたメッセージEnc(KID,K)を作成する。暗号化されたメッセージEnc(KID,K)は、復号装置2により復号されて読み出される。
【0026】
この際、コントローラ3内のKc暗号部31は、利用した復号装置2ごとに固有に割り当てられたDeviceIDを利用履歴として、秘匿領域41に書き込む。この利用履歴は、後に専用のコマンドにてコントローラ3を介して読み取られ、アクセスのあったDeviceIDの情報収集に利用することが可能となる。コピーされた不正な復号装置等が用いられた場合、同じDeviceIDが複数の箇所から発見されることとなるため、不正デバイスの検出に有利である。詳細については、後述する。
【0027】
復号装置2では、選択されたEnc(Kdi, Kidi)がKID復号部14によって、Kdiで復号されてKidiが計算される。その結果とカードから受け取ったEnc(Kidi, Kc)はKc復号部15にて復号されコンテンツ鍵Kcが得られる。このコンテンツ鍵Kcは他の配信経路等で配布された対応するコンテンツの復号などに利用される。
【0028】
ここでDeviceIDから複数のデータを選択する方法について説明する。様々な実施方法が考えられるが、例えば、DeviceIDが1から1000までの値で、複数のデータが1から1000まで与えられた場合には、初めからDeviceIDの番号分数えたデータを選択することで実現可能である。
【0029】
1−2.Indexテーブルの構成例
次に、図2を用い、第1の実施形態に係るIndexテーブルの構成例について説明する。
【0030】
このIndexテーブルは、選択対象の複数のデータに対象となるものであり、そのIndexテーブルに従って選択されることでも実現可能である。
【0031】
また参考文献2のChapter3に記載されているDeviceKeySet, DeviceNode, MKBをそれぞれKdi,DeviceID,複数のデータの代わりに利用することで同様の効果が得られる。
【0032】
関数処理部で処理されるHoFは例えば関数処理部が解釈可能なプログラムのバイナリーコードであったり、インストラクションなどで実現できる。もしくは関数処理部で予め定められた関数を用意し、HoFを入力値として関数を実行することでも実現できる。復号装置で得られた結果が正しいかどうかを記録装置内で判定することで、不正な復号装置の処理を防止する効果が得られる。
【0033】
<3.作用効果>
第1の実施形態に係るコンテンツデータ再生システムによれば、少なくとも下記(1)および(2)の効果が得られる。
【0034】
(1)コンテンツデータの不正利用の防止に有利である。
【0035】
上記のように、第1の実施形態に係るコンテンツデータ再生システムは、復号装置(ホスト装置)2ごとに固有に割り当てられたデバイスID(Device ID)を有する。そして、記憶装置1側では、Kid生成部32により復号装置2から受信したメッセージ内Encのメッセージ内の要素Kseedと復号装置DeviceIDとからKidi(暗号鍵)を作成し、Kc暗号部31により暗号鍵Kidiで要素Kcを暗号化し、暗号化されたメッセージEnc(KID,K)を作成する。暗号化されたメッセージEnc(KID,K)は、復号装置2により復号されて読み出される。
【0036】
このように、本システムでは、復号装置(ホスト装置)2ごとに固有のデバイスID(Device ID)により暗号化されるメッセージEnc(KID,K)によりコンテンツデータが再生される。その結果、コンテンツデータの不正利用の防止に有利である。
【0037】
(2)不正装置をシステムから排除でき、不正デバイスの検出に有利である。
【0038】
さらに、コントローラ3内のKc暗号部31は、利用した復号装置2ごとに固有に割り当てられたDeviceIDを利用履歴として、秘匿領域41に書き込む。この利用履歴は、後に専用のコマンドにてコントローラ3を介して読み取られ、アクセスのあったDeviceIDの情報収集に利用することが可能となる。具体的には、不正にコピーされた復号装置等では同じDeviceIDが複数の箇所から発見されることとなる。
【0039】
その結果、発見されたデバイスIDの装置を不正装置とみなしてシステムから排除でき、不正デバイスの検出に有利である。
【0040】
なお、アクセスのあったDeviceIDの情報収集の具体例については、次の第2の実施形態で詳説する。
【0041】
[第2の実施形態(アクセスのあった利用履歴の情報収集の一例)]
次に、第2の実施形態に係るコンテンツデータ再生システムの利用履歴の収集システムについて説明する。この実施形態は、アクセスのあった利用履歴の情報収集の一例に関するものである。この説明において、上記第1の実施形態と重複する部分の詳細な説明を省略する。
【0042】
<利用履歴の収集システム>
まず、図3を用い、第2の実施形態に係る記録装置1の内部に記録された利用履歴(ID Log)を収集する具体的な構成を説明する。
【0043】
図示するように、本例での利用履歴の収集システムは、管理サーバ1、データ書込み装置21,22,…、記録装置31,32,…、復号装置41,42,…から構成される。
【0044】
復号装置(41,42,…)は、記録装置(31,32,…)にそれぞれアクセスする際に、それぞれのDevice IDを記録装置(31,32,…)に渡す記憶装置のホスト装置である。
【0045】
記録装置(31,32,…)は、それぞれのDevice IDを利用履歴(31a,32a,…)として記録する。利用履歴(31a,32a,…)は、記録装置(31,32,…)それぞれにユニークに割り振られたCard IDとアクセスのあったDevice IDとから構成される。
【0046】
続いて、利用履歴(31a,32a,…)は、データ書込み装置(21,22,…)が記録装置(31,32,…)にアクセスする際に読み込まれる。
【0047】
続いて、データ書込み装置(21,22,…)は、読み込んだそれぞれの利用履歴(31a,32a,…)を管理サーバ1へ送信する。
【0048】
<利用履歴の構成例について>
図4は、利用履歴の構成例を示す。ここでは、記憶装置31の利用履歴31aを一例にあげる。
図示するように、この利用履歴31aは、記録装置31にユニークに割り振られたCard ID(000010FE)とアクセスのあったDevice ID(00010A11, 00010A11, 0001FF15, 00A90055, …)とから構成される。
【0049】
上記のように、この例では、利用履歴のアクセスのあった同じDevice IDの(00010A11, 00010A11)が発見されることが分かる。
【0050】
このように利用履歴を、管理サーバ1が収集することで、同じDeviceID(例えば、00010A11, 00010A11, …)が複数の記憶装置(31,32,…)から発見された場合、不正にコピーされたデバイスであると判定できる。その結果、DeviceID(例えば、00010A11)を有するデバイスをコンテンツ再生システムから排除でき、コンテンツデータの不正利用の防止することができる。
【0051】
<作用効果>
上記のように、第2の実施形態に係るコンテンツデータ再生システムおよびその利用履歴の収集システムによれば、少なくとも上記(1)および(2)と同様の効果が得られる。
【0052】
さらに、本例によれば、より具体的に、上記の利用履歴および利用履歴の収集システムを適用することにより、必要に応じて、不正装置をコンテンツ再生システムから排除でき、コンテンツデータの不正利用の防止することができる。
【0053】
[第3の実施形態]
次に、第3の実施形態に係るコンテンツデータ再生システムについて説明する。この実施形態は、他の実施形態に適用した一例に関するものである。この説明において、上記第1の実施形態と重複する部分の詳細な説明を省略する。
【0054】
第3の実施形態は、例えば、上記特許文献2の実施形態の発展させた実施形態に関する。
【0055】
<全体構成>
まず、図5を用い、第3の実施形態に係る全体構成(コンテンツ再生システム)について説明する。
【0056】
図示するように、本例に係るシステムは、記録装置1および復号装置2で構成される。
【0057】
記録装置1は、下記の処理を行う、秘密記録部11、ユーザデータ領域12、AKE処理部13、比較部14、一方向性関数計算部15、Kuv計算部16、判定部17、復号部181、復号部182、暗号部183、および暗号部184を備える。
【0058】
復号装置2は、下記の処理を行う、MKB処理部21、選択部22、関数処理部23、一方向性関数計算部24、AKE処理部25、合成部26、暗号部271、復号部272、復号部273、復号部274、およびコンテンツ復号部28を備える。
【0059】
<処理手順>
次に、図6を用い、上記システムによる処理の手順について説明する。
図示するように、第3の実施形態に係る処理は、(P1)AKE処理、(P2)MKB処理、(P3)関数処理、(P4)セッション鍵による計算、(P5)セッション鍵による暗号処理、(P6)セッション鍵による復号処理、(P7)Ksrv復号処理、(P8)セッション鍵による計算、(P9)関数処理結果の比較、(P10)Kuv計算、(P11)Kuv暗号処理、(P12)セッション鍵による暗号処理、(P13)uv履歴保存、(P14)セッション鍵による復号処理、(P15)Kc復号処理、(P16)コンテンツ復号から構成される。
【0060】
(ステップP1)
まず、復号装置2は、記録装置1とそれぞれのAKE処理部13を通じて認証処理を行い、お互いに共通のセッション鍵(Ks)を共有する。ここでの認証処理は、例えば、AKE Processにより実現可能である。
【0061】
(ステップP2)
続いて、MKB処理を行い、記録装置1のユーザデータ領域12に記録されたMKBを復号装置2が読み出し、MKB処理部21にてMKB処理を行い、index、UVi、Km、Kuviを取り出す。取り出されたindexに従って、選択部22はユーザデータ領域12から読まれたデータから該当するデータエントリHoF IDi, Enc(Ksrv, Enc(Kmi, Kc) || Kseed || Ai) || Qi を選択する。
MKB処理は、具体的には、例えば、図8に示すMKB(Media Key Block)を、以下の図7の処理を行うことで実現可能である。
【0062】
<MKB(Media Key Block)の構成>
ここで、図8に示すMKB(Media Key Block)の構成について説明する。
図示するように本例に示すMKBは、Type and Version record(MK1), 拡張 Verify Media Key record(MK2), Subset Different index record(MK3), Explicit Subset Difference record(MK4), 拡張Media Key Data Record(MK5), およびEnd of Media Key Block record(MK6)により構成される。
上記のように、Verify Media Key recordは拡張されて拡張 Verify Media Key record(MK2)に、Media Key Block Recorは拡張されて拡張Media Key Block Record(MK5)にそれぞれ置き換えられる。
さらに、上記Explicit Subset Difference record(MK4)は、Type, Length, UV Descriptor #1, ,,, UV Descriptor #i, ,,, UV Descriptor #nより構成される。
【0063】
<拡張Verify Media Key record(MK2)の構成>
図9を用い、上記拡張Verify Media Key record(MK2)の構成について説明する。
図示するように、拡張Verify Media Key record(MK2)は、Record Type(MK21)、Record Length(MK22)、Verification Data #1(MK23), ,,, Verification Data #i(MK24), ,,, およびVerification Data #n (MK25)より構成される。
【0064】
<拡張Media Key Data record(MK5)の構成>
図10を用い、上記拡張Media Key Data record(MK5)の構成について説明する。
図示するように拡張Media Key Data record(MK5)は、Record Type(MK51)、Record Length(MK52)、AES_ECBC(Processing Key#1, KM#1, || Kuv#1)(MK53), ,,, AES_ECBC(Processing Key#i, KM#i, || Kuv#i)(MK54), ,,, AES_ECBC(Processing Key#n, KM#n, || Kuv#n)(MK55)より構成される。ここで、図中において、AES_ECBCは関数、iは1以上n以下の値、||はデータの連結を示す。
【0065】
<MKB処理について>
以下においては、図7を用い、MKB処理について説明をする。
【0066】
(ステップP21)
まず、MKB処理は、このステップS21により、復号装置2が処理するUV DescriptorをExplicit Subset Difference record(MK4)から選択する。このUV DescriptorはUViとして記述され、以降の処理で利用される。
【0067】
(ステップP21)
続いて、選択されたUV Descriptorから対応するProcessing Keyが算出される。ここで算出されたProcessing KeyをProcessing Key #i と以下表記する。
【0068】
(ステップP23)
続いて、拡張Media Key Block (Data) record (MK5)からMedia Key Dataを抽出する。具体的には、図10に書かれる拡張Media Key Block record(MK5)の中から対応するAES_ECBC(Processing Key#i, Km#i || Kuv#i) (AES_ECBCは関数、iは1以上n以下の値、||はデータの連結を示す)を抽出する。
【0069】
Media Key DataはUV Descriptorと同じ数で、同じ順番で配置されるため、復号装置2は対応するMedia Key Dataを探し出すことができる。そして抽出されたMedia Key Dataの復号作業を行う。Processing Key#iでの復号により、Km#i, Kuv#i が抽出できる。
【0070】
(ステップP24)
続いて、抽出したKm#iが拡張Verify Media Key record(MK2)にて正しいかどうかの確認処理を行う。本例に係る拡張Verify Media Key record(MK2)は、上記図9で示したように、複数のVerification Data(MK23〜MK25)から構成され、Km0がそれぞれKm#1からKm#nと表記された値で暗号化されたデータで構成される。
復号装置2は、対応するVerification Dataを取り出し、復号することで下記のデータを復号した際に得られるKm#iが正しく取り出せたのかどうかが確認可能となる。Verification Data(MK23〜MK25)は、UV Descriptorと同じ数配置され、あるUV Descriptorに対応するVerification Data(MK23〜MK25)は同じ順番で配置される。そのため、復号装置2は、対応するVerification Data(MK23〜MK25)を探し出すことができる。
【0071】
(ステップP25)
続いて、記録装置1に書かれていて、図11に示す関数処理データから対応する関数情報エントリ(FE1〜FE3)を取得する。関数情報エントリ(FE1〜FE3)は、UV Descriptorと同じ数(#1,,, #i,,, #n)で記録されており、当該UV Descriptorと同じ順番で対応する関数情報エントリが記録されているため、対応する関数情報エントリを探し出すことができる。
ここで、図11に示すように、例えば、関数情報エントリ(FE2)は、関数ID(以下HoF IDiと記述する)、入力値(以下Qiと記述する)、出力値(以下Aiと記述する)から構成される。
上記MKB処理の後は、下記ステップP3に続く。
【0072】
(ステップP3)
次に、関数処理にて、選択部22で選択されたデータエントリの中からQi、HoF IDiを取り出し関数処理部23にて関数処理を行う。関数処理部には予めHoF IDに該当した関数が記録されており、その入力値としてQiを入れると出力Aiが計算可能となる。なおここでの出力Aiは記録装置に予め記録されていたAiと区別するために復号処理部で計算された結果をAiH、記録されていたAiをAiCと記述する。
【0073】
(ステップP4)
続いて、セッション鍵による計算にて、関数処理部23で得たAiHをAKE処理部25で得たKsで一方向性関数計算部24にて計算する。ここでの計算はAES-G(AiH, Ks) で計算しているが、一方向性関数の性質をもつ式であればこの限りではない。なおAES-G(A,B) は参考文献2に記載されている関数AES_Gで実現可能である。
【0074】
(ステップP5)
続いて、セッション鍵による暗号処理にて、記録装置に送信する情報を暗号化する。送信する情報は(P2)(P4)で得られた情報UVi、AES-G(A1H, Ks)、Enc(Ksrv, Enc(Km, Kc) || Kseed || A1C)が連結されて暗号化されて送信される。
【0075】
(ステップP6)
続いて、記録装置内では受け取った情報をセッション鍵により復号処理を行う。
【0076】
(ステップP7)
続いて、記録装置内にあるサービス鍵Ksrvを用いて、上記ステップP6で得られたEnc(Ksrv, Enc(Km, Kc) || Kseed || A1C) || UVi を復号する。
【0077】
(ステップP8)
続いて、上記ステップP7で得られたA1Cと(P1)で得られたセッション鍵による計算により、AES-G(A1C, Ks)を計算する。
【0078】
(ステップP9)
続いて、上記ステップP8の結果と上記ステップP6で得られたAES-G(A1H, Ks)が同じ値かどうかを検証する。もし同じ値でない場合は、例えばこれ以降の処理を行わない、といった不正な復号装置からのアクセスとみなす処理を行う。
【0079】
(ステップP10)
続いて、上記ステップP7で得られたKseed とUVi からKuvi を計算する。計算方法は例えば、以下の数式(I)により、計算可能である。
【0080】
Kuvi = AES-D(Kseed xor UVi) xor UVi … 数式(I)
(ステップP11)
続いて、上記ステップP7で得られたEnc(Km, Kc)を、上記ステップP10にて得られたKuviにて暗号処理を行う。
【0081】
(ステップP12)
続いて、上記ステップP1で得られたセッション鍵により、上記ステップP11にて得られたEnc(Kuvi, Enc(Km, Kc))を暗号化して、復号装置へ送信する。
【0082】
(ステップP13)
続いて、記録装置1は、上記ステップP7で得られたUViを履歴情報として秘密記録部11へ保存する。ここで記録された履歴情報は、後に専用端末に接続された時などに読み出され、管理サーバに回収される。回収処理は、例えば、上記第2の実施形態で説明したような同様のシステム等にて実現可能である。
【0083】
(ステップP14)
続いて、復号装置2は、上記ステップP13で受け取った情報を、上記ステップP1で生成されたセッション鍵により復号処理を行う。
【0084】
(ステップP15)
続いて、上記ステップP14にて復号されたEnc(Kuvi, Enc(Km, Kc))を、上記ステップP2にて得られたKm、Kuvi用いて復号処理を行い、コンテンツ鍵Kcを取り出す。
【0085】
(ステップP16)
最後に、上記ステップP15で得られたコンテンツ鍵Kcによりコンテンツ復号を行う。
【0086】
<作用効果>
上記のように、第3の実施形態に係るコンテンツデータ再生システムによれば、少なくとも上記(1)および(2)と同様の効果が得られる。
【0087】
さらに、第3の実施形態によれば、例えば、ステップS11のように、記録装置1内で、コンテンツ鍵Kcは暗号化された状態で処理される。このように、記録装置1がコンテンツ鍵Kcそのものを知ることができず、情報の秘匿性を向上することができる。
【0088】
また、必要に応じて、本例のような構成を適用することが可能である。
【0089】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0090】
1…記憶装置、2…復号装置(ホスト装置)、3…メモリコントローラ、4…メモリ、31…Kc暗号部、32…KID生成部、33…検証部、34…メッセージ復号部、Enc…メッセージ、Kseed…(メッセージ内)要素、Device ID…(ホスト装置ごとに固有に割り当てられる)デバイスID、41…秘匿領域、42…ユーザ領域、ID Log…利用履歴。

【特許請求の範囲】
【請求項1】
コンテンツデータを利用するホスト装置と、
前記コンテンツデータをコンテンツ鍵データで暗号化してなる暗号化コンテンツデータを復号してコンテンツデータを前記ホスト装置において利用可能となるように構成される記憶装置とを具備するコンテンツデータ再生システムにおいて、
前記ホスト装置は、ホスト装置ごとに固有に割り当てられるデバイスIDを有し、
前記記憶装置は、メモリと前記メモリを制御するコントローラとを備え、前記コントローラは、
前記ホスト装置から受信したメッセージ内の要素と前記デバイスIDとから暗号鍵を作成する暗号鍵生成部と、
送信するメッセージ内の要素を前記暗号鍵で暗号化し、暗号化されたメッセージを作成する暗号部とを有する。
【請求項2】
前記コントローラは、利用した前記デバイスIDを利用履歴として、前記メモリ内の秘匿領域に書き込む
請求項1に記載のコンテンツデータ再生システム。
【請求項3】
請求項2に記載のコンテンツデータ再生システムは、
前記記憶装置にアクセスする際に前記利用履歴を前記記憶装置に書き込むデータ書込み装置と、前記書き込まれた利用履歴が送信される管理サーバとを備える利用履歴の収集システムに適用され、
前記管理サーバは、送信された前記利用履歴内に同じ前記デバイスIDが発見された場合、前記デバイスIDに対応するホスト装置を不正装置であると判定する。
【請求項4】
コンテンツデータを利用するホスト装置と、前記コンテンツデータをコンテンツ鍵データで暗号化してなる暗号化コンテンツデータを復号してコンテンツデータを前記ホスト装置において利用可能となるように構成される記憶装置とを具備するコンテンツデータ再生システムが適用される利用履歴の収集システムであって、
前記ホスト装置は、ホスト装置ごとに固有に割り当てられるデバイスIDを有し、
前記記憶装置は、メモリと前記メモリを制御するコントローラとを備え、前記コントローラは、利用した前記デバイスIDを利用履歴として、前記メモリ内の秘匿領域に書き込み、
前記利用履歴の収集システムは、
前記記憶装置にアクセスする際に前記利用履歴を前記記憶装置に書き込むデータ書込み装置と、
前記書き込まれた利用履歴が送信される管理サーバとを備え、
前記管理サーバは、送信された前記利用履歴内に同じ前記デバイスIDが発見された場合、前記デバイスIDに対応するホスト装置を不正装置であると判定する。
【請求項5】
前記コントローラは、
前記ホスト装置から受信したメッセージ内の要素と前記デバイスIDとから暗号鍵を作成する暗号鍵生成部と、
送信するメッセージ内の要素を前記暗号鍵で暗号化し、暗号化されたメッセージを作成する暗号部とを有する
請求項4に記載のコンテンツデータ再生システムの利用履歴の収集システム。
【請求項6】
コンテンツデータを利用するホスト装置と、
前記コンテンツデータをコンテンツ鍵データで暗号化してなる暗号化コンテンツデータを復号してコンテンツデータを前記ホスト装置において利用可能となるように構成される記憶装置とを具備するコンテンツデータ再生システムにおいて、
前記ホスト装置は、
ホスト装置ごとに固有に割り当てられるデバイスIDと、
前記デバイスIDに対応したデバイス鍵と、
複数のデバイス鍵で暗号化された暗号鍵データから前記デバイスIDに基づいてデータを選択する選択部と、
前記選択部で選択されたデータをデバイス鍵に基づいて復号する暗号鍵復号部を有し、
前記記憶装置は、メモリと前記メモリを制御するコントローラとを備え、前記メモリにはサービス鍵を記録し、
前記コントローラは、
前記ホスト装置から前記サービス鍵で暗号化された要素と前記デバイスIDとをメッセージとして受信し、
前記暗号化された要素を復号するサービス鍵復号部と、
前記要素と前記デバイスIDから暗号鍵を作成する暗号鍵生成部と、
送信するメッセージ内の要素を前記暗号鍵で暗号化し、暗号化されたメッセージを作成する暗号部とを有する
コンテンツデータ再生システム。
【請求項7】
前記メッセージには、前記サービス鍵で暗号化されたコンテンツ鍵データが含まれ、
前記復号部は、前記暗号化されたコンテンツ鍵データを復号し、
前記記録装置が送信するメッセージに前記コンテンツ鍵データが含まれる
請求項6に記載のコンテンツデータ再生システム。
【請求項8】
前記ホスト装置は、
複数の関数入力値から前記デバイスIDに基づいて関数入力値を選択する関数入力値選択部と、
選択された前記関数入力値を処理し、関数出力値を算出する関数処理部とを更に有し、
前記コントローラは、
前記ホスト装置から受信したメッセージには前記関数出力値と前記の複数の関数入力値を処理した複数の関数結果値が前記サービス鍵で暗号化されて含まれ、
前記サービス鍵復号部にて、前記暗号化された複数の関数結果値が復号され、
前記複数の関数結果値から前記デバイスIDに基づいて関数結果値を選択し、その値が前記関数出力値と同じかどうかを判定する検証部を更に有する
請求項7に記載のコンテンツデータ再生システム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate


【公開番号】特開2012−204879(P2012−204879A)
【公開日】平成24年10月22日(2012.10.22)
【国際特許分類】
【出願番号】特願2011−64928(P2011−64928)
【出願日】平成23年3月23日(2011.3.23)
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】