(57)【特許請求の範囲】
【請求項１】
コンテンツデータの復号化を管理する制御情報を扱うコンテンツデータ管理システムであって、このシステムは、
コンテンツデータを暗号化してこのコンテンツデータを第２の装置に記憶し、この第２の装置に記憶された前記コンテンツデータを復号化して前記コンテンツデータを再生する第１の装置と、
この第１の装置で暗号化された前記コンテンツデータを記憶する前記第２の装置と、を有し、
前記第１の装置は、前記第１及び前記第２の装置に対して、両装置が持つデータの転送機能に関する問合せを行い、この問合せの結果に基づいて、前記第１及び前記第２の装置のいずれか一方の装置から他方の装置へ制御情報を一方向に転送する第１の転送モード、及び前記第１及び前記第２の装置間で制御情報を双方向に転送する第２の転送モードのいずれかの転送モードを設定するホスト処理部を有し、
前記第１及び前記第２の装置の正当性を相互に認証し、この認証の結果、前記第１及び前記第２の装置が正当な場合には、前記第１及び前記第２の装置間で鍵データ（共通鍵データ）を共有し、
この共通鍵データを用いて前記第１又は前記第２の装置で制御情報を暗号化処理し、
暗号化された前記制御情報は、設定された前記第１又は前記第２の転送モードに従って、前記第１及び前記第２の装置のいずれか一方の装置から他方の装置へ転送され、前記第１の装置が前記制御情報を受信した場合は、前記共通鍵データを用いて前記制御情報を復号化し、復号化した前記制御情報を用いて前記コンテンツデータを復号化し、
前記第２の転送モードに設定された場合、正当性の認証時に、
前記第２の装置は、自身の公開鍵が含まれる証明書を前記第１の装置へ送信し、
前記第１の装置は、受信した証明書の正当性を検証して、一時的な共通鍵暗号化の鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて前記第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結してこの連結データを前記第２の装置に送信し、
前記第２の装置は、受信したデータを自身の秘密鍵を用いて復号化することにより前記第１チャレンジ鍵を取得し、一時的な共通鍵暗号化の鍵である第２チャレンジ鍵を生成し、この第２チャレンジ鍵と自身の情報領域に埋め込まれている前記公開鍵を連結し、前記連結データを受信した前記公開鍵で暗号化し、暗号化データに対して、自身に記録された証明書失効リストを連結し、連結データを受信した第１チャレンジ鍵で暗号化し、暗号化したデータを前記第１の装置へ送信し、
前記第１の装置は、受信したデータを前記第１チャレンジ鍵で復号化し、証明書失効リストにあるリストの発行日を比較し、その結果、受信した前記第２の装置の証明書失効リストの発行日が前記第1の装置に記録された証明書失効リストの発行日より新しければ、受信した証明書失効リストで前記第1の装置に記録された証明書失効リストを更新し、
前記第１の装置は、自身の秘密鍵を用いてすべての復号化したデータから証明書失効リストを除いたデータを復号化し、更に、一時的な共通鍵暗号化の鍵である０次第１セッション鍵を生成し、先に受信した前記第２の装置の公開鍵及び前記第２チャレンジ鍵で暗号化を行い、この暗号化されたデータを第２の装置へ送信し、
前記第２の装置は、受信した暗号化データを前記第２チャレンジ鍵で復号化し、この復号化データに前記第１の装置の証明書失効リストが含まれていた場合は、前記第２の装置に記録された証明書失効リストを受信した証明書失効リストで更新し、この証明書失効リスト以外のすべての復号化データを前記第２の装置に埋め込まれている秘密鍵で復号化し、０次第１セッション鍵を取得することを特徴とするコンテンツデータ管理システム。
【請求項２】
前記第１の装置は、デジタルコンテンツを視聴できる機能を有する記録再生装置であり、
前記第２の装置は、前記第１の装置に着脱可能な磁気ディスク装置であり、
前記コンテンツ記憶部は磁気ディスク媒体であることを特徴とする請求項１記載のコンテンツデータ管理システム。
【請求項３】
前記制御情報は、
前記制御情報自身がどのような種類のモジュールに対して出力可能なものであるかを示すフォーマットと、
特定のデータに一意に割り当てられた識別子と、
前記コンテンツデータの利用を制限する条件と、
暗号化された前記コンテンツデータを復号化する鍵データと、
関連するコンテンツデータを特定する識別子と、を含むことを特徴とする請求項１記載のコンテンツデータ管理システム。
【請求項４】
前記第１の転送モードにおける前記制御情報の転送時に、前記第１及び前記第２の装置は、前記制御情報の処理に関連するそれぞれのトランザクションログを生成して、このトランザクションログを前記第１及び前記第２の書き込み保護記憶領域にそれぞれ記憶し、
正当性の認証が正常に行われなかった場合、前記第１又は前記第２の装置は、前記第１又は前記第２の書き込み保護記憶領域内に記憶された前記トランザクションログを参照し、前記共通鍵データを生成し、この共通鍵データを他方の装置へ送ることを特徴とする請求項１記載のコンテンツデータ管理システム。
【請求項５】
前記第２の転送モードにおける制御情報の転送時に、前記第１の装置は、前記制御情報の処理に関連するトランザクションログを生成して、このトランザクションログを前記第１の書き込み保護記憶領域に記憶し、
正当性の認証が正常に行われなかった場合、前記第１の装置は、前記第１の書き込み保護記憶領域に記憶されたトランザクションログを参照し、前記共通鍵データを生成し、この共通鍵データを前記第２の装置へ送ることを特徴とする請求項１記載のコンテンツデータ管理システム。
【請求項６】
前記第１の転送モードは、先に正当性の認証を行う認証情報を転送した、前記第１及び前記第２の装置のいずれか一方の装置から他方の装置へ制御情報を一方向に転送することを特徴とする請求項１記載のコンテンツデータ管理システム。
【請求項７】
取得したコンテンツデータを暗号化してこのコンテンツデータを第２の装置に記憶し、この第２の装置から送信された暗号化コンテンツデータを復号化してこの復号化コンテンツデータを再生する第１の装置と、この第１の装置と接続して前記第１の装置で暗号化した前記コンテンツデータを記憶する第２の装置とを含み、前記第１の装置及び前記第２の装置で扱う前記コンテンツデータのセキュリティを管理するコンテンツデータ管理システムであって、
前記第１の装置は、
前記第２の装置と接続するインタフェースと、
取得した前記コンテンツデータを記録する処理を行う記録モジュールと、
外部から又は前記インタフェースを介して前記第２の装置から送られた前記コンテンツデータを再生する処理を行う再生モジュールと、
少なくとも前記コンテンツデータを暗号化する鍵データを保持する第１の書き込み保護記憶領域と、
暗号化された前記コンテンツデータを復号化する鍵データと、前記コンテンツデータを復号化する条件を含む制御情報とを生成するホストセキュリティマネージャと、
前記第２の装置との間で行われるデータ転送を制御するホスト処理部と、を有し、
前記第２の装置は、
少なくも前記第１の装置から送られた前記コンテンツデータを記憶するコンテンツ記憶部と、
少なくとも前記制御情報を保持する第２の書き込み保護記憶領域と、
前記インタフェースを介して前記第１の装置との間でやり取りされる情報の転送制御を行う転送モジュールと、を有し、
前記ホスト処理部は、記録モジュール又は再生モジュール、及び前記第２の装置に対して、装置が持つデータの転送機能に関する問合せを行い、特定の問合せの結果に応じて、前記第１又は前記第２の装置から他方の装置へ前記制御情報を一方向に転送する第１の転送モード、及び前記第１及び前記第２の装置間において前記制御情報を双方向に転送する第２の転送モードのいずれかの転送モードを設定し、
前記ホストセキュリティマネージャは、前記第２の装置の特性に関する情報を検証して前記第２の装置の正当性を認証し、前記第２の装置の前記転送モジュールは、前記第１の装置の前記記録モジュール又は前記再生モジュールの特性に関する情報を検証してその正当性を認証し、認証の結果正当性が確認された場合には前記第１の装置及び前記第２の装置間で共通鍵データを共有し、
前記第１の転送モードに設定された場合、前記ホストセキュリティマネージャは、生成された前記制御情報を前記共通鍵データを用いて暗号化し、暗号化した前記制御情報を前記インタフェースを介して前記第２の装置へ転送し、又は前記転送モジュールは前記共通鍵データを用いて前記第２の書き込み保護記憶領域に記憶された前記制御情報を暗号化し、この暗号化された前記制御情報を前記インタフェースを介して前記第１の装置へ転送し、
前記第２の転送モードに設定された場合、前記ホストセキュリティマネージャは、生成された前記制御情報を前記共通鍵データを用いて暗号化し、この暗号化された前記制御情報を前記インタフェースを介して前記第２の装置へ転送し、又は前記転送モジュールは前記共通鍵データを用いて前記第２の書き込み保護記憶領域内に保持された前記制御情報を暗号化し、この暗号化された前記制御情報を前記インタフェースを介して前記第１の装置へ転送し、
前記第１の装置の再生モジュールは、前記共通鍵データを用いて受信した前記制御情報を復号化し、この復号化された前記制御情報を用いて前記コンテンツデータを復号化し、
前記第２の転送モードに設定された場合、正当性の認証時に、
前記第２の装置は、自身の公開鍵が含まれる証明書を前記第１の装置へ送信し、
前記第１の装置は、受信した証明書の正当性を検証して、一時的な共通鍵暗号化の鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて前記第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結してこの連結データを前記第２の装置に送信し、
前記第２の装置は、受信したデータを自身の秘密鍵を用いて復号化することにより前記第１チャレンジ鍵を取得し、一時的な共通鍵暗号化の鍵である第２チャレンジ鍵を生成し、この第２チャレンジ鍵と自身の情報領域に埋め込まれている前記公開鍵を連結し、前記受信した公開鍵を用いて暗号化し、前記第２の装置自身の無効化された認証のリストを前記暗号化されたデータに連結し、前記受信した第１のチャレンジ鍵を用いて前記連結されたデータを暗号化し、更に、前記暗号化されたデータを前記第１の装置に送信し、
前記第１の装置は、受信したデータを前記第１チャレンジ鍵で復号化し、証明書失効リストにあるリストの発行日を比較し、その結果、受信した前記第２の装置の証明書失効リストの発行日が前記第1の装置に記録された証明書失効リストの発行日より新しければ、受信した証明書失効リストで前記第1の装置に記録された証明書失効リストを更新し、
前記第１の装置は、自身の秘密鍵を用いてすべての復号化したデータから証明書失効リストを除いたデータを復号化し、更に、一時的な共通鍵暗号化の鍵である０次第１セッション鍵を生成し、先に受信した前記第２の装置の公開鍵及び前記第２チャレンジ鍵で暗号化を行い、この暗号化されたデータを第２の装置へ送信し、
前記第２の装置は、受信した暗号化データを前記第２チャレンジ鍵で復号化し、この復号化データに前記第１の装置の証明書失効リストが含まれていた場合は、前記第２の装置に記録された証明書失効リストを受信した証明書失効リストで更新し、この証明書失効リスト以外のすべての復号化データを前記第２の装置に埋め込まれている秘密鍵で復号化し、０次第１セッション鍵を取得することを特徴とするコンテンツデータ管理システム。
【請求項８】
前記第１の装置は、デジタルコンテンツを視聴できる機能を有する記録再生装置であり、
前記第２の装置は、前記第１の装置に着脱可能な磁気ディスク装置であり、
前記コンテンツ記憶部は磁気ディスク媒体であり、
前記第１及び第２の書き込み保護記憶領域のそれぞれは対タンパ性メモリを構成することを特徴とする請求項７記載のコンテンツデータ管理システム。
【請求項９】
前記制御情報は、
前記制御情報自身がどのような種類のモジュールに対して出力可能なものであるかを示すフォーマットと、
特定のデータに一意に割り当てられた識別子と、
前記コンテンツデータの利用を制限する条件と、
暗号化された前記コンテンツデータを復号化する鍵データと、
関連するコンテンツデータを特定する識別子と、を含むことを特徴とする請求項７記載のコンテンツデータ管理システム。
【請求項１０】
前記第１の転送モードにおける前記制御情報の転送時に、前記第１及び前記第２の装置は、前記制御情報の処理に関連するそれぞれのトランザクションログを生成して、このトランザクションログを前記第１及び前記第２の書き込み保護記憶領域にそれぞれ記憶し、
正当性の認証が正常に行われなかった場合、前記第１又は前記第２の装置は、前記第１又は前記第２の書き込み保護記憶領域内に記憶された前記トランザクションログを参照し、前記共通鍵データを生成し、この共通鍵データを他方の装置へ送ることを特徴とする請求項７記載のコンテンツデータ管理システム。
【請求項１１】
前記第２の転送モードにおける制御情報の転送時に、前記第１の装置は、前記制御情報の処理に関連するトランザクションログを生成して、このトランザクションログを前記第１の書き込み保護記憶領域に記憶し、
正当性の認証が正常に行われなかった場合、前記第１の装置は、前記第１の書き込み保護記憶領域に記憶されたトランザクションログを参照し、前記共通鍵データを生成し、この共通鍵データを前記第２の装置へ送ることを特徴とする請求項７記載のコンテンツデータ管理システム。
【請求項１２】
前記第１の転送モードは、先に正当性の認証を行う認証情報を転送した、前記第１及び前記第２の装置のいずれか一方の装置から他方の装置へ制御情報を一方向に転送することを特徴とする請求項７記載のコンテンツデータ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツデータ管理システム及び装置に係り、更に詳しく言えば、暗号化されたコンテンツデータを利用するための制御情報を転送処理するプロトコルの処理システム及びその装置に関するものである。
より具体的に言えば、記録再生装置や記憶装置で取扱われるコンテンツデータを利用するための鍵データを含む制御情報を転送処理するためのプロトコルの処理を含むコンテンツデータの取扱い管理システム、及びそのシステムにおける記録再生装置及び記憶装置に関する。
【背景技術】
【０００２】
音楽データや画像データ等のコンテンツデータに著作権が存在する場合、著作権保護のための適切な方策が取られていないと、著作者の権利が侵害される恐れがある。一方、著作権保護の目的を最優先し、コンテンツデータの流通を阻害してしまうと、著作物の複製に際して著作権料を徴収することが可能な著作権者にとっても、かえって不利益となる。
【０００３】
著作権保護の対象となるコンテンツデータの配信は、主にディジタル通信網や、放送波などを介して行なわれる。これらのデータを利用者が利用する際は、一度何らかの記憶媒体に記録した後、再生装置で再生する場合が多い。現状、容量が大きくアクセス性能が高い制御機能付きの記憶装置として磁気ディスク装置が知られている。磁気ディスク装置は、記録再生装置に固定的に内蔵されているものがほとんどで、磁気ディスク装置に記録されたデータを他の再生装置で利用できるようなものは未だ知られていない。しかし、利便性の面から、今後は可搬型の記憶装置の利用が進む可能性がある。一方で、容量は磁気ディスク装置に比べ少ないが、著作権保護機能を伴った可搬型の記憶装置としてメモリカードが知られている。
【０００４】
データを再生する装置としては、このようなデータの配信を受ける時に用いた記録再生装置や、可搬型の専用の再生装置が使用される。
可搬型の記憶装置を接続できる記録再生装置において、記憶装置に記録されたデータの著作権を保護するためには、記憶装置に記録されたデータを、著作権者が主張する条件の範囲を超えて再生できないように、記録再生装置及び記憶装置にセキュリティ対策を施すことが重要である。セキュリティ対策を機器に施す際には、その装置の内部及び外部から自由にアクセス可能な領域で行なわれるデータの授受に関しては、データの授受が行われる装置の間で認証処理を行ったり、データ自体に暗号化処理等を施したりして、平文で自由にデータへのアクセスが行われることがないようにする必要がある。一方で、このような認証処理や暗号化処理が厳重になるほど、利用者がデータ利用要求を発してから、実際に利用が出来るようになるまでに多くの処理が必要となり、結果としてデータの再生を円滑に行うことができない事態が生じる可能性がある。
【０００５】
例えば、特許文献１及び２には、利用目的のディジタルデータを暗号化する一方で、それを復号するための鍵及び復号した際の利用条件を、不正に取得，改竄などができないようにすることで、著作権を保護することが提案されている。また、特許文献３には、記憶装置とホスト装置との間で秘匿すべきデータを暗号化して入出力するときの耐タンパ性を向上させるために、ホスト装置から送られる複数の暗号入出力処理を複数の手順に分割して、並行して処理する記憶装置に関する技術が開示されている。
【０００６】
【特許文献１】ＷＯ０１/０１３３５８公報
【特許文献２】ＷＯ０１/０４３３３９公報
【特許文献３】特開２００４−３０２７０１公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記特許文献１及び２に開示された方法は、ディジタルデータを復号するための鍵と利用条件を２つの機器の間で転送する場合、処理の負荷が高い公開鍵の暗復号演算及び証明書の検証処理を必要とする。然るに、特許文献１及び２に開示された技術には、下記のような幾つかの問題点があることがわかった。また、特許文献３の技術も下記の課題について言及していない。
【０００８】
１つには、転送元が正しい機器であるか否かを転送先が認証することが考慮されておらず、それゆえ不正な機器から鍵や利用条件が転送先に送信された場合、それを記録してしまうので、不正アクセスに対して防御できない。
２つには、複数の鍵と利用条件を連続的に送信するような状況についてあまり考慮されておらず、それゆえこれらのデータを送信する度に、転送元と転送先の両機器で、負荷の高い公開鍵暗号演算を行わなければならない。
【０００９】
３つには、証明書で各機器の正当性を判別する場合、証明書と並んで、失効した証明書のリストがシステム全体として用いられるが、上記方法では、転送先の証明書失効リストしか更新できない。
４つには、２つの機器間で鍵や利用条件を転送する場合、認証処理と、鍵や利用条件の転送の方向が固定されており、逆向きの転送を行うためには、認証処理も逆方向で最初からやり直さなくてはならない。これでは、記録再生装置及び記憶装置の双方に大きな負荷を与える。
【００１０】
本発明の目的は、上記のような問題点を解決したコンテンツデータ管理システム、及びそのシステムにおける記録再生装置及び記憶装置を提供することにある。
【課題を解決するための手段】
【００１１】
本発明に係るコンテンツデータ管理システムは、コンテンツデータの復号化を管理するための制御情報を扱うコンテンツデータ管理システムにおいて、コンテンツデータを記録再生する第１の装置（例えば記録再生装置）と、コンテンツデータを記憶する第２の装置（例えば磁気ディスク装置）と、及び両装置間のデータ転送を制御するホスト処理部と、を有し、ホスト処理部の制御によって、両方の装置に対して、装置が持つデータの転送機能に関する問合せを行い、問合せの結果、両装置間のデータ転送に関して、制御情報の転送を第１の装置から第２の装置へ一方向に行なう第１転送モードか、又は制御情報の転送を両装置の間で双方向に行なう第２転送モードか、のいずれかの転送モードを設定し、第１及び第２の装置で相互に正当性の認証処理を行い、認証処理の結果、正当な場合に第１及び第２の装置で鍵データ（共有鍵データ）を共有し、この共有鍵データを用いて、第１又は第２の装置で制御情報を暗号化処理し、設定された第１又は第２の転送モードに従って、一方の装置で暗号化された制御情報を他方の装置へ転送し、制御情報を受信した第１の装置は、共有鍵データを用いて制御情報を復号化し、その復号化された制御情報を用いてコンテンツデータを復号処理するシステムである。
好ましい例では、第１の装置は、デジタルコンテンツを視聴できる機能を有する記録再生装置であり、第２の装置は、第１の装置に着脱可能な磁気ディスク装置であり、コンテンツ記憶部は磁気ディスク媒体であり、第１及び第２の保護記憶領域は耐タンパ性を持つメモリである。
また、好ましい例では、上記制御情報は、自身がどのような種類のモジュールに対して出力可能なものであるかを示すフォーマットと、それぞれに一意に割り当てられた識別子と、コンテンツデータの利用を制限するための条件を示す情報と、暗号化されたコンテンツデータを解くための鍵データと、関連するコンテンツデータを特定するための識別子を含む。
また、好ましくは、第１の転送モードにおける制御情報の転送において、第１及び第２の装置は、制御情報の処理に関連するトランザクションログを生成して、それぞれ第１及び第２の保護記憶領域に格納し、正当性の認証処理時に正常に処理が行なわれなかった場合、第１又は第２の装置は第１又は第２の保護記憶領域に記憶されたトランザクションログを参照して共有鍵データを生成し、第２の装置へ送る。
また、好ましくは、前記第２の転送モードにおける制御情報の転送において、第１の装置は、制御情報の処理に関連するトランザクションログを生成して、第１の保護記憶領域に格納し、制御情報の転送時に正常に処理が行なわれなかった場合、第１の装置は第１の保護記憶領域に記憶されたトランザクションログを参照して共有鍵データを生成し、第２の装置へ送る。
また、好ましくは、前記第２転送モードに設定された場合、前記正当性の認証処理において、第２の装置は、自身の公開鍵が含まれる証明書を第１の装置へ送信し、
第１の装置では、受信した証明書の正当性を検証して、一時的な共通鍵暗号化のための鍵である第１チャレンジ鍵を生成し、受信した公開鍵を用いて第１チャレンジ鍵を暗号化し、生成された暗号化データに自身の公開鍵を含む証明書を連結して、第２の装置に送信し、
第２の装置では、受信したデータを、自身の秘密鍵を用いて復号し、第１チャレンジ鍵を取得し、かつ、一時的な共通鍵暗号化のための鍵である第２チャレンジ鍵を生成し、第２チャレンジ鍵と自身に埋め込まれている公開鍵と連結して、受信した公開鍵で暗号化し、得られた暗号化データに対して、自身の証明書失効リストを連結し、連結したデータを受信した第１チャレンジ鍵で暗号化し、暗号化したデータを第１の装置へ送信し、
第１の装置は、受信したデータを第１チャレンジ鍵で復号し、証明書失効リスト中にあるリストの発行日情報と自身の証明書失効リストが持つ発効日情報とを比較し、その結果、受信した第２の装置の証明書失効リストの発行日が新しければ、第２の装置の証明書失効リストを自らのリストとして更新し、
かつ、復号化したデータから証明書失効リストを除いたデータを自身の秘密鍵で復号化し、更に、一時的な共通鍵暗号化のための鍵である０次第１セッション鍵を生成し、先に受信した第２の装置の公開鍵及び第２チャレンジ鍵で暗号化し、暗号化されたデータを第２の装置へ送信し、
第２の装置は、受信した暗号化データを第２チャレンジ鍵で復号し、この復号化データに第１の装置の証明書失効リストが含まれていた場合は、自らの証明書失効リストを受信した証明書失効リストにより更新し、かつ、証明書失効リスト以外の復号化データを自身に埋め込まれている秘密鍵で復号化し、０次第１セッション鍵を取得する。
【００１２】
本発明に係る記録再生装置は、取得されたコンテンツデータを記録再生する記録再生装置において、コンテンツデータを記憶する記憶装置と接続し、記憶装置との間でコンテンツデータを含む情報の転送を行なう接続部と、コンテンツデータを記録するための処理を行なう記録部と、少なくとも接続部を介して記憶装置から送られたコンテンツデータを再生するための処理を行なう再生部と、記録部又は再生部と、記憶装置との間における制御情報の転送を、記憶装置に対して一方向に行なう第１転送モードか、又は記憶装置との間で双方向に行なう第２転送モードか、のいずれかの転送モードを設定する第１の処理手段と、暗号化されたコンテンツデータを復号するための鍵データとコンテンツデータを復号するための条件を含む制御情報を生成する手段と、記憶装置の特性に関する情報を検証して認証を行い、認証処理の結果、記憶装置が正当な場合に、記憶装置との間で共有された鍵データ（共有鍵データ）を用いて、生成された制御情報を暗号化する手段と、と含む第２の処理手段と、を有し、暗号化された制御情報は、第１の処理手段の制御により設定された第１又は第２の転送モードに従って、接続部を介して記憶装置へ転送され、かつ、記憶装置から送られ受信した制御情報は、第２の処理手段で共通鍵データを用いて復号化され、復号化された制御情報を用いてコンテンツデータを復号処理して再生部で再生する記録再生装置である。
【００１３】
好ましい例では、取得されたコンテンツデータを記録再生する記録再生装置において、コンテンツデータを記憶する記憶装置を着脱自在に接続し、記憶装置との間でコンテンツデータを含む、種々の情報のやり取りを行なうインタフェースと、コンテンツデータを記録するための処理を行なう記録モジュールと、インタフェースを介して記憶装置から送られたコンテンツデータを再生するための処理を行なう再生モジュールと、少なくともコンテンツデータを暗号化するために使用される鍵データを保持する第１の保護記憶領域と、暗号化されたコンテンツデータを復号するための鍵データと、コンテンツデータを復号するための条件を含む制御情報を生成するホストセキュリティマネージャと、記憶装置との間で行なわれるデータ転送を制御するホスト処理部と、を有し、
ホスト処理部は、記録モジュール又は再生モジュール、及び記憶装置に対して、それらが持つデータの転送機能に関する問合せを行い、問合せの結果、記憶装置との間のデータ転送に関して、制御情報の転送を記憶装置に対して一方向に行なう第１転送モードか、又は制御情報の転送を記憶装置との間で双方向に行なう第２転送モードか、のいずれかの転送モードを設定し、
ホストセキュリティマネージャは、記憶装置の特性に関する情報を検証して認証を行い、認証処理の結果、正当な場合に鍵データ（共有鍵データ）を共有し、
第１の転送モードに設定された場合、ホストセキュリティマネージャは、生成された制御情報を、共有鍵データを用いて暗号化処理し、暗号化された制御情報をインタフェースを介して記憶装置へ転送し、
第２の転送モードに設定された場合、ホストセキュリティマネージャは、生成された制御情報を、共有鍵データを用いて暗号化処理し、暗号化された制御情報をインタフェースを介して記憶装置へ転送し、また記憶装置から転送された共有鍵データにより暗号化された制御情報を受信し、
かつ、再生モジュールは、共通鍵データを用いて、受信した制御情報を復号化し、復号化された制御情報を用いてコンテンツデータを復号処理する記録再生装置である。
【００１４】
また、本発明に係る磁気ディスク装置は、データを処理する他の装置に接続され、データを記憶することができる磁気ディスク装置であって、他の装置に着脱自在に接続され、他の装置との間でデータを含む情報のやり取りを行なう接続部と、接続部を介して他の装置から送られた、暗号化されたデータを記憶するディスク媒体と、少なくともデータを暗号化するために使用される鍵データ、及びデータを復号するための条件を含む制御情報を保持する第２の保護記憶領域と、接続部を介して他の装置との間でやり取りされる情報の転送制御を行なう制御手段と、を有し、
制御手段は、他の装置との間でお互いに正当性の認証を行い、正当な場合に、他の装置との間で所定の鍵データ（共有鍵データ）を共有し、第２の保護記憶領域内に保持された制御情報を、共有鍵データを用いて暗号化処理し、かつ、他の装置からの指示により設定された、他の装置から磁気ディスク装置へ一方向に制御情報を転送する第１転送モードか、又は他の装置との間で双方向に制御情報を転送する第２転送モードのいずれかの転送モードに従って、暗号化された制御情報を接続部を介して他の装置へ転送する磁気ディスク装置である。
好ましい例では、データの記録再生を行なう記録再生装置に接続され、データを記憶する磁気ディスク装置であって、記録再生装置に着脱自在に接続され、記録再生装置との間でデータを含む情報のやり取りを行なうインタフェースと、インタフェースを介して記録再生装置から取得されたデータを記憶するディスク媒体と、ディスク媒体に対するデータの書込み及び読出しを制御する制御部と、少なくともデータを暗号化するために使用される鍵データ、及びデータを復号するための条件を含む制御情報を保持する第２の保護記憶領域と、インタフェースに接続され、記録再生装置との間でやり取りされる情報の転送制御を行なう転送モジュールと、を有し、
転送モジュールは、
記録再生装置からの要求に応じて、記録再生装置との間における制御情報の転送に関して、記録再生装置から磁気ディスク装置へ一方向に行なう第１転送モードか、又は記録再生装置との間で双方向に行なう第２転送モードか、のいずれの転送モードが可能であるかを回答する手段と、記録再生装置からの要求に応じて、磁気ディスク装置の特性に関する情報（特性情報）を記録再生装置へ送信すると共に、記録再生装置から送られた特性情報を検証して認証し、正当な場合、記録再生装置との間で所定の鍵データ（共有鍵データ）を共有する手段と、を有し、
記録再生装置からの指示により第１又は第２の転送モードに設定された場合、転送モジュールは、記録再生装置からインタフェースを介して転送された、共有鍵データにより暗号化された制御情報を受信して、第２保護記憶領域に記憶し、
及び、第２の保護記憶領域内に保持された制御情報を、共有鍵データを用いて暗号化処理し、暗号化された制御情報をインタフェースを介して記録再生装置へ転送する。
【００１５】
また、本発明に係る記憶装置は、次のように把握され得る。すなわち、
データを処理する他の装置に接続され、データを記憶することができる記憶装置において、他の装置との間でデータを含む情報のやり取りを行なう接続部と、接続部を介して他の装置から送られた、暗号化されたデータを記憶する記憶部と、少なくともデータを暗号化するために使用される鍵データ、及びデータを復号するための条件を含む制御情報を保持する所定の記憶領域と、接続部を介して他の装置との間でやり取りされる情報の転送制御を行なう制御部を有し、制御部は、他の装置との間でお互いに正当性の認証を行い、正当な場合に、他の装置との間で所定の鍵データ（共有鍵データ）を共有し、所定の記憶領域に保持された制御情報を、共有鍵データを用いて暗号化処理し、かつ、選択的に設定される、他の装置から記憶装置へ一方向に制御情報を転送する第１転送モードか、又は他の装置との間で双方向に制御情報を転送する第２転送モードのいずれかの転送モードに従って、暗号化された制御情報を接続部を介して他の装置へ転送する記憶装置である。
【発明の効果】
【００１６】
本発明によれば、複数のデータを復号するための鍵及びデータの利用条件を含む制御情報を一方の装置から他方の装置へ転送する場合に、両装置の暗号演算に関する負荷を軽減する適切な方法を提供することができる。
また、正当な装置の間で当該制御情報を安全に転送できる。不正な装置へ制御情報を転送することは転送元の装置によって拒絶し、不正な装置から制御情報が送られた場合には、転送先の装置でその受信を拒絶することができる。
更に、当該制御情報を、一方の装置から他方の装置へ転送するシステムにおいて、転送先の装置が有する失効した証明書のリストの方が、転送元の装置が有するリストより新しかった場合、それらの装置間で相互認証処理を実行する間に、転送元のリストで、転送先のリストを更新できるようになる。
【発明を実施するための最良の形態】
【００１７】
本発明は、以下のような好ましい例において実施される。
前提として、保護が必要なデータは暗号化されること、及び、該データを復号するために必要な鍵データと、復号が許容される条件を１つにまとめられ、それは利用者が自由にアクセスすることができない記憶領域に記録される。この鍵データと、復号が許容される条件を関連付けたものを、以下の例ではユーセジパス（Usage Pass）と呼ぶ。
本発明は、Usage Passを一方のモジュールから他方のモジュールへ転送する場合の、さまざまな処理及びその処理系列について開示するものである。処理系列の種類は２種類ある。その１つは、Usage Passの転送方向が一意に決まるＵＴ（Unidirectional Transfer mode）モードであり、他の１つは双方向にUsage Passを転送することができるＢＴ（Bidirectional Transfer mode）モードである。好ましい例として、このUsage Passの特徴的な転送方法を、２つの機器、例えば記録再生装置と記憶装置の間の転送に適用した場合について述べる。
【００１８】
記録再生装置と記憶装置の間でUsage Pass転送を行なうためには、初めに、２つのモードのうち、いずれのモードでUsage Pass転送を実行するか、記録再生装置内の処理部（以下の例では、ホスト（Host）モジュールという）を選択し、それぞれの装置におけるUsage Pass送信あるいは受信処理を行うモジュールに、選択したモードを通知する処理を行う。以下では、ＵＴモードがUsage Pass送信あるいは受信処理を行うモジュールに設定された場合について、先ず説明する。
【００１９】
ＵＴモードが設定されると、Usage Passを最終的に受信するモジュールが、自身に埋め込まれているDevice Class証明書を、Usage Passを送信するモジュールへ送信する。Device Class証明書には、Device Class公開鍵が含まれる。尚、ＵＴモードでは、Usage Passを送信するモジュールを含む機器をPrimal Device、受信するモジュールを含む機器をInceptive Deviceと呼ぶ。その意味で、該Device Class証明書をInceptive Device Class証明書、該Device Class公開鍵をInceptive Device Class公開鍵と呼ぶ。
【００２０】
Primal Deviceでは、受信した証明書の正当性を検証し、検証の結果、受信した証明書の正当性が確認されると、一時的な共通鍵暗号化のための鍵であるPrimal Challenge鍵を生成する。続いて、受信したDevice Class公開鍵を用いてPrimal Challenge鍵を暗号化し、生成された暗号化データにPrimal Device Class公開鍵を含むPrimal Device Class証明書を連結し、Inceptive Deviceに送信する。
【００２１】
Inceptive Deviceでは、受信した該データを、自身のDevice Class秘密鍵を用いて復号し、Primal Challenge鍵を取得する。続いてInceptive Deviceは、一時的な共通鍵暗号化のための鍵である０次Inceptive セッション鍵を生成する。この鍵の生成を終えると、自身に埋め込まれているInceptive Device公開鍵と連結し、受信したPrimal Device Class鍵で暗号化する。更に、得られたデータに対し、自身に記録されている失効Device Classリスト（Inceptive RDCL）を連結し、受信したPrimal Challenge鍵で暗号化する。以上の処理を終了すると、得られたデータをPrimal Deviceへ送信する。
【００２２】
Primal Deviceは、受信したデータをPrimal Challenge鍵で復号し、その結果からInceptive RDCLを取り出す。RDCLには、該データの発行日情報が含まれているので、Inceptive RDCLの発行日情報と、自身に記録されているRDCL（Primal RDCL）の発行日情報とを比較する。その結果、Inceptive RDCLの発行日の方が新しければ、Primal RDCLをInceptive RDCLで上書きする。RDCLの発行日比較を終えると、残りのデータをPrimal Device秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である０次Primal セッション鍵を生成する。この鍵の生成を終えると、先に受信した０次Inceptive セッション鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Device公開鍵で暗号化する。暗号化を終えると、該データをInceptive Deviceへ送信する。
【００２３】
Inceptive Deviceは、受信したデータをInceptive Device秘密鍵で復号する。この復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLをPrimal RDCLで上書きする。続いて、残りのデータを０次Inceptive セッション鍵で復号し、０次Primal セッション鍵を得る。
以上が、ＵＴモードにおける認証処理である。これをUT Connection stageと呼ぶ。UT Connection stageを完了すると、０次Primal セッション鍵、０次Inceptive セッション鍵、Inceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。
【００２４】
認証処理を終えると、Usage Pass転送を実行することができる。ＵＴモードにおけるUsage Pass転送は、次のように行われる。尚、ＵＴモードにおけるUsage Pass転送は、Primal DeviceからInceptive Deviceへのみ行われる。
まず、Primal Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュールに準備する。続いて、ホストモジュールは目的のUsage Passを識別するための識別子（UPID）をInceptive Deviceへ送る。
【００２５】
Inceptive Deviceは、Usage Passを暗号化するためのn次Inceptive セッション鍵を生成し、UPIDと共に、Inceptive Transaction Logと呼ばれるログに記録する。ログには、転送処理段階（RP）も記録する。ログは、Usage Pass転送処理が正常に完了しなかった場合に、元の状態にUsage Passを復旧するために用いられるものである。n次Inceptive セッション鍵の生成を終えると、１つ前のUsage Pass転送時に生成したInceptive セッション鍵（n-１次Inceptive セッション鍵）と０次Primal セッション鍵で暗号化し、Primal Deviceへ送信する。
【００２６】
Primal Deviceは、受信したデータを０次Primal セッション鍵及びn-１次Inceptive セッション鍵で復号する。そして、転送対象Usage PassのUPID、Inceptive Device Class証明書に含まれる一部のパラメータ、Connection stageにおいて受信したInceptive Device公開鍵、復号結果得られたn次Inceptive セッション鍵、転送処理段階（SP）、転送対象Usage Passに含まれるデータの復号可能条件、Usage Passが記録されていたアドレスを、Primal Transaction Logへ記録する。
続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成後、該Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、n次Inceptive セッション鍵と共有Inceptive Device鍵で暗号化する。暗号化を終えると、Primal Transaction Logにおける転送処理段階要素をSCに更新し、そのデータをInceptive Deviceへ送信する。
【００２７】
Inceptive Deviceは、受信したデータを共有Inceptive Device鍵及び０次Inceptive セッション鍵で復号する。そして、Inceptive Transaction Logにおける転送処理段階要素をRCに更新し、またUsage Passの記録先アドレスをInceptive Transaction Logに記録し、該データをUsage Pass記憶領域へ記録する。
以上が、ＵＴモードにおけるUsage Pass転送処理である。これをUT Transfer stageと呼ぶ。以上に説明したように、ＵＴモードではUsage Passの転送方向は、Primal DeviceからInceptive Deviceに固定されている。
【００２８】
Usage Passの転送処理を実行中に、記録再生装置に電源供給停止等の異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。
異常時には、UT Connection stageにおいて共有された０次Primal セッション鍵、０次Inceptive セッション鍵、共有Device鍵は、記録再生装置及び記憶装置から失われてしまうので、新たにこれらの鍵を共有しなければならない。ただし、UT Connection stageを実行する必要はなく、以下に記す処理を実行すれば良い。
【００２９】
初めに、Hostが、復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。Primal Deviceでは、UPIDを用いて、Primal Transaction Logを検索する。その結果、UPIDを含むPrimal Transaction Logが見つかると、新しい０次Primal セッション鍵を生成する。そして、生成した該セッション鍵を、見つけられたPrimal Transaction Logに記録されていたセッション鍵及びInceptive Device公開鍵で暗号化し、Inceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを復号し、新しい０次Primal セッション鍵及び共有Devce鍵を得る。
以上が、ＵＴモードにおける再認証処理である。これを、UT Reconnection stageと呼ぶ。UT Reconnection stageを完了すると、新しい０次Primal セッション鍵、Inceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Inceptive Device鍵が共有される。
【００３０】
UT Reconnection stageを終えると、Primal Deviceにおいて、以下のようにしてUsage Passの復旧処理が行われる。
ホストモジュールが、復旧対象のUsage PassのUPIDを、Inceptive Deviceに送信する。Inceptive Deviceでは、UPIDを用いて、Inceptive Transaction Logを検索する。その結果、UPIDを含むInceptive Transaction Logが見つかると、Transaction Logに記録されている処理段階情報とUsage Passの存在状態情報を連結し、Primal Deviceへ送信する。この時送信されるデータには、データ、０次Primal セッション鍵、Inceptive Transaction Logに記録されていたInceptive セッション鍵から計算されたHash値も連結される。
【００３１】
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないことを確認する。この検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、Logに記録されている転送前の復号可能条件を、現在存在しているUsage Passに上書きする。
以上が、ＵＴモードにおけるUsage Passの復旧処理である。これを、UT Recovery stageと呼ぶ。このstageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
【００３２】
次に、ＢＴモードがUsage Pass送信あるいは受信処理を行うモジュールに設定された場合について、説明する。
ＢＴモードでは、Usage Passを転送する方向が固定されておらず、Primal DeviceとInceptive Deviceの双方が、Usage Passの送受信を実行できる。ＢＴモードの下で、記録再生装置にあって相互認証処理やUsage Passの送受信処理を実行するモジュールをPrimal Device、記憶装置にあって相互認証処理やUsage Passの送受信処理を実行するモジュールをInceptive Deviceと呼ぶ。Device Class証明書をInceptive Device Class証明書、Device Class公開鍵をInceptive Device Class公開鍵と呼ぶ。
【００３３】
Primal Deviceでは、受信した証明書の正当性を検証し、検証の結果受信した証明書の正当性が確認されると、一時的な共通鍵暗号化のための鍵であるPrimal Challenge鍵を生成する。続いて、受信したDevice Class公開鍵を用いてPrimal Challenge鍵を暗号化し、生成された暗号化データにPrimal Device Class公開鍵を含むPrimal Device Class証明書を連結し、Inceptive Deviceに送信する。
【００３４】
Inceptive Deviceでは、受信した該データを、自身のDevice Class秘密鍵を用いて復号し、Primal Challenge鍵を取得する。
続いてInceptive Deviceは、一時的な共通鍵暗号化のための鍵であるInceptive セッション鍵を生成する。この鍵の生成を終えると、自身に埋め込まれているInceptive Device公開鍵と連結し、受信したPrimal Device Class鍵で暗号化する。更に、得られたデータ（即ち、Primal Device Class鍵で暗号化されたデータ）に対し、自身に記録されている失効Device Classリスト（Inceptive RDCL）を連結し、受信したPrimal Challenge鍵で暗号化する。以上の処理を終了すると、得られたデータをPrimal Deviceへ送信する。
【００３５】
Primal Deviceは、受信したデータ（即ち、暗号化されたデータ）をPrimal Challenge鍵で復号し、その結果からInceptive RDCLを取り出す。RDCLには、データの発行日情報が含まれているので、Inceptive RDCLの発行日情報と、自身に記録されているRDCL（Primal RDCL）の発行日情報とを比較する。その結果、Inceptive RDCLの発行日の方が新しければ、Primal RDCLをInceptive RDCLで上書きする。RDCLの発行日比較を終えると、残りのデータをPrimal Device秘密鍵で復号する。続いて、一時的な共通鍵暗号化のための鍵である０次Primal セッション鍵を生成する。該鍵の生成を終えると、先に受信したInceptive Device公開鍵で暗号化する。ここで、先に行ったRDCLの発行日情報の比較結果において、Primal RDCLの発行日の方が新しいことが判明した場合は、先に暗号化したデータに、Primal RDCLを連結する。得られたデータは、先に受信したInceptive Challenge鍵で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する。
【００３６】
Inceptive Deviceは、受信したデータをInceptive Challenge鍵で復号する。この復号結果にPrimal RDCLが含まれていた場合は、Inceptive RDCLをPrimal RDCLで上書きする。続いて、残りのデータをPrimal Device公開鍵で復号し、０次Primal セッション鍵を得る。
Primal Deviceは、受信したデータをPrimal Device秘密鍵及び０次Primal セッション鍵で復号し、０次Inceptive セッション鍵を得る。続いて、Inceptive Device公開鍵、０次Inceptive セッション鍵、０次Primal セッション鍵、Inceptive Device Class証明書に含まれる一部のパラメータを、Primal Connection Logに記録する。
以上が、ＢＴモードにおける認証処理である。これをBT Connection stageと呼ぶ。BT Connection stageを完了すると、０次Primal セッション鍵、０次Inceptive セッション鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Primal Device鍵、及びInceptive Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる共有Inceptive Device鍵が共有される。
【００３７】
認証処理を終えると、Usage Pass転送を実行することができる。初めに、Primal DeviceからInceptive DeviceへのUsage Pass転送について説明する。
まず、Primal Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュールに準備する。
続いて、Inceptive Deviceは、Usage Passを暗号化するためのn次Inceptive セッション鍵を生成する。この鍵の生成を終えると、１つ前のPrimal DeviceからInceptive DeviceへのUsage Pass転送時に生成したInceptive セッション鍵（n-１次Inceptive セッション鍵）と、その時点で最新のPrimal セッション鍵で暗号化し、Primal Deviceへ送信する。
【００３８】
Primal Deviceは、受信したデータをその時点で最新のPrimal セッション鍵及びn-１次Inceptive セッション鍵で復号する。そして、転送対象Usage PassのUPID、転送における自身の役割（転送元）、送信予定のUsage Passを、Transaction Logへ記録する。尚、ＢＴモードでは、Transaction Logの記録は、Primal Deviceのみが行う。
続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Inceptive DeviceにおけるUsage Passの記録先アドレスをTransaction Logに記録した後、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、n次Inceptive セッション鍵と共有Inceptive Device鍵で暗号化する。暗号化を終えると、データをInceptive Deviceへ送信する。
Inceptive Deviceは、受信したデータを共有Inceptive Device鍵及びn次Inceptive セッション鍵で復号する。そして、該データをInceptive Device内のUsage Pass記憶領域へ記録する。
以上が、ＢＴモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理である。これをBT PI Transfer stageと呼ぶ。
【００３９】
初めに、Primal DeviceからInceptive DeviceへのUsage Pass転送について説明する。
まず、Inceptive Deviceにおいて、目的のUsage Passを、Usage Pass転送用モジュールに準備する。
続いてInceptive Deviceは、Usage Passに対し、データ暗号鍵部分を０で置き換え、Usage Passの状態情報を連結した（該データをMasked Usage Passと呼ぶ）後、データに最新のPrimal セッション鍵とInceptive セッション鍵連結してHash値計算する。そして、得られたHash値を、Masked Usage Passに連結し、Primal Deviceへ送信する。
【００４０】
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないことを確認する。この検証を終えると、受信したUsage PassのUPID、データの復号可能条件、Inceptive DeviceにおいてUsage Passが記録されているアドレスを、Transaction Logに記録する。続いて、m次Primal セッション鍵を生成し、１つ前のInceptive DeviceからPrimal DeviceへのUsage Pass転送で生成されたPrimal セッション鍵（m-１次Primal セッション鍵）と、その時点で最新のInceptive セッション鍵で暗号化し、Inceptive Deviceへ送信する。
【００４１】
Inceptive Deviceは、受信したデータをその時点で最新のInceptive セッション鍵及びm-１次Primal セッション鍵で復号する。続いて、Usage Pass送信用モジュールに準備されたUsage Passから、実際に送信するUsage Passを生成する。そして、Usage Passに利用目的（複製、移動、再生のいずれか）を示すパラメータやChecksumを連結し、m次Inceptive セッション鍵と共有Primal Device鍵で暗号化する。該暗号化を終えると、該データをPrimal Deviceへ送信する。
Primal Deviceは、受信したデータを共有Primal Device鍵及びm次Primal セッション鍵で復号する。
以上が、ＢＴモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理である。これをBT IP Transfer stageと呼ぶ。
【００４２】
ＵＴモードと同様に、記録再生装置に異常が発生して、Usage Pass転送元及びUsage Pass転送先双方からUsage Passが失われてしまった場合、以下の処理を行うことで、Usage Passを復旧することができる。ＢＴモードによる再認証処理は、ＵＴモードとは若干異なり、過去にBT PI Transfer stageやBT IP Transfer stageが実行されている必要はなく、BT Connection stageのみが完了していれば良い。
異常時には、BT Connection stageにおいて共有された０次Primal セッション鍵、０次Inceptive セッション鍵、共有Primal Device鍵、共有Inceptive Device鍵は、記録再生装置及び記憶装置から失われてしまうので、新たにこれらの鍵を共有しなければならない。ただし、BT Connection stageを実行する必要はなく、以下に記す処理を実行すれば良い。
【００４３】
初めに、Primal Deviceにおいて、新たな０次Primal セッション鍵を生成し、Primal Connection Logに記録されているInceptive セッション鍵とInceptive Device公開鍵で、生成した該鍵を暗号化する。そして、得られたデータをInceptive Deviceへ送信する。
【００４４】
Inceptive Deviceは、受信したデータをInceptive Connection Logに記録されているInceptive Device秘密鍵及びInceptive セッション鍵で復号する。そして、新たな０次Inceptive セッション鍵を生成し、Inceptive Connection Logに記録されているPrimal セッション鍵とPrimal Device公開鍵で、生成した該鍵を暗号化する。続いて、受信した０次Primal セッション鍵及び生成した０次Inceptive セッション鍵を、Inceptive Connection Logに上書き記録し、先に暗号化したデータを、Primal Deviceへ送信する。
【００４５】
Primal Deviceは、受信したデータをPrimal Device秘密鍵及びInceptive Connection Logに記録されている０次Primal セッション鍵で復号する。そして、得られた新しい０次Inceptive セッション鍵と、先に生成した０次Primal セッション鍵を、Primal Connection Logに上書き記録する。
以上が、ＢＴモードにおける再認証処理である。これを、BT Reconnection stageと呼ぶ。BT Reconnection stageを完了すると、新しい０次Primal セッション鍵、０次Inceptive セッション鍵、Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Primal Device鍵Primal Device公開鍵による暗号化と同秘密鍵による復号化の過程で得られる新しい共有Inceptive Device鍵が共有される。
【００４６】
BT Connection stageやBT Reconnection stageが完了すると、過去に転送処理を完了できなかったUsage Passについて、以下に述べる方法により、転送処理の前の状態に復旧することができる。初めにBT PI Transfer stageに対する復旧処理について、続いてBT IP Transfer stageに対する復旧処理について説明する。
BT PI Transfer stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにHostが復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。
【００４７】
Primal Deviceは、このUPIDを用いて、Primal Transaction Logを検索する。その結果、該UPIDを含むPrimal Transaction Logが見つかると、Logに記録されているInceptive DeviceにおけるUsage Passの記録先アドレス（受信したUsage Passを記録する予定だったアドレス）をInceptive Deviceへ送信する。
Inceptive Deviceは、受信したアドレスでアクセスされるUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べる。そして、その結果をUsage Pass Statusに設定する。次に、UPID、検索されたUsage Passの復号可能条件、生成されたUsage Pass Status、Usage Passの記録先アドレスを連結し、Primal Deviceへ送信する。この時送信されるデータには、該データ、m次Primal セッション鍵、n次Inceptive セッション鍵から計算されたHash値も連結される。
【００４８】
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが存在しないことを確認する。検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、該Logに記録されている転送前の復号可能条件を、現在Usage Pass送信用モジュールに用意されているUsage Passに上書きする。
以上が、ＢＴモードにおけるBT PI Transfer stageに対するUsage Passの復旧処理である。これを、BT PI Recovery stageと呼ぶ。このstageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
【００４９】
次に、BT IP Transfer stageに対するUsage Passの復旧処理について説明する。
BT PI Transfer stageで転送されたUsage Passを転送処理実行前の状態に戻す処理を行うにあたり、まず初めにホストモジュールが復旧対象のUsage PassのUPIDを、Primal Deviceに送信する。
Primal Deviceは、このUPIDを用いて、Primal Transaction Logを検索する。その結果、このUPIDを含むPrimal Transaction Logが見つかると、Logに記録されているInceptive DeviceにおけるUsage Passの記録先アドレス（転送対象のUsage Passが元来記録されていた領域を指し示すアドレス）をInceptive Deviceへ送信する。
【００５０】
Inceptive Deviceは、受信したアドレスでアクセスされるUsage Pass記憶領域へアクセスし、Usage Passの記録状態を調べる。そして、その結果をUsage Pass Statusに設定する。次に、UPID、検索されたUsage Passの復号可能条件、生成されたUsage Pass Status、Usage Passの記録先アドレスを連結し、Primal Deviceへ送信する。この時送信されるデータには、該データ、m次Primal セッション鍵、n-１次Inceptive セッション鍵から計算されたHash値も連結される。尚、この時点で共有されている最新のInceptive セッション鍵は、n-１次のものとする。
【００５１】
Primal Deviceは、受信したHash値を検証し、受信したデータに改竄が行われていないこと、及びInceptive Deviceに先に転送したUsage Passが、過去の転送（送信）処理によって、変化してしまったかどうかを確認する。
上記検証に並行して、Inceptive Deviceでは、n次Inceptive セッション鍵の生成を行う。この鍵の生成を終えると、n-１次Inceptive セッション鍵及びm次Primal セッション鍵で暗号化し、Primal Deviceへ送信する。
【００５２】
Primal Deviceでは、データを受信後、先に述べた検証処理によって、Usage Passが送信処理を実行することによって変化してしまっていることが確認されると、以下に記すUsage Passの復旧処理を実行する。まず、受信したデータを、m次Primal セッション鍵及びn-１次Inceptive セッション鍵で復号する。続いて、先に検索の結果見つけられたTransaction Logに記録されている復号可能条件を、Usage PassのUPIDに連結し、n次Inceptive セッション鍵及び共有Inceptive Device鍵で暗号化する。暗号化を終えると、そのデータをInceptive Deviceへ送信する。
【００５３】
Inceptive Deviceは、受信したデータを、共有Inceptive Device鍵及びn次Inceptive セッション鍵で復号する。そして、復号結果に含まれるUPIDが、復旧対象Usage PassのUPIDと一致しているか確認する。UPIDの一致が確認されると、復号結果に含まれる復号可能条件を、Inceptive Device中に存在するUsage Passに上書き記録する。
以上が、ＢＴモードにおけるBT IP Transfer stageに対するUsage Passの復旧処理である。これを、BT IP Recovery stageと呼ぶ。このstageを完了すると、Inceptive Deviceには、送信を行う前のUsage Passが存在するようになる。
検証を終えると、受信したUPIDを含むPrimal Transaction Logを検索する。Logが見出されると、そのLogに記録されている転送前の復号可能条件を、現在Usage Pass送信用モジュールに用意されているUsage Passに上書きする。
以上が、ＢＴモードにおけるBT PI Transfer stageに対するUsage Passの復旧処理である。これを、BT PI Recovery stageと呼ぶ。該stageを完了すると、Primal Deviceには、送信を行う前のUsage Passが存在するようになる。
【００５４】
以下、図面を参照して本発明の実施例について説明する。
システム構成
まず、図１及び図２を用いて、一実施例におけるデータ記録再生装置及びそれに接続可能な記憶装置を含むシステムの全体構成について説明する。
この実施例は、放送されたディジタル映像データや、配信サーバ（Distribution Server）から配信されたディジタルデータ、また他の機器と接続したディジタル信号線を介して送信されたディジタルデータを脱着可能な記憶装置に記録し、また記憶装置に記憶されたデジタルデータを、記録再生装置のディスプレイ装置やスピーカーなどで再生する記録再生システムに適用した例について説明する。以下では、ディジタルデータ記録再生装置を単に記録再生装置といい、記録再生装置が受信する映像や音楽、テキストなどのディジタルデータを、コンテンツデータという。ここで、コンテンツデータを記録する脱着可能な記憶装置は、例えば、磁気ディスク装置や半導体メモリデバイスなどであり、何れも本発明に特徴的な制御機能を有する。以下では、記憶装置として磁気ディスク装置を例に説明するが、これに限るものではない、以下に説明するような本発明に特徴的な機能を有するものであれば、磁気ディスク装置以外の他の周知な記憶装置にも適用できる。
【００５５】
著作権の保護が求められるコンテンツデータは、放送波を介してアンテナ１３１で受信したり、配信サーバ１５０から配信されたものをネットワークインタフェース （Network Interface）１００を介して受信することによって、記録再生装置１１２に取り込まれる。配信されるコンテンツデータは、放送波発信元１３０や配信サーバ１５０において、所定の暗号方式により暗号化されている。その暗号方式は、それぞれのコンテンツ保護仕様によって、独自に規定されていてよい。その際、コンテンツデータを復号するための鍵データ（以下ではこれをコンテンツ鍵と呼ぶ）と、コンテンツデータの利用条件も、別途、記録再生装置１１２に送信される。これらのコンテンツデータを復号するための情報を、以下ではコンテンツデータの復号制御情報と呼ぶ。この復号制御情報は、コンテンツデータの送信元と同一の送信元から送信される場合もあるし、他の送信元から送信される場合もある。
【００５６】
記録再生装置１１２は、脱着可能な記憶装置、例えば磁気ディスク装置１２５、１２６を接続することができる構成を有する。磁気ディスク装置１２５及び１２６には、放送波に乗って送信されたり、配信サーバ １５０から送信されたりした暗号化されたコンテンツデータ及びコンテンツデータの復号制御情報が、記録モジュール（Recording Module）１０２及び保護情報転送モジュール（Protected Information Transmit Module）１０４を介して記録される。また、再生モジュール（Playback Module）１０３には、脱着可能な磁気ディスク装置１２５や１２６から、暗号化されたコンテンツデータや、コンテンツデータの復号制御情報が、保護情報転送モジュール１０４を介して送信される。コンテンツデータの復号及び再生は、記録再生装置１１２内の再生モジュール１０３において行われる。
【００５７】
ところで、コンテンツデータの不正利用を防止するためには、復号制御情報に含まれるコンテンツ鍵が不正に取り出されたり、利用条件が不正に複製されたり、書き換えられたりすることがないようにする必要がある。そのためには、記録再生装置１１２や脱着可能な磁気ディスク装置１２５及び１２６内において復号制御情報の送受信を行ったり、情報を記録したり読み出したりする部分は、対タンパ性を持つように実装することが重要である。そのような部分は、記録再生装置１１２ではホストセキュリティマネージャ（Host Security Manager）１１１であり、磁気ディスク装置においては、ストレージセキュリティマネージャ（Storage Security Manager）２２５である。尚、ホストセキュリティマネージャ １１１内の保護情報領域（Protected Information Storage）１０１の役割や、ストレージセキュリティマネージャ ２２５内のUsage Pass転送モジュール（Usage Pass Transfer Module）２２１、制限記憶コントローラ（制限記憶部 Controller）２２２、制限記憶部（Qualified Storage）２２３の具体的な役割については、後に説明する。本発明に係る実施例では、ホストセキュリティマネージャ（Host Security Manger）１１２及びストレージセキュリティマネージャ２２５内にあるモジュール間で、復号制御情報を送受信し合うための転送プロトコルに関するものである。尚、ここで、記録再生装置１１２及び磁気ディスク装置１２５、１２６における各モジュール及びセキュリティマネージャ等の機能の実現手段としてはハードウェア又はソフトウェア（プログラム）の何れによって構成されてもよい。
【００５８】
一方で、記録再生装置１１２の中で、ネットワークとの間のネットワークインタフェース１００や、入力デバイスとの間のインタフェースブリッジ部１０５、磁気ディスク装置との間のインタフェース１０６及び１０７、及びこれらを制御するプロセッサ（ＰＵ）１０８などは、全体として、システム内部を流れるデータの処理や受け渡しを制御する機能を有する。その意味で、以下ではこれらをまとめてホストモジュール（Host Modules）１１０と呼ぶ。
【００５９】
モジュール間での相互認証とUsage Pass転送方式の概略
放送波に乗せられて送信されるコンテンツデータや、他の媒体に記録されているコンテンツデータは、一般的には独自に規定された方式で暗号化されている。また、データには、その復号制御情報も含まれていることが多い。これらのデータを、アンテナ１３１やディジタル信号線１３２を介して記録再生装置１１２が取り込む場合、記録モジュール１０２は、規定された方式に従ってコンテンツデータを復号し、また復号制御情報を取り出す。取り出された復号制御情報は、本実施例において定める特定の形式を持った１つのデータにまとめられる。これを、以下ではUsage Passと呼ぶ。Usage Passの具体的な構造については、後に図４を用いて説明する。
【００６０】
記録モジュール １０２はUsage Passを生成すると、それを磁気ディスク装置１２５あるいは１２６に対して送信する。ただし、本送信が完了するためには、それに先立って、記録モジュール１０２もしくは保護情報転送モジュール１０４とUsage Pass転送モジュール２２１の間では、相互認証が完了しなければならない。認証処理が完了すると、いくつかの鍵データが共有される。そして、転送対象のUsage Passは、共有された鍵を用いて、暗号化された後、記録モジュール１０２からUsage Pass転送モジュール２２１に対して送信される。
【００６１】
本発明は、鍵を共有するまでの認証処理方法と、認証処理によって共有された鍵を用いてUsage Passを暗号化し、転送する処理方法に関するものである。その処理方法は、２種類ある。その１つは、２つのモジュール間で相互認証が終了すると、Usage Passの転送方向が一意に確定してしまう方法であり、他の１つは双方向にUsage Passを転送することができる方法である。以下では、前者による相互認証及びUsage Pass転送方式を単一方向転送モード（Unidirectional Transfer mode）（略してＵＴモード）と呼び、後者による相互認証及びUsage Pass転送方式を双方向転送モード（Bidirectional Transfer mode）（略してＢＴモード）と呼ぶ。これらのモードを総称して、制限アクセス（Qualified Access）モードと呼ぶ。モジュール間でUsage Passを転送する際、いずれのモードで相互認証及びUsage Pass転送を行うかは、記録再生装置を起動する際、ホストモジュール（Host Module）１１０が決定する。
【００６２】
磁気ディスク装置では、Usage Pass転送モジュール ２２１がUsage Passを受信すると、それを制限記憶コントローラ２２２へ送信する。制限記憶コントローラは、制限記憶部２２３を制御するモジュールである。Usage Pass本体は、最終的には制限記憶部２２３に記録される。尚、配信サーバ１５０が磁気ディスク装置へUsage Passを送信する場合や、ある磁気ディスク装置から他の磁気ディスク装置へUsage Passを転送する場合は、Usage Passの転送元となるモジュールが、転送先となる磁気ディスク装置内のUsage Pass転送モジュールに対して、本発明で定める方式に従って、直接Usage Passを送信しても良い。この場合、記録再生装置１１２内のネットワークインタフェース１００や記録モジュール１０２は、データの一方から他方のモジュールへの転送を制御するたけで、相互認証処理やUsage Passの暗号化には直接関係しない。
【００６３】
次に、図２を参照して、磁気ディスク装置の構成について説明する。
磁気ディスク装置には、インタフェース部２２０を介してデータが入出力される。Usage Passのような保護が必要なデータ以外のデータが外部から入力される場合、コントローラ２３０を介して、ヘッド部２０２から磁気ディスク円盤２００上に記録される。暗号化されたコンテンツデータも、このフローに従って、磁気ディスク円盤２００上に記録される。読み出す場合は、前述を逆にデータが流れる。コントローラ２００は、プロセッサ（ＰＵ）２３１からも制御される。Usage Pass転送モジュール２２１や制限記憶コントローラ２２２なども、プロセッサ２３１によって制御される。図２では、制限記憶部２２３は磁気ディスク円盤２００とは別に設けられているが、暗号化されたコンテンツデータの読み出しと書き込みとは異なる特殊なアクセス方法でのみアクセスが許容されていて、また本装置を分解等し内部のデータを直接読み出す等を行うことが不可能な構成になっていれば、制限記憶部は磁気ディスク円盤２００上に設けても良い。
【００６４】
システムの鍵およびデータの構成
図３は、図１及び図２に示した機器において、記録モジュール１０２、再生モジュール１０３、及びUsage Pass転送モジュール２２１の間でUsage Pass転送を実行する際、それを暗号化するために用いられる鍵データ、及び配信するデータ等の一覧を示すものである。
通常、鍵データＸが対称暗号用の鍵データである場合は、対象のデータは鍵データＸを用いて暗号化されており、その復号も同一の鍵データＸを用いて行われる。一方、鍵データＸが非対称暗号用の秘密鍵あるいは公開鍵であった場合は、暗号化対象のデータは、Ｘとは異なるこれらに対応する公開鍵あるいは秘密鍵Yを用いて暗号化されている。Ｙを用いて暗号化されたデータは、Ｘを用いて復号される。以下では、非対称暗号用公開鍵データを公開鍵、非対称暗号用秘密鍵データを秘密鍵、対称暗号用鍵データを共通鍵と略す。
データに電子署名が付けられている場合、データを一部に含むデータ集合のハッシュ値が、公開鍵Ｘに対応する秘密鍵Ｙで暗号化されていることを意味する。
尚、本明細書中でK_xのように表記されているものは、全ての図ではxは添え字として表現されている。
【００６５】
コンテンツデータの暗号化、復号及び再生処理、Usage Passの暗号化及び復号化、記録モジュール １０２、再生モジュール１０３、磁気ディスク装置１２５及び１２６、配信サーバ１５０の認証に関わる鍵として、以下のものがある。
コンテンツデータを暗号化および復号するための鍵は、コンテンツ鍵K_cである。配信サーバ１５０、記録モジュール１０２、再生モジュール１０３、Usage Pass転送モジュール ２２１には、それぞれ個別に互いに認証を行うための電子署名付き公開鍵KP_dcがそれぞれ割り当てられる。ただし、ホストセキュリティマネージャ １１１を全体として１つの対タンパ性を持つ機能単位として実装する場合、ホストセキュリティマネージャ １１１に対して１つのKP_dcを割り当てても良い。
【００６６】
公開鍵KP_dcにより暗号化されたデータは、これに対応する秘密鍵K_dcによって復号可能である。これらの秘密鍵データは、配信サーバ１５０、記録モジュール１０２、Usage Pass転送モジュール２２１、再生モジュール１０３について、それぞれのある有限個に対して、１つ割り当てられる。有限個という意味は、１つでも複数個でも良いことを意味する。KP_dc及びK_dcを共有する単位をClassと呼ぶ。１つのClassに対しては、Usage Passを転送したり、記録したりする部分が、実装する際に満たさなければならない安全性のレベルや、１つのUsage Pass転送方式が規定される。つまり、あるClassに属する複数のモジュールは、全てがそのClassで規定された安全性のレベルを満たす形で実装されており、また１つの共通した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秘密鍵は、全てのデバイスに異なったものが埋め込まれる。
尚、公開鍵による暗号化の過程では、暗号化に用いられる公開鍵を元にして、１つの共通鍵が生成される。これは、*KP_dのように表される。同様に、秘密鍵による復号化の過程では、復号に用いられる秘密鍵を元にして、１つの共通鍵が生成される。これは、*K_dのように表される。*KP_dと*K_dは、実際には同一の値であり、*KP_dで暗号化されたデータは、*K_dで復号することができる。これらの共通鍵を、それぞれ共有Device公開鍵及び共有Device秘密鍵と呼ぶ。これらの鍵の生成方法については、後に公開鍵暗号化方法に関する説明をする際、更に詳細に説明する。
【００６８】
さらに、図１に示したシステムにおいて、使用される鍵等として以下のものがある。異なる２つのデバイス間でUsage Pass転送を行う度に、Usage Passを暗号化するために、主にUsage Passの転送先において生成される共通鍵K_sn（n ≧０）、及びデバイス間で相互認証処理の最終段階において両デバイスで共有されるK_s０を暗号化するために生成される共通鍵K_chである。K_ch及びK_s０は、デバイス間の相互認証処理において共有される鍵で、Usage Pass転送の際にそれを暗号化するためには利用されない。一方K_sn（n ≧ １）については、Usage Pass転送を実行する度に、必ずK_snからK_sn+１へ更新されてから利用される。以後、K_chをChallenge鍵、K_sn（n ≧ ０）をセッション（Session）鍵と呼ぶ。特に、nが０の場合のセッション鍵を、０次のセッション鍵と呼ぶ。
【００６９】
各鍵に対しては、[P]もしくは[I]の添え字が与えられる。これは、鍵が、Primal Device及びInceptive Deviceのいずれで生成された（あるいは埋め込まれた）か、を示すものである。ここでPrimal Deviceとは、あるデバイスが他のデバイスとの間で相互認証を行う場合に、相手となるデバイスから送信されたDevice Class証明書の検証を最初の処理で行うもののことである。一方、Inceptive Deviceとは、同様の場合に、自身のDevice Class証明書を相手となるデバイスに送信することを最初の処理で行うもののことである。
【００７０】
以上に説明した鍵を用いて行う暗号化をE(X, Y)と表す。これは、データＹを、鍵データＸを用いて暗号化することを表す。同様に復号化を、D(X, Y)と表す。これは、データＹを、鍵データＸを用いて復号することを表す。また、H(X)はデータXのハッシュ値を、X || YはデータXとデータYを連結することを表す。これらの表記法は、ＵＴモード、ＢＴモードいずれの場合にも全て共通のものである。
尚、ＵＴモードではUsage Passの転送方向が一意に確定してしまうと以前に述べたが、その方向は常にPrimal DeviceからInceptive Deviceである。従ってＵＴモードでは、記録モジュール１０２は常にPrimal Deviceとなり、再生モジュール １０３は常にInceptive Deviceとなる。一方、磁気ディスク装置は、記録モジュールから送信されたUsage Passを記録する場合はInceptive Deviceとなり、コンテンツデータの復号再生などを目的に自身からUsage Passを再生モジュールへ送信する場合は、Primal Deviceとなる。
【００７１】
これに対し、ＢＴモードでは、ホストセキュリティマネージャを有する装置が常にPrimal Deviceとなり、磁気ディスク装置は常にInceptive Deviceとなるが、Usage Passの転送は、Primal DeviceからInceptive DeviceへもInceptive DeviceからPrimal Deviceへも可能である。
【００７２】
Usage Passの構成
Usage Passの構造について、図４を用いて説明する。
Usage Passには、自身がどのような種類のモジュールに出力可能なものであるかを示すUsage Pass Format４００、それぞれに一意に割り当てられた識別子ＵＰＩＤ４０１、対象コンテンツデータの利用を制限するための条件４０２及び４０４、暗号化されたコンテンツデータを解くための鍵データK_c ４０３、対応するコンテンツデータを特定するための識別子ＣＩＤ４０５、コンテンツの著作権情報４０６が含まれる。対象コンテンツデータの利用を制限するための条件には、Usage Passの転送元で内容を解釈しその出力を制御するための制御情報UR_s ４０２０（Usage Passの転送元には、通常記録モジュールや磁気ディスク装置がなりうる）と、再生モジュール １０３がUsage Pass及びコンテンツデータを受信後、モジュールにおけるコンテンツデータの復号処理を制御するための制限情報UR_p ４０４０とがある。UR_s ４０２０には、Usage Passが複製された場合の世代情報を表すGeneration Count、自身からUsage Passの複製可能な回数を表すCopy Count、自身のUsage Passを使ってコンテンツデータの復号可能な回数を表すPlay Countなどが含まれる。
【００７３】
ＵＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成
図５を用いて、ＵＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュール２２１の構成について説明する。
Usage Pass転送モジュール５３０の中には、他のデバイスとの間で相互認証を行う場合に、自身がPrimal Deviceとなって必要な処理を行うための機能を持ったモジュール５００、自身がPrimal DeviceとなってUsage Passの転送を行うための機能を持ったモジュール５０１、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール５０２、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール５０３、利用者の意思による書き換えが行えないような静的な記憶領域５０４、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール５０５、及び制限記憶コントローラ２２２へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer ５１０が設けられている。認証用モジュール ５００及び５０２、Usage Pass暗号化及び送信用モジュール ５０１、Usage Pass受信及び復号化モジュール５０３、Usage Pass復旧用モジュール５０５などは、必要に応じて、記憶領域５０４へアクセスする。記憶領域５０４は、保護情報領域と呼ばれる。
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、インタフェース５２０及びバス５４０を介して行なわれる。ＰＵ５２１は、図２における２３１と同じものである。
【００７４】
各モジュールが実際に持っている機能については、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域 ５０４に記録されるデータの種類等については、図９を用いて後で説明する。
【００７５】
ＵＴモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成
図６を用いて、ＵＴモードでのUsage Pass送信が実行可能な記録モジュール １０２の構成について説明する。尚、ＵＴモードによるUsage Passの転送を行う機能を記録再生装置で実現する場合は、図１における保護情報転送モジュール１０４は、特に必要ではないため、描かれていない。
ＵＴモードでは、記録モジュールは常にPrimal Deviceとなる。そこで、記録モジュール ６２５の中には、他のデバイスとの間で相互認証を行う場合に、自身がPrimal Deviceとなって必要な処理を行うための機能を持ったモジュール６００、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール６０１、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール６０５、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール６０６が設けられている。暗号化されたコンテンツは、モジュール６０６からデータバス６４０へ、External Storage Interface ６２０を介して、磁気ディスク装置へ記録される。
【００７６】
記録モジュールを含むホストセキュリティマネージャ６３０には、利用者の意思による書き換えが行えないような静的な記憶領域６０４が設けられており、認証用モジュール６００やUsage Pass暗号化及び送信用モジュール６０１、Usage Pass復旧用モジュール６０５などは、必要に応じて、記憶領域へアクセスする。記憶領域６０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域５０４に記録されるデータの種類等については、図８を用いて後で説明する。
【００７７】
ＵＴモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成
図７を用いて、ＵＴモードでのUsage Pass受信が実行可能な再生モジュール１０３の構成について説明する。記録モジュールと同様に、ＵＴモードでUsage Passの転送を行う機能を記録再生装置で実現する場合は、図１における保護情報転送モジュール１０４は、特に必要ではないため、描かれていない。
【００７８】
ＵＴモードでは、再生モジュールは常にInceptive Deviceとなる。そこで、再生モジュール７２５の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール７００、自身がInceptive DeviceとなってUsage Passの受信を行うための機能を持ったモジュール７０３、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール６０５、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール ７０６が設けられている。この時、暗号化されたコンテンツデータは、External Storage Interface７２０及びデータバス７４０を介して、モジュール７０６に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール７０６から直接再生モジュール外へ出力される。
【００７９】
再生モジュールを含むホストセキュリティマネージャ７３０には、利用者の意思による書き換えが行えないような静的な記憶領域７０４が設けられており、認証用モジュール ７０２や、Usage Pass受信及び復号化用モジュール７０３、Usage Pass復旧用モジュール ７０５などは、必要に応じて、この記憶領域をアクセスする。記憶領域７０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域５０４に記録されるデータの種類等については、図８を用いて後で説明する。
【００８０】
ホストセキュリティマネージャ内にあるＵＴモード用保護情報領域の構成
図８を用いて、記録再生装置におけるＵＴモード用の保護情報領域の構成を説明する。
記憶領域８１９は、記録モジュール１０２がアクセスする領域である。一方、記憶領域８３９は、再生モジュール１０３がアクセスする領域である。記憶領域８１９と８３９には、同じ種類のデータが保持もしくは記録される。それらは、次の通りである。
８０１及び８２１は、Device Class証明書である。Device Class証明書８０１には、Device Class公開鍵８００が、同様にDevice Class証明書８２１にはDevice Class公開鍵８２０が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。
【００８１】
８０３及び８２３は認証局公開鍵、８０４及び８２４はDevice Class秘密鍵、８０５及び８２５はDevice公開鍵、８０６及び８２６はDevice秘密鍵である。
以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない。
【００８２】
これに対し、８０２及び８２２、８１０、８１１、８３０、８３１は、相互認証処理やUsage Pass転送処理において、更新される情報である。ここで８０２及び８２２は、失効したDevice Classのリストである。このリストを、以下ではRDCLと呼ぶ。あるDevice Class公開鍵KP_dcの安全性が失われると、KP_dcを含む証明書の固有番号を、このリストに登録する。他のデバイスから送られたDevice Class証明書の検証を行う際には、電子署名部を用いて証明書に改竄が行われていないことを確認すると共に、証明書の固有番号が、リストに登録されていないかどうかについても確認する。また、８１０、８１１、８３０、８３１はTransaction Logと呼ばれる記憶領域である。Transaction Logとしては、転送対象Usage PassのUPID、及び認証相手から送信されたDevice Class証明書中に含まれる「受信可能なUsage Pass Formatに関する情報」（記録するのはPrimal Deviceのみ、以下ではこれをType Mapと呼ぶ）。相互認証を実行中の相手のDevice公開鍵（記録するのはInceptive Deviceのみ）、転送過程において生成されるセッション鍵、Session Statusと呼ばれるUsage Pass転送処理の進行状況、転送を実行する前のUR_s（記録するのはPrimal Deviceのみ）、Usage Passが記録されているアドレスあるいは記録先のアドレスが、Usage Pass転送が実行される際に記録される。これらのデータをUsage Pass転送実行時に各段階において記録しておくことで、不慮の事故等により、転送元及び転送先いずれからもUsage Passが失われてしまった場合にも、Usage Passを復旧することができるようになる。これらのデータを記録するタイミングについては、図１７から図２０を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。
【００８３】
ここで、Type Mapについて説明しておく。Type Mapは、前述の通り、「受信可能なUsage Pass Formatに関する情報」を示すものである。この情報はDevice Class証明書に含まれており、その意味で認証処理中に認証相手となるデバイスに送られる。認証相手のデバイスは、自身がUsage Pass転送元であった場合に、どういった類のUsage Passであれば相手のデバイスが受信可能であるかを、Type Mapによって判断する。例えば、あるUsage PassのUsage Pass Formatが「Type ０」を示していた場合に、認証相手デバイスから送信された証明書中のType Mapが「Type ０受信不可」となっていた場合、Usage Passの転送元デバイスは、Usage Passの転送処理を行わない。
【００８４】
尚、図８では、保護情報領域において、記録モジュール用の記憶領域と、Playback用の記憶領域が分離され、それぞれの記憶領域にDevice Class証明書や認証局公開鍵、Device Class秘密鍵、Device公開鍵、Device秘密鍵、Transaction Log記録領域、失効されたDevice Classのリスト等が記録される形となっているが、必ずしもそのように実装する必要はない。つまり、１つのDevice Class証明書や認証局公開鍵、Device Class秘密鍵、Device公開鍵、Device秘密鍵を、記録モジュールと再生モジュール双方が用い、Transaction Log記録領域やRDCLの記録領域は共用領域として実装する形でも良い。
【００８５】
Usage Pass転送モジュール２２１内にある保護情報領域の構成
図９を用いて、磁気ディスク装置におけるＵＴモード用の保護情報領域の構成を説明する。図示するように、Usage Pass転送モジュール２２１内に設けられる保護情報領域５０４に記録されるデータは、図８における記録モジュール用に保持及び記録されるProtected Information８１９、あるいは再生モジュール用に保持及び記録されるProtected Information８３９と同じである。つまり、１つのDevice Class証明書９０１、１つの認証局公開鍵９０３、１つのDevice Class秘密鍵９０４、１つのDevice公開鍵９０５、１つのDevice秘密鍵９０６が埋め込まれ、また１つのRDCLを記録する領域９０２、適切な数のTransaction Logを記録する領域が設けられる。Device Class証明書９０１とそれぞれの鍵９０３、９０４、９０５、９０６は、磁気ディスク装置がPrimal Deviceとなる場合もInceptive Deviceとなる場合も利用される。Transaction Log記録領域も同様である。RDCLの更新は、磁気ディスク装置がPrimal Deviceとなる場合もInceptive Deviceとなる場合も、更新されうる。RDCLの更新基準は、後に図１７を用いて説明する。
【００８６】
制限記憶部２２３の構成
図１０を用いて、制限記憶部２２３の構成について説明する。制限記憶部２２３は、磁気ディスク装置の中にあって、記録モジュールや他の磁気ディスク装置から送られてきたUsage Passを記録し、保持する部分である。Usage Passの記録は、制限記憶コントローラ２２２によって制御される。制限記憶部２２３は、Usage Pass本体が記録される領域１０００、１０１０、１０２０等と、Usage Passの有効性を示すフラグを記録する領域１００１、１０１１、１０２１等から成る。以降、フラグを有効性指示フラグと呼ぶ。１００１に書き込まれた有効性指示フラグは領域１０００に書き込まれたUsage Passの有効性を、１０１１に書き込まれた有効性指示フラグは領域１０１０に書き込まれたUsage Passの有効性を、１０２１に書き込まれた有効性指示フラグは領域１０２０に書き込まれたUsage Passの有効性を示すものである。Usage Pass及び有効性指示フラグを記録する領域は、前記のようにペアを構成し、前記と同様に制限記憶部２２３内に多数設けられる。各々の有効性指示フラグ領域には、フラグとペアとなっている領域に有効なUsage Passが書き込まれると、制限記憶コントローラ ２２２によって、「有効」を示す値が記録される。一方、一度書き込まれたUsage Passを再生モジュールや他の磁気ディスク装置へ出力して後は、領域には「無効」を示す値が記録される。また、完全な初期状態においては、「未記録」を示す値が記録される。尚、制限記憶部に記録されているUsage Passの読み出しは、制限記憶コントローラ ２２２によって行われる。
【００８７】
ＢＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成
図１１を用いて、ＢＴモードでのUsage Pass転送が実行可能なUsage Pass転送モジュールの構成について説明する。
ＢＴモードでは、磁気ディスク装置は常にInceptive Deviceとなる。そこで、Usage Pass転送モジュール１１３０の中には、他のデバイスとの間で相互認証を行う場合に、自身がInceptive Deviceとなって必要な処理を行うための機能を持ったモジュール １１０２、自身がInceptive DeviceとなってUsage Passの転送を行うための機能を持ったモジュール１１０３、利用者の意思による書き換えが行えないような静的な記憶領域１１０４、Usage Pass転送を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元Device及び転送先Deviceいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール１１０５、及び制限記憶コントローラ２２２へUsage Passを送信する前に一時的にそれを蓄積しておいたり、制限記憶部から読み出したUsage Passを一時的に蓄積しておいたりするためのUsage Pass Buffer １１１０が設けられている。また、静的な記憶領域１１０４は、ＵＴモードの場合と同様に保護情報領域と呼ばれる。ただし、ここに記録されるデータは、５０４に記録されるデータとは、若干異なる。認証用モジュール１１００は、必要に応じて、記憶領域へアクセスする。
【００８８】
磁気ディスク装置の外部と各モジュールとの間でのデータのやりとりは、インタフェース１１２０及びバス１１４０を介して行なわれる。ＰＵ１１２１は、図２における２３１と同じものである。各モジュールが実際に持っている機能、保護情報領域 １１０４に記録されるデータの種類等については、図１５及び図２１から図２６を用いて、後で説明する。
【００８９】
ＢＴモードでのUsage Pass送信が実行可能な記録再生装置内の記録モジュールの構成
図１２を用いて、ＢＴモードでのUsage Pass送信が実行可能な記録モジュール１０２の構成について説明する。
ＢＴモードでは、Host Security Manager１１１全体が常にPrimal Deviceとして動作し、Usage Passは、Host Security Manager１１１に対して双方向に流れる。そこで、記録モジュール１２２５は、Usage Passを出力するために必要な機能のみ包含し、Inceptive Deviceとの間で相互認証を行うための機能などは、保護情報転送モジュール１０４が含む構成とした方が適切である。そこで記録モジュールには、自身がPrimal DeviceとなってUsage Passの送信を行うための機能を持ったモジュール１２０１、Usage Pass送信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール１２０５、及び外部からコンテンツデータ及び利用権情報を入手し、コンテンツ鍵を生成し、鍵でコンテンツを暗号化し、鍵を含むUsage Passを生成する機能を有するモジュール１２０６が設けられている。暗号化されたコンテンツデータは、モジュール１２０６からデータバス１２４０へ、External Storage Interface１２２０を介して、磁気ディスク装置へ記録される。
【００９０】
記録モジュールを含むホストセキュリティマネージャ１２３０には、利用者の意思による書き換えが行えないような静的な記憶領域１２０４が設けられており、認証用モジュール１２００やUsage Pass暗号化及び送信用モジュール１２０１、Usage Pass復旧用モジュール１２０５などは、必要に応じて、この記憶領域へアクセスする。記憶領域１２０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図２２から図２７を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域 １２０４に記録されるデータの種類等については、図１５を用いて後で説明する。
【００９１】
ＢＴモードでのUsage Pass受信が実行可能な記録再生装置内の再生モジュールの構成
図１３を用いて、ＢＴモードでのUsage Pass受信が実行可能な再生モジュール１０３の構成について説明する。
ＢＴモードでは、再生モジュールは、記録モジュールと同様に、常にPrimal Deviceとなる。記録モジュールについて説明した際にも述べたように、ホストセキュリティマネージャがPrimal DeviceとなってInceptive Deviceと相互認証を行うための機能は、保護情報転送モジュール１０４が担う。そこで、再生モジュール１３２５には、自身がPrimal DeviceとなってUsage Passの受信を行うための機能を持ったモジュール１３０３、Usage Pass受信処理を実行した際、処理が正常に終了しなかった場合に、対象のUsage Passが転送元デバイス及び転送先デバイスいずれからも失われてしまうことを避けるための、Usage Passの復旧機能を有するモジュール１３０５及び１３０１、及び受信したUsage Passから、Usage Passに含まれるUR_pに記載されている内容を解釈し、それに従って暗号化されたコンテンツデータを復号する機能を有するモジュール１３０６が設けられている。この時、暗号化されたコンテンツデータは、External Storage Interface １３２０及びデータバス１３４０を介して、モジュール１３０６に送信される。復号されたコンテンツデータは、保護されたデータ通信路等を通る形で、モジュール１３０６から直接再生モジュール外へ出力される。
【００９２】
再生モジュールを含むホストセキュリティマネージャ１３３０には、利用者の意思による書き換えが行えないような静的な記憶領域１３０４が設けられており、認証用モジュール １３０２や、Usage Pass受信及び復号化用モジュール１３０３、Usage Pass復旧用モジュール１３０５及び１３０１は、必要に応じて、記憶領域へアクセスする。記憶領域１３０４は、保護情報領域と呼ばれる。
各モジュールが実際に持っている機能については、図２２から図２７を用いて相互認証処理及びUsage Pass転送処理を具体的に説明する中で、詳細に説明する。また、保護情報領域１３０４に記録されるデータの種類等については、図１５を用いて後で説明する。
【００９３】
ＢＴモード用保護情報転送モジュールの構成
図１４を用いて、ＢＴモード用の保護情報転送モジュールの構成について説明する。
記録モジュールや再生モジュールに関する説明においても述べたように、ＢＴモードでは、保護情報転送モジュールがInceptive Deviceとの間の相互認証を実行する構成の方が適切である。そこで、保護情報転送モジュール１４１０には、自身がPrimal DeviceとなってInceptive Deviceとの間で相互認証処理を実行するためのモジュール１４００、再生モジュール１４１６の中のUsage Pass受信用モジュール１４０３が生成した最新のセッション鍵を一時的に保持し、必要に応じて記録モジュール内のUsage Pass送信用モジュールへ送信するモジュール１４０５が含まれる。尚、Usage Pass受信用モジュール１４０３における最新のセッション鍵生成タイミング、及びUsage Pass送信用モジュール１４０１におけるセッション鍵の利用方法などについては、図２３及び図２４を用いて処理シーケンスを説明する際に、詳細に述べる。
【００９４】
ホストセキュリティマネージャ内にあるＢＴモード用保護情報領域の構成
図１５を用いて、記録再生装置におけるＢＴモード用の保護情報領域の構成を説明する。
ＢＴモードは、Usage Passを転送する向きに拠らず、ホストセキュリティマネージャ１１１が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。それ故、通常記録モジュール１０２と再生モジュール１０３は、１つの保護情報領域を共有する形で実装した方が、記録再生装置に設ける静的記憶領域を小さくすることができる。
【００９５】
図１５は、このような状況を想定して保護情報領域を実装した場合の内部構成を示している。尚、ＵＴモードの場合に説明したように、記録モジュール１０２用と再生モジュール１０３用の別の記憶領域を用意し、それぞれにDevice Class証明書や、相互認証に必要な鍵を記憶させておいても良い。この場合、記録モジュールと再生モジュールはそれぞれが相互認証実行用モジュールを含まなければならなくなる。そのような場合は、本実施例では説明しない。
【００９６】
１５０１は、Device Class証明書である。Device Class証明書１５０１には、Device Class公開鍵１５００が含まれる。Device Class証明書は、含まれるDevice Class公開鍵の正当性を証明するものであり、電子署名が含まれる。電子署名部は、認証局秘密鍵K_CAで暗号化されている。
１５０３は認証局公開鍵、１５０４はDevice Class秘密鍵、１５０５はDevice公開鍵、１５０６はDevice秘密鍵である。
以上の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない。
【００９７】
これに対し、領域１５０２と１５１０に記録される情報は、RDCＬ及びConnection Logであり、これらは相互認証処理において更新される情報である。RDCLに含まれるデータの意味や、その役割は、ＵＴモードの場合と同じである。一方、Connection Logは、ＢＴモードに固有のログ情報である。ログに記録されるのは、認証相手となるデバイスのDevice公開鍵、認証処理実行中に自身及び相手によって生成される０次セッション鍵、及びType Mapである。図示のように、Connection Logは複数のエントリを持たない。ある２つのDevice間で相互認証処理を実行した後、一方を異なるDeviceと接続し直した場合、Connection Logは上書きされてしまう。
【００９８】
領域１５２０及び１５２１には、Transaction Logが記録される。Transaction Logは、Usage Pass転送処理において更新される情報であるが、記録される内容は、ＵＴモードの場合と異なる。ＢＴモードにおいて、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転送処理を具体的に説明する中で、詳細に説明する。
【００９９】
Usage Pass転送モジュール内にある保護情報領域の構成
図１６を用いて、磁気ディスク装置におけるＢＴモード用の保護情報領域の構成を説明する。
前述の通り、ＢＴモードは、Usage Passを転送する向きに拠らず、ホストセキュリティマネージャ １１１が全体として常にPrimal Deviceとなり、磁気ディスク装置が常にInceptive DeviceとなってUsage Pass転送をいずれの方向にも実行できるように考案された方式である。
図示の通り、Usage Pass転送モジュール内に設けられる保護情報領域に記録されるデータは、Transaction Logを除き、ホストセキュリティマネージャ １１１に記録されるデータと同一である。つまり、１６０１はDevice Class公開鍵１６００を含むDevice Class証明書であり、１６０３は認証局公開鍵、１６０４はDevice Class秘密鍵、１６０５はDevice公開鍵、１６０６はDevice秘密鍵、そして１６１０はConnection Logの記録領域である。
【０１００】
また、図示されている通り、制限記憶部２２３内の保護情報領域には、Transaction Logの記録領域が設けられていない。これは、Usage Pass転送実行時には、磁気ディスク装置はTransaction Logの記録を行わないことを意味する。ログの記録処理がない分、ＢＴモードでのUsage Pass転送時の磁気ディスク装置の処理負荷は、ＵＴモードに比べて、軽くなるという特徴がある。
上記の証明書及び鍵情報は、初期の実装時に埋め込まれているもので、後で更新されるものではない点、及びConnection LogはUsage Passを実行しようとするデバイス間で行われる相互認証処理において更新される点も、ホストセキュリティマネージャ１１１内の保護情報領域１０１と同じである。
【０１０１】
次に、図１７から図２７を参照して、ホストモジュール１１０、Primal Device、Inceptive Deviceの三者の間で行われる、相互認証処理、Usage Pass転送処理の詳細について説明する。これらの図は、ホストモジュールが発行する命令と、それに付随してデータバスを流れるデータ、及び命令とデータを受信または送信し、相互認証あるいはUsage Pass転送を実行するために各デバイスもしくはモジュールに求められる処理及び機能を示すものである。
【０１０２】
Usage Pass転送モード設定処理
Usage Pass転送を実行するためには、まず初めに、ホストモジュール１１０が仲介する形で、自身に接続されている脱着可能な記憶装置１２５，１２６及び自身に備わっているホストセキュリティマネージャ１１１に対して、ＵＴモードあるいはＢＴモードいずれの方式でUsage Pass転送を実行するか、を設定する必要がある。図１７は、これを実現するために各Deviceもしくはモジュールに求められる処理及び機能を、ホストモジュールが発行する命令とそれに付随して流れるデータの流れという観点で示したものである。
尚、図１７では、ホストモジュールを介して接続されている２つのDeviceを、便宜的にDevice１、Device２と呼んでいるが、これらはいずれも、ホストセキュリティマネージャ（より機能を特定して記録モジュールあるいは再生モジュールの場合もある）、脱着可能な記憶装置内のUsage Pass転送モジュールのいずれかである。これらのモジュールであれば、何れでもよい。
【０１０３】
まず、ホストモジュールは、Device２に対し、制限アクセスモード取得（GET QUALIFIED ACCESS MODE）命令１７０００を発行する。これに対しDevice２は、自身がＵＴモードによるUsage Pass転送を実行する機能とＢＴモードによるUsage Pass転送を実行する機能のいずれか、もしくは双方を有しているかを、応答１７００１としてホストモジュール１１０へ通知する。
次に、ホストモジュール１１０は、Device１に対しても同様の命令１７０１０を発行する。Device１は、Device２と同様に、自身がＵＴモードによるUsage Pass転送を実行する機能とＢＴモードによるUsage Pass転送を実行する機能のいずれか、もしくは双方を有しているかを、応答１７０１１としてホストモジュール１１０へ通知する。
【０１０４】
このようにして、ホストモジュール１１０は、Device２及びDevice１がそれぞれ実装しているUsage Pass転送モードの種類を知ることができ、ホストモジュール１１０は、双方のDeviceが実装しているモードを選び、双方のDeviceにモードを設定する。Device２に対しては、オープンチャネル（OPEN CHANNEL）命令１７０２０、Device１に対しては、OPEN CHANNEL命令１７０３０が、それらを設定するためのものである。これらの命令に付随して、いずれの制限アクセスモードでUsage Pass転送を実行するか、及び複数の転送処理を同時並列的に実行する場合にそれらを分離可能にするための識別子を、データ１７０２１及びデータ１７０３１で双方のDeviceに送信する。以下では、識別子のことをChannel識別子と呼ぶ。図１７では、Device１に対して設定されるChannel識別子はID_[D１]、Device２に対して設定されるChannel識別子はID_[D２]と記されている。
【０１０５】
ここで、同時並列的とは、例えば以下のような状況を言う。認証の確立後、Usage Pass転送が実行される場合は、Channel IDが特定されて、そのChannel IDの下でのみ転送が行われる。特に、UTモードの場合、Device２（磁気ディスク装置）に対して書き込みを行いながら、読み出しを行なう場合、ホストモジュールが発行する命令は、インターリーブ的になる場合がある。この様子を図２８に示す。
図２８において、PUT USAGE PASSの後には、ホストモジュールからDevice２にUsage Passが転送され、GET USAGE PASSの後には、Device ２からホストモジュールにUsage Passが転送される。太線で示す命令群（＊１、＊２、＊３印の命令）は、それ自体に処理順序が規定されおり、不規則な順序で命令を受信しても、Device２はそれを失敗させる（abort）。しかし、途中に、細線で示す命令（＊＊１、＊＊２、＊＊３印の命令）が来ても、それは失敗させない。太線の命令群は、それ自体規定された順序を守ってDevice２に命令が送られる限り、問題はないからである。
このような状況において、Device２はChannel IDを使って太線で示す処理系列と細線で示す処理系列を判別する。つまり、同時並列的な処理とは、このような状況を想定しており、太線で示す命令だけ先に初めから最後まで実行しUsage Pass転送を終了してから細線で示す処理を実行するというようなやり方ではなく、上記のように、お互いに属する命令が間に差し挟まれながら全体として処理を行なうような状況をいう。尚、上記のように２つの処理系列に限らず、３つ以上がお互い差し挟まれながら実行される場合も該当する。
【０１０６】
説明を図１７に戻す。Channel識別子は、具体的には次のように利用される。
例えば、記録再生装置に唯一の脱着型記憶装置が接続されていたとする。このような状況において、ＵＴモードで記録モジュール１０２から記憶装置（例えば１２５、以下同じ）へのUsage Passの書き込み行いながら、同様にＵＴモードで記憶装置１２５から再生モジュール１０３へ、既に記録されているUsage Passの読み出しを行うような場合、記憶装置１２５では、それぞれのUsage Pass転送処理を分離して管理できるようにする必要がある。このような二つの処理系列に異なるChannel識別子を割り当てることで、脱着型の記憶装置は、ホストモジュール１１０から送信されてきた命令が、どちらの処理系列に関連するものなのかを判断できるようになる。
Device２及びDevice１は、それぞれデータ１７０２１及び１７０３１を受信すると、Channel識別子と、この識別子に関連付けられた制限アクセスモードを設定する処理を、１７０２２及び１７０３２において実行する。
【０１０７】
Channel識別子と制限アクセスモードが設定されると、Device１とDevice２の間で相互認証処理１７０４０、及びそれに引き続く実際のUsage Pass転送処理１７０４１が実行される。これらの詳細は、図１８から図２７を用いて、後で詳細に説明する。
必要なUsage Pass転送処理を終えると、ホストモジュール１１０は、Device２とDevice１に対し、それぞれクローズチャネル（CLOSE CHANNEL）命令１７０５０及び１７０６０命令を発行する。この命令には、付随してChannel識別子１７０５１及び１７０６１がそれぞれのDeviceに送信される。それぞれのDeviceは、命令を受信すると、命令に続いて受信したChannel識別子で特定される処理系列に関する状態情報をすべてリセットし、Channel識別子も開放する。一度Channel識別子が開放されると、再度OPEN CHANNEL命令によってChannel識別子及び制限アクセスモードを設定しない限り、Deviceは認証処理やUsage Pass転送を実行するためにホストモジュールが発行する命令において、Channel識別子が指定されても、命令に関する処理を中断する。
【０１０８】
公開鍵暗号化による共有Device公開鍵共有方法
相互認証及びUsage Pass転送に関する詳細な処理シーケンスについて説明する前に、本発明の実施例で用いられる公開鍵暗号化の方法について説明する。
本実施例では、公開鍵暗号化の方法として楕円暗号を利用する。楕円暗号は、２次元のある楕円曲線の方程式で表される曲線上の固定点（これをベースポイントG = (Gx, Gy)と呼ぶ）に対し、そのn倍点、すなわちGをn回加算するという演算を暗号化に際して利用するものである。ここで用いられる加算法は、通常の十進法の加算方式と異なり、Gを整数回加算した結果は、Gとは異なる楕円曲線上の点となるようなものである。
【０１０９】
説明に際し、Device１とDevice２の二つのDeviceを想定する。そして、Device１には暗号化すべきメッセージMが、Device２には、ある公開鍵KPuとペアとなる秘密鍵KPrが記録されているものとする。ここで、KPrは自然数、KPuは楕円曲線上の座標点（KPux, KPuy）であり、両者及びベースポイントは、KPu = KPr × Gという関係で結ばれている。言い換えると、KPuは、ベースポイントのKPｒ回加算点であるということである。
【０１１０】
まず、Device１における暗号化処理について説明する。
(E１) Device２からDevice１へ、KPuを送信する。
(E２) Device１において、あるランダム自然数rを生成する。
(E３) r × G = R = (Rx, Ry)を計算する。
(E４) r × KPu = P = (Px, Py)を計算する
(E５) Px, Pyを用いて、ある自然数*KPuを生成する: *KPu = f(Px, Py) ここで、関数fは、事前に決めてあれば、任意でよい。
(E６) *KPuを共通鍵として用い、暗号化対象のメッセージMを、対称暗号化する: E(*KPu, M)
(E７) (６)で得られたデータに、(３)で得られたデータを連結し、Device２へ送信する。送信されるデータは、Rx || Ry || E(*KPu, M)である。ここで、*KPuを共有Device公開鍵と呼ぶ。
【０１１１】
次に、Device２における復号化処理について説明する。
(D１) Rx, Ry, KPrを用いて、Pを計算する: KPr × R = KPr × r × G = r × (KPr × G) = r × KPu = P = (Px, Py)
(D２) Px, Pyを用いて、*KPrを求める。ここで、*KPrと*KPuは、全く同一の数である。前者は、KPrを用いて得られたという意味で、*KPrと表現されている: *KPr = f(Px, Py)
(D３) r × KPu = P = (Px, Py)を求める。
(D４) *KPrを共通鍵として用い、受信したデータを、対称復号化する: D(*KPr, E(*KPu, M)), 本発明では、これをD(KPr, E(KPu, M))と記載する。ここで、*KPrを共有Device秘密鍵と呼ぶ。
以上に説明した、共通鍵*KPu、*KPrを共有するためのアルゴリズムは、一般にはECDHアルゴリズムと呼ばれている。
【０１１２】
尚、本明細書では、処理E２から処理E７全てを行う暗号化を、E(KPu, M)と記載する。既に*KPuが求められていて、処理E６のみ行う場合は、E(*KPu, M)と記載する。同様に、処理D１から処理D４まで全てを行う復号化を、D(KPr, E(KPu, M))と記載する。既に*KPrを求められていて、処理D４のみ行う場合は、D(*KPr, E(*KPu, M))と記載する。
【０１１３】
図１８から図２７に表れる記号短縮名に関する説明
図１８から図２７には、ＵＴモード及びＢＴモードでの、相互認証処理シーケンス及びUsage Pass転送処理シーケンスを示す。これらの図中では、短縮形として以下の表記が用いられる。
ID: Usage Pass Identifier（識別子）
DCC: Device Class Certificate
PD.C.key: Primal Deviceで生成されるChallenge鍵
ID.C.key: Inceptive Deviceで生成されるChallenge鍵
PD.S.key: Primal Deviceで生成されるセッション鍵
ID.S.key: Inceptive Deviceで生成されるセッション鍵
RDCL: 失効させられたDevice Classのリスト
UP: Usage Pass
UPL: Usage Pass Locationの略で、Primal Deviceに記録されている、あるいはInceptive Deviceに記録する予定の、Usage Passのアドレスである。アドレッシングの方法は、さまざまな機器毎とに異なるので、ここでは特定しない。
MUP: Masked Usage Pass．Usage Pass中のコンテンツ鍵の部分が０に置き換えられたUsage Passに、Usage Pass Stautsを連結したもの。
AI: Action Indicator．ENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれの命令を受信したかを示すもの。詳細は、図１９、図２３、図２４の説明において述べる。
CKS: Checksum。Usage Passを暗号化して転送する際、転送元においてUsage PassとAction Indicatorを連結したデータから計算し、データに対して連結するもの。詳細は、図１９、図２３、図２４の説明において述べる。
TL: Transaction Log
CL: Connection Log
TS_UT: ＵＴモードにおいて用いられるTransaction Status．詳細は、図２１の説明において述べる。
TS_BT: ＢＴモードにおいて用いられるTransaction Status．詳細は、図２１の説明において述べる。
Status: 
SS: Session Status．Usage Passの転送処理の段階．詳細は、図２１の説明において述べる。
UPS: Usage Pass Status。Usage Passの検索あるいは読み出しを行なった結果判明した、記録されているUsage Passの状態。図１０における有効性指示フラグに記載されている値と同一である。有効、無効、未記録の３状態がある。
【０１１４】
ＵＴモードにおけるDevice間相互認証処理シーケンス
図１８を用いて、ＵＴモードにおける、Primal DeviceとInceptive Deviceの間で相互認証を行う場合の処理シーケンスについて説明する。
尚、ＵＴモードにおける相互認証処理段階のことを、以下ではＵＴコネクションステージ（Connection stage）と呼ぶ。二つの脱着可能な記憶装置間でUsage Passを転送するということは、Primal Deviceが記憶装置１２５におけるモジュール５００、Inceptive Deviceが記憶装置１２６におけるモジュール５０２であるような場合である。記録モジュールなどで新たに生成したUsage Passを、脱着可能な記憶装置へ記録するような場合は、Primal Deviceがモジュール６００、Inceptive Deviceがモジュール５０２である。磁気ディスク装置に記録されているUsage Passを再生モジュールへ送信し、コンテンツデータの復号や再生などを行う場合は、Primal Deviceがモジュール５００、Inceptive Deviceがモジュール７０２となる。これらの関係は、図１９から図２１におけるＵＴモードでの各処理シーケンスについての説明でも同様である。
【０１１５】
まず初めに、ホストモジュールは、Inceptive Deviceに対してデバイスクラス証明書取得（GET DEVICE CLASS CERTIFICATE）命令１８０００を発行する。すると、Inceptive Deviceは、自身に埋め込まれているデバイスクラス（Device Class）証明書を、ホストモジュール１１０へ送信する（１８００１）。Device Class証明書を、以降ではDCC（K_CA, KP_dc[I]）と記載する。これは、証明書が、KP_dc[I]の正当性を示すもので、K_CAを用いて電子署名部が暗号化されていることを表している。
ホストモジュール１１０は、DCC（K_CA, KP_dc[I]）を受信すると、Primal Deviceに対しデバイスクラス証明書検証（VERIFY DEVICE CLASS CERTIFICATE）命令１８０１０を発行し、それに続いてDCC（K_CA, KP_dc[I]）をPrimal Deviceへ送信する（１８０１２）
Primal Deviceは、DCC（K_CA, KP_dc[I]）を受信すると、１８０１２に示す１つの処理（処理UT１.１.１）を実行する。
処理UT１.１.１: DCC（K_CA, KP_dc[I]）の検証を行う。検証は、証明書中のデータに対して改竄が行われていないか、及び含まれる証明書を特定する番号が、自身に記録されているRDCL_[P]に載っていないか、を調査することによって達成される。改竄の有無は、KP_dc[I]を含む電子署名部以外のデータのハッシュ値を計算した後、それがDCC（K_CA, KP_dc[I]）における電子署名部をKP_CAで復号した結果と一致しているか否かで判定される。両者が一致していた場合、改竄は行われていないことになる。証明書を特定する番号がRDCL_[P]に載っていた場合、認証処理は中断される。
【０１１６】
Primal DeviceがDCC（K_CA, KP_dc[I]）を検証中に、ホストモジュール１１０は、処理が終了するタイミングを見計らって、Primal Deviceに対し、プライマルデバイスチャレンジキーＵＴコネクション取得（GET PRIMAL DEVICE CHALLENGE KEY UT CONNECTION）命令１８０２０を発行する。Primal Deviceは命令を受信すると、１８０２１に示す、下記３つの処理を実行する。
処理UT１.２.１: Challenge鍵K_ch[P]を生成する。
処理UT１.２.２:  処理UT１.２.１で生成したK_ch[P]を、DCC（K_CA, KP_dc[I]）中のKP_dc[I]で暗号化する。得られるデータは、E(KP_dc[I], K_ch[P])である。
処理UT１.２.３: 処理UT１.２.２で得られたデータに対し、自身に埋め込まれているDevice Class証明書を連結。得られるデータは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])である。
【０１１７】
処理UT１.２.３においてE(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])の生成を終えると、Primal Deviceは、データをホストモジュールへ送信する（１８０２２）。
ホストモジュールは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE CHALLENGE KEY UT CONNECTION命令１８０３０命令を発行後、受信したデータをInceptive Deviceに送信する（１８０３１）。
【０１１８】
Inceptive Deviceは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、１８０３２に示す、下記の３つの処理を実行する。
処理UT１.３.１: DCC(K_CA, KP_dc[P])を検証する。検証手段は、処理UT１.１.１で説明した方法と同じである。但し、参照するRDCLは、RDCL_[I]である。
処理UT１.３.２: 受信したデータのうち、E(KP_dc[I], K_ch[P])を分離し、復号する。復号は、自身の保護情報領域に埋め込まれているK_dc[I]を用いて行う。
処理UT１.３.３: 処理UT１.３.２の結果として、K_ch[P]が正当な形で含まれていたかどうかを確認する。確認は、次のようにして行う。まず、処理UT１.３.２においてK_ch[P]を暗号化する際、K_ch[P]に対し固有の番号を連結して暗号化するということをあらかじめ規定しておく。そして、処理UT１.３.２において受信したデータを復号した際、その結果において、規定された番号が得られれば、データの破壊等は起こっていないと判断する。
【０１１９】
処理UT１.３.１から処理UT１.３.３を実行中、ホストモジュール１１０は、処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE SESSION KEY UT CONNECTION命令１８０４０を発行する。Inceptive Deviceは命令を受信すると、１８０４１に示す下記の２つの処理を実行する。
処理UT１.４.１: ０次セッション鍵K_s[I]０を生成する。
処理UT１.４.２: 処理UT１.４.１で生成したK_s[I]０に対し、自身に埋め込まれているDevice公開鍵KP_d[I]を連結し、処理UT１.３.１で受信したKP_dc[P]で暗号化する。暗号化によって得られたデータに、自身に記録されているRDCL_[I]を連結し、得られたデータ全体を処理UT１.３.３で得られたK_ch[P]で暗号化する。最終的に得られるデータは、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])である。
【０１２０】
Inceptive Deviceにおいて、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])が生成されると、Deviceは、生成されたデータをホストモジュールへ送信する（１８０４２）。
ホストモジュールは、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])を受信すると、Primal Deviceに対して、インセンプティブデバイスセッションキーＵＴコネクション送信（PUT INCEPTIVE DEVICE SESSION KEY UT CONNECTION）命令１８０５０を発行後、受信したデータをPrimal Deviceへ送信する（１８０５１）。
【０１２１】
Primal Deviceは、E(K_ch[P], E(KP_dc[P], K_s[I]０ || KP_d[I]) || RDCL_[I])を受信すると、１８０５２に示す、下記の５つの処理を実行する。
処理UT１.５.１: 受信したデータを、K_ch[P]で復号する。K_ch[P]は、処理UT１.２.１において自身で生成された鍵である。
処理UT１.５.２: 処理UT１.５.１の結果から、RDCL_[I]を分離し、RDCL_[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT１.５.３: 自身に記録されているRDCL_[P]と、送信されたRDCL_[I]について、それらが発行された日付情報を比較する。RDCLの発行日情報は、RDCL内に含まれるものとする。比較した結果、受信したRDCL_[I]の発行日情報が、自身に記録されているRDCL_[P]の発行日情報より新しかった場合は、RDCL_[P]をRDCL_[I]で上書きする。
処理UT１.５.４: 残りのデータE(KP_dc[P], K_s[I]０ || KP_d[I])を、K_dc[P]で復号する。
処理UT１.５.５: 処理UT１.５.４で得られたデータについて、K_s[I]０ || KP_d[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
【０１２２】
処理UT１.５.１から処理UT１.５.５をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY UT CONNECTION命令１８０６１を発行する。Primal Deviceは命令を受信すると、１８０６１に示す、下記の２つの処理を実行する。
処理UT１.６.１: ０次セッション鍵K_s[P]０生成する。
処理UT１.６.２: 処理UT１.６.１で生成したK_s[P]０を、処理UT１.５.５で受信した０次セッション鍵K_s[I]０で暗号化する。得られるデータはE(K_s[I]０, K_s[P]０)である。ここで、処理UT１.５.３におけるRDCL_[P]とRDCL_[I]の発行日情報の比較の結果、RDCL_[P]の発行日の方が新しかった場合は、E(K_s[I]０, K_s[P]０)に対し、RDCL_[P]を連結後、得られたデータ全体を処理UT１.５.５で得られたKP_d[I]で暗号化する。最終的に得られるデータは、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])である。
【０１２３】
Primal Deviceにおいて、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])の生成を終えると、Deviceは、データをホストモジュール１１０へ送信する（１８０６２）。
ホストモジュール１１０は、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE SESSION KEY UT CONNECTION命令１８０７０命令を発行後、受信したデータをDeviceに送信する（１８０７１）。
【０１２４】
Inceptive Deviceは、E(KP_d[I], E(K_s[I]０, K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、１８０７２に示す、下記の５つの処理を実行する。
処理UT１.７.１: 受信したデータを、K_d[I]で復号する。K_d[I]は、自身の保護情報領域に埋め込まれている。
処理UT１.７.２: 処理UT１.７.１の結果にRDCL_[P]が含まれていた場合、データを分離し、データが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT１.７.３: 処理UT１.７.１と処理UT１.７.２の結果、受信したデータにRDCL_[P]が含まれていて、それが正当な形で含まれていたことが確認できた場合、自身に記録されているRDCL_[I]を、受信したRDCL_[P]で上書きする。
処理UT１.７.４: 残りのデータE(K_s[I]０, K_s[P]０)を、K_s[I]０で復号する。K_s[I]０は、処理UT１.４.１において、自身で生成した鍵データである。
処理UT１.７.５: 処理UT１.７.４で得られたデータについて、K_s[P]０が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
【０１２５】
以上処理UT１.７.５までを完了すると、共有Device公開鍵*KP_d[I]（共有Device秘密鍵*K_d[I]と同じ）、K_s[P]０、K_s[I]０の共有が完了する。
【０１２６】
ＵＴモードにおけるDevice間Usage Pass転送処理シーケンス
ＵＴモードにより、Primal DeviceとInceptive Deviceの間で相互認証が完了すると、Primal DeviceからInceptive Deviceに対して、Usage Passを転送することができる。次に、図１９を用いて、Usage Passの転送処理シーケンスについて説明する。尚、ＵＴモードにおけるUsage Pass転送処理段階のことを、以下ではUT Transfer stageと呼ぶ。
【０１２７】
まず初めに、ホストモジュール１１０は、Primal Deviceに対してユーセジパスリード（READ USAGE PASS）命令１９０００を発行する。そして、命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、１９００１においてPrimal Deviceに通知する。Primal Deviceは、命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、１９００２に示す、下記の処理を実行する。
処理UT２.１.１: 転送対象のUsage Passを、Usage Pass送信用モジュール内へ準備する。例えば、Primal Deviceが磁気ディスク装置であった場合、目的のUsage Passを制限記憶部 ２２３からUsage Pass Buffer ５１０を介してモジュール５０１内に送るような処理に相当する。同様に、Primal Deviceが記録モジュールであった場合、目的のUsage PassをUsage Pass Creator and Content Encrypter６０６からモジュール６０１へ送るような処理に相当する。
【０１２８】
ホストモジュール１１０は、目的のUsage Passが、Usage Pass送信用モジュール内に準備されると、続いてマスクユーセジパス取得（GET MASKED USAGE PASS）命令１９０１０を、Primal Deviceに対して発行する。Primal Deviceはこの命令を受信すると、Masked Usage Passを作成し、１９０１１においてホストモジュール１１０へデータを送信する。先に説明したように、Masked Usage Passは、Usage Pass中のコンテンツ鍵データ部を０で置き換えたものに、Usage Pass Statusを連結したものである。ホストモジュール１１０は、Masked Usage Passを受信すると、データ中のUR_sを解析し、Usage Pass送信用モジュール内に読み出されたUsage Passが、転送可能であるかどうかを判断する。転送可能であると判断された場合は、以下のUsage Pass転送処理を継続する。
【０１２９】
Usage Pass転送処理を継続する場合、次にホストモジュール１１０は、Inceptive Deviceに対して、インセプティブデバイスセッション鍵ＵＴ転送生成（CREATE INCEPTVE DEVICE SESSION KEY UT TRANSFER）命令１９０２０命令を発行する。そして、この命令に続いて、転送対象となるUsage PassのUsage Pass識別子をInceptive Deviceへ送信する（１９０２１）。Inceptive Deviceは、受信対象Usage PassのUsage Pass識別子を受信すると、１９０２２に示す、下記の３つの処理を実行する。
処理UT２.２.１: セッション鍵K_s[I]nを生成する。セッション鍵は、Usage Pass転送を行う度に生成される共通鍵であり、その意味から、nはn回目のUsage Pass転送用に生成されたことであることを意味する。n ≧ １である。
処理UT２.２.２: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、処理UT２.２.１で生成したセッション鍵K_s[I]n、Session Statusである。要素には、Usage Passを受信する準備が整ったという意味で、RP（Receive Prepared）が設定される。残りの要素には、不定U（Unspecified）が記録される。
処理UT２.２.３: 処理UT２.２.１で生成したK_s[I]nを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-１及びConnection stageにおいてPrimal Deviceで生成された０次セッション鍵K_s[P]０を用いて、暗号化する。本処理の前に一度のUsage Pass転送が行われていない場合は、Connection stage中の処理UT１.４.１において自身で生成した０次セッション鍵を用いる。得られるデータは、E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))である。
【０１３０】
処理UT２.２.１及び処理UT２.２.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、インセプティブデバイスセッション鍵ＵＴ転送取得（GET INCEPIVE DEVICE SESSION KEY UT TRANSFER）命令１９０３０を発行する。Inceptive Deviceはこの命令を受信すると、処理UT２.２.３において生成されたデータを、ホストモジュール１１０へ送信する（１９０３１）。
ホストモジュール１１０は、E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))を受信すると、Primal Deviceに対して、インセプティブデバイスセッション鍵ＵＴ転送送信（PUT INCEPTIVE DEVICE SESSION KEY UT TRANSFER）命令１９０４０を発行した後、受信したデータにUsage Pass識別子を連結し、Primal Deviceへ送信する（１９０４１）。送信されるデータは、UPID || E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))である。
【０１３１】
Primal Deviceは、UPID || E(K_s[P]０, E(K_s[I]n-１, K_s[I]n))を受信すると、１９０４２に示す、下記の５つの処理を実行する。
処理UT２.３.１: 受信したUPIDと、処理UT２.１.１でUsage Pass送信用モジュール内に準備したUsage PassのUPIDが一致しているか調べる。一致していなければ、ここでUsage Pass転送処理を中断する。
処理UT２.３.２: 受信したデータを、K_s[P]０及びK_s[I]n-１で復号する。K_s[P]０は処理UT１.６.１において自身で生成したものであり、K_s[I]n-１は処理UT.２.２.３において説明したものと同じである。
処理UT２.３.３: 処理UT２.３.２で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT２.３.４: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、処理UT１.１.１で得たInceptive DeviceのDevice Class証明書に含まれるType Map、処理処理UT２.３.３で得たセッション鍵K_s[I]n、Session Status、転送対象Usage PassのUR_s、処理UT２.１.１で読み出したUsage PassのUsage Pass Locationである。Session Statusには、Usage Passを送信する準備が整ったという意味で、SP（Send Prepared）が設定される。
【０１３２】
以上、処理UT２.３.１から処理UT２.３.４をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令１９０５０を発行する。尚、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。そこで、命令を受信すると、Primal Deviceは、１９０５１に示す、下記の２つの処理を実行する。
【０１３３】
処理UT２.４.１: Inceptive Deviceに対して送信するUsage Passを、処理UT２.１.１においてUsage Pass送信用モジュール内に準備されたUsage Passを元に、生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理UT２.４.２: 処理UT２.４.１において生成された送信用Usage Passに対し、受信した命令がENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれであるかを示す識別子情報Action Indicator、及びUsage Pass || Action Indicatorに対するChecksumを計算し、連結する。連結処理の後、得られたデータをK_s[I]n及び*KP_d[I]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))である。尚、Checksumの計算は、例えば次のように行えば良い。
まず、計算対象とするデータUsage Pass || Action Indicatorを、固定長ごとに分割する。そして、得られたそれぞれのブロックデータを全て足し合わせた後、全てのビット値を反転し、更に１を加える。これは、Usage Pass || Action Indicatorの２の補数を求めていることに他ならない。検証時は、Checksumを含めたデータ全体Usage Pass || Action Indicator || Checksumを先と同じ固定長に分割後、各ブロックデータを全て足し合わせる。その結果が０となれば、途中でデータに変化がないということになる。
【０１３４】
上記の処理UT２.４.１及び処理UT２.４.２をPrimal Deviceが実行中、ホストモジュール１１０は処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令１９０６０を発行する。Primal Deviceは、命令を受信すると、１９０６２に示す、下記の３つの処理を実行する。
処理UT２.５.１: Transaction LogにおけるSession Statusを更新する。Usage Passの送信が完了したことで、Session StatusをSC（Send Completed）に設定する。
処理UT２.５.２: 処理２.４.２において生成されたデータE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))をホストモジュールへ送信する。
処理UT２.５.３: 元のUsage Pass中のUR_sを規定に従って変更する。Primal Deviceが磁気ディスク装置であった場合は、UR_sが変更されたUsage Passを、Usage Passが制限記憶部中で元来記録されていた場所に、上書きする。尚、命令１９０５０がENCRYPT USAGE PASS MOVEであった場合、有効性指示フラグの値は「無効」にされる。
【０１３５】
ホストモジュール１１０は、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を受信すると、Inceptive Deviceに対して、ユーセジパス送信（PUT USAGE PASS）命令１９０７０を発行し、またDeviceに対し、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を送信する（１９０７１）。Inceptive Deviceは、命令及びデータを受信すると、１９０７２に示す、下記の３つの処理を実行する。
処理UT２.５.１: 受信したデータを、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、処理UT１.７.１において得た共通鍵である。また、K_s[I]nは処理UT２.２.１において自身で生成したセッション鍵である。
処理UT２.５.２: 処理UT２.５.１で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載してある。
処理UT２.５.３: Transaction LogにおけるSession Status及びUsage Pass Locationを更新する。Session Status には、Usage Passの受信が完了したということを表すRC（Receive Completed）を設定する。Usage Pass Locationには、Usage Passの記録先アドレスを記載する。
【０１３６】
尚、Inceptive Deviceが磁気ディスク装置の場合、処理UT２.５.３の後、受信したUsage Passを制限記憶部２２３に記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive DeviceにおけるUsage Passの受信もしくは制限記憶部２２３への記録が正常に終了したか否かを確認するために、ホストモジュール１１０は、Inceptive Deviceに対し、実行ステータスチェック（CHECK EXECUTION STATUS）命令１９０８０を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が１９０８１において送信される。
以上のように、UT Transfer stageを繰り返すことにより、Connection stageを繰り返し行わなくても、連続的にUsage Pass転送を実行することができる。
【０１３７】
ＵＴモードにおけるDevice間再相互認証処理シーケンス
Primal DeviceとInceptive Deviceの間で１回以上のUT Transfer stageが行われ、両Deviceの間でセッション鍵K_s[I]nの共有及び鍵のTransaction Logへの記録が終了した後、記録再生装置に異常が発生して、Usage Pass送信用モジュール及び同受信用モジュールからセッション鍵が失われてしまった場合、Connection stageと比べ、少ない処理で相互認証を再完了することができる。
次に、図２０を用いて、この再相互認証処理について説明する。尚、ＵＴモードにおける本処理段階のことを、以下ではUT Reconnection stageと呼ぶ。
【０１３８】
まず、UT Transfer stageにおいて、Inceptive Deviceはユーセジパス送信（PUT USAGE PASS）命令２００００及びそれに続いてUsage Pass ２０００１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常発生の理由により、Primal DeviceとInceptive Deviceの間で分断が発生し、２０００１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]や共有Device公開鍵*KP_d[I]が、両Deviceから失われてしまったとする（２００１０）。
上記の場合、ホストモジュール１１０は、まずPrimal Deviceに対し、トランザクションログ再認証検索（SEARCH TRANSACTION LOG RECONNECTION）命令２００２０を発行する。そして、命令に続き、２０００１で送信中であったUsage PassのUsage Pass識別子を、送信する（２００２１）。
Primal Deviceは、識別子を受信すると、２００２２に示す下記の１つの処理を実行する。
処理UT３.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
【０１３９】
処理UT３.１.１を実行中、ホストモジュール１１０は処理が終了するタイミングを予測し、適切なタイミングで、プライマルデバイスセッション鍵ＵＴ再認証取得（GET PRIMAL DEVICE SESSION KEY UT RECONNECTION）命令２００３０を発行する。Primal Deviceは、命令を受信すると、２００３１に示す下記の２つの処理を実行する。
処理UT３.２.１: 新しい０次セッション鍵K_s[P]０'を生成する。
処理UT３.２.２: 処理UT３.２.１で生成したK_s[P]０'を、処理UT３.１.１で見出された自身のTransaction Logに記録されているセッション鍵K_s[I]TL及びDevice公開鍵KP_d[I]TLで暗号化する。鍵K_s[I]TL及びKP_d[I]TLは、Transaction Logに記録されていた鍵データであるということを表している。最終的に得られるデータは、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]０'))である。
処理UT３.２.２における暗号化を終えると、Primal Deviceは、その暗号化されたデータをホストモジュールへ送信する（２００３２）。
【０１４０】
ホストモジュール１１０は、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]０'))を受信すると、Inceptive Deviceに対して、プライマルデバイスセッション鍵ＵＴ再認証送信（PUT PRIMAL DEVICE SESSION KEY UT RECONNECTION）命令２００４０命令を発行した後、受信したデータに２００２１でPrimal Deviceに対して送信したUsage Pass識別子と同一の識別子を連結し、Inceptive Deviceに送信する（２００４１）。
Inceptive Deviceは、E(KP_d[I]TL, E(K_s[I]TL, K_s[P]０'))を受信すると、２００４２に示す下記の３つの処理を実行する。
処理UT３.３.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT３.３.２: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[I]及び処理UT３.３.１で見出されたTransaction Log中に含まれるセッション鍵K_s[I]TLである。
処理UT３.３.３: 処理UT３.３.２の結果として、K_s[P]０'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理UT３.３.２が完了すると、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'の共有が完了する。以上の処理に続いてUT Transfer stageを実行する場合、K_s[I]n-１としては、K_s[I]TLを用いる。
【０１４１】
ＵＴモードにおけるUsage Pass復旧処理シーケンス
UT Transfer stageにおいてUsage Passの移動が行われている最中に、記録再生装置に電源断などの異常が発生して、Primal DeviceからもInceptive Deviceからも転送処理中のUsage Passが失われてしまった場合や、Primal DeviceからInceptive Deviceに対して再生用のUsage Pass転送を行い、Primal DeviceにおけるUsage PassのPlay Countは減ぜられたが、Inceptive Deviceでは全く再生を実行しなかった場合などに、Primal Deviceに元来存在したUsage PassのPlay Countを伴った形で、Usage Passを復旧することができるような仕組みを設けることは有意義である。
次に、図２１を用いて、このようなUsage Pass復旧処理について説明する。ＵＴモードにおける本処理段階のことを、以下ではUT Recovery stageと呼ぶ。
【０１４２】
まず、UT Transfer stageにおいて、Inceptive Deviceがユーセジパス設定（PUT USAGE PASS）命令２１０００及びそれに続いてUsage Pass ２１００１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が発生し、２１００１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]が、両Deviceから失われてしまったとする（２１０１０）。この場合、まず前節に記したUT Reconnection stageが実行され、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'が新たに共有される。
【０１４３】
UT Reconnection stageを終えると、ホストモジュール１１０は、まずInceptive Deviceに対し、ユーセジパスＵＴ復旧検索（SEARCH USAGE PASS UT RECOVERY）命令２１０２０を発行する。そして、命令に続き、２１００１で送信中であったUsage PassのUsage Pass識別子を、送信する（２１０２１）。
Primal Deviceは、識別子を受信すると、２１０２２に示す４つの処理を実行する。
処理UT４.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT４.１.２: 処理UT.４.１.１で見出されたTransaction Logに記録されていたUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理UT４.１.３: 処理UT４.１.２で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理UT４.１.４: ＵＴモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || Transaction Log中に記録されているSession Status || 処理UT４.１.３で設定したUsage Pass Status || Hash値である。ここでHash値は、K_s[P]０' || K_s[I]TL || UPID || Session Status || Usage Pass Statusから計算される。本処理で生成されたTransaction Statusを、以下ではUT Transaction Statusと呼ぶ。
【０１４４】
処理UT４.１.１から処理UT４.１.４をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでトランザクションステータスＵＴ復旧取得（GET TRANSACTION STATUS UT RECOVERY）命令２１０３０を発行する。Inceptive Deviceは命令を受信すると、処理UT４.１.４において生成されたUT Transaction Statusを、ホストモジュール１１０へ送信する（２１０３１）。
ホストモジュール１１０は、Transaction Statusを受信すると、Primal Deviceに対し、トランザクションステータスＵＴ復旧検証（VERIFY TRANSACTION STATUS UT RECOVERY）命令２１０４０を発行し、続いて受信したデータを送信する（２１０４１）。送信されるデータは、UT Transaction Statusである。
【０１４５】
Primal Deviceは、UT Transaction Statusを受信すると、２１０４２に示す下記の３つの処理を実行する。
処理UT４.２.１: UT Transaction Statusの検証と、UT Transaction Statusに含まれるUsage Pass識別子、Session Status、Usage Pass Statusの確認を行う。UT Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]０'とK_s[I]TLから計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、Session Status及びUsage Pass Statusは復旧可否を判定するために用いられる。Session StatusがRPであった場合や、Session StatusがRPであるがUsage Pass Statusが「無効」や「未記録」であった場合は、Primal Deviceにおける復旧処理（下記処理４.２.２）が行われる。
処理UT４.２.２: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
処理UT４.２.３: Usage Pass復旧処理を実行する。Usage Passの復旧は、対象のUsage Passの有効性指示フラグが「無効」となっていた場合はそれを「有効」にし、復旧対象のUsage PassのUR_sを、処理UT４.２.２で見出されたTransaction Logに記録されていたUR_sで上書きすることによって達成される。
【０１４６】
その後、Primal DeviceにおけるUsage Passの復旧処理が正常に終了したか否かを確認するために、ホストモジュールは、Primal Deviceに対し、CHECK EXECUTION STATUS命令２１０５０を発行しても良い。Primal Deviceからホストモジュールへは、実行状態が２１０５１において送信される。
処理UT４.２.２が完了すると、Primal Deviceには、送信する以前のUsage Passが存在するようになる。
【０１４７】
ＢＴモードにおけるDevice間相互認証処理シーケンス
次に、図２２を参照して、ＢＴモードにおける、Primal DeviceとInceptive Deviceの間で相互認証を行う場合の処理シーケンスについて説明する。尚、ＢＴモードにおける相互認証処理段階のことを、以下ではBT Connection stageと呼ぶ。
図１１から図１３の説明でも述べたように、ＢＴモードでは、Primal Deviceは記録再生装置内のホストセキュリティマネージャ１１１全体である。Managerに含まれるモジュールの中で、相互認証処理は保護情報転送モジュール内のモジュール１４００が、Usage Passの送信や受信は記録モジュールと再生モジュール内のモジュール１２０１やモジュール１３０３が担う。また、Inceptive Deviceは、磁気ディスク装置内のUsage Pass転送モジュール１１３０である。これらの関係は、以後図２２から図２７において説明するＢＴモードでの各処理シーケンスにおいても同様である。
【０１４８】
まず初めに、ホストモジュール１１０は、Inceptive Deviceに対してGET DEVICE CLASS CERTIFICATE命令２２０００を発行する。すると、Inceptive Deviceは、自身に埋め込まれているDevice Class証明書DCC（K_CA, KP_dc[I]）を、ホストモジュールへ送信する（２２００１）。
ホストモジュール１１０は、DCC（K_CA, KP_dc[I]）を受信すると、Primal Deviceに対してVERIFY DEVICE CLASS CERTIFICATE命令２２０１０を発行し、それに続いてDCC（K_CA, KP_dc[I]）をPrimal Deviceへ送信する（２２０１２）。
【０１４９】
Primal Deviceは、DCC（K_CA, KP_dc[I]）を受信すると、２２０１２に示す下記の４つの処理を実行する。
処理BT１.１.１: DCC（K_CA, KP_dc[I]）を検証する。証明書について改竄が行われていないか、及び含まれる証明書を特定する番号が自身に記録されているRDCL_[P]に載っていないか、検証する。検証方法は、UT１.１.１に記載した方法と同じである。
処理BT１.１.２: Challenge鍵K_ch[P]を生成する。
処理BT１.１.３:処理BT１.１.３で生成したK_ch[P]を、DCC（K_CA, KP_dc[I]）中のKP_dc[I]で暗号化する。この暗号方式は、公開鍵暗号化である。得られるデータは、E(KP_dc[I], K_ch[P])である。
処理BT１.１.４: 処理BT１.１.３で得られたデータに対し、自身に埋め込まれているDevice Class証明書を連結。得られるデータは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])である。
【０１５０】
Primal Deviceが処理BT１.１.１から処理BT１.１.４を実行中に、ホストモジュール１１０は、処理が終了するタイミングを見計らって、Primal Deviceに対し、GET PRIMAL DEVICE CHALLENGE KEY BT CONNECTION命令２２０３０を発行する。Primal Deviceは、命令を受信すると、処理B１.１.４で生成したデータを、ホストモジュールへ送信する（２２０３１）。
ホストモジュール１１０は、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE CHALLENGE KEY BT CONNECTION命令２２０４０命令を発行後、受信したデータをInceptive Deviceに送信する（２２０４１）。
【０１５１】
Primal Deviceは、E(KP_dc[I], K_ch[P]) || DCC(K_CA, KP_dc[P]を受信すると、２２０４２に示す下記の３つの処理を実行する。
処理BT１.２.１: DCC(K_CA, KP_dc[P])を検証する。検証手段は、処理UT１.１.１で説明した方法と同じである。但し、参照するRDCLは、RDCL_[I]である。
処理BT１.２.２: 受信したデータのうち、E(KP_dc[I], K_ch[P])を分離し、復号する。復号は、自身の保護情報領域に埋め込まれているK_dc[I]を用いて行う。
処理BT１.２.３: 処理BT１.２.２の結果として、K_ch[P]が正当な形で含まれていたかどうかを確認する。確認の方法は、処理UT１.３.３に記載した方法と同じである。
【０１５２】
処理BT１.２.１から処理BT１.２.３を実行中、ホストモジュール１１０は、処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE CHALLENGE KEY BT CONNECTION命令２２０５０を発行する。Inceptive Deviceは命令を受信すると、２２０５１に示す下記の２つの処理を実行する。
処理BT１.３.１: Challenge鍵K_ch[I]を生成する。
処理BT１.３.２: 処理BT１.３.１で生成したK_ch[I]に対し、自身に埋め込まれているDevice公開鍵KP_d[I]を連結し、処理BT１.２.１で受信したKP_dc[P]で暗号化する。暗号化によって得られたデータに、自身に記録されているRDCL_[I]を連結し、得られたデータ全体を処理BT１.２.３で得られたK_ch[P]で暗号化する。最終的に得られるデータは、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])である。
【０１５３】
Inceptive Deviceにおいて、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])が生成されると、Deviceは、生成されたデータをホストモジュールへ送信する（２２０５２）。
ホストモジュール１１０は、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])を受信すると、Primal Deviceに対しPUT INCEPTIVE DEVICE CHALLENGE KEY BT CONNECTION命令２２０６０を発行した後、受信したデータをPrimal Deviceへ送信する（２２０６１）。
【０１５４】
Primal Deviceは、E(K_ch[P], E(KP_dc[P], K_ch[I] || KP_d[I]) || RDCL_[I])を受信すると、２２０６２に示す下記の７つの処理を実行する。
処理BT１.４.１: 受信したデータを、K_ch[P]で復号する。K_ch[P]は、処理BT１.１.２において自身で生成された鍵である。
処理BT１.４.２: 処理UT１.４.１の結果から、RDCL_[I]を分離し、RDCL_[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.４.３: 自身に記録されているRDCL_[P]と、送信されたRDCL_[I]について、それらが発行された日付情報を比較する。RDCLの発行日情報は、RDCL内に含まれるものとする。比較した結果、受信したRDCL_[I]の発行日情報が、自身に記録されているRDCL_[P]の発行日情報より新しかった場合は、RDCL_[P]をRDCL_[I]で上書きする。
処理BT１.４.４: 残りのデータE(KP_dc[P], K_ch[I] || KP_d[I])を、K_dc[P]で復号する。
処理BT１.４.５: 処理BT１.４.４で得られたデータについて、K_ch[I] || KP_d[I]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.２.３に記したものと同じである。
処理BT１.４.６: ０次セッション鍵K_s[P]０生成する。
処理BT１.４.７: 処理BT１.４.６で生成したK_s[P]０に自身に埋め込まれているDevice公開鍵KP_d[P]を連結し、処理BT１.４.５で受信したDevice公開鍵KP_d[I]で暗号化する。得られるデータはE(KP_d[I], K_s[P]０ || KP_d[P])である。ここで、処理BT１.４.３におけるRDCL_[P]とRDCL_[I]の発行日情報の比較の結果、RDCL_[P]の発行日の方が新しかった場合は、E(KP_d[I], K_s[P]０ || KP_d[P])に対し、RDCL_[P]を連結後、得られたデータ全体を処理BT１.４.５で得られたK_ch[I]で暗号化する。最終的に得られるデータは、E(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])である。
【０１５５】
処理BT１.４.１から処理BT１.４.７をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY BT CONNECTION命令２２０７１を発行する。Primal Deviceは命令を受信すると、処理BT１.４.７で生成したE(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])を、ホストモジュールへ送信する（２２０７１）。
ホストモジュール１１０は、E(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE SESSION KEY BT CONNECTION命令２２０８０命令を発行後、受信したデータをDeviceに送信する（２２０８１）。
【０１５６】
Inceptive Deviceは、E(K_ch[I], E(KP_d[I], K_s[P]０ || KP_d[P]) || RDCL_[P])を受信すると、２２０８２に示す下記の５つの処理を実行する。
処理BT１.５.１: 受信したデータを、K_ch[I]で復号する。K_ch[I]は、処理BT１.３.１において、自身で生成した鍵データである。
処理BT１.５.２: 処理BT１.５.１の結果にRDCL_[P]が含まれていた場合、データを分離し、データが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.５.３: 処理BT１.５.１と処理BT１.５.２の結果、受信したデータにRDCL_[P]が含まれていて、それが正当な形で含まれていたことが確認できた場合、自身に記録されているRDCL_[I]を、受信したRDCL_[P]で上書きする。
処理BT１.５.４: 残りのデータE(KP_d[I], K_s[P]０ || KP_d[P])を、K_d[I]０で復号する。K_d[I]は、自身の保護情報領域に埋め込まれている。
処理BT１.５.５: 処理UT１.５.４で得られたデータについて、K_s[P]０ || KP_d[P]が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
【０１５７】
処理BT１.５.１から処理BT１.５.５をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE SESSION KEY BT CONNECTION命令２２０９０を発行する。Inceptive Deviceは命令を受信すると、２２０９１に示す下記の３つの処理を実行する。
処理BT１.６.１: ０次セッション鍵K_s[I]０を生成する。
処理BT１.６.２: Connection Logに、処理BT１.５.５で受信したK_s[P]０及びKP_d[P]、処理BT１.６.１で生成したK_s[I]０、処理BT１.２.１で受信したDCC（K_CA, KP_dc[P]）に含まれていたPrimal DeviceのType Map TM_[P]を記録する。
処理BT１.６.３: 処理BT１.６.１で生成したK_s[I]０を、処理BT１.５.５で受信したK_s[P]０及びKP_d[P]で暗号化する。得られるデータは、E(KP_d[P], E(K_s[P]０, K_s[I]０))である。
【０１５８】
Inceptive Deviceにおいて、E(KP_d[P], E(K_s[P]０, K_s[I]０))が生成されると、Deviceは、生成されたデータをホストモジュール１１０へ送信する（２２０９２）。
ホストモジュール１１０は、E(KP_d[P], E(K_s[P]０, K_s[I]０))を受信すると、Primal Deviceに対してPUT INCEPTIVE DEVICE SESSION KEY BT CONNECTION命令２２１００命令を発行後、受信したデータをDeviceに送信する（２２１０１）。
【０１５９】
Primal Deviceは、E(KP_d[P], E(K_s[P]０, K_s[I]０))を受信すると、２２１０２に示す下記の３つの処理を実行する。
処理BT１.７.１: 受信したデータを、K_d[P]及びK_s[P]０で復号する。K_d[P]は、自身の保護情報領域に埋め込まれている鍵データであり、K_s[P]０は処理BT１.４.６において自身で生成した鍵データである。
処理UT１.７.２: 処理UT１.７.１で得られたデータについて、K_s[I]０が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT１.７.３: Connection Logに、処理BT１.４.５で受信したKP_d[I]、処理BT１.７.２で受信したK_s[I]０、処理BT１.４.６で生成したK_s[P]０、処理BT１.１.１で受信したDCC（K_CA, KP_dc[I]）に含まれていたPrimal DeviceのType Map TM_[I]を記録する。
以上処理BT１.７.３までを完了すると、共有Device公開鍵*KP_d[P]（共有Device秘密鍵*K_d[P]と同じ）、K_s[P]０、K_s[I]０の共有が完了する。
【０１６０】
ＢＴモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理シーケンス
ＢＴモードにより、Primal DeviceとInceptive Deviceの間で相互認証が完了すると、Primal DeviceからInceptive Deviceあるいはその逆の方向に関して、Usage Passを転送することができる。
まず、Primal DeviceからInceptive DeviceへUsage Passを転送する場合について、図２３を用いて説明する。記録モジュール１０２がPrimal Deviceとなって、磁気ディスク装置にUsage Passを転送する場合が、その一例である。尚、ＢＴモードにおけるPrimal DeviceからInceptive DeviceへのUsage Pass転送処理段階のことを、以下ではBT PI Transfer stageと呼ぶ。
【０１６１】
まず初めに、ホストモジュール１１０は、Primal Deviceに対してREAD USAGE PASS命令２３０００を発行する。そして、命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、２３００１においてPrimal Deviceに通知する。Primal Deviceは、命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、２３００２に示す下記の１つの処理を実行する。
処理BT２.１.１: 転送対象のUsage Passを、Usage Pass送信用モジュール内へ準備する。Primal Deviceが記録モジュールである場合、目的のUsage PassをUsage Pass Creator and Content Encrypter ６０６からモジュール ６０１へ送るような処理に相当する。
【０１６２】
ホストモジュール１１０は、Primal Deviceに処理BT２.１.１を実行させている間に、Inceptive Deviceに対しCREATE INCEPTVE DEVICE SESSION KEY UT TRANSFER命令１９０２０命令を発行する。Inceptive Deviceは、命令を受信すると、２３０１２に示す下記の２つの処理を実行する。
処理BT２.２.１: セッション鍵K_s[I]nを生成する。ここでnは、ここでnは、BT Connection stage完了後、本処理がn回目のBT PI Transfer stageであることを意味する。
処理BT２.２.２: 処理BT２.２.１で生成したK_s[I]nを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-１及びPrimal Deviceにおいて生成された最新のセッション鍵K_s[P]mを用いて、暗号化する。K_s[P]mは、Inceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行される度に生成されるものであり、BT Connection stageが完了してから、m回の転送処理が実行されたことを意味する。Inceptive DeviceからPrimal DeviceへのUsage Pass転送処理シーケンスの詳細は、図２４を用いて後述する。もし、一度もInceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Connection stageにおいて共有される０次セッション鍵K_s[P]０を、K_s[P]mとして用いる。得られるデータは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))である。
【０１６３】
処理BT２.２.１及び処理BT２.２.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPIVE DEVICE SESSION KEY BT TRANSFER命令２３０２０を発行する。Inceptive Deviceは命令を受信すると、処理BT２.２.２において生成されたデータE(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を、ホストモジュールへ送信する（２３０２１）。
ホストモジュール１１０は、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信すると、Primal Deviceに対しPUT INCEPTIVE DEVICE SESSION KEY BT TRANSFER命令２２０３０を発行し、続いて受信したデータをPrimal Deviceへ送信する（２３０３１）。
【０１６４】
Primal Deviceは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信すると、２３０３２に示す下記の３つの処理を実行する。
処理BT２.３.１: 受信したデータを、K_s[P]m及びK_s[I]n-１で復号する。両鍵データについては、処理BT２.２.２で説明した通りである。
処理BT２.３.２: 処理BT２.３.１で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT２.３.３: Transaction Logを生成する。ＢＴモードでのUsage Pass転送処理では、Primal DeviceのみTransaction Logの記録を行う。ＢＴモードにおけるTransaction Logの要素は、転送対象Usage PassのUsage Pass識別子、当Usage Pass転送処理におけるPrimal Deviceの役割（即ち、Usage Pass転送元「Source」であるか、同転送先「Destination」であるか）、Primal DeviceがUsage Passの転送先であった場合のみ受信予定のUsage Passの受信以前のUR_s、Primal DeviceがUsage Passの転送元であった場合のみ送信予定のUsage Passの送信以前のUsage Pass、Primal DeviceがUsage Passの転送先であった場合は同転送元におけるUsage Pass Location（読み出し元のアドレス）、Primal DeviceがUsage Passの転送元であった場合は同転送先におけるUsage Pass Location（記録先のアドレス）である。それらのうち、ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、このUsage Pass転送処理におけるPrimal Deviceの役割「Source」（図中では短縮形「S」）、送信対象Usage Passの送信前の当該Usage Pass、Usage PassのUsage Pass Location（記録先アドレス）である。
【０１６５】
処理BT２.３.１から処理BT２.３.３をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令２３０４０を発行する。命令に続き、Inceptive DeviceへのUsage Passの記録先アドレス情報を、２３０４１においてPrimal Deviceに対し送信する。尚、ＵＴモードの場合と同様、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。そこで、命令を受信すると、Primal Deviceは、２３０４２に示す下記の３つの処理を実行する。
処理BT２.４.１: Inceptive Deviceに対して送信するUsage Passを、処理BT２.１.１においてUsage Pass送信用モジュール内に準備されたUsage Passを元に、生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理BT２.４.２: Transaction LogにおけるUsage Pass Locationに、２３０４１で受信したInceptive DeviceでのUsage Passの記録先アドレスを記録する。
処理BT２.４.３: 処理BT２.４.１において生成された送信用Usage Passに対し、受信した命令がENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれであるかを示す識別子情報Action Indicator、及びUsage Pass || Action Indicatorに対するChecksumを計算し、連結する。連結処理の後、得られたデータをK_s[I]n及び*KP_d[I]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))である。Checksumの計算は、UT２.４.２に記載した通りである。
【０１６６】
処理BT２.４.１から処理BT２.４.３をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令２３０５０を発行する。Primal Deviceは、命令を受信すると、E(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))をホストモジュールへ送信する（２３０５２）。
ホストモジュール１１０はE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を受信すると、Inceptive Deviceに対しPUT USAGE PASS命令２３０６０を発行し、続いてE(*KP_d[I], E(K_s[I]n, Usage Pass || Action Indicator || Checksum))を送信する（２３０６１）。
【０１６７】
Inceptive Deviceは、命令及びデータを受信すると、２３０６２に示す下記の３つの処理を実行する。
処理BT２.５.１: 受信したデータを、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、処理BT１.５.４において得た共通鍵である。また、K_s[I]nは処理BT２.２.１において自身で生成したセッション鍵である。
処理BT２.５.２: 処理UT２.５.１で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載してある。
処理UT２.５.３: 受信したUsage Passを制限記憶部へ記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
その後、Inceptive Deviceにおける制限記憶部２２３へのUsage Passの記録が正常に終了したか否かを確認するために、ホストモジュールは、Inceptive Deviceに対し、CHECK EXECUTION STATUS命令２３０７０を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が２３０７１において送信される。
以上に記したBT Transfer stageを繰り返すことにより、Connection stageを繰り返し行わなくても、Primal DeviceからInceptive Deviceに対し、連続的にUsage Pass転送を実行することができる。
【０１６８】
ＢＴモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理シーケンス
次に、図２４を参照して、Inceptive DeviceからPrimal DeviceへUsage Passを転送する場合について説明する。磁気ディスク装置がPrimal Deviceとなって、再生モジュール１０４にUsage Passを転送する場合が、その一例である。尚、ＢＴモードにおけるInceptive DeviceからPrimal DeviceへのUsage Pass転送処理段階のことを、以下ではBT IP Transfer stageと呼ぶ。
【０１６９】
まず初めに、ホストモジュール１１０は、Inceptive Deviceに対してREAD USAGE PASS命令２４０００を発行する。そして、この命令に続いて、Usage Passが記録されている場所及び読み出すUsage Passの数を、２４００１においてPrimal Deviceに通知する。Inceptive Deviceは、この命令とUsage Passが記録されている場所及び読み出すUsage Passの数についての情報を受信すると、２４００２に示す下記の１つの処理を実行する。
処理BT３.１.１: 制限記憶部において指定されたアドレスから転送対象のUsage Passを読み出し、Usage Pass Buffer １１１０へ送信する。
【０１７０】
処理BT３.１.１をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、Primal Deviceに対し、GET MASKED USAGE PASS WITH KEYED HASH命令２４０１０を発行する。Inceptive Deviceは、命令を受信すると、２４０１１に示す下記の２つの処理を実行する。
処理BT３.２.１: READ USAGE PASS命令２４０００で制限記憶部から読み出したUsage PassからMasked Usage Passを生成し、それに対しGET MASKED USAGE PASS WITH KEYED HASH命令２４０１０を受信した時点で最新のセッション鍵K_s[P]m-１及びK_s[I]nを連結したデータを元に、Hash値を計算する。命令２４０００で複数のUsage Passを一度に読み出している場合は、個々のUsage Passに対してHash値を計算する。
処理BT３.２.２: 処理BT３.２.１で生成した個々のHash値を、個々のMasked Usage Passに連結する。得られるデータは、MUP || H(K_s[P]m-１ || K_s[I]n || MUP)である。
【０１７１】
Inceptive Deviceは処理BT３.２.２を終えると、生成されたデータMUP || H(K_s[P]m-１ || K_s[I]n || MUP)を、ホストモジュールへ送信する（２４０１２）。
ホストモジュール１１０は、MUP || H(K_s[P]m-１ || K_s[I]n || MUP)受信すると、Primal Deviceに対し、PUT MASKED USAGE PASS WITH KEYED HASH命令を発行し、続いてデータをPrimal Deviceへ送信する。
【０１７２】
Primal Deviceは、データを受信すると、２４０２２に示す下記の１つの処理を実行する。
処理BT３.３.１: 受信したデータについて、改竄が行われていないかどうかを検証する。自身が保持しているセッション鍵K_s[P]m-１及びK_s[I]n及び受信したMUPを用いてHash値H(K_s[P]m-１ || K_s[I]n || MUP)を計算し、それが受信したHasht値と一致していれば、改竄が行われていないと判断する。
処理BT３.３.１をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングで、Primal Deviceに対し、CREATE PRIMAL DEVICE SESSION KEY BT TRANSFER命令２４０３０を発行し、続いて転送対象Usage PassのUsage Pass識別子を送信する（２４０３１）。
【０１７３】
Primal Deviceは、命令及びデータを受信すると、２４０３２に示す下記の４つの処理を実行する。
処理BT３.４.１: ２４０３１で受信したUsage Pass識別子と、２４０２１で受信したMasked Usage PassのUsage Pass識別子が一致しているか確認する。
処理BT３.４.２: Transaction Logを生成する。ここで記録されるのは、転送対象Usage PassのUsage Pass識別子、当Usage Pass転送処理におけるPrimal Deviceの役割「Destination」（図中では短縮形「D」）、２４０２１で受信したMasked Usage Pass中に含まれるUR_s、Inceptive Device中の制限記憶部におけるUsage Pass Location（記録元アドレス）である。
処理BT３.４.３: セッション鍵K_s[P]mを生成する。ここでmは、BT Connection stage完了後、m回目のBT IP Transfer stageにおいて生成されたセッション鍵であることを意味する。
処理BT３.４.４: 処理BT３.４.３で生成したK_s[P]mを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[P]m-１及びInceptive Deviceにおいて生成された最新のセッション鍵K_s[P]nを用いて、暗号化する。K_s[I]nは、BT PI Transfer stageが実行される度に生成されるものであり、BT Connection stageが完了してから、n回の転送処理が実行されたことを意味する。尚、BT PI Transfer stageについては、図２３を用いて前節で説明済みである。もし、一度もPrimal DeviceからInceptive Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Connection stageにおいて共有される０次セッション鍵K_s[I]０を、K_s[I]nとして用いる。得られるデータは、E(K_s[I]n, E(K_s[P]m-１, K_s[P]m))である。
【０１７４】
処理BT３.４.１から処理BT３.４.４をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY BT TRANSFER命令２４０４０を発行する。Primal Deviceは命令を受信すると、処理BT３.４.４において生成されたデータを、ホストモジュールへ送信する（２４０４１）。
ホストモジュール１１０は、E(K_s[I]n, E(K_s[P]m-１, K_s[P]m))を受信すると、Inceptive Deviceに対しPUT PRIMAL DEVICE SESSION KEY BT TRANSFER命令２４０５０を発行後、受信したデータをInceptive Deviceへ送信する（２４０５１）。
【０１７５】
Inceptive Deviceは、E(K_s[I]n, E(K_s[P]m-１, K_s[P]m))を受信すると、２４０５２に示す下記の２つの処理を実行する。
処理BT３.５.１: 受信したデータを、K_s[I]n及びK_s[P]m-１で復号する。両鍵データについては、処理BT３.２.１及び処理BT３.４.４で説明した通りである。
処理BT３.５.２: 処理UT３.５.１で得られたデータについて、K_s[P]mが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
【０１７６】
処理BT３.５.１及び処理BT３.５.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS COPYあるいはENCRYPT USAGE PASS MOVEあるいはENCRYPT USAGE PASS PLAY命令２４０６０を発行する。尚、ＵＴモードの場合と同様に、どの命令を受信した場合にどのようなUR_sのUsage Passを送信するか、そして複製や再生の場合Primal Deviceに残るUsage PassのUR_sはどのように変更しなければならないか等については、あらかじめ全て規定されているものとする。
そこで、この命令を受信すると、Inceptive Deviceは、２４０６２に示す下記の２つの処理を実行する。
処理BT３.６.１: Primal Deviceに対して送信するUsage Passを、処理BT３.１.１においてUsage Pass Bufferへ送信されたUsage Passを元に、モジュール １１０３内に生成する。通常、UPIDやK_cなどはそのまま複製され、UR_sのみ規定に従う形で変更される。
処理BT３.６.２: 処理BT３.６.１において生成された送信用Usage Passに対し、受信した命令がENCRYPT USAGE PASS COPY/MOVE/PLAYのいずれであるかを示す識別子情報Action Indicator、及びUsage Pass || Action Indicatorに対するChecksumを計算し、連結する。連結処理の後、得られたデータをK_s[P]m及び*KP_d[P]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))である。Checksumの計算は、UT２.４.２に記載した通りである。
【０１７７】
以上、処理BT３.６.１及び処理BT３.６.２をInceptive Deviceが実行中、ホストモジュールは、処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS命令２４０７０を発行する。Inceptive Deviceは、命令を受信すると、２４０７１に示す下記の１つの処理を実行する。
処理BT３.７.１: Usage Pass Buffer中のUsage PassのUR_sを、規定に従って変更する。そして、Usage PassをUsage Passが制限記憶部中で元来記録されていた場所に、上書きする。尚、命令２４０６０がENCRYPT USAGE PASS MOVEであった場合、有効性指示フラグの値は「無効」にされる。
【０１７８】
Inceptive Deviceは、処理BT３.７.１を終了すると、処理で生成されたデータを、ホストモジュールへ送信する（２４０７２）。
ホストモジュール１１０はE(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))を受信すると、Primal Deviceに対しPUT USAGE PASS命令２４０８０を発行し、またDeviceに対し、E(*KP_d[P], E(K_s[P]m, Usage Pass || Action Indicator || Checksum))を送信する（２４０８１）。
【０１７９】
Inceptive Deviceは、命令及びデータを受信すると、２４０８２に示す下記の２つの処理を実行する。
処理BT３.８.１: 受信したデータを、*K_d[P]及びK_s[P]mで復号する。*K_d[P]は、処理BT１.７.１において得た共通鍵である。また、K_s[P]mは処理BT３.４.３において自身で生成したセッション鍵である。
処理BT３.８.２: 処理UT３.８.１で得られたデータについて、Usage Pass || Action Indicator || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載した通りである。
【０１８０】
その後、Inceptive DeviceにおけるUsage Passの受信が正常に終了したか否かを確認するために、ホストモジュールは、Primal Deviceに対し、CHECK EXECUTION STATUS命令２４０９０を発行しても良い。Primal Deviceからホストモジュールへは、実行状態が２４０９１において送信される。
以上に記したBT Transfer stageを繰り返すことにより、Connection stageを繰り返し行わなくても、Inceptive DeviceからPrimal Deviceに対し、連続的にUsage Pass転送を実行することができる。
【０１８１】
ＢＴモードにおけるDevice間再相互認証処理シーケンス
Primal DeviceとInceptive Deviceの間で１度BT Connection stageが行われ、両Deviceの間で互いの共有Device公開鍵KP_d[P]及びKP_d[I]、０次セッション鍵K_s[P]０及びK_s[I]０、の共有及び鍵のConnection Logへの記録が終了した後、記録再生装置に電源供給停止等の異常が発生して、Usage Pass送信用モジュール及び同受信用モジュールからセッション鍵が失われてしまった場合、Connection stageと比べ、少ない処理で相互認証を再完了することができる。この再相互認証処理について、図２５を用いて説明する。尚、ＢＴモードにおける本処理段階のことを、以下ではBT Reconnection stageと呼ぶ。
【０１８２】
まず、BT Connection stageが２５０００において完了した後、異常発生の理由により、Primal DeviceとInceptive Deviceの間で分断が発生し、その時点までで最新のセッション鍵K_s[P]m及びK_s[I]nや、共有Device公開鍵*KP_d[P]や*KP_d[I]が、両Deviceから失われてしまったとする（２５０１０）。
この場合、ホストモジュール１１０は、まずPrimal Deviceに対し、CREATE PRIMAL DEVICE SESSION KEY BT RECONNECTION命令２５０１０を発行する。
Primal Deviceは、命令を受信すると、２５０１１に示す下記の２つの処理を実行する。
処理BT４.１.１: 新しい０次セッション鍵K_s[P]０'を生成する。
処理BT４.１.２: 処理BT４.１.１で生成したK_s[P]０'を、自身のConnection Logに記録されているセッション鍵K_s[I]CL及びDevice公開鍵KP_d[I]CLで暗号化する。鍵K_s[I]CL及びKP_d[I]CLは、Connection Logに記録されていた鍵データであるということを表している。最終的に得られるデータは、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))である。
【０１８３】
処理BT４.１.１及び処理BT４.１.２を実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET PRIMAL DEVICE SESSION KEY BT RECONNECTION命令２５０２０を発行する。Primal Deviceは、命令を受信すると、処理BT４.１.２で生成したデータE(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))を、ホストモジュールへ送信する。
ホストモジュール１１０は、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))を受信すると、Inceptive Deviceに対してPUT PRIMAL DEVICE SESSION KEY BT RECONNECTION命令２５０３０命令を発行した後、受信したデータをInceptive Deviceに送信する（２５０３１）。
Inceptive Deviceは、E(KP_d[I]CL, E(K_s[I]CL, K_s[P]０'))を受信すると、２５０３２に示す下記の２つの処理を実行する。
処理BT４.２.１: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[I]及びConnection Log中に含まれるセッション鍵K_s[I]CLである。
処理BT４.２.２: 処理UT４.２.１の結果として、K_s[P]０'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
【０１８４】
処理BT４.２.１及び処理BT４.２.２を実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPTIVE DEVICE SESSION KEY BT RECONNECTION命令２５０４０を発行する。Inceptive Deviceは、命令を受信すると、２５０４１に示す下記の３つの処理を実行する。
処理BT４.３.１: 新しい０次セッション鍵K_s[I]０'を生成する。
処理BT４.３.２: 処理BT４.３.１で生成したK_s[I]０'を、自身のConnection Logに記録されているセッション鍵K_s[P]CL及びDevice公開鍵KP_d[P]CLで暗号化する。鍵K_s[P]CL及びKP_d[P]CLは、Connection Logに記録されていた鍵データであるということを表している。最終的に得られるデータは、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))である。
処理BT４.３.３: 処理BT４.２.２で受信したK_s[P]０'、処理BT４.３.１で生成したK_s[I]０'を、Connection Logに上書き記録する。KP_d[P]及びTM_[P]は、そのまま保持する。
【０１８５】
Inceptive Deviceは、処理BT４.３.３を終了すると、処理BT４.３.２で生成したデータE(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))をホストモジュールへ送信する（２５０４０）。
ホストモジュール１１０は、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))を受信すると、Primal Deviceに対してPUT INCEPTIVE DEVICE SESSION KEY BT RECONNECTION命令２５０５０命令を発行後、受信したデータをPrimal Deviceに送信する（２５０５１）。
Primal Deviceは、E(KP_d[P]CL, E(K_s[P]CL, K_s[I]０'))を受信すると、２５０５２に示す下記の３つの処理を実行する。
処理BT４.４.１: 受信したデータを復号する。復号は、自身の保護情報領域に埋め込まれているK_d[P]及びConnection Log中に含まれるセッション鍵K_s[P]CLである。
処理BT４.４.２: 処理UT４.４.１の結果として、K_s[I]０'が正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
処理BT４.４.３: 処理BT４.４.２で受信したK_s[I]０'、処理BT４.１.１で生成したK_s[P]０'を、Connection Logに上書き記録する。KP_d[I]及びTM_[I]は、そのまま保持する。
【０１８６】
処理UT４.４.３が完了すると、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'、K_s[I]０'の共有が完了する。以上の処理に続いてBT PI Transfer stageを実行する場合、K_s[I]n-１としては、K_s[I]０'を、BT IP Transfer stageを実行する場合、K_s[P]m-１としてはK_s[P]０'を用いる。
【０１８７】
BT PI Transfer stageに対するUsage Pass復旧処理シーケンス
BT PI Transfer stageにおいてUsage Passの移動が行われている最中に、記録再生装置に異常が発生して、Primal DeviceからもInceptive Deviceからも転送処理中のUsage Passが失われてしまった場合、Primal Deviceにおいて、元来存在したものと同じUR_sを伴った形で、Usage Passを復旧する。このUsage Pass復旧処理について、図２６を用いて説明する。ＢＴモードにおける本処理段階のことを、以下ではBT PI Recovery stageと呼ぶ。
【０１８８】
まず、BT PI Transfer stageにおいて、Inceptive DeviceがPUT USAGE PASS命令２６０１０及びそれに続いてUsage Pass ２６０１１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が生じ、２６０１１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[I]n及び*KP_d[I]（*K_d[I]）が、両Deviceから失われてしまったとする（２６０２０）。この場合、まず前節で説明したBT Reconnection stageが実行され、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'、K_s[I]０'が新たに共有される。
【０１８９】
BT Reconnection stageを終えると、ホストモジュール１１０は、まずPrimal Deviceに対し、SEARCH TRANSACTION LOG BT RECOVERY命令２６０３０を発行する。そして、命令に続き、２１０１１で送信中であったUsage PassのUsage Pass識別子を、送信する（２６０３１）。
Primal Deviceは、識別子を受信すると、２６０３２に示す下記の１つの処理を実行する。
処理BT５.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
【０１９０】
処理BT５.１.１をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS LOCATION命令２６０４０を発行する。命令を受信すると、Primal Deviceは、処理BT５.１.１で見出されたTransaction Log中に記録されているUsage Pass Location情報を、ホストモジュールへ送信する（２６０４１）。
ホストモジュール１１０は、Usage Pass Location情報を受信すると、Inceptive Deviceに対し、SEARCH USAGE PASS BT RECOVERY命令２６０５０を発行し、続いて受信したデータを送信する（２６０５１）。
【０１９１】
Inceptive Deviceは、Usage Pass Location情報を受信すると、２６０５２に示す下記の３つの処理を実行する。
処理BT５.２.１: 制限記憶部において、受信したUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理BT５.２.２: 処理UT５.２.１で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理BT５.２.３: ＢＴモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || 処理BT５.２.１で見出されたUsage PassのUR_s || 処理BT５.２.２で設定したUsage Pass Status || ２６０４１で受信したUsage Pass Location || Hash値である。ここでHash値は、K_s[P]m || K_s[I]n || UPID || UR_s || Usage Pass Status || Usage Pass Locationから計算される。ここで用いられるK_s[P]m |及びK_s[I]nは、Connection stageあるいはReconnection stage完了後、その時点で共有されている最新のセッション鍵である。stage完了後、m回のBT PI Transfer stage及びn回のBT IP Transfer stageが実行されたことを意味している。本処理で生成されるTransaction Statusを、以下ではBT PI Transaction Statusと呼ぶ。
【０１９２】
処理BT５.２.１から処理BT５.２.３をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET TRANSACTION STATUS BT RECOVERY命令２６０６０を発行する。命令を受信すると、Inceptive Deviceは、処理BT５.２.３で生成されたBT PI Transaction Statusを、ホストモジュールへ送信する（２６０６１）。
ホストモジュール１１０は、BT PI Transaction Statusを受信すると、Primal Deviceに対し、VERIFY TRANSACTION STATUS BT PI RECOVERY命令２６０７０を発行し、続いて受信したBT PI Transaction Statusを送信する（２６０７１）。
Primal Deviceは、BT PI Transaction Statusを受信すると、２６０７２に示す下記の２つの処理を実行する。
処理BT５.３.１: BT PI Transaction Statusの検証と、BT PI Transaction Statusに含まれるUsage Pass識別子、Usage Pass Status、Usage Pass Locationの確認を行う。BT PI Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]mとK_s[I]nから計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、Usage Pass Statusは復旧可否の判定、Usage Pass Locationは自身に記録されていたUsage Pass Locationで指定される制限記憶部内のUsage Pass記憶領域を正しく検索したかを確認するために用いられる。Usage Pass Statusが「無効」や「未記録」であった場合は、Primal Deviceにおいて、Usage Passの復旧処理が行われる。一方、Usage Pass Locationが、自身のTransaction Logに記録されていたものと異なっていた場合は、Usage Passの復旧処理は行われない。
処理UT５.３.２: Usage Pass復旧処理を実行する。Usage Passの復旧は、対象のUsage Passの有効性指示フラグが「無効」となっていた場合はそれを「有効」にし、復旧対象のUsage Passを、Transaction Logに記録されていたUsage Passで上書きすることによって達成される。
処理BT５.３.２が完了すると、Primal Deviceには、送信する以前のUsage Passが存在するようになる。
【０１９３】
BT IP Transfer stageに対するUsage Pass復旧処理シーケンス
BT IP Transfer stageにおいてUsage Passの移動が行われている最中に、記録再生装置に異常が発生して、Primal DeviceからもInceptive Deviceからも転送処理中のUsage Passが失われてしまった場合、Inceptive Deviceにおいて、元来存在したものと同じUR_sを伴った形で、Usage Passを復旧することができる。このUsage Pass復旧処理について、図２７を用いて説明する。ＢＴモードにおける本処理段階のことを、以下ではBT IP Recovery stageと呼ぶ。
【０１９４】
まず、BT IP Transfer stageにおいて、Primal DeviceがPUT USAGE PASS命令２７０１０及びそれに続いてUsage Pass ２７０１１を受信しているという状況を想定する。そして、Usage Passの受信処理が完全に完了しないうちに、異常が発生して、Primal DeviceとInceptive Deviceの間で分断が生じ、２７００１で流れるUsage Passを暗号化するために用いられていたセッション鍵K_s[P]n及び*KP_d[P]（*K_d[P]）が、両Deviceから失われてしまったとする（２７０２０）。この場合、まず前節に記したBT Reconnection stageが実行され、*KP_d[P]（*K_d[P]と同じ）、*KP_d[I]（*K_d[I]と同じ）、K_s[P]０'、K_s[I]０'が新たに共有される。
【０１９５】
BT Reconnection stageを終えると、ホストモジュールは、まずPrimal Deviceに対し、SEARCH TRANSACTION LOG BT RECOVERY命令２７０３０を発行する。そして、命令に続き、２７０１１で送信中であったUsage PassのUsage Pass識別子を、送信する（２７０３１）。
Primal Deviceは、識別子を受信すると、２７０３２に示す下記の１つの処理を実行する。
処理BT６.１.１: 保護情報領域の中で、識別子と同じ識別子値が記録されているTransaction Logを検索する。
【０１９６】
処理BT６.１.１をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET USAGE PASS LOCATION命令２６０４０を発行する。命令を受信すると、Primal Deviceは、処理BT６.１.１で見出されたTransaction Log中に記録されているUsage Pass Location情報を、ホストモジュールへ送信する（２７０４１）。
ホストモジュール１１０は、Usage Pass Location情報を受信すると、Inceptive Deviceに対し、SEARCH USAGE PASS BT RECOVERY命令２７０５０を発行し、続いて受信したデータを送信する（２７０５１）。
【０１９７】
Inceptive Deviceは、Usage Pass Location情報を受信すると、２７０５２に示す下記の３つの処理を実行する。
処理BT６.２.１: 制限記憶部において、受信したUsage Pass Locationで指定される制限記憶部中のUsage Pass記憶領域を検索する。
処理BT６.２.２: 処理UT６.２.１で見出されたUsage Passについて、その有効性指示フラグの値を調べ、Usage Pass Statusに「有効」「無効」「未記録」のいずれかの値を設定する。
処理BT６.２.３: ＢＴモード用Transaction Statusを生成する。Transaction Statusは、復旧対象Usage PassのUPID || 処理BT６.２.１で見出されたUsage PassのUR_s || 処理BT６.２.２で設定したUsage Pass Status || ２７０４１で受信したUsage Pass Location || Hash値である。ここでHash値は、K_s[P]m || K_s[I]n-１ || UPID || UR_s || Usage Pass Status || Usage Pass Locationから計算される。ここで用いられるK_s[P]m |及びK_s[I]n-１は、Connection stageあるいはReconnection stage完了後、その時点で共有されている最新のセッション鍵である。stage完了後、m回のBT PI Transfer stage及びn-１回のBT IP Transfer stageが実行されたことを意味している。本処理で生成されるTransaction Statusを、以下ではBT IP Transaction Statusと呼ぶ。
【０１９８】
処理BT６.２.１から処理BT６.２.３をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET TRANSACTION STATUS BT RECOVERY命令２７０６０を発行する。命令を受信すると、Inceptive Deviceは、処理BT６.２.３で生成されたBT IP Transaction Statusを、ホストモジュールへ送信する（２７０６１）。
ホストモジュール１１０は、BT IP Transaction Statusを受信すると、Primal Deviceに対し、VERIFY TRANSACTION STATUS BT IP RECOVERY命令２７０７０を発行し、続いて受信したBT IP Transaction Statusを送信する（２７０７１）。
【０１９９】
Primal Deviceは、BT IP Transaction Statusを受信すると、２７０７２に示す下記の１つの処理を実行する。
処理BT６.３.１: BT IP Transaction Statusの検証と、BT IP Transaction Statusに含まれるUsage Pass識別子、UR_s、Usage Pass Status、Usage Pass Locationの確認を行う。BT IP Transaction Statusの検証は、データに含まれるHash値を、自身が保持しているK_s[P]mとK_s[I]n-１から計算することによって行う。計算結果が含まれているHash値と一致すれば、データの改竄は行われていないと判断される。また、Usage Pass識別子は、今回復旧対象のものであるどうかの確認、UR_s及びUsage Pass Statusは復旧可否の判定、Usage Pass Locationは自身に記録されていたUsage Pass Locationで指定される制限記憶部内のUsage Pass記憶領域を正しく検索したかを確認するために用いられる。Usage Pass Statusが「無効」であったり、BT IP Transaction Statusに含まれるUR_sを処理BT６.１.１で見出されたTransaction Logに記録されているUR_sに照らし合わせた結果、Inceptive Deviceに残っている目的のUsage PassのUR_sが変化してしまっていることが判明したりした場合は、以降のUsage Pass復旧処理が実行される。
【０２００】
処理BT６.３.１をPrimal Deviceが実行中、それに並列して、ホストモジュール１１０はCREATE INCEPTIVE DEVICE SESSION KEY BT TRANSFER命令２７０８０を発行する。
Inceptive Deviceは、命令を受信すると、２７０８１に示す下記の２つの処理を実行する。
処理BT６.４.１: セッション鍵K_s[I]nを生成する。ここでnは、ここでnは、BT Connection stage完了後、本処理がn回目のBT IP Transfer stageであることを意味する。
処理BT６.４.２: 処理BT６.４.１で生成したK_s[I]nを、１つ前のUsage Pass転送実行時に生成したセッション鍵K_s[I]n-１及びPrimal Deviceにおいて生成された最新のセッション鍵K_s[P]mを用いて、暗号化する。K_s[P]mは、BT Connection stageが完了してから、m回のBT IP Transfer stageが実行されたことを意味する。もし、一度もInceptive DeviceからPrimal Deviceに対してUsage Pass転送処理が実行されていなかった場合は、BT Reconnection stageにおいて共有される０次セッション鍵K_s[P]０'を、K_s[P]mとして用いる。得られるデータは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))である。
【０２０１】
処理BT６.４.１及び処理BT６.４.２をInceptive Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET INCEPIVE DEVICE SESSION KEY BT TRANSFER命令２７０９０を発行する。Inceptive Deviceは命令を受信すると、処理BT６.４.２において生成されたデータE(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を、ホストモジュールへ送信する（２７０９１）。
ホストモジュール１１０は、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信すると、Primal Deviceに対しPUT INCEPTIVE DEVICE SESSION KEY BT RETRANSFER命令２７１００を発行し、続いて受信したデータをPrimal Deviceへ送信する（２７１０１）。
【０２０２】
Primal Deviceは、E(K_s[P]m, E(K_s[I]n-１, K_s[I]n))を受信し、処理BT６.３.１においてInceptive Device中のUsage Passの復旧処理が必要であることが判明すると、２７１０２に示す下記の２つの処理を実行する。
処理BT６.５.１: 受信したデータを、K_s[P]m及びK_s[I]n-１で復号する。両鍵データについては、処理BT６.２.３で説明した通りである。
処理BT６.５.２: 処理BT６.５.１で得られたデータについて、K_s[I]nが正当な形で含まれていたかどうかを確認する。確認するための手段は、処理UT１.３.３に記したものと同じである。
【０２０３】
処理BT６.５.１及び処理BT６.５.２をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでENCRYPT USAGE PASS RECOVER命令２７１１０を発行する。命令を受信すると、Primal Deviceは、２７１１１に示す下記の２つの処理を実行する。
処理BT６.６.１: 処理BT６.２.１で見出されたTransaction Logに記録されているUPIDとUR_sを連結し、Usage Pass送信用モジュール１３０１へ送信する。
処理BT６.６.２: 処理BT６.６.１においてUsage Pass送信用モジュール １３０１に準備されたUPID || UR_sについて、Checksumを計算し、データに連結する。そして、得られたデータを、K_s[I]n及び*KP_d[I]を用いて暗号化する。即ち、共通鍵による二重暗号化である。得られるデータは、E(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))である。Checksumの計算は、UT２.４.２に記載した通りである。
【０２０４】
処理BT６.６.１及び処理BT６.６.２をPrimal Deviceが実行中、ホストモジュールは処理が終了するタイミングを予測し、適切なタイミングでGET RECOVER USAGE PASS命令２７１２０を発行する。Primal Deviceは、命令を受信すると、E(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))をホストモジュールへ送信する（２７１２１）。
ホストモジュール１１０はE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))を受信すると、Inceptive Deviceに対しRECOVER USAGE PASS命令２７１３０を発行し、続いてE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))及びデータの書き込み先Usage Pass Locationを送信する（２７１３１）。
【０２０５】
Inceptive Deviceは、命令及びデータを受信すると、２３０６２に示す下記の４つの処理を実行する。
処理BT６.７.１: 受信したデータE(*KP_d[I], E(K_s[I]n, UPID || UR_s || Checksum))を、*K_d[I]及びK_s[I]nで復号する。*K_d[I]は、Reconnection stage ２７０２１において得た共通鍵である。また、K_s[I]nは処理BT６.４.１において自身で生成したセッション鍵である。
処理BT６.７.２: 処理BT６.７.１で得られたデータについて、UPID || UR_s || Checksumが正当な形で含まれていたかどうかを確認する。確認は、Checksumを検証すること及び処理UT１.３.３に記した手段を用いて行われる。Checksumによる検証方法は、処理UT２.４.２に記載してある。
処理BT６.７.３: 受信したUsage Pass Locationで指定される制限記憶部のUsage Pass記録領域からUsage PassをUsage Pass Bufferへ読み出し、Usage PassのUPIDが、処理BT６.７.２で復号した結果得られたUPIDと一致するか確認する。一致しない場合は、処理を中断する。
処理BT６.７.４: 受信したUsage Passを制限記憶部へ記録する。Usage Passの記録を行う際には、有効性指示フラグを「有効」に設定する。
【０２０６】
その後、Inceptive DeviceにおけるUsage Passの制限記憶部への記録が正常に終了したか否かを確認するために、ホストモジュールは、Inceptive Deviceに対し、CHECK EXECUTION STATUS命令２７１４０を発行しても良い。Inceptive Deviceからホストモジュールへは、実行状態が２７１４１において送信される。
処理BT６.７.２が完了すると、Inceptive Deviceには、送信する以前のUsage Passが存在するようになる。
【０２０７】
以上、実施例について説明したが、本発明は上記実施例に限定されない。また、種々変形して実施したり、また他の装置やシステムにも応用できるであろう。
例えば、上記実施例において説明された命令やモジュール等の呼び名は、あくまで一例であって上記の例に限定されない。例えば、上記実施例におけるユーセジパス（Usage Pass）は、ライセンス情報、或いは機密情報と呼ばれる場合もあろう。
【０２０８】
また、上記実施例では、記録再生装置と磁気ディスク装置を含むシステムにおけるコンテンツデータのセキュリティ管理について述べたものであるが、他の例によるシステム及びその構成装置としては、記録再生装置や磁気ディスク装置以外の装置に適用することも可能である。即ち、本発明に係る、コンテンツデータの復号化を管理するための制御情報を取扱う特徴的な処理機能を有すれば、記録再生装置及び磁気ディスク装置に限定されない。この特徴的な処理機能を有する限りにおいて、例えば、磁気ディスク装置は、半導体メモリを含む記憶装置でもよく、また、記録再生装置は、記憶装置が接続されるホストコンピュータでもよい。
【０２０９】
また、他の変形例においては、上記実施例の鍵データ等を記憶する保護記憶領域は、論理的に対タンパ性が確保されていれば、必ずしも物理的に対タンパ性を有するメモリであることを要しない。
【図面の簡単な説明】
【０２１０】
【図１】本発明の一実施例が適用される記録再生装置を含むのデータ保護システムを示す概略構成図。
【図２】一実施例による脱着可能な磁気ディスク装置の構成図。
【図３】一実施例において使用されるデータ、情報、及び記号法等を示す表。
【図４】一実施例において使用されるデータの復号条件や復号鍵をまとめたデータ（Usage Pass）の構成図。
【図５】一実施例による図２の磁気ディスク装置におけるＵＴモードを実現するUsage Pass Tranfer モジュール５３０を示す図。
【図６】一実施例による記録再生装置におけるＵＴモードを実現する記録専用の機能モジュールを示す図。
【図７】一実施例による記録再生装置におけるＵＴモードを実現する復号専用の機能モジュールを示す図。
【図８】一実施例による記録再生装置におけるＵＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。
【図９】一実施例による磁気ディスク装置におけるＵＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。
【図１０】一実施例による磁気ディスク装置における、Usage Passを記録する、対タンパ性を有する静的な記憶領域を示す図。
【図１１】磁気ディスク装置における、ＢＴモードを実現する機能モジュールを示す図。
【図１２】記録再生装置における、ＢＴモードに従って、Usage Pass送信を実現する記録専用の機能モジュールを示す図。
【図１３】記録再生装置における、ＢＴモードに従って、Usage Pass受信を実現する復号専用の機能モジュールを示す図。
【図１４】記録再生装置における、ＢＴモードに従って、磁気ディスク装置との間で相互認証処理を実現する機能モジュールを示す図。
【図１５】記録再生装置における、ＢＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報、Usage Pass転送処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。
【図１６】磁気ディスク装置における、ＵＴモードにおいて用いられる、証明書、公開鍵、秘密鍵、相互認証処理のログ情報などの秘匿情報を記録する、対タンパ性を有する静的な記憶領域を示す図。
【図１７】一実施例によるUsage Pass転送処理におけるアクセスモードの認識、設定のための処理シーケンスを示す図。
【図１８】一実施例における、ＵＴモードに従って記録再生装置と記憶装置の間で行われる相互認証処理シーケンスを示す図。
【図１９】一実施例における、ＵＴモードに従って記録再生装置と磁気ディスク装置の間で行われるUsage Pass転送処理シーケンスを示す図。
【図２０】一実施例における、ＵＴモードに従って記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シーケンスを示す図。
【図２１】一実施例における、ＵＴモードに従って記録再生装置と磁気ディスク装置の間で行われる、消失したUsage Passの復旧処理シーケンスを示す図。
【図２２】一実施例における、ＢＴモードに従って記録再生装置と磁気ディスク装置の間で行われる相互認証処理シーケンスを示す図。
【図２３】一実施例における、ＢＴモードに従って記録再生装置から磁気ディスク装置に対して送信される、Usage Pass転送処理シーケンスを示す図。
【図２４】一実施例における、ＢＴモードに従って磁気ディスク装置から記録再生装置に対して送信される、Usage Pass転送処理シーケンスを示す図。
【図２５】一実施例における、ＢＴモードに従って記録再生装置と磁気ディスク装置の間で行われる簡略化された再相互認証処理シーケンスを示す図。
【図２６】一実施例における、ＢＴモードに従って記録再生装置から磁気ディスク装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シーケンスを示す図。
【図２７】一実施例における、ＢＴモードに従って磁気ディスク装置から記録再生装置に対して送信されたUsage Passが消失した場合における、消失したUsage Passの復旧処理シーケンスを示す図。
【図２８】一実施例における、ホストモジュールとデバイス２間における命令の転送のシーケンスを示す図。
【符号の説明】
【０２１１】
１００：ネットワークインタフェース、  １０１：保護情報領域  １０２：記録モジュール  １０３：再生モジュール  １０５：ユーザインタフェースブリッジ  １０６，１０７：外部ストレージインタフェース  １０８：プロセッサ  
１１０：ホストモジュール  １１１：ホストセキュリティマネージャ  １１２：記録再生装置  １５０：配信サーバ  １２５、１２６、２４０：磁気ディスク装置  
２２１：ユーザパス転送モジュール  ２２２：制限記憶制御部  ２２３：制限記憶部  ２３１：プロセッサ
【図１】
0004848163.tif 000002
【図２】
0004848163.tif 000003
【図３】
0004848163.tif 000004
【図４】
0004848163.tif 000005
【図５】
0004848163.tif 000006
【図６】
0004848163.tif 000007
【図７】
0004848163.tif 000008
【図８】
0004848163.tif 000009
【図９】
0004848163.tif 000010
【図１０】
0004848163.tif 000011
【図１１】
0004848163.tif 000012
【図１２】
0004848163.tif 000013
【図１３】
0004848163.tif 000014
【図１４】
0004848163.tif 000015
【図１５】
0004848163.tif 000016
【図１６】
0004848163.tif 000017
【図１７】
0004848163.tif 000018
【図１８】
0004848163.tif 000019
【図１９】
0004848163.tif 000020
【図２０】
0004848163.tif 000021
【図２１】
0004848163.tif 000022
【図２２】
0004848163.tif 000023
【図２３】
0004848163.tif 000024
【図２４】
0004848163.tif 000025
【図２５】
0004848163.tif 000026
【図２６】
0004848163.tif 000027
【図２７】
0004848163.tif 000028
【図２８】
0004848163.tif 000029