JP5139028B2

JP5139028B2 - コンテンツデータ管理システム及び方法

Info

Publication number: JP5139028B2
Application number: JP2007276479A
Authority: JP
Inventors: 達哉平井; 幸秀稲垣
Original assignee: エイチジーエスティーネザーランドビーブイ
Priority date: 2007-10-24
Filing date: 2007-10-24
Publication date: 2013-02-06
Anticipated expiration: 2027-10-24
Also published as: US20090132820A1; US9400876B2; CN101420296B; JP2009105737A; CN101420296A

Description

本発明は、コンテンツデータ管理システム及び方法に係り、更に詳しく言えば、暗号化されたコンテンツデータ記録及び再生するシステム及び方法に関するものである。

音楽データや画像データ等のコンテンツデータに著作権が存在する場合、著作権保護のための適切な方策が取られていないと、著作者の権利が侵害される恐れがある。一方、著作権保護の目的を最優先し、コンテンツデータの流通を阻害してしまうと、著作物の複製に際して著作権料を徴収することが可能な著作権者にとっても、かえって不利益となる。

著作権保護の対象となるコンテンツデータの配信は、主にデジタル通信網や、放送波などを介して行なわれる。これらのデータを利用者が利用する際は、一度何らかの記憶媒体に記録した後、再生装置で再生する場合が多い。現状、容量が大きくアクセス性能が高い制御機能付きの記憶装置として磁気ディスク装置が知られている。

磁気ディスク装置は、記録再生装置に固定的に内蔵されているものが主であるが、著作権保護機能を伴った可搬型のものも存在するようになってきた。

データを再生する装置としては、このようなデータの配信を受ける時に用いた記録再生装置や、可搬型の専用の再生装置が使用される。可搬型の記憶装置を接続できる記録再生装置において、記憶装置に記録されたデータの著作権を保護するためには、記憶装置に記録されたデータを、著作権者が主張する条件の範囲を超えて再生できないように、記録再生装置及び記憶装置にセキュリティ対策を施すことが重要である。セキュリティ対策を機器に施す際には、その装置の内部及び外部から自由にアクセス可能な領域で行なわれるデータの授受に関しては、データの授受が行われる装置の間で認証処理を行ったり、データ自体に暗号化処理等を施したりして、平文で自由にデータへのアクセスが行われることがないようにする必要がある。一方で、このような認証処理や暗号化処理が厳重になるほど、利用者がデータ利用要求を発してから、実際に利用が出来るようになるまでに多くの処理が必要となり、結果としてデータの再生を円滑に行うことができない事態が生じる可能性がある。

このような問題に対して、特許文献1及び特許文献2は、一つの解決法を提示している。

これらは、(1)利用目的のデジタルデータを暗号化し、記憶装置内で通常にアクセスできる領域に記録する、(2)記憶装置内には、前記デジタルデータを復号するための鍵データや、鍵データの記憶装置からの出力条件や復号されたコンテンツの再生及び描画条件（これらをまとめて利用条件データと呼ぶ）を不正に取得したり、改竄したりすることができないような特殊アクセス領域を設け、当該鍵データや利用条件はそこに記録する、(3)当該鍵データや利用条件データを記録再生装置と記憶装置間で転送したり、記憶装置に記録された当該鍵データや利用条件データにアクセスしたりするために、特殊な処理手続き（プロトコル）を用いる、といった特徴を記述した文献である。尚、特殊な処理手続きについては、2種類の方法が記述されている。

また、特許文献3及び4にも、利用目的のデジタルデータを暗号化し、その復号を実行するための鍵及び復号されたデジタルデータの利用条件情報を不正改竄したりすることができないようにすることで、著作権を保護する手段が提案されている。

特許文献5には、記憶装置とホスト装置との間で秘匿すべきデータを暗号化して入出力するときの耐タンパ性を向上させるために、ホスト装置から送られる複数の暗号入出力処理を複数の手順に分割して、並行して処理する記憶装置に関する技術が開示されている。

また、暗号化されたコンテンツデータへアクセスする際の負荷を軽減するための技術が、特許文献6に開示されている。

特開2007-96783 特開2007-96817 ＷＯ01/013358公報ＷＯ01/043339公報特開2004−302701公報特開2004-7533公報

特許文献1及び2に記述された、2種類の鍵データ及び利用条件データの管理及び機器間転送方法は、遠隔地にあるサーバ装置や動画像録画再生装置と、磁気ディスク装置のような内部に制御部をもつ記憶装置とを接続し、保護が必要なデジタルコンテンツデータを転送するような場合に効果的である。特に、デジタルテレビコンテンツを記録及び再生するようなサービスの提供を主目的とした場合、ホスト装置と記憶装置をBTモード（Bidirectional Transfer mode）で接続し、当該機器間で鍵データや利用条件データの転送を行うと、それらに関して記憶装置で実行が必要な処理負荷を低く抑えることができ、極めて有効である。その特徴を具体的に述べると、次のような3点が挙げられる。

（1）初めて接続し合うホスト装置と記憶装置の間で認証処理（Connection Stage）を実行する際に認証ログ（Connection Log）を記録し、次回以降の認証処理は、該ログに記録されている情報を用いた簡略化された処理で認証（Reconnection Stage）を終えることができるようにする。

（2）鍵データ及び利用条件データの転送処理の過程において、これらのデータが消失してしまった場合に復旧できるようにするための処理経過ログ（Transaction Log）の記録を、記憶装置では行わない。

（3）鍵データ及び利用条件データの不正な複製や復旧を防止するために、記憶装置にはConnection Logを記録できるエントリを1つしか設けてはいけない。

上記中の(3)の帰結として、ある記憶装置を、過去に接続したことがあるホスト装置に対して再度接続する場合でも、一度別のホスト装置に接続した後に再び接続する場合には、Reconnection Stageで認証を終えることができなくなってしまうという課題がある。本発明は、このような課題を解決するものである。

本発明のコンテンツデータ管理システム及びその方法は、第１の接続先装置（ストレージ装置）との間で互いを認証するために用いた認証用鍵データを含む情報を格納する第１の認証ログ（Connection Log）、この第１の認証ログの1つのエントリに関連付けられて、暗号化されたコンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む所定の情報の第１の接続先装置への転送に先立ち、前記転送処理の過程で前記所定の情報が消失してしまった場合に前記所定の情報を復旧するために、所定の情報を格納する転送ログ（Transaction Log）を有し、所定の認証処理及び所定の情報の転送処理を実行後、第１の接続先装置との間で再度互いに認証するために、第１の接続先装置に格納されている、第１の認証ログの1つのエントリに格納されている内容に対応する認証ログの1つのエントリの格納場所を特定する情報を、第１の接続先装置に送信し、続いて第１の接続先装置からの許可（Recovery Permission Indicator）に応答して、再認証処理の実行に際して利用した認証ログの1つのエントリに格納されている内容に関連付けられた転送ログに格納した所定の情報を転送するホスト装置（記録再生装置）と、暗号化されたコンテンツデータを格納する記憶媒体と、ホスト装置を含む複数の接続先装置の各々との間で互いを認証するための認証用鍵データを含む情報を、複数の接続先の装置に対応して格納する第２の認証ログとを有し、ホスト装置からの第１の認証ログの1つのエントリに格納されている内容に対応する認証ログの1つのエントリの格納場所を特定する情報が、複数の接続先装置の中で最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つに対応する第２の認証ログの1つのエントリの格納場所を指示（Recovery Allowed Primal Device Indicator）するときに、転送処理の過程で所定の情報が消失してしまった場合に当該所定の情報を復旧する許可をホスト装置に応答する、第１の接続先装置としてのストレージ装置とにより構成される。

本発明の他の態様では、ストレージ装置は、複数の接続先装置の中で、最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する第２の認証ログの1つのエントリの格納場所を指示する情報を格納する領域を設ける。

本発明のさらに他の態様では、ストレージ装置は、複数の接続先装置の中で最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する第２の認証ログの各エントリに、最新の前記転送処理を実行した一つであることを示す情報を格納する。

本発明によれば、ある記憶装置を、過去に認証を完了したことがあるホスト装置に対して再度接続する場合には、簡略化された認証処理（Reconnection Stage）によって認証を終えることができるようになり、利用者にとっての利便性を向上できる。

以下、本発明の実施の形態を、図面を用いて説明する。

本実施例は、以下に記すような特徴を有する。すなわち、
（1）保護が必要なデジタルデータは暗号化されること、
（2）当該デジタルデータの利用は、当該暗号化されたデジタルデータを復号するための鍵データと、当該デジタルデータの利用条件が記述された利用条件データとによって制御されること、
（3）（2）に記載の鍵データと利用条件データが媒体に記録される場合、その媒体は利用者が自由にアクセスすることができない領域であること、
（4）ホスト装置や遠隔地のサーバ内にあり、（2）に記載の鍵データと利用条件データを生成し記憶装置へ送信する機能を有する機能単位と、記憶装置内にあり、受信した当該鍵データと利用条件データを実際に媒体上に記録する機能を有する機能単位の間や、当該記憶装置内の機能単位と、記録された当該鍵データや利用条件データを読み出し、暗号化デジタルデータの再生を制御する機能単位の間では、相互に正当性を検証するための認証処理が行われ、その結果暗号通信路が確立されること、
（5）生成あるいは記録された（2）に記載の鍵データと利用条件データを、（4）に記したような2つの機能単位間で転送する場合は、（4）に記したような暗号通信路内を通ること
である。

初めに、システム装置全体及び記憶装置の一例として磁気ディスク装置について述べ、その後に鍵データと利用条件データを転送する方法について説明する。

[システム装置構成]
図1及び図2を用いて、本実施例におけるデータ記録再生装置（Content Recordr/Player）112及びそれに接続可能な記憶装置を含むシステムの全体構成について説明する。この実施例は、放送されたデジタル映像データや、配信サーバ（Distribution Server）150から配信されたデジタルデータ、また他の機器と接続したデジタル信号線(Digital signal)132を介して送信されたデジタルデータを脱着可能な記憶装置(Detachable Storage Device又はStorage Device)125、126に記録し、また記憶装置125、126に記憶されたデジタルデータを、記録再生装置112のディスプレイ装置134やスピーカー135などで再生する記録再生システムに適用した例について説明する。

