JP2008205989A - コンテンツデータ管理システム及び装置 - Google Patents

コンテンツデータ管理システム及び装置 Download PDF

Info

Publication number
JP2008205989A
JP2008205989A JP2007041676A JP2007041676A JP2008205989A JP 2008205989 A JP2008205989 A JP 2008205989A JP 2007041676 A JP2007041676 A JP 2007041676A JP 2007041676 A JP2007041676 A JP 2007041676A JP 2008205989 A JP2008205989 A JP 2008205989A
Authority
JP
Japan
Prior art keywords
content data
key
usage pass
data
recording
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007041676A
Other languages
English (en)
Other versions
JP5076546B2 (ja
Inventor
Tatsuya Hirai
平井達哉
Hiroo Okamoto
岡本宏夫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007041676A priority Critical patent/JP5076546B2/ja
Publication of JP2008205989A publication Critical patent/JP2008205989A/ja
Application granted granted Critical
Publication of JP5076546B2 publication Critical patent/JP5076546B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】暗号化されたコンテンツデータを分割する場合、分割点付近のコンテンツの復号方法を正しく制御するための制御情報が、記憶装置に安全な形で記録されていないと、コンテンツの著作権者が意図した範囲を超えた利用が可能になってしまう。情報が正しく記述されないと、分割されたコンテンツについて、コンテンツの不正利用が行えないようにする必要があり、ホスト装置に多大な負荷を負わせてしまう。
【解決手段】コンテンツデータの暗号処理には、初期ベクトル生成鍵及びコンテンツ鍵が必要であるが、これらはコンテンツ復号制御情報としてまとめて扱われる。記憶装置と様々な機器の間で該復号制御情報を転送するため、両機器は相互認証され、該復号制御情報を暗号化するための鍵が共有される。そして、該鍵を用いて暗号化され、該機器間を転送される。一方、既に暗号化されたコンテンツデータを分割する場合、分割点前後の情報を、該コンテンツ復号制御情報に新たに追記する。
【選択図】 図26

Description

本発明は、コンテンツデータ管理システム及び装置に係り、更に詳しく言えば、暗号化されたコンテンツデータ記録及び再生するシステム及び装置に関するものである。
音楽データや画像データ等のコンテンツデータに著作権が存在する場合、著作権保護のための適切な方策が取られていないと、著作者の権利が侵害される恐れがある。一方、著作権保護の目的を最優先し、コンテンツデータの流通を阻害してしまうと、著作物の複製に際して著作権料を徴収することが可能な著作権者にとっても、かえって不利益となる。
著作権保護の対象となるコンテンツデータの配信は、主にデジタル通信網や、放送波などを介して行なわれる。これらのデータを利用者が利用する際は、一度何らかの記憶媒体に記録した後、再生装置で再生する場合が多い。現状、容量が大きくアクセス性能が高い制御機能付きの記憶装置として磁気ディスク装置が知られている。磁気ディスク装置は、記録再生装置に固定的に内蔵されているものがほとんどで、磁気ディスク装置に記録されたデータを他の再生装置で利用できるようなものは未だ知られていない。しかし、利便性の面から、今後は可搬型の記憶装置の利用が進む可能性がある。一方で、容量は磁気ディスク装置に比べ少ないが、著作権保護機能を伴った可搬型の記憶装置としてメモリカードが知られている。
データを再生する装置としては、このようなデータの配信を受ける時に用いた記録再生装置や、可搬型の専用の再生装置が使用される。可搬型の記憶装置を接続できる記録再生装置において、記憶装置に記録されたデータの著作権を保護するためには、記憶装置に記録されたデータを、著作権者が主張する条件の範囲を超えて再生できないように、記録再生装置及び記憶装置にセキュリティ対策を施すことが重要である。セキュリティ対策を機器に施す際には、その装置の内部及び外部から自由にアクセス可能な領域で行なわれるデータの授受に関しては、データの授受が行われる装置の間で認証処理を行ったり、データ自体に暗号化処理等を施したりして、平文で自由にデータへのアクセスが行われることがないようにする必要がある。一方で、このような認証処理や暗号化処理が厳重になるほど、利用者がデータ利用要求を発してから、実際に利用が出来るようになるまでに多くの処理が必要となり、結果としてデータの再生を円滑に行うことができない事態が生じる可能性がある。
例えば、特許文献1及び2には、利用目的のディジタルデータを暗号化する一方で、それを復号するための鍵及び復号した際の利用条件を、不正に取得,改竄などができないようにすることで、著作権を保護することが提案されている。また、特許文献3には、記憶装置とホスト装置との間で秘匿すべきデータを暗号化して入出力するときの耐タンパ性を向上させるために、ホスト装置から送られる複数の暗号入出力処理を複数の手順に分割して、並行して処理する記憶装置に関する技術が開示されている。
また、暗号化されたコンテンツデータへアクセスする際の負荷を軽減するための技術が、特許文献4に開示されている。
WO01/013358公報 WO01/043339公報 特開2004−302701公報 特開2004-7533公報
上記特許文献1及び2に開示された方法は、ディジタルデータを復号するための鍵と利用条件を2つの機器の間で転送する場合、処理の負荷が高い公開鍵の暗復号演算及び証明書の検証処理を必要とする。これらの文献は、鍵と利用条件の転送方法については記載しているが、コンテンツデータそのものの暗号化法については、特に言及していない。特に、暗号化されたコンテンツデータを分割する場合は、分割点付近のコンテンツデータの復号方法を正しく制御するための制御情報が、何らかの形で記憶装置に安全な形で記録されていないと、コンテンツデータの著作権者が意図した利用範囲を超えた利用が可能になってしまうという課題がある。
本発明の目的は、上記のような問題点を解決したコンテンツデータ管理システム、及びそのシステムにおける記録再生装置及び記憶装置を提供することにある。
上記課題を解決するため、以下のシステム及び装置を提供する。
コンテンツデータの復号化を管理するための制御情報を扱うコンテンツデータ管理システムにおいて、当該コンテンツデータを暗号化し、記憶装置へ出力し、当該記憶装置から出力された暗号化されたコンテンツデータを復号化する記録再生装置と、当該記録再生装置で暗号化されたコンテンツデータを記憶する前記記憶装置と、を有し、前記制御情報は、初期ベクトル生成鍵及びコンテンツ鍵を有し、前記コンテンツデータは、第1の単位のコンテンツデータを複数有し、前記記録再生装置は、前記第1の単位のコンテンツデータ毎に、当該第1のコンテンツデータを識別する識別番号及び前記初期ベクトル生成鍵に基づき、初期ベクトルを生成し、当該初期ベクトル及び前記コンテンツ鍵に基づき、当該第1の単位のコンテンツデータを暗号化し、当該暗号化された第1の単位のコンテンツデータを前記記憶装置へ出力し、前記記憶装置は、前記暗号化されたコンテンツデータを記憶した後、当該コンテンツデータが、所定の識別番号を割り当てられた第1の単位のコンテンツデータの途中で分割され、当該コンテンツデータの前半部分である第1の分割コンテンツデータ及び当該コンテンツデータの後半部分である第2の分割コンテンツデータに分割された場合、当該第2の分割コンテンツデータの制御情報として、前記所定の識別番号を記憶するコンテンツデータ管理システム。
コンテンツデータの複合化を管理するための制御情報を扱うコンテンツデータ管理システムに利用される記憶装置であって、記録再生装置から出力された暗号化されたコンテンツデータを記憶し、当該コンテンツデータを前記記録再生装置に出力するものであり、前記制御情報は、初期ベクトル生成鍵及びコンテンツ鍵を有し、前記コンテンツデータは、第1の単位のコンテンツデータを複数有し、前記記録再生装置は、前記第1の単位のコンテンツデータ毎に、当該第1のコンテンツデータを識別する識別番号及び前記初期ベクトル生成鍵に基づき、初期ベクトルを生成し、当該初期ベクトル及び前記コンテンツ鍵に基づき、当該第1の単位のコンテンツデータを暗号化し、当該暗号化された第1の単位のコンテンツデータを前記記憶装置へ出力し、前記記憶装置は、前記暗号化されたコンテンツデータを記憶した後、当該コンテンツデータが、所定の識別番号を割り当てられた第1の単位のコンテンツデータの途中で分割され、当該コンテンツデータの前半部分である第1の分割コンテンツデータ及び当該コンテンツデータの後半部分である第2の分割コンテンツデータに分割された場合、当該第2の分割コンテンツデータの制御情報として、前記所定の識別番号を記憶する記憶装置。
本発明によれば、暗号化されたコンテンツデータを分割した際、分割したコンテンツデータの一時復号及び再暗号化を行わずに、コンテンツデータの復号・利用を正規の範囲内にとどめることができる。
本発明は、以下に記すような特徴を有する好ましい例において実施される。すなわち、
(1) 保護が必要なデータは暗号化されること
(2) 該データを復号するために必要な鍵データと、復号が許容される条件は1つにまとめられること、
(3) 該1つにまとめられた鍵データと復号が許容される条件が媒体に記録される場合、その媒体は利用者が自由にアクセスすることができない領域であること
(4) 該1つにまとめられた鍵データと復号が許容される条件を生成し、媒体へ送信する機能を有する機能単位と、記憶媒体への記録及び再生を制御する機能単位は、所謂暗号通信路を確立すること
(5) 生成あるいは記録された該1つにまとめられた鍵データと復号が許容される条件を、(4)に記したような2つの機能単位間で転送する場合は、(4)に記したような暗号通信路内を通ること
である。
図面を参照して本発明の実施例について説明する。初めに、システム装置全体及び記憶装置の一例として磁気ディスク装置について述べ、その後で該1つにまとめられた鍵データと復号が許容される条件を転送する方法について説明する。
[システム装置構成]
図1及び図2を用いて、一実施例におけるデータ記録再生装置及びそれに接続可能な記憶装置を含むシステムの全体構成について説明する。この実施例は、放送されたデジタル映像データや、配信サーバ(Distribution Server)から配信されたデジタルデータ、また他の機器と接続したデジタル信号線を介して送信されたディジタルデータを脱着可能な記憶装置に記録し、また記憶装置に記憶されたデジタルデータを、記録再生装置のデスプレイ装置やスピーカーなどで再生する記録再生システムに適用した例について説明する。以下では、デジタルデータ記録再生装置を単に記録再生装置といい、記録再生装置が受信する映像や音楽、テキストなどのデジタルデータを、コンテンツデータという。ここで、コンテンツデータを記録する脱着可能な記憶装置は、例えば、磁気ディスク装置や半導体メモリデバイスなどであり、何れも本発明に特徴的な制御機能を有する。以下では、記憶装置として磁気ディスク装置を例に説明するが、これに限るものではない、以下に説明するような本発明に特徴的な機能を有するものであれば、磁気ディスク装置以外の他の周知な記憶装置にも適用できる。
著作権の保護が求められるコンテンツデータは、放送波を介してアンテナ131で受信したり、配信サーバ150から配信されたものをネットワークインタフェース(Network Interface)100を介して受信することによって、記録再生装置112に取り込まれる。配信されるコンテンツデータは、放送波発信元130や配信サーバ150において、所定の暗号方式により暗号化されている。その暗号方式は、それぞれのコンテンツ保護仕様によって、独自に規定されていてよい。その際、コンテンツデータを復号するための鍵データ(以下ではこれをコンテンツ鍵と呼ぶ)と、コンテンツデータの利用条件も、別途、記録再生装置112に送信される。これらのコンテンツデータを復号するための情報を、以下ではコンテンツデータの復号制御情報と呼ぶ。この復号制御情報は、コンテンツデータの送信元と同一の送信元から送信される場合もあるし、他の送信元から送信される場合もある。
記録再生装置112は、脱着可能な記憶装置、例えば磁気ディスク装置125、126を接続することができる構成を有する。磁気ディスク装置125及び126には、放送波に乗って送信されたり、配信サーバ 150から送信されたりした暗号化されたコンテンツデータ及びコンテンツデータの復号制御情報が、記録モジュール(Recording Module)102及び保護情報転送モジュール(Protected Information Transmit Module)104を介して記録される。また、再生モジュール(Playback Module)103には、脱着可能な磁気ディスク装置125や126から、暗号化されたコンテンツデータや、コンテンツデータの復号制御情報が、保護情報転送モジュール104を介して送信される。コンテンツデータの復号及び再生は、記録再生装置112内の再生モジュール103において行われる。
ところで、コンテンツデータの不正利用を防止するためには、復号制御情報に含まれるコンテンツ鍵が不正に取り出されたり、利用条件が不正に複製されたり、書き換えられたりすることがないようにする必要がある。そのためには、記録再生装置112や脱着可能な磁気ディスク装置125及び126内において復号制御情報の送受信を行ったり、情報を記録したり読み出したりする部分は、対タンパ性を持つように実装することが重要である。そのような部分は、記録再生装置112ではホストセキュリティマネージャ(Host Security Manager)111であり、磁気ディスク装置においては、ストレージセキュリティマネージャ(Storage Security Manager)225である。尚、ホストセキュリティマネージャ 111内の保護情報領域(Protected Information Storage)101の役割や、ストレージセキュリティマネージャ 225内のUsage Pass転送モジュール(Usage Pass Transfer Module)221、制限記憶コントローラ(制限記憶部 Controller)222、制限記憶部(Qualified Storage)223の具体的な役割については、後に説明する。本発明に係る実施例では、ホストセキュリティマネージャ(Host Security Manger)112及びストレージセキュリティマネージャ225内にあるモジュール間で、復号制御情報を送受信し合うための転送プロトコルに関するものである。尚、ここで、記録再生装置112及び磁気ディスク装置125、126における各モジュール及びセキュリティマネージャ等の機能の実現手段としてはハードウェア又はソフトウェア(プログラム)の何れによって構成されてもよい。
一方で、記録再生装置112の中で、ネットワークとの間のネットワークインタフェース100や、入力デバイスとの間のインタフェースブリッジ部105、磁気ディスク装置との間のインタフェース106及び107、及びこれらを制御するプロセッサ(PU)108などは、全体として、システム内部を流れるデータの処理や受け渡しを制御する機能を有する。その意味で、以下ではこれらをまとめてホストモジュール(Host Modules)110と呼ぶ。
[磁気ディスク装置構成]
次に、図2を参照して、磁気ディスク装置の構成について説明する。磁気ディスク装置には、インタフェース部220を介してデータが入出力される復号制御情報以外の、特に保護を必要としないデータが外部から入力される場合、コントローラ230を介して、ヘッド部202から磁気ディスク円盤200上に記録される。暗号化されたコンテンツデータも、このフローに従って、磁気ディスク円盤200上に記録される。読み出す場合は、前述を逆にデータが流れる。コントローラ200は、プロセッサ(PU)231からも制御される。Usage Pass転送モジュール221や制限記憶コントローラ222なども、プロセッサ231によって制御される。尚、Usage Pass転送モジュール221や制限記憶コントローラ222の詳細な挙動については、後で説明する。
一方、復号制御情報のような保護が必要なデータの記録や転送を制御するモジュール群全体であるStorage Security Managerは、高い対タンパ性を有するように実装する必要がある。但し、図2では、制限記憶部223は磁気ディスク円盤200とは別に設けられているが、暗号化されたコンテンツデータの読み出しと書き込みとは異なる特殊なアクセス方法でのみアクセスが許容されていて、また本装置を分解等し内部のデータを直接読み出す等を行うことが不可能な構成になっていれば、制限記憶部は磁気ディスク円盤200上に設けても良い。このような実装を行う場合は、Storage Contollerの挙動を外部から変えられないように、対タンパ性を有する特殊な実装をする必要がある。
[基礎前提事項]
放送波に乗せられて送信されるコンテンツデータや、他の媒体に記録されているコンテンツデータは、一般的には独自に規定された方式で暗号化されている。また、データには、その復号制御情報も含まれていることが多い。これらのデータを、アンテナ131やデジタル信号線132を介して記録再生装置112が取り込む場合、記録モジュール102は、規定された方式に従ってコンテンツデータを復号し、また復号制御情報を取り出す。取り出された復号制御情報は、本実施例において定める特定の形式を持った1つのデータにまとめられる。これを、以下ではユーセジパス(Usage Pass)と呼ぶ。Usage Passの具体的な構造については、後に図4を用いて説明する。
記録モジュール 102はUsage Passを生成すると、それを磁気ディスク装置125あるいは126に対して送信する。ただし、本送信が完了するためには、それに先立って、記録モジュール102もしくは保護情報転送モジュール104とUsage Pass転送モジュール221の間では、相互認証が完了しなければならない。認証処理が完了すると、いくつかの鍵データが共有される。そして、転送対象のUsage Passは、共有された鍵を用いて、暗号化された後、記録モジュール102からUsage Pass転送モジュール221に対して送信される。
Usage Passを転送するための処理は、大きく分けて、(1) 鍵を共有するまでの認証処理 (2) 認証処理によって共有された鍵を用いてUsage Passを暗号化し、転送する処理 の2つからなる。これらの処理方法は、2種類ある。1つは、2つのモジュール間で相互認証が終了すると、Usage Passの転送方向が一意に確定してしまう方法であり、他の1つは双方向にUsage Passを転送することができる方法である。以下では、前者による相互認証及びUsage Pass転送方式を単一方向転送モード(Unidirectional Transfer mode,略してUTモード)と呼び、後者による相互認証及びUsage Pass転送方式を双方向転送モード(Bidirectional Transfer mode,略してBTモード)と呼ぶ。これらのモードを総称して、制限アクセス(Qualified Access)モードと呼ぶ。モジュール間でUsage Passを転送する際、いずれのモードで相互認証及びUsage Pass転送を行うかは、記録再生装置を起動する際、ホストモジュール(Host Module)110が決定する。該相互認証処理には、公開鍵暗号基盤上で生成された電子署名を利用する。また、Usage Passや途中で生成される一時鍵の暗号化は、共通鍵暗号方式を用いて、CBC(Cipher Block Chaining)モードで行う。CBCモードによる暗号化処理方法ついては、例えば、「ネットワークセキュリティ(ピアソン・エデュケーション刊)」に説明がある。
磁気ディスク装置では、Usage Pass転送モジュール 221がUsage Passを受信すると、それを制限記憶コントローラ222へ送信する。制限記憶コントローラは、制限記憶部223を制御するモジュールである。Usage Pass本体は、最終的には制限記憶部223に記録される。尚、配信サーバ150が磁気ディスク装置へUsage Passを送信する場合や、ある磁気ディスク装置から他の磁気ディスク装置へUsage Passを転送する場合は、Usage Passの転送元となるモジュールが、転送先となる磁気ディスク装置内のUsage Pass転送モジュールに対して、本発明で定める方式に従って、直接Usage Passを送信しても良い。この場合、記録再生装置112内のネットワークインタフェース100や記録モジュール102は、データの一方から他方のモジュールへの転送を制御するたけで、相互認証処理やUsage Passの暗号化には直接関係しない。
[システムの鍵およびデータの構成]
図3は、図1及び図2に示した機器において、記録モジュール102、再生モジュール103、及びUsage Pass転送モジュール221の間でUsage Pass転送を実行する際、それを暗号化するために用いられる鍵データ、及び配信するデータ等の一覧を示すものである。通常、鍵データXが対称暗号用の鍵データである場合は、対象のデータは鍵データXを用いて暗号化されており、その復号も同一の鍵データXを用いて行われる。一方、鍵データXが非対称暗号用の秘密鍵あるいは公開鍵であった場合は、暗号化対象のデータは、Xとは異なるこれらに対応する公開鍵あるいは秘密鍵Yを用いて暗号化されている。Yを用いて暗号化されたデータは、Xを用いて復号される。以下では、非対称暗号用公開鍵データを公開鍵、非対称暗号用秘密鍵データを秘密鍵、対称暗号用鍵データを共通鍵と略す。データに電子署名が付けられている場合、データを一部に含むデータ集合のハッシュ値が、公開鍵Xに対応する秘密鍵Yで暗号化されていることを意味する。尚、本明細書中でK_xのように表記されているものは、全ての図ではxは添え字として表現されている。
コンテンツデータの暗号化、復号及び再生処理、Usage Passの暗号化及び復号化、記録モジュール 102、再生モジュール103、磁気ディスク装置125及び126、配信サーバ150の認証に関わる鍵として、以下のものがある。コンテンツデータを暗号化および復号するための鍵は、コンテンツ鍵K_cである。配信サーバ150、記録モジュール102、再生モジュール103、Usage Pass転送モジュール221には、それぞれ個別に互いに認証を行うための電子署名付き公開鍵KP_dcがそれぞれ割り当てられる。ただし、Host Security Manager(Host Security Manager)111を全体として1つの対タンパ性を持つ機能単位として実装する場合、Host Security Manager 111に対して1つのKP_dcを割り当てても良い。
公開鍵KP_dcにより暗号化されたデータは、これに対応する秘密鍵K_dcによって復号可能である。これらの秘密鍵データは、配信サーバ150、記録モジュール102、Usage Pass転送モジュール221、再生モジュール103について、それぞれのある有限個に対して、1つ割り当てられる。有限個という意味は、1つでも複数個でも良いことを意味する。KP_dc及びK_dcを共有する単位をClassと呼ぶ。1つのClassに対しては、Usage Passを転送したり、記録したりする部分が、実装する際に満たさなければならない安全性のレベルや、1つのUsage Pass転送方式が規定される。つまり、あるClassに属する複数のモジュールは、全てがそのClassで規定された安全性のレベルを満たす形で実装されており、また1つの共通したUsage Pass転送方法を実現するための機能を持つ。尚、以下ではこのような機器やモジュールを、総称してDeviceと呼ぶ。
KP_dcは、他の一般情報と連結された後、所定の認証局によって電子署名が与えられ、各デバイスに対する証明書としての役割を果たす。電子署名を与えるための認証局の公開鍵をKP_CA、これに対応する秘密鍵をK_CAと記す。以降では、これらの認証局公開鍵及び認証局秘密鍵と呼ぶ。証明書に記載される一般情報とは、その証明書の発行元や証明書のシリアル番号などである。以降では、KP_dcの正当性を示すための証明書をDevice Class証明書、公開鍵KP_dcをDevice Class公開鍵、鍵で暗号化されたデータを復号するために用いられる秘密鍵をDevice Class秘密鍵と呼ぶ。Device Class証明書やDevice Class秘密鍵は、出荷時に各デバイスに埋め込まれる。各デバイスに対しては、個別に埋め込まれる公開鍵KP_dと、鍵で暗号化されたデータを復号するための秘密鍵K_dも埋め込まれる。以降では、これらをDevice公開鍵、Device秘密鍵と呼ぶ。Device公開鍵とDevice秘密鍵は、全てのデバイスに異なったものが埋め込まれる。尚、公開鍵による暗号化の過程では、暗号化に用いられる公開鍵を元にして、1つの共通鍵が生成される。これは、*KP_dのように表される。同様に、秘密鍵による復号化の過程では、復号に用いられる秘密鍵を元にして、1つの共通鍵が生成される。これは、*K_dのように表される。*KP_dと*K_dは、実際には同一の値であり、*KP_dで暗号化されたデータは、*K_dで復号することができる。これらの共通鍵を、それぞれ共有Device公開鍵及び共有Device秘密鍵と呼ぶ。これらの鍵の生成方法については、後に公開鍵暗号化方法に関する説明をする際、詳細に説明する。
さらに、図1に示したシステムにおいて、使用される鍵等として以下のものがある。異なる2つのデバイス間でUsage Pass転送を行う度に、Usage Passを暗号化するために、主にUsage Passの転送先において生成される共通鍵K_sn(n ≧ 0)、及びデバイス間で相互認証処理の最終段階において両デバイスで共有されるK_s0を暗号化するために生成される共通鍵K_chである。K_ch及びK_s0は、デバイス間の相互認証処理において共有される鍵で、Usage Pass転送の際にそれを暗号化するためには利用されない。一方K_sn(n ≧ 1)については、Usage Pass転送を実行する度に、必ずK_snからK_sn+1へ更新されてから利用される。以後、K_chをChallenge鍵、K_sn(n ≧ 0)をセッション(Session)鍵と呼ぶ。特に、nが0の場合のセッション鍵を、0次のセッション鍵と呼ぶ。
各鍵に対しては、[P]もしくは[I]の添え字が与えられる。これは、鍵が、Primal Device及びInceptive Deviceのいずれで生成された(あるいは埋め込まれた)か、を示すものである。ここでPrimal Deviceとは、あるデバイスが他のデバイスとの間で相互認証を行う場合に、相手となるデバイスから送信されたDevice Class証明書の検証を最初の処理で行うもののことである。一方、Inceptive Deviceとは、同様の場合に、自身のDevice Class証明書を相手となるデバイスに送信することを最初の処理で行うもののことである。
以上に説明した鍵を用いて行う暗号化をE(X, Y)と表す。これは、データYを、鍵データXを用いて暗号化することを表す。同様に復号化を、D(X, Y)と表す。これは、データYを、鍵データXを用いて復号することを表す。また、H(X)はデータXのハッシュ値を、X || YはデータXとデータYを連結することを表す。これらの表記法は、UTモード、BTモードいずれの場合にも全て共通のものである。尚、UTモードではUsage Passの転送方向が一意に確定してしまうと以前に述べたが、その方向は常にPrimal DeviceからInceptive Deviceである。従ってUTモードでは、記録モジュール102は常にPrimal Deviceとなり、再生モジュール 103は常にInceptive Deviceとなる。一方、磁気ディスク装置は、記録モジュールから送信されたUsage Passを記録する場合はInceptive Deviceとなり、コンテンツデータの復号再生などを目的に自身からUsage Passを再生モジュールへ送信する場合は、Primal Deviceとなる。
これに対し、BTモードでは、Host Security Managerを有する装置が常にPrimal Deviceとなり、磁気ディスク装置は常にInceptive Deviceとなるが、Usage Passの転送は、Primal DeviceからInceptive DeviceへもInceptive DeviceからPrimal Deviceへも可能である。
[公開鍵暗号化による共有Device公開鍵共有方法]
相互認証及びUsage Pass転送に関する詳細な処理シーケンスについて説明する前に、本発明の実施例で用いられる公開鍵暗号化の方法について説明する。本実施例では、公開鍵暗号化の方法として楕円暗号を利用する。但し、この暗号化方式に限定するものではない。
楕円暗号は、2次元のある楕円曲線の方程式で表される曲線上の固定点(これをベースポイントG = (Gx, Gy)と呼ぶ)に対し、そのn倍点、すなわちGをn回加算するという演算を暗号化に際して利用するものである。ここで用いられる加算法は、通常の十進法の加算方式と異なり、Gを整数回加算した結果は、Gとは異なる楕円曲線上の点となるようなものである。
説明に際し、Device 1とDevice 2の2つのDeviceを想定する。そして、Device 1には暗号化すべきメッセージMが、Device 2には、ある公開鍵KPuとペアとなる秘密鍵KPrが記録されているものとする。ここで、KPrは自然数、KPuは楕円曲線上の座標点(KPux, KPuy)であり、両者及びベースポイントは、KPu = KPr × Gという関係で結ばれている。言い換えると、KPuは、ベースポイントのKPr回加算点であるということである。
まず、Device 1における暗号化処理について説明する。
(E1) Device2からDevice1へ、KPuを送信する。
(E2) Device1において、あるランダム自然数rを生成する。
(E3) r × G = R = (Rx, Ry)を計算する。
(E4) r × KPu = P = (Px, Py)を計算する
(E5) Px, Pyを用いて、ある自然数*KPuを生成する: *KPu = f(Px, Py) ここで、関数fは、事前に決めてあれば、任意でよい。
(E6) *KPuを共通鍵として用い、暗号化対象のメッセージMを、対称暗号化する: E(*KPu, M)
(E7) (E6)で得られたデータに、(E3)で得られたデータを連結し、Device 2へ送信する。送信されるデータは、Rx || Ry || E(*KPu, M)である。ここで、*KPuを共有Device公開鍵と呼ぶ。
次に、Device 2における復号化処理について説明する。
(D1) Rx, Ry, KPrを用いて、Pを計算する: KPr × R = KPr × r × G = r × (KPr × G) = r × KPu = P = (Px, Py)
(D2) Px, Pyを用いて、*KPrを求める。ここで、*KPrと*KPuは、全く同一の数である。前者は、KPrを用いて得られたという意味で、*KPrと表現されている: *KPr = f(Px, Py)
(D3) r × KPu = P = (Px, Py)を求める。
(D4) *KPrを共通鍵として用い、受信したデータを、対称復号化する: D(*KPr, E(*KPu, M)), 本発明では、これをD(KPr, E(KPu, M))と記載する。ここで、*KPrを共有Device秘密鍵と呼ぶ。以上に説明した、共通鍵*KPu、*KPrを共有するためのアルゴリズムは、一般にはECDHアルゴリズムと呼ばれている。
尚、本明細書では、処理E2から処理E7全てを行う暗号化を、E(KPu, M)と記載する。既に*KPuが求められていて、処理E6のみ行う場合は、E(*KPu, M)と記載する。同様に、処理D1から処理D4まで全てを行う復号化を、D(KPr, E(KPu, M))と記載する。既に*KPrを求められていて、処理D4のみ行う場合は、D(*KPr, E(*KPu, M))と記載する。
[Usage Passの構造]
Usage Passの構造について、図4を用いて説明する。Usage Passには、自身がどのような種類のモジュールに出力可能なものであるかを示すUsage Pass Format(UPF)400、それぞれに一意に割り当てられた識別子Usage Pass Identifier(UPID)401、対象コンテンツデータの利用を制限するための条件Usage Rules enforced in Storage Module (UR_s)402及びUsage Rules enforced in Playback Module(UR_p)404、本Usage Passで暗復号を管理するコンテンツデータの暗復号処理関連情報(コンテンツデータを暗号化及び復号化するためのコンテンツ鍵K_cを含む) Cipher Informatino of Content(CIC)403、対応するコンテンツデータを特定するための識別子Content Identifier(CID)405、コンテンツの著作権情報Copyright Information(406)が含まれる。UR_s 402は、Usage Passの転送元で内容を解釈しその出力を制御するための情報(Usage Passの転送元には、通常記録モジュールや磁気ディスク装置がなりうる)であり、UR_p 404は、再生モジュール 103がUsage Pass及びコンテンツデータを受信後、該モジュールにおけるコンテンツデータの復号処理を制御するための情報である。UR_s 402には、複製可能な世代情報を表すGeneration Count、自身からUsage Passの複製可能な回数を表すCopy Count、自身のUsage Passを使ってコンテンツデータの復号可能な回数を表すPlay Countなどが含まれる。これら全てが指定できるような形でも構わないが、本実施例ではこれらの値を解釈及び処理する場合の負荷を減らすために、いずれか一つのみが選択できるものとする。一方UR_pは、サービス毎に規定されるものであり、汎用的な制御条件は特に規定されない。
記憶装置に記録されているUsage Passについては、記録再生装置がUsage Passを参照するための命令を発行することにより、CIC 403以外の情報は全て応答される。この機能により、UPIDやUR_s,UR_pなどの情報については、転送用の暗復号処理を行わずに、記録再生装置は把握できる。
尚、各フィールドには、各フィールドを特定するためのタグデータ及びデータ本体の大きさが、データ本体と共に記述されている。例として、UPIDフィールドの構造を図5に示す。UPIDフィールドは、タグデータ500,データ本体の大きさ501,データ本体502で構成されている。各フィールドの大きさは可変でも良いが、固定長としておくと、情報格納位置が特定され、各Deviceにおいて目的のフィールドを検索する際の処理負荷を軽減できるという利点がある。そこで、本実施例では、各フィールドは図4に示すような大きさを有するものとする。UR_pは、サービス毎に多様な条件が規定される可能性があるため、他のUR_sやCICのフィールドに比べて、大きい領域が確保されている。また、磁気ディスク装置にUsage Passを記録する場合には、現状はデータのアクセス単位が512バイトであることから、Usage Pass全体の大きさは512バイト以下となるように構成しておくべきである。本実施例でも、そのようになっている。
また、UR_s 403,CIC 404,UR_p 405の後には、Usage Pass全体の大きさを拡張せずに将来制御情報の追加ができるように、Reserved areaが設けられている。
以下では、BTモードでUsage Pass転送を実現する手段について、転送モジュール構成及び処理手順を、図6から図20を用いて説明する。
[BTモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成]
図6を用いて、BTモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成について説明する。BTモードでは、磁気ディスク装置は常にInceptive Deviceとなる。そこで、Usage Pass転送モジュール630の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール 602、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール603、利用者の意思による書き換えが行えないような静的な記憶領域604、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元Device及び転送先Deviceいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール605、及び制限記憶コントローラ222へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer 610が設けられている。また、静的な記憶領域604は、保護情報領域と呼ばれる。認証用モジュール602は、必要に応じて、記憶領域へアクセスする。
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、インタフェース620及びバス640を介して行なわれる。PU 621は、図2における231と同じものである。
[BTモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成]
図7を用いて、BTモードでのUsage Pass送信が実行可能な記録モジュール102の構成について説明する。BTモードでは、Host Security Manager111全体が常にPrimal Deviceとして動作し、Usage Passは、Host Security Manager111に対して双方向に流れる。そこで、記録モジュール725は、Usage Passを出力するために必要な機能のみ包含し、Inceptive Deviceとの間で相互認証を行うための機能などは、保護情報転送モジュール104が含む構成とした方が適切である。そこで記録モジュールには、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール701、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール705、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール706が設けられている。暗号化されたコンテンツデータは、モジュール706からデータバス740へ、External Storage Interface 720を介して、磁気ディスク装置へ記録される。
記録モジュールを含むHost Security Manager 730には、利用者の意思による書き換えが行えないような静的な記憶領域704が設けられており、認証用モジュール700やUsage Pass暗号化及び送信用モジュール701、Usage Pass復旧用モジュール705などは、必要に応じて、この記憶領域へアクセスする。記憶領域704は、保護情報領域と呼ばれる。
保護情報領域 704に記録されるデータの種類等については、図10を用いて後で説明する。
[BTモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成]
図8を用いて、BTモードでのUsage Pass受信が実行可能な再生モジュール103の構成について説明する。BTモードでは、再生モジュールは、記録モジュールと同様に、常にPrimal Deviceとなる。記録モジュールについて説明した際にも述べたように、Host Security ManagerがPrimal DeviceとなってInceptive Deviceと相互認証を行うための機能は、保護情報転送モジュール104が担う。そこで、再生モジュール825には、自身がPrimal DeviceとなってUsage Passの受信を行うための機能を持ったモジュール803、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール805及び801、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール806が設けられている。この時、暗号化されたコンテンツデータは、External Storage Interface 820及びデータバス840を介して、モジュール806に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール806から直接再生モジュール外へ出力される。
再生モジュールを含むHost Security Manager 830には、利用者の意思による書き換えが行えないような静的な記憶領域804が設けられており、認証用モジュール 802や、Usage Pass受信及び復号化用モジュール803、Usage Pass復旧用モジュール805及び801は、必要に応じて、記憶領域へアクセスする。記憶領域804は、保護情報領域と呼ばれる。
保護情報領域804に記録されるデータの種類等については、図10を用いて後で説明する。
[BTモード用保護情報転送モジュールの構成]
図9を用いて、BTモード用の保護情報転送モジュール910(図7では700,図8では800に相当する)の構成について説明する。記録モジュールや再生モジュールに関する説明においても述べたように、BTモードでは、保護情報転送モジュール910がInceptive Deviceとの間の相互認証を実行する構成の方が適切である。そこで、保護情報転送モジュール910には、自身がPrimal DeviceとなってInceptive Deviceとの間で相互認証処理を実行するためのモジュール900、再生モジュール916の中のUsage Pass受信用モジュール903が生成した最新のセッション鍵を一時的に保持し、必要に応じて記録モジュール内のUsage Pass送信用モジュールへ送信するモジュール905が含まれる。
[Host Security Manager内にあるBTモード用保護情報領域の構成]
図10を用いて、記録再生装置におけるBTモード用の保護情報領域の構成を説明する。BTモードは、Usage Passを転送する向きに拠らず、Host Security Manager 111が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。それ故、通常記録モジュール102と再生モジュール103は、1つの保護情報領域を共有する形で実装した方が、記録再生装置に設ける静的記憶領域を小さくすることができる。
図10は、このような状況を想定して保護情報領域を実装した場合の内部構成を示している。尚、記録モジュール102用と再生モジュール103用の別の記憶領域を用意し、それぞれにDevice Class証明書や、相互認証に必要な鍵を記憶させておいても良い。この場合、記録モジュールと再生モジュールはそれぞれが相互認証実行用モジュールを含まなければならなくなる。そのような場合は、本実施例では説明しない。
1001は、Device Class証明書である。Device Class証明書1001には、Device Class公開鍵1000が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。1003は認証局公開鍵、1004はDevice Class秘密鍵、1005はDevice公開鍵、1006はDevice秘密鍵である。以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、セキュリティシステムが破られない限り、普通後で更新はされない。
これに対し、領域1002と1010に記録される情報は、RDCL及びConnection Logである。RDCLは、失効したDevice Classのリストである。。あるDevice Class公開鍵KP_dcの安全性が失われると、KP_dcを含む証明書の固有番号を、このリストに登録する。他のデバイスから送られたDevice Class証明書の検証を行う際には、電子署名部を用いて証明書に改竄が行われていないことを確認すると共に、証明書の固有番号が、リストに登録されていないかどうかについても確認する。Connection Logは、BTモードに固有のログ情報である。ログに記録されるのは、認証相手となるデバイスのDevice公開鍵、認証処理実行中に自身及び相手によって生成される0次セッション鍵、及びType Mapである。図示のように、Connection Logは複数のエントリを持たない。ある2つのDevice間で相互認証処理を実行した後、一方を異なるDeviceと接続し直した場合、Connection Logは上書きされてしまう。これら2つの情報は、相互認証処理において更新される情報である。ここで、Type Mapについても簡単に説明しておく。Type Mapは、「受信可能なUsage Pass Formatに関する情報」を示すものである。この情報はDevice Class証明書に含まれており、その意味で認証処理中に認証相手となるデバイスに送られる。認証相手のデバイスは、自身がUsage Pass転送元であった場合に、どういった類のUsage Passであれば相手のデバイスが受信可能であるかを、Type Mapによって判断する。例えば、あるUsage PassのUsage Pass Formatが「Type 0」を示していた場合に、認証相手デバイスから送信された証明書中のType Mapが「Type 0受信不可」となっていた場合、Usage Passの転送元デバイスは、Usage Passの転送処理を行わない。
領域1020及び1021には、Transaction Logが記録される。Transaction Logは、Usage Pass転送処理において更新される情報である。BTモードにおいて、Transaction Logとして記録されるのは、転送対象Usage PassのUPID、転送の種類(自身がUsage Passの転送元であるか転送先であるか)、転送を実行する前のUR_s(ただし、Primal DeviceがUsage Passの転送先であった場合のみ)、転送を実行する前のUsage Pass(但し、Primal DeviceがUsage Passの転送元であった場合のみ)、Usage Passが記録されているアドレス(但し、Primal Deviceが転送元であった場合のみ)あるいは記録先のアドレス(但し、Primal DeviceがUsage Passの転送先であった場合のみ)が、Usage Pass転送が実行される際に記録される。これらのデータをUsage Pass転送を行う際に記録しておくことで、不慮の事故等により、転送元及び転送先いずれからもUsage Passが失われてしまった場合にも、復旧することができるようになる。
[Usage Pass転送モジュール内にある保護情報領域の構成]
図11を用いて、磁気ディスク装置におけるBTモード用の保護情報領域の構成を説明する。前述の通り、BTモードは、Usage Passを転送する向きに拠らず、Host Security Manager 111が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。図示の通り、Usage Pass転送モジュール内に設けられる保護情報領域に記録されるデータは、Transaction Logを除き、Host Security Manager 111に記録されるデータと同一である。つまり、1101はDevice Class公開鍵1100を含むDevice Class証明書であり、1103は認証局公開鍵、1104はDevice Class秘密鍵、1105はDevice公開鍵、1106はDevice秘密鍵、そして1110はConnection Logの記録領域である。
また、図示されている通り、制限記憶部223内の保護情報領域には、Transaction Logの記録領域が設けられていない。これは、Usage Pass転送実行時には、磁気ディスク装置はTransaction Logの記録を行わないことを意味する。ログの記録処理がない分、BTモードでのUsage Pass転送時の磁気ディスク装置の処理負荷を、比較的軽く抑えておくことができるという特徴がある。上記の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない点、及びConnection LogはUsage Passを実行しようとするデバイス間で行われる相互認証処理において更新される点も、Host Security Manager 111内の保護情報領域101と同じである。
[制限記憶部223の構成]
図12を用いて、制限記憶部223の構成について説明する。制限記憶部223は、磁気ディスク装置の中にあって、記録モジュールや他の磁気ディスク装置から送られてきたUsage Passを記録し、保持する部分である。Usage Passの記録は、制限記憶コントローラ222によって制御される。制限記憶部223は、Usage Pass本体が記録される領域1200、1210、1220等と、Usage Passの有効性を示すフラグを記録する領域1201、1211、1221等から成る。以降、フラグを有効性指示フラグと呼ぶ。1201に書き込まれた有効性指示フラグは領域1200に書き込まれたUsage Passの有効性を、1211に書き込まれた有効性指示フラグは領域1210に書き込まれたUsage Passの有効性を、1221に書き込まれた有効性指示フラグは領域1220に書き込まれたUsage Passの有効性を示すものである。Usage Pass及び有効性指示フラグを記録する領域は、前記のようにペアを構成し、前記と同様に制限記憶部223内に多数設けられる。各々の有効性指示フラグ領域には、フラグとペアとなっている領域に有効なUsage Passが書き込まれると、制限記憶コントローラ 222によって、「有効」を示す値が記録される。一方、一度書き込まれたUsage Passを再生モジュールや他の磁気ディスク装置へ出力して後は、領域には「無効」を示す値が記録される。また、完全な初期状態においては、「未記録」を示す値が記録される。尚、制限記憶部に記録されているUsage Passの読み出しは、制限記憶コントローラ 222によって行われる。
[Usage Pass転送処理: 転送モード設定]
以下では、2つのDeviceの間で、Usage Passを転送する方法について説明する。
記録再生装置と記憶装置の間でUsage Pass転送を行なうためには、初めに、2つのモードのうち、いずれのモードでUsage Pass転送を実行するか、記録再生装置内のHost Modules 110が選択し、それぞれの装置におけるUsage Pass送信あるいは受信処理を行うモジュールに、選択したモードを通知する処理を行う。通常は、先ずHost Modulesが、記憶装置のStorage Security Manager 225に対して、どちらの方法でUsage Passの転送が可能か、問い合わせを行う(13000)。これに対し、Storage Security Managerは、自身に実装されている転送モードを、Host Modulesに対して応答(13001)する。続いてHost Modules 110は、Storage Security Manager 225に対して、どちらのモードでUsage Passの転送を実行するか、設定する(13010)。
[Usage Pass転送処理: BTモード Connection Stage]
BTモードでは、Usage Passを転送する方向が固定されておらず、Primal DeviceとInceptive Deviceの双方が、Usage Passの送受信を実行できる。BTモードの下で、記録再生装置にあって相互認証処理やUsage Passの送受信処理を実行するモジュールをPrimal Device、記憶装置にあって相互認証処理やUsage Passの送受信処理を実行するモジュールをInceptive Deviceと呼ぶ。Device Class証明書をInceptive Device Class証明書、Device Class公開鍵をInceptive Device Class公開鍵と呼ぶ。以下、図14を用いて、BTモードでのConnection Stageについて説明する。Connection Stageとは、Primal DeviceとInceptive Deviceが相互認証を行い、RDCLの更新や所定の秘密鍵を共有する処理のことである。
BTモードが設定されると、Inceptive Device内のConnection用モジュール602は、自身に埋め込まれているDevice Class証明書を、Host Security Manager 111へ送信(14000)する。
Primal Deviceでは、受信した証明書の正当性を検証し、検証の結果受信した証明書の正当性が確認されると、一時的な共通鍵暗号化のための鍵であるPrimal Challenge鍵(PD.C.Key)を生成する。続いて、受信したDevice Class公開鍵を用いてPrimal Challenge鍵を暗号化し、生成された暗号化データにPrimal Device Class公開鍵を含むPrimal Device Class証明書を連結し、Inceptive Deviceに送信する(14010)。以上の処理が、14001である。
Inceptive Deviceでは、受信した該データを、自身のDevice Class秘密鍵を用いて復号し、Primal Challenge鍵を取得する。続いてInceptive Deviceは、一時的な共通鍵暗号化のための鍵であるInceptiveセッション鍵(ID.S.Key)を生成する。この鍵の生成を終えると、自身に埋め込まれているInceptive Device公開鍵と連結し、受信したPrimal Device Class鍵で暗号化する。更に、得られたデータ(即ち、Primal Device Class鍵で暗号化されたデータ)に対し、自身に記録されている失効Device Classリスト(Inceptive RDCL)及びChecksumを連結し、受信したPrimal Challenge鍵で暗号化する。該暗号化処理を終了すると、得られたデータをPrimal Deviceへ送信する(14020)。以上の処理が、14011である。
Primal Deviceは、受信したデータ(即ち、暗号化されたデータ)をPrimal Challenge鍵で復号し、データの完全性をChecksumで検証後、その結果からInceptive RDCLを取り出す。RDCLには、データの発行日情報が含まれているので、Inceptive RDCLの発行日情報と、自身に記録されているRDCL(Primal RDCL)の発行日情報とを比較する。その結果、Inceptive RDCLの発行日の方が新しければ、Primal RDCLをInceptive RDCLで上書きする。RDCLの発行日比較を終えると、残りのデータをPrimal Device秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である0次Primalセッション鍵(PD.S.Key)を生成する。該鍵の生成を終えると、先に受信したInceptive Device公開鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Challenge鍵で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する(14030)。以上の処理が、14021である。
Inceptive Deviceは、受信したデータをInceptive Challenge鍵で復号し、データの完全性を検証する。復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLを該Primal RDCLで上書きする。続いて、残りのデータをPrimal Device公開鍵で復号し、0次Primalセッション鍵を得る。続いて、一時的な共通鍵暗号化のための鍵である0次Inceptiveセッション鍵(ID.S.Key)を生成する。該鍵の生成を終えると、Primal Device公開鍵、0次Primalセッション鍵、0次Inceptiveセッション鍵、Primal Device Class証明書に含まれるType Map情報を、Inceptive Connection Logに記録する。そして、先に受信した0次Primal セッション鍵及びPrimal Device公開鍵で暗号化し、Primal Deviceへ送信する(14040)。以上の処理が、14031である。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及び0次Primal セッション鍵で復号し、0次Inceptive セッション鍵を得る。続いて、Inceptive Device公開鍵、0次Inceptiveセッション鍵、0次Primalセッション鍵、Inceptive Device Class証明書に含まれるType Map情報を、Primal Connection Log(CL)に記録する(14041)。
以上の処理を、BT Connection Stageと呼ぶ。BT Connection Stageを完了すると、0次Primalセッション鍵、0次Inceptiveセッション鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Primal Device鍵、及びInceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。
[Usage Pass転送処理: BTモード PI Transfer Stage]
認証処理を終えると、Usage Pass転送を実行することができる。初めに、Primal DeviceからInceptive DeviceへのUsage Pass転送処理について、図15を用いて説明する。
まず、Primal Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュール701に準備する。続いて、Inceptive Deviceは、Usage Passを暗号化するためのn次Inceptiveセッション鍵(ID.S.Key)を生成する。該鍵の生成を終えると、1つ前のPrimal DeviceからInceptive DeviceへのUsage Pass転送時に生成したInceptive セッション鍵(n-1次Inceptive セッション鍵)と、その時点で最新のPrimalセッション鍵で暗号化し、Primal Deviceへ送信する(15020)。以上の処理が、15011である。
Primal Deviceは、受信したデータをその時点で最新のPrimalセッション鍵及びn-1次Inceptiveセッション鍵で復号する。そして、転送対象Usage PassのUPID、転送における自身の役割(転送元S = Source)、送信予定のUsage Passを、Transaction Logへ記録する。尚、BTモードでは、Transaction Logの記録は、Primal Deviceのみが行う。続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Inceptive DeviceにおけるUsage Passの記録先アドレスをTransaction Logに記録した後、Usage Passに利用目的(複製、移動、再生のいずれか)を示すパラメータやChecksumを連結し、n次Inceptive セッション鍵と共有Inceptive Device鍵で暗号化する。暗号化を終えると、記録先アドレスと共に、暗号化されたUsage Passを含むデータをInceptive Deviceへ送信する(15030)。以上の処理が、15021である。
Inceptive Deviceは、受信したデータを共有Inceptive Device鍵及びn次Inceptive セッション鍵で復号する。そして、該データをInceptive Device内のUsage Pass記憶領域へ記録する。以上の処理が、15031である。
以上が、BTモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理である。これをBT PI Transfer Stageと呼ぶ。
[Usage Pass転送処理: BTモード IP Transfer Stage]
次に、Inceptive DeviceからPrimal DeviceへのUsage Pass転送処理について、図16を用いて説明する。
まず、Host Modules 110は、目的のUsage Passが記録されているアドレスや、目的のUsage PassのUPIDをInceptive Deviceに対して通知する(16000)。
これを受けて、Inceptive Deviceは、Usage Pass転送用モジュール603に目的のUsage Passを準備する。続いてInceptive Deviceは、Usage Passに対し、CICフィールド403を0で置き換え、Usage Passの状態情報Usage Pass Status(UPS)を連結した後、データに最新のPrimal セッション鍵とInceptive セッション鍵連結してHash値を計算する。そして、得られたHash値を、Masked Usage Passに連結し、Primal Deviceへ送信する。前記CICフィールド403を0で置き換えたUsage Passを、以下ではMasked Usage Passと呼ぶ。以上の処理が、16001である。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないことを確認する(16011)。
続いて、Host Modules 110は、Primal Deviceに対して、転送対象Usage PassのUPIDを送信する(16020)。
Primal Deviceは、受信したUsage PassのHost Modules 110から受信したUPIDと、Masked Usage Passとして受信したUsage PassのUPIDを比較する。これらが一致していた場合は、UPID、転送における自身の役割(転送先D = Destination)、転送対象Usage Passに記述されているUR_s、Inceptive Deviceにおいて転送予定のUsage Passが記録されているアドレスを、Transaction Logに記録する。続いて、m次Primalセッション鍵(PD.S.Key)を生成し、1つ前のInceptive DeviceからPrimal DeviceへのUsage Pass転送で生成されたPrimal セッション鍵(m-1次Primalセッション鍵)と、その時点で最新のInceptive セッション鍵で暗号化し、Inceptive Deviceへ送信する(16030)。以上の処理が、16021である。
Inceptive Deviceは、受信したデータをその時点で最新のInceptive セッション鍵及びm-1次Primal セッション鍵で復号する(16031)。続いて、Host Modules 110は、どのような形態でのUsage Pass転送処理なのか(複製,移動,再生等)を、Inceptive Deviceへ通知する(16040)。これを受けてInceptive Deviceは、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Usage Passに利用目的(複製、移動、再生のいずれか)を示すパラメータやChecksumを連結し、m次Inceptive セッション鍵と共有Primal Device鍵で暗号化後(16041)、Primal Deviceへ送信する(16050)。該データを送信後、Inceptive Deviceでは、転送を行ったUsage PassのUR_sやFlag(1101等)を適切に変更し、記録し直す(16051)。
Primal Deviceは、受信したデータを共有Primal Device鍵及びm次Primal セッション鍵で復号し、目的のUsage Passの転送が完了する(16052)。
以上が、BTモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理である。これをBT IP Transfer Stageと呼ぶ。
[Usage Pass転送処理: BTモード Reconnection Stage]
記録再生装置に異常が発生し、Connectionが切断されてしまった場合(26001)、Connection Stageと比べると、より簡単な処理で、再びConnectionを確立するための処理が、BT Reconnection Stageである。BT Reconnection Stageについて、図17を用いて説明する。
まず初めに、Host Modules 110が、Primal Deviceに対し、新たな0次Primalセッション鍵(PD.S.Key)の生成要求を送信する(17010)。
続いてPrimal Deviceにおいて、新たな0次Primalセッション鍵を生成する。そして、Primal Connection Logに記録されているInceptive セッション鍵とInceptive Device公開鍵で、生成した該鍵を暗号化する。そして、得られたデータをInceptive Deviceへ送信する(17020)。以上の処理が、17011である。
Inceptive Deviceは、受信したデータをInceptive Connection Logに記録されているInceptive Device秘密鍵及びInceptive セッション鍵で復号する。そして、新たな0次Inceptiveセッション鍵(ID.S.Key)を生成し、Inceptive Connection Logに記録されているPrimalセッション鍵とPrimal Device公開鍵で、生成した該鍵を暗号化する。続いて、受信した0次Primalセッション鍵及び生成した0次Inceptive セッション鍵を、Inceptive Connection Logに上書き記録し、先に暗号化したデータを、Primal Deviceへ送信する(17030)。以上の処理が17021である。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及びInceptive Connection Logに記録されている0次Primalセッション鍵で復号する。そして、得られた新しい0次Inceptiveセッション鍵と、先に生成した0次Primal セッション鍵を、Primal Connection Logに上書き記録する。以上の処理が、17031である。
以上の処理を、BT Reconnection Stageと呼ぶ。
[Usage Pass転送処理: BTモード PI Recovery Stage]
記録再生装置に異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。
BT Connection StageもしくはBT Reconnection Stageを完了すると、新しい0次Primal セッション鍵、0次Inceptive セッション鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Primal Device鍵Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Inceptive Device鍵が共有されていることは、先に述べた通りである。
初めにBT PI Transfer Stageに対する復旧処理について、図18を用いて説明する。BT PI Transfer Stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにHost Modules 110が、復旧対象のUsage PassのUPIDをPrimal Deviceに送信する(18010)。
Primal Deviceは、このUPIDを用いて、Primal Transaction Logを検索する(18011)。その結果、該UPIDを含むPrimal Transaction Logが見つかると、Logに記録されているInceptive DeviceにおけるUsage Passの記録先アドレス(受信したUsage Passを記録する予定だったアドレス)をHost Modulesへ送信する(18012)。Host Modules 110は、該アドレスを受信すると、UPIDと共に、該アドレスをInceptive Deviceへ送信する(18020)。
Inceptive Deviceは、受信したアドレスでアクセスされるUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べる。そして、その結果をUsage Pass Statusに設定する。そして、m次Primalセッション鍵、n次Inceptiveセッション鍵、UPID、検索されたUsage PassのUR_s,生成されたUsage Pass Status,Usage Passの記録先アドレスを連結し、Hash値を計算する。そして、UPID、検索されたUsage PassのUR_s,生成されたUsage Pass Status,Usage Passの記録先アドレス、Hash値を連結し、Primal Deviceへ送信する(18030)。以上の処理が、18021である。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが存在しないことを確認する。検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、該Logに記録されている転送前のUsage Passを、現在Usage Pass送信用モジュール701に用意されているUsage Passに上書きする。
以上が、BTモードにおけるBT PI Transfer Stageに対するUsage Passの復旧処理である。これを、BT PI Recovery Stageと呼ぶ。このStageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
[Usage Pass転送処理: BTモード IP Recovery Stage]
次に、BT IP Transfer Stageに対するUsage Passの復旧処理について、図19を用いて説明する。BT IP Transfer Stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにHost Modules 110が復旧対象のUsage PassのUPIDを、Primal Deviceに送信する(19010)。
Primal Deviceは、このUPIDを用いて、Primal Transaction Logを検索する(19011)。その結果、このUPIDを含むPrimal Transaction Logが見つかると、Logに記録されているInceptive DeviceにおけるUsage Passの記録先アドレス(転送対象のUsage Passが元来記録されていた領域を指し示すアドレス)をHost Modulesへ送信する(19012)。Host Modules 110は、該アドレスを受信すると、UPIDと共に、該アドレスをInceptive Deviceへ送信する(19020)。
Inceptive Deviceは、受信したアドレスでアクセスされるUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べ、その結果をUsage Pass Statusに設定する。そして、m次Primalセッション鍵、n-1次Inceptiveセッション鍵、UPID、検索されたUsage PassのUR_s,生成されたUsage Pass Status,Usage Passの記録先アドレスを連結し、Hash値を計算する。そして、UPID、検索されたUsage PassのUR_s、生成されたUsage Pass Status、Usage Passの記録先アドレス、Hash値を連結し、Primal Deviceへ送信する(19030)。以上の処理が、19021である。
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが、過去の転送(送信)処理によって、変化してしまったかどうかを確認する(19031)。
上記検証と並行して、Host Modules 110は、Inceptive Deviceに対し、セッション鍵(ID.S.Key)の生成を要求する(19040)。該要求を受信すると、Inceptive Deviceは、n次Inceptiveセッション鍵を生成する。この鍵の生成を終えると、生成されたn次Inceptiveセッション鍵をn-1次Inceptive セッション鍵及びm次Primalセッション鍵で暗号化し、Primal Deviceへ送信する(19050)。以上の処理が、19041である。
Primal Deviceでは、データを受信後、先に述べた検証処理によって、Usage Passが送信処理を実行することによって変化してしまっていることが確認されると、以下に記すUsage Passの復旧処理を実行する。まず、受信したデータを、m次Primal セッション鍵及びn-1次Inceptive セッション鍵で復号する。続いて、先に検索の結果見つけられたTransaction Logに記録されているUR_sを、Usage PassのUPIDに連結し、n次Inceptiveセッション鍵及び共有Inceptive Device鍵で暗号化する。暗号化を終えると、そのデータをInceptive Deviceへ送信する(19060)。以上の処理が、19051である。
Inceptive Deviceは、受信したデータを、共有Inceptive Device鍵及びn次Inceptiveセッション鍵で復号する。そして、復号結果に含まれるUPIDが、復旧対象Usage PassのUPIDと一致しているか確認する。UPIDの一致が確認されると、復号結果に含まれるUR_sを、Inceptive Device中に存在するUsage Passに上書き記録する。以上の処理が、19061である。
以上が、BTモードにおけるBT IP Transfer Stageに対するUsage Passの復旧処理である。これを、BT IP Recovery Stageと呼ぶ。このStageを完了すると、Inceptive Deviceには、送信を行う前のUsage Passが存在するようになる。
[Host Modulesによる、記憶装置に記録されているUsage Passの参照処理: UP Inquiry Stage]
記憶装置に記録されているUsage Passのうちの、CIC以外の情報をHost Modulesが把握するための処理について説明する。これをUP Inquiry Stageと呼ぶ。これは、記憶装置がPrimal DeviceであってもInceptive Deviceであっても、またConnection StageがUTモード,BTモードのいずれで確立されていたとしても、実行可能な処理である。
まず、Host Modules 110が、Usage Passが記録されている記憶装置に対して、Masked Usage Pass転送要求を送信する(20000)。記憶装置は、該要求を送信すると、Host Modules 110に対して、Masked Usage Passを応答する(20001)。
[コンテンツデータの暗号化方法]
次に、Usage Passに含まれるCICフィールド403に含まれるコンテンツ鍵を用いて、実際にコンテンツデータを暗号化する方法について、図21を用いて説明する。該暗号化は、共通鍵暗号方式と呼ばれる方法を用いる。共通鍵暗号方式は、暗号化と復号化に、同じ鍵データを用いる。共通鍵暗復号のアルゴリズムとしてはどのようなものを用いても構わない。但し、以下では128ビット(16バイト)単位で、128ビットの鍵データを用いて暗号化を行う方法を仮定して説明する。これを、E128と表現することにする。
ある程度の長さのデータを共通鍵方式暗号化する場合は、コンテンツデータを固定長毎に暗号化する方法(ECBモード)より、連鎖的に暗号化する方法(CBCモード)の方が、攻撃に対して破られにくい。そこで以下では、コンテンツデータはUsage Pass同様に、CBCモードで暗号化することとする。暗号化のための鍵データは、Usage Passに含まれるコンテンツ鍵であるが、CBCモードによってデータの暗復号を行なうためには、該鍵データの他に、鍵データと同じ長さの初期ベクトル(Initial Vector,IV)が必要である。
E128によって、16バイト単位,CBCモードで暗復号処理を実行する場合、コンテンツデータを16バイトの整数倍の長さで分割して処理を行うと都合が良い。なぜなら、CBCモードは再帰的に暗号化を行う処理方法であるため、分割せずに暗号化処理を行うと、コンテンツを途中から利用したい場合でも、常に先頭から復号しなければならないからである。
一方、現在の磁気ディスク装置は、アクセス単位が512バイト(これを1セクタと呼ぶ)であることから、CBCモードによって暗号化を行うデータの単位は、512バイトの整数倍でもあった方が無駄な処理を省くことができる。
そこで本実施例は、CBCモードによる暗号化処理の最小単位を、3072バイトとすることにする。3072バイトは、16バイトの192倍であり、また512バイトの6倍でもある。このコンテンツデータのブロックを、アラインドユニット(ALNU)21000と呼ぶ。無論、ALNUの長さは、必ずしも3072バイトでなくとも良い。
ALNUは、CBCモードによる暗号化の最小単位であるので、異なるALNUに対しては、異なる初期ベクトルが用いられる。また、同様のことはコンテンツ鍵についても言える。より詳細に言えば、16バイト毎に異なるコンテンツ鍵を用いて暗号化する形にすることが可能である。しかし、コンテンツ鍵はUsage Passに含まれるデータであるので、コンテンツデータの暗号化あるいは復号化にあまりに大量のコンテンツ鍵が必要であるとすると、該コンテンツ鍵を含む大量のUsage Passの転送処理が必要になり、ホスト装置及び記憶装置の負荷が非常に高くなってしまう懸念がある。
そこで、1つのコンテンツ鍵を用いて暗号化を実行するコンテンツデータの最小単位を、アロケーションユニット(ALCU)21010として新たに定義する。ALCUの大きさは、16バイトの整数倍であればいくつでも良いが、ALNUの整数倍でもあった方が、都合が良い。そこで、本実施例ではその大きさを、1.5メガバイト(1572864バイト)とする。但し、必ずしもこの大きさでなくとも良い。1.5メガバイトは、3072バイトの512倍である。つまり、一つのALCUの中には、512個のALNUが含まれる。
ここで、初期ベクトルについて求められる多様性について述べる。コンテンツデータはALNU毎にCBCモードで暗号化されるが、全てのALNUでCBCモード処理のための初期ベクトルの値を変える必要はない。しかし、適当な大きさ毎に変更した方が、同一初期ベクトルを用いた暗号化データの標本数を少なくすることができるため、より安全性を高めることができる。そこで本実施例では、ある1つの初期ベクトルを用いて、CBCモードで暗号化を行うコンテンツデータの単位を、1つのコンテンツ鍵を用いて暗号化を行う単位と同じにする。これは、1つのALCU内の各ALNUは、同じ初期ベクトルを用いて暗号化を行うということである。
以上、ALCUの暗号化法について、図22に示す。図中E-CBC 22000は、E128方式で、CBCモードで暗号化する処理ブロックである。
このようにしてコンテンツデータの暗号化を行うためには、Usage Passの中に、コンテンツ鍵と共に、初期ベクトル値を記載しておく必要がある。IVは、暗復号処理を実行する場合に必要なパラメータであるので、UP Inquiry Stageでも記録再生装置に開示しないようにする方が望ましい。そこで、初期ベクトル値は、CICフィールドに、コンテンツ鍵と共に記載することにする。
ところで、ALCUは、ある1つのUsage Passに含まれるコンテンツ鍵で暗号化を行う、最小のコンテンツデータの単位であることは先に述べた通りである。これは、逆の見方をすれば、複数のALCUが1つのコンテンツ鍵で暗号化されるような場合も許容されるということである。例えば、1つのコンテンツ鍵を用いて、1024個のALCUが暗号化されるような場合がそれに当たる。
しかし、初期ベクトルの一様性はALCU内に限定されている。従って、1つのUsage Pass(コンテンツ鍵)で複数のALCUの暗復号処理が管理される場合には、個々のALCUの暗復号処理で用いる初期ベクトルは、異なる値とすべきである。
そこで、このような場合に対応できるような初期ベクトル値の決め方について、図23及び図24を用いて説明する。まず、1つのUsage Pass(コンテンツ鍵)で複数のALCUが管理される場合、初期記録時には、各ALCUに対して、1から始まるALCU識別番号(ALCU Number)を割り当てる。この模様を、図23に例示する。本図例は、
Usage Pass #1によって管理される複数のALCU Numberを1からp,
...
Usage Pass #mによって管理される複数のALCU Numberを1からr,
...
Usage Pass #nによって管理される複数のALCU Numberを1からs
のように管理する場合を想定している。この識別番号は、ある1つのUsage Passで管理されるALCUについては、全て必ず異なる値となるので、初期ベクトルとして利用することができる。そこで、該値を初期ベクトルとしてそのまま利用するか、該値を用いて何らかの方法で別の値を生成すれば、それを初期ベクトルとして利用できる。特に、該識別番号を何らかのデータで暗号化した結果を初期ベクトルとして用いれば、初期ベクトルの秘匿性を更に高めることができる。
そこで本実施例では、
(a1) ALCU Numberを暗号化して、初期ベクトルとして用いる
(a2) ALCU Numberを暗号化するための鍵データは、コンテンツ鍵とは別に設定する
(a3) ALCU Numberを暗号化するための鍵データは、初期ベクトル生成鍵(IVGK)として、コンテンツ鍵同様に、Usage Pass内のCICフィールド403に記載する
という特徴を持たせることとする。尚、ここで暗号化の方法は特に問わないが、コンテンツと同様のものとしておくと、実装する際異なる暗復号用機能モジュールを搭載する必要がなくなるという利点がある。そこで、本実施例では、E128を用いて暗号化することとする。但し、ALCU Numberは、コンテンツデータのように長いデータではないので、暗号化はECB(Electronic Code Book)モードで実行する。ECBモードでは、暗号化を実行しようとするデータを必要な長さ(固定長)に分割し、分割された個々のブロックを単純に暗号化する方法である。
ALCU Numberの暗号化に関しては、該処理を実行するための鍵データを、コンテンツ鍵と同様にUsage PassのCICフィールド403に記録しておき、該データを用いて該識別番号を暗号化したものを、各ALCU内でのCBC暗号化用の初期ベクトルとして利用することにする。この方法を、図24に例示する。
しかし、このような方法でコンテンツデータを暗号化すると、一度記録したコンテンツデータを分割する場合に問題がある。この模様を、図25を用いて説明する。
例えば、コンテンツデータを、Usage Pass #mで管理されているALCU(25000から25001)を、ALCU Number kのALCU 34010途中で分割したとする。ここで、分割したコンテンツデータのうちの後半部を、該コンテンツデータ及びそれらを管理するUsage Passが記録されている記憶装置から別の記憶装置へ移動するためには、Usage Pass #mを複製し、一方をコンテンツデータと共に、移動先記憶装置へ移動する必要がある。何故なら、そうしなければ移動先記憶装置にはALCU NumberがkであるALCU 25010からALCU NumberがrであるALCU 25001までを復号するためのUsage Passが存在しないことになってしまうためである。
一方、ALCUは暗号化されているので、通常は記憶装置内の自由にアクセスできる領域に記録されており、それゆえ利用者自身による自由な複製が可能である。そこで、これらのALCUを、別の記憶装置へ複製したとする。一方、ALCU Number 1 25000からALCU Number r 25001のALCUは、これを復号するためのUsage Pass #mが2個存在するので、そのうちの一方を、前記ALCUを複製した記憶装置へ、複製ではなく移動する。すると、転送元でも転送先でも該ALCU Number 1 25000からALCU Number r 25001の復号が可能となる。これでは、Usage Pass #mのUR_s 402において複製制限が課せられている場合、それを違反することになってしまう。
このような状況が発生しないようにするために、更にUsage Passに記述する情報を増やすことにする。但し、ここで1つ前提条件を付与する。それは、コンテンツデータを分割する場合、ALNU単位のみに制限する、というものである。もし、ALNUの途中での分割も許容すると、分割点を含むALNU全体を一旦復号した後で分割を行い、その後で再暗号化を行わなければならない。理論的には、ALNUの途中で分割を許容しても構わないが、該条件を課すことによって、分割した際の分割点を含むALNUの復号化及び再暗号化処理の実行が不要になる。
図25は、以上の条件を満たすようにコンテンツデータの分割を行った様子も示している。ALCU Number kのALCUは二つに分割されているが、このうち前半部にはt個(25020)のALNUが、後半部には512 t個(25021)のALNUが含まれているとする。
分割点に関する上記のような制約を設けたところで、Usage Passには以下に記す情報を記述する。記述するフィールドは、CICの中とする。拡張されたCICフィールドの構造を、図26に示す。
(b1) [分割されたコンテンツデータ前半部向け] 最後のALCU Number(2607)
(b2) 情報(b1)を記録してあるフィールドに記述されている値の有効性表示情報(1ビットで可,2606)
(b3) [分割されたコンテンツデータ前半部向け] 最後のALCUに含まれるALNUの数(2608)
(b4) 情報(b3)を記録してあるフィールドに記述されている値の有効性表示情報(1ビットで可,2608)
(b5) [分割されたコンテンツデータ後半部向け] 最初のALCU Number(2604)
(b6) 情報(b5)を記録してあるフィールドに記述されている値の有効性表示情報(1ビットで可,2603)
(b7) [分割されたコンテンツデータ後半部向け] 最初のALCUに含まれるALNUの数(2605)
(b8) 情報(b7)を記録してあるフィールドに記述されている値の有効性表示情報(1ビットで可,2605)
Playback Module 825は、該値が記述されたUsage Passを受信すると、まず(b2), (b4), (b6), (b8)の情報を確認する。そして、これらが該当するフィールドに有効な情報が記述されていることを示していると解釈された場合は、(b1), (b3), (b5), (b7)のいずれかの対応するフィールドを確認する。そして、記録されている値に応じて、適切なALCU及びその内部のALNUまでコンテンツデータを復号する。このようにすることによって、UR_s(402)において複製制限情報が記述されていた場合には、それを違反することがないようにできる。
尚、上記(b1)から(b8)の情報は、図4に示したUsage Passの内部であれば、どこへ記述しても良い。本情報は、暗号化されたコンテンツデータの復号を制御する情報であるので、例えばUR_pへ記述する場合などである。しかし、CICフィールド403へ記述すると、より攻撃に対する耐性を高めることができる。その理由としては、下記のような事項が挙げられる。
(c1) Usage Passは、CBCモードで暗号化されているため、暗号文上の1ビット改竄を行うと、復号結果では該情報を含む次の復号単位まで影響が及ぶ。本実施例で記したように16バイト単位で、二重に暗号化を行う場合は、復号結果において該16バイトを含む前後64バイトに改竄範囲が影響する。
(c2) 暗号化されたUsage Passの一部を改竄した結果、(b2),(b4),(b6),(b8)のいずれかのビット値が反転してしまうと、Playback Moduleは、(b1),(b3),(b5),(b7)等のフィールドに制御すべき値が記述されていたにも関わらず、該値に基づいた復号制御を行わなくなってしまう。(復号可能なALNUが制限されているにも関わらず、制限されていないものとして復号処理を実行してしまう)。
(c3) 改竄が影響する範囲に確認すべきタグ値(例えば500)がなかった場合、実際に改竄が行われたとしても、そのことをPlayback Moduleが検出できない(改竄が影響する範囲が、全てReserved areaに収まってしまっている場合は、このような状況にある可能性が高い)。図4の説明の際にも述べたが、UR_pに記述される制御条件はサービス毎に異なってよいので、他のフィールドに比べ、相対的に大きい領域を確保しておくことが望ましい。場合によっては、CICフィールドより多くのデータが記述されることもありうるが、逆に何も記述されない場合もある。そのような状況を考慮すると、Reserved領域の大きさも含め、比較的小さい大きさに固定されているCICフィールドに、該情報を記述することは、理に叶っている。
以上のようなことを考慮すると、CICフィールド403に(b1)から(b8)の情報が記述されていたとして、これらに改竄が行われた結果、UR_pのタグ値まで変えてしまう可能性は、UR_pフィールド404に(b1)から(b8)の情報が記述されていたとして、これらに改竄が行われた結果、CIDのタグ値を変えてしまう可能性より高いと言える。また、CICフィールド403は、Host Modules 110によるUsage Pass参照要求に対して、記憶装置からは開示されないので、その意味でもこちらに記録しておいた方が、より安全性は高いと言える。
以上の実施例によれば、コンテンツデータの暗復号を管理するための情報を、暗号化されたコンテンツデータとは別に管理,記録,転送等するシステムにおいて、暗号化されたコンテンツデータを分割する場合に、記録再生装置の暗号演算に関する負荷を軽減する適切な方法を提供することができる。
以上、実施例について説明したが、本発明は上記実施例に限定されない。また、種々変形して実施したり、また他の装置やシステムにも応用できるであろう。特に、UTモードによる認証処理(Connection Stage)やUsage Pass転送処理(Transfer Stage)について詳細は述べなかったが、該方法でUsage Pass転送が行われる場合にも、本実施例に記述した内容がそのまま適用可能である。更に言えば、機器同士の認証方法や、機器間転送時のコンテンツ鍵や利用条件の暗号化方法は、UTモードやBTモードに限らず、より一般的なものであっても良い。本実施例では、コンテンツ鍵や利用条件は転送の際には二重に暗号化されたが、これは一重であったり、あるいは三重以上であったりしても良い。
また、上記実施例において説明された命令やモジュール等の呼び名は、あくまで一例であって上記の例に限定されない。例えば、上記実施例におけるユーセジパス(Usage Pass)は、ライセンス情報、或いは機密情報と呼ばれる場合もあろう。
また、上記実施例では、記録再生装置と磁気ディスク装置を含むシステムにおけるコンテンツデータのセキュリティ管理について述べたものであるが、他の例によるシステム及びその構成装置にも適用可能である。即ち、本発明に係る、コンテンツデータの復号化を管理するための制御情報を取扱う特徴的な処理機能を有すれば、記録再生装置及び磁気ディスク装置に限定されない。この特徴的な処理機能を有する限りにおいて、例えば、磁気ディスク装置は、半導体メモリを含む記憶装置でもよく、また、記録再生装置は、記憶装置が接続されるホストコンピュータでもよい。
また、他の変形例においては、上記実施例の鍵データ等を記憶する保護記憶領域は、論理的に対タンパ性が確保されていれば、必ずしも物理的に対タンパ性を有するメモリであることを要しない。
本発明の一実施例が適用される記録再生装置を含むのデータ保護システムを示す概略構成図。 一実施例による脱着可能な磁気ディスク装置の構成図。 一実施例において使用されるデータ、情報、及び記号法等を示す表。 一実施例において使用されるデータの復号条件や復号鍵をまとめたデータ(Usage Pass)の構成図。 一実施例において使用される図4に示したデータ(Usage Pass)のUPIDフィールドの構造図。 一実施例による磁気ディスク装置におけるBTモードを実現するUsage Pass転送モジュール図。 一実施例による記録再生装置において、BTモードでUsage Pass送信を実現する記録専用の機能モジュールの構成図。 一実施例による記録再生装置において、BTモードでUsage Pass受信を実現する復号専用の機能モジュールの構成図。 一実施例による記録再生装置において、BTモードで磁気ディスク装置との間で相互認証処理を実現する機能モジュールの構成図。 一実施例による記録再生装置において、BT及びUTモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例による磁気ディスク装置において、BTモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例による磁気ディスク装置において、図4等に示したUsage Passを記録する、対タンパ性を有する静的な記憶領域を示す図。 一実施例によるUsage Pass転送処理におけるアクセスモードの認識、設定のための処理シーケンスを示す図。 一実施例における、BTモードで記録再生装置と磁気ディスク装置の間で行われる相互認証処理シーケンスを示す図。 一実施例における、BTモードで記録再生装置から磁気ディスク装置に対して送信される、Usage Pass転送処理シーケンスを示す図。 一実施例における、BTモードで磁気ディスク装置から記録再生装置に対して送信される、Usage Pass転送処理シーケンスを示す図。 一実施例における、BTモードで記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シーケンスを示す図。 一実施例における、BTモードで記録再生装置から磁気ディスク装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シーケンスを示す図。 一実施例における、BTモードで磁気ディスク装置から記録再生装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シーケンスを示す図。 一実施例における、ホストモジュールに対し、コンテンツ鍵以外のUsage Passの情報を、記憶装置が応答する処理シーケンスを示す図。 一実施例における、コンテンツデータの暗号化と、Usage Passの関連関係を示した図。 一実施例における、コンテンツデータの暗号化方法を示した図。 一実施例における、コンテンツデータの暗号化と、Usage Passの関連関係を示した図。 一実施例における、コンテンツデータの暗号化に際して用いられる、初期ベクトルの算出方法を示した図。 一実施例における、暗号化されたコンテンツデータを分割する場合の例を示した図。 一実施例における、CICフィールドの構造例を示した図。
符号の説明
100:ネットワークインタフェース、 101:保護情報領域 102:記録モジュール 103:再生モジュール 105:ユーザインタフェースブリッジ 106,107:外部ストレージインタフェース 108:プロセッサ 110:ホストモジュール 111:ホストセキュリティマネージャ 112:記録再生装置 150:配信サーバ 125、126、240:磁気ディスク装置 221:ユーザパス転送モジュール 222:制限記憶制御部 223:制限記憶部 231:プロセッサ

Claims (8)

  1. コンテンツデータの復号化を管理するための制御情報を扱うコンテンツデータ管理システムにおいて、
    当該コンテンツデータを暗号化し、記憶装置へ出力し、当該記憶装置から出力された暗号化されたコンテンツデータを復号化する記録再生装置と、当該記録再生装置で暗号化されたコンテンツデータを記憶する前記記憶装置と、を有し、
    前記制御情報は、初期ベクトル生成鍵及びコンテンツ鍵を有し、
    前記コンテンツデータは、第1の単位のコンテンツデータを複数有し、
    前記記録再生装置は、
    前記第1の単位のコンテンツデータ毎に、当該第1のコンテンツデータを識別する識別番号及び前記初期ベクトル生成鍵に基づき、初期ベクトルを生成し、当該初期ベクトル及び前記コンテンツ鍵に基づき、当該第1の単位のコンテンツデータを暗号化し、当該暗号化された第1の単位のコンテンツデータを前記記憶装置へ出力し、
    前記記憶装置は、
    前記暗号化されたコンテンツデータを記憶した後、当該コンテンツデータが、所定の識別番号を割り当てられた第1の単位のコンテンツデータの途中で分割され、当該コンテンツデータの前半部分である第1の分割コンテンツデータ及び当該コンテンツデータの後半部分である第2の分割コンテンツデータに分割された場合、当該第2の分割コンテンツデータの制御情報として、前記所定の識別番号を記憶する
    ことを特徴とするコンテンツデータ管理システム。
  2. 請求項1に記載のコンテンツデータ管理システムにおいて、
    前記第1の単位のコンテンツデータは、第2の単位のコンテンツデータを複数有し、
    前記記憶装置は、
    前記分割が、前記第2の単位のコンテンツデータのm番目とn番目の間で分割された場合、前記第1の分割コンテンツデータの制御情報として、当該m番目の識別番号を記憶する
    ことを特徴とするコンテンツデータ管理システム。
  3. 請求項2に記載のコンテンツデータ管理システムにおいて、
    制御情報を記憶する論理的な領域が、複数に分割されており、当該分割された領域のそれぞれは、論理的に固定の開始位置及びリザーブ領域を有しており、
    前記記憶装置は、
    他の分割された領域よりも相対的にリザーブ領域が小さい分割された領域に、前記所定の識別番号を記憶する
    ことを特徴とするコンテンツデータ管理システム。
  4. 請求項3に記載のコンテンツデータ管理システムにおいて、
    前記記憶装置は、
    前記記録再生装置との間で相互認証を行った後、前記制御情報を前記記録再生装置へ出力する
    ことを特徴とするコンテンツデータ管理システム。
  5. コンテンツデータの複合化を管理するための制御情報を扱うコンテンツデータ管理システムに利用される記憶装置であって、
    記録再生装置から出力された暗号化されたコンテンツデータを記憶し、当該コンテンツデータを前記記録再生装置に出力するものであり、
    前記制御情報は、初期ベクトル生成鍵及びコンテンツ鍵を有し、
    前記コンテンツデータは、第1の単位のコンテンツデータを複数有し、
    前記記録再生装置は、
    前記第1の単位のコンテンツデータ毎に、当該第1のコンテンツデータを識別する識別番号及び前記初期ベクトル生成鍵に基づき、初期ベクトルを生成し、当該初期ベクトル及び前記コンテンツ鍵に基づき、当該第1の単位のコンテンツデータを暗号化し、当該暗号化された第1の単位のコンテンツデータを前記記憶装置へ出力し、
    前記記憶装置は、
    前記暗号化されたコンテンツデータを記憶した後、当該コンテンツデータが、所定の識別番号を割り当てられた第1の単位のコンテンツデータの途中で分割され、当該コンテンツデータの前半部分である第1の分割コンテンツデータ及び当該コンテンツデータの後半部分である第2の分割コンテンツデータに分割された場合、当該第2の分割コンテンツデータの制御情報として、前記所定の識別番号を記憶する
    ことを特徴とする記憶装置。
  6. 請求項5に記載の記憶装置において、
    前記第1の単位のコンテンツデータは、第2の単位のコンテンツデータを複数有し、
    前記記憶装置は、
    前記分割が、前記第2の単位のコンテンツデータのm番目とn番目の間で分割された場合、前記第1の分割コンテンツデータの制御情報として、当該m番目の識別番号を記憶する
    ことを特徴とする記憶装置。
  7. 請求項6に記載の記憶装置において、
    制御情報を記憶する論理的な領域が、複数に分割されており、当該分割された領域のそれぞれは、論理的に固定の開始位置及びリザーブ領域を有しており、
    前記記憶装置は、
    他の分割された領域よりも相対的にリザーブ領域が小さい分割された領域に、前記所定の識別番号を記憶する
    ことを特徴とする記憶装置。
  8. 請求項7に記載の記憶装置において、
    前記記憶装置は、
    前記記録再生装置との間で相互認証を行った後、前記制御情報を前記記録再生装置へ出力する
    ことを特徴とする記憶装置。
JP2007041676A 2007-02-22 2007-02-22 コンテンツデータ管理システム及び装置 Active JP5076546B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007041676A JP5076546B2 (ja) 2007-02-22 2007-02-22 コンテンツデータ管理システム及び装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007041676A JP5076546B2 (ja) 2007-02-22 2007-02-22 コンテンツデータ管理システム及び装置

Publications (2)

Publication Number Publication Date
JP2008205989A true JP2008205989A (ja) 2008-09-04
JP5076546B2 JP5076546B2 (ja) 2012-11-21

Family

ID=39782956

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007041676A Active JP5076546B2 (ja) 2007-02-22 2007-02-22 コンテンツデータ管理システム及び装置

Country Status (1)

Country Link
JP (1) JP5076546B2 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11195287A (ja) * 1997-12-27 1999-07-21 Sony Corp フアイル管理装置及びフアイル管理方法
JP2002042424A (ja) * 2000-07-18 2002-02-08 Toyo Commun Equip Co Ltd 情報をブロック暗号化して記録する方法およびこれをサポートする記録媒体
JP2003257157A (ja) * 2002-03-05 2003-09-12 Sanyo Electric Co Ltd 情報記録装置、情報再生装置、情報記録方法、情報再生方法、情報記録用プログラム及び情報再生用プログラム並びに情報記録媒体
JP2005140823A (ja) * 2003-11-04 2005-06-02 Sony Corp 情報処理装置、制御方法、プログラム、並びに記録媒体
JP2005175605A (ja) * 2003-12-08 2005-06-30 Sony Corp 情報処理装置、制御方法、プログラム、並びに記録媒体
JP2006345234A (ja) * 2005-06-09 2006-12-21 Sony Corp 暗号化装置および暗号化方法、復号装置および復号方法、並びにプログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11195287A (ja) * 1997-12-27 1999-07-21 Sony Corp フアイル管理装置及びフアイル管理方法
JP2002042424A (ja) * 2000-07-18 2002-02-08 Toyo Commun Equip Co Ltd 情報をブロック暗号化して記録する方法およびこれをサポートする記録媒体
JP2003257157A (ja) * 2002-03-05 2003-09-12 Sanyo Electric Co Ltd 情報記録装置、情報再生装置、情報記録方法、情報再生方法、情報記録用プログラム及び情報再生用プログラム並びに情報記録媒体
JP2005140823A (ja) * 2003-11-04 2005-06-02 Sony Corp 情報処理装置、制御方法、プログラム、並びに記録媒体
JP2005175605A (ja) * 2003-12-08 2005-06-30 Sony Corp 情報処理装置、制御方法、プログラム、並びに記録媒体
JP2006345234A (ja) * 2005-06-09 2006-12-21 Sony Corp 暗号化装置および暗号化方法、復号装置および復号方法、並びにプログラム

Also Published As

Publication number Publication date
JP5076546B2 (ja) 2012-11-21

Similar Documents

Publication Publication Date Title
JP4848163B2 (ja) コンテンツデータ管理システム及び装置
JP5036406B2 (ja) コンテンツデータ管理システム及び方法
JP4755472B2 (ja) データ転送方法及びシステム
US7958370B2 (en) System and device for managing control data
JP4555046B2 (ja) データ転送システム及びデータ転送方法
KR101331670B1 (ko) 디지털 저작권 이전 방법
JP5139028B2 (ja) コンテンツデータ管理システム及び方法
US7778417B2 (en) System and method for managing encrypted content using logical partitions
US20130007467A1 (en) Binding of cryptographic content using unique device characteristics with server heuristics
EP2466511B1 (en) Media storage structures for storing content and devices for using such structures
JPWO2004109972A1 (ja) ライセンス受信用ユーザ端末
KR20070109804A (ko) 디지털 컨텐츠 사용을 위한 권리객체 발급 방법 및 장치
US20060106721A1 (en) Method for retransmitting or restoring contents key for decrypting encrypted contents data
JP2010267240A (ja) 記録装置
CN101262332A (zh) 用于在移动装置和主机装置之间相互认证的方法和系统
US8156339B2 (en) Method for transmission/reception of contents usage right information in encrypted form, and device thereof
WO2023078055A1 (zh) 在第一区域和第二区域间数据安全共享的方法和系统
JP2003110544A (ja) 暗復号装置及び方法
JP5076546B2 (ja) コンテンツデータ管理システム及び装置
JP2004240959A (ja) コンテンツ再生装置、ライセンス発行サーバ及びコンテンツ再生システム
JP2010146635A (ja) コンテンツ記録再生装置並びにコンテンツの書き込み及び読み出し方法
US8345868B2 (en) Data transfer system, data transfer method, data transmission device and data receiving device

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100128

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120501

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120515

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120709

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120731

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120813

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150907

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 5076546

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150907

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250