JP2005252866A - 情報処理装置、および認証処理方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】 機器間でのデータ転送を伴うデータ処理におけるコンテンツの不正取得や利用を防止可能とした認証を実行する装置および方法を提供する。
【解決手段】 認証相手機器の公開鍵証明書の格納データからセキュア認証チャネル（ＳＡＣ）タイプ情報を取得し、認証相手とのデータ転送において適用するチャネルタイプを確認し、チャネルタイプに基づいて認証成立の可否を判定する。例えばホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）適用のデータ処理を行なうホスト−デバイスタイプであることの確認を認証成立の条件とした。本構成により、例えば、他のタイプのチャネルを適用するアプリケーションやドライブが不正な鍵情報を有し認証を成立させてコンテンツを不正に入手するなどの処理の排除が可能となる。
【選択図】 図１６

Description

本発明は、情報処理装置、および認証処理方法、並びにコンピュータ・プログラムに関する。さらに、詳細にはコンテンツ不正利用の防止を実現する情報処理装置、および認証処理方法、並びにコンピュータ・プログラムに関する。

近年、ＤＶＤや、青色レーザーディスク（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）など、大容量のデータを格納可能なディスクが利用、開発されており、大容量データである高精細画像、高品質音声の保存、再生が可能となっている。また、これらの大容量記録媒体の再生環境として、従来のコンシューマ用記録再生装置だけでなく、高性能なＣＰＵやビデオカードを搭載したパーソナルコンピュータ（ＰＣ）、その他の情報再生装置も、様々開発され、利用が進んでいる。

例えば、ＰＣにおいてコンテンツ再生を行う際の問題として、コンテンツの著作権保護が挙げられる。音楽データ、画像データ等、多くのコンテンツは、一般的にその作成者あるいは販売者に頒布権等が保有されている。従って、これらのコンテンツの配布に際しては、一定の利用制限、すなわち、正規なユーザに対してのみ、コンテンツの利用を許諾し、許可のない複製等が行われないようにする構成をとるのが一般的となっている。

特に、デジタル記録装置および記録媒体によれば、画像や音声を劣化させることなく記録、再生を繰り返すことが可能であり、不正コピーされたコンテンツのインターネットを介した配信や、ＣＤ−Ｒ、ＤＶＤ等の記録媒体にコンテンツをコピーした海賊版ディスクの流通という問題が発生している。

ＤＶＤや青色レーザディスク等の大容量型記録媒体には、著作権の保護対象となる様々な映像情報、音楽情報がデジタルデータとして格納されて市場に流通する。このようなデジタルデータを記録した媒体を市場に流通させる場合には、不正コピーを防止し著作権者の保護を図る構成が必須となる。昨今では、このようなデジタルデータの不正なコピーを防ぐため、デジタル記録装置および記録媒体に違法なコピーを防止するための様々な技術が実用化されている。

例えば、ＤＶＤプレーヤでは、コンテンツ・スクランブルシステム（ＣＳＳ：Ｃｏｎｔｅｎｔ Ｓｃｒａｍｂｌｅ Ｓｙｓｔｅｍ）が採用されている。コンテンツ・スクランブルシステムでは、記録媒体、例えばＤＶＤ−ＲＯＭ(Read Only Memory)に、ビデオデータやオーディオデータ等が暗号化されて記録されており、その暗号化されたデータの復号に用いる鍵をライセンスを受けたプレーヤのみに与える。ライセンスは、不正コピーを行わない等の所定の動作規定に従うように設計されたプレーヤに対してのみ与えられる。従って、ライセンスを受けたプレーヤでは、与えられたキーを利用して、情報記録媒体に記録された暗号化データを復号することにより画像や音声を再生することができる。

一方、ライセンスを受けていないプレーヤは、暗号化されたデータを復号するための鍵を有していないため、情報記録媒体に記録された暗号化データの復号を行うことができない。このように、コンテンツ・スクランブルシステム（ＣＳＳ）は、正規のライセンスを持つプレーヤのみのコンテンツ利用を許容するシステムを提供している。

しかし、このコンテンツ・スクランブルシステム（ＣＳＳ）は、確実なコンテンツの不正利用の排除ができないという問題がある。特に、情報記録媒体を装着したドライブからコンテンツをＰＣなどの情報処理装置に出力して再生する処理において、コンテンツの不正利用が行われ得るという問題点が発生する。以下、この問題点について図面を参照して説明する。

図１にコンテンツ・スクランブルシステム（ＣＳＳ）を採用したコンテンツを格納した情報記録媒体の格納データ例と、再生機器（プレーヤ）の処理を示す。

図１に示す情報記録媒体１０は、例えばＤＶＤビデオディスクであり、情報記録媒体１０には、暗号化ディスクキー（Ｓｅｃｕｒｅｄ Ｄｉｓｃ Ｋｅｙ）１１、情報記録媒体１０に格納されたコンテンツのタイトル対応の暗号化タイトルキー１２、ＣＳＳ方式に基づくスクランブル処理のなされたコンテンツとしてスクランブルＭＰＥＧデータ１３が格納されている。

情報記録媒体１０を装着してコンテンツ再生を実行する再生機器２０、例えばＤＶＤプレーヤは、再生機器２０に格納されたマスターキーを適用し、ステップＳ１１において、情報記録媒体１０から取得した暗号化ディスクキー（Ｓｅｃｕｒｅｄ Ｄｉｓｃ Ｋｅｙ）１１の復号処理を実行し、ディスクキーを取得し、ステップＳ１２において取得したディスクキーを適用して情報記録媒体１０から取得した暗号化タイトルキー１２の復号処理を実行してタイトルキーを取得し、取得したタイトルキーを適用してステップＳ１３において、スクランブルＭＰＥＧデータ１３のスクランブル解除処理を実行した後、ステップＳ１４においてＭＰＥＧデコード処理を実行して音声／映像データ２５を再生する。

次に、ＰＣ等のホスト装置に付設あるいは接続されたドライブからコンテンツをホスト（ＰＣ）側に入力し、ホスト側のプレーヤ・アプリケーションによってコンテンツ再生を行なう処理シーケンスについて図２を参照して説明する。

図２に示すように、情報記録媒体を装着したドライブ３０とホスト（ＰＣ）側のプレーヤ・アプリケーション４０間で、図に示すステップＳ３１，Ｓ４１において、相互認証および鍵共有（ＡＫＥ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）を実行する。相互認証処理は、例えば公開鍵暗号方式または共通鍵暗号方式に従ったアルゴリズムに従って実行される。相互認証においてセッションキーが生成され、ドライブ３０とホスト側のプレーヤ・アプリケーション４０がセッションキーを共有する。

ドライブ３０は、ステップＳ３２において、セッションキーを適用して情報記録媒体１０から取得した暗号化ディスクキー１１の再暗号化を実行して、プレーヤ・アプリケーション４０に送信し、また、ステップＳ３３においてセッションキーを適用して情報記録媒体から取得した暗号化タイトルキー１２の再暗号化を実行して、プレーヤ・アプリケーション４０に送信する。ドライブ３０と、プレーヤ・アプリケーション４０の実行装置としてのＰＣは接続バス、例えばＡＴＡＰＩバス（ＡＴ Ａｔｔａｃｈｅｍｅｎｔ ｗｉｔｈ Ｐａｃｋｅｔ Ｉｎｔｅｒｆａｃｅ ＢＵＳ）によって接続されており、接続バスを介してこれらの暗号化鍵情報がＰＣのプレーヤ・アプリケーション４０側に送信される。

さらに、ドライブ３０は、情報記録媒体から取得し、ＣＳＳ方式に基づくスクランブル処理のなされたコンテンツであるスクランブルＭＰＥＧデータ１３を、ドライブとＰＣ間の接続バスを介してＰＣ側に出力する。

ホスト（ＰＣ）側のプレーヤ・アプリケーション４０は、ステップＳ４２において、セッションキーを用いて、ドライブ３０から受領した暗号化ディスクキー１１のセッションキーによる再暗号化データを復号して暗号化ディスクキー１１を取得し、さらに、ステプＳ４３において、ドライブ３０から受領した暗号化タイトルキー１２のセッションキーによる再暗号化データを復号して暗号化タイトルキー１２を取得する。

その後のステップＳ５１〜Ｓ５５の処理は、先に図１を参照して説明した処理（Ｓ１１〜Ｓ１４）と同様の処理となる。

この図２に示す処理におけるドライブ側の処理をフローで示した図を図３に示す。ステップＳ６１において情報記録媒体（ディスク）が挿入されたと判定されると、ステップＳ６２において、ホスト、すなわち図２に示すプレーヤ・アプリケーション４０を実行するＰＣと相互認証および鍵共有（ＡＫＥ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）を実行する。

相互認証および鍵共有（ＡＫＥ）に成功（ステップＳ６３：Ｙｅｓ）すると、ドライブに装着した情報記録媒体の格納コンテンツであるＣＳＳスクランブルデータの出力が許可された状態に移行し、このＣＳＳスクランブルデータの出力許可状態が、情報記録媒体が排出されるまで、あるいは電源がオフされるまで継続されることになる。

このように、ＰＣ等のホスト装置に付設あるいは接続されたドライブからコンテンツをホスト（ＰＣ）側に入力し、ホスト側のプレーヤ・アプリケーションによってコンテンツ再生を行なう場合には、ホスト側のプレーヤ・アプリケーションとドライブ間で認証が実行されてセキュアなデータ転送が行なわれる。情報記録媒体（ディスク）に対するデータ記録の際にも、ホスト側のプレーヤ・アプリケーションとドライブ間で認証が実行されてセキュアなデータ転送が行なわれる。

しかしながら、相互認証処理は、特定のシーケンスに従った処理として実行され、所定の条件を見たすことで認証は成立する。例えば公開鍵暗号方式に従った相互認証アルゴリズムでは、相互認証を実行する機器が、無効化されていない公開鍵と秘密鍵のペアを有するという条件を満足することで認証が成立する。

公開鍵は、所定の管理センタが発行する公開鍵証明書に格納され、管理センタの電子署名が付与されて改竄は困難である。また、不正なコピー鍵の流出など不正処理が発見された場合には、管理センタにおける管理の下に発行済みの公開鍵証明書を無効化（リボーク）する処理が行われる。この無効化（リボーク）処理において、管理センタは無効化された公開鍵証明書の識別子（ＩＤ）をリスト化したリボークリスト（ＣＲＬ：Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）を発行する。

公開鍵暗号方式に従った相互認証を実行する機器は、最新の更新されたリボークリストをネットワークや記録媒体などを介して入手し、認証処理を実行する際に、入手したリボークリストを参照して、認証相手の公開鍵証明書の有効性を判定し、相手機器の公開鍵証明書のＩＤがリボークリストに記録されている場合は、不正な公開鍵証明書であると判定し、認証を不成立とするといった処置を行なうことができる。

しかし、リボークリストに基づく不正な鍵情報の利用排除までには相当の時間がかかり、その間は、コンテンツの不正利用を防止できないという問題がある。例えば公開鍵と秘密鍵の漏洩などにより不正な公開鍵と秘密鍵を利用した不正処理が行なわれた後、管理センタによる不正処理の確認がなされ、その後リボークリストへの登録処理がなされて、更新されたリボークリストが各デバイスに対して配布されて始めて、その後の認証処理において更新されたリボークリストによる不正鍵の排除が可能となる。

これらの処理が完了するまでには数ヶ月を要することも多い。また、管理センタによる漏洩の確認がなされず、不正に流通した鍵情報が放置されたままとなってしまうこともある。

従って、上述のドライブとホストアプリケーション間の認証成立を条件としたコンテンツ利用構成において、ドライブ、またはホストアプリケーションのいずれかが不正に入手した公開鍵証明書と秘密鍵のペアを有し、認証処理においてリボークリストでの不正確認ができない場合には、相互認証が成立してしまい、不正な鍵を持つドライブまたはホストアプリケーションがコンテンツを不正に入手し、利用してしまうという事態が発生し得る。

具体的な例について、図４、図５を参照して説明する。図４は、ドライブ６０とホスト側のプレーヤ・アプリケーション７０との間で公開鍵暗号アルゴリズムに基づく相互認証を実行し、相互認証の成立を条件としてドライブ６０に装着した情報記録媒体６０からコンテンツを読み出してプレーヤ・アプリケーション７０において、再生、利用する処理を示している。

ここで、ホスト側のプレーヤ・アプリケーション７０は不正に入手した公開鍵ＰＨと秘密鍵ＳＨとからなる不正鍵７１を有しているものとする。なお、公開鍵ＰＨは、公開鍵証明書に格納されている。ただし、管理センタの発行するリボークリストにはまだ記録されておらず、リボークリストに基づく排除はできない状態にある。

この状態で、ドライブ６０とホスト側のプレーヤ・アプリケーション７０との間で公開鍵暗号アルゴリズムに基づく相互認証および鍵交換処理（ＡＫＥ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈｅｎｇｅ）（ステップＳ８１）を実行する。相互認証および鍵交換処理（ＡＫＥ）は、相互認証処理とセッションキー（Ｋｓ）の共有を行なう処理である。セッションキー（ｋｓ）は、認証機器間で実行するデータ通信の際の暗号鍵として利用される。

ステップＳ８１の相互認証および鍵交換処理（ＡＫＥ）において、ドライブ６０とホスト側のプレーヤ・アプリケーション７０の双方は、公開鍵を格納した公開鍵証明書を交換し、公開鍵証明書の署名検証や、リボークリストに基づくリボーク確認を行って正当性を確認する。

ドライブ６０は、プレーヤ・アプリケーション７０から受領した公開鍵証明書の署名検証と、リボークリストに基づくリボーク確認を行って正当性を確認する。プレーヤ・アプリケーション７０の公開鍵は、不正な鍵であるが、この時点で、リボークリストには記録されていないので、ドライブ６０は、正当な公開鍵であると判断し、相互認証は成立する。

その後、ドライブ６０は、ステッブＳ８２およびステップＳ８３において、情報記録媒体５０から読み出した暗号化コンテンツと暗号化コンテンツの暗号化キーであるコンテンツキー（Ｋｃ）をセッションキー（Ｋｓ）で暗号化してプレーヤ・アプリケーション７０に出力する。

プレーヤ・アプリケーション７０は、ステップＳ８４と、ステップＳ８５において、ドライブ６０からの受信データを、セッションキー（Ｋｓ）を適用して復号し、暗号化コンテンツとコンテンツキー（Ｋｃ）を取得し、ステップＳ８６において、コンテンツキー（Ｋｃ）を適用して暗号化コンテンツの復号を実行してコンテンツを取得することができる。