以下では、デジタルデータ記録再生装置112を単に記録再生装置といい、記録再生装置112が受信する映像や音楽、テキストなどのデジタルデータを、コンテンツデータという。ここで、コンテンツデータを記録する脱着可能な記憶装置125、126は、例えば、磁気ディスク装置や半導体メモリデバイスなどであり、何れも本実施例に特徴的な制御機能を有する。以下では、記憶装置125、126として磁気ディスク装置を例に説明するが、これに限るものではなく、以下に説明するような本実施例に特徴的な機能を有するものであれば、磁気ディスク装置以外の他の周知な記憶装置であれば、何れにも適用できる。

著作権の保護が求められるコンテンツデータは、放送波を介してアンテナ131で受信したり、配信サーバ150から配信されたものをネットワークインタフェース（Network Interface）100を介して受信したりすることによって、記録再生装置112に取り込まれる。配信されるコンテンツデータは、放送波発信元(broadcast)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であり、磁気ディスク装置(図2)240においては、ストレージセキュリティマネージャ（Storage Security Manager）225である。尚、ホストセキュリティマネージャ 111内の保護情報領域（Protected Information Storage）101の役割や、ストレージセキュリティマネージャ 225内のユーセジパス（Usage Pass）転送モジュール（Usage Pass Transfer Module）221、制限記憶コントローラ（Qualified Storage Controller）222、制限記憶部（Qualified Storage）223の具体的な役割については、後に説明する。

本実施例は、ホストセキュリティマネージャ（Host Security Manger）111及びストレージセキュリティマネージャ225内にあるモジュール間で、利用制御情報を送受信し合うための転送プロトコルに関するものである。尚、ここで、記録再生装置112及び磁気ディスク装置125、126における各モジュール及びセキュリティマネージャ等の機能の実現手段としてはハードウェア又はソフトウェア（プログラム）の何れによって構成されてもよい。

一方で、記録再生装置112の中で、ネットワークとの間のネットワークインタフェース100や、入力デバイス(Input device)120との間のインタフェースブリッジ部(User Interface Bridge)105、磁気ディスク装置との間のインタフェース(Host Interface Unit 1,2)106及び107、及びこれらを制御するプロセッサ（PU）108などは、全体として、システム内部を流れるデータの処理や受け渡しを制御する機能を有する。その意味で、以下ではこれらをまとめてホストモジュール（Host Modules）110と呼ぶ。

[磁気ディスク装置構成]
図2を用いて、磁気ディスク装置の構成の概要について説明する。磁気ディスク装置240には、インタフェース部(Storage Interface Unit)220を介してデータが入出力される利用制御情報以外の、特に保護を必要としないデータが外部から入力される場合、コントローラ230を介して、ヘッド部202から磁気ディスク円盤200上に記録される。暗号化されたコンテンツデータも、この流れに従って、磁気ディスク円盤200上に記録される。読み出す場合は、前述を逆にデータが流れる。コントローラ(Storage Controller)200は、プロセッサ（PU）235からも制御される。Usage Pass転送モジュール221や制限記憶コントローラ222なども、プロセッサ235によって制御される。尚、Usage Pass転送モジュール221や制限記憶コントローラ222の詳細な挙動については、後で説明する。

一方、利用制御情報のような保護が必要なデータの記録や転送を制御するモジュール群全体であるストレージセキュリティマネージャ（Storage Security Manager）225は、高い対タンパ性を有するように実装する必要がある。但し、図2では、制限記憶部223は磁気ディスク円盤200とは別に設けられているが、暗号化されたコンテンツデータの読み出しと書き込みとは異なる特殊なアクセス方法でのみアクセスが許容されていて、また本装置を分解等し内部のデータを直接読み出す等を行うことが不可能な構成になっていれば、制限記憶部は磁気ディスク円盤200上に設けても良い。このような実装を行う場合は、Storage Controller230の挙動を外部から変えられないように、対タンパ性を有する特殊な実装をする必要がある。

［基礎前提事項］
放送波に乗せられて送信されるコンテンツデータや配信されるデータ、あるいは他の媒体に記録されているコンテンツデータは、一般的には独自に規定された方式で暗号化されている。また、それらのデータには、その利用を制御するための情報も含まれていることが多い。これらのデータを、アンテナ131やデジタル信号線132を介して記録再生装置112が取り込む場合、記録モジュール102は、規定された方式に従ってコンテンツデータを復号し、また復号制御情報を取り出す。一方、復号されたコンテンツデータは、記憶装置に送信したり、媒体に書き込んだりするための個別の方法で暗号化されることが多い。ここで、取り出された当該利用制御情報は、コンテンツデータを復号するための鍵データと共に、特定の形式を持った1つのデータにまとめておくと、その管理が簡潔になるという利点がある。以下ではこれを、ユーセジパス（Usage Pass）と呼ぶ。但し、利用制御情報は、必ずしも一つにまとめられる必要はない。図4には、Usage Passの構造の例を示す。

記録モジュール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に記述されたBidirectional Transfer mode（略してBTモード）に基づいて説明する。但し、この方法に限るものではない。課題に挙げた(1)から(3)の特徴を有するような認証処理，経過ログ記録，利用条件情報転送処理に対しては、本発明の適用が可能である。

尚、上記BTモードのような利用制御情報を総称して、以下では制限アクセス（Qualified Access）モードと呼ぶ。モジュール間でUsage Passを転送する際、いずれの制限アクセスモードで相互認証及びUsage Pass等の利用制御情報の転送を行うかは、記録再生装置を起動する際、ホストモジュール（Host Module）110が決定する。該相互認証処理には、公開鍵暗号基盤上で生成された電子署名を利用する。また、Usage Passや途中で生成される一時鍵の暗号化は、共通鍵暗号方式を用いて、CBC（Cipher Block Chaining）モードで行うのが、暗号論上も適切である。CBCモードによる暗号化処理方法ついては、例えば、「ネットワークセキュリティ（ピアソン・エデュケーション刊）」に説明がある。

磁気ディスク装置では、Usage Pass転送モジュール 221がUsage Passを受信すると、それを制限記憶コントローラ222へ送信する。制限記憶コントローラ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 Manager111を全体として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の場合のSession鍵を、0次のSession鍵と呼ぶ。

各鍵に対しては、K_s[P]nのような形で、[P]，[I]、もしくは[S]，[D]の何れかの添え字が与えられる。これは、当該鍵データがPrimal DeviceあるいはInceptive Deviceの何れで生成された（あるいは埋め込まれた）か、もしくはUsage Passの転送元（Source）あるいは転送先（Destination）の何れで生成されたか、を示すものである。ここで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を連結することを表す。

[公開鍵暗号化による共有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において目的のフィールドを検索する際の処理負荷を軽減できるという利点がある。

また、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転送モジュール(図2の221)の構成について説明する。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は、必要に応じて、記憶領域へアクセスする。

磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、インタフェース(Storage Interface Unit)620及びバス640を介して行なわれる。PU 621は、図2における235と同じものである。

[BTモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成]
図7を用いて、BTモードでのUsage Pass送信が実行可能な記録モジュール(図1の102)の構成について説明する。BTモードでは、Host Security Manager111全体が常にPrimal Deviceとして動作し、Usage Passは、Host Security Manager111に対して双方向に流れる。そこで、記録モジュール(Recording Module)725は、Usage Passを出力するために必要な機能のみ包含し、Inceptive Deviceとの間で相互認証を行うための機能などは、保護情報転送モジュール104が含む構成とした方が適切である。そこで記録モジュール725には、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール701、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール705、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール706が設けられている。暗号化されたコンテンツデータは、モジュール706からデータバス740へ、ホストモジュール(Host Module) 720を介して、磁気ディスク装置へ記録される。

記録モジュール725を含むHost Security Manager 730には、利用者の意思だけに基づいた書き換えは行えないような静的な記憶領域(Protected Information Storage)704が設けられている。Host Security Manager 111から送信されたUsage Passの読み出しや書き込み要求を受信すると、認証用モジュール(Protected Information Transmit Module)700やUsage Pass暗号化及び送信用モジュール701、Usage Pass復旧用モジュール705などは、規定された処理を実行する過程で、この記憶領域へアクセスする。以降では、記憶領域704を保護情報領域と呼ぶ。

保護情報領域 704に記録されるデータの種類等については、後に図10を用いて説明する。

[BTモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成]
図8を用いて、BTモードでのUsage Pass受信が実行可能な再生モジュール(図1の103)の構成について説明する。BTモードでは、再生モジュールは、記録モジュールと同様に、常にPrimal Deviceとなる。記録モジュールについて説明した際にも述べたように、Host Security ManagerがPrimal DeviceとなってInceptive Deviceと相互認証を行うための機能は、保護情報転送モジュール104が担う。そこで、再生モジュール(Playback Module)825には、自身がPrimal DeviceとなってUsage Passの受信を行うための機能を持ったモジュール803、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール805及び801、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール806が設けられている。この時、暗号化されたコンテンツデータは、ホストモジュール(Host Module) 820及びデータバス840を介して、モジュール806に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール806から直接再生モジュール外へ出力される。

再生モジュール825を含むHost Security Manager 830には、保護情報領域704と同様の性質を持つ静的な記憶領域(Protected Information Storage)804が設けられている。利用者から発せられたUsage Passの読み出しや書き込み要求を検出すると、認証用モジュール(Protected Information Transmit Module) 800や、Usage Pass受信及び復号化用モジュール803、Usage Pass復旧用モジュール805及び801は、規定された処理を実行する過程で、記憶領域へアクセスする。保護情報領域704と同様に、記憶領域804も保護情報領域と呼ぶ。保護情報領域804に記録されるデータの種類等については、後に図10を用いて説明する。

[BTモード用保護情報転送モジュールの構成]
図9を用いて、BTモード用の保護情報転送モジュール(Protected Information Transmit Module) 910（図7では700，図8では800に相当する）の構成について説明する。記録モジュールや再生モジュールに関する説明においても述べたように、BTモードでは、保護情報転送モジュール910がInceptive Deviceとの間の相互認証を実行する構成の方が適切である。そこで、保護情報転送モジュール910には、自身がPrimal DeviceとなってInceptive Deviceとの間で相互認証処理を実行するためのモジュール900、再生モジュール(Playback Module)916の中のUsage Pass受信用モジュール903が生成した最新のSession鍵を一時的に保持し、必要に応じて記録モジュール内のUsage Pass送信用モジュールへ送信するモジュール905が含まれる。

[記録再生装置内BTモード用保護情報領域の構成]
先ず、記録再生装置におけるBTモード用の保護情報領域の構成を、図10を用いて説明する。BTモードは、Usage Passを転送する向きに拠らず、Host Security Manager 111が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるような方式である。それ故、通常記録モジュール102と再生モジュール103は、1つの保護情報領域を共有する形で実装した方が、記録再生装置に設ける静的記憶領域を小さくすることができる。

図10は、このような特徴を持つように保護情報領域を実装した場合の内部構成を示している。尚、記録モジュール102用と再生モジュール103用の別の記憶領域を用意し、それぞれにDevice Class証明書や、相互認証に必要な鍵を記憶させておいても良い。この場合、記録モジュールと再生モジュールはそれぞれが相互認証実行用モジュールを含まなければならなくなる。そのような場合は、本実施例では説明しない。

1001は、Device Class証明書(DCC)である。Device Class証明書1001には、Device Class公開鍵KP_dc 1000が含まれる。Device Class証明書1001は、含まれるDevice Class公開鍵1000の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。1003は認証局公開鍵KP_CA、1004はDevice Class秘密鍵K_dc、1005はDevice公開鍵KP_d、1006はDevice秘密鍵K_dである。以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、セキュリティシステムが破られない限り、通常後で更新はされない。

これに対し、領域1002，1010，1011に記録される情報は、それぞれDevice Class証明書失効リスト)RDCＬ，コネクションログ（Connection Log），トランザクションログ（Transaction Log）である。これらの領域に記録される情報は、必要に応じて更新される情報である。

RDCLは、失効したDevice Classのリストである。あるDevice Class公開鍵KP_dcの安全性が失われると、当該KP_dcを含む証明書の固有番号を、このリストに登録する。他のデバイスから送られたDevice Class証明書の検証を行う際には、電子署名部を用いて証明書に改竄が行われていないことを確認すると共に、証明書の固有番号が、リストに登録されていないかどうかについても確認する。固有番号としては、それぞれのDevice Class証明書に割り当てられたシリアル番号などが用いられる。

Connection Log 1010は、BTモードに固有のログ情報である。Connection Logの1つのエントリは、初期相互認証処理であるConnection Stage完了時に作成され、再認証処理（簡略相互認証処理）であるReconnection Stage完了時に、その一部が更新される。Connection StageとReconnection Stageの処理の詳細については、図17及び図19を用いて後で説明する。

図12に、Connection Logの1つのエントリに含まれるフィールドを示す。即ち、Host Security Manager及びStorage Security Manager双方で記録されるのは、認証相手となるデバイスのDevice公開鍵（Device Public Key）1200，認証処理実行中に相手及び自身によって生成される0次Session鍵(0th order Session Key)1201及び1202，受信可能なUsage Pass Formatの種類を示すAcceptable Usage Pass Type Map 1203，互いの世代を特定する情報を記録するPartner Device Generation Number 1204である。

0次Session鍵フィールドに記録されるデータは、Reconnection Stageが実行されると、必ず更新される。

Acceptable Usage Pass Type Map1203には、Device Class証明書に含まれているAcceptable Usage Pass Type Mapがそのまま記録される。Acceptable Usage Pass Type Map1203は、「受信可能なUsage Pass Formatの種類」を示すものである。接続相手デバイスは、自身がUsage Pass転送元であった場合に、どういった種類のUsage Passであれば相手のデバイスが受信可能であるかを、Acceptable Usage Pass Type Map1203によって判断する。例えば、あるUsage PassのUsage Pass Formatが「Type 0」を示していた場合に、接続相手デバイスから送信されたDevice Class証明書中のAcceptable Usage Pass Type Map1203が「Type 0受信不可」となっていた場合、Usage Passの転送元デバイスは、Usage Passの転送処理を行わない。

Partner Device Generation Numberフィールド1204には、Host Security ManagerとStorage Security Managerの間でConnection Stageにおいて交換される、互いの世代を特定する情報が記録される。例えば、本実施例に記載した機能を有するHost Security Manager及びStorage Security Managerの世代値を1とし、本機能を有しない前記二つのManagerの世代値を0とすると、Partner Device Generation Numberフィールド1204には、接続された相手デバイスの世代に応じて、0もしくは1のいずれかの値が記録される。

以上5つが、Host Security Manager及びStorage Security Managerの双方でConnection Logとして記録される情報であるが、これらに加えて、Storage Security ManagerのConnection Logには、Host Security Manager Specifier 1205フィールドも設けられる。当該フィールド1205には、認証相手であるHost Security Managerを特定する情報が記録される。その適切な例としては、当該Managerから送信されたDevice Class証明書のシリアル番号が挙げられる。

本情報の記録は、セキュリティの観点からは必須というわけではない。一方で、本情報をConnection Logの1つのフィールドとして記録しておくことにより、Host Security ManagerとStorage Security Managerの間でReconnection Stageを実行する場合に、必要なConnection Logのエントリの選定のための試行錯誤を行わずに済ませることが可能になり、処理時間を短縮することができる。

図10に戻り、次にTransaction Log 1011について説明する。Transaction Logは、Usage Pass転送処理において記録及び更新される情報である。但し、Usage Pass転送は、あるHost Security ManagerとStorage Security Managerの間で認証処理（Connection StageもしくはReconnection Stage）を完了して初めて実行できるものであるので、Transaction Logは、Usage Pass転送処理を実行したStorage Moduleを特定するためのConnection Logに関連づけられて、Host Security Manager内の保護情報領域に記録される必要がある。例えば、Connection LogのエントリCL Entry #1 1021に対しては、Transaction LogのエントリTL Entry #1.1 1023，TL Entry #1.2 1024等が関連付けられている。同様に、CL Entry #2 1031に対しては、Transaction LogのエントリTL Entry #2.1 1033，TL Entry #2.2 1034等が関連付けられている。このように、Transaction Logは保護情報領域904内に記録されているConnection Logのいずれか一つのエントリに関連つけられているので、当該エントリが無効になると、それに関連づけられたTransaction Logも同時に無効になる。

図10に示したように、Connection Logの1つのエントリと、それと関連付けられたTransaction Logの複数のエントリのまとまりを、以下ではグループ(Group)と呼ぶ。図10では、CL Entry #1 1021とTL Entry #1.1 1023，TL Entry #1.2 1024等のまとまりをGroup 1 1020，CL Entry #2 1031とTL Entry #2.1 1023，TL Entry #2.2 1034等のまとまりをGroup 2 1030とする。

図13に、Transaction Logの1つのエントリに含まれるフィールドを示す。Transaction Logとして記録されるのは、転送対象Usage PassのUPID(Usage Pass Identifier) 1300，転送の種類(Transfer Type)（自身がUsage Passの転送元であるか転送先であるか）1301，転送を実行する前のUR_s(Original Usage Rule enforced in Storage Module)（ただし、Primal DeviceがUsage Passの転送先であった場合のみ）1302，転送を実行する前のUsage Pass(Original Usage Pass)（但しPrimal DeviceがUsage Passの転送元であった場合のみ）1303，Usage Passが記録されているアドレス(Usage Pass Location)（但し、Primal Deviceが転送元であった場合のみ）あるいは記録先のアドレス（但しPrimal DeviceがUsage Passの転送先であった場合のみ）1304が、Usage Pass転送が実行される際に記録される。これらのデータをUsage Pass転送を行う際に記録しておくことで、不慮の事故等により、転送元及び転送先いずれからもUsage Passが失われてしまった場合にも、復旧することができるようになる。

[記憶装置内BTモード用保護情報領域の構成]
図11を用いて、磁気ディスク装置におけるBTモード用の保護情報領域の構成を説明する。BTモードは、Usage Passを転送する向きとは無関係に、Host Security Manager 111が全体として常にPrimal Deviceとなり、記憶装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるような方式である。図示の通り、Usage Pass転送モジュール内に設けられる保護情報領域に記録されるデータは、Device Class公開鍵KP_dc1100を含むDevice Class証明書（DCC）1101，認証局公開鍵KP_CA1103，Device Class秘密鍵K_dc1104，Device公開鍵KP_d1105，Device秘密鍵K_d1106，Recovery Allowed Primal Device Indicator 1120，Connection Log 1110である。Connection Log1110は、複数のエントリ1111，1112，1113，1115を含むことができる。それぞれのエントリは、異なるHost Security ManagerとのConnection StageあるいはReconnection Stageを実行した際に、生成あるいは更新されたものである。

ここで、Recovery Allowed Primal Device Indicator 1120の役割について説明する。あるHost Security Managerとの間でUsage Pass転送処理が実行されると、それに先立ち当該Host Security Managerとの間で実行されたConnection（もしくはReconnection）Stageにおいて、生成もしくは更新されたConnection Log1110のエントリを指し示す情報が、当該Indicatorとして記録される。当該エントリに割り当てられたエントリ番号は、その好例である。エントリ番号を用いる場合、Connection LogのエントリCL Entry #3 1113を用いてあるHost Security Managerとの間でReconnection Stageが実行された後、当該Host Security Managerとの間でUsage Pass転送処理が実行されると、Recovery Allowed Primal Device Indicator 1120には3が記録される。言い換えると、Connection StageもしくはReconnection Stageを完了した時点では、当該Indicatorは更新されない。Usage Pass転送処理が実行されて、初めて更新されるものである。当該Host Security Managerとの間で2度目以降のUsage Pass転送処理を実行した場合には、当該Indicatorは更新してもしなくても良い。仮に更新した場合には、同一の値で上書きされるだけである。尚、本図では、Recovery Allowed Primal Device IndicatorはConnection Logの各エントリと独立した形で置かれているが、必ずしもこのような形態を取らなくてもよい。例えば、Connection Logの各エントリに同様の名前のフィールドを設け、Usage Pass転送処理をHost Security ManagerとStorage Security Managerの間で実行した場合、最新の転送処理が実行されたHost Device用のエントリのフィールドには1を、他のものについては0を設定するといったような形態はその一例である。このようにRecovery Allowed Primal Device Indicatorを設けた場合であっても、上記以外の特徴については、全て本実施例の他の部位において説明する内容と同じである。例えば、Recovery Allowed Primal Device Indicatorが1に設定されているConnection Logのエントリが、今まで接続したことがないHost Security ManagerとのConnection Stageを実行することによって新しい情報で上書きされた場合、当該Host Security Managerとの間でUsage Pass転送処理が実行されなければ、当該エントリのRecovery Allowed Primal Device Indicatorは0に設定される。この時、他のエントリで、Recovery Allowed Primal Device Indicatorが1となっているようなものは存在しない。

また、図示されている通り、制限記憶部223内の保護情報領域には、Transaction Logの記録領域が設けられていない。これは、Usage Pass転送実行時には、記憶装置はTransaction Logの記録を行わないことを意味する。ログの記録処理がない分、BTモードでのUsage Pass転送時の記憶装置の処理負荷を、比較的軽く抑えておくことができるという特徴がある。上記の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない点、及びConnection LogはUsage Passを実行しようとするデバイス間で行われる相互認証処理において更新される点も、Host Security Manager内の保護情報領域101と同じである。

本図に示すように、制限記憶部223内の保護情報領域へConnection Logを記録する場合、複数エントリの記録が可能である。個々のエントリに記録される情報は、図12を用いて説明した通りである。こちらはStorage Security Manager内に記録される情報であるので、Host Security Manager Specifier 1205も記録される。

[制限記憶部223の構成]
図14を用いて、制限記憶部223の構成について説明する。制限記憶部223は、磁気ディスク装置の中にあって、記録モジュールや他の磁気ディスク装置から送られてきたUsage Passを記録し、保持する部分である。Usage Passの記録は、制限記憶コントローラ222によって制御される。制限記憶部223は、Usage Pass本体が記録される領域1400，1410，1420等と、Usage Passの有効性を示すフラグを記録する領域1401，1411，1421等から成る。以降、フラグを有効性指示フラグと呼ぶ。1401に書き込まれた有効性指示フラグは領域1400に書き込まれたUsage Passの有効性を、1411に書き込まれた有効性指示フラグは領域1410に書き込まれたUsage Passの有効性を、1421に書き込まれた有効性指示フラグは領域1420に書き込まれたUsage Passの有効性を示すものである。Usage Pass及び有効性指示フラグを記録する領域は、前記のようにペアを構成し、前記と同様に制限記憶部223内に多数設けられる。各々の有効性指示フラグ領域には、フラグとペアとなっている領域に有効なUsage Passが書き込まれると、制限記憶コントローラ 222によって、「有効」を示す値が記録される。一方、一度書き込まれたUsage Passを再生モジュールや他の磁気ディスク装置へ出力して後は、領域には「無効」を示す値が記録される。また、完全な初期状態においては、「未記録」を示す値が記録される。尚、制限記憶部に記録されているUsage Passの読み出しは、制限記憶コントローラ 222によって行われる。

[Usage Pass転送処理: 初期化処理]
以下では、本実施例によるUsage Pass転送に際して、記録再生装置及び記憶装置で実行される処理について図１５を用いて説明する。

記録再生装置と記憶装置の間でUsage Pass転送を行なうに当たり、初めに、記憶装置に実装されている機能を記録再生装置が把握する必要がある。まず、記録再生装置が記憶装置に対して問い合わせ要求（15000）を送信すると、記憶装置は自身に搭載されている機能を記録再生装置へ通知（15001）する。通知する情報としては、自身に割り当てられている記憶装置の識別子情報，自身に実装されているUsage Pass転送モード，記録可能なConnection Logのエントリ数，記録されているConnection Logがどの記録再生装置との間で生成されたものなのかを示す情報などである。1つ目の情報については、Device Class証明書のシリアル番号であっても良いが、より単純に、各記憶装置に割り当てられている製造用シリアル番号等でも良い。3つ目の情報については、Connection Logの各エントリに記録されているHost Security Manager Specifierを用いると良い。当該情報を受信すると、Host Security Managerは、記憶装置に記録されているどのConnection Logのエントリを用いてReconnection Stageを実行するかを内部で決定しておくと共に、いずれのモードでUsage Pass転送を実行するかを選択し、記憶装置におけるUsage Pass送信あるいは受信処理用モジュールに、選択したモードを通知する（15010）。

[Usage Pass転送処理: BTモード Connection Stage]
BTモードでは、Usage Passを転送する方向が固定されておらず、Primal DeviceとInceptive Deviceの双方から、Usage Passを送信できるという特徴がある。以前に説明した通り、BTモードの下で、記録再生装置にあって相互認証処理やUsage Passの送受信処理を制御及び実行するモジュール（Host Security Manager 111）はPrimal Device、記憶装置にあって相互認証処理やUsage Passの転送処理を実行するモジュール（Storage Security Manager225）はInceptive Deviceである。そこで以下では、Primal Deviceに埋め込まれたDevice Class証明書をPrimal Device Class証明書、Device Class公開鍵をPrimal Device Class公開鍵と呼ぶ。Inceptive Deviceについても同様である。また以下では、認証処理やUsage Pass転送処理を実行するより具体的な機能単位であるHost Security ManagerやStorage Security Managerを用いず、これらを含む上位の機器の意味でのPrimal Device及びInceptive Deviceを用いて説明する。勿論、詳細な意味では、当該2つのManagerが当該認証処理やUsage Pass転送処理を管理及び実行していることを、ここで付け加えておく。

以下、図16及び図17を用いて、BTモードでのConnection Stageについて説明する。Connection Stageとは、Primal DeviceとInceptive Deviceが相互認証を行い、RDCLの更新や所定の秘密鍵を共有する処理のことである。

Initialization Process （16000）においてPrimal Device及びInceptive DeviceにBTモードが設定される（15010）と、Host Modulesは、接続されているInceptive Deviceが過去に接続されたものかどうかをPrimal Deviceが判断できるように、15001で得たStorage Device Identifierを、Primal Deviceへ送信する（16001）。

Inceptive Device内のConnection用モジュール602は、自身に埋め込まれているDevice Class証明書DCC_[I]を、Primal Deviceへ送信（16010）する。

Primal Deviceでは、受信したDevice Class証明書DCC_[I]の正当性を検証し、検証の結果、受信した証明書の正当性が確認されると、一時的な共通鍵暗号化のための鍵であるPrimal Challenge鍵K_ch[P]（PD.C.Key）を生成する。続いて、受信したDevice Class公開鍵KP_dc[I]を用いてPrimal Challenge鍵K_ch[P]を暗号化し、生成された暗号化データにPrimal Device Class公開鍵KP_dc[P]を含むPrimal Device Class証明書DCC_[P]を連結し、Inceptive Deviceに送信する（16020）。以上の処理が、16011である。

Inceptive Deviceでは、受信したデータ16020を、自身のDevice Class秘密鍵K_dc[I]を用いて復号し、Primal Challenge鍵K_ch[P]を取得する。続いてInceptive Deviceは、一時的な共通鍵暗号化のための鍵である0次Inceptive Challenge鍵K_ch[I]（ID.C.Key）を生成する。この鍵の生成を終えると、自身に埋め込まれているInceptive Device公開鍵及び自身の世代情報GN_[I]と連結し、受信したPrimal Device Class鍵KP_dc[P]で暗号化する。更に、得られたデータ（即ち、Primal Device Class鍵で暗号化されたデータ）に対し、自身に記録されている失効Device ClassリストRDCL_[I]（Inceptive RDCL）及びChecksumを連結し、受信したPrimal Challenge鍵K_ch[P]で暗号化する。該暗号化処理を終了すると、得られたデータをPrimal Deviceへ送信する（16030）。以上の処理が、16021である。

Primal Deviceは、受信したデータ16030をPrimal Challenge鍵で復号し、データの完全性をChecksumで検証後、その結果からInceptive RDCL RDCL_[I]を取り出す。RDCLには、データの発行日情報が含まれているので、Inceptive RDCL RDCL_[I]の発行日情報と、自身に記録されているRDCL RDCL_[P]（Primal RDCL）の発行日情報とを比較する。その結果、RDCL_[I]の発行日の方が新しければ、RDCL_[P]をRDCL_[I]で上書きする。もし、RDCLの更新が行われた場合は、自身に記録されているConnection Logの全エントリを、消去もしくは無効化する。このようにすることで、以後当該Host Security ManagerにStorage Security Managerを接続する場合は、必ずConnection Stageが実行されることになる。Reconnection Stageについては、図19を用いて後に詳細に説明する。これにより、ある閉じた機器群に新しいRDCLを持った機器が追加された場合、最新のRDCLを徐々に伝播させてゆくことができるようになる。RDCLの発行日比較を終えると、残りのデータをPrimal Device秘密鍵K_d[P]で復号する。続いて、一時的な共通鍵暗号化のための鍵である0次Primal Session鍵K_s[P]0（PD.S.Key）を生成する。該鍵の生成を終えると、自身に埋め込まれているPrimal Device公開鍵及び自身の世代情報GN_[P]と連結し、データ16020によって受信したInceptive Device公開鍵KP_d[I]で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、RDCL_[P]の発行日の方が新しいことが判明した場合は、先に暗号化したデータに、RDCL_[P]を連結する。得られたデータは、データ16020に含まれていたInceptive Challenge鍵K_ch[I]で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する（16040）。以上の処理が、16031である。

以降の処理は、図17を用いて説明する。Inceptive Deviceは、受信したデータ16040をInceptive Challenge鍵K_ch[I]で復号し、データの完全性を検証する。復号結果にRDCL_[P]が含まれていた場合は、RDCL_[I]を該RDCL_[P]で上書きする。Host Security Manager同様に、RDCLの更新処理が実行された場合、Storage Security Managerに記録されていたConnection Logの全エントリを消去あるいは無効化する。続いて、残りのデータをInceptive Device秘密鍵K_d[I]で復号し、0次Primal Session鍵を得る。続いて、一時的な共通鍵暗号化のための鍵である0次Inceptive Session鍵K_s[I]0（ID.S.Key）を生成する。該鍵の生成を終えると、Primal Device公開鍵，0次Primal Session鍵，0次Inceptive Session鍵，Primal Device Class証明書DCC_[P]に含まれるAcceptable Usage Pass Type Map，データ16030に含まれていたPrimal Deviceの世代情報，Primal Device Class証明書DCC_[P]のシリアル番号を、Inceptive Connection Log（CL）の各フィールドKP_d[P]，K_s[P]0，K_s[I]0，TM_[P]，GN_[P]，HS_[P]に記録する。この時、既に当該HS_[P]と同じ値がHS_[P]として記録されたエントリがあった場合は、当該エントリを一度無効化して新しいエントリを生成するか、当該エントリの各フィールドを上書きするかのいずれかを行う必要がある。このようにすることにより、あるPrimal Deviceに対して複数のConnection LogのエントリがInceptive Device内に存在することを防止することができる。また、Inceptive DeviceにおけるConnection Log記録用エントリ1111〜1115が全て使用されていて、且つどのエントリもここで接続しようとしているPrimal DeviceとのConnection（Reconnection）Stageに関する情報を記録していなかった場合は、どれか一つのエントリを上書きする形でログ情報を記録する必要がある。このような場合、通常はRecovery Allowed Primal Device Indicatorが指し示すエントリ以外のエントリを上書きするべきである。しかし、もし同Indicatorが指し示すエントリを上書きするような事態となった場合は、Recovery Allowed Primal Device Indicatorに記録されているConnection Logのエントリを特定する情報を、消去もしくは無効化する。Recovery Allowed Primal Device Indicatorを記録するタイミングについては、PI Transfer Stage及びIP Transfer Stageに関する説明をする際に、詳細に説明する。そして、生成した0次Inceptive Session鍵K_s[I]0を、データ16030に含まれていた0次Primal Session鍵K_s[P]0及びPrimal Device公開鍵KP_d[P]で暗号化し、Primal Deviceへ送信する（16050）。以上の処理が、16041である。

Primal Deviceは、受信したデータ16050をPrimal Device秘密鍵K_d[P]及び0次Primal Session鍵K_s[P]0で復号し、0次Inceptive Session鍵K_s[I]0を得る。続いて、Inceptive Device公開鍵KP_d[I]，0次Inceptive Session鍵K_s[I]0，0次Primal Session鍵K_s[P]0，Inceptive Device Class証明書DCC_[I]に含まれるAcceptable Usage Pass Type Map，Inceptive Deviceの世代情報を、Primal Connection Log（CL）の各フィールドKP_d[I]，K_s[I]0，K_s[P]0，TM_[I]，GN_[I]に記録する。記録する際のエントリは、Inceptive Deviceにおいてエントリを選択した場合と、同様の方法で選択する。即ち、接続されているInceptive Deviceに関するエントリがあった場合は、当該エントリを一度無効化して新しいエントリを生成するか、当該エントリの各フィールドを上書きするかのいずれかとする。このような選択が実行できるようにするために、Connection Logのエントリを生成した場合には、15001で得たStorage Device Identiferを当該エントリに関連付けてどこかに記録しておくと良い。但し、この処理は必須ではない。また、Connection Log用エントリ1021，1031等が全て使用されていて、且つどのエントリもここで接続しようとしているInceptive DeviceとのConnection（Reconnection）Stageに関する情報を記録していなかった場合は、どれか一つのエントリを上書きする形でログ情報を記録することとする。以上の処理が、16051である。

以上の処理を、BT Connection Stageと呼ぶ。BT Connection Stageを完了すると、0次Primal Session鍵、0次Inceptive Session鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Primal Device鍵、及びInceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。

[Usage Pass転送処理: BTモードPI Transfer Stage]
認証処理を終えると、Usage Pass転送を実行することができる。初めに、図18を用いて、BT PI Transfer Stage について説明する。BT PI Transfer Stageとは、BTモードにおいて、Primal DeviceからInceptive DeviceへUsage Passを転送する処理のことである。尚、次節では、図18を用いてBT IP Transfer Stageについて詳細に説明する。BT IP Transfer Stageとは、Inceptive DeviceからPrimal DeviceへUsage Passを転送する処理のことである。

まず、Host Modulesからの要求18000に応じて、Primal Deviceにおいて目的のUsage Passを、Usage Pass転送用モジュール701に準備する（18001）。続いて、Host Modulesからの要求により、Inceptive DeviceはUsage Passを暗号化するためのn次Inceptive Session鍵K_s[I]n（ID.S.Key）を生成する。ここでnは、Connection StageもしくはReconnection Stage完了後に行われた、BT PI Transfer Stageの実行回数である（即ち、n ≧ 1）。該鍵の生成を終えると、1つ前のPrimal DeviceからInceptive DeviceへのUsage Pass転送時に生成したInceptive Session鍵K_s[I]n-1（n-1次Inceptive Session鍵）と、その時点で最新のPrimal Session鍵K_s[P]mで暗号化し、Primal Deviceへ送信する（18020）。ここでmは、n同様に、Connection StageもしくはReconnection Stage完了後に行われた、BT IP Transfer Stageの実行回数である（即ち、m ≧ 1）。以上の処理が、18011である。

Primal Deviceは、受信したデータ18020をPrimal Session鍵K_s[P]m及びn-1次Inceptive Session鍵K_s[I]n-1で復号する。そして、転送対象Usage PassのUPID，転送における自身の役割（転送元S = Source）、送信予定のUsage Passを、Transaction Logの1つのエントリに記録する。尚、BTモードでは、Transaction Logの記録は、Primal Deviceのみが行う。続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Inceptive DeviceにおけるUsage Passの記録先アドレスUPL_[D]（転送先D = Destination）をTransaction Logの当該エントリに記録した後、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータAI，Checksum，UPL_[D]を連結し、n次Inceptive Session鍵K_s[I]nと共有Inceptive Device鍵*KP_d[I]で暗号化する。暗号化を終えると、Inceptive Deviceへ目的のデータを送信するための命令に付属するパラメータとして記録先アドレスUPL_[D]を平文のままInceptive Deviceへ送信するのに続いて、暗号化されたUsage Passを含むデータをInceptive Deviceへ送信する（18030）。UPL_[D]は、前記のようにパラメータとして送信する必要は必ずしもない。しかし、磁気ディスク装置における一般的なインタフェースアーキテクチャであるATAでは、目的のデータを記憶装置に書き込む場合は、書き込み先アドレスをパラメータとして指定する形になっているため、このようにしておくと、本実施例に説明するような技術を磁気ディスク装置に実装する場合、親和性が高くなるという利点がある。以上の処理が、18021である。

Inceptive Deviceは、受信したデータ18030を共有Inceptive Device鍵*K_d[I]及びn次Inceptive Session鍵K_s[I]nで復号する。復号され平文となったデータは、データ構造が確認される。構造の確認は、図5に示したような、各フィールドに割り当てられたTagの値やSize情報によって行われる。データ構造に関して問題がないことが確認されると、パラメータとして受信したUPL_[D]と、暗号データ17030に含まれるUPL_[D]が一致しているか否かを確認する。もし一致していなかった場合は、パラメータとして受信したUPL_[D]が改竄されていることになるため、この処理を中断する。一致していた場合は、目的のUsage Passの受信が正常に行われたと判断され、当該PI Transfer Stageの前段として実行されたConnection（あるいはReconnection）Stageにおいて生成（あるいは更新）されたConnection Logのエントリを指し示すように、Recovery Allowed Primal Device Indicatorを設定する。尚、Recovery Allowed Primal Device Indicatorの設定は、PI Transfer StageやIP Transfer Stageが実行される度に行っても良いが、Connection StageあるいはReconnection Stageが完了した後、初めてPI Transfer StageもしくはIP Transfer Stageが実行された場合だけでも良い。このようにすれば、PI Transfer StageやIP Transfer Stageを実行する際の、Inceptive Deviceにおける処理負荷を軽減することができる。以上の処理を終えると、平文となったUsage PassのUR_sを規定された方法で適切に更新した後、Inceptive Device内のUsage Pass記憶領域へ記録する。以上の処理が、18031である。以上が、BT PI Transfer Stageである。

[Usage Pass転送処理: BTモード IP Transfer Stage]
次に、Inceptive DeviceからPrimal DeviceへのUsage Pass転送処理であるBT IP Transfer Stageについて、図19を用いて説明する。

まず、Host Modulesは、目的のUsage Passが記録されているアドレスUPL_[S]（転送元S = Source）や、目的のUsage PassのUPIDをInceptive Deviceに対して通知する（1９000）。

これを受けて、Inceptive Deviceは、Usage Pass転送用モジュール603に目的のUsage Passを準備する。続いてInceptive Deviceは、Usage Passに対し、CICフィールド403を0で置き換え、Usage Passの状態情報Usage Pass Status（UPS）を連結した後、データに最新のPrimal Session鍵とInceptive Session鍵連結してHash値を計算する。Usage Pass Statusとしては、次の3つの状態のいずれかが設定される。:(1)目的のUsage Passが存在しない（UPIDが異なるUsage Passが記録されているか、あるいは何も記録されていない）。(2) 目的のUsage Passが有効な状態で記録されている。 (3) 目的のUsage Passが無効な状態で記録されている。そして、得られたHash値を、Masked Usage Passに連結し、Primal Deviceへ送信する。前記CICフィールド403を0で置き換えたUsage Passを、以下ではMasked Usage Passと呼ぶ。以上の処理が、19001である。

Primal Deviceは、データ19010におけるHash値を検証し、当該データに改竄が行われていないかどうか、検証する（19011）。

改竄が行われていないことが確認できた場合は、Primal Deviceに対して、Host Modules 110が転送対象Usage PassのUPIDを送信する（19020）。

Primal Deviceは、Host Modules 110から受信したUPID 19020と、Masked Usage Pass 19010として受信したUsage PassのUPIDを比較する。これらが一致していた場合は、UPID、転送における自身の役割（転送先D = Destination）、転送対象Usage Passに記述されているUR_s、Inceptive Deviceにおいて転送予定のUsage Passが記録されているアドレスUPL_[S]を、Transaction Logに記録する。続いて、m次Primal Session鍵K_s[P]m（PD.S.Key）を生成し、1つ前のInceptive DeviceからPrimal DeviceへのUsage Pass転送で生成されたPrimal Session鍵K_s[P]m-1（m-1次Primal Session鍵）と、その時点で最新のInceptive Session鍵K_s[I]nで暗号化し、Inceptive Deviceへ送信する（19030）。ここで、mやnの意味は、BT PI Transfer Stageに関する説明において述べたのと全く同じである。以上の処理が、19021である。

Inceptive Deviceは、データ19030をその時点で最新のInceptive Session鍵K_s[I]n及びm-1次Primal Session鍵K_s[P]m-1で復号する（19031）。続いて、Host Modules 110は、どのような形態でのUsage Pass転送処理なのか（複製，移動，再生等）を、Inceptive Deviceへ通知する（19040）。これを受けてInceptive Deviceは、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータAIやChecksumを連結し、m次Primal Session鍵K_s[P]mと共有Primal Device鍵*KP_d[P]で暗号化する（19041）。続いて、BT PI Transfer Stageの場合と全く同様の方針に則って、Recovery Allowed Primal Device Indicatorを設定する。以上の処理を終えたら、前記暗号化データをPrimal Deviceへ送信する（19050）。データ19050を送信後、Inceptive Deviceでは、転送を行ったUsage PassのUR_sやFlag（1401，1411，1421等）を適切に変更し、記録し直す（19051）。

Primal Deviceは、受信したデータを共有Primal Device鍵*K_d[P]及びm次Primal Session鍵K_s[P]mで復号及び平文データの構造を確認し、目的のUsage Passの転送が完了する（19052）。以上が、BT IP Transfer Stageである。

[Usage Pass転送処理: BTモード Reconnection Stage]
記録再生装置に異常が発生し、Connectionが切断されてしまった場合（20001）、Connection Stageと比べると、より簡単な処理で、再びConnectionを確立するための処理が、BT Reconnection Stageである。BT Reconnection Stageについて、図20を用いて説明する。

図15に示したInitialization Process 20002に続いて、Primal Deviceに対し、Host ModulesはStorage Device Identifierの通知及び新たな0次Primal Session鍵K_s[P]0.RCN（PD.S.Key）の生成要求を行う（20010）。

Primal Deviceでは、接続されたInceptive Deviceが本実施例に説明する処理を実行する機能を伴った世代のものであるかどうかを、Connection LogのPartner Device Generation Numberから把握する。当該Inceptive Deviceが、当該処理の実行が可能と判断されると、受信したデータ20010に基づいて、当該BT Reconnection Stageを実行するためのConnection Logのエントリを選択する。続いて、新たな0次Primal Session鍵K_s[P]0.RCNを生成する。次に、Initialization Process 20002においてInceptive Deviceより受信した情報15002に基づいて、Inceptive Deviceに、どのConnection Logのエントリを用いて当該Reconnection Stageを実行させるかを決定する。決定された値はCLENに設定される。CLENは、生成した鍵K_s[P]0.RCNに連結された後、選択したConnection Logのエントリに記録されているInceptive Session鍵K_s[I]0.CLとInceptive Device公開鍵K_s[P].CLで暗号化され、Inceptive Deviceへ送信される（20020）。この送信処理に先立ち、CLENは、処理20021を実行させるための命令に付随するパラメータとして、平文状態でもInceptive Deviceへ送信される。これは、平文状態でCLENを受信しないと、Inceptive Deviceでは、どのConnection Logのエントリに記録されている鍵データを使って受信したデータの復号を実行すればよいか、判断が付かないためである。以上の処理が、20011である。

Inceptive Deviceは、パラメータとしてCLENに記述された情報に基づいてConnection Logのエントリを選択し、自身のInceptive Device秘密鍵K_d[I]及び当該エントリに記録されているInceptive Session鍵K_s[I]0.CLを用いて、受信したデータ20020を復号する。復号結果は、Tagなどを元に構造が確認された後、パラメータとして受信したCLENと、復号結果に含まれるCLENが一致しているかどうかが調べられる。もし両者が一致していなかった場合、復号結果に構造上の問題がなくても、転送処理20020においてパラメータとしてのCLENが改竄された可能性が高いため、本処理は中断される。両者が一致していた場合は、接続されているPrimal Deviceが、本実施例に説明する処理を実行する機能を伴った世代のものであるかどうかを、Connection LogのPartner Device Generation Number GN_[P]に記録された値から把握する。続いて、CLENで指定されたConnection Logのエントリを、Recovery Allowed Primal Device Indicatorが指し示しているかどうかを確認する。そして、GN_[P]，CLEN，RAPDIの値に応じて、Recovery Permission Indicator（RPI）の値を適切に設定及び処理する。尚、記述を簡潔にするため、GN_[P]とRPIの値とその意味を、下記の通りとする。言うまでもないが、値については、これに限るものではない。

- Partner Device Generation Number（GN_[P]）
1: 接続されたPrimal Deviceが本実施例に説明する処理を実行する機能を伴った世代のものである
0: 接続されたPrimal Deviceが本実施例に説明する処理を実行する機能を伴った世代より前のものである
- Recovery Permission Indicator（RPI）
1: Primal Deviceに記録されている、Connection Logの当該エントリに関連したTransaction Logの保持が許可される
0: Primal Deviceに記録されている、Connection Logの当該エントリに関連したTransaction Logを無効化あるいは消去しなければならない
受信したデータ20020の復号，前記2つの確認処理の結果及びPartner Device Generation Number（GN_[P]）とRecovery Allowed Primal Device Indicator（RAPDI）の値によって、以下のように処理を行う。
(1) GN_[P] = 0であり、且つRAPDIが指し示すConnection Logのエントリに記録された鍵データを用いてデータ20020を復号及び前記2つの確認処理が正常に完了した場合: Recovery Permission Indicatorに1を設定する。
(2) GN_[P] = 0であり、且つRAPDIが指し示すConnection Logのエントリに記録された鍵データを用いてデータ20020を復号及び前記2つの確認処理が正常に完了できなかった場合: 当該Reconnection Stageを中断する。
(3) GN_[P] = 0であり、且つRAPDIが指し示すConnection Logのエントリに記録された鍵データを用いてデータ20020を復号及び前記2つの確認処理が正常に完了した場合: Recovery Permission Indicatorに1を設定する。
(4) GN_[P] = 0であり、且つRAPDIが指し示すConnection Logのエントリに記録された鍵データを用いてデータ20020を復号及び前記2つの確認処理が正常に完了できなかった場合: Recovery Permission Indicatorに0を設定する。

上記4種のいずれかの処理を行った後、中断する以外の場合については、Inceptive Deviceにおいて新たな0次Inceptive Session鍵K_s[I]0.RCN（ID.S.Key）の生成を行う。そして、生成されたK_s[I]0.RCNに、RPIを連結し、Connection Logの当該エントリに記録されているPrimal Session鍵K_s[P]0.CLとPrimal Device公開鍵KP_d[P].CLを用いて暗号化する。続いて、受信した0次Primal Session鍵K_s[P]0.RCN及び生成した0次Inceptive Session鍵K_s[I]0.RCNを、Connection Logの当該エントリに上書きし、先に暗号化したデータを、Primal Deviceへ送信する（20030）。以上の処理が20021である。Connection Stageの場合同様に、新しいConnection Logのエントリを生成しそこに記録しても良いが、その場合は、古いエントリは無効化もしくは消去しなければならない。

Primal Deviceは、受信したデータ20030をPrimal Device秘密鍵K_d[P]及び20011で選択したConnection Logのエントリに記録されている0次Primal Session鍵K_s[P]0.CLを用いて復号する。そして、得られた新しい0次Inceptive Session鍵K_s[I]0.RCNと、先に生成した0次Primal Session鍵K_s[P]0.RCNを、Connection Logの当該エントリに上書き記録する。以上の処理が、20031である。最後に、Recovery Permission Indicatorの値を評価し、当該Indicatorが0であった場合は、Connection Logの当該エントリに関連付けられたTransaction Logの全エントリを無効化もしくは消去する。当該Indicatorが1であった場合、Transaction Logの当該エントリは、そのまま保持される。以上の処理が20031である。以上の処理を、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 Session鍵、0次Inceptive Session鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Primal Device鍵Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Inceptive Device鍵が共有されていることは、先に述べた通りである。

初めにBT PI Transfer Stageに対する復旧処理について、図21を用いて説明する。BT PI Transfer Stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにHost Modules 110が、復旧対象のUsage PassのUPIDをPrimal Deviceに送信する（21010）。

Primal Deviceは、このUPIDを用いて、当該Connection StageもしくはReconnection Stage 21001において、生成もしくは更新されたConnection Logのエントリと関連付けられたTransaction Logの全エントリを検索する（21011）。その結果、当該UPIDを含むTransaction Logのエントリが見つかると、当該エントリに記録されているInceptive DeviceにおけるUsage Passの記録先アドレスUPL_[D]（受信したUsage Passを記録する予定だったアドレス）をHost Modulesへ送信する（21012）。Host Modulesは、当該アドレスUPL_[D]を受信すると、UPIDと共に、当該UPL_[D]をInceptive Deviceへ送信する（21020）。

Inceptive Deviceは、受信したアドレスが指し示すUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べる。そして、その結果をUsage Pass Statusに設定する。続いて、m次Primal Session鍵K_s[P]m，n次Inceptive Session鍵K_s[I]n（これら2つのSession鍵は、この時点で共有されている最新のものである），UPID，検索されたUsage PassのUR_s，生成されたUsage Pass Status，UPL_[D]を連結し、Hash値を計算する。そして、当該UPID，当該UR_s，当該Usage Pass Status，当該UPL_[D]，Hash値を連結し、Primal Deviceへ送信する（21030）。以上の処理が、21021である。

Primal Deviceは、受信したデータ21030に含まれるHash値を検証し、データ21030に改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが存在しないことを確認する。検証を終えると、受信したUPIDを含むTransaction Logを再度検索する。目的のTransaction Logのエントリが見出されると、当該エントリに記録されている転送前のUsage Passを、現在Usage Pass送信用モジュール701に用意されているUsage Passに対して上書きする。

以上が、BT PI Recovery Stageである。このStageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。

[Usage Pass転送処理: BTモード IP Recovery Stage]
次に、BT IP Transfer Stageに対するUsage Passの復旧処理について、図22を用いて説明する。BT IP Transfer Stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにHost Modules 110が復旧対象のUsage PassのUPIDを、Primal Deviceに送信する（22010）。

Primal Deviceは、このUPIDを用いて、当該Connection StageもしくはReconnection Stage 22001において、生成もしくは更新されたConnection Logのエントリと関連付けられたTransaction Logの全エントリを検索する（22011）。その結果、当該UPIDを含むTransaction Logのエントリが見つかると、当該エントリに記録されているInceptive DeviceにおけるUsage Passの記録先アドレスUPL_[S]（転送対象のUsage Passが元来記録されていた領域を指し示すアドレス）をHost Modulesへ送信する（22012）。Host Modulesは、当該アドレスUPL_[S]を受信すると、UPIDと共に、当該アドレスUPL_[S]をInceptive Deviceへ送信する（22020）。

Inceptive Deviceは、受信したアドレスが指し示すUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べ、その結果をUsage Pass Statusに設定する。そして、m次Primal Session鍵K_s[P]m，n-1次Inceptive Session鍵K_s[I]n-1，UPID，検索されたUsage PassのUR_s，生成されたUsage Pass Status，UPL_[S]を連結し、Hash値を計算する。そして、UPID，当該UR_s，当該Usage Pass Status，当該UPL_[S]，Hash値を連結し、Primal Deviceへ送信する（22030）。以上の処理が、22021である。

Primal Deviceは、受信したデータ22030に含まれるHash値を検証し、データ22030に改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが、過去の転送（送信）処理によって、変化してしまったかどうかを確認する（22031）。

上記検証と並行して、Host Modulesは、Inceptive Deviceに対し、Session鍵（ID.S.Key）の生成を要求する（22040）。該要求を受信すると、Inceptive Deviceは、n次InceptiveSession鍵K_s[I]nを生成する。当該鍵の生成を終えると、生成されたn次Inceptive Session鍵K_s[I]nをn-1次Inceptive Session鍵K_s[I]n-1及びm次Primal Session鍵K_s[P]mで暗号化し、Primal Deviceへ送信する（22050）。以上の処理が、22041である。

Primal Deviceでは、データ22050を受信後、先に述べた検証処理によって、Usage Passが送信処理を実行することによって変化してしまっていることが確認されると、以下に記すUsage Passの復旧処理を実行する。まず、受信したデータを、m次Primal Session鍵K_s[P]m及びn-1次Inceptive Session鍵K_s[I]n-1で復号する。続いて、先に検索の結果見つけられたTransaction Logの当該エントリに記録されているUPID，UR_s，UPL_[S]とを連結し、n次Inceptive Session鍵K_s[I]n及び共有Inceptive Device鍵*KP_d[I]で暗号化する。暗号化を終えると、Inceptive Deviceへ目的のデータを送信するための命令に付属するパラメータとしてUPL_[S]を平文のままInceptive Deviceへ送信するのに続いて、当該暗号化データをInceptive Deviceへ送信する（22060）。UPL_[S]は、データ18030で説明したのと同様に、パラメータとして送信する必要は必ずしもない。しかし、磁気ディスク装置における一般的なインタフェースアーキテクチャであるATAでは、目的のデータを記憶装置に書き込む場合は、書き込み先アドレスをパラメータとして指定する形になっているため、このようにしておくと、本実施例に説明するような技術を磁気ディスク装置に実装する場合、親和性が高くなるという利点がある。以上の処理が、22051である。

Inceptive Deviceは、受信したデータ22060を、共有Inceptive Device鍵*K_d[I]及びn次Inceptive Session鍵K_s[I]nで復号する。復号され平文となったデータは、データ構造が確認される。構造の確認は、図5に示したような、各フィールドに割り当てられたTagの値やSize情報によって行われる。データ構造に関して問題がないことが確認されると、パラメータとして受信したUPL_[S]と、暗号データ22060に含まれるUPL_[S]が一致しているか否かを確認する。もし一致していなかった場合は、パラメータとして受信したUPL_[S]が改竄されていることになるため、この処理を中断する。一致していた場合は、復号結果に含まれるUPIDが、UPL_[S]で指し示される領域に記録されているUsage PassのUPIDと一致しているかを確認する。UPIDの一致が確認されると、UPL_[S]で指し示される領域に記録されているUsage Passを有効化し、復号結果に含まれるUR_sで当該Usage PassのUR_sを上書き記録する。以上の処理が、22061である。

以上が、BT IP Recovery Stageである。このStageを完了すると、Inceptive Deviceには、送信を行う前のUsage Passが存在するようになる。

[RPIの値に応じたTransaction Logの該当エントリの無効化タイミング]
Primal DeviceにおけるRPIの確認及びその帰結としてのTransaction Logの対象エントリの消去或いは無効化処理は、上述のようにReconnection Stage時に一括して行わなくても良い。その場合は、Recovery Stageにおいて、Transaction Logの目的のエントリからOriginal Usage PassもしくはOriginal Usage Ruleを取り出す処理を実行する（図21 21031 処理2及び図22 22051 処理3）より前の何れかの時点で、当該消去或いは無効化処理を完了する。

[Host Modulesによる、記憶装置に記録されているUsage Passの参照処理: UP Inquiry Stage]
記憶装置に記録されているUsage Passのうちの、CIC以外の情報をHost Modulesが把握するための処理について図23を用いて説明する。これをUP Inquiry Stageと呼ぶ。

まず、Host Modulesが、Usage Passが記録されている記憶装置に対して、Masked Usage Pass転送要求を送信する（23000）。該要求を受信すると、Host Modules 110に対して、記憶装置はMasked Usage Passを応答する（23001）。

以上、実施例について説明したが、本発明は上記実施例に限定されない。また、種々変形して実施したり、また他の装置やシステムにも応用できるであろう。特に、機器同士の認証方法や、機器間転送時のコンテンツ鍵や利用条件の暗号化方法は、BTモードに限らず、より一般的なものであっても良い。本実施例では、コンテンツ鍵や利用条件は転送の際には二重に暗号化されたが、これは一重であったり、あるいは三重以上であったりしても良い。

また、上記実施例において説明された命令やモジュール等の呼び名は、あくまで一例であって上記の例に限定されない。例えば、上記実施例におけるユーセジパス（Usage Pass）は、ライセンス情報、或いは機密情報と呼ばれる場合もあろう。

また、上記実施例では、記録再生装置と磁気ディスク装置を含むシステムにおけるコンテンツデータのセキュリティ管理について述べたものであるが、他の例によるシステム及びその構成装置にも適用可能である。即ち、本発明に係る、コンテンツデータの復号化を管理するための制御情報を取扱う特徴的な処理機能を有すれば、記録再生装置及び磁気ディスク装置に限定されない。この特徴的な処理機能を有する限りにおいて、例えば、磁気ディスク装置は、半導体メモリを含む記憶装置でもよく、また、記録再生装置は、記憶装置が接続されるホストコンピュータでもよい。

また、他の変形例においては、上記実施例の鍵データ等を記憶する保護記憶領域は、論理的に対タンパ性が確保されていれば、必ずしも物理的に対タンパ性を有するメモリであることを要しない。

実施例1に説明したものと、処理シークエンスはほぼ同じだが、Primal Deviceで保持するTransaction Logの構造と、Inceptive Device内に記録されるRecovery Allowed Primal Device Indicator及び、Reconnection Stageにおけるデータ20030でInceptive DeviceからPrimal Deviceに対して送信されるRecovery Permission Indicatorを、以下のようにすることでも、同様の機能を実現できる。

図24に、Transaction Logの構造を示す。本実施例では、Transaction Logに0次Session鍵を記録するフィールド2405を新たに設ける。このフィールドには、Primal DeviceとInceptive DeviceがConnection StageもしくはReconnection Stageで共有した0次Session鍵を記録する。0次Session鍵としては、あらかじめ規定さえしておけば、Primal Deviceで生成されたものでもInceptive Deviceで生成されたものでも、あるいはその双方の何れであっても良い。記録するタイミングは、他のフィールド同様で、BT PI Transfer Stageの場合は18021，BT IP Transfer Stageの場合は19021である。

Inceptive Deviceに記録されるRecovery Allowed Primal Device Indicatorは、Connection StageもしくはReconnection Stage完了後に、始めてBT PI Transfer StageもしくはBT IP Transfer Stageが実行された際に、その時点で共有されている0次Session鍵を記録する。記録する0次Session鍵は、Transaction Logに記録するものと同じものとするとの取り決めをしておけば、Primal Deviceで生成されたものでもInceptive Deviceで生成されたものでも、あるいはその双方の何れでも良い。

Reconnection StageにおいてInceptive DeviceからPrimal Deviceに送信するデータ20030に含まれるRecovery Permission Indicator（RPI）には、前記Recovery Allowed Primal Device Indicatorとして記録されている情報そのものを設定する。Primal Deviceでは、データ20030を受信すると、Reconnection Stageの実行のために利用しているConnection Logのエントリに関連したTransaction Logの全エントリについて、0次Session鍵のフィールド2405を検索する。その結果、RPIと異なる値が当該フィールドに記録されたエントリが存在した場合は、それらのエントリを全て消去もしくは無効化する。尚、前記0次Session鍵の一致確認及びその帰結としてのTransaction Logの対象エントリの消去或いは無効化処理は、Reconnection Stage時に一括して行わなくても良い。その場合は、実施例1同様に、Recovery Stageにおいて、Transaction Logの目的のエントリからOriginal Usage PassもしくはOriginal Usage Ruleを取り出す処理を実行する（図21 21031 処理2及び図22 22051 処理3）より前の何れかの時点で、当該消去或いは無効化処理を完了する。

本発明の一実施例が適用される記録再生装置を含むデータ保護システムを示す概略構成図。一実施例による脱着可能な磁気ディスク装置の構成図。一実施例において使用されるデータ、情報、及び記号法等を示す表。一実施例において使用されるデータの復号条件や復号鍵をまとめたデータ（Usage Pass）の構成図。一実施例において使用される図4に示したデータ（Usage Pass）のUPIDフィールドの構造図。一実施例による磁気ディスク装置におけるBTモードを実現するUsage Pass転送モジュール図。一実施例による記録再生装置において、BTモードでUsage Pass送信を実現する記録専用の機能モジュールの構成図。一実施例による記録再生装置において、BTモードでUsage Pass受信を実現する復号専用の機能モジュールの構成図。一実施例による記録再生装置において、BTモードで磁気ディスク装置との間で相互認証処理及びUsagePass転送を実現する機能モジュールの構成図。一実施例による記録再生装置において、BTモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。一実施例による磁気ディスク装置において、BTモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。一実施例による記録再生装置及び記憶装置において、BTモードにおいて記録される、相互認証処理のログ情報の構造図。一実施例による記録再生装置において、BTモードにおいて記録される、Usage Pass転送処理のログ情報の構造図。一実施例による磁気ディスク装置において、図4等に示したUsage Passを記録する、対タンパ性を有する静的な記憶領域を示す図。一実施例によるUsage Pass転送処理におけるアクセスモードの認識、設定のための処理シークエンスを示す図。一実施例における、BTモードで記録再生装置と磁気ディスク装置の間で行われる相互認証処理シークエンスの前半部を示す図。一実施例における、BTモードで記録再生装置と磁気ディスク装置の間で行われる相互認証処理シークエンスの後半部を示す図。一実施例における、BTモードで記録再生装置から磁気ディスク装置に対して送信される、Usage Pass転送処理シークエンスを示す図。一実施例における、BTモードで磁気ディスク装置から記録再生装置に対して送信される、Usage Pass転送処理シークエンスを示す図。一実施例における、BTモードで記録再生装置と磁気ディスク装置の間で行われる、簡略化された再相互認証処理シークエンスを示す図。一実施例における、BTモードで記録再生装置から磁気ディスク装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シークエンスを示す図。一実施例における、BTモードで磁気ディスク装置から記録再生装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シークエンスを示す図。一実施例における、記録再生装置内のホストモジュールに対し、コンテンツ鍵以外のUsage Passに含まれる情報を、記憶装置が応答する処理シークエンスを示す図。一実施例による記録再生装置において、BTモードにおいて記録される、Usage Pass転送処理のログ情報の構造図。

符号の説明

100：ネットワークインタフェース、101：保護情報領域、102：記録モジュール、103：再生モジュール、105：ユーザインタフェースブリッジ、106，107：外部ストレージインタフェース、108：プロセッサ、110：ホストモジュール、111：ホストセキュリティマネージャ、112：記録再生装置、150：配信サーバ、125、126、240：磁気ディスク装置、221：ユーセジパス転送モジュール、222：制限記憶制御部、223：制限記憶部、230：記憶装置コントローラ、231：バッファ。

Claims

第１の接続先装置との間で互いを認証するために用いた認証用鍵データを含む情報を格納する第１の認証ログ、前記第１の認証ログに対応して、暗号化されたコンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む所定の情報の前記第１の接続先装置への、及び前記第1の接続先装置からの転送に先立ち、前記転送処理の過程で前記所定の情報が消失してしまった場合に、前記所定の情報を復旧するために、前記所定の情報を格納する転送ログ、前記認証処理及び所定の情報の転送処理実行後、前記第１の接続先装置との間で再度互いに認証するために、前記第１の接続先装置に格納されている、前記第１の認証ログの1つのエントリに格納されている内容に対応する認証ログの1つのエントリの格納場所を特定する情報を、前記第１の接続先装置に送信する送信モジュール、及び前記第１の接続先装置からの前記再認証処理の成功及び許可の通知に続いて、前記認証処理の実行に際して利用した認証ログの1つのエントリに格納されている内容に関連付けられた前記転送ログに格納されている、前記所定の情報の転送を実行する実行モジュールを含むホスト装置と、前記ホスト装置と接続し、前記ホスト装置を含む複数の接続先装置の各々との間で互いを再認証するための認証用鍵データを含む情報を、前記複数の接続先の装置に対応して格納する第２の認証ログ、前記送信モジュールからの前記第１の認証ログの当該1つのエントリに格納されている内容に対応する認証ログの1つのエントリの格納場所を特定する情報が、前記複数の接続先装置の中で最新の該鍵データと該利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する、前記第２の認証ログの1つのエントリの格納場所を指示するときに、前記ホスト装置に前記所定の情報の転送許可を応答する応答モジュール、及び前記暗号化されたコンテンツデータを格納する記憶媒体を含む、第１の接続先装置としてのストレージ装置とを有することを特徴とするコンテンツデータ管理システム。
前記ストレージ装置は、前記複数の接続先装置の中で、最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する前記第２の認証ログの1つのエントリの格納場所を指示する情報を格納する指示領域を有することを特徴とする請求項１記載のコンテンツデータ管理システム。
前記送信モジュールからの、前記第１の認証ログの前記1つのエントリの格納場所を特定する情報が、前記指示領域に格納されている情報に不一致のときに、前記応答モジュールは前記ホスト装置に不許可を応答することを特徴とする請求項２記載のコンテンツデータ管理システム。
前記不許可に応答して、前記ホスト装置は、前記第１の認証ログの前記1つのエントリに格納されている内容に関連付けられた前記転送ログに格納されている、以前に実行された転送過程において消失してしまった前記暗号化されたコンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む前記所定の情報を無効にすることを特徴とする請求項３記載のコンテンツデータ管理システム。
前記ホスト装置は、前記暗号化されたコンテンツデータが複数ある場合に、該複数の暗号化されたコンテンツデータの各々に対応して、以前に実行された転送過程において消失してしまった各コンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む各所定の情報を前記第１の認証ログの複数のエントリにそれぞれ格納することを特徴とする請求項３記載のコンテンツデータ管理システム。
前記ストレージ装置は、複数の接続先装置の中で、最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する前記第２の認証ログの1つのエントリに、前記最新の転送処理を実行した一つであることを示す情報を格納することを特徴とする請求項２記載のコンテンツデータ管理システム。
第１の認証ログ及び前記第１の認証ログの1つのエントリに関連づけられた転送ログを有するホスト装置と、暗号化されたコンテンツデータを格納する記憶媒体及び前記ホスト装置を含む複数の接続先装置に対応する第２の認証ログを有するストレージ装置との間で、前記暗号化されたコンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む所定の情報を転送するコンテンツデータ管理方法であって、前記ホスト装置は、前記ストレージ装置との間で互いを認証するために用いた認証用鍵データを含む情報を前記第１の認証ログの1つのエントリに格納し、前記ストレージ装置は、前記ホスト装置との間で互いを認証するために用いた認証用鍵データを含む情報を前記第２の認証ログの前記ホスト装置に対応する1つのエントリに格納し、前記ホスト装置は、前記第１の認証ログの1つのエントリに格納された内容に対応して、前記暗号化されたコンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む所定の情報の前記ストレージ装置への、及び前記ストレージ装置からの転送に先立ち、前記所定の情報を特定する情報を前記転送ログの1つのエントリに格納し、前記ホスト装置は、前記認証処理及び所定の情報の転送処理実行後、前記ストレージ装置との間で再度互いに認証するために、前記ストレージ装置に格納されている前記第１の認証ログの前記1つのエントリに格納されている内容に対応する認証ログの1つのエントリの格納場所を特定する情報を前記ストレージ装置に送信し、前記ストレージ装置は、前記第１の認証ログの前記1つのエントリに格納されている内容に対応する前記認証ログの1つのエントリの格納場所を特定する情報の受信に応答して、該情報が前記第２の認証ログの、前記ホスト装置に対応する前記領域を特定する情報であり、且つ前記第２の認証ログの、前記ホスト装置に対応する前記領域に格納されている情報が、前記複数の接続先装置の中で最新の認証処理を実行した一つに対応する場合に、前記ホスト装置に対して許可を応答し、前記ホスト装置は前記許可に応答して、前記転送ログに格納した前記所定の情報を特定する情報を用いて、前記所定の情報を転送することを特徴とするコンテンツデータ管理方法。
前記ストレージ装置は、前記複数の接続先装置の中で、最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する前記第２の認証ログの1つのエントリの格納場所を指示する情報を格納する指示領域を有することを特徴とする請求項７記載のコンテンツデータ管理方法。
前記ストレージ装置は、前記第１の認証ログの1つのエントリの格納場所を特定する情報が、前記指示領域に格納されている情報に不一致のときに、前記ホスト装置に不許可を応答することを特徴とする請求項８記載のコンテンツデータ管理方法。
前記不許可に応答して、前記ホスト装置は、前記第１の認証ログの前記1つのエントリに格納されている内容に関連付けられた前記転送ログに格納されている、以前に実行された転送過程において消失してしまった前記暗号化されたコンテンツデータを復号するための鍵データと該コンテンツデータの利用条件とを含む前記所定の情報を無効にすることを特徴とする請求項９記載のコンテンツデータ管理方法。
前記ホスト装置は、前記暗号化されたコンテンツデータが複数ある場合に、該複数の暗号化されたコンテンツデータの各々に対応して、以前に実行された転送過程において消失してしまった各コンテンツデータ復号するための鍵データと該コンテンツデータの利用条件とを含む各所定の情報を前記第１の認証ログの複数のエントリにそれぞれ格納することを特徴とする請求項９記載のコンテンツデータ管理方法。
前記ストレージ装置は、複数の接続先装置の中で、最新の鍵データと利用条件とを含む所定の情報の転送処理を実行した一つのホスト装置に対応する前記第２の認証ログの1つのエントリに、前記最新の転送処理を実行した一つであることを示す情報を格納することを特徴とする請求項８記載のコンテンツデータ管理方法。