このように、不正に入手した鍵であっても、リボークリストに登録されていない間は、不正であることが分からないので、認証が成立し、情報記録媒体５０に格納された著作権管理、利用管理のなされたコンテンツが不正なアプリケーションによって、不正に読み出されて利用されてしまう。

図５は、ドライブ６０側が不正な鍵情報［ＳＤ，ＰＤ］６１を持つ場合のコンテンツの不正利用例を示している。

ステップＳ９１の相互認証および鍵交換処理（ＡＫＥ）において、ドライブ６０とホスト側のプレーヤ・アプリケーション７０の双方は、公開鍵を格納した公開鍵証明書を交換し、公開鍵証明書の署名検証や、リボークリストに基づくリボーク確認を行って正当性を確認する。プレーヤ・アプリケーション７０は、ドライブ６０から受領した公開鍵証明書の署名検証と、リボークリストに基づくリボーク確認を行って正当性を確認する。ドライブ６０の公開鍵は、不正な鍵であるが、この時点で、リボークリストには記録されていないので、プレーヤ・アプリケーション７０は、正当な公開鍵であると判断し、相互認証は成立する。

その後、プレーヤ・アプリケーション７０は、ステッブＳ９２において、例えばネットワークから正規な手続きで取得したコンテンツを、やはり正規な手続きで取得したコンテンツキー（Ｋｃ）を適用して暗号化して、さらに、ステップＳ９３およびステップＳ９４において、暗号化コンテンツと暗号化コンテンツの暗号化キーであるコンテンツキー（Ｋｃ）をセッションキー（Ｋｓ）で暗号化してドライブ６０に出力する。

ドライブ６０は、ステップＳ９５と、ステップＳ９６において、プレーヤ・アプリケーション７０からの受信データを、セッションキー（Ｋｓ）を適用して復号し、暗号化コンテンツとコンテンツキー（Ｋｃ）を取得し、ステップＳ９７において、コンテンツキー（Ｋｃ）を適用して暗号化コンテンツの復号を実行してコンテンツを取得し、例えばＣＤ−Ｒなどの記録媒体にコンテンツを記録する。

このように、不正に入手した鍵であっても、リボークリストに登録されていない間は、不正であることが分からないので、認証が成立し、プレーヤ・アプリケーション７０が正規な手続きで外部から取得したコンテンツを不正なドライブが入手し、ＣＤ−Ｒなどの不正なコンテンツ記録媒体を生成することが可能となる。

このように、現状のリボークリストに基づく不正鍵の排除構成のみでは、コンテンツの不正利用を完全に防止することは困難であるというのが現状である。

本発明は、上述の問題点に鑑みてなされたものであり、リボークリストによる鍵情報の検証ができない場合においても、認証相手の鍵情報の正当性を厳格に審査することを可能とし、コンテンツの不正利用を排除することを可能とした情報処理装置、および認証処理方法、並びにコンピュータ・プログラムを提供することを目的とする。

本発明の第１の側面は、
情報処理装置であり、
データ転送処理を行なうインタフェースと、
データ処理を実行するデータ処理部とを有し、
前記データ処理部は、
前記インタフェースを介したデータ転送を伴うデータ処理の実行条件として、データ転送対象との認証処理を実行し、該認証処理において認証相手の保持する公開鍵証明書の格納データに基づいて、データ転送において適用するチャネルタイプを確認し、該チャネルタイプに基づいて認証成立の可否を判定する構成であることを特徴とする情報処理装置にある。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、認証相手の保持する公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、該確認に基づいて認証の成立可否を判定する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、認証相手の保持する公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、該確認に基づいて認証の成立可否を判定する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、前記認証処理において、認証相手の保持する公開鍵証明書の格納データに基づいて、さらに認証相手のデバイスタイプを確認し、該デバイスタイプに基づいて認証の成立可否を判定する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記デバイスタイプは、アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかのいずれかを示す情報であり、前記データ処理部は、予め定めた認証条件としてのデバイスタイプに基づいて認証の成立可否を判定する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記情報処理装置は、ドライブとの接続を行い、アプリケーションを実行するホスト機器であり、前記データ処理部は、前記認証処理において、ドライブから受領する公開鍵証明書の格納データに基づいて、前記ドライブが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するドライブであることの確認であるＳＡＣタイプ確認と、デバイスタイプがドライブであることの確認であるデバイスタイプ確認と、上記２つの確認を認証成立の条件とした認証処理を実行する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記情報処理装置は、アプリケーションを実行するホスト機器と接続し、情報記録媒体に対するデータ記録または読み取りを実行するドライブであり、前記データ処理部は、前記認証処理において、アプリケーションを実行するホストから受領する公開鍵証明書の格納データに基づいて、前記アプリケーションが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するアプリケーションであることのＳＡＣタイプ確認と、デバイスタイプがホストであることの確認であるデバイスタイプ確認と、上記２つの確認を認証成立の条件とした認証処理を実行する構成であることを特徴とする。

さらに、本発明の第２の側面は、
認証処理方法であり、
認証相手の保持する公開鍵証明書を取得する公開鍵証明書取得ステップと、
前記公開鍵証明書の格納データからチャネルタイプ情報を取得する情報取得ステップと、
前記チャネルタイプ情報に基づいて、認証相手とのデータ転送において適用するチャネルタイプを確認するチャネルタイプ確認ステップと、
前記チャネルタイプ確認ステップにおいて確認したチャネルタイプに基づいて認証成立の可否を判定する認証可否判定ステップと、
を有することを特徴とする認証処理方法にある。

さらに、本発明の認証処理方法の一実施態様において、前記チャネルタイプ確認ステップは、公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認するステップであることを特徴とする。

さらに、本発明の認証処理方法の一実施態様において、前記チャネルタイプ確認ステップは、公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認するステップであることを特徴とする。

さらに、本発明の認証処理方法の一実施態様において、前記認証処理方法は、さらに、認証相手の保持する公開鍵証明書の格納データに基づいて、さらに認証相手のデバイスタイプを確認するデバイスタイプ確認ステップを有し、前記認証可否判定ステップは、前記チャネルタイプ確認ステップにおいて確認したチャネルタイプと、前記デバイスタイプ確認ステップにおいて確認したデバイスタイプとに基づいて認証成立の可否を判定するステップであることを特徴とする。

さらに、本発明の認証処理方法の一実施態様において、前記デバイスタイプは、アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかのいずれかを示す情報であり、前記認証可否判定ステップは、予め定めた認証条件としてのデバイスタイプに基づいて認証の成立可否を判定することを特徴とする。

さらに、本発明の認証処理方法の一実施態様において、前記認証処理は、ドライブとの接続を行い、アプリケーションを実行するホスト機器において実行する認証処理であり、前記ホスト機器は、ドライブから取得した公開鍵証明書の格納データに基づいて、前記ドライブが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するドライブであることの確認であるＳＡＣタイプ確認と、デバイスタイプがドライブであることの確認であるデバイスタイプ確認と、上記２つの確認を認証成立の条件とした認証処理を実行することを特徴とする。

さらに、本発明の認証処理方法の一実施態様において、前記認証処理は、アプリケーションを実行するホスト機器と接続し、情報記録媒体に対するデータ記録または読み取りを実行するドライブにおいて実行する認証処理であり、前記ドライブは、アプリケーションを実行するホストから受領した公開鍵証明書の格納データに基づいて、前記アプリケーションがホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するアプリケーションであることのＳＡＣタイプ確認と、デバイスタイプがホストであることの確認であるデバイスタイプ確認と、上記２つの確認を認証成立の条件とした認証処理を実行することを特徴とする。

さらに、本発明の第３の側面は、
認証処理を実行するコンピュータ・プログラムであり、
認証相手の保持する公開鍵証明書を取得する公開鍵証明書取得ステップと、
前記公開鍵証明書の格納データからチャネルタイプ情報を取得する情報取得ステップと、
前記チャネルタイプ情報に基づいて、認証相手とのデータ転送において適用するチャネルタイプを確認するチャネルタイプ確認ステップと、
前記チャネルタイプ確認ステップにおいて確認したチャネルタイプに基づいて認証成立の可否を判定する認証可否判定ステップと、
を有することを特徴とするコンピュータ・プログラムにある。

なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能なコンピュータ・システムに対して、コンピュータ可読な形式で提供する記録媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本発明の構成によれば、例えばコンテンツ再生処理や記録処理など機器間でのデータ転送を伴うデータ処理を実行する場合に、データ転送機器間において認証処理を実行し、この認証処理において認証相手機器の公開鍵証明書の格納データからチャネルタイプ情報を取得し、チャネルタイプ情報に基づいて適用するチャネルタイプを確認し、確認したチャネルタイプに基づいて認証成立の可否を判定する構成としたので、不正なアプリケーションやドライブが接続して、不正に取得した鍵によって認証を成立させて、コンテンツの転送を行なわせる処理を排除できる。例えばホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）適用のデータ処理を行なうホスト−デバイスタイプであることの確認を認証成立の条件としたので、例えば、他のタイプのチャネルを適用するアプリケーションやドライブが不正な鍵情報を有し認証を成立させてコンテンツを不正に入手するなどの処理を排除可能となる。

さらに、本発明の構成によれば、公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、これらの確認処理を条件とした認証を行なう構成としたので、特定のセキュアチャネルを適用したデータ処理を実行するアプリケーションとドライブとの対応が成立した場合にのみチャネル間のデータ転送を伴うデータ処理が許容され、不正なアプリケーションやドライブの接続によるコンテンツの不正取得を排除することが可能となる。

さらに、本発明の構成によれば、認証相手の公開鍵証明書の格納データに基づいて、認証相手のデバイスタイプを確認する。具体的には、アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかのいずれかを確認し、チャネルタイプと、デバイスタイプとに基づいて認証成立の可否を判定する構成としたので、さらに厳格な認証が可能となり、不正なアプリケーションやドライブの接続によるコンテンツの不正取得を排除することが可能となる。

以下、図面を参照しながら本発明の情報処理装置、および認証処理方法、並びにコンピュータ・プログラムの詳細について説明する。なお、説明は、以下の記載項目に従って行う。
１．情報記録媒体の格納データ構成
２．コンテンツ対応のデータ処理
３．ホストおよびドライブを構成する情報処理装置の構成

［１．情報記録媒体の格納データ構成］
まず、情報記録媒体の格納データ構成について説明する。図６にコンテンツの格納された情報記録媒体の一例を示す。ここでは、コンテンツ格納済みディスクとしてのＲＯＭディスクの情報格納例を示す。

このＲＯＭディスクは、例えば、Ｂｌｕ−ｒａｙディスク、ＤＶＤなどの情報記録媒体であり、正当なコンテンツ著作権、あるいは頒布権を持ついわゆるコンテンツ権利者の許可の下にディスク製造工場において製造された正当なコンテンツを格納した情報記録媒体である。なお、以下の実施例では、情報記録媒体の例としてディスク型の媒体を例として説明するが、本発明は様々な態様の情報記録媒体の適用が可能である。

図６に示すように、情報記録媒体１００は、コンテンツ等のデータを格納するデータ格納領域１０１と、ディスクおよび格納コンテンツに対応する付帯情報、コンテンツの復号処理に適用する鍵情報などを格納するリードイン領域１０２を持つ。

データ格納領域１０１には、暗号化（スクランブル）コンテンツ１１１と、暗号化コンテンツの復号処理に適用する鍵の生成に必要となる情報としての記録シード（ＲＥＣ ＳＥＥＤ）であるユニットキー生成情報：Ｖｕ１１２、リボーク情報１１３が格納される。なお、スクランブル処理は、暗号化処理の一態様であり、本明細書ではスクランブルコンテンツの上位概念として、暗号化コンテンツという表現を用いる。暗号化コンテンツ１１１は、所定のユニット単位に区分され、ユニットに対応付けられたユニットキーを適用した暗号化がなされた状態で、情報記録媒体１００のデータ格納領域１０１に格納される。ユニットキー生成情報：Ｖｕ１１２は、これらの各ユニットキーの生成に適用する情報でありシード情報とも呼ばれる。リボーク情報１１３については後述する。

リードイン領域１０２には、暗号化コンテンツ１１１の復号処理に適用する鍵の生成に必要となる各種情報が格納される。その１つは、ＲＯＭマーク：Ｖｅ１１４である。ＲＯＭマーク：Ｖｅ１１４は物理インデックス（Ｐｈｙｓｉｃａｌ Ｉｎｄｅｘ）とも呼ばれ、書き換えの不可能な固定情報である。リードイン領域１０２には、さらに、暗号鍵情報１２０が格納される。なお、ＲＯＭマーク：Ｖｅ１１４、暗号鍵情報１２０は必ずしもリードイン領域１０２に格納されることが必須ではなく、データ領域１０１に格納してもよい。

暗号鍵情報１２０は、前述のユニットキー生成情報：Ｖｕ１１２、ＲＯＭマーク：Ｖｅ１１４と同様、情報記録媒体のデータ格納領域１０１に格納された暗号化コンテンツ１１１の復号処理に適用する鍵を生成するための鍵情報（鍵生成情報）によって構成される。

すなわち、暗号化コンテンツ１１１の復号処理に適用する鍵として、例えば情報記録媒体に格納されたコンテンツに対応する鍵として設定されるメディアキー：Ｋｍを取得するために必要となる暗号鍵ブロックであるＲＫＢ（Renewal Key Block）１２１と、暗号化コンテンツ１１１の復号処理に適用する鍵としてのディスクキー：Ｋｄを、メディアキー：Ｋｍを適用して暗号化した暗号化ディスクキーｅＫｍ（Ｋｄ）１２２とを含む情報である。なお、ｅＫａ（ｂ）は、データ：ｂを鍵：Ｋａで暗号化したデータを示すものとする。

ＲＫＢ（Renewal Key Block）１２１は、ブロードキャストエンクリプション方式の一態様として知られる木構造の鍵配信方式に基づいて生成される暗号鍵ブロックであり、情報記録媒体の再生を実行する正当なライセンスを保有するユーザ機器としての情報処理装置に配布されたデバイスキーを適用した復号処理によってメディアキー：Ｋｍを取得可能とした暗号鍵ブロックである。暗号鍵ブロック：ＲＫＢの構成データを変更することにより、メディアキー：Ｋｍを取得可能なユーザ機器を選別することが可能となる。

管理センタが、特定のユーザ機器あるいは再生アプリケーションを不正であると判定した場合は、ＲＫＢの構成を変更して、不正機器によるメディアキー：Ｋｍの取得を不可能とすることが可能となる。なお、不正と判定されたユーザ機器あるいは再生アプリケーションはリボーク（排除）機器として管理センタに登録される。管理センタは、リボークされたユーザ機器あるいは再生アプリケーションの識別情報をリスト化したリボケーションリストを保持し、適宜更新する。ユーザは、最新のリボケーションリストを含むリボーク情報を情報記録媒体あるいはネットワークを介して入手することができる。

図６に示すリボーク情報１１３は、リボークされたユーザ機器あるいは再生アプリケーションの識別情報をリスト化したリボケーションリストを含む情報である。ユーザ機器は、例えばコンテンツを出力する機器が不正機器であるか否かを、機器から入力した機器識別子（ＩＤ）がリボークリストに記録されていないかを検証することにより判定することが可能であり、リボークリストに掲載された不正機器である場合は、コンテンツの出力を中止する処理を行なう。

次に、情報記録媒体１００に格納される暗号化コンテンツ１１１の記録構成の詳細について、図７〜図９を参照して説明する。図７（ａ）が情報記録媒体に格納されるデータ記録構成である。１８バイトのユーザ制御データ（ＵＣＤ：User Control Data）と、実際のＡＶコンテンツデータなどを含む２０４８バイトのユーザデータ(User Data)が１つのセクタデータとして構成される。

図７（ｂ）に示すように、例えばユーザデータ３セクタ分６１４４バイトのデータが１つのブロック暗号処理単位としての１ユニット（１ＡＵ：Aligned Unit）、すなわちブロックとして設定される。６１４４バイトのデータは、３２ＴＳ（トランスポートストリーム）パケットに相当する。なお、ブロックの設定単位は、３セクタ分６１４４バイトのデータとする方式に限らず、１セクタ分２０４８バイトのデータを１つの暗号処理単位、すなわちブロックとして設定する方式など、様々な設定が可能である。

図７（ｃ）に示すように、コンテンツに対応するコピー制御情報ＣＣＩ（Copy Control Information）を格納したユーザデータは、２Ｋ（２０４８）バイト単位で暗号化されて記録される。

なお、１８バイトのユーザ制御データ（User Control Data）は暗号化対象から除去され、ユーザデータのみが、暗号化されて記録される。

図８は、１つのセクタデータの構成を示している。１つのセクタデータは、１８バイトのユーザ制御データ（ＵＣＤ：User Control Data）と２０４８バイトのユーザデータ(User Data)からなる。

ユーザ制御データ（ＵＣＤ：User Control Data）はセクタヘッダとも呼ばれ、その一部に、セクタ単位の出力制御情報（Output Control Information）１５１が記録される。

出力制御情報１５１は、対応するセクタデータ（ユーザデータ）の転送制御情報、例えば情報記録媒体を装着したドライブからＰＣ等の情報処理装置に対する出力の制御情報であり、以下の情報を含む。
＊出力制御フラグ（Output Control Flag）
＊セキュリティレベル（Security Level）
＊アプリケーションＩＤ（Application ID）
を含む情報として設定される。

図９にユーザ制御データ（ＵＣＤ：User Control Data）中に記録される出力制御情報１５１の詳細構成を示す。出力制御情報１５１は、ユーザ制御データ（ＵＣＤ：User Control Data）の３バイト（２４ビット）データに記録される。

まず、ビット１５〜０には、最大１６ビットの情報としてアプリケーションＩＤ（Application ID）が記録される。アプリケーションＩＤ（Application ID）は、情報記録媒体の読み出しコンテンツの制御を出力制御情報（Output Control Information）に従って実行する場合に適用する情報であり、情報記録媒体の読み出しコンテンツの再生処理を許容する再生アプリケーションの識別情報（ＩＤ）である。例えば情報記録媒体に格納されたコンテンツが、再生アプリケーションとしてのブルーレイ（Blu-ray）ディスクプレーヤを適用することで再生可能なＭＰＥＧ−ＴＳパケットベースのハイビジョン映像コンテンツである場合には、再生アプリケーションとしてのブルーレイ（Blu-ray）ディスクプレーヤのアプリケーションＩＤが記録される。また、情報記録媒体に格納されたコンテンツが、再生アプリケーションとしてのＤＶＤプレーヤで再生可能なＭＰＥＧ−ＰＳベースの標準画質の映像コンテンツである場合には、再生アプリケーションとしてのＤＶＤプレーヤの識別情報がアプリケーションＩＤとして記録される。このように、アプリケーションＩＤは、コンテンツの再生を許可する再生プラットフォームを指定する識別情報である。

次のビット１９〜１６には、最大４ビット情報としてセキュリティレベル（Security Level）が記録される。セキュリティレベル（Security Level）も、情報記録媒体の読み出しコンテンツの制御を出力制御情報（Output Control Information）に従って実行する場合に適用する情報であり、コンテンツ出力先として許容するＰＣなどの情報処理装置のセキュリティレベルを規定した情報である。例えば、特定のセキュアなデータ処理を実行する構成を持ついわゆるセキュアＰＣに対してのみ出力を許容するなど、コンテンツ出力先として許容するＰＣなどの情報処理装置のセキュリティレベルを規定する。

４ビット情報としてセキュリティレベルを設定した場合、００００〜１１１１までのセキュリティレベルの設定が可能であり、００００を最低セキュリティレベル、１１１１を最高セキュリティレベルとし、出力先の機器から取得したセキュリティレベル情報が、情報記録媒体の出力制御情報１５１に記録されたセキュリティレベル（Security Level）以上である場合に、ドライブからのコンテンツ出力を許容する。

具体的には、例えばセキュリティレベル（Security Level）＝０００１はＭｉｃｒｏｓｏｆｔ ＮＧＳＣＢ やＴｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐで仕様策定されつつあるセキュアＰＣ（Secure PC）環境下で動作するアプリケーション、およびセキュアＰＣ（Secure PC）環境下でしか動作を認めないコンテンツであることを示す。このような設定、すなわち、セキュリティレベル（Security Level）＝０００１の記録されたデータは、通常のＰＣアプリケーションでの再生が禁止され、ドライブからのコンテンツ出力が禁止される。

ビット２２〜２０の３ビットはリザーブ領域であり、
ビット２３の１ビットが出力制御フラグ（Output Control Flag）として設定される。出力制御フラグ（Output Control Flag）は、情報記録媒体の読み出しコンテンツの制御を出力制御情報（Output Control Information）に従って実行するか否かの判定情報として利用される。具体的には、例えば、
出力制御フラグ（Output Control Flag）＝１：出力制限、およびバス暗号化あり
出力制御フラグ（Output Control Flag）＝０：出力制限なし
として設定される。なお、バス暗号化は、ドライブからのコンテンツ出力時に実行する暗号化処理であり、詳細については後述する。

なお、ここで説明した各情報の構成ビット数は一例であり、それぞれの仕様により、様々な設定が可能である。

［２．コンテンツ対応のデータ処理］
次に、上述した情報記録媒体に格納されたコンテンツの再生処理などのコンテンツ対応のデータ処理について説明する。情報記録媒体に格納されたコンテンツの再生態様には２つの態様がある。第１の態様は、情報記録媒体を装着し、情報記録媒体からのデータ読み取りを実行する機器自体が再生処理を実行する態様であり、第２の態様は、情報記録媒体からのデータ読み取りを実行するドライブと、再生処理投のコンテンツ処理を実行するホスト（ＰＣ）等の情報処理装置とが別の機器として構成され、ドライブ装置とホスト（ＰＣ）間がデータ転送用バスによって接続され、接続バスを介したデータ転送を実行して再生処理他のコンテンツデータ処理を行なう態様である。

まず、情報記録媒体を装着し、情報記録媒体からのデータ読み取りを実行する機器自体が再生処理を実行する処理シーケンスについて図１０を参照して説明する。

ドライブ兼用再生機器３００が、暗号化コンテンツ２０６を格納した情報記録媒体２００をセットしてデータの読み取り、鍵生成、コンテンツ復号などの各種の暗号処理を実行してコンテンツを出力する。

情報記録媒体２００には、先に、図５を参照して説明した各種の情報、すなわち不正機器リストとしてのリボケーションリストを含むリボーク情報（Ｒｅｖｏｃａｔｉｏｎ ｉｎｆｏ ｆｏｒ ＡＫＥ）２０１、メディアキー：Ｋｍを格納した暗号鍵ブロックとしてのＲＫＢ２０２、ディスクキー：Ｋｄをメディアキー：Ｋｍで暗号化した暗号化ディスクキー：ＥＫｍ（Ｋｄ）２０３、ＲＯＭマーク：Ｖｅ２０４、ユニットキー生成情報：Ｖｕ２０５、暗号化コンテンツ２０６が格納されている。

ドライブ兼用再生機器３００の処理について説明する。ドライブ兼用再生機器３００は、ステップＳ１０１において、予め機器内に格納されているデバイスキー：Ｋｄｅｖ３０１を適用して暗号鍵ブロックとしてのＲＫＢ２０２の復号処理を実行して、ＲＫＢ２０２からメディアキー：Ｋｍを取得する。なお、ＲＫＢ２０２からメディアキー：Ｋｍを取得できるのは、コンテンツの利用を認められた機器のみであり、前述したように不正機器としてリボークされた機器の持つデバイスキーではＲＫＢの復号が出来ず、メディアキー：Ｋｍを取得することができない。

ステップＳ１０１においてメディアキー：Ｋｍの取得に成功すると、次に、ステップＳ１０２において、取得したメディアキー：Ｋｍを適用して、情報記録媒体２００から取得した暗号化ディスクキー：ＥＫｍ（Ｋｄ）２０３の復号処理を実行し、ディスクキー：Ｋｄを取得する。

次にステップＳ１０３において、取得したディスクキー：Ｋｄと、情報記録媒体２００から取得したＲＯＭマーク：Ｖｅ２０４に基づく鍵生成処理、例えばＡＥＳ暗号アルゴリズムに従った鍵生成処理を実行してエンベデッドキー：Ｋｅを生成する。

ＡＥＳ暗号アルゴリズムに従った鍵生成処理の詳細について、図１１を参照して説明する。図１１に示すように、ＡＥＳ暗号アルゴリズムに従った鍵生成は、ＡＥＳ暗号処理ブロック３１１において、入力値に対して暗号鍵を適用したＡＥＳ暗号処理を実行し、その出力と入力値の排他論理和（ＸＯＲ）演算結果を出力とする処理である。図１０のステップＳ１０３においては、入力値を情報記録媒体２００から取得したＲＯＭマーク：Ｖｅ２０４とし、適用鍵をディスクキー：Ｋｄとした鍵生成処理を実行して、出力値としてのエンベデッドキー：Ｋｅを得る。

次に、ステップＳ１０４において、取得したエンベデッドキー：Ｋｅと、情報記録媒体２００から取得したユニットキー生成情報：Ｖｕ２０５に基づく鍵生成処理を実行してユニットキー：Ｋｕを生成する。この鍵生成処理も、図１１を参照して説明したＡＥＳ暗号アルゴリズムに従った鍵生成処理として実行される。

次に、ステップＳ１０５において、生成したユニットキーＫｕを適用した暗号化コンテンツ２０６の復号処理が実行されて、コンテンツが出力される。

ステップＳ１０５におけるユニットキーＫｕを適用した暗号化コンテンツ２０６の復号処理の詳細について、図１２を参照して説明する。

暗号化コンテンツ２０６は、所定データ単位のブロック単位での暗号化がなされて情報記録媒体２００に格納されている。図１２に示すように例えば６１４４バイトのセクタデータは、１６バイトのブロックごとの暗号化がなされている。

復号処理の手順について説明する。まず、６１４４バイトのセクタデータから先頭の１６バイトデータを取得し、ＡＥＳ鍵生成処理ブロック［ＡＥＳ＿Ｇ］３２１において、ＡＥＳ暗号アルゴリズムに従った鍵生成処理を実行する。これは、先に図１１を参照して説明した処理と同様である。ＡＥＳ鍵生成処理ブロック３２１の出力をブロックキー：Ｋｂとし、このブロックキー：Ｋｂを適用して次の１６バイトデータの復号処理をＡＥＳ復号処理ブロック［ＡＥＳ＿Ｄ］３２２において実行する。

ＡＥＳ復号処理ブロック［ＡＥＳ＿Ｄ］３２２では、セクタデータの第２番目の１６バイトデータと初期値：ＩＶａとの排他論理和（ＸＯＲ）結果を入力としてブロックキー：Ｋｂを適用したＡＥＳ暗号アルゴリズムに従った復号処理を実行して、１６バイトブロックデータの復号データを取得するとともに、次のブロックの復号に適用する入力値とする。以下、同様の処理を繰り返し実行して、復号セクタデータ３２３を得ることができる。なお、初期値：ＩＶａは、予め設定された定数である。ＩＶａは、例えばセクタデータに対応するユーザ制御データあるいはユーザデータから取得することができる値として設定されるという場合もある。

図１０のステップＳ１０５では、このように、ユニットキー：Ｋｕを適用して、ブロック単位の復号処理を実行し、復号されたコンテンツを出力する。

このように、情報記録媒体からの情報読み取りと再生処理を１つの機器内で実行する場合には、コンテンツの漏洩の可能性は少なく、コンテンツの著作権の侵害といった問題が発生する可能性は少ない。しかし、先に、図２〜図５を参照して説明したように、情報記録媒体を装着したドライブからバスを介してＰＣ等のホスト機器にコンテンツ出力を行なう場合や、ＰＣ等のホスト機器が外部から入手したコンテンツをドライブに転送する処理を実行する場合には、ホストのアプリケーションまたはドライブいずれかが不正な処理を行なうことでコンテンツの不正利用の問題が発生し得る。

本発明の構成では、このようなドライブとＰＣ等のホスト間でのコンテンツ転送を行なう構成において、コンテンツの記録や再生の前ステップとして実行する認証処理を厳格に行なう。認証相手がたとえリボークされていない鍵（公開鍵証明書）を持つ場合であっても、公開鍵証明書の格納データに基づいて認証相手の正当性の厳格な確認処理を行い、この確認に基づいて正当性が確認された場合にのみコンテンツの再生や記録を実行する。本構成により不正なコンテンツ利用を防止する。

具体的には、相互認証時に認証機器間で交換し相互に検証する公開鍵証明書に、
（１）ＳＡＣタイプ情報
（２）デバイスタイプ情報
の各情報を設定し、これらの情報に基づいて認証相手機器の正当性を判断する。これらの各情報についての詳細は後述する。

ドライブと、アプリケーション実行機器としてのＰＣなどのホストをバス接続し、コンテンツの転送を伴う処理シーケンスの詳細について説明する。

図１３は、情報記録媒体２００と、情報記録媒体２００をセットし、情報記録媒体２００からのデータ読み取りまたは記録を行なうドライブ装置４００と、ドライブ装置４００と接続バスを介して接続し、コンテンツの再生や入出力処理アプリケーションを実行するＰＣ等の情報処理装置としてのホスト５００の処理を示している。なお、ドライブ装置４００とホスト５００とを接続するバスは、例えばＡＴＡＰＩ ＢＵＳ、ＵＳＢバス、ＩＥＥＥ１３９４バスなどのバスである。

情報記録媒体２００には、先に図１０を参照して説明したと同様、図５に示す各種の情報、すなわち不正機器リストとしてのリボケーションリストを含むリボーク情報（Ｒｅｖｏｃａｔｉｏｎ ｉｎｆｏ ｆｏｒ ＡＫＥ）２０１、メディアキー：Ｋｍを格納した暗号鍵ブロックとしてのＲＫＢ２０２、ディスクキー：Ｋｄをメディアキー：Ｋｍで暗号化した暗号化ディスクキー：ＥＫｍ（Ｋｄ）２０３、ＲＯＭマーク：Ｖｅ２０４、ユニットキー生成情報：Ｖｕ２０５、暗号化コンテンツ２０６が格納されている。

ドライブ装置４００には、公開鍵暗号方式に従った管理センタの公開鍵［Ｋｐ＿ｋｉｃ］４０１、公開鍵暗号方式に従ったドライブ対応の秘密鍵［Ｋｓ＿ｄｒｉｖｅ］４０２、公開鍵暗号方式に従ったドライブ対応の公開鍵を格納した公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］４０３、およびデバイスキー［Ｋｄｅｖ］４０４を格納している。

一方、ホストアプリケーションを実行するホスト５００には、公開鍵暗号方式に従った管理センタの公開鍵［Ｋｐ＿ｋｉｃ］５０１、ホストの実行するホストアプリケーション対応の公開鍵暗号方式に従ったホストアプリケーション秘密鍵［Ｋｓ＿ｈｏｓｔ］５０２、ホストの実行するホストアプリケーション対応の公開鍵暗号方式に従った公開鍵を格納したホストアプリケーション公開鍵証明書［Ｃｅｒｔ＿ｈｏｓｔ］５０３を格納している。

ドライブ対応の公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］４０３と、ホストアプリケーション対応の公開鍵証明書［Ｃｅｒｔ＿ｈｏｓｔ］５０３の詳細について、図１４を参照して説明する。

図１４（ａ）がドライブ対応の公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］５３０のデータ構成であり、図１４（ｂ）がホストアプリケーション対応の公開鍵証明書［Ｃｅｒｔ＿ｈｏｓｔ］５５０のデータ構成である。

ドライブ対応の公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］５３０には、従来からの公開鍵証明書と同様のデータとしての証明書タイプ、証明書識別子、公開鍵、署名データの他に、前述した
（１）ＳＡＣタイプ情報５３１
（２）デバイスタイプ情報５３２
が格納される。

（１）ＳＡＣタイプ情報は、
セキュア認証チャネル（ＳＡＣ：Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ）情報であり、ＰＣ等のホストが実行するアプリケーションとドライブ間のデータ転送バスに関するチャネル情報である。アプリケーション側の公開鍵証明書には、そのアプリケーションの適用するチャネル情報としてのＳＡＣタイプ情報が格納され、ドライブ側の公開鍵証明書には、ドライブの適用するチャネル情報としてのＳＡＣタイプ情報が格納される。

ＳＡＣタイプ情報には、
（１ａ）ＳＡＣタイプ＝［Ｈｏｓｔ−Ｄｅｖｉｃｅ］
（１ｂ）ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］
の２つの情報がある。

（１ａ）ＳＡＣタイプ＝［Ｈｏｓｔ−Ｄｅｖｉｃｅ］は、
ホスト側アプリケーションが動作の主導権を持ち、バスを介してドライブに対してコマンドを出力し、ドライブ側は、ホスト側アプリケーションから入力するコマンドによって従属的に動作するタイプを示す。

具体的には、例えば、ＰＣ等のホストが実行するアプリケーションとドライブとの接続バスとして、ＡＴＡＰＩバス（ＡＴ Ａｔｔａｃｈｅｍｅｎｔ ｗｉｔｈ Ｐａｃｋｅｔ Ｉｎｔｅｒｆａｃｅ ＢＵＳ）を適用する場合、あるいはアプリケーションとドライブをＵＳＢ接続した場合、または、アプリケーションとドライブをＩＥＥＥ１３９４バス接続としてシリアルバスプロトコル（ＳＢＰ：Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ）に従ったデータ処理を実行する構成とした場合などが、
ＳＡＣタイプ＝［Ｈｏｓｔ−Ｄｅｖｉｃｅ］
である。

一方、（１ｂ）ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］は、
ホスト側アプリケーションが動作の主導権を持つといった形態ではなく、各デバイスが対等の関係を持ってデータ処理を実行するタイプである。

具体的には、例えば、ＰＣ等のホストが実行するアプリケーションとドライブとの接続バスとして、ＩＥＥＥ１３９４を用い、ＡＶプロトコルを採用している場合などである。このような構成でデータ処理を実行するアプリケーションやドライブの公開鍵証明書には、
ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］
が設定される。

（２）デバイスタイプ情報は、
デバイスのタイプ情報を示す情報であり、具体的には、
（２ａ）ホスト
（２ｂ）ドライブ
の各設定がある。

ホスト側アプリケーションの公開鍵証明書には、
（２ａ）デバイスタイプ＝ホスト
が設定され、
ドライブの公開鍵証明書には、
（２ｂ）デバイスタイプ＝ドライブ
が設定される。

ホスト側アプリケーションおよびドライブは、それぞれ
（１）ＳＡＣタイプ情報
（２）デバイスタイプ情報
の２つの付加情報を格納した公開鍵証明書を有し、相互認証時にこれらの公開鍵証明書を交換し、相互に（１）ＳＡＣタイプ情報と、（２）デバイスタイプ情報とを抽出して検証する。

認証処理においては、データ転送において適用するチャネルタイプを確認し、確認したチャネルタイプに基づいて認証成立の可否を判定する。すなわち、認証相手の保持する公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、この確認に基づいて認証の成立可否を判定する。

具体的には、公開鍵証明書に設定されたチャネルタイプが、ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、この確認に基づいて認証の成立可否を判定する。さらに、認証相手の保持する公開鍵証明書の格納データに基づいて、認証相手のデバイスタイプを確認し、確認したデバイスタイプに基づいて認証の成立可否を判定する。すなわち、アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかを確認し、予め定めた認証条件としてのデバイスタイプに対応するか否かを判定して認証の成立可否を判定する。

ホストアプリケーション対応の公開鍵証明書［Ｃｅｒｔ＿ｈｏｓｔ］５５０は、証明書タイプ、証明書識別子、公開鍵、署名データに加え、アプリケーション・セキュリティレベル［ＳＬｃｅｒｔ］５５１と、アプリケーションＩＤ［ＡＩＤｃｅｒｔ］５５２と、
（１）ＳＡＣタイプ情報５５３
（２）デバイスタイプ情報５５４
が追加データとして設定される。

アプリケーション・セキュリティレベル［ＳＬｃｅｒｔ］５５１は、例えば４ビット情報であり、先に図９を参照して説明した情報記録媒体のコンテンツ構成データとしてのセクタデータに対応するユーザ制御データ（ＵＣＤ）に格納される出力制御情報（Output Control Information）内のセキュリティレベル（Security Level）に対応するデータである。

ホストのアプリケーション対応の公開鍵証明書に格納されるアプリケーション・セキュリティレベル［ＳＬｃｅｒｔ］５５１は、そのアプリケーションの持つセキュリティレベル情報が設定される。例えば、セキュアＰＣで実行されるアプリケーションであれば、高いセキュリティレベルの値が設定される。

公開鍵証明書に格納されるアプリケーション・セキュリティレベル［ＳＬｃｅｒｔ］５５１は、４ビットデータとした場合、［００００］〜［１１１１］までのセキュリティレベルの値のいずれかが設定される。００００を最低セキュリティレベル、１１１１を最高セキュリティレベルとする。

アプリケーションＩＤ［ＡＩＤｃｅｒｔ］５５２は、先に図９を参照して説明した情報記録媒体のコンテンツ構成データとしてのセクタデータに対応するユーザ制御データ（ＵＣＤ）に格納される出力制御情報（Output Control Information）内のアプリケーションＩＤに対応するデータである。

公開鍵証明書に格納されるアプリケーションＩＤは、公開鍵証明書の設定されたアプリケーションの識別情報である。例えば情報記録媒体に格納されたコンテンツが、再生アプリケーションとしてのブルーレイ（Blu-ray）ディスクプレーヤ・アプリケーションであれば、ブルーレイ（Blu-ray）ディスクプレーヤ・アプリケーションであることを判別可能な識別情報としてのアプリケーションＩＤが格納される。

ＳＡＣタイプ情報５５３は、セキュア認証チャネル（ＳＡＣ：Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ）情報であり、ＰＣ等のホストが実行するアプリケーションとドライブ間のデータ転送バスに関するチャネル情報である。アプリケーション側の公開鍵証明書には、そのアプリケーションの適用するチャネル情報としてのＳＡＣタイプ情報が格納され、ドライブ側の公開鍵証明書には、ドライブの適用するチャネル情報としてのＳＡＣタイプ情報が格納される。

ＳＡＣタイプ情報５５３は、ドライブのＳＡＣタイプ情報５１３と同様、
（１ａ）ＳＡＣタイプ＝［Ｈｏｓｔ−Ｄｅｖｉｃｅ］
（１ｂ）ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］
の２つの情報のいずれかが設定される。

ＳＡＣタイプ＝［Ｈｏｓｔ−Ｄｅｖｉｃｅ］は、ホスト側アプリケーションが動作の主導権を持ち、バスを介してドライブに対してコマンドを出力し、ドライブ側は、ホスト側アプリケーションから入力するコマンドによって従属的に動作するタイプであり、具体的には、例えば、ＰＣ等のホストが実行するアプリケーションとドライブとの接続バスとして、ＡＴＡＰＩバス（ＡＴ Ａｔｔａｃｈｅｍｅｎｔ ｗｉｔｈ Ｐａｃｋｅｔ Ｉｎｔｅｒｆａｃｅ ＢＵＳ）を適用する場合、あるいはアプリケーションとドライブをＵＳＢ接続した場合、または、アプリケーションとドライブをＩＥＥＥ１３９４バス接続としてシリアルバスプロトコル（ＳＢＰ：Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ）に従ったデータ処理を実行する構成とした場合である。

一方、ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］は、ホスト側アプリケーションが動作の主導権を持つといった形態ではなく、各デバイスが対等の関係を持ってデータ処理を実行するタイプである。具体的には、例えば、ＰＣ等のホストが実行するアプリケーションとドライブとの接続バスとして、ＩＥＥＥ１３９４を用い、ＡＶプロトコルを採用している構成である場合などに、ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］の設定がなされる。

デバイスタイプ情報５５４は、デバイスのタイプ情報を示す情報であり、具体的には、
（２ａ）ホスト
（２ｂ）ドライブ
の各設定があり、ホスト側アプリケーションの公開鍵証明書には、デバイスタイプ＝ホストが設定される。

なお、図１４に示す公開鍵証明書を構成する各データの構成ビット数は、一例であり、各情報のビット数が図１４に示す態様に限定されるものではなく、様々な設定が可能である。

図１３戻り、ドライブ装置４００が情報記録媒体から取得したコンテンツ等のデータを接続バスを介してホスト５００に転送して再生する処理シーケンスについて説明する。

まず、ステップＳ２０１，Ｓ３０１において、ドライブ装置４００とホスト５００のアプリケーション間で相互認証および鍵交換（ＡＫＥ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）処理が実行される。相互認証および鍵交換（ＡＫＥ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）処理の詳細シーケンスについて、図１５を参照して説明する。この処理は、例えば、ＩＳＯ／ＩＥＣ９７９８−３に規定された公開鍵アルゴリズムを利用した相互認証、ＩＳＯ／ＩＥＣ１１７７０−３に規定された公開鍵アルゴリズムを利用した鍵生成処理方式を適用して実行可能である。なお、公開鍵を利用した相互認証方式として実用化された方式としては、例えば、ＤＴＣＰ(Digital Transmission Content Protection) Specification Volume 1 (Informational Version)に記載される方法がある。

図１５に示す処理シーケンスについて説明する。ステップＳ４０１において、ホストアプリケーションは、ドライブに対して乱数生成処理によって生成したチャレンジデータ［Ｃ＿ｈｏｓｔ］と、公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］を送信する。公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］は、図１４（ｂ）に示す公開鍵証明書であり、セキュリティレベルと、アプリケーションＩＤ、ＳＡＣタイプ、デバイスタイプの各情報が格納された公開鍵証明書である。

このデータを受け取ったドライブ側は、ステップＳ４０２において、ホストアプリケーションの公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］に基づく検証処理を実行する。

ステップＳ４０２において、ドライブの実行するホストアプリケーションの公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］に基づく検証処理の詳細シーケンスを図１６（ａ）のフローを参照して説明する。

まず、ドライブは、ステップＳ４３１において、ホスト（アプリケーション）から公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］を受信する。ステップＳ４３２において、ドライブは、ホスト（アプリケーション）公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］の署名検証処理により、公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］の改竄の有無を検証する。署名検証処理は、ドライブの保持する管理センタの公開鍵［Ｋｐ＿ｋｉｃ］４０１（図１３参照）を適用して実行される。

公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］の改竄がないことが検証されると、公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］からアプリケーションＩＤを取得して、情報記録媒体から取得したリボーク情報２０１に含まれるリボケーションリストに基づくリボーク確認を実行する。

署名検証により公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］の改竄可能性が検出された場合や、アプリケーションＩＤに基づいて、ホストアプリケーションがリボークされていることが判明した場合（ステップＳ４３３：Ｎｏ）には、ステップＳ４３７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］の改竄のないことが確認され、ホストアプリケーションがリボークされていないアプリケーションであることが確認されると（ステップＳ４３３：Ｙｅｓ）、ステップＳ４３４に進み、ホストアプリケーションの公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］に記録されたＳＡＣタイプを読み取る。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］でない場合には、ステップＳ４３７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］でないということは、ＳＡＣタイプ＝ピアツーピア［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］であることを意味し、ホスト側アプリケーションが動作の主導権を持つといった形態ではなく、各デバイスが対等の関係を持ってデータ処理を実行するタイプということになる。具体的には、例えば、ＰＣ等のホストが実行するアプリケーションとドライブとの接続バスとして、ＩＥＥＥ１３９４を用い、ＡＶプロトコルを採用している構成である場合などに、ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］の設定がなされており、この場合には、認証成立とすることなく、ステップＳ４３７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］である場合（ステップＳ４３４：Ｙｅｓ）には、ステップＳ４３５に進む。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］であるとは、すなわち、ホスト側のアプリケーションがデータ処理における各種の動作の主導権を持ち、バスを介してドライブに対してコマンドを出力し、ドライブ側がホスト側アプリケーションから入力するコマンドによって従属的に動作するタイプに対応したアプリケーションであることを示している。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］である場合は、具体的には、アプリケーションが、ドライブとＡＴＡＰＩバス接続、ＵＳＢ接続、または、ＩＥＥＥ１３９４バス接続としてシリアルバスプロトコル（ＳＢＰ：Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ）を適用した構成においてデータ処理を実行するアプリケーションであることを示している。

この場合には、さらに、ステップＳ４３５において、ドライブは、ホストアプリケーションの公開鍵証明書からデバイスタイプを取得し、デバイスタイプ＝ホストであるか否かを判定する。デバイスタイプ＝ホストでない場合（ステップＳ４３５：Ｎｏ）には、ステップＳ４３７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

デバイスタイプ＝ホストである場合（ステップＳ４３５：Ｙｅｓ）には、ステップＳ４３６に進み、その後の認証処理を継続して実行する。

このように、ドライブは、ホストアプリケーションの公開鍵証明書［Ｃｅｒｔ＿Ｈｏｓｔ］に記録されたＳＡＣタイプに基づいて、アプリケーションがＡＴＡＰＩのようなＩ／Ｆを通じてドライブを動作させる［Ｈｏｓｔ−Ｄｅｖｉｃｅ］タイプのデータ処理、すなわち２者間でのＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｃｈａｎｎｅｌ）を適用したデータ転送により、アプリ主導型のデータ処理を実行するアプリケーションであることを確認し、さらに、デバイスタイプに基づいて、アプリケーション実行デバイスがホストであることを確認することを認証の成立条件とする。

次に、図１５のステップＳ４０３において、ドライブは、ホストアプリケーションに対して乱数生成処理によって生成したチャレンジデータ［Ｃ＿ｄｒｉｖｅ］と、ドライブ側の公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］を送信する。

ホストアプリケーション側では、ドライブ側の公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］の検証を実行する。

ステップＳ４０４において、ホストアプリケーションの実行するドライブの公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］に基づく検証処理の詳細シーケンスを図１６（ｂ）のフローを参照して説明する。

まず、ホストアプリケーションは、ステップＳ４５１において、ドライブから公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］を受信する。ステップＳ４５２において、ホストアプリケーションは、ドライブ公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］の署名検証処理により、公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］の改竄の有無を検証する。署名検証処理は、ホストアプリケーションの保持する管理センタの公開鍵［Ｋｐ＿ｋｉｃ］５０１（図１３参照）を適用して実行される。

公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］の改竄がないことが検証されると、リボケーションリストに基づくリボーク確認を実行する。リボケーション情報は、ネットワークまたは情報記録媒体から取得し、メモリに格納されたデータを適用する。

署名検証により公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］の改竄可能性が検出された場合や、ドライブがリボークされていることが判明した場合（ステップＳ４５３：Ｎｏ）には、ステップＳ４５７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］の改竄のないことが確認され、リボークされていないドライブであることが確認されると（ステップＳ４５３：Ｙｅｓ）、ステップＳ４５４に進み、ドライブの公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］に記録されたＳＡＣタイプを読み取る。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］でない場合には、ステップＳ４５７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］でないということは、ドライブ側の公開鍵証明書がＳＡＣタイプ＝ピアツーピア［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］であることを意味し、ホスト側アプリケーションが動作の主導権を持つといった形態ではなく、各デバイスが対等の関係を持ってデータ処理を実行するタイプということになる。具体的には、例えば、ＰＣ等のホストが実行するアプリケーションとドライブとの接続バスとして、ＩＥＥＥ１３９４を用い、ＡＶプロトコルを採用している構成である場合などである。

この場合に、ＳＡＣタイプ＝［Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ］の設定がなされており、この場合には、認証成立とすることなく、ステップＳ４５７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］である場合（ステップＳ４５４：Ｙｅｓ）には、ステップＳ４５５に進む。ＳＡＣタイプ＝ホストデバイス［Ｈｏｓｔ−Ｄｅｖｉｃｅ］であるとは、すなわち、ホスト側のアプリケーションがデータ処理における各種の動作の主導権を持ち、バスを介してドライブに対してコマンドを出力し、ドライブ側がホスト側アプリケーションから入力するコマンドによって従属的に動作するタイプに対応したアプリケーションに応答して処理を実行するドライブであることを示している。具体的には、ドライブがアプリケーションとＡＴＡＰＩバス接続、ＵＳＢ接続、または、ＩＥＥＥ１３９４バス接続としてシリアルバスプロトコル（ＳＢＰ：Ｓｅｒｉａｌ Ｂｕｓ Ｐｒｏｔｏｃｏｌ）を適用した構成においてデータ処理を実行するドライブであることを示している。

この場合には、さらに、ステップＳ４５５において、ホストアプリケーションはドライブの公開鍵証明書からデバイスタイプを取得し、デバイスタイプ＝ドライブであるか否かを判定する。デバイスタイプ＝ドライブでない場合（ステップＳ４５５：Ｎｏ）には、ステップＳ４５７に進み、エラーメッセージの通知などを実行し、処理を終了する。以後のコンテンツ、出力、再生処理は中止される。

デバイスタイプ＝ドライブである場合（ステップＳ４５５：Ｙｅｓ）には、ステップＳ４５６に進み、その後の認証処理を継続して実行する。

このように、ホストアプリケーションは、ドライブの公開鍵証明書［Ｃｅｒｔ＿Ｄｒｉｖｅ］に記録されたＳＡＣタイプに基づいて、ドライブがＡＴＡＰＩのようなＩ／Ｆを通じてアプリケーションからのコマンドに応じて動作する［Ｈｏｓｔ−Ｄｅｖｉｃｅ］タイプのデータ処理、すなわち２者間でのＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｃｈａｎｎｅｌ）を適用し、アプリ主導型のデータ処理を実行するドライブであることを確認し、デバイスタイプに基づいて、ドライブが間違いなくドライブであることが確認されたことを認証の成立条件とする。

公開鍵証明書［Ｃｅｒｔ＿ｄｒｉｖｅ］の正当性が確認された場合には、ホストアプリケーションは、ドライブから受信したチャレンジデータ［Ｃ＿ｄｒｉｖｅ］に基づく演算を実行しパラメータ［Ａ＿ｈｏｓｔ］を算出し、新たに生成した乱数［Ｒ＿ｈｏｓｔ］とともに、ドライブに送信（ステップＳ４０５）する。

一方、ドライブは、ホストアプリケーションから受信したチャレンジデータ［Ｃ＿ｈｏｓｔ］に基づく演算を実行しパラメータ［Ａ＿ｄｒｉｖｅ］を算出し、新たに生成した乱数［Ｒ＿ｄｒｉｖｅ］とともに、ホストアプリケーションに送信（ステップＳ４０６）する。

この処理により、ドライブ、ホストアプリケーションの双方は、乱数[Ｒ_ｈｏｓｔ]、［Ｒ＿ｄｒｉｖｅ］、パラメータ［Ａ＿ｈｏｓｔ］、［Ａ＿ｄｒｉｖｅ］を共有することになり、ドライブと、ホストアプリケーションの双方は、これらの共有データに基づいて共通のセッションキーＫｓを生成（ステップＳ４０７）する。

ドライブは、さらに、ステップＳ４０８において、乱数に基づいて生成したバスキー：Ｋｂｕｓ、およびバスキーのシーケンス番号：ＳＥＱとの連結データ：［Ｋｂｕｓ‖ＳＥＱ］に、この連結データの改竄検証用データとして算出したハッシュ値［ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］をセッションキー：Ｋｓを用いて暗号化したデータ：ＥＫｓ［（Ｋｂｕｓ‖ＳＥＱ），ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］をホストアプリケーションに送信する。なお、このステップＳ４０８の処理は、図１３において、ステップＳ２０６のバスキー生成処理（Ｇｅｎａｒａｔｅ＿Ｋｂｕｓ）と、ステップＳ２０７のセッションキー：Ｋｓによるバスキーの暗号化処理（ＡＥＳ＿Ｅ）の処理に相当する。

バスキー：Ｋｂｕｓは、暗号化コンテンツのドライブからホスト側への接続バスを介した転送処理の際の暗号化キーとして用いられる鍵であり、ドライブにおいて乱数に基づいて生成される。バスキーは、適宜切り替えられ、各バスキーに応じたシーケンス番号が対応付けられる。例えばホスト側で複数のアプリケーションを適用して情報記録媒体に格納された異なるコンテンツの再生をそれぞれのアプリケーションを適用して実行する場合には、各アプリケーションで適用するバスキーを異なる鍵として設定する。

図１３に戻り、ドライブ装置４００が情報記録媒体から取得したコンテンツ等のデータを接続バスを介してホスト５００に転送して再生する処理シーケンスについて説明を続ける。

ドライブ装置４００は、ホスト５００との相互認証および鍵交換（ＡＫＥ）が終了すると、ドライブ内に保持するデバイスキー：Ｋｄｅｖ４０４を適用し、ステップＳ２０２において、情報記録媒体２００から読み出した暗号鍵ブロックとしてのＲＫＢ２０２の復号処理を実行して、ＲＫＢ２０２からメディアキー：Ｋｍを取得する。なお、ＲＫＢ２０２からメディアキー：Ｋｍを取得できるのは、コンテンツの利用を認められた機器のみであり、前述したように不正機器としてリボークされた機器の持つデバイスキーではＲＫＢの復号が出来ず、メディアキー：Ｋｍを取得することができない。

ステップＳ２０２においてメディアキー：Ｋｍの取得に成功すると、次に、ステップＳ２０３において、取得したメディアキー：Ｋｍを適用して、情報記録媒体２００から取得した暗号化ディスクキー：ＥＫｍ（Ｋｄ）２０３の復号処理を実行し、ディスクキー：Ｋｄを取得する。

次にステップＳ２０４において、取得したディスクキー：Ｋｄと、情報記録媒体２００から取得したＲＯＭマーク：Ｖｅ２０４に基づく鍵生成処理、例えばＡＥＳ暗号アルゴリズムに従った鍵生成処理を実行してエンベデッドキー：Ｋｅを生成する。ＡＥＳ暗号アルゴリズムに従った鍵生成処理は、先に図１１を参照して説明した通りである。

ドライブは、ステップＳ２０５において、エンベデッドキー：Ｋｅを先の相互認証および鍵交換処理（ＡＫＥ）において生成したセッションキー：Ｋｓで暗号化してホスト５００に対して接続バスを介して送信する。

ステップＳ２０６、およびステップＳ２０７の処理は、先に図１５を参照して説明した相互認証および鍵交換処理（ＡＫＥ）のステップＳ４０８の処理に相当し、乱数に基づいて、バスキー：Ｋｂｕｓを生成（ステップＳ２０６）し、セッションキー：Ｋｓでバスキー：Ｋｂｕｓを含むデータを暗号化（ステップＳ２０７）して生成したデータをホスト５００に対して接続バスを介して送信する処理である。送信データは、先に図１５を参照して説明したように、乱数に基づいて生成したバスキー：Ｋｂｕｓ、およびバスキーのシーケンス番号：ＳＥＱとの連結データ：［Ｋｂｕｓ‖ＳＥＱ］と、この連結データの改竄検証用データとして算出したハッシュ値［ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］とをセッションキー：Ｋｓを用いて暗号化したデータ：ＥＫｓ［（Ｋｂｕｓ‖ＳＥＱ），ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］である。

さらに、ドライブ装置４００は、ステップＳ２０８において、情報記録媒体２００から読み出した暗号化コンテンツ２０６のユーザ制御データ（ＵＣＤ）に含まれる出力制御情報と、相互認証および鍵交換処理（ＡＫＥ）処理において、ホスト５００から取得したホストの公開鍵証明書の格納データとに基づく出力制御を実行し、ステップＳ２０９において、暗号化コンテンツ２０６を制御態様に応じてバスキー：Ｋｂｕｓを用いて暗号化し、生成した暗号化データを接続バスを介してホスト５００に対して出力する。

情報記録媒体２００から読み出される暗号化コンテンツ３５０は、例えばスクランブル処理のなされた暗号化データであり、ドライブは、このスクランブル処理されたデータをバスキー：Ｋｂｕｓを適用して再暗号化してホスト側に出力する。このバスキー：Ｋｂｕｓを適用した再暗号化処理によるデータ出力を実行することにより、バスキー：Ｋｂｕｓを保持している認証のなされたホスト側の唯一のアプリケーションのみが、バスキー：Ｋｂｕｓを適用した復号が可能となり、復号処理によって暗号化コンテンツ３５０を取得することが可能となる。

このような構成とすることで、コンテンツを入力するＰＣ（ホスト）側でのアプリケーションの切り替えによるコンテンツの迂回取得や、ドライブとホストとの接続バスの転送データを盗聴することによるコンテンツ取得を行なっても、取得されるコンテンツは、バスキー：Ｋｂｕｓによって暗号化されたデータであり、バスキー：Ｋｂｕｓを保有しているのは、ドライブとの認証の成立した特定のアプリケーションのみであり、その特定のアプリケーションを適用しない限り、入力コンテンツの復号は実行できない。ＣＳＳスクランブルの解除プログラムのみではバスキー：Ｋｂｕｓによって暗号化されたデータの復号は実行できず、コンテンツの不正利用が防止可能となる。

バスキー：Ｋｂｕｓを適用した暗号化コンテンツ２０６の暗号化処理態様について、図１７を参照して説明する。バスキー：Ｋｂｕｓを適用した暗号化コンテンツ２０６の暗号化処理は、例えば図１７に示すように、ＡＥＳ−ＣＢＣモードを適用したブロック暗号化処理によって実行される。

ドライブ装置４００は、情報記録媒体２００から読み出される暗号化コンテンツに対して、ドライブにおいて生成したバスキー：Ｋｂｕｓを適用して、所定データブロック単位（１６バイト）で暗号化する処理を実行する。

まず、情報記録媒体２００から読み出される暗号化コンテンツの構成データである２０４８バイトのセクタデータ３５０から先頭の１６バイトデータを取得し、初期値：ＩＶｂとの排他論理和（ＸＯＲ）結果を、ＡＥＳ暗号処理部［ＡＥＳ＿Ｅ］３５１に入力し、バスキー：Ｋｂｕｓを適用したＡＥＳ暗号アルゴリズムに従った暗号処理を実行して１６バイトブロックデータの暗号化データを生成する。初期値：ＩＶｂは、予め設定された定数である。ＩＶｂは、例えば、セクタデータ３５０に対応するユーザ制御データ（ＵＣＤ）から取得されるという場合もある。

さらに、この生成データは、次のブロックの暗号化に適用する入力値として適用される。以下、各１６バイトのブロックデータ毎に排他論理和（ＸＯＲ）およびＡＥＳ暗号処理を同様に繰り返し実行して、バスキーによる暗号化セクタデータ３５２を生成し、このデータをＡＴＡＰＩ−ＢＵＳなどの接続バスを介してホスト５００側のアプリケーションに向けて送信する。ホスト５００側ではこの入力暗号化データを復号して再生処理を行なう。

図１３に戻り、ホスト５００側の処理シーケンスについて説明する。ホスト５００は、まず、前述したようにステップＳ３０１においてドライブ装置４００との相互認証および鍵交換（ＡＫＥ）を実行し、セッションキー：Ｋｓを取得する。

次に、ステップＳ３０２において、ドライブから接続バスを介して入力したセッションキー：Ｋｓによって暗号化されたエンベデッドキー：Ｋｅ、すなわち［ＥＫｓ（Ｋｅ）］に対して、セッションキー：Ｋｓを適用した復号処理を実行しエンベデッドキー：Ｋｅを取得する。

さらに、ステップＳ３０３において、ドライブから接続バスを介して入力したユニットキー生成情報：Ｖｕに対してエンベデッドキー：Ｋｅを適用したＡＥＳ鍵生成処理（図１１参照）を実行し、ユニットキー：Ｋｕを生成する。

さらに、ステップＳ３０４において、ドライブから接続バスを介して入力したセッションキー：Ｋｓによって暗号化されたバスキー：Ｋｂｕｓ、すなわち［ＥＫｓ（Ｋｂｕｓ）］に対して、セッションキー：Ｋｓを適用した復号処理を実行しバスキー：Ｋｂｕｓを取得する。

なお、先に、図１５を参照して説明したように、ドライブから送信されるバスキー：Ｋｂｕｓを含むデータは、バスキー：Ｋｂｕｓおよびバスキーのシーケンス番号：ＳＥＱとの連結データ：［Ｋｂｕｓ‖ＳＥＱ］と、この連結データの改竄検証用データとして算出したハッシュ値［ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］とをセッションキー：Ｋｓを用いて暗号化したデータ：ＥＫｓ［（Ｋｂｕｓ‖ＳＥＱ），ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］である。

ホスト５００のアプリケーションは、ステップＳ３０４において、データ：ＥＫｓ［（Ｋｂｕｓ‖ＳＥＱ），ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］をセッションキー：Ｋｓで復号し、バスキー：Ｋｂｕｓおよびバスキーのシーケンス番号：ＳＥＱとの連結データ：［Ｋｂｕｓ‖ＳＥＱ］と、この連結データの改竄検証用データとして算出したハッシュ値［ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］とを取得する。

次に、ステップＳ３０５において、連結データ：［Ｋｂｕｓ‖ＳＥＱ］のハッシュ値を算出し、ドライブからの入力データ中に含まれるハッシュ値［ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］と比較を実行する。両ハッシュ値が一致していれば、連結データ：［Ｋｂｕｓ‖ＳＥＱ］が改竄されていないものと判定し、ステップＳ３０６におけるバスキー：Ｋｂｕｓを適用したコンテンツ復号処理に移行する。

ステップＳ３０６では、ドライブ装置４００から入力するバスキー：Ｋｂｕｓによって再暗号化された暗号化コンテンツの復号処理を実行する。

バスキー：Ｋｂｕｓによって再暗号化された暗号化コンテンツの復号処理の詳細について、図１８を参照して説明する。バスキー：Ｋｂｕｓを適用した暗号化コンテンツの復号処理は、例えば図１８に示すように、ＡＥＳ−ＣＢＣモードを適用したブロック復号処理によって実行される。

ホスト５００のアプリケーションは、ドライブ装置４００から接続バスを介して入力する暗号化コンテンツに対して、ドライブから入力したバスキー：Ｋｂｕｓを適用して、所定データブロック単位（１６バイト）で復号する処理を実行する。

まず、ドライブ装置４００から接続バスを介して入力する暗号化コンテンツの構成データである２０４８バイトのセクタデータ３７０から先頭の１６バイトデータを取得し、ＡＥＳ復号処理部［ＡＥＳ＿Ｄ］３７１に入力し、バスキー：Ｋｂｕｓを適用したＡＥＳ暗号アルゴリズムに従った復号処理を実行し、さらに、初期値：ＩＶｂとの排他論理和（ＸＯＲ）演算を実行して復号結果を得る。初期値：ＩＶｂは、予め設定された定数である。ＩＶｂは、例えば、セクタデータ３７０に対応するユーザ制御データ（ＵＣＤ）から取得されるという場合もある。

さらに、１６バイト単位の復号結果データは、次のブロックの復号処理に適用する入力値として適用される。以下、各１６バイトのブロックデータ毎にＡＥＳ復号処理および排他論理和（ＸＯＲ）を同様に繰り返し実行して、バスキーによる暗号化を解除したセクタデータ、すなわち、情報記録媒体２００に格納されたデータ状態としての暗号化（スクランブル）セクタデータ３７２を取得する。

さらに、ホスト５００のホストアプリケーションは、図１３に示すステップＳ３０７において、ユニットキー：Ｋｕを適用して、情報記録媒体２００に格納されたデータ状態としての暗号化コンテンツの復号処理を実行する。この復号処理は、先に図１２を参照して説明したと同様の処理として実行される。

以上の処理により、ホスト５００のホストアプリケーションは、復号コンテンツ５２０を取得し、スピーカ、ディスプレイ等の出力部に対する出力処理を行いコンテンツ再生を実行する。

このように、本発明の構成では、情報記録媒体のデータ読み取りを実行するドライブにおいて、情報記録媒体から読み出したスクランブル処理されたデータをバスキー：Ｋｂｕｓを適用して再暗号化してホスト側に出力する構成としたので、バスキー：Ｋｂｕｓを保持しているホスト側アプリケーション、すなわちドライブとの相互認証が成立したホストアプリケーションのみにおいてバスキー：Ｋｂｕｓを適用した復号が可能となり、復号処理による暗号化コンテンツの利用が可能となる。

従って、コンテンツを入力するＰＣ（ホスト）側でのアプリケーションの切り替えによるコンテンツの迂回取得や、ドライブとホストとの接続バスの転送データを盗聴することによるコンテンツ取得を行なってもバスキー：Ｋｂｕｓによって暗号化されたデータの復号は、ドライブとの相互認証が成立し、同一のバスキー：Ｋｂｕｓを持つ唯一のアプリケーションのみが可能となるので、他のアプリケーション、例えばＣＳＳスクランブルの解除プログラムはバスキー：Ｋｂｕｓによる暗号化データの復号が不可能でありコンテンツの不正利用が防止される。

次に、図１９〜図２１を参照して、図１３に示すステップＳ２０８、ステップＳ２０９において実行する出力制御情報解析と、コンテンツの出力制御の複数の態様について説明する。

先に、図９を参照して説明したように、情報記録媒体に格納した暗号化コンテンツのセクタヘッダ（ユーザ制御データ）には、ドライブからＰＣ等の情報処理装置に対する出力制御情報として、
（１）出力制御フラグ（Output Control Flag）
（２）セキュリティレベル（Security Level）
（３）アプリケーションＩＤ（Application ID）
の各情報が設定されると説明した。

これら（１）〜（３）の３種類の情報のすべてを出力制御情報として設定する態様も可能であるが、（１）出力制御フラグ（Output Control Flag）のみ、あるいは、（１）出力制御フラグ（Output Control Flag）と、（３）アプリケーションＩＤ（Application ID）のみを設定するなど、各種の態様が可能である。また、設定情報としては（１）〜（３）の全てが設定されている場合であっても、ドライブにおける出力制御情報の解析に際して、その一部のみを適用した解釈を実行してもよい。以下、これらの複数の処理態様について、図１９〜図２１を参照してドライブ側の処理シーケンス例について説明する。

図１９〜図２１は、それぞれ、以下の処理を説明するシーケンスである。
図１９：出力制御情報中の［出力制御フラグ］のみに基づく出力制御シーケンス
図２０：出力制御情報中の［出力制御フラグ］と［アプリケーションＩＤ］に基づく出力制御シーケンス
図２１：出力制御情報中の［出力制御フラグ］と［アプリケーションＩＤ］と［セキュリティレベル］に基づく出力制御シーケンス

まず、図１９を参照して、出力制御情報中の［出力制御フラグ］のみに基づいて、ドライブからホストに対するコンテンツ出力を制御するシーケンスについて説明する。

図１９のフローの各ステップについて説明する。まず、ステップＳ５１１においてドライブに対する情報記録媒体（ディスク）の挿入を検知し、ステップＳ５１２において、バス接続されたホスト側でのコンテンツ再生処理を実行するホストアプリケーションの起動を検知する。これらが検知されたことを条件として、ステップＳ５１３に進み、ホスト側からの相互認証要求を待機し、相互認証要求を受信すると、ステップＳ５１４において、先に図１５、図１６を参照して説明した公開鍵暗号方式に従った相互認証および鍵交換（ＡＫＥ）処理を実行する。

この認証処理においては、図１６を参照して説明したように、公開鍵証明書内のＳＡＣタイプ、デバイスタイプを抽出する。ＳＡＣタイプに基づいて認証相手とのデータ転送において適用するチャネルタイプを確認し、公開鍵証明書に設定されたチャネルタイプが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、この確認に基づいて認証の成立可否を判定する。例えば、公開鍵証明書に設定されたチャネルタイプが、ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、この確認に基づいて認証の成立可否を判定する。

また、認証相手の公開鍵証明書の格納データに基づいて認証相手のデバイスタイプを確認し、このデバイスタイプに基づいて認証の成立可否を判定する。具体的には、デバイスタイプがホストであるか、ドライブであるかを確認し、予め定めた認証条件としてのデバイスタイプに基づいて認証の成立可否を判定する。

ステップＳ５１５において、相互認証および鍵交換（ＡＫＥ）処理の完了が確認されると、ステップＳ５１６に進み、ドライブは、バスキー：Ｋｂに対応する乱数Ｒの生成処理を実行し、この生成乱数Ｒをバスキー：Ｋｂとする。この処理は、図１３におけるステップＳ２０６の処理に相当する。なお、前述したように、バスキー：Ｋｂには、シーケンス番号が対応付けられる。ドライブは、複数の異なるシーケンス番号に対応する異なるバスキーを保持し、ホスト側の実行アプリケーションに応じて切り替えて適用する場合もある。

ステップＳ５１７において、ホスト側からバスキーの転送要求を受領すると、ステップＳ５１８において、バスキー：Ｋｂをホスト側に転送する。この処理は、図１３におけるステップＳ２０７の処理に相当する。なお、このバスキー転送は、図１５の相互認証および鍵交換（ＡＫＥ）処理の最終ステップＳ４０８に相当する処理であり、ドライブは、バスキー：Ｋｂｕｓおよびバスキーのシーケンス番号：ＳＥＱとの連結データ：［Ｋｂｕｓ‖ＳＥＱ］と、この連結データの改竄検証用データとして算出したハッシュ値［ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］とをセッションキー：Ｋｓを用いて暗号化したデータ：ＥＫｓ［（Ｋｂｕｓ‖ＳＥＱ），ｈａｓｈ（Ｋｂｕｓ‖ＳＥＱ）］を生成してホスト側に送信する。

次に、ステッブＳ５１９では、新たな相互認証要求がないことを確認し、また、ステップＳ５２０では、情報記録媒体の排出がなされないことを確認して、ステップＳ５２１において、ホスト側のコンテンツ取得要求、すなわちセクタデータの読み取り要求がなされるまで待機する。

なお、ステップＳ５１９において、新たな相互認証要求があった場合は、ステップＳ５１４に戻り相互認証および鍵交換（ＡＫＥ）処理を実行し、新たなバスキーの生成、送信を実行する。この際に生成するバスキーは、シーケンス番号：２のバスキーであり、先に生成したバスキー（シーケンス番号１）とは異なるバスキーとなる。これらは、ホスト側の異なるアプリケーションに対応するバスキーであり、ドライブは、ホスト側の起動アプリケーション毎に相互認証および鍵交換（ＡＫＥ）処理を実行し、新たなバスキーの生成、送信を実行し、コンテンツ送信に際しては、ホスト側の起動アプリケーション毎に対応するバスキーを適用した暗号化データを生成して送信する。

なお、ステップＳ５２０において、ドライブからのディスク排出があったと判定した場合は、ステップＳ５１１に戻り、初期招待に設定され、生成済みのバスキー、セッションキー等のすべてのデータはリセット、すなわち消去される。

ステップＳ５２１において、ホスト側からセクタデータの読み出し要求があると、ドライブは、ステップＳ５２２において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）から出力制御情報を読み取り、［出力制御フラグ：ＯＣＦ］の値を判定する。この処理は、図１３のステップＳ２０８の処理に相当する。

出力制御フラグ：ＯＣＦは、先に図９を参照して説明したように、
ＯＣＦ＝１：出力制限あり、バス暗号化あり、
ＯＣＦ＝０：出力制限なし、
の設定情報である。

ステップＳ５２２において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［１］に設定されていると判定した場合は、ステップＳ５２３に進み、情報記録媒体から読出したセクタデータをバスキー：Ｋｂｕｓで暗号化して、ステップＳ５２４においてホスト側に出力する。なお、ステップＳ５２３におけるセクタデータの暗号化処理は、例えば、先に図１７を参照して説明したＡＥＳ−ＣＢＣモードを適用した暗号化処理として実行される。

ステップＳ５２２において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［０］に設定されていると判定した場合は、ステップＳ５２３をスキップし、情報記録媒体から読出したセクタデータのバスキー：Ｋｂｕｓによる暗号化処理を実行することなく、ステップＳ５２４において、情報記録媒体からの読出しコンテンツをそのままホスト側に出力する。なお、この読出しコンテンツは、例えばＣＳＳ規定に従った暗号化（スクランブル）コンテンツである。

このように、ドライブは、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［０］か［１］かに基づいてバスキーによる暗号化の要否を判定し、バスキーによる暗号化の必要なデータである場合に、出力コンテンツのバスキーによる暗号化を実行して出力する。

次に、図２０を参照して、出力制御情報中の［出力制御フラグ］と［アプリケーションＩＤ］とに基づいて、ドライブからホストに対するコンテンツ出力を制御するシーケンスについて説明する。

図２０のフローの各ステップについて説明する。まず、ステップＳ６１１において、初期設定処理としてセッションＩＤ［ＳＩＤ］と、バスキー：Ｋｂｕｓの値を初期値［０］に設定する。セッションＩＤは、ドライブトホスト間で設定されたセッションに対応する識別子であり、ホストドライブ間において設定されたセッションに対しては、ホストドライブ間の相互認証および鍵交換（ＡＫＥ）処理において、ドライブがホストから受領したホストのアプリケーション対応の公開鍵証明書（図１４参照）から取得したアプリケーションＩＤ［ＡＩＤｃｅｒｔ］と同一の値がセッションＩＤとされる。すなわち、ＳＩＤ＝ＡＩＤｃｅｒｔとしてセッションＩＤが決定される。

ステップＳ６１２〜Ｓ６１６の処理は、図１９において説明した処理ステップＳ５１１〜５１５と同様の処理であり、説明を省略する。

ステップＳ６１７では、ホストドライブ間の相互認証および鍵交換（ＡＫＥ）処理において、ドライブが、ホストから受領したホストのアプリケーション対応の公開鍵証明書（図１４参照）から取得したアプリケーションＩＤ［ＡＩＤｃｅｒｔ］と、セッションＩＤ［ＳＩＤ］が一致するか否かを判定する。

ＳＩＤ＝ＡＩＤｃｅｒｔであれば、既に成立済みのセッションであり、セッション対応のバスキーが存在しているので、バスキー生成処理を実行することなくステップＳ６２０に進む。

ＳＩＤ≠ＡＩＤｃｅｒｔであれば、新たなセッションであり、ステップＳ６１８において、セッション対応のバスキーの生成処理を実行する。これは乱数生成によるバスキーの生成として実行する。なお、バスキーにはシーケンス番号が対応付けられる。それぞれのセッション対応のバスキーは区別されて記憶され、利用される。

バスキー：Ｋｂｕｓの生成が完了すると、ステップＳ６１９において、新たなセッションに対するセッション識別子をホストドライブ間の相互認証および鍵交換（ＡＫＥ）処理において、ドライブが、ホストから受領したホストのアプリケーション対応の公開鍵証明書（図１４参照）から取得したアプリケーションＩＤ［ＡＩＤｃｅｒｔ］として設定、すなわち、ＳＩＤ＝ＡＩＤｃｅｒｔとして設定する。

ステップＳ６２０〜Ｓ６２４の処理は、先に説明した図１９のフローにおけるステップＳ５１７〜５２１の処理と同様であるので、説明を省略する。

ステップＳ６２４において、ホスト側からセクタデータの読み出し要求があると、ドライブは、ステップＳ６２５において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）から出力制御情報を読み取り、［出力制御フラグ：ＯＣＦ］の値を判定する。この処理は、図１３のステップＳ２０８の処理に相当する。

出力制御フラグ：ＯＣＦは、先に図９を参照して説明したように、
ＯＣＦ＝１：出力制限あり、バス暗号化あり、
ＯＣＦ＝０：出力制限なし、
の設定情報である。

ステップＳ６２５において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［１］に設定されていると判定した場合は、ステップＳ６２６に進み、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中のアプリケーションＩＤ［ＡＩＤｕｃｄ］と、ホストドライブ間の相互認証および鍵交換（ＡＫＥ）処理において、ドライブが、ホストから受領したホストのアプリケーション対応の公開鍵証明書（図１４参照）から取得したアプリケーションＩＤ［ＡＩＤｃｅｒｔ］とが一致するか否か、すなわち、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立するか否かを判定する。

前述したように、出力制御情報中のアプリケーションＩＤ［ＡＩＤｕｃｄ］は、出力を許容するアプリケーションを示す識別情報であり、ドライブは、ホストのアプリケーションが、出力制御情報中のアプリケーションＩＤ［ＡＩＤｕｃｄ］に一致する場合にのみ、コンテンツ出力を許容する。

ステップＳ６２６において、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立しないと判定した場合は、ステップＳ６２９においてドライブからホスト側にエラーメッセージを送信し、処理を終了する。この場合、コンテンツの送信は実行されない。

ステップＳ６２６において、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立すると判定した場合は、ステップＳ６２７において、情報記録媒体から読出したセクタデータをバスキー：Ｋｂｕｓで暗号化して、ステップＳ６２８においてホスト側に出力する。なお、ステップＳ６２７におけるセクタデータの暗号化処理は、例えば、先に図１７を参照して説明したＡＥＳ−ＣＢＣモードを適用した暗号化処理として実行される。

ステップＳ６２５において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［０］に設定されていると判定した場合は、ステップＳ６２６，Ｓ６２７をスキップし、アプリケーションＩＤの判定処理、および情報記録媒体から読出したセクタデータのバスキー：Ｋｂｕｓによる暗号化処理を実行することなく、ステップＳ６２８に進み、情報記録媒体からの読出しコンテンツをそのままホスト側に出力する。なお、この読出しコンテンツは、例えばＣＳＳ規定に従った暗号化（スクランブル）コンテンツである。

この実施例においては、ドライブは、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［０］か［１］かを判定し、出力制御を実行するか否かを判定するともに、出力制御フラグ（ＯＣＦ）に基づいて出力制御が必要とされる場合には、さらに、アプリケーションＩＤの検証、すなわち、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中のアプリケーションＩＤ［ＡＩＤｕｃｄ］と、ホストドライブ間の相互認証および鍵交換（ＡＫＥ）処理において、ドライブが、ホストから受領したホストのアプリケーション対応の公開鍵証明書から取得したアプリケーションＩＤ［ＡＩＤｃｅｒｔ］とが一致するか否か、すなわち、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立するか否かを判定し、一致する場合にコンテンツ出力を許容して、出力コンテンツのバスキーによる暗号化を実行して出力する。

この構成とすることで、ホスト側で実行しているアプリケーションの確認に基づくコンテンツ出力が実現される。なお、アプリケーションＩＤは公開鍵証明書に格納されたデータであり、管理センタの署名に基づいて相互認証時に改竄検証の実行されたデータであるので、信頼性の担保されたデータに基づくアプリケーションの確認が可能となる。

次に、図２１を参照して、出力制御情報中の［出力制御フラグ］と［アプリケーションＩＤ］と、［セキュリティレベル］とに基づいて、ドライブからホストに対するコンテンツ出力を制御するシーケンスについて説明する。

図２１のフローの各ステップの処理について説明する。図２１のフローにおいて、ステップＳ６３１〜Ｓ６４４は、先に説明した図２０のフローにおけるステップＳ６１１〜Ｓ６２４と同様の処理であるので、説明を省略する。

ステップＳ６４４において、ホスト側からセクタデータの読み出し要求があると、ドライブは、ステップＳ６４５において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）から出力制御情報を読み取り、［出力制御フラグ：ＯＣＦ］の値を判定する。この処理は、図１３のステップＳ２０８の処理に相当する。

出力制御フラグ：ＯＣＦは、先に図９を参照して説明したように、
ＯＣＦ＝１：出力制限あり、バス暗号化あり、
ＯＣＦ＝０：出力制限なし、
の設定情報である。

ステップＳ６４５において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［１］に設定されていると判定した場合は、ステップＳ６４６に進み、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中のセキュリティレベル［ＳＬｕｃｄ］と、ホストドライブ間の相互認証および鍵交換（ＡＫＥ）処理において、ドライブが、ホストから受領したホストのアプリケーション対応の公開鍵証明書（図１４参照）から取得したセキュリティレベル［ＳＬｃｅｒｔ］との値の比較を実行する。

セクタヘッダ（ユーザ制御データ）の出力制御情報中に記録されたセキュリティレベル［ＳＬｕｃｄ］はコンテンツ出力を許容するアプリケーションのセキュリティレベルを設定した情報であり、許容する最低のセキュリティレベルの値が記録される。例えば１１１１（最高レベル）〜００００（最低レベル）のいずれかの値が設定される。ホストアプリケーション対応の公開鍵証明書に記録さたれセキュリティレベル［ＳＬｃｅｒｔ］は、ホストアプリケーション対応のセキュリティレベルの値である。

ドライブは、ホストアプリケーション対応のセキュリティレベル［ＳＬｃｅｒｔ］の値が、出力制御情報中に記録されたセキュリティレベル［ＳＬｕｃｄ］の値以上である場合に、コンテンツ出力の許容アプリケーションであると判定する。すなわち、
ＳＬｕｃｄ≦ＳＬｃｅｒｔ
である場合に、コンテンツ出力の許容アプリケーションであると判定する。

ステップＳ６４６において、
ＳＬｕｃｄ≦ＳＬｃｅｒｔ
が成立しないと判定した場合は、ステップＳ６５０においてドライブからホスト側にエラーメッセージを送信し、処理を終了する。この場合、コンテンツの送信は実行されない。

ステップＳ６４６において、
ＳＬｕｃｄ≦ＳＬｃｅｒｔ
が成立すると判定した場合は、さらに、ステップＳ６４７において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中のアプリケーションＩＤ［ＡＩＤｕｃｄ］と、ホストから受領したホストのアプリケーション対応の公開鍵証明書（図１４参照）から取得したアプリケーションＩＤ［ＡＩＤｃｅｒｔ］とが一致するか否か、すなわち、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立するか否かを判定する。
この処理は、図２０において説明したステップＳ６２６の処理と同様である。

ステップＳ６４７において、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立しないと判定した場合は、ステップＳ６５０においてドライブからホスト側にエラーメッセージを送信し、処理を終了する。この場合、コンテンツの送信は実行されない。

ステップＳ６４７において、
ＡＩＤｕｃｄ＝ＡＩＤｃｅｒｔ
が成立すると判定した場合は、ステップＳ６４８において、情報記録媒体から読出したセクタデータをバスキー：Ｋｂｕｓで暗号化して、ステップＳ６４９においてホスト側に出力する。なお、ステップＳ６２７におけるセクタデータの暗号化処理は、例えば、先に図１７を参照して説明したＡＥＳ−ＣＢＣモードを適用した暗号化処理として実行される。

なお、ステップＳ６４５において、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［０］に設定されていると判定した場合は、ステップＳ６４６〜Ｓ６４８をスキップし、セキュリティレベルの判定処理、アプリケーションＩＤの判定処理、および情報記録媒体から読出したセクタデータのバスキー：Ｋｂｕｓによる暗号化処理を実行することなく、ステップＳ６４９に進み、情報記録媒体からの読出しコンテンツをそのままホスト側に出力する。なお、この読出しコンテンツは、例えばＣＳＳ規定に従った暗号化（スクランブル）コンテンツである。

この実施例においては、ドライブは、読み出し対象のセクタデータに対応するセクタヘッダ（ユーザ制御データ）の出力制御情報中の出力制御フラグ（ＯＣＦ）が［０］か［１］かを判定し、出力制御を実行するか否かを判定するともに、出力制御フラグ（ＯＣＦ）に基づいて出力制御が必要とされる場合には、さらに、セキュリティレベルの検証と、アプリケーションＩＤの検証を実行する構成である。

本構成によれば、ホスト側で実行しているアプリケーションのセキュリティレベルと、アプリケーション確認に基づくコンテンツ出力が実現される。なお、セキュリティレベルとアプリケーションＩＤは公開鍵証明書に格納されたデータであり、管理センタの署名に基づいて相互認証時に改竄検証の実行されたデータであるので、信頼性の担保されたデータに基づくセキュリティレベルおよびアプリケーションの確認が可能となる。

［３．ホストおよびドライブを構成する情報処理装置の構成］
次に、図２２、図２３を参照して、例えば情報記録媒体の格納コンテンツの再生や外部からのコンテンツ入力およびドライブに対するコンテンツ出力などの各種の処理を行うＰＣなどによって構成されるホストおよび、情報記録媒体の格納コンテンツの読み取りおよび出力を実行するドライブ装置を構成する情報処理装置の構成例について説明する。

まず、図２２を参照して、ホストとしての情報処理装置の構成について説明する。情報処理装置（ホスト）６００は、ＯＳやコンテンツ再生アプリケーションプログラム、相互認証処理プログラムなどの各種プログラムに従ったデータ処理を実行するＣＰＵ６７０、プログラム、パラメータ等の記憶領域としてのＲＯＭ６６０、メモリ６８０、デジタル信号を入出力する入出力Ｉ／Ｆ６１０、アナログ信号を入出力し、Ａ／Ｄ，Ｄ／Ａコンバータ６４１を持つ入出力Ｉ／Ｆ６４０、ＭＰＥＧデータのエンコード、デコード処理を実行するＭＰＥＧコーデック６３０、ＴＳ（Transport Stream）・ＰＳ(Program Stream)処理を実行するＴＳ・ＰＳ処理手段６２０、相互認証、暗号化コンテンツの復号処理など各種の暗号処理を実行する暗号処理手段６５０、ハードディスクなどの記録媒体６９１、記録媒体６９１の駆動、データ記録再生信号の入出力を行なうドライブ６９０を有し、バス６０１に各ブロックが接続されている。

情報処理装置（ホスト）６００は、例えばＡＴＡＰＩＢＵＳ等の接続バスによってドライブと接続され、上述したバスキーによって暗号化されたコンテンツは、デジタル信号用入出力Ｉ／Ｆ６１０から入力され、必要に応じて暗号化処理手段６５０によって、例えば、図１８を参照して説明したＡＥＳ−ＣＢＣモードによる復号処理が実行される。

なお、コンテンツ再生処理を実行するプログラムは例えばＲＯＭ６６０内に保管されており、プログラムの実行処理中は必要に応じて、パラメータ、データの保管、ワーク領域としてメモリ６８０を使用する。

ＲＯＭ６６０または記録媒体６９１には、先に図１３を参照して説明した管理センタの公開鍵、ホストアプリケーションに対応する秘密鍵、ホストアプリケーションに対応する公開鍵証明書が格納されている。なお、複数のホストアプリケーションを保持している場合は、それぞれに対応する秘密鍵と公開鍵証明書が格納される。

次に、図２３を参照して、情報記録媒体の格納コンテンツの読み取り、および情報処理装置（ホスト）に対する出力を実行するドライブの構成について説明する。ドライブ装置７００は、コンテンツ読み取り、転送処理プログラム、相互認証処理プログラムなどの各種プログラムに従ったデータ処理を実行するＣＰＵ７０２、プログラム、パラメータ等の記憶領域としてのＲＯＭ７０５、メモリ７０６、デジタル信号を入出力する入出力Ｉ／Ｆ７０３、相互認証、バスキーの生成、出力データの暗号化処理など各種の暗号処理を実行する暗号処理手段７０４、ＤＶＤ，Ｂｌｕ−ｒａｙディスクなどの情報記録媒体７０８の駆動、データ記録再生信号の入出力を行なう記録媒体Ｉ／Ｆ７０７を有し、バス７０１に各ブロックが接続されている。

ドライブ７００は、例えばＡＴＡＰＩＢＵＳ等の接続バスによって情報処理装置（ホスト）と接続され、例えば情報記録媒体７０８に格納された暗号化（スクランブル）コンテンツをバスキー：Ｋｂｕｓで、再暗号化し入出力Ｉ／Ｆ７０３から出力する。バスキー：Ｋｂｕｓを適用したコンテンツの暗号化は、暗号化処理手段７０４によって、例えば、図１７を参照して説明したＡＥＳ−ＣＢＣモードで実行される。

なお、ＲＯＭ７０５、またはメモリ７０６には、先に図１３を参照して説明した管理センタの公開鍵、ドライブに対応する秘密鍵、ドライブに対応する公開鍵証明書、および暗号鍵ブロックＲＫＢの処理に適用するためのデバイスキー：Ｋｄｅｖが格納されている。また、コンテンツの読み取り、取得、および相互認証処理を実行するプログラム等が格納されている。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。

例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。

なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本発明の構成によれば、例えばコンテンツ再生処理や記録処理など機器間でのデータ転送を伴うデータ処理を実行する場合に、データ転送機器間において認証処理を実行し、この認証処理において認証相手機器の公開鍵証明書の格納データからチャネルタイプ情報を取得し、チャネルタイプ情報に基づいて適用するチャネルタイプを確認し、確認したチャネルタイプに基づいて認証成立の可否を判定する構成としたので、不正なアプリケーションやドライブが接続して、不正に取得した鍵によって認証を成立させて、コンテンツの転送を行なわせる処理を排除できる。例えばホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）適用のデータ処理を行なうホスト−デバイスタイプであることの確認を認証成立の条件としたので、例えば、他のタイプのチャネルを適用するアプリケーションやドライブが不正な鍵情報を有し認証を成立させてコンテンツを不正に入手するなどの処理を排除可能となる。

さらに、本発明の構成によれば、公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、これらの確認処理を条件とした認証を行なう構成としたので、特定のセキュアチャネルを適用したデータ処理を実行するアプリケーションとドライブとの対応が成立した場合にのみチャネル間のデータ転送を伴うデータ処理が許容され、不正なアプリケーションやドライブの接続によるコンテンツの不正取得を排除することが可能となる。

さらに、本発明の構成によれば、認証相手の公開鍵証明書の格納データに基づいて、認証相手のデバイスタイプを確認する。具体的には、アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかのいずれかを確認し、チャネルタイプと、デバイスタイプとに基づいて認証成立の可否を判定する構成としたので、さらに厳格な認証が可能となり、不正なアプリケーションやドライブの接続によるコンテンツの不正取得を排除することが可能となる。

従来の情報記録媒体格納コンテンツの再生シーケンスを説明する図である。 従来の情報処理装置（ホスト）におけるドライブ出力コンテンツの再生シーケンスを説明する図である。 ドライブからのコンテンツ出力シーケンスを説明するフロー図である。 従来のホストドライブ間のコンテンツ転送を伴う処理構成におけるコンテンツの不正利用例を説明する図である。 従来のホストドライブ間のコンテンツ転送を伴う処理構成におけるコンテンツの不正利用例を説明する図である。 本発明の情報記録媒体の格納データについて説明する図である。 本発明の情報記録媒体の格納データの構成について説明する図である。 本発明の情報記録媒体の格納データとしてのセクタデータおよびセクタヘッダの構成について説明する図である。 本発明の情報記録媒体のセクタヘッダに記録される出力制御情報の詳細について説明する図である。 情報記録媒体の格納コンテンツの読み取り、再生を実行する再生機器の処理シーケンスについて説明する図である。 情報記録媒体の格納コンテンツの再生において実行するＡＥＳ暗号アルゴリズムに従った鍵生成処理について説明する図である。 情報記録媒体の格納コンテンツの再生において実行するＡＥＳ暗号アルゴリズムに従ったデータ復号処理について説明する図である。 本発明のドライブ装置と情報処理装置（ホスト）において実行するコンテンツ転送を伴う再生シーケンスを説明する図である。 ドライブ装置と情報処理装置（ホスト）に格納される公開鍵証明書のデータ構成について説明する図である。 ドライブ装置と情報処理装置（ホスト）間で実行する相互認証および鍵交換（ＡＫＥ）処理シーケンスを説明する図である。 ドライブ装置と情報処理装置（ホスト）間で実行する相互認証時の公開鍵証明書の検証処理シーケンスを説明するフロー図である。 ドライブ装置で実行するコンテンツのバスキー：Ｋｂｕｓに基づく暗号化処理構成を説明する図である。 情報処理装置（ホスト）で実行するコンテンツのバスキー：Ｋｂｕｓに基づく復号処理構成を説明する図である。 ドライブ装置で実行するコンテンツの出力制御処理例１を説明するフローチャートを示す図である。 ドライブ装置で実行するコンテンツの出力制御処理例２を説明するフローチャートを示す図である。 ドライブ装置で実行するコンテンツの出力制御処理例３を説明するフローチャートを示す図である。 本発明の情報処理装置（ホスト）の構成例を示す図である。 本発明のドライブ装置の構成例を示す図である。

符号の説明

１０ 情報記録媒体
１１ 暗号化ディスクキー
１２ 暗号化タイトルキー
１３ スクランブルＭＰＥＧデータ
２０ 再生機器
２５ 音声／映像データ
３０ ドライブ
４０ プレーヤ・アプリケーション
４５ 音声／映像データ
６０ ドライブ
６１ 鍵情報
７０ ホスト側プレーヤ・アプリケーション
７１ 鍵情報
１００ 情報記録媒体
１０１ ユーザデータ領域
１０２ リードイン領域
１１１ 暗号化コンテンツ
１１２ ユニットキー生成情報
１１３ リボーク情報
１１４ ＲＯＭマーク
１２０ 暗号鍵情報
１２１ 暗号鍵ブロック（ＲＫＢ）
１２２ 暗号化ディスクキー
１５１ 出力制御情報
２００ 情報記録媒体
２０１ リボーク情報
２０２ 暗号鍵ブロック（ＲＫＢ）
２０３ 暗号化ディスクキー
２０４ ＲＯＭマーク
２０５ ユニットキー生成情報
２０６ 暗号化コンテンツ
３００ ドライブ兼用再生機器
３０１ デバイスキー
３１１ ＡＥＳ暗号処理ブロック
３２１ ＡＥＳ鍵生成処理ブロック
３２２ ＡＥＳ復号処理ブロック
３２３ 復号セクタデータ
３５０ セクタデータ
３５１ ＡＥＳ暗号処理部
３５２ バスキーによる暗号化セクタデータ
３７０ バスキーによる暗号化セクタデータ
３７１ ＡＥＳ復号処理部
３７２ 暗号化（スクランブル）セクタデータ
４００ ドライブ装置
４０１ 管理センタ公開鍵
４０２ ドライブ秘密鍵
４０３ ドライブ公開鍵証明書
４０４ デバイスキー
５００ 情報処理装置（ホスト）
５０１ 管理センタ公開鍵
５０２ ホストアプリケーション秘密鍵
５０３ ホストアプリケーション公開鍵証明書
５２０ コンテンツ
５３０ ドライブ公開鍵証明書
５３１ ＳＡＣタイプ
５３２ デバイスタイプ
５５０ ホストアプリケーション公開鍵証明書
５５１ セキュリティレベル
５５２ アプリケーションＩＤ
５５３ ＳＡＣタイプ
５５４ デバイスタイプ
６００ 情報処理装置（ホスト）
６０１ バス
６１０ 入出力Ｉ／Ｆ
６２０ ＴＳ・ＰＳ処理手段
６３０ ＭＰＥＧコーデック
６４０ 入出力Ｉ／Ｆ
６４１ Ａ／Ｄ，Ｄ／Ａコンバータ
６５０ 暗号処理手段
６６０ ＲＯＭ
６７０ ＣＰＵ
６８０ メモリ
６９０ ドライブ
６９１ 記録媒体
７００ ドライブ装置
７０１ バス
７０２ ＣＰＵ
７０３ 入出力Ｉ／Ｆ
７０４ 暗号処理手段
７０５ ＲＯＭ
７０６ メモリ
７０７ 記録媒体Ｉ／Ｆ
７０８ 情報記録媒体

Claims (15)

1. 情報処理装置であり、
   データ転送処理を行なうインタフェースと、
   データ処理を実行するデータ処理部とを有し、
   前記データ処理部は、
   前記インタフェースを介したデータ転送を伴うデータ処理の実行条件として、データ転送対象との認証処理を実行し、該認証処理において認証相手の保持する公開鍵証明書の格納データに基づいて、データ転送において適用するチャネルタイプを確認し、該チャネルタイプに基づいて認証成立の可否を判定する構成であることを特徴とする情報処理装置。
2. 前記データ処理部は、
   認証相手の保持する公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、
   公開鍵証明書に設定されたチャネルタイプが、
   ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、該確認に基づいて認証の成立可否を判定する構成であることを特徴とする請求項１に記載の情報処理装置。
3. 前記データ処理部は、
   認証相手の保持する公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、
   公開鍵証明書に設定されたチャネルタイプが、
   ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認し、該確認に基づいて認証の成立可否を判定する構成であることを特徴とする請求項１に記載の情報処理装置。
4. 前記データ処理部は、
   前記認証処理において、認証相手の保持する公開鍵証明書の格納データに基づいて、さらに認証相手のデバイスタイプを確認し、該デバイスタイプに基づいて認証の成立可否を判定する構成であることを特徴とする請求項１に記載の情報処理装置。
5. 前記デバイスタイプは、
   アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかのいずれかを示す情報であり、
   前記データ処理部は、
   予め定めた認証条件としてのデバイスタイプに基づいて認証の成立可否を判定する構成であることを特徴とする請求項４に記載の情報処理装置。
6. 前記情報処理装置は、
   ドライブとの接続を行い、アプリケーションを実行するホスト機器であり、
   前記データ処理部は、
   前記認証処理において、ドライブから受領する公開鍵証明書の格納データに基づいて、
   前記ドライブが、
   ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するドライブであることの確認であるＳＡＣタイプ確認と、
   デバイスタイプがドライブであることの確認であるデバイスタイプ確認と、
   上記２つの確認を認証成立の条件とした認証処理を実行する構成であることを特徴とする請求項１に記載の情報処理装置。
7. 前記情報処理装置は、
   アプリケーションを実行するホスト機器と接続し、情報記録媒体に対するデータ記録または読み取りを実行するドライブであり、
   前記データ処理部は、
   前記認証処理において、アプリケーションを実行するホストから受領する公開鍵証明書の格納データに基づいて、
   前記アプリケーションが、
   ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するアプリケーションであることのＳＡＣタイプ確認と、
   デバイスタイプがホストであることの確認であるデバイスタイプ確認と、
   上記２つの確認を認証成立の条件とした認証処理を実行する構成であることを特徴とする請求項１に記載の情報処理装置。
8. 認証処理方法であり、
   認証相手の保持する公開鍵証明書を取得する公開鍵証明書取得ステップと、
   前記公開鍵証明書の格納データからチャネルタイプ情報を取得する情報取得ステップと、
   前記チャネルタイプ情報に基づいて、認証相手とのデータ転送において適用するチャネルタイプを確認するチャネルタイプ確認ステップと、
   前記チャネルタイプ確認ステップにおいて確認したチャネルタイプに基づいて認証成立の可否を判定する認証可否判定ステップと、
   を有することを特徴とする認証処理方法。
9. 前記チャネルタイプ確認ステップは、
   公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、
   ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認するステップであることを特徴とする請求項８に記載の認証処理方法。
10. 前記チャネルタイプ確認ステップは、
    公開鍵証明書の格納データとしてのセキュア認証チャネル（ＳＡＣ）タイプ情報に基づいて、公開鍵証明書に設定されたチャネルタイプが、
    ＡＴＡＰＩバス接続、またはＵＳＢバス接続、またはＩＥＥＥ１３９４におけるシリアルバスプロトコル（ＳＢＰ）を適用したセキュアチャネルを適用したデータ処理を行なうホスト−デバイスタイプであるか否かを確認するステップであることを特徴とする請求項８に記載の認証処理方法。
11. 前記認証処理方法は、さらに、
    認証相手の保持する公開鍵証明書の格納データに基づいて、さらに認証相手のデバイスタイプを確認するデバイスタイプ確認ステップを有し、
    前記認証可否判定ステップは、
    前記チャネルタイプ確認ステップにおいて確認したチャネルタイプと、前記デバイスタイプ確認ステップにおいて確認したデバイスタイプとに基づいて認証成立の可否を判定するステップであることを特徴とする請求項８に記載の認証処理方法。
12. 前記デバイスタイプは、
    アプリケーション実行機器としてのホストであるか、情報記録媒体に対するデータ記録処理または再生処理を実行するドライブであるかのいずれかを示す情報であり、
    前記認証可否判定ステップは、
    予め定めた認証条件としてのデバイスタイプに基づいて認証の成立可否を判定することを特徴とする請求項１１に記載の認証処理方法。
13. 前記認証処理は、ドライブとの接続を行い、アプリケーションを実行するホスト機器において実行する認証処理であり、前記ホスト機器は、ドライブから取得した公開鍵証明書の格納データに基づいて、前記ドライブが、ホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するドライブであることの確認であるＳＡＣタイプ確認と、
    デバイスタイプがドライブであることの確認であるデバイスタイプ確認と、
    上記２つの確認を認証成立の条件とした認証処理を実行することを特徴とする請求項８に記載の認証処理方法。
14. 前記認証処理は、アプリケーションを実行するホスト機器と接続し、情報記録媒体に対するデータ記録または読み取りを実行するドライブにおいて実行する認証処理であり、前記ドライブは、アプリケーションを実行するホストから受領した公開鍵証明書の格納データに基づいて、前記アプリケーションがホストアプリケーション主導のデータ処理を実行するセキュア認証チャネル（ＳＡＣ）を適用したホスト−デバイスタイプのデータ処理を実行するアプリケーションであることのＳＡＣタイプ確認と、
    デバイスタイプがホストであることの確認であるデバイスタイプ確認と、
    上記２つの確認を認証成立の条件とした認証処理を実行することを特徴とする請求項８に記載の認証処理方法。
15. 認証処理を実行するコンピュータ・プログラムであり、
    認証相手の保持する公開鍵証明書を取得する公開鍵証明書取得ステップと、
    前記公開鍵証明書の格納データからチャネルタイプ情報を取得する情報取得ステップと、
    前記チャネルタイプ情報に基づいて、認証相手とのデータ転送において適用するチャネルタイプを確認するチャネルタイプ確認ステップと、
    前記チャネルタイプ確認ステップにおいて確認したチャネルタイプに基づいて認証成立の可否を判定する認証可否判定ステップと、
    を有することを特徴とするコンピュータ・プログラム。

Images