JP4660899B2 - データ処理装置およびデータ処理方法、並びにプログラム提供媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、データ処理装置およびデータ処理方法、並びにプログラム提供媒体に関する。特に、ツリー構造の階層的鍵配信方式を用いることにより、メッセージ量を小さく押さえて、例えばコンテンツキー配信、あるいはその他の暗号処理鍵の配信の負荷を軽減し、かつデータの安全性を保持することを可能とするとともに、有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置に格納することにより効率的なコンテンツ処理を可能としたデータ処理装置およびデータ処理方法、並びにプログラム提供媒体に関する。
【０００２】
【従来の技術】
昨今、音楽データ、ゲームプログラム、画像データ等、様々なソフトウエアデータ（以下、これらをコンテンツ（Content）と呼ぶ）を、インターネット等のネットワーク、あるいは、メモリカード、ＤＶＤ、ＣＤ等の流通可能な記憶媒体を介して流通させるコンテンツ流通が盛んになってきている。これらの流通コンテンツは、ユーザの所有するＰＣ（Personal Computer）、再生専用器、あるいはゲーム機器におけるコンテンツデータの受信、あるいはメモリカード、ＣＤ、ＤＶＤ等の記憶媒体の装着により、コンテンツ再生処理が実行されたり、あるいは外部からの入力コンテンツを再生器、ＰＣ等に内蔵の記録デバイス、例えばメモリカード、ハードディスク等に格納し、再度、格納媒体から再生する等の方法により利用される。
【０００３】
再生装置、ゲーム機器、ＰＣ等の情報機器には、流通コンテンツをネットワークから受信するため、あるいはＤＶＤ、ＣＤ等にアクセスするためのインタフェースを有し、さらにコンテンツの再生に必要となる制御手段、プログラム、データのメモリ領域として使用されるＲＡＭ、ＲＯＭ等を有する。
【０００４】
音楽データ、画像データ、あるいはプログラム等の様々なコンテンツは、再生機器として利用される再生装置、ゲーム機器、ＰＣ等の情報機器本体からのユーザ指示、あるいは接続された入力手段を介したユーザの指示により、例えば内蔵、あるいは着脱自在の記憶媒体から呼び出され、情報機器本体、あるいは接続されたディスプレイ、スピーカ等を通じて再生される。
【０００５】
ゲームプログラム、音楽データ、画像データ等、多くのソフトウエア・コンテンツは、一般的にその作成者、販売者に頒布権等が保有されている。従って、これらのコンテンツの配布に際しては、一定の利用制限、すなわち、正規なユーザに対してのみ、ソフトウエアの使用を許諾し、許可のない複製等が行われないようにする、すなわちセキュリティを考慮した構成をとるのが一般的となっている。
【０００６】
ユーザに対する利用制限を実現する１つの手法が、配布コンテンツの暗号化処理である。すなわち、例えばインターネット等を介して暗号化された音声データ、画像データ、ゲームプログラム等の各種コンテンツを配布するとともに、正規ユーザであると確認された者に対してのみ、配布された暗号化コンテンツを復号する手段、すなわち復号鍵を付与する構成である。
【０００７】
暗号化データは、所定の手続きによる復号化処理によって利用可能な復号データ（平文）に戻すことができる。このような情報の暗号化処理に暗号化鍵を用い、復号化処理に復号化鍵を用いるデータ暗号化、復号化方法は従来からよく知られている。
【０００８】
暗号化鍵と復号化鍵を用いるデータ暗号化・復号化方法の態様には様々な種類あるが、その１つの例としていわゆる共通鍵暗号化方式と呼ばれている方式がある。共通鍵暗号化方式は、データの暗号化処理に用いる暗号化鍵とデータの復号化に用いる復号化鍵を共通のものとして、正規のユーザにこれら暗号化処理、復号化に用いる共通鍵を付与して、鍵を持たない不正ユーザによるデータアクセスを排除するものである。この方式の代表的な方式にＤＥＳ（データ暗号標準：Deta encryption standard）がある。
【０００９】
上述の暗号化処理、復号化に用いられる暗号化鍵、復号化鍵は、例えばあるパスワード等に基づいてハッシュ関数等の一方向性関数を適用して得ることができる。一方向性関数とは、その出力から逆に入力を求めるのは非常に困難となる関数である。例えばユーザが決めたパスワードを入力として一方向性関数を適用して、その出力に基づいて暗号化鍵、復号化鍵を生成するものである。このようにして得られた暗号化鍵、復号化鍵から、逆にそのオリジナルのデータであるパスワードを求めることは実質上不可能となる。
【００１０】
また、暗号化するときに使用する暗号化鍵による処理と、復号するときに使用する復号化鍵の処理とを異なるアルゴリズムとした方式がいわゆる公開鍵暗号化方式と呼ばれる方式である。公開鍵暗号化方式は、不特定のユーザが使用可能な公開鍵を使用する方法であり、特定個人に対する暗号化文書を、その特定個人が発行した公開鍵を用いて暗号化処理を行なう。公開鍵によって暗号化された文書は、その暗号化処理に使用された公開鍵に対応する秘密鍵によってのみ復号処理が可能となる。秘密鍵は、公開鍵を発行した個人のみが所有するので、その公開鍵によって暗号化された文書は秘密鍵を持つ個人のみが復号することができる。公開鍵暗号化方式の代表的なものにはＲＳＡ（Rivest-Shamir-Adleman）暗号がある。このような暗号化方式を利用することにより、暗号化コンテンツを正規ユーザに対してのみ復号可能とするシステムが可能となる。
【００１１】
【発明が解決しようとする課題】
上記のようなコンテンツ配信システムでは、コンテンツを暗号化してユーザにネットワーク、あるいはＤＶＤ、ＣＤ等の記録媒体に格納して提供し、暗号化コンテンツを復号するコンテンツキーを正当なユーザにのみ提供する構成が多く採用されている。コンテンツキー自体の不正なコピー等を防ぐためのコンテンツキーを暗号化して正当なユーザに提供し、正当なユーザのみが有する復号キーを用いて暗号化コンテンツキーを復号してコンテンツキーを使用可能とする構成が提案されている。
【００１２】
正当なユーザであるか否かの判定は、一般には、例えばコンテンツの送信者であるコンテンツプロバイダとユーザデバイス間において、コンテンツ、あるいはコンテンツキーの配信前に認証処理を実行することによって行なう。一般的な認証処理においては、相手の確認を行なうとともに、その通信でのみ有効なセッションキーを生成して、認証が成立した場合に、生成したセッションキーを用いてデータ、例えばコンテンツあるいはコンテンツキーを暗号化して通信を行なう。認証方式には、共通鍵暗号方式を用いた相互認証と、公開鍵方式を使用した認証方式があるが、共通鍵を使った認証においては、システムワイドで共通な鍵が必要になり、更新処理等の際に不便である。また、公開鍵方式においては、計算負荷が大きくまた必要なメモリ量も大きくなり、各デバイスにこのような処理手段を設けることは望ましい構成とはいえない。
【００１３】
本発明では、上述のようなデータの送信者、受信者間の相互認証処理に頼ることなく、正当なユーザに対してのみ、安全にデータを送信することを可能とする階層的鍵配信ツリーを用い、正当なライセンスを持つデバイスにのみ安全に鍵を配信する管理構成を実現する暗号鍵ブロックを用いたシステムを提供するとともに、有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置に格納することにより効率的なコンテンツ処理を可能としたデータ処理装置およびデータ処理方法、並びにプログラム提供媒体を提供することを目的とする。
【００１４】
【課題を解決するための手段】
本発明の第１の側面は、
記憶装置からのコンテンツ再生または記憶装置に対するコンテンツ記録を行なうデータ処理装置において、
前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリーを構成するパス上の更新キー、および下位キーによる上位キーの暗号化処理データを含む有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）を有し、
前記有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置中に格納する構成としたことを特徴とするデータ処理装置にある。
【００１５】
さらに、本発明のデータ処理装置の一実施態様において、前記配信鍵許可情報ファイルは、コンテンツの暗号処理鍵であるコンテンツキーＫｃｏｎを前記ＥＫＢ配信キー暗号キー（ＫＥＫ）によって暗号化したコンテンツキー暗号化データ：Ｅ（ＫＥＫ，Ｋｃｏｎ）を含む構成であることを特徴とする。
【００１６】
さらに、本発明のデータ処理装置の一実施態様において、前記データ処理装置は、有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数の変更に応じて、前記配信鍵許可情報ファイル中のリンクカウント・データを更新する処理を実行する構成を有することを特徴とする。
【００１７】
さらに、本発明のデータ処理装置の一実施態様において、前記データ処理装置は、記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持する構成としたことを特徴とする。
【００１８】
さらに、本発明のデータ処理装置の一実施態様において、前記データ処理装置は、記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持する構成とするとともに、記憶装置に格納したコンテンツの処理において、前記メモリに予め格納したキー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可能な場合においてメモリに予め格納したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場合においてのみ、配信鍵許可情報ファイルの読み出しを実行する構成を有することを特徴とする。
【００１９】
さらに、本発明のデータ処理装置の一実施態様において、前記有効化キーブロック（ＥＫＢ）によって暗号化され提供されるＥＫＢ配信キー暗号キー（ＫＥＫ）は、世代（バージョン）管理がなされ、世代毎の更新処理が実行される構成であることを特徴とする。
【００２０】
さらに、本発明のデータ処理装置の一実施態様において、前記データ処理装置は、前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリー構成中、自己リーフに対応して設定されたリーフキーを、該データ処理装置固有のストレージキー（Ｋｓｔｄ）で暗号化してデータ処理装置内の記憶手段に格納した構成を有することを特徴とする。
【００２１】
さらに、本発明のデータ処理装置の一実施態様において、前記データ処理装置は、前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリー構成中、自己リーフに対応して設定されたリーフキーに基づいて、前記キーツリーの自己リーフから上位に至るパス上の複数段の異なるノードキーを個別に暗号化した暗号化キーの集合としてのデバイスキーブロック（ＤＫＢ）をデータ処理装置内の記憶手段に格納した構成を有することを特徴とする。
【００２２】
さらに、本発明の第２の側面は、
データ処理装置において、記憶装置からのコンテンツ再生または記憶装置に対するコンテンツ記録を行なうデータ処理方法であり、
前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリーを構成するパス上の更新キー、および下位キーによる上位キーの暗号化処理データを含む有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置中に格納することを特徴とするデータ処理方法にある。
【００２３】
さらに、本発明のデータ処理方法の一実施態様において、前記配信鍵許可情報ファイルは、コンテンツの暗号処理鍵であるコンテンツキーＫｃｏｎを前記ＥＫＢ配信キー暗号キー（ＫＥＫ）によって暗号化したコンテンツキー暗号化データ：Ｅ（ＫＥＫ，Ｋｃｏｎ）を含む構成であることを特徴とする。
【００２４】
さらに、本発明のデータ処理方法の一実施態様において、有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数の変更に応じて、前記配信鍵許可情報ファイル中のリンクカウント・データを更新する処理を実行することを特徴とする。
【００２５】
さらに、本発明のデータ処理方法の一実施態様において、前記データ処理方法は、さらに、記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キーをメモリに格納し保持することを特徴とする。
【００２６】
さらに、本発明のデータ処理方法の一実施態様において、前記データ処理方法は、さらに、記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持するとともに、記憶装置に格納したコンテンツの処理において、前記メモリに予め格納したキー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可能な場合においてメモリに予め格納したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場合においてのみ、配信鍵許可情報ファイルの読み出しを実行することを特徴とする。
【００２７】
さらに、本発明の第３の側面は、
記憶装置からのコンテンツ再生または記憶装置に対するコンテンツ記録を行なうデータ処理をコンピュータ・システム上で実行せしめるコンピュータ・プログラムを提供するプログラム提供媒体であって、前記コンピュータ・プログラムは、
記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持するステップと、
記憶装置に格納したコンテンツの処理において、前記メモリに予め格納したキー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可能な場合においてメモリに予め格納したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場合においてのみ、配信鍵許可情報ファイルの読み出しを実行するステップと、
を実行させるプログラムを記録したことを特徴とするプログラム提供媒体にある。
【００２８】
なお、本発明の第３の側面に係るプログラム提供媒体は、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ・プログラムをコンピュータ可読な形式で提供する媒体である。媒体は、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの伝送媒体など、その形態は特に限定されない。
【００２９】
このようなプログラム提供媒体は、コンピュータ・システム上で所定のコンピュータ・プログラムの機能を実現するための、コンピュータ・プログラムと提供媒体との構造上又は機能上の協働的関係を定義したものである。換言すれば、該提供媒体を介してコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の他の側面と同様の作用効果を得ることができるのである。
【００３０】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【００３１】
【発明の実施の形態】
［システム概要］
図１に本発明のデータ処理システムの適用可能なコンテンツ配信システム例を示す。コンテンツ配信手段１０は、データ処理手段２０に対して、コンテンツあるいはコンテンツキー、その他、認証処理キー等のデータを暗号化して送信する。データ処理手段２０では、受信した暗号化コンテンツ、あるいは暗号化コンテンツキー等を復号してコンテンツあるいはコンテンツキー等を取得して、画像データ、音声データの再生、あるいは各種プログラムを実行する。コンテンツの配信手段１０とデータ処理手段２０との間のデータ交換は、インターネット等のネットワークを介して、あるいはＤＶＤ、ＣＤ、その他の流通可能な記憶媒体を介して実行される。
【００３２】
データ処理手段２０は、例えばフラッシュメモリ等の記憶手段を備えたメモリーカード等のデータ記憶手段３０にデータを格納して保存する。データ記憶手段３０には、暗号処理機能を有する記憶手段としての例えばメモリーカード（具体例としてはメモリスティック(Memory Stick:商標））が含まれる。データ処理手段２０からデータ記憶手段３０に対するデータ格納処理、およびデータ記憶手段３０からデータ処理手段に対するデータ移動の際には、相互認証処理、およびデータの暗号処理が実行され不正なデータコピーの防止が図られる。
【００３３】
なお、データ処理手段２０に含まれる各機器間でのコンテンツデータの移動も可能であり、この際にも機器間の相互認証処理、データの暗号処理が実行される。
【００３４】
コンテンツ配信手段１０としては、インターネット１１、衛星放送１２、電話回線１３、ＤＶＤ、ＣＤ等のメディア１４等があり、一方、データ処理手段２０のデバイスとしては、パーソナルコンピュータ（ＰＣ）２１、ポータブルデバイス（ＰＤ）２２、携帯電話、ＰＤＡ（Personal Digital Assistants）等の携帯機器２３、ＤＶＤ、ＣＤプレーヤ等の記録再生器、ゲーム端末２４、メモリーカード（ｅｘ．メモリースティック（商標））を利用した再生装置２５等がある。これらデータ処理手段２０の各デバイスは、コンテンツ配信手段１０から提供されるコンテンツをネットワーク等の通信手段あるいは、他のデータ処理手段、または、データ記憶手段３０から取得可能である。
【００３５】
図２に、代表的なコンテンツデータの移動処理例を示す。図２に示すシステムは、パーソナルコンピュータ（ＰＣ）１００、再生装置２００および記憶装置３００間でのデータ（コンテンツ）の移動処理例を示した図である。ＰＣ１００は、プログラムおよびデータ記憶用のハードディスク（ＨＤ）を有し、さらに、外部記憶媒体としてのＣＤ，ＤＶＤ等を装着可能な構成を持つ。
【００３６】
パーソナルコンピュータ（ＰＣ）１００は、インターネット、公衆回線等の各種ネットワークに接続可能であり、例えば、ＥＭＤ(Electronic Music Distribution: 電子音楽配信）などのサービスを提供する図示しないサービスプロバイダのホストコンピュータから、ネットワークをしてオーディオデータ、画像データ、プログラム等の各種データを受信し、受信したデータを必要に応じて復号して、再生装置２００に出力する。また、パーソナルコンピュータ（ＰＣ）１００は、コンテンツデータを受信するに当たって、必要に応じて、サービスプロバイダのホストコンピュータとの間で認証処理および課金処理などを行う。また、パーソナルコンピュータ（ＰＣ）１００は、例えば、ＣＤ、ＤＶＤから入力したデータを再生装置２００に出力する。
【００３７】
記憶装置３００は、再生装置２００に対して着脱自在な装置、例えばメモリスティック(Memory Stick:商標）であり、フラッシュメモリなどの書き換え可能な半導体メモリを内蔵している。
【００３８】
図２に示すように、ＰＣ１００、再生装置２００、記憶装置３００間におけるデータ移動、例えば音楽データ、画像データ等のデータ再生、データ記録、データコピー等の処理の際にはデータ移動機器間において、相互認証処理が実行され、不正な機器を用いたデータ移動は防止される。これらの処理については後述する。また、コンテンツデータのネットワークまたは各種記憶媒体を介する配信、また、ＰＣと再生装置相互間、あるいは再生装置とメモリカード等の記憶装置間でのコンテンツ移動の際にはコンテンツを暗号化することでデータのセキュリティが保全される。
【００３９】
［キー配信構成としてのツリー（木）構造について］
上述のようなコンテンツに対する暗号処理に適用する暗号鍵、例えばコンテンツの暗号処理に適用するコンテンツキー、またはコンテンツキーを暗号化するためのコンテンツキー暗号化キー等の様々な暗号処理キーを、安全に正当なライセンスを持つデバイスに配信する構成として、階層キー・ツリー構成について図３以下を用いて説明する。
【００４０】
図３の最下段に示すナンバ０〜１５がコンテンツデータの再生、実行を行なうデータ処理手段２０を構成する個々のデバイス、例えばコンテンツ（音楽データ）再生装置である。すなわち図３に示す階層ツリー（木）構造の各葉(リーフ：leaf)がそれぞれのデバイスに相当する。
【００４１】
各デバイス０〜１５は、製造時あるいは出荷時、あるいはその後において、図３に示す階層ツリー（木）構造における、自分のリーフからルートに至るまでのノードに割り当てられた鍵（ノードキー）および各リーフのリーフキーからなるキーセットをメモリに格納する。図３の最下段に示すＫ００００〜Ｋ１１１１が各デバイス０〜１５にそれぞれ割り当てられたリーフキーであり、最上段のＫＲ（ルートキー）から、最下段から２番目の節（ノード）に記載されたキー：ＫＲ〜Ｋ１１１をノードキーとする。
【００４２】
図３に示すツリー構成において、例えばデバイス０はリーフキーＫ００００と、ノードキー：Ｋ０００、Ｋ００、Ｋ０、ＫＲを所有する。デバイス５はＫ０１０１、Ｋ０１０、Ｋ０１、Ｋ０、ＫＲを所有する。デバイス１５は、Ｋ１１１１、Ｋ１１１、Ｋ１１、Ｋ１、ＫＲを所有する。なお、図３のツリーにはデバイスが０〜１５の１６個のみ記載され、ツリー構造も４段構成の均衡のとれた左右対称構成として示しているが、さらに多くのデバイスがツリー中に構成され、また、ツリーの各部において異なる段数構成を持つことが可能である。
【００４３】
また、図３のツリー構造に含まれる各デバイスには、様々な記録媒体、例えば、デバイス埋め込み型あるいはデバイスに着脱自在に構成されたフラッシュメモリ等を使用したメモリカード、ＤＶＤ、ＣＤ、ＭＤ等、様々なタイプの記憶装置を利用可能なデバイスが含まれている。さらに、様々なアプリケーションサービスが共存可能である。このような異なるデバイス、異なるアプリケーションの共存構成の上に図３に示すコンテンツあるいは鍵配布構成である階層ツリー構造が適用される。
【００４４】
これらの様々なデバイス、アプリケーションが共存するシステムにおいて、例えば図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を同一の記録媒体を用いる１つのグループとして設定する。例えば、この点線で囲んだグループ内に含まれるデバイスに対しては、まとめて、共通のコンテンツを暗号化してプロバイダから送付したり、各デバイス共通に使用するコンテンツキーを送付したり、あるいは各デバイスからプロバイダあるいは決済機関等にコンテンツ料金の支払データをやはり暗号化して出力するといった処理が実行される。コンテンツプロバイダ、あるいは決済処理機関等、各デバイスとのデータ送受信を行なう機関は、図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を１つのグループとして一括してデータを送付する処理を実行する。このようなグループは、図３のツリー中に複数存在する。コンテンツプロバイダ、あるいは決済処理機関等、各デバイスとのデータ送受信を行なう機関は、メッセージデータ配信手段として機能する。
【００４５】
なお、ノードキー、リーフキーは、ある１つの鍵管理センタによって統括して管理してもよいし、各グループに対する様々なデータ送受信を行なうプロバイダ、決済機関等のメッセージデータ配信手段によってグループごとに管理する構成としてもよい。これらのノードキー、リーフキーは例えばキーの漏洩等の場合に更新処理が実行され、この更新処理は鍵管理センタ、プロバイダ、決済機関等が実行する。
【００４６】
このツリー構造において、図３から明らかなように、１つのグループに含まれる３つのデバイス０，１，２，３はノードキーとして共通のキーＫ００、Ｋ０、ＫＲを保有する。このノードキー共有構成を利用することにより、例えば共通のコンテンツキーをデバイス０，１，２，３のみに提供することが可能となる。たとえば、共通に保有するノードキーＫ００自体をコンテンツキーとして設定すれば、新たな鍵送付を実行することなくデバイス０，１，２，３のみに共通のコンテンツキーの設定が可能である。また、新たなコンテンツキーＫｃｏｎをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を、ネットワークを介してあるいは記録媒体に格納してデバイス０，１，２，３に配布すれば、デバイス０，１，２，３のみが、それぞれのデバイスにおいて保有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を解いてコンテンツキー：Ｋｃｏｎを得ることが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであることを示す。
【００４７】
また、ある時点ｔにおいて、デバイス３の所有する鍵：Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,ＫＲが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキー：Ｋ００１,Ｋ００,Ｋ０,ＫＲをそれぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Generation）：ｔの更新キーであることを示す。
【００４８】
更新キーの配布処理ついて説明する。キーの更新は、例えば、図４（Ａ）に示す有効化キーブロック（ＥＫＢ：Enabling Key Block）と呼ばれるブロックデータによって構成されるテーブルをたとえばネットワーク、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図３に示すようなツリー構造を構成する各リーフに対応するデバイスに新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：Key Renewal Block）と呼ばれることもある。
【００４９】
図４（Ａ）に示す有効化キーブロック（ＥＫＢ）には、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図４の例は、図３に示すツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。図３から明らかなように、デバイス０，デバイス１は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒが必要である。
【００５０】
図４（Ａ）のＥＫＢに示されるようにＥＫＢには複数の暗号化キーが含まれる。最下段の暗号化キーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。これはデバイス２の持つリーフキーＫ００１０によって暗号化された更新ノードキーＫ（ｔ）００１であり、デバイス２は、自身の持つリーフキーによってこの暗号化キーを復号し、Ｋ（ｔ）００１を得ることができる。また、復号により得たＫ（ｔ）００１を用いて、図４（Ａ）の下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００１，Ｋ（ｔ）００）を復号可能となり、更新ノードキーＫ（ｔ）００を得ることができる。以下順次、図４（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。一方、デバイスＫ００００．Ｋ０００１は、ノードキーＫ０００は更新する対象に含まれておらず、更新ノードキーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ（ｔ）Ｒである。デバイスＫ００００．Ｋ０００１は、図４（Ａ）の上から３段目の暗号化キーＥｎｃ（Ｋ０００，Ｋ（ｔ）００）を復号しＫ（ｔ）００、を取得し、以下、図４（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。このようにして、デバイス０，１，２は更新した鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ（ｔ）Ｒを得ることができる。なお、図４（Ａ）のインデックスは、復号キーとして使用するノードキー、リーフキーの絶対番地を示す。
【００５１】
図３に示すツリー構造の上位段のノードキー：Ｋ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノードキーＫ００のみの更新処理が必要である場合には、図４（Ｂ）の有効化キーブロック（ＥＫＢ）を用いることで、更新ノードキーＫ（ｔ）００をデバイス０，１，２に配布することができる。
【００５２】
図４（Ｂ）に示すＥＫＢは、例えば特定のグループにおいて共有する新たなコンテンツキーを配布する場合に利用可能である。具体例として、図３に点線で示すグループ内のデバイス０，１，２，３がある記録媒体を用いており、新たな共通のコンテンツキーＫ（ｔ）ｃｏｎが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ００を更新したＫ（ｔ）００を用いて新たな共通の更新コンテンツキー：Ｋ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ），Ｋ（ｔ）ｃｏｎ）を図４（Ｂ）に示すＥＫＢとともに配布する。この配布により、デバイス４など、その他のグループの機器においては復号されないデータとしての配布が可能となる。
【００５３】
すなわち、デバイス０，１，２はＥＫＢを処理して得たＫ（ｔ）００を用いて上記暗号文を復号すれば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得ることが可能になる。
【００５４】
［ＥＫＢを使用したコンテンツキーの配布］
図５に、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る処理例として、Ｋ（ｔ）００を用いて新たな共通のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と図４（Ｂ）に示すＥＫＢとを記録媒体を介して受領したデバイス０の処理を示す。すなわちＥＫＢによる暗号化メッセージデータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。
【００５５】
図５に示すように、デバイス０は、記録媒体に格納されている世代：t時点のＥＫＢと自分があらかじめ格納しているノードキーＫ０００を用いて上述したと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００を生成する。さらに、復号した更新ノードキーＫ（ｔ）００を用いて更新コンテンツキーＫ（ｔ）ｃｏｎを復号して、後にそれを使用するために自分だけが持つリーフキーＫ００００で暗号化して格納する。
【００５６】
［ＥＫＢのフォーマット］
図６に有効化キーブロック（ＥＫＢ）のフォーマット例を示す。バージョン６０１は、有効化キーブロック（ＥＫＢ）のバージョンを示す識別子である。なお、バージョンは最新のＥＫＢを識別する機能とコンテンツとの対応関係を示す機能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ６０３は、有効化キーブロック（ＥＫＢ）中のデータ部の位置を示すポインタであり、タグポインタ６０４はタグ部の位置、署名ポインタ６０５は署名の位置を示すポインタである。
【００５７】
データ部６０６は、例えば更新するノードキーを暗号化したデータを格納する。例えば図５に示すような更新されたノードキーに関する各暗号化キー等を格納する。
【００５８】
タグ部６０７は、データ部に格納された暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを図７を用いて説明する。図７では、データとして先に図４（Ａ）で説明した有効化キーブロック（ＥＫＢ）を送付する例を示している。この時のデータは、図７の表（ｂ）に示すようになる。このときの暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。この場合は、ルートキーの更新キーＫ（ｔ）Ｒが含まれているので、トップノードアドレスはＫＲとなる。このとき、例えば最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図７の（ａ）に示す階層ツリーに示す位置にある。ここで、次のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）であり、ツリー上では前のデータの左下の位置にある。データがある場合は、タグが０、ない場合は１が設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）の左にはデータがあるので、Ｌタグ＝０、右にはデータがないので、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図７（ｃ）に示すデータ列、およびタグ列が構成される。
【００５９】
タグは、データＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）がツリー構造のどこに位置しているのかを示すために設定されるものである。データ部に格納されるキーデータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）．．．は、単純に暗号化されたキーの羅列データに過ぎないので、上述したタグによってデータとして格納された暗号化キーのツリー上の位置を判別可能としたものである。上述したタグを用いずに、先の図４で説明した構成のように暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）
００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）
０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（Ｔ）００）
．．．
のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とすると冗長なデータとなりデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、上述したタグをキー位置を示す索引データとして用いることにより、少ないデータ量でキー位置の判別が可能となる。
【００６０】
図６に戻って、ＥＫＢフォーマットについてさらに説明する。署名（Signature）は、有効化キーブロック（ＥＫＢ）を発行した例えば鍵管理センタ、コンテンツロバイダ、決済機関等が実行する電子署名である。ＥＫＢを受領したデバイスは署名検証によって正当な有効化キーブロック（ＥＫＢ）発行者が発行した有効化キーブロック（ＥＫＢ）であることを確認する。
【００６１】
［ＥＫＢを使用したコンテンツキーおよびコンテンツの配信］
上述の例では、コンテンツキーのみをＥＫＢとともに送付する例について説明したが、コンテンツキーで暗号化したコンテンツと、コンテンツキー暗号キーで暗号化したコンテンツキーと、ＥＫＢによって暗号化したコンテンツキー暗号キーを併せて送付する構成について以下説明する。
【００６２】
図８にこのデータ構成を示す。図８（ａ）に示す構成において、Ｅｎｃ（Ｋｃｏｎ，ｃｏｎｔｅｎｔ）８０１は、コンテンツ（Content）をコンテンツキー（Ｋｃｏｎ）で暗号化したデータであり、Ｅｎｃ（ＫＥＫ，Ｋｃｏｎ）８０２は、コンテンツキー（Ｋｃｏｎ）をコンテンツキー暗号キー（ＫＥＫ：Key Encryption Key）で暗号化したデータであり、Ｅｎｃ（ＥＫＢ，ＫＥＫ）８０３は、コンテンツキー暗号キーＫＥＫを有効化キーブロック（ＥＫＢ）によって暗号化したデータであることを示す。
【００６３】
ここで、コンテンツキー暗号キーＫＥＫは、図３で示すノードキー（Ｋ０００，Ｋ００…）、あるいはルートキー（ＫＲ）自体であってもよく、またノードキー（Ｋ０００，Ｋ００…）、あるいはルートキー（ＫＲ）によって暗号化されたキーであってもよい。
【００６４】
図８（ｂ）は、複数のコンテンツがメディアに記録され、それぞれが同じＥｎｃ（ＥＫＢ，ＫＥＫ）８０５を利用している場合の構成例を示す、このような構成においては、各データに同じＥｎｃ（ＥＫＢ，ＫＥＫ）を付加することなく、Ｅｎｃ（ＥＫＢ，ＫＥＫ）にリンクするリンク先を示すデータを各データに付加する構成とすることができる。
【００６５】
図９にコンテンツキー暗号キーＫＥＫを、図３に示すノードキーＫ００を更新した更新ノードキーＫ（ｔ）００として構成した場合の例を示す。この場合、図３の点線枠で囲んだグループにおいてデバイス３が、例えば鍵の漏洩によりリボーク（排除）されているとして、他のグループのメンバ、すなわち、デバイス０，１，２に対して図９に示す（ａ）有効化キーブロック（ＥＫＢ）と、（ｂ）コンテンツキー（Ｋｃｏｎ）をコンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）で暗号化したデータと、（ｃ）コンテンツ（content）をコンテンツキー（Ｋｃｏｎ）で暗号化したデータとを配信することにより、デバイス０，１，２はコンテンツを得ることができる。
【００６６】
図９の右側には、デバイス０における復号手順を示してある。デバイス０は、まず、受領した有効化キーブロックから自身の保有するリーフキーＫ０００を用いた復号処理により、コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を取得する。次に、Ｋ（ｔ）００による復号によりコンテンツキーＫｃｏｎを取得し、さらにコンテンツキーＫｃｏｎによりコンテンツの復号を行なう。これらの処理により、デバイス０はコンテンツを利用可能となる。デバイス１，２においても各々異なる処理手順でＥＫＢを処理することにより、コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を取得することが可能となり、同様にコンテンツを利用することが可能となる。
【００６７】
図３に示す他のグループのデバイス４，５，６…は、この同様のデータ（ＥＫＢ）を受信したとしても、自身の保有するリーフキー、ノードキーを用いてコンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を取得することができない。同様にリボークされたデバイス３においても、自身の保有するリーフキー、ノードキーでは、コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を取得することができず、正当な権利を有するデバイスのみがコンテンツを復号して利用することが可能となる。
【００６８】
このように、ＥＫＢを利用したコンテンツキーの配送を用いれば、データ量を少なくして、かつ安全に正当権利者のみが復号可能とした暗号化コンテンツを配信することが可能となる。
【００６９】
なお、有効化キーブロック（ＥＫＢ）、コンテンツキー、暗号化コンテンツ等は、ネットワークを介して安全に配信することが可能な構成であるが、有効化キーブロック（ＥＫＢ）、コンテンツキー、暗号化コンテンツをＤＶＤ、ＣＤ等の記録媒体に格納してユーザに提供することも可能である。この場合、記録媒体に格納された暗号化コンテンツの復号には、同一の記録媒体に格納された有効化キーブロック（ＥＫＢ）の復号により得られるコンテンツキーを使用するように構成すれば、予め正当権利者のみが保有するリーフキー、ノードキーによってのみ利用可能な暗号化コンテンツの配布処理、すなわち利用可能なユーザデバイスを限定したコンテンツ配布が簡易な構成で実現可能となる。
【００７０】
図１０に記録媒体に暗号化コンテンツとともに有効化キーブロック（ＥＫＢ）を格納した構成例を示す。図１０に示す例においては、記録媒体にコンテンツＣ１〜Ｃ４が格納され、さらに各格納コンテンツに対応するの有効化キーブロック（ＥＫＢ）を対応付けたデータが格納され、さらにバージョンＭの有効化キーブロック（ＥＫＢ＿Ｍ）が格納されている。例えばＥＫＢ＿１はコンテンツＣ１を暗号化したコンテンツキーＫｃｏｎ１を生成するのに使用され、例えばＥＫＢ＿２はコンテンツＣ２を暗号化したコンテンツキーＫｃｏｎ２を生成するのに使用される。この例では、バージョンＭの有効化キーブロック（ＥＫＢ＿Ｍ）が記録媒体に格納されており、コンテンツＣ３，Ｃ４は有効化キーブロック（ＥＫＢ＿Ｍ）に対応付けられているので、有効化キーブロック（ＥＫＢ＿Ｍ）の復号によりコンテンツＣ３，Ｃ４のコンテンツキーを取得することができる。ＥＫＢ＿１、ＥＫＢ＿２はディスクに格納されていないので、新たな提供手段、例えばネットワーク配信、あるいは記録媒体による配信によってそれぞれのコンテンツキーを復号するために必要なＥＫＢ＿１，ＥＫＢ＿２を取得することが必要となる。
【００７１】
［階層ツリー構造のカテゴリー分類］
暗号鍵をルートキー、ノードキー、リーフキー等、図３の階層ツリー構造として構成し、コンテンツキー、認証キー、ＩＣＶ生成キー、あるいはプログラムコード、データ等を有効化キーブロック（ＥＫＢ）とともに暗号化して配信する構成について説明してきたが、ノードキー等を定義している階層ツリー構造を各デバイスのカテゴリー毎に分類して効率的なキー更新処理、暗号化キー配信、データ配信を実行する構成について、以下説明する。
【００７２】
図１１に階層ツリー構造のカテゴリーの分類の一例を示す。図１１において、階層ツリー構造の最上段には、ルートキーＫｒｏｏｔ１１０１が設定され、以下の中間段にはノードキー１１０２が設定され、最下段には、リーフキー１１０３が設定される。各デバイスは個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーを保有する。
【００７３】
ここで、一例として最上段から第Ｍ段目のあるノードをカテゴリノード１１０４として設定する。すなわち第Ｍ段目のノードの各々を特定カテゴリのデバイス設定ノードとする。第Ｍ段の１つのノードを頂点として以下、Ｍ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとする。
【００７４】
例えば図１１の第Ｍ段目の１つのノード１１０５にはカテゴリ［メモリステッイク（商標）］が設定され、このノード以下に連なるノード、リーフはメモリステッイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフとして設定される。すなわち、ノード１１０５以下を、メモリスティックのカテゴリに定義されるデバイスの関連ノード、およびリーフの集合として定義する。
【００７５】
さらに、Ｍ段から数段分下位の段をサブカテゴリノード１１０６として設定することができる。例えば図に示すようにカテゴリ［メモリスティック］ノード１１０５の２段下のノードに、メモリスティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノードを設定する。さらに、サブカテゴリノードである再生専用器のノード１１０６以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード１１０７が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［ＰＨＳ］ノード１１０８と［携帯電話］ノード１１０９を設定することができる。
【００７６】
さらに、カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えばあるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、あるいは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。例えば１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器ＸＹＺ専用の頂点ノードとして設定すれば、メーカーの販売するゲーム機器ＸＹＺにその頂点ノード以下の下段のノードキー、リーフキーを格納して販売することが可能となり、その後、暗号化コンテンツの配信、あるいは各種キーの配信、更新処理を、その頂点ノードキー以下のノードキー、リーフキーによって構成される有効化キーブロック（ＥＫＢ）を生成して配信し、頂点ノード以下のデバイスに対してのみ利用可能なデータが配信可能となる。
【００７７】
このように、１つのノードを頂点としして、以下のノードをその頂点ノードに定義されたカテゴリ、あるいはサブカテゴリの関連ノードとして設定する構成とすることにより、カテゴリ段、あるいはサブカテゴリ段の１つの頂点ノードを管理するメーカー、コンテンツプロバイダ等がそのノードを頂点とする有効化キーブロック（ＥＫＢ）を独自に生成して、頂点ノード以下に属するデバイスに配信する構成が可能となり、頂点ノードに属さない他のカテゴリのノードに属するデバイスには全く影響を及ぼさずにキー更新を実行することができる。
【００７８】
［簡略ＥＫＢによるキー配信構成］
先に説明した例えば図３のツリー構成において、キー、例えばコンテンツキーを所定デバイス（リーフ）宛に送付する場合、キー配布先デバイスの所有しているリーフキー、ノードキーを用いて復号可能な有効化キーブロック（ＥＫＢ）を生成して提供する。例えば図１２（ａ）に示すツリー構成において、リーフを構成するデバイスａ，ｇ，ｊに対してキー、例えばコンテンツキーを送信する場合、ａ，ｇ，ｊの各ノードにおいて復号可能な有効化キーブロック（ＥＫＢ）を生成して配信する。
【００７９】
例えば更新ルートキーＫ（ｔ）ｒｏｏｔでコンテンツキーＫ（ｔ）ｃｏｎを暗号化処理し、ＥＫＢとともに配信する場合を考える。この場合、デバイスａ，ｇ，ｊは、それぞれが図１２（ｂ）に示すリーフおよびノードキーを用いて、ＥＫＢの処理を実行してＫ（ｔ）ｒｏｏｔを取得し、取得した更新ルートキーＫ（ｔ）ｒｏｏｔによってコンテンツキーＫ（ｔ）ｃｏｎの復号処理を実行してコンテンツキーを得る。
【００８０】
この場合に提供される有効化キーブロック（ＥＫＢ）の構成は、図１３に示すようになる。図１３に示す有効化キーブロック（ＥＫＢ）は、先の図６で説明した有効化キーブロック（ＥＫＢ）のフォーマットにしたがって構成されたものであり、データ（暗号化キー）と対応するタグとを持つ。タグは、先に図７を用いて説明したように左（Ｌ）、右（Ｒ）、それぞれの方向にデータがあれば０、無ければ１を示している。
【００８１】
有効化キーブロック（ＥＫＢ）を受領したデバイスは、有効化キーブロック（ＥＫＢ）の暗号化キーとタグに基づいて、順次暗号化キーの復号処理を実行して上位ノードの更新キーを取得していく。図１３に示すように、有効化キーブロック（ＥＫＢ）は、ルートからリーフまでの段数（デプス）が多いほど、そのデータ量は増加していく。段数（デプス）は、デバイス（リーフ）数に応じて増大するものであり、キーの配信先となるデバイス数が多い場合は、ＥＫＢのデータ量がさらに増大することになる。
【００８２】
このような有効化キーブロック（ＥＫＢ）のデータ量の削減を可能とした構成について説明する。図１４は、有効化キーブロック（ＥＫＢ）をキー配信デバイスに応じて簡略化して構成した例を示すものである。
【００８３】
図１３と同様、リーフを構成するデバイスａ，ｇ，ｊに対してキー、例えばコンテンツキーを送信する場合を想定する。図１４の（ａ）に示すように、キー配信デバイスによってのみ構成されるツリーを構築する。この場合、図１２（ｂ）に示す構成に基づいて新たなツリー構成として図１４（ｂ）のツリー構成が構築される。ＫｒｏｏｔからＫｊまでは全く分岐がなく１つの枝のみが存在すればよく、ＫｒｏｏｔからＫａおよびＫｇに至るためには、Ｋ０に分岐点を構成するのみで、２分岐構成の図１４（ａ）のツリーが構築される。
【００８４】
図１４（ａ）に示すように、ノードとしてＫ０のみを持つ簡略化したツリーが生成される。更新キー配信のための有効化キーブロック（ＥＫＢ）は、これらの簡略ツリーに基づいて生成する。図１４（ａ）に示すツリーは、有効化キーブロック（ＥＫＢ）を復号可能な末端ノードまたはリーフを最下段とした２分岐型ツリーを構成するパスを選択して不要ノードを省略することにより再構築される再構築階層ツリーである。更新キー配信のための有効化キーブロック（ＥＫＢ）は、この再構築階層ツリーのノードまたはリーフに対応するキーのみに基づいて構成される。
【００８５】
先の図１３で説明した有効化キーブロック（ＥＫＢ）は、各リーフａ，ｇ，ｊからＫｒｏｏｔに至るまでのすべてのキーを暗号化したデータを格納していたが、簡略化ＥＫＢは、簡略化したツリーを構成するノードについてのみの暗号化データを格納する。図１４（ｂ）に示すようにタグは３ビット構成を有する。第１および第２ビットは、図１３の例と、同様の意味を持ち、左（Ｌ）、右（Ｒ）、それぞれの方向にデータがあれば０、無ければ１を示す。第３番目のビットは、ＥＫＢ内に暗号化キーが格納されているか否かを示すためのビットであり、データが格納されている場合は１、データが無い場合は、０として設定される。
【００８６】
データ通信網、あるいは記憶媒体に格納されてデバイス（リーフ）に提供される有効化キーブロック（ＥＫＢ）は、図１４（ｂ）に示すように、図１３に示す構成に比較すると、データ量が大幅に削減されたものとなる。図１４に示す有効化キーブロック（ＥＫＢ）を受領した各デバイスは、タグの第３ビットに１が格納された部分のデータのみを順次復号することにより、所定の暗号化キーの復号を実現することができる。例えばデバイスａは、暗号化データＥｎｃ（Ｋａ，Ｋ（ｔ）０）をリーフキーＫａで復号して、ノードキーＫ（ｔ）０を取得して、ノードキーＫ（ｔ）０によって暗号化データＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）を復号してＫ（ｔ）ｒｏｏｔを取得する。デバイスｊは、暗号化データＥｎｃ（Ｋｊ，Ｋ（ｔ）ｒｏｏｔ）をリーフキーＫｊで復号して、Ｋ（ｔ）ｒｏｏｔを取得する。
【００８７】
このように、配信先のデバイスによってのみ構成される簡略化した新たなツリー構成を構築して、構築されたツリーを構成するリーフおよびノードのキーのみを用いて有効化キーブロック（ＥＫＢ）を生成することにより、少ないデータ量の有効化キーブロック（ＥＫＢ）を生成することが可能となり、有効化キーブロック（ＥＫＢ）のデータ配信が効率的に実行可能となる。
【００８８】
なお、簡略化した階層ツリー構成は、後段で説明するエンティテイ単位のＥＫＢ管理構成において特に有効に活用可能である。エンティテイは、キー配信構成としてのツリー構成を構成するノードあるいはリーフから選択した複数のノードあるいはリーフの集合体ブロックである。エンティテイは、デバイスの種類に応じて設定される集合であったり、あるいはデバイス提供メーカー、コンテンツプロバイダ、決済機関等の管理単位等、ある共通点を持った処理単位、管轄単位、あるいは提供サービス単位等、様々な態様の集合として設定される。１つのエンティテイには、ある共通のカテゴリに分類されるデバイスが集まっており、例えば複数のエンティテイの頂点ノード（サブルート）によって上述したと同様の簡略化したツリーを再構築してＥＫＢを生成することにより、選択されたエンティテイに属するデバイスにおいて復号可能な簡略化された有効化キーブロック（ＥＫＢ）の生成、配信が可能となる。エンティテイ単位の管理構成については後段で詳細に説明する。
【００８９】
なお、このような有効化キーブロック（ＥＫＢ）は、光ディスク、ＤＶＤ等の情報記録媒体に格納した構成とすることが可能である。例えば、上述の暗号化キーデータによって構成されるデータ部と、暗号化キーデータの階層ツリー構造における位置識別データとしてのタグ部とを含む有効化キーブロック（ＥＫＢ）にさらに、更新ノードキーによって暗号化したコンテンツ等のメッセージデータとを格納した情報記録媒体を各デバイスに提供する構成が可能である。デバイスは有効化キーブロック（ＥＫＢ）に含まれる暗号化キーデータをタグ部の識別データにしたがって順次抽出して復号し、コンテンツの復号に必要なキーを取得してコンテンツの利用を行なうことが可能となる。もちろん、有効化キーブロック（ＥＫＢ）をインターネット等のネットワークを介して配信する構成としてもよい。
【００９０】
［暗号処理機能を有する記憶装置とデータ処理装置間のデータ移動］
次に、上述した階層ツリー構成を適用した有効化キーブロック（ＥＫＢ）によって配信される暗号処理キーを適用した処理構成について、暗号処理機能を有する記憶装置、例えばメモリスティック（商標）等のメモリカードと、データ再生装置間におけるデータ移動処理を中心として説明する。
【００９１】
図１５は、相互にコンテンツデータの移動を実行可能な再生装置と暗号処理機能を有するメモリカード等の記憶装置の詳細構成を示したブロック図である。
【００９２】
図１５に示すように、記憶装置３００は、例えば、主制御モジュール３１、通信インターフェイス３２、制御モジュール３３、フラッシュメモリ３４およびフラッシュメモリ管理モジュール３５を有する。以下、各モジュールについて説明する。
【００９３】
〔制御モジュール３３〕
図１５に示すように、制御モジュール３３は、例えば、乱数発生ユニット５０、記憶ユニット５１、鍵生成／演算ユニット５２、相互認証ユニット５３、暗号化／復号ユニット５４および制御ユニット５５を有する。制御モジュール３３は、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール３３は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット５０は、乱数発生指示を受けると、６４ビット（８バイト）の乱数を発生する。
【００９４】
記憶ユニット５１は、例えば、ＥＥＰＲＯＭ(Electrically Erasable Programmable Read Only Memory) などの不揮発性メモリであり、認証処理に必要な鍵データなどの種々のデータを記憶している。図１６は、記憶ユニット５１に記憶されているデータを説明するための図である。図１６に示すように、記憶ユニット５１は、認証鍵データＩＫ0〜ＩＫ31、装置識別データＩＤmおよび記憶用鍵データＫｓｔｍを記憶している。
【００９５】
認証鍵データＩＫ0〜ＩＫ31は、記憶装置３００が再生装置２００との間で相互認証を行う際に用いられる鍵データであり、後述するように相互認証を行う度に認証鍵データＩＫ0〜ＩＫ31のうち一の認証鍵データがランダムに選択される。なお、認証鍵データＩＫ0〜ＩＫ31および記憶用鍵データＫｓｔｍは、記憶装置３００の外部から読めないようになっている。装置識別データＩＤmは、記憶装置３００に対してユニークに付けられた識別データであり、後述するように、記憶装置３００が再生装置２００との間で相互認証を行う際に読み出されて再生装置２００に出力される。記憶用鍵データＫｓｔｍは、後述するように、コンテンツの暗号化に用いられるコンテンツ鍵データＣＫを暗号化してフラッシュメモリ３４に記憶する際に用いられる。
【００９６】
鍵生成／演算ユニット５２は、例えば、ＩＳＯ／ＩＥＣ９７９７のＭＡＣ(Message Authentication Code) 演算などの種々の演算を行って鍵データを生成する。このとき、ＭＡＣ演算には、例えば、"Block cipher Algorithm"としてＦＩＰＳＰＵＢ４６−２に規定されるＤＥＳ(Data Encryption Standard)が用いられる。ＭＡＣ演算は、任意の長さのデータを固定の長さに圧縮する一方向性ハッシュ関数演算であり、関数値が秘密鍵に依存して定まる。
【００９７】
相互認証ユニット５３は、再生装置２００からオーディオデータを入力してフラッシュメモリ３４に書き込む動作を行うのに先立って、再生装置２００との間で相互認証処理を行う。また、相互認証ユニット５３は、フラッシュメモリ３４からオーディオデータを読み出して再生装置２００に出力する動作を行うのに先立って、再生装置２００との間で相互認証処理を行う。また、相互認証ユニット５３は、相互認証処理において、前述したＭＡＣ演算を行う。当該相互認証処理では、記憶ユニット５１に記憶されているデータが用いられる。
【００９８】
暗号化／復号ユニット５４は、ＤＥＳ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック暗号アルゴリズムでの暗号化を行う。使用するモードは、ＦＩＰＳ ＰＵＢ８１”ＤＥＳ ＭＯＤＥＳ ＯＦ ＯＰＥＲＡＴＩＯＮ”に規定されているようなＥＣＢ(Electronic Code Book)モードおよびＣＢＣ(Cipher Block Chaining) モードである。また、暗号化／復号ユニット５４は、ＤＥＳ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック復号アルゴリズムでの復号を行う。使用するモードは、上記ＥＣＢモードおよびＣＢＣモードである。当該ＥＣＢモードおよびＣＢＣモードのブロック暗号化／復号では、指定された鍵データを用いて指定されたデータを暗号化／復号する。制御ユニット５５は、乱数発生ユニット５０、記憶ユニット５１、鍵生成／演算ユニット５２、相互認証ユニット５３および暗号化／復号ユニット５４の処理を統括して制御する。
【００９９】
〔フラッシュメモリ３４〕
フラッシュメモリ３４は、例えば、３２Ｍバイトの記憶容量を有する。フラッシュメモリ３４には、相互認証ユニット５３による再生装置２００と記憶装置３００との間の相互認証処理によって双方が正当な装置であると認められたときに、再生装置２００から入力したオーディオデータあるいは画像データ等、各種データが書き込まれる。また、フラッシュメモリ３４からは、相互認証ユニット５３による再生装置２００と記憶装置３００との間の相互認証処理によって正当な相手であると認められたときに、オーディオデータ、画像データ等が読み出されて再生装置２００に出力される。
【０１００】
以下、フラッシュメモリ３４に記憶されるデータおよびそのフォーマットについて説明する。図１７は、フラッシュメモリ３４に記憶されるデータを説明するための図である。図１７に示すように、フラッシュメモリ３４には、例えば、再生管理ファイル、複数のトラックデータ（再生データ）ファイルが記憶されている。ここで、再生管理ファイルはトラックデータファイルの再生を管理する管理データを有し、トラックデータファイルはそれぞれ対応するトラックデータ（オーディオデータ）を有している。なお、本実施形態では、トラックデータは、例えば、１曲分のオーディオデータを意味する。以下、フラッシュメモリ３４に記憶されるデータをオーディオデータとした場合の例について説明する。
【０１０１】
図１８は、再生管理ファイルの構成を示し、図１９が一つ（１曲）のＡＴＲＡＣ３データファイルの構成を示す。再生管理ファイルは、１６ＫＢ固定長のファイルである。ＡＴＲＡＣ３データファイルは、曲単位でもって、先頭の属性ヘッダと、それに続く実際の暗号化された音楽データとからなる。属性ヘッダも１６ＫＢ固定長とされ、再生管理ファイルと類似した構成を有する。
【０１０２】
再生管理ファイルは、ヘッダ、１バイトコードのメモリカードの名前ＮＭ１−Ｓ、２バイトコードのメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブルＴＲＫＴＢＬ、メモリカード全体の付加情報ＩＮＦ−Ｓとからなる。データファイルの先頭の属性ヘッダは、ヘッダ、１バイトコードの曲名ＮＭ１、２バイトコードの曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前の属性、付加情報のサイズの情報等が含まれる。
【０１０３】
属性ヘッダに対してＡＴＲＡＣ３の音楽データが続く。音楽データは、１６ＫＢのブロック毎に区切られ、各ブロックの先頭にヘッダが付加されている。ヘッダには、暗号を復号するための初期値が含まれる。なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データファイル中の音楽データ等のコンテンツデータのみであって、それ以外の再生管理ファイル、ヘッダ等のデータは、暗号化されない。
【０１０４】
図２０は、再生管理ファイルＰＢＬＩＳＴの詳細なデータ構成を示す。再生管理ファイルＰＢＬＩＳＴは、１クラスタ（１ブロック＝１６ＫＢ）のサイズである。図２０Ａに示すヘッダは、３２バイトから成る。図２０Ｂに示すヘッダ以外の部分は、メモリカード全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名前ＮＭ２−Ｓ（５１２バイト）、暗号化されたコンテンツキー（ＣＯＮＴＥＮＴＳＫＥＹ）、ＭＡＣ、Ｓ−ＹＭＤｈｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ（８００バイト）、メモリカード全体に対する付加情報ＩＮＦ−Ｓ（１４７２０バイト）および最後にヘッダ中の情報の一部が再度記録されている。これらの異なる種類のデータ群のそれぞれの先頭は、再生管理ファイル内で所定の位置となるように規定されている。
【０１０５】
再生管理ファイルは、図２０Ａに示す（０ｘ００００）および（０ｘ００１０）で表される先頭から３２バイトがヘッダである。なお、ファイル中で先頭から１６バイト単位で区切られた単位をスロットと称する。ファイルの第１および第２のスロットに配されるヘッダには、下記の意味、機能、値を持つデータが先頭から順に配される。なお、Ｒｅｓｅｒｖｅｄと表記されているデータは、未定義のデータを表している。通常ヌル（０ｘ００）が書かれるが、何が書かれていてもＲｅｓｅｒｖｅｄのデータが無視される。将来のバージョンでは、変更がありうる。また、この部分への書き込みは禁止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。
【０１０６】
ＢＬＫＩＤ−ＴＬ０（４バイト）
意味：BLOCKID FILE ID
機能：再生管理ファイルの先頭であることを識別するための値
値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３０）
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
ＲＥＶＩＳＩＯＮ（４バイト）
意味：ＰＢＬＩＳＴの書き換え回数
機能：再生管理ファイルを書き換える度にインクリメント
値：０より始まり＋１づつ増加する
【０１０７】
ＳＮ１Ｃ＋Ｌ（２バイト）
意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前（１バイト）の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：文字コード（Ｃ）は上位１バイトで下記のように文字を区別する
00: 文字コードは設定しない。単なる２進数として扱うこと
01: ASCII(American Standard Code for Information Interchange)
02:ASCII+KANA 03:modifided8859-1
81:MS-JIS 82:KS C 5601-1989 83:GB(Great Britain)2312-80
90:S-JIS(Japanese Industrial Standards)(for Voice)。
【０１０８】
言語コード（Ｌ）は下位１バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する
00: 設定しない 08:German 09:English 0A:Spanish
0F:French 15:Italian 1D:Dutch
65:Korean 69:Japanese 75:Chinese
データが無い場合オールゼロとすること。
【０１０９】
ＳＮ２Ｃ＋Ｌ（２バイト）
意味：ＮＭ２−Ｓ領域に書かれるメモリカードの名前（２バイト）の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：上述したＳＮ１Ｃ＋Ｌと同一
ＳＩＮＦＳＩＺＥ（２バイト）
意味：ＩＮＦ−Ｓ領域に書かれるメモリカード全体に関する付加情報の全てを合計したサイズを表す
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値：サイズは０ｘ０００１から０ｘ３９Ｃ（９２４）
Ｔ−ＴＲＫ（２バイト）
意味：TOTAL TRACK NUMBER
機能：総トラック数
値：１から０ｘ０１９０（最大４００トラック）、データが無い場合はオールゼロとすること
ＶｅｒＮｏ（２バイト）
意味：フォーマットのバージョン番号
機能：上位がメジャーバージョン番号、下位がマイナーバージョン番号。著作権対応型か否か、すなわち前述の階層ツリー構成による有効化キーブロック（ＥＫＢ）による配信キーの使用対象か否かを示すデータとしても使用される。

【０１１０】
上述したヘッダに続く領域に書かれるデータ（図２０Ｂ）について以下に説明する。
【０１１１】
ＮＭ１−Ｓ
意味：メモリカード全体に関する１バイトの名前
機能：１バイトの文字コードで表した可変長の名前データ（最大で２５６）名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録すること
値：各種文字コード
ＮＭ２−Ｓ
意味：メモリカード全体に関する２バイトの名前
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録すること
値：各種文字コード。
【０１１２】
ＥＫＢ＿ｖｅｒｓｉｏｎ（４バイト）
意味：前述の階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供されるコンテンツキーの世代番号、および／または有効化キーブロック（ＥＫＢ）のファイル名を示す。
機能：階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供されるコンテンツキーを求めるための有効化キーブロック（ＥＫＢ）を示す。
値：０から０ｘＦＦまで
【０１１３】
Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）（８バイト）
意味：コンテンツ毎の暗号処理用のキーであルコンテンツキーをメモリカードのストレージキー（Ｋｓｔｍ）で暗号化したデータ。
機能：コンテンツの暗号処理に使用される
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
【０１１４】
Ｅ（ＫＥＫｎ，Ｋｃｏｎ）（８バイト）
意味：コンテンツ毎の暗号処理用のキーであるコンテンツキーを前述の階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供されるキー暗号化キーＫＥＫｎによって暗号化したデータ。
機能：コンテンツの暗号処理に使用される
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
【０１１５】
Ｃ＿ＭＡＣ［０］（８バイト）
意味：著作権情報改ざんチェック値
機能：再生管理ファイル内のデータ、最終コンテンツ記録等のコンテンツ処理日時を示すＳ−ＹＭＤｈｍｓ他のデータに基づいて生成される改竄チェック用の値。日時データＳ−ＹＭＤｈｍｓが改竄されていた場合には、Ｃ＿ＭＡＣ［０］のチェック時に改竄があったと判定され、コンテンツの再生が実行されない。
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで。
【０１１６】
ＭＧＲ
意味：コンテンツキーの種類
機能：０ｘ００で、コンテンツキーＫｃｏｎと、Ｅ（ＫＥＫｎ，Ｋｃｏｎ）の両方有り、０ｘ０１で、Ｅ（ＫＥＫｎ，Ｋｃｏｎ）のみ有り。
値：０から０ｘ０１まで
【０１１７】
Ｓ−ＹＭＤｈｍｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：信頼できる時計を持つ機器で記録した年・月・日・時・分・秒
機能：コンテンツの最終記録日時等、コンテンツ最終処理日時を識別するための値。コンテンツの処理時に更新される。

なお、Ｓ−ＹＭＤｈｍｓは、コンテンツ記録時等のコンテンツ処理時に更新され、更新されたデータに基づいて前述のＣ−ＭＡＣ［０］も更新されて格納される。
【０１１８】
ＴＲＫ−ｎｎｎ
意味：再生するＡＴＲＡＣ３データファイルのＳＱＮ（シーケンス）番号
機能：ＴＲＫＩＮＦの中のＦＮｏを記述する
値：１から４００（０ｘ１９０）
トラックが存在しない時はオールゼロとすること
ＩＮＦ−Ｓ
意味：メモリカード全体に関する付加情報データ（例えば写真、歌詞、解説等の情報）
機能：ヘッダを伴った可変長の付加情報データ
複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付けられている。個々のヘッダを含む付加情報データは最小１６バイト以上で４バイトの整数倍の単位で構成される。その詳細については、後述する
値：付加情報データ構成を参照
【０１１９】
再生管理ファイルの最後のスロットとして、ヘッダ内のものと同一のＢＬＫＩＤ−ＴＬ０と、ＭＣｏｄｅと、ＲＥＶＩＳＩＯＮとが書かれる。
【０１２０】
民生用オーディオ機器として、メモリカードが記録中に抜かれたり、電源が切れることがあり、復活した時にこれらの異常の発生を検出することが必要とされる。上述したように、ＲＥＶＩＳＩＯＮをブロックの先頭と末尾に書き込み、この値を書き換える度に＋１インクリメントするようにしている。若し、ブロックの途中で異常終了が発生すると、先頭と末尾のＲＥＶＩＳＩＯＮの値が一致せず、異常終了を検出することができる。ＲＥＶＩＳＩＯＮが２個存在するので、高い確率で異常終了を検出することができる。異常終了の検出時には、エラーメッセージの表示等の警告が発生する。
【０１２１】
また、１ブロック（１６ＫＢ）の先頭部分に固定値ＢＬＫＩＤ−ＴＬ０を挿入しているので、ＦＡＴが壊れた場合の修復の目安に固定値を使用できる。すなわち、各ブロックの先頭の固定値を見れば、ファイルの種類を判別することが可能である。しかも、この固定値ＢＬＫＩＤ−ＴＬ０は、ブロックのヘッダおよびブロックの終端部分に二重に記述するので、その信頼性のチェックを行うことができる。なお、再生管理ファイルＰＢＬＩＳＴの同一のものを二重に記録しても良い。
【０１２２】
ＡＴＲＡＣ３データファイルは、トラック情報管理ファイルと比較して、相当大きなデータ量であり、ＡＴＲＡＣ３データファイルに関しては、ブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬが付けられている。但し、ＡＴＲＡＣ３データファイルは、通常複数のファイルがメモリカード上に存在するので、ＣＯＮＮＵＭ０でコンテンツの区別を付けた上で、ＢＬＯＣＫ ＳＥＲＩＡＬを付けないと、重複が発生し、ＦＡＴが壊れた場合のファイルの復旧が困難となる。換言すると単一のＡＴＲＡＣ３データファイルは、複数のＢＬＯＣＫで構成されると共に、離散して配置される可能性があるので、同一ＡＴＲＡＣ３データファイルを構成するＢＬＯＣＫを判別するためにＣＯＮＮＵＭ０を用いると共に、同一ＡＴＲＡＣ３データファイル内の昇降順をブロック番号ＢＬＯＣＫ ＳＥＲＩＡＬで決定する。
【０１２３】
同様に、ＦＡＴの破壊までにはいたらないが、論理を間違ってファイルとして不都合のあるような場合に、書き込んだメーカーの機種が特定できるように、メーカーコード（ＭＣｏｄｅ）がブロックの先頭と末尾に記録されている。
【０１２４】
図２０Ｃは、付加情報データの構成を示す。付加情報の先頭に下記のヘッダが書かれる。ヘッダ以降に可変長のデータが書かれる。
【０１２５】
ＩＮＦ
意味：FIELD ID
機能：付加情報データの先頭を示す固定値
値：０ｘ６９
ＩＤ
意味：付加情報キーコード
機能：付加情報の分類を示す
値：０から０ｘＦＦ
ＳＩＺＥ
意味：個別の付加情報の大きさ
機能：データサイズは自由であるが、必ず４バイトの整数倍でなければならない。また、最小１６バイト以上のこと。データの終わりより余りがでる場合はヌル（０ｘ００）で埋めておくこと
値：１６から１４７８４（０ｘ３９Ｃ０）
ＭＣｏｄｅ
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
Ｃ＋Ｌ
意味：先頭から１２バイト目からのデータ領域に書かれる文字の属性を表す
機能：使用する文字コードと言語コードを各１バイトで表す
値：前述のＳＮＣ＋Ｌと同じ
ＤＡＴＡ
意味：個別の付加情報データ
機能：可変長データで表す。実データの先頭は常に１２バイト目より始まり、長さ（サイズ）は最小４バイト以上、常に４バイトの整数倍でなければならない。データの最後から余りがある場合はヌル（０ｘ００）で埋めること
値：内容により個別に定義される。
【０１２６】
図２１に、ＡＴＲＡＣ３データファイルＡ３Ｄｎｎｎｎのデータ配列例を示す。図２１には、データファイルの属性ヘッダ（１ブロック）と、音楽データファイル（１ブロック）とが示されている。図２１では、この２ブロック（１６×２＝３２Ｋバイト）の各スロットの先頭のバイト（０ｘ００００〜０ｘ７ＦＦ０）が示されている。図２２に分離して示すように、属性ヘッダの先頭から３２バイトがヘッダであり、２５６バイトが曲名領域ＮＭ１（２５６バイト）であり、５１２バイトが曲名領域ＮＭ２（５１２バイト）である。属性ヘッダのヘッダには、下記のデータが書かれる。
【０１２７】
ＢＬＫＩＤ−ＨＤ０（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データファイルの先頭であることを識別するための値
値：固定値＝”ＨＤ＝０”（例えば０ｘ４８４４２Ｄ３０）
【０１２８】
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
【０１２９】
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント
編集されても値を変化させない
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで。
【０１３０】
Ｎ１Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ１）の属性を表す
機能：ＮＭ１に使用される文字コードと言語コードを各１バイトで表す
値：ＳＮ１Ｃ＋Ｌと同一
【０１３１】
Ｎ２Ｃ＋Ｌ（２バイト）
意味：トラック（曲名）データ（ＮＭ２）の属性を表す
機能：ＮＭ２に使用される文字コードと言語コードを各１バイトで表す
値：ＳＮ１Ｃ＋Ｌと同一
【０１３２】
ＩＮＦＳＩＺＥ（２バイト）
意味：トラックに関する付加情報の全てを合計したサイズを表す
機能：データサイズを１６バイト単位の大きさで記述、無い場合は必ずオールゼロとすること
値：サイズは０ｘ００００から０ｘ３Ｃ６（９６６）
【０１３３】
Ｔ−ＰＲＴ（２バイト）
意味：トータルパーツ数
機能：トラックを構成するパーツ数を表す。通常は１
値：１から０ｘ２８５（６４５dec ）
【０１３４】
Ｔ−ＳＵ（４バイト）
意味：トータルＳＵ（サウンドユニット）数、ＳＵは、パーツの最小単位であり、且つＡＴＲＡＣ３でオーディオデータを圧縮する時の最小のデータ単位である。４４．１ｋHzのサンプリング周波数で得られた１０２４サンプル分（１０２４×１６ビット×２チャンネル）のオーディオデータを約１／１０に圧縮した数百バイトのデータがＳＵである。１ＳＵは、時間に換算して約２３ｍ秒になる。通常は、数千に及ぶＳＵによって１つのパーツが構成される。１クラスタが４２個のＳＵで構成される場合、１クラスタで約１秒の音を表すことができる。１つのトラックを構成するパーツの数は、付加情報サイズに影響される。パーツ数は、１ブロックの中からヘッダや曲名、付加情報データ等を除いた数で決まるために、付加情報が全く無い状態が最大数（６４５個）のパーツを使用できる条件となる。
機能：１トラック中の実際の総ＳＵ数を表す。曲の演奏時間に相当する
値：０ｘ０１から０ｘ００１ＦＦＦＦＦ
【０１３５】
ＩＮＸ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の相対場所
機能：曲のさびの部分（特徴的な部分）の先頭を示すポインタ。曲の先頭からの位置をＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する
値：０から０ｘＦＦＦＦ（最大、約６０８４秒）
【０１３６】
ＸＴ（２バイト）（Ｏｐｔｉｏｎ）
意味：INDEX の再生時間
機能：ＩＮＸ-nnnで指定された先頭から再生すべき時間のＳＵの個数を１／４した数で指定する。これは、通常のＳＵの４倍の長さの時間（約９３ｍ秒）に相当する
値：０ｘ００００：無設定 ０ｘ０１から０ｘＦＦＦＥ（最大６０８４秒）
０ｘＦＦＦＦ：曲の終わりまで。
【０１３７】
次に曲名領域ＮＭ１およびＮＭ２について説明する。
【０１３８】
ＮＭ１
意味：曲名を表す文字列
機能：１バイトの文字コードで表した可変長の曲名（最大で２５６）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ００２０）からヌル（０ｘ００）を１バイト以上記録すること
値：各種文字コード
【０１３９】
ＮＭ２
意味：曲名を表す文字列
機能：２バイトの文字コードで表した可変長の名前データ（最大で５１２）
名前データの終了は、必ず終端コード（０ｘ００）を書き込むこと
サイズはこの終端コードから計算すること、データの無い場合は少なくとも先頭（０ｘ０１２０）からヌル（０ｘ００）を２バイト以上記録すること
値：各種文字コード。
【０１４０】
属性ヘッダの固定位置（０ｘ３２０）から始まる、８０バイトのデータをトラック情報領域ＴＲＫＩＮＦと呼び、主としてセキュリティ関係、コピー制御関係の情報を一括して管理する。図２３にＴＲＫＩＮＦの部分を示す。ＴＲＫＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１４１】
ＥＫＩ（１バイト）
意味：前述の階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供される暗号化コンテンツキー：Ｅ（ＫＥＫｎ，Ｋｃｏｎ）を有するか否かを示す。
機能：ｂｉｔ７＝１でキー有、ｂｉｔ７＝０で無し。ｂｉｔ７＝０の場合は、ＥＫＢ＿ｖｅｒｓｉｏｎ、Ｅ（ＫＥＫｎ，Ｋｃｏｎ）は非参照。
値：０から０ｘＦＦまで
【０１４２】
ＥＫＢ＿ｖｅｒｓｉｏｎ（４バイト）
意味：前述の階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供されるコンテンツキーの世代番号、および／または有効化キーブロック（ＥＫＢ）のファイル名を示す。
機能：階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供されるコンテンツキーを求めるための有効化キーブロック（ＥＫＢ）を示す。
値：０から０ｘＦＦまで
【０１４３】
Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）（８バイト）
意味：コンテンツ毎の暗号処理用のキーであるコンテンツキーをメモリカードのストレージキー（Ｋｓｔｍ）で暗号化したデータ。
機能：コンテンツの暗号処理に使用される
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
【０１４４】
Ｅ（ＫＥＫｎ，Ｋｃｏｎ）（８バイト）
意味：コンテンツ毎の暗号処理用のキーであるコンテンツキーを前述の階層ツリー構成による有効化キーブロック（ＥＫＢ）によって提供されるキー暗号化キーＫＥＫｎによって暗号化したデータ。
機能：コンテンツの暗号処理に使用される
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦまで
【０１４５】
Ｃ＿ＭＡＣ［ｎ］（８バイト）
意味：著作権情報改ざんチェック値
機能：コンテンツ累積番号を含む複数のＴＲＫＩＮＦの内容と隠しシーケンス番号から作成される値。隠しシーケンス番号とは、メモリカードの隠し領域に記録されているシーケンス番号のことである。著作権対応でないレコーダは、隠し領域を読むことができない。また、著作権対応の専用のレコーダ、またはメモリカードを読むことを可能とするアプリケーションを搭載したパーソナルコンピュータは、隠し領域をアクセスすることができる。
【０１４６】
Ａ（１バイト）
意味：パーツの属性
機能：パーツ内の圧縮モード等の情報を示す
値：図２４を参照して以下に説明する
ただし、Ｎ＝０，１のモノラルは、ｂｉｔ７が１でサブ信号を０、メイン信号（Ｌ＋Ｒ）のみの特別なＪｏｉｎｔモードをモノラルとして規定する。ｂｉｔ２，１の情報は通常の再生機は無視しても構わない。
【０１４７】
Ａのビット０は、エンファシスのオン／オフの情報を形成し、ビット１は、再生ＳＫＩＰか、通常再生かの情報を形成し、ビット２は、データ区分、例えばオーディオデータか、ＦＡＸ等の他のデータかの情報を形成する。ビット３は、未定義である。ビット４、５、６を組み合わせることによって、図示のように、ＡＴＲＡＣ３のモード情報が規定される。すなわち、Ｎは、この３ビットで表されるモードの値であり、モノ（Ｎ＝０，１），ＬＰ（Ｎ＝２），ＳＰ（Ｎ＝４），ＥＸ（Ｎ＝５），ＨＱ（Ｎ＝７）の５種類のモードについて、記録時間（６４ＭＢのメモリカードの場合）、データ転送レート、１ブロック内のＳＵ数がそれぞれ示されている。１ＳＵのバイト数は、（モノ：１３６バイト、ＬＰ：１９２バイト、ＳＰ：３０４バイト、ＥＸ：３８４バイト、ＨＱ：５１２バイト）である。さらに、ビット７によって、ＡＴＲＡＣ３のモード（０：Dual １：Joint ）が示される。
【０１４８】
一例として、６４ＭＢのメモリカードを使用し、ＳＰモードの場合について説明する。６４ＭＢのメモリカードには、３９６８ブロックがある。ＳＰモードでは、１ＳＵが３０４バイトであるので、１ブロックに５３ＳＵが存在する。１ＳＵは、（１０２４／４４１００）秒に相当する。従って、１ブロックは、（１０２４／４４１００）×５３×（３９６８−１６）＝４８６３秒＝８１分
転送レートは、
（４４１００／１０２４）×３０４×８＝１０４７３７ bps
となる。
【０１４９】
ＬＴ（１バイト）
意味：再生制限フラグ（ビット７およびビット６）とセキュリティバージョン
（ビット５−ビット０）
機能：このトラックに関して制限事項があることを表す

ビット５−ビット０：セキュリティバージョン０（０以外であれば再生禁止とする）
【０１５０】
ＦＮｏ（２バイト）
意味：ファイル番号
機能：最初に記録された時のトラック番号、且つこの値は、メモリカード内の隠し領域に記録されたＭＡＣ計算用の値の位置を特定する
値：１から０ｘ１９０（４００）
【０１５１】
ＭＧ（Ｄ）ＳＥＲＩＡＬ−ｎｎｎ（１６バイト（ｕｐｐｅｒ：８，Ｌｏｗｅｒ：８））
意味：記録機器のセキュリティブロック（セキュリティＩＣ２０）のシリアル番号
機能：記録機器ごとに全て異なる固有の値
値：０から0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
【０１５２】
ＣＯＮＮＵＭ（４バイト）
意味：コンテンツ累積番号
機能：曲毎に累積されていく固有の値で記録機器のセキュリティブロックによって管理される。２の３２乗、４２億曲分用意されており、記録した曲の識別に使用する
値：０から０ｘＦＦＦＦＦＦＦＦ。
【０１５３】
ＹＭＤｈｍｓ−Ｓ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生開始日時
機能：ＥＭＤで指定する再生開始を許可する日時
値：上述した日時の表記と同じ
ＹＭＤｈｍｓ−Ｅ（４バイト）（Ｏｐｔｉｏｎ）
意味：再生制限付きのトラックの再生終了日時
機能：ＥＭＤで指定する再生許可を終了する日時
値：上述した日時の表記と同じ
【０１５４】
ＸＣＣ（１バイト）
意味：以下に説明するＣＣの拡張部
機能：コピー制御
【０１５５】
ＣＴ（１バイト）（Ｏｐｔｉｏｎ）
意味：再生回数
機能：再生許可された回数の内で、実際に再生できる回数。再生の度にデクリメントする
値：０ｘ００〜０ｘＦＦ 未使用の時は、０ｘ００である
ＬＴのｂｉｔ７が１でＣＴの値が００の場合は再生を禁止すること。
【０１５６】
ＣＣ（１バイト）
意味：COPY CONTROL
機能：コピー制御
値：図２５に示すように、ビット６および７によってコピー制御情報を表し、ビット４および５によって高速ディジタルコピーに関するコピー制御情報を表し、ビット２および３によってセキュリティブロック認証レベルを表す。ビット０および１は、未定義
ＣＣの例：（ｂｉｔ７，６）１１：無制限のコピーを許可、０１：コピー禁止、００：１回のコピーを許可（ｂｉｔ３，２）００：アナログないしディジタルインからの録音、ＭＧ認証レベルは０とする
ＣＤからのディジタル録音では（ｂｉｔ７，６）は００、（ｂｉｔ３，２）は００となる
【０１５７】
ＣＮ（１バイト）（Ｏｐｔｉｏｎ）
意味：高速ディジタルコピーＨＳＣＭＳ(High speed Serial Copy Management System)におけるコピー許可回数
機能：コピー１回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第１世代の場合にのみ有効であり、コピーごとに減算する
値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘＦＦ：回数無制限。
【０１５８】
上述したトラック情報領域ＴＲＫＩＮＦに続いて、０ｘ０３７０から始まる２４バイトのデータをパーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１つのトラックを複数のパーツで構成する場合に、時間軸の順番にＰＲＴＩＮＦを並べていく。図２６にＰＲＴＩＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１５９】
ＰＲＴＳＩＺＥ（４バイト）
意味：パーツサイズ
機能：パーツの大きさを表す。クラスタ：２バイト（最上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バイト（最下位）
値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，２，と０から開始する）
【０１６０】
ＰＲＴＫＥＹ（８バイト）
意味：パーツを暗号化するための値
機能：初期値＝０、編集時は編集の規則に従うこと
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
【０１６１】
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号キー
機能：コンテンツをユニークにするためのＩＤの役割
値：コンテンツ累積番号初期値キーと同じ値とされる。
【０１６２】
図２１に戻る。ＡＴＲＡＣ３データファイルの属性ヘッダ中には、図２１に示すように、付加情報ＩＮＦが含まれる。ＩＮＦは、トラックに関する付加情報データであり、ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小１６バイト以上で４バイトの整数倍の単位である。
【０１６３】
上述した属性ヘッダに対して、ＡＴＲＡＣ３データファイルの各ブロックのデータが続く。図２７に示すように、ブロック毎にヘッダが付加される。各ブロックのデータについて以下に説明する。
【０１６４】
ＢＬＫＩＤ−Ａ３Ｄ（４バイト）
意味：BLOCKID FILE ID
機能：ＡＴＲＡＣ３データの先頭であることを識別するための値
値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２０）
【０１６５】
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
【０１６６】
ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号
機能：コンテンツをユニークにするためのＩＤの役割、編集されても値は変化させない
値：コンテンツ累積番号初期値キーと同じ値とされる
【０１６７】
ＢＬＯＣＫ ＳＥＲＩＡＬ（４バイト）
意味：トラック毎に付けられた連続番号
機能：ブロックの先頭は０から始まり次のブロックは＋１づつインクリメント
編集されても値を変化させない
値：０より始まり０ｘＦＦＦＦＦＦＦＦまで
【０１６８】
ＢＬＯＣＫ−ＳＥＥＤ（８バイト）
意味：１ブロックを暗号化するための１つの鍵
機能：ブロックの先頭は、記録機器のセキュリティブロックで乱数を生成、続くブロックは、＋１インクリメントされた値、この値が失われると、１ブロックに相当する約１秒間、音が出せないために、ヘッダとブロック末尾に同じものが二重に書かれる。編集されても値を変化させない
値：初期は８バイトの乱数
【０１６９】
ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ ＶＥＣＴＯＲ（８バイト）
意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号化する時に必要な初期値
機能：ブロックの先頭は０から始まり、次のブロックは最後のＳＵの最後の暗号化された８バイトの値。デバイドされたブロックの途中からの場合は開始ＳＵの直前の最後の８バイトを用いる。編集されても値を変化させない
値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
【０１７０】
ＳＵ−ｎｎｎ
意味：サウンドユニットのデータ
機能：１０２４サンプルから圧縮されたデータ、圧縮モードにより出力されるバイト数が異なる。編集されても値を変化させない（一例として、ＳＰモードの時では、Ｎ＝３８４バイト）
値：ＡＴＲＡＣ３のデータ値。
【０１７１】
図２１では、Ｎ＝３８４であるので、１ブロックに４２ＳＵが書かれる。また、１ブロックの先頭の２つのスロット（４バイト）がヘッダとされ、最後の１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫ ＳＥＲＩＡＬが二重に書かれる。従って、１ブロックの余りの領域Ｍバイトは、（１６，３８４−３８４×４２−１６×３＝２０８（バイト）となる。
この中に上述したように、８バイトのＢＬＯＣＫ ＳＥＥＤが二重に記録される。
【０１７２】
ここで、フラッシュメモリ３４に記憶されているデータは、後述するように例えば、ＡＴＲＡＣ３方式で圧縮されている。圧縮の単位がサウンドユニットＳＵである。従って、記憶装置３００から再生装置２００にデータを読み出す場合には、読み出しの最小単位は当該サウンドユニットＳＵとなる。オーディオデータの圧縮方式は、ＡＴＲＡＣ３などのＡＴＲＡＣ方式以外のＣＯＤＥＣ方式でもよい。
【０１７３】
ブロックシードデータＢＳは、各ブロック毎に例えば乱数を発生して生成されたデータである。
【０１７４】
〔フラッシュメモリ管理モジュール３５〕
フラッシュメモリ管理モジュール３５は、フラッシュメモリ３４へのデータの書き込み、フラッシュメモリ３４からのデータの読み出しなどの制御を行う。
【０１７５】
図１５に示す再生装置２００の構成について説明する。再生装置２００は、例えば、主制御モジュール４１、通信インターフェイス４２、制御モジュール４３、編集モジュール４４、圧縮／伸長モジュール４５、スピーカ４６、Ｄ／Ａ変換器４７およびＡ／Ｄ変換器４８を有する。
【０１７６】
〔主制御モジュール４１〕
主制御モジュール４１は、再生装置２００の処理を統括的に制御する。
【０１７７】
〔制御モジュール４３〕
図１５に示すように、制御モジュール４３は、例えば、乱数発生ユニット６０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、相互認証ユニット６３、暗号化／復号ユニット６４および制御ユニット６５を有する。制御モジュール４３は、制御モジュール３３と同様に、シングルチップの暗号処理専用の集積回路であり、多層構造を有し、内部のメモリセルはアルミニウム層などのダミー層に挟まれている。また、制御モジュール４３は、動作電圧または動作周波数の幅が狭く、外部から不正にデータを読み出せないように耐タンパー性を有している。乱数発生ユニット６０は、乱数発生指示を受けると、６４ビット（８バイト）の乱数を発生する。記憶ユニット６１は、認証処理に必要な種々のデータを記憶している。
【０１７８】
鍵生成／鍵演算ユニット６２は、例えば、ＩＳＯ／ＩＥＣ９７９７のＭＡＣ演算方式を用いた演算などの種々の演算を行って鍵データを生成する。このとき、"Block cipher Algorithm"としてＦＩＰＳ ＰＵＢ ４６−２に規定されるＤＥＳが用いられる。
【０１７９】
相互認証ユニット６３は、例えば、コンピュータから入力したオーディオデータを記憶装置３００に出力する動作を行うのに先立って、記憶装置３００との間で相互認証処理を行う。また、相互認証ユニット６３は、記憶装置３００からオーディオデータを入力する動作を行うのに先立って、記憶装置３００との間で相互認証処理を行う。また、相互認証ユニット６３は、相互認証処理において、前述したＭＡＣ演算を行う。当該相互認証処理では、記憶ユニット６１に記憶されているデータが用いられる。なお、相互認証ユニット６３は、必要に応じて、例えば、パーソナルコンピュータ（ＰＣ）１００あるいはネットワーク上のコンピュータとの間でオーディオデータの入出力を行う動作に先立って、パーソナルコンピュータ（ＰＣ）１００あるいはネットワーク上のコンピュータとの間で相互認証処理を行う。
【０１８０】
暗号化／復号ユニット６４は、前述したように、ＦＩＰＳ ＰＵＢ ８１に規定されたＥＣＢモードおよびＣＢＣモードを選択的に用いてブロック暗号化を行う。
【０１８１】
暗号化／復号ユニット６４は、ＦＩＰＳ８１のモードのうち、ＥＣＢモードおよびＣＢＣモードの復号を選択的に行う。ここで、暗号化／復号ユニット６４は、ＣＢＣモードにおいて、例えば５６ビットの鍵データｋを用いて、暗号文を、６４ビットからなる暗号化ブロックを単位として復号して平文を生成する。
【０１８２】
制御ユニット６５は、乱数発生ユニット６０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、相互認証ユニット６３および暗号化／復号ユニット６４の処理を統括的に制御する。
【０１８３】
〔編集モジュール４４〕
編集モジュール４４は、例えば、図１６に示すように記憶装置３００のフラッシュメモリ３４内に記憶されたトラックデータファイルを、ユーザからの操作指示に基づいて編集して新たなトラックデータファイルを生成する。
【０１８４】
〔圧縮／伸長モジュール４５〕
圧縮／伸長モジュール４５は、例えば、記憶装置３００から入力した暗号化されたオーディオデータを復号した後に再生する際に、ＡＴＲＡＣ３方式で圧縮されているオーディオデータを伸長し、当該伸長したオーディオデータをＤ／Ａ変換器４７に出力する。また、例えば、ＣＤ、ＤＶＤあるいはＰＣ１から入力したオーディオデータを、記憶装置３００に記憶する際に、当該オーディオデータをＡＴＲＡＣ３方式で圧縮する。
【０１８５】
〔Ｄ／Ａ変換器４７〕
Ｄ／Ａ変換器４７は、圧縮／伸長モジュール４５から入力したデジタル形式のオーディオデータをアナログ形式のオーディオデータに変換してスピーカ４６に出力する。
【０１８６】
〔スピーカ４６〕
スピーカ４６は、Ｄ／Ａ変換器４７から入力したオーディオデータに応じた音響を出力する。
【０１８７】
〔Ａ／Ｄ変換器４８〕
Ａ／Ｄ変換器４８は、例えば、ＣＤプレーヤ７から入力したアナログ形式のオーディオデータをデジタル形式に変換して圧縮／伸長モジュール４５に出力する。
【０１８８】
〔メモリ４９〕
メモリ４９は、例えば、Ｅ２ＰＲＯＭ（ｅｘ．フラッシュメモリ）であり、前述したキー有効化ブロック（ＥＫＢ）、あるいはＥＫＢに基づいて生成されるデバイスキーブロック（ＤＫＢ）等の鍵データ、デバイス識別子としてのデバイスＩＤ等が格納される。
【０１８９】
［コンテンツデータの記憶装置に対する格納処理および再生処理］
図１５に示す再生装置２００と、記憶装置３００との間では、コンテンツデータの移動、すなわち、再生装置２００から記憶装置３００のフラッシュメモリ３４に対するデータ記録処理が実行され、さらに、記憶装置３００のフラッシュメモリ３４から再生装置２００に対するデータ再生処理が実行される。
【０１９０】
このデータ記録および再生処理について、以下説明する。まず、再生装置２００から記憶装置３００のフラッシュメモリ３４に対するデータ記録処理を図２８のフローを用いて説明する。
【０１９１】
再生装置および記憶装置は、データ移動に先立ち、まずステップＳ２７０１、Ｓ２７０２に示す相互認証処理を実行する。図２９に、共通鍵暗号方式を用いた相互認証方法（ISO/IEC 9798-2）を示す。図２９においては、共通鍵暗号方式としてＤＥＳを用いているが、共通鍵暗号方式であれば他の方式も可能である。図２９において、まず、Ｂが６４ビットの乱数Ｒｂを生成し、Ｒｂおよび自己のＩＤであるＩＤ（ｂ）をＡに送信する。これを受信したＡは、新たに６４ビットの乱数Ｒａを生成し、Ｒａ、Ｒｂ、ＩＤ（ｂ）の順に、ＤＥＳのＣＢＣモードで鍵Ｋａｂを用いてデータを暗号化し、Ｂに返送する。なお、鍵Ｋａｂは、ＡおよびＢに共通の秘密鍵としてそれぞれの記録素子内に格納する鍵である。ＤＥＳのＣＢＣモードを用いた鍵Ｋａｂによる暗号化処理は、例えばＤＥＳを用いた処理においては、初期値とＲａとを排他的論理和し、ＤＥＳ暗号化部において、鍵Ｋａｂを用いて暗号化し、暗号文Ｅ１を生成し、続けて暗号文Ｅ１とＲｂとを排他的論理和し、ＤＥＳ暗号化部において、鍵Ｋａｂを用いて暗号化し、暗号文Ｅ２を生成し、さらに、暗号文Ｅ２とＩＤ（ｂ）とを排他的論理和し、ＤＥＳ暗号化部において、鍵Ｋａｂを用いて暗号化して生成した暗号文Ｅ３とによって送信データ（Token-AB）を生成する。
【０１９２】
これを受信したＢは、受信データを、やはり共通の秘密鍵としてそれぞれの記録素子内に格納する鍵Ｋａｂ（認証キー）で復号化する。受信データの復号化方法は、まず、暗号文Ｅ１を認証キーＫａｂで復号化し、乱数Ｒａを得る。次に、暗号文Ｅ２を認証キーＫａｂで復号化し、その結果とＥ１を排他的論理和し、Ｒｂを得る。最後に、暗号文Ｅ３を認証キーＫａｂで復号化し、その結果とＥ２を排他的論理和し、ＩＤ(ｂ)を得る。こうして得られたＲａ、Ｒｂ、ＩＤ(ｂ)のうち、ＲｂおよびＩＤ(ｂ)が、Ｂが送信したものと一致するか検証する。この検証に通った場合、ＢはＡを正当なものとして認証する。
【０１９３】
次にＢは、認証後に使用するセッションキー（Ｋｓｅｓ）を生成する（生成方法は、乱数を用いる）。そして、Ｒｂ、Ｒａ、Ｋｓｅｓの順に、ＤＥＳのＣＢＣモードで認証キーＫａｂを用いて暗号化し、Ａに返送する。
【０１９４】
これを受信したＡは、受信データを認証キーＫａｂで復号化する。受信データの復号化方法は、Ｂの復号化処理と同様であるので、ここでは詳細を省略する。こうして得られたＲｂ、Ｒａ、Ｋｓｅｓの内、ＲｂおよびＲａが、Ａが送信したものと一致するか検証する。この検証に通った場合、ＡはＢを正当なものとして認証する。互いに相手を認証した後には、セッションキーＫｓｅｓは、認証後の秘密通信のための共通鍵として利用される。
【０１９５】
なお、受信データの検証の際に、不正、不一致が見つかった場合には、相互認証が失敗したものとして処理を終了（Ｓ２７０３でＮｏ）する。
【０１９６】
相互認証が成立（Ｓ２７０３でＹｅｓ）した場合は、ステップＳ２７０４において、再生装置がコンテンツキーＫｃｏｎの生成処理を実行する。この処理は、図１５の乱数生成ユニット６０で生成した乱数を用いて鍵生成／鍵演算ユニット６２において実行される。
【０１９７】
次に、ステップＳ２７０５において、（１）コンテンツキーＫｃｏｎを有効化キーブロック（ＥＫＢ）から取得される暗号化キーＫＥＫを用いて暗号化処理して、Ｅ（ＫＥＫ，Ｋｃｏｎ）を生成するとともに、（２）コンテンツキーＫｃｏｎを認証処理において生成したセッションキー（Ｋｓｅｓ）で暗号化処理を実行して、Ｅ（Ｋｓｅｓ，Ｋｃｏｎ）を生成して、記憶装置（メモリカード）に送信する。
【０１９８】
ステップＳ２７０６では、記憶装置が再生装置から受信したＥ（Ｋｓｅｓ，Ｋｃｏｎ）をセッションキーで復号してコンテンツキーＫｃｏｎを取得し、さらに、Ｋｃｏｎを記憶装置に予め格納されているストレージキーＫｓｔｍによって暗号化してＥ（Ｋｓｔｍ，Ｋｃｏｎ）を生成し、これを再生装置に送信する。
【０１９９】
次に、再生装置は、ステップＳ２７０７において、ステップＳ２７０５で生成したＥ（ＫＥＫ，Ｋｃｏｎ）、およびステップＳ２７０６で記憶装置から受信したＥ（Ｋｓｔｍ，Ｋｃｏｎ）を用いて、データファイル（図２１参照）を構成するトラック情報領域ＴＲＫＩＮＦデータを生成し、データファイルのフォーマット処理の後、これを記憶装置（メモリカード）に送信する。
【０２００】
ステップＳ２７０８において、記憶装置（メモリカード）は、再生装置から受信したデータファイルをフラッシュメモリに格納する。
【０２０１】
このような処理により、データファイルのトラック情報領域ＴＲＫＩＮＦデータには、先に説明した図２１、図２３に示すように、コンテンツキーＫｃｏｎを有効化キーブロック（ＥＫＢ）から取得される暗号化キーＫＥＫを用いて暗号化処理したＥ（ＫＥＫ，Ｋｃｏｎ）と、コンテンツキーＫｃｏｎを記憶装置に予め格納されているストレージキーＫｓｔｍによって暗号化したＥ（Ｋｓｔｍ，Ｋｃｏｎ）の２つの暗号化コンテンツキーが格納されることになる。
【０２０２】
なお、音楽データ、画像データ等の暗号化処理は、コンテンツキーＫｃｏｎをそのままコンテンツの暗号化鍵として適用して実行するか、あるいはコンテンツを構成するパーツ、またはブロック等を単位として、コンテンツキーと他のキー生成データに基づいて各パーツ単位、またはブロック単位の暗号化鍵を個別に生成して各パーツ単位、またはブロック単位の暗号化処理を行なう構成とすることが可能である。
【０２０３】
このようなデータファイルを用いた再生処理においては、再生装置は、Ｅ（ＫＥＫ，Ｋｃｏｎ）と、Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）のいずれかを選択的に適用してコンテンツキーＫｃｏｎを取得可能となる。
【０２０４】
次に、再生装置２００が記憶装置３００のフラッシュメモリ３４に格納されたデータの読み出し処理、すなわち再生処理を実行する場合の処理を図３０のフローを用いて説明する。
【０２０５】
再生装置および記憶装置は、データ移動に先立ち、まずステップＳ２９０１、Ｓ２９０２に示す相互認証処理を実行する。この処理は、先に説明した図２９の処理と同様である。相互認証が失敗した場合（Ｓ２９０３でＮｏ）は、処理を終了する。
【０２０６】
相互認証が成立（Ｓ２９０３でＹｅｓ）した場合は、ステップＳ２９０４において、記憶装置が再生装置に対してデータファイルを送信する。データファイルを受信した再生装置は、データファイル中のトラック情報領域ＴＲＫＩＮＦデータを検査し、コンテンツキー（Ｋｃｏｎ）の格納状況を判別する。この判別処理は、キー有効化ブロック（ＥＫＢ）によって取得される暗号化キーＫＥＫによって暗号化されたコンテンツキー、すなわちＥ（ＫＥＫ．Ｋｃｏｎ）が格納されているか否かを判別する処理である。Ｅ（ＫＥＫ．Ｋｃｏｎ）の有無は、先の図２１，２３で説明したデータファイル中のトラック情報領域ＴＲＫＩＮＦデータの［ＥＫＩ］のデータにより判別可能である。
【０２０７】
Ｅ（ＫＥＫ．Ｋｃｏｎ）が格納されている場合（ステップＳ２９０６でＹｅｓ）は、ステップＳ２９０７に進み、キー有効化ブロック（ＥＫＢ）の処理により、暗号化キーＫＥＫを取得して、取得した暗号化キーＫＥＫにより、Ｅ（ＫＥＫ．Ｋｃｏｎ）を復号して、コンテンツキーＫｃｏｎを取得する。
【０２０８】
Ｅ（ＫＥＫ．Ｋｃｏｎ）が格納されていない場合（ステップＳ２９０６でＮｏ）は、ステップＳ２９０８において、記憶装置の制御モジュール３３において、記憶装置に予め格納されているストレージキーＫｓｔｍによって暗号化したＥ（Ｋｓｔｍ，Ｋｃｏｎ）をストレージキーＫｓｔｍによって復号して、さらに、相互認証処理において再生装置および記憶装置で共有したセッションキーＫｓｅｓで暗号化したデータＥ（Ｋｓｅｓ，Ｋｃｏｎ）を生成して、再生装置に送信する。
【０２０９】
再生装置は、ステップＳ２９０９において、記憶装置から受信したＥ（Ｋｓｅｓ，Ｋｃｏｎ）をセッションキーＫｓｅｓで復号してコンテンツキーＫｃｏｎを取得する。
【０２１０】
ステップＳ２９１０では、ステップＳ２９０７、またはステップＳ２９０９のいずれかにおいて取得したコンテンツキーＫｃｏｎにより暗号化コンテンツの復号を行なう。
【０２１１】
このように、暗号化コンテンツの再生処理において、再生装置は、Ｅ（ＫＥＫ，Ｋｃｏｎ）を有効化キーブロック（ＥＫＢ）から取得される暗号化キーＫＥＫを用いて復号するか、または、記憶装置に予め格納されているストレージキーＫｓｔｍによって暗号化したＥ（Ｋｓｔｍ，Ｋｃｏｎ）に基づく処理を実行するか、いずれかの処理を実行することによりコンテンツキーＫｃｏｎを取得することができる。
【０２１２】
なお、音楽データ、画像データ等の復号処理は、コンテンツキーＫｃｏｎをそのままコンテンツの復号鍵として適用して実行するか、あるいはコンテンツを構成するパーツ、またはブロック等を単位として、コンテンツキーと他のキー生成データに基づいて各パーツ単位、またはブロック単位の復号鍵を個別に生成して各パーツ単位、またはブロック単位の復号処理を行なう構成とすることが可能である。
【０２１３】
［ＫＥＫを格納したＥＫＢのフォーマット］
先に図６を用いて有効化キーブロック（ＥＫＢ）の概略的なフォーマットについて説明したが、さらに、キー暗号化キー（ＫＥＫ）を有効化キーブロック（ＥＫＢ）に格納して保持する場合の具体的なデータ構成例について説明する。
【０２１４】
図３１にキー暗号化キー（ＫＥＫ）を有効化キーブロック（ＥＫＢ）に格納したデータであるＥＫＢである配信鍵許可情報ファイルの構成例を示す。デバイス（再生装置）は、このファイルから必要に応じてキー暗号化キー（ＫＥＫ）を取り出して、ＫＥＫによりＥ（ＫＥＫ，Ｋｃｏｎ）を復号してコンテンツキー：Ｋｃｏｎを取得してコンテンツの復号を実行する。各データについて説明する。
【０２１５】
ＢＬＫＩＤ−ＥＫＢ（４バイト）
意味：BLOCKID FILE ID
機能：配信鍵情報ファイルの先頭であることを識別するための値
値：固定値＝”ＥＫＢ”（例えば０ｘ４５４Ｂ４２２０）
【０２１６】
ＭＣｏｄｅ（２バイト）
意味：MAKER CODE
機能：記録した機器の、メーカー、モデルを識別するコード
値：上位１０ビット（メーカーコード） 下位６ビット（機種コード）
【０２１７】
ＬＫＦ
意味：LINK FILE INFORMATION
機能：このＥＫＢによって取得されるＫＥＫが適用可能なコンテンツデータであるリンクファイルを識別する。
値：０〜０ｘＦＦ
ｂｉｔ７：再生管理ファイル（ＰＢＬＩＳＴ）に使用：１、未使用：０
ｂｉｔ６：改竄チェック値（ＩＣＶ）に使用：１、未使用：０
ｂｉｔ５〜０：リザーブ
【０２１８】
ＬＩＮＫ ｃｏｕｎｔ
意味：LINK COUNT
機能：リンクしているファイル（例えばＡＴＲＡＣＫ３ファイル）数
値：０〜０ｘＦＦＦＦＦＦＦＦ
【０２１９】
Ｖｅｒｓｉｏｎ
意味：VERSION
機能：配信鍵許可情報ファイルのバージョンを示す。
値：０〜０ｘＦＦＦＦＦＦＦＦ
【０２２０】
ＥＡ
意味：Encryption Algorithm
機能：配信鍵許可情報ファイルのトレース処理アルゴリズムを示す。
値：０〜０ｘＦＦ
００ｈ：３ＤＥＳ：トリプルＤＥＳモードによる処理
０１ｈ：ＤＥＳ ：シングルＤＥＳモードによる処理
なお、トリプルＤＥＳモードによる処理は、２種類以上の暗号処理キーを用いる暗号処理であり、シングルＤＥＳモードは１つのキーによる処理である。
【０２２１】
ＫＥＫ１
意味：Key Encrypting Key
機能：キー有効化ブロック（ＥＫＢ）中のルートキー（最上位）キーで暗号化されたコンテンツキー暗号キー
値：０〜０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
【０２２２】
ＫＥＫ２
意味：Key Encrypting Key
機能：キー有効化ブロック（ＥＫＢ）中のルートキー（最上位）キーで暗号化されたコンテンツキー暗号キー
値：０〜０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
【０２２３】
Ｅ（Ｖｅｒｓｉｏｎ）
意味：Encrypted Version
機能：キー有効化ブロック（ＥＫＢ）中のルートキー（最上位）キーで暗号化されたバージョン番号。復号時の下４バイトはリザーブ
値：０〜０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
【０２２４】
Ｓｉｚｅ ｏｆ ｔａｇ ｐａｒｔ
意味：Size of tag part
機能：配信鍵許可情報ファイルを構成するデータのタグ部分のサイズ（Ｂｙｔｅ）
値：０〜０ｘＦＦＦＦＦＦＦＦ
【０２２５】
Ｓｉｚｅ ｏｆ Ｋｅｙ ｐａｒｔ
意味：Size of key part
機能：配信鍵許可情報ファイルを構成するデータのキー部分のサイズ（Ｂｙｔｅ）
値：０〜０ｘＦＦＦＦＦＦＦＦ
【０２２６】
Ｓｉｚｅ ｏｆ Ｓｉｇｎ ｐａｒｔ
意味：Size of sign part
機能：配信鍵許可情報ファイルを構成するデータのサイン部分のサイズ（Ｂｙｔｅ）
値：０〜０ｘＦＦＦＦＦＦＦＦ
【０２２７】
Ｔａｇ ｐａｒｔ
意味：Tag part
機能：配信鍵許可情報ファイルを構成するデータのタグ部分のデータ
値：すべての値
８バイトに満たない場合は０で埋めて８バイトにする。
【０２２８】
Ｋｅｙ ｐａｒｔ
意味：Key part
機能：配信鍵許可情報ファイルを構成するデータのキー部分のデータ
値：すべての値
【０２２９】
Ｓｉｇｎａｔｕｒｅ ｐａｒｔ
意味：Signature part
機能：配信鍵許可情報ファイルを構成するデータの署名（Ｓｉｇｎａｔｕｒｅ）部分のデータ
値：すべての値
【０２３０】
上述の説明および図３１によって示されるように、デバイスに対して提供される配信鍵許可情報ファイルには、その配信鍵許可情報ファイルから取得されるＫＥＫが適用可能なコンテンツデータであるリンクファイルを識別するための識別データ［ＬＫＦ］が格納され、さらに、リンクしているファイル（例えばＡＴＲＡＣＫ３ファイル）数としてのデータ［Ｌｉｎｃ Ｃｏｕｎｔ］が格納される。再生装置は、［ＬＫＦ］、［Ｌｉｎｋ Ｃｏｕｎｔ］を参照することにより、その配信鍵許可情報ファイルから取得されるＫＥＫを適用すべきデータが存在するか否かおよびその数を知ることが可能となる。
【０２３１】
［リンク情報を用いたデータ復号、再生処理］
上述した配信鍵許可情報ファイルに含まれるリンクファイルを識別するための識別データ［ＬＫＦ］、リンクしているファイル（例えばＡＴＲＡＣＫ３ファイル）数としてのデータ［Ｌｉｎｃ Ｃｏｕｎｔ］を用いて、効率的にデータの復号、再生を実行する処理態様について、以下説明する。
【０２３２】
図３２に記憶装置のデータ格納領域、例えば図１５に示す記憶装置３００のフラッシュメモリ３４に格納されたデータファイル構成例を示す。ここでは、音楽データ（ＨＩＦＩ）のディレクトリ構成のみを例として示しているが、さらに、画像ファイル等のディレクトリが存在してもよい。
【０２３３】
図３２に示す音楽データのディレクトリには、再生管理ファイル（ＰＢＬＩＳＴ）、暗号化コンテンツとして複数のＡＴＲＡＣＫ３データファイル（Ａ３Ｄ）含まれる。さらに、記憶装置には、複数の有効化キーブロックファイル（ＥＫＢｎ）が格納される。ＡＴＲＡＣＫ３データファイル（Ａ３Ｄ）の復号処理に適用するコンテンツキーを取得するための有効化キーブロックファイル（ＥＫＢｎ）は、ＡＴＲＡＣＫ３データファイル（Ａ３Ｄ）に含まれるポインタによって判別される。図３２に示すように、１つの有効化キーブロックファイル（ＥＫＢ１）３１０１は複数（３）のＡＴＲＡＣＫ３データファイル（Ａ３Ｄ）の復号処理に適用される。
【０２３４】
この場合、有効化キーブロックファイル（ＥＫＢ１）３１０１に対応する配信鍵許可情報ファイルの［Ｌｉｎｃ Ｃｏｕｎｔ］には３つのコンテンツに適用されることを示すデータが格納されることになる。
【０２３５】
図３２のような複数のコンテンツファイル、複数の有効化キーブロックファイルを格納した記憶装置であるメモリカードからコンテンツを復号して、再生する場合の処理フローを図３３に示す。
【０２３６】
図３３の処理は、例えば記憶装置としてのメモリカードを再生装置にセットした際、あるいはメモリカードを装着した再生装置の電源をＯＮした際に再生装置が実行する処理である。
【０２３７】
まず、ステップＳ３２０１において、再生装置は、各々のＥＫＢファイルのトラック情報を読み取り、［Ｌｉｎｃ Ｃｏｕｎｔ］をチェックする。さらに、［Ｌｉｎｃ Ｃｏｕｎｔ］のカウント数が多いものから順に、予め定められた個数［ｎ］のＥＫＢファイルを選択する。個数［ｎ］は、再生装置の所定メモリ領域、すなわちキー暗号化キー：ＫＥＫを格納保持する領域に格納可能な個数に相当する個数として設定される。
【０２３８】
次に、ステップＳ３２０２において、選択したＥＫＢの処理により、複数［ｎ］のキー暗号化キー：ＫＥＫを取得し、これらを再生装置の鍵格納領域として設定されたＲＡＭの所定領域に格納する。
【０２３９】
次に、再生装置は、ステップＳ３２０３において、復号、再生するコンテンツを選択する。さらに、ステップＳ３２０４において、その選択コンテンツの復号に適用するＫＥＫがＲＡＭに格納されているか否かを判定し、Ｙｅｓの場合は、ステップＳ３２０５に進み、その対応ＫＥＫに基づいて、Ｅ（ＫＥＫ，Ｋｃｏｎ）を復号してコンテンツキーを取得して、ステップＳ３２０９で再生、すなわち、取得したコンテンツキーによるデータの復号、再生処理を実行する。
【０２４０】
ステップＳ３２０４において、選択コンテンツの復号に適用するＫＥＫがＲＡＭに格納されていない場合は、ステップＳ３２０６において、ストレージキーで暗号化されたコンテンツキー、すなわち、Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）の有無を判定し、ある場合は、ステップＳ３２０７において、Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）の復号処理によりコンテンツキーを取得して、ステップＳ３２０９で再生、すなわち、取得したコンテンツキーによるデータの復号、再生処理を実行する。
【０２４１】
また、ステップＳ３２０６において、Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）がないと判定されると、その復号対象コンテンツに適用すべきＥＫＢを記憶装置から取得して、取得したＥＫＢの復号処理によりＫＥＫを取得し、取得したＫＥＫによるＥ（ＫＥＫ，Ｋｃｏｎ）の復号処理を実行してコンテンツキーを取得して、ステップＳ３２０９で再生、すなわち、取得したコンテンツキーによるデータの復号、再生処理を実行する。
【０２４２】
このように、再生装置は、予め記憶装置に格納した複数のキー有効化ブロック（ＥＫＢ）の［Ｌｉｎｃ Ｃｏｕｎｔ］をチェックし、［Ｌｉｎｃ Ｃｏｕｎｔ］のカウント数が多いＥＫＢの復号を実行して、キー暗号化キー：ＫＥＫを格納しておく構成とすることにより、コンテンツ再生処理の際に、高い確率でＲＡＭに格納したＫＥＫを適用可能となり、効率的なコンテンツ再生が実行できる。
【０２４３】
［キー有効化ブロック（ＥＫＢ）による認証キー配信］
上述の有効化キーブロック（ＥＫＢ）を使用したキーの配信において、認証処理を実行する際に使用する認証キーＩＫｎを配信することにより、安全な秘密鍵として共有する認証キーを提供し、共通鍵方式に従った認証処理を実行する構成について説明する。
【０２４４】
共通鍵暗号方式を用いた相互認証方法（ISO/IEC 9798-2）は、先に図２９を用いて説明した処理であり、データ送受信が実行される前の処理として、双方の正当性を確認するための処理として実行される。認証処理においては、データの送受信を行なう、例えば再生装置と記憶装置は認証キーＫａｂを共有する。この共通鍵Ｋａｂを上述の有効化キーブロック（ＥＫＢ）を使用して再生装置に配信する。
【０２４５】
図３４および図３５に複数のデバイスに共通の認証キーＩＫｎを有効化キーブロック（ＥＫＢ）によって配信する構成例を示す。図３４はデバイス０，１，２，３に対して復号可能な認証キーＩＫｎを配信する例、図３５はデバイス０，１，２，３中のデバイス３をリボーク（排除）してデバイス０，１，２に対してのみ復号可能な認証キーを配信する例を示す。
【０２４６】
図３４の例では、更新ノードキーＫ（ｔ）００によって、認証キーＩＫｎを暗号化したデータ（ｂ）とともに、デバイス０，１，２，３においてそれぞれの有するノードキー、リーフキーを用いて更新されたノードキーＫ（ｔ）００を復号可能な有効化キーブロック（ＥＫＢ）を生成して配信する。それぞれのデバイスは、図３４の右側に示すようにまず、ＥＫＢを処理（復号）することにより、更新されたノードキーＫ（ｔ）００を取得し、次に、取得したノードキーＫ（ｔ）００を用いて暗号化された認証キー：Ｅｎｃ（Ｋ（ｔ）００，ＩＫｎ）を復号して認証キーＩＫｎを得ることが可能となる。
【０２４７】
その他のデバイス４，５，６，７…は同一の有効化キーブロック（ＥＫＢ）を受信しても自身の保有するノードキー、リーフキーでは、ＥＫＢを処理して更新されたノードキーＫ（ｔ）００を取得することができないので、安全に正当なデバイスに対してのみ認証キーを送付することができる。
【０２４８】
一方、図３５の例は、デバイス３が、例えば鍵の漏洩によりリボーク（排除）されているとして、他のグループのメンバ、すなわち、デバイス０，１，２，に対してのみ復号可能な有効化キーブロック（ＥＫＢ）を生成して配信した例である。図３５に示す（ａ）有効化キーブロック（ＥＫＢ）と、（ｂ）認証キー（ＩＫｎ）をノードキー（Ｋ（ｔ）００）で暗号化したデータを配信する。
【０２４９】
図３５の右側には、復号手順を示してある。デバイス０，１，２は、まず、受領した有効化キーブロックから自身の保有するリーフキーまたはノードキーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）００）を取得する。次に、Ｋ（ｔ）００による復号により認証キーＩＫｎを取得する。
【０２５０】
他のグループのデバイス、例えばデバイス４，５，６…は、この同様のデータ（ＥＫＢ）を受信したとしても、自身の保有するリーフキー、ノードキーを用いて更新ノードキー（Ｋ（ｔ）００）を取得することができない。同様にリボークされたデバイス３においても、自身の保有するリーフキー、ノードキーでは、更新ノードキー（Ｋ（ｔ）００）を取得することができず、正当な権利を有するデバイスのみが認証キーを復号して利用することが可能となる。
【０２５１】
このように、ＥＫＢを利用した認証キーの配送を用いれば、データ量を少なくして、かつ安全に正当権利者のみが復号可能とした認証キーを配信することが可能となる。また、有効化キーブロック（ＥＫＢ）によって暗号化され提供されるＥＫＢ配信認証鍵は、世代（バージョン）管理がなされ、世代毎の更新処理が実行され、任意のタイミングでのデバイスのリボーク（排除）が可能である。
【０２５２】
上述したＥＫＢによる認証キーの提供処理により、リボークされたデバイス（再生装置）では、記憶装置（例えばメモリカード）との認証処理が成立せず、データの不正な復号が不可能となる。
【０２５３】
さらに、ＥＫＢを利用した認証キーの配送を用いれば、メモリカード以外の記憶媒体、例えば再生装置に内蔵したハードディスク等の記憶媒体に対するデータ格納、再生処理に対する制御も可能となる。
【０２５４】
先の図２８〜３０を用いて説明したように、記憶装置を利用したコンテンツの記録、再生処理においては、相互認証処理が実行され、相互認証処理の成立を条件として、データの記録および再生が可能となる。この認証処理プログラムは、メモリカードのような相互認証処理が可能な記憶装置との間での処理においては有効に作用するが、例えば、再生装置がハードディスク、ＣＤ−Ｒ等、暗号処理機能を持たない、すなわち相互認証を実行不可能な記憶媒体に対してデータ格納、データ再生時には意味をなさないことになる。シカシ、本発明のシステムでは、このような認証不可能な機器を利用したデータ格納、あるいはデータ再生処理においても認証処理プログラムを実行させる構成とする。ハードディスク、ＣＤ−Ｒ等は相互認証が不可能であるので、仮想のメモリカード（メモリスティック）を再生装置に構成し、仮想メモリカードと再生装置間において認証処理を実行させて、認証成立を条件として、認証機能を持たない記憶媒体に対するデータ格納処理、あるいは記憶媒体からのデータ再生を可能とする。
【０２５５】
これらの仮想メモリカードを使用したデータ記録、再生処理フローを図３６に示す。まず、再生装置は、再生装置内の仮想メモリカードとの間で相互認証処理を実行する。ステップＳ３５０２において、認証成立したか否かを判定し、成立したことを条件としてステップＳ３５０３に進み、認証機能を持たない記憶媒体、例えばハードディスク、ＣＤ−Ｒ、ＤＶＤ等を用いたデータ記録、再生処理を実行する。
【０２５６】
ステップＳ３５０２において、認証が成立しなかったと判定された場合は、ステップＳ３５０３の認証機能を持たない記憶媒体、例えばハードディスク、ＣＤ−Ｒ、ＤＶＤ等を用いたデータ記録、再生処理が実行されない。
【０２５７】
ここで、仮想メモリカードには、予め、先の図１６で説明した認証鍵データを格納した構成とし、再生装置が使用する認証キーを前述したように、キー有効化ブロックで提供する構成とする。
【０２５８】
このように、再生装置の認証キーをキー有効化ブロック（ＥＫＢ）で提供することにより、正当なライセンスを持つデバイス（再生装置）に対してのみ、仮想メモリカードとの相互認証可能な認証キーを配信することが可能となる。従って、不正な機器、すなわちリボークされた再生装置には、有効な認証キーが配信しない処理が可能となる。有効な認証キーが提供されない再生装置は、相互認証が不成立となり、認証機能を持つメモリカードのみならず、認証機能を持たない記憶媒体、例えばハードディスク、ＣＤ−Ｒ、ＤＶＤ等を用いたデータ記録、再生処理が実行されず、不正な機器によるデータ記録、再生を排除することが可能となる。
【０２５９】
すなわち、認証鍵を提供する有効化キーブロック（ＥＫＢ）をキーツリーのリーフを構成するデータ処理装置中、正当なライセンスを持つデータ処理装置においてのみ復号可能で、正当ライセンスを持たない不正なデータ処理装置においては復号不可能な有効化キーブロック（ＥＫＢ）として提供することにより、不正なデータ処理装置における仮想メモリデバイスとの認証成立を防止して、不正データ処理装置におけるコンテンツ利用を排除可能とした構成を有するライセンスシステムが実現される。
【０２６０】
［チェック値（ＩＣＶ:Integrity Check Value）格納構成］
次に、コンテンツの改竄を防止するためにコンテンツのインテグリティ・チェック値（ＩＣＶ）を生成して、コンテンツに対応付けて、ＩＣＶの計算により、コンテンツ改竄の有無を判定する処理構成について説明する。
【０２６１】
コンテンツのインテグリティ・チェック値（ＩＣＶ）は、例えばコンテンツに対するハッシュ関数を用いて計算され、ＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｃ１，Ｃ２，…）によって計算される。ＫｉｃｖはＩＣＶ生成キーである。Ｃ１，Ｃ２はコンテンツの情報であり、コンテンツの重要情報のメッセージ認証符号（ＭＡＣ：Message authentication Code）が使用される。前述したように、［ＭＡＣ］は、図２１で説明したＡＴＲＡＣ３データファイルにも含まれる。これらを使用してインテグリティ・チェック値（ＩＣＶ）の計算がなされる。
【０２６２】
ＤＥＳ暗号処理構成を用いたＭＡＣ値生成例を図３７に示す。図３７の構成に示すように対象となるメッセージを８バイト単位に分割し、（以下、分割されたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、まず、初期値（Initial Value（以下、ＩＶとする））とＭ１を排他的論理和する（その結果をＩ１とする）。次に、Ｉ１をＤＥＳ暗号化部に入れ、鍵（以下、Ｋ１とする）を用いて暗号化する（出力をＥ１とする）。続けて、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２をＤＥＳ暗号化部へ入れ、鍵Ｋ１を用いて暗号化する（出力Ｅ２）。以下、これを繰り返し、全てのメッセージに対して暗号化処理を施す。最後に出てきたＥＮがメッセージ認証符号（ＭＡＣ（Message Authentication Code））となる。なお、メッセージとしては、検証対象となるコンテンツおよびヘッダ情報等のコンテンツ関連データを構成する部分データが使用可能である。
【０２６３】
このようなコンテンツのＭＡＣ値とＩＣＶ生成キーＫｉｃｖにハッシュ関数を適用して用いてコンテンツのインテグリティ・チェック値（ＩＣＶ）が生成される。改竄のないことが保証された例えばコンテンツ生成時に生成したＩＣＶと、新たにコンテンツに基づいて生成したＩＣＶとを比較して同一のＩＣＶが得られればコンテンツに改竄のないことが保証され、ＩＣＶが異なれば、改竄があったと判定される。
【０２６４】
上述のようなインテグリティ・チェック値（ＩＣＶ）は、コンテンツ個々に対して生成される複数のコンテンツＭＡＣ値により、１つのインテグリティ・チェック値（ＩＣＶ）を生成することが可能である。複数のＭＡＣによるＩＣＶの計算は、例えば、ＩＣＶ＝ＭＡＣ（Ｋｉｃｖ，Ｃ＿ＭＡＣ［０］||Ｃ＿ＭＡＣ［１］||Ｃ＿ＭＡＣ［２］||…）によって生成する。
【０２６５】
コンテンツ生成時に生成したＩＣＶを格納しておき、チェック処理時に生成ＩＣＶと格納ＩＣＶの比較処理を行なう。両ＩＣＶが一致すれば改竄無しと判定し、ＩＣＶが不一致の場合は、改竄が有りと判定され、データ再生等の処理制限がなされる。
【０２６６】
メモリカード等の記憶装置には、音楽コンテンツのみならず、画像データ、ゲームプログラムデータ等、カテゴリの異なるが格納される。これら各カテゴリのコンテンツも改竄の防止を図るため、各カテゴリ毎にインテグリティ・チェック値（ＩＣＶ）を生成して格納することがコンテンツ改竄チェックのためには有効な手段となる。
【０２６７】
しかしながら、メモリに格納するコンテンツ数が増大すると、検証用のチェック値を正規のコンテンツデータに基づいて生成し、格納し管理することが困難となる。特に、昨今フラッシュメモリを使用したメモリカード等の容量の大きい媒体においては、音楽データ、画像データ、プログラムデータ等、様々なカテゴリのコンテンツデータがメモリに格納されることとなる。このような環境においては、チェック値の生成処理、格納処理、改竄チェック処理の管理は困難となる。格納データ全体に対するチェック値を生成すると、チェック対象となったデータ全体に対するチェック値生成処理を実行することが必要となる。例えばＤＥＳ−ＣＢＣモードにおいて生成されるメッセージ認証符号（ＭＡＣ）により、チェック値ＩＣＶを求める手法を行なう場合、データ全体に対するＤＥＳ−ＣＢＣの処理を実行することが必要となる。この計算量は、データ長が長くなるにつれ増大することとなり、処理効率の点で問題がある。
【０２６８】
記憶装置として使用可能なメモリカードには、多くのカテゴリの異なるコンテンツが格納される。これらのカテゴリの異なるコンテンツの改竄チェック管理をカテゴリ毎に独立したインテグリティ・チェック値（ＩＣＶ）を生成して実行する構成とすることにより、ＩＣＶのチェック時、あるいはＩＣＶの変更時、例えばデータ変更時の新たなインテグリティ・チェック値（ＩＣＶ）の生成処理が、１つのカテゴリ内のデータを対象として実行可能となり、他のカテゴリに影響を及ぼすことがない。このようにカテゴリ毎の複数のインテグリティ・チェック値（ＩＣＶ）を格納する構成について説明する。
【０２６９】
図３８に記憶装置に格納されるデータ構成と、それぞれのインテグリティ・チェック値（ＩＣＶ）の格納構成例を示す。メモリカード等の記憶部（フラッシュメモリ）には、図３８に示されるように音楽データのディレクトリに、再生管理ファイル（ＰＢＬＩＳＴ）、暗号化コンテンツとして複数のＡＴＲＡＣＫ３データファイル（Ａ３Ｄ）が含まれ、さらに、メモリには、複数のカテゴリに属するコンテンツデータ（＃１〜＃ｎ）が格納される。複数のカテゴリとは、例えば、音楽データ、画像データ、ゲームプログラム等である。さらに、同様の画像データであっても、それぞれのデータ提供元に応じて別のディレクトリとして独立のカテゴリとして管理してもよい。
【０２７０】
また、前述の有効化キーブロック（ＥＫＢ）の管理単位（エンティテイ）を１カテゴリとして設定してもよい。すなわち、ある有効化キーブロック（ＥＫＢ）によって取得されるキー暗号キー：ＫＥＫによって復号されるコンテンツキーＫｃｏｎを適用可能なコンテンツ集合を１つのカテゴリとして設定してもよい。
【０２７１】
再生管理ファイル（ＰＢＬＩＳＴ）、暗号化コンテンツとして複数のＡＴＲＡＣＫ３データファイル（Ａ３Ｄ）の各々には、改竄チェックのためのメッセージ認証符号（ＭＡＣ（Message Authentication Code））が含まれ、これらのＭＡＣ値に基づいてインテグリティ・チェック値（ＩＣＶ（ｃｏｎ））が生成される。複数のコンテンツのＭＡＣ値は、フラッシュメモリのシーケンスページにＭＡＣリストとして格納、管理され、これらのＭＡＣリストに基づいてＩＣＶ生成キーＫｉｃｖを適用して得られるインテグリティ・チェック値（ＩＣＶ（ｃｏｎ））が格納保存される。
【０２７２】
コンテンツＭＡＣ値を格納するシーケンスページフォーマットを図３９に示す。シーケンスページ領域は、一般コンテンツデータの書き込み禁止領域として設定された領域である。図３９のシーケンスページ構成について説明する。
【０２７３】
Ｅ（ｋＳＴＲ，ｋＣＯＮ）は、メモリカードのストレージキーで暗号化したコンテンツキーである。ＩＤ（ｕｐｐｅｒ），（ｌｏｗｅｒ）は、メモリカードの識別子（ＩＤ）の格納領域である。Ｃ＿ＭＡＣ［０］は、再生管理ファイル（ＰＢＬＩＳＴ）の構成データに基づいて生成されたＭＡＣ値である。Ｃ＿ＭＡＣ［１］は、コンテンツ、例えばＡＴＲＡＣＫ３データファイル＃１のデータに基づいて生成されたＭＡＣ値、以下、コンテンツ毎にＭＡＣ値が格納される。これらのＭＡＣ値に基づいてインテグリティ・チェック値（ＩＣＶ（ｃｏｎ））が生成され、生成されたＩＣＶ（ｃｏｎ）がシリアルプロトコルを通してメモリに書き込まれる。なお、異なる鍵システムに対応するため、それぞれの鍵システムから生成されるＩＣＶをそれぞれ違うエリアに格納する構成とすることが好ましい。
【０２７４】
また、カテゴリ毎に改竄チェックのために生成される各カテゴリ毎のインテグリティ・チェック値（ＩＣＶ）は、メモリカードの記憶部（フラッシュメモリ）のプールページに記録される。プールページもまた、一般データの書き込みの禁止された領域として設定されている。
【０２７５】
各カテゴリ毎のインテグリティ・チェック値（ＩＣＶ）を格納するプールページフォーマットを図４０に示す。＃０＿ｒｅｖｉｓｉｏｎは、カテゴリ＃０の更新データが設定され、更新された場合はインクリメントされる。＃０＿ｖｅｒｓｉｏｎは、カテゴリ＃０のバージョン、＃０＿Ｅ（ＫＥＫ，Ｋｉｃｖ）は、カテゴリ＃０のキー暗号化キー（ＫＥＫ）で暗号化したＩＣＶ生成キー（Ｋｉｃｖ）であり、ＩＣＶ０は、カテゴリ＃０のインテグリティ・チェック値（ＩＣＶ）値である。以下、同様のデータが各カテゴリ毎にＥＫＢ＃１５まで格納可能となっている。
【０２７６】
ＩＣＶのチェックは、パワーオン時、またはメモリカード等の記憶装置が再生装置にセットされたことを条件として開始される。図４１にＩＣＶチェックを含む処理フローを示す。
【０２７７】
まず、再生装置がパワーオン、または新たなメモリカード等が装着されたことを検知すると、ステップＳ４００１において、再生装置と記憶装置間の相互認証が可能か否かが判定され、可能である場合は、ステップＳ４００２において記憶装置と再生装置間での相互認証処理（図２９参照）が実行される。また、ステップＳ４００１において、再生装置と記憶装置間の相互認証が可能でないと判定された場合は、ステップＳ４００３において、前述した仮想メモリカードと再生装置間の相互認証処理が実行される。
【０２７８】
ステップＳ４００４で相互認証が成立したか否かが判定され、不成立の場合は、以下の処理は実行されないで終了する。相互認証が成立の場合は、ステップＳ４００５においてＩＣＶの計算が実行される。ＩＣＶは、前述したように各ファイルのＭＡＣ値に基づいて算出される。
【０２７９】
次にステップＳ４００６において、計算によって算出された生成ＩＣＶと、予め格納してある格納ＩＣＶとの比較が実行される。両ＩＣＶが一致した場合は、データ改竄がないと判定され、ステップＳ４００７において、データ再生等の様々な処理が実行される。一方、ＩＣＶが不一致であった場合は、データ改竄があると判定され、データの再生等を行なわず処理を終了する。このような処理を実行することによりデータ改竄の防止、改竄されたデータの再生が排除される。
【０２８０】
このように、カテゴリの異なるコンテンツについて、カテゴリ毎に独立したインテグリティ・チェック値（ＩＣＶ）を生成して管理する構成とすることにより、ＩＣＶのチェック時、あるいはＩＣＶの変更時、例えばデータ変更時の新たなインテグリティ・チェック値（ＩＣＶ）の生成処理が、１つのカテゴリ内のデータを対象として実行可能となり、他のカテゴリに影響を及ぼすことがない。
【０２８１】
［拡張ＭＡＣ構成］
前述の再生管理ファイルまたは、ＡＴＲＡＣＫ３データファイルのデータ内容の欄で説明したデータ改竄チェック用のＭＡＣ(Message Authentication Code)の生成、および各ファイルに対する格納処理の変形例として、拡張ＭＡＣの生成、格納処理について、以下説明する。
【０２８２】
図４２に拡張ＭＡＣの生成、格納処理例を示す。図４２には、先の図２１〜２３で示したＡＴＲＡＣＫ３データファイルの一部を示している。データ改竄チェック用のＭＡＣ(Message Authentication Code)は、例えばＡＴＲＡＣＫ３データファイル中のいくつかのデータ項目のデータに基づいて、先の図３７で説明した処理によって生成される値であり、予めファイルに格納されたＭＡＣと、チェック時の生成ＭＡＣとの比較により、データ改竄の有無を判定する。
【０２８３】
例えば、図４２に示すＡＴＲＡＣＫ３データファイルに格納されるＭＡＣは、そのＭＡＣによる改竄チェック対象データが、「ＩＮＦ−ｓｅｑ＃」からの複数のデータ項目に設定され、予めそれらのＭＡＣ対象データ項目に基づいて生成されたＭＡＣがファイルに格納されることになる。すなわち、ＭＡＣ（ＩＮＦ−ｓｅｑ＃||Ａ||ＬＴ||…）である。（）内のデータがＭＡＣの対象、すなわち、改竄の有無の判定対象となるデータである。
【０２８４】
しかしながら、ＡＴＲＡＣＫ３データファイル中には、様々な情報データが格納され、改竄チェック対象データが増加する場合がある。このような増加したチェック対象データも含めて新たなＭＡＣを生成し、これを拡張ＭＡＣとしてファイル中に格納するとともに、従来の改竄チェック対象データのみを対象として生成されるオリジナルＭＡＣについては、基本的に改竄チェック対象領域を不変として設定した構成について説明する。
【０２８５】
図４２には、先に説明したＩＮＦ−ｓｅｑ＃以下のデータを改竄チェック対象データとして設定して、生成されるオリジナルＭＡＣ７０１がＡＴＲＡＣＫ３データファイルに格納されている。
【０２８６】
さらに、ＡＴＲＡＣＫ３データファイル中のＩＮＦスペースに記録されるいくつかの情報中に、改竄チェックの対象とすべきデータが存在する場合、オリジナルＭＡＣ７０１のＭＡＣ生成対象データを構成するデータ、ここでは、［ＩＮＦ−ｓｅｑ＃］を含めて、その他のＩＮＦスペース内の改竄チェック対象データに基づいて新たなＭＡＣを生成し、これを拡張ＭＡＣとしてデータファイル中に格納する。
【０２８７】
図４２において、拡張ＭＡＣ［ＭＡＣ（ＩＮＦ）］７０２は、ＭＡＣ（INF−Seq#||path||MAC（profile）||Others…）によって生成される、このように、拡張ＭＡＣは、オリジナルＭＡＣのＭＡＣ生成対象データの一部を含み、その他の改竄チェック対象と併せたデータに基づいて生成される。
【０２８８】
また、拡張ＭＡＣの書き換え時、すなわち、拡張ＭＡＣの対象データ、すなわちＩＮＦ領域の［ｐａｔｈ］以下のデータの書き換えにより、新たな拡張ＭＡＣを、その書き換えデータに基づいて再生成して再格納する処理を実行する際には、拡張ＭＡＣに含まれ、かつオリジナルＭＡＣの対象データでもある［ＩＮＦ−ｓｅｑ＃］の書き換えを行なって新たな拡張ＭＡＣの生成、格納処理を実行する。
【０２８９】
この場合、オリジナルＭＡＣについても、その対象データである［ＩＮＦ−ｓｅｑ＃］の書き換えが実行されているので、新たにオリジナルＭＡＣの計算を実行する。すなわち、拡張ＭＡＣの更新時には、オリジナルＭＡＣの再生成、再格納処理を併せて実行する。
【０２９０】
［ＩＮＦ−ｓｅｑ＃］の書き換えは、例えば新たな乱数の発生による書き換え処理、あるいは、ＩＮＦ−ｓｅｑ＃データのインクリメント処理等によって実行可能である。
【０２９１】
このように、改竄チェック対象データの増加に対応して生成される拡張ＭＡＣのＭＡＣ生成対象データに、オリジナルＭＡＣのＭＡＣ対象データの一部を含めて、双方のＭＡＣの共通するＭＡＣ対象データを存在させ、拡張ＭＡＣの更新時には、オリジナルＭＡＣの再生成も併せて実行する構成としたので、オリジナルＭＡＣのＭＡＣ対象データ領域を広げることなく、新たな改竄チェック用データである例えばＩＮＦ内のデータの書き換え処理を常にオリジナルＭＡＣに反映させることが可能となる。
【０２９２】
［記憶装置および再生装置間におけるＥＫＢ処理］
次に、前述のツリー構造の鍵配信システムを適用した有効化キーブロック（ＥＫＢ）を用いて、暗号化コンテンツの復号処理に適用するコンテンツキーを取得する具体的処理構成について説明する。
【０２９３】
図４３にＡＴＲＡＣＫ３データ等の暗号化コンテンツを格納した例えばメモリスティック等の記憶装置１００と、コンテンツ再生を実行する再生装置Ａ２００，再生装置Ｂ３００を示す。
【０２９４】
記憶装置１００には、暗号化コンテンツとして、図２１等を用いて説明したＡＴＲＡＣＫ３データファイルが格納され、再生装置においてコンテンツを再生するためには、コンテンツの復号に必要なコンテンツキーＫｃｏｎを取得することが必要となる。
【０２９５】
まず、再生装置が記憶装置からコンテンツキーを直接取得する処理態様について、図４３に示す記憶装置８００と再生装置Ａ８１０とで説明する。まず、記憶装置８００と、再生装置Ａ８１０は、認証処理機能を実行する相互の制御モジュール８０１，８１１間において相互認証処理を実行する。相互認証は、例えば先に説明した図８の共通鍵暗号方式、あるいは公開鍵暗号方式による相互認証処理として実行する。この場合、記憶装置８００と、再生装置Ａ８１０は、それぞれの制御処理モジュール８０１，８１１が認証処理実行アルゴリズムを有し、さらに、認証処理に必要な鍵を格納していることが必要である。
【０２９６】
記憶装置８００は、再生装置Ａ８１０との相互認証の成立後、記憶装置８００内の制御モジュール８０１において、フラッシュメモリ８０２に格納したＡＴＲＡＣＫ３データファイルから、記憶装置のストレージキーＫｓｔｍで暗号化されたコンテンツキー：Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）または、先に説明したＥＫＢファイルの処理によって取得可能なキー暗号キー（ＫＥＫ）で暗号化されたコンテンツキー：Ｅ（ＫＥＫ，Ｋｃｏｎ）のいずれかを取り出し、復号処理を実行して、コンテンツキーＫｃｏｎを取得する。
【０２９７】
記憶装置８００は、再生装置Ａ８１０との相互認証時に生成したセッションキーＫｓｅｓを用いてコンテンツキーＫｃｏｎの再暗号化を実行し、生成した暗号化データ：Ｅ（Ｋｓｅｓ，Ｋｃｏｎ）を再生装置Ａ８１０に送付する。再生装置Ａ８１０は、制御モジュール８１１において、受領した暗号化コンテンツキーＥ（Ｋｓｅｓ，Ｋｃｏｎ）をセッションキーＫｓｅｓで復号してコンテンツキーを取得する。
【０２９８】
以上、説明した手法が、記憶装置側において、コンテンツキーを復号して取り出して、これを再度セッションキーで暗号化して再生装置に送付する手法である。
【０２９９】
次に、記憶装置側では復号処理を実行せず、再生装置側においてコンテンツキーを取得する処理を実行形態について説明する。
【０３００】
この処理形態を図４３の記憶装置８００と再生装置Ｂ８３０との間の処理として説明する。記憶装置８００は、ＡＴＲＡＣＫ３データフアイル中の有効化キーブロック（ＥＫＢ）バージョン（またはジェネレーション）から、コンテンツキーの取得に必要となる対応有効化キーブロック（ＥＫＢ）を特定し、特定されたＥＫＢを再生装置Ｂ８３０に送付する。
【０３０１】
再生装置Ｂ８３０は、記憶装置からＥＫＢを受領し、予め再生装置内のメモリ、例えばＥ２ＰＲＯＭ（ｅｘ．フラッシュメモリ）内に格納したデバイスキーブロック（ＤＫＢ）を用いて受領ＥＫＢの処理を実行し、キー暗号キー（ＫＥＫ）を取得する。
【０３０２】
ここで、デバイスキーブロック（ＤＫＢ）について説明する。図４４を用いてデバイスキーブロック（ＤＫＢ）の構成を説明する。前述したように、コンテンツ再生装置等の各デバイスは、図４４（ａ）に示すツリー構造の鍵配信構成の末端すなわちリーフから上位のルートに連なる各ノードのキーを有する。例えば図４４（ａ）に示す末端ノードのセット５（ＳＥＴ５）に対応するデバイスは、リーフキーとしてのＫ１０１，ノードキーとしてＫ１０，Ｋ１から、ルートキーＫｒｏｏｔに至るキーセット、または、サブカテゴリーノードキーに至るキーセット、あるいはカテゴリーノードに至るキーセットを保有する。
【０３０３】
これらの各キーは、デバイスにおいて暗号化されてデバイス内のメモリ、例えばＥ２ＰＲＯＭに格納される。このような各デバイスに保存されるリーフから特定ノード（ｅｘ．サブカテゴリーノード）またはルートまでのキーに対応するキーセットの暗号化キーセットがデバイスキーブロック（ＤＫＢ）である。
【０３０４】
デバイスキーブロック（ＤＫＢ）のデータ構成例を図４４（ｂ）に示す。図４４（ｂ）に示すように、ＤＫＢはノードキー、およびルートキーをリーフキーで暗号化したデータと、リーフキーをデバイス（ｅｘ．再生装置）のストレージキー：Ｋｓｔｄで暗号化したデータを有する暗号化キーブロックとして構成される。デバイス（ｅｘ．再生装置）は、このデバイスキーブロック（ＤＫＢ）中のＥｎｃ（Ｋｓｔｄ，Ｋｌｅａｆ）を、自身のストレージキー：Ｋｓｔｄを用いて復号し、リーフキーＫｌｅａｆを取得し、さらに、取得したリーフキーＫｌｅａｆを用いて高位の暗号化ノードキー、暗号化ルートキーを直接復号することが可能となり、ＥＫＢの下位キーから順次復号して上位キーを取得していく処理の省略が可能となる。なおデバイスキーブロック（ＤＫＢ）には、リーフの識別子であるリーフＩＤを含む。
【０３０５】
デバイス固有のストレージキーは、各セット（デバイス）毎に異なる鍵であり、予めデバイス中のセキュアメモリ（ｅｘ．ＳＡＭ）中に格納するか、あるいはリーフＩＤに基づいて求めることの可能な構成としてもよい。すなわち、デバイスの制御モジュール（暗号処理部）において、リーフＩＤに基づいて生成する構成としてもよい。具体的には、所定のセット単位で共通に格納されたマスターキーＫｍａｓに基づいてリーフＩＤに対するハッシュを適用し、Ｋｓｔｄ＝ｈａｓｈ（Ｋｍａｓ，リーフＩＤ）として求める構成としてもよい。
【０３０６】
図４３に戻ってコンテンツキーの取得処理の説明を続ける。記憶装置８００から有効化キーブロック（ＥＫＢ）を受領した再生装置Ｂ８３０は、制御モジュール８３１において、メモリ８３２に格納したデバイスキーブロック（ＤＫＢ）の復号によって得られるノードーキー、ルートキー等を適用してＥＫＢにより暗号化されたキー暗号化キー（ＫＥＫ）を取得する。ＥＫＢの処理手法は、先に図５あるいは図９を用いて説明したと同様の手法である。
【０３０７】
再生装置Ｂ８３０は、有効化キーブロック（ＥＫＢ）の処理によって取得したキー暗号化キー（ＫＥＫ）を用い、さらに、記憶装置８００から受領した暗号化コンテンツキー：Ｅ（ＫＥＫ，Ｋｃｏｎ）の復号処理を実行してコンテンツキーを取得する。
【０３０８】
なお、図４３の再生装置Ｂ８３０のメモリ（Ｅ２ＰＲＯＭ）８３２に格納されたイニシャルＥＫＢは、デバイス（再生装置Ｂ８３０）に当初から格納される簡略化したＥＫＢファイルであり、例えば、前述の図１１を用いた説明中に記載したカテゴリーノードにおいて、１つのカテゴリノード（例えばカテゴリ＝メモリステイック）の下位に接続されるリーフに対応するデバイスに共通に格納される暗号化キーブロックである。
【０３０９】
例えばカテゴリーノードの持つキーがＫ０１であればＫ０１で暗号化されたルートキー：Ｅｎｃ（Ｋ０１，Ｋｒｏｏｔ）がイニシャルＥＫＢとして格納される。デバイスはイニシャルＥＫＢの処理によりルートキーを取得することが可能となり、例えばルートキーによって暗号化されたキー暗号化キー（ＫＥＫ）を格納したＥＫＢを受領した場合には、イニシャルＥＫＢから得たルートキーを用いてキー暗号化キー（ＫＥＫ）を取得することが可能となる。
【０３１０】
なお、イニシャルＥＫＢは、１つのカテゴリーノードに属するデバイスに共通に提供する構成とする態様に限らず、複数のカテゴリノードに共通に構成してもよい。例えばメモリスティックのカテゴリノードのノードキーＫ０１、コンテンツ再生機能を持つＰＣのカンテゴリノードのノードキーをＫ１０、ネットワーク対応の形態再生装置のカテゴリノードのノードキーをＫ１１としたとき、これらの各デバイスに予め、Ｅｎｃ（Ｋ０１，Ｋｒｏｏｔ）、Ｅｎｃ（Ｋ１０，Ｋｒｏｏｔ）、Ｅｎｃ（Ｋ１１，Ｋｒｏｏｔ）の３種類の暗号化ルートキーを格納したイニシャルＥＫＢを設定して出荷することにより、それぞれの異なるデバイスにおいて共通に利用可能な暗号化コンテンツの配信を行なうことが可能となる。
【０３１１】
図４５に、再生装置のメモリ（ｅｘ．Ｅ２ＰＲＯＭ）にデバイスキーブロック（ＤＫＢ）と、イニシャルＥＫＢとして自己録音、自己再生用の有効化キーブロック（ＥＫＢ）を格納した構成例を示す。また、図４６にこれらのキーブロックを利用したコンテンツキーの取得処理例を示す。
【０３１２】
図４５の構成について説明する。デバイス（ｅｘ．記録再生器）は、図４５（ａ）のリーフに対応するデバイスであり、ツリー構成の第８段目に構成されるカテゴリーノードＫｎ８のカテゴリーに属するデバイスである。デバイスには、（ｂ）に示すＥｎｃ（Ｋｓｔｄ，Ｋｌｅａｆ）〜Ｅｎｃ（Ｋｌｅａｆ，Ｋｎ８）のデバイスキーブロック（ＤＫＢ）が格納される。この構成は、先に説明したＤＫＢと同様であるが、リーフキーによって直接暗号化されて格納されたデータは、リーフキーの直上のノードキーＫｎ４７からカテゴリーノードキーであるＫｎ８までのキーとして構成される。
【０３１３】
さらに、デバイスは、自己録音、再生用の有効化キーブロック（ＥＫＢ）を保有し、自己のデバイスでのコンテンツ録音、再生時には、この自己録音、再生用の有効化キーブロック（ＥＫＢ）とデバイスキーブロック（ＤＫＢ）との処理によりコンテンツキーＫｃｏｎを取得して、コンテンツの復号、暗号化を実行する。
【０３１４】
図４６に、図４５（ｂ）のＤＫＢ，ＥＫＢを持つデバイスにおけるコンテンツキーの取得処理において実行するステップを示す。まずステップＳ４６０１において、デバイスは、リーフＩＤに基づいてストレージキーＫｓｔｄを抽出する。ストレージキーＫｓｔｄは、リーフＩＤに基づいてデバイス中のセキュアメモリから抽出するか、あるいは前述したように、マスターキーＫｍａｓとリーフＩＤに基づいて算出する。
【０３１５】
次に、Ｓ４６０２において、ストレージキーＫｓｔｄに基づいてデバイスキーブロック（ＤＫＢ）の処理、すなわちＥｎｃ（Ｋｓｔｄ，Ｋｌｅａｆ）の復号を実行し、リーフキーを求める。次に、Ｓ４６０３において、リーフキーＫｌｅａｆに基づいてデバイスキーブロック（ＤＫＢ）の処理、すなわちＥｎｃ（Ｋｌｅａｆ，Ｋｎ８）の復号を実行し、カテゴリーノードキーを求める。ＤＫＢは、リーフキーにより直接暗号化されたノードキーが格納されているので、高位のノードキーを直接リーフキーによる復号処理によって取得することが可能となる。
【０３１６】
次に、ステップＳ４６０４において、ノードキーＫｎ８からＥＫＢ処理を実行し、順次高位のノードキーを求めて、最上位キーであるルートキーを算出する。次に、ステップＳ４６０５において、有効化キーブロック（ＥＫＢ）の処理によって求めたルートキーＫｒｏｏｔを用いてＥｎｃ（Ｋｒｏｏｔ，ＫＥＫ）の復号処理を実行してキー暗号化キーＫＥＫを求める。最後にステップＳ４６０６において、取得したキー暗号化キーＫＥＫを用いて、コンテンツデータに付随したデータ中に格納されたＥｎｃ（ＫＥＫ，Ｋｃｏｎ）の復号処理を実行してコンテンツキーＫｃｏｎを取得する。
【０３１７】
図４５（ｂ）に示す有効化キーブロック（ＥＫＢ）は自己録再用のＥＫＢであるが、様々なコンテンツをデバイスにダウンロードする際に、そのコンテンツに対応するＥＫＢを併せてダウンロードし、コンテンツに対応付けてＥＫＢをメモリに格納し、コンテンツの再生時にダウンロードしたコンテンツ対応のＥＫＢに対して図４６の処理を実行することも可能である。また、図４５（ｂ）に示すデバイスキーブロック（ＤＫＢ）は、上位から８段のノードＫｎ８のノードキーまでを直接リーフキーで暗号化したデータをＤＫＢの暗号化キーデータとした構成であるが、格納するノードキーは、さらに上位、あるいは下位までのノードキーとしてもよい。
【０３１８】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０３１９】
【発明の効果】
以上、説明したように、本発明のデータ処理装置および方法によれば、複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリーを構成するパス上の更新キー、および下位キーによる上位キーの暗号化処理データを含む有効化キーブロック（ＥＫＢ）によって暗号化された鍵を提供し、選択された正当なデバイスにおいてのみ復号可能な構成として、セキュリティの高い暗号処理鍵、あるいはコンテンツ配信システムが実現される。
【０３２０】
さらに、本発明のデータ処理装置および方法によれば、有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置に格納する構成としたので、適用可能なコンテンツ数が容易に把握可能となり、複数の有効化キーブロック（ＥＫＢ）を記憶装置に格納する場合に、多くのリンクカウントを持つ有効化キーブロック（ＥＫＢ）に含まれるキー暗号キー（ＫＥＫ）を予め復号してメモリに格納しておくことにより、コンテンツ利用時のＥＫＢ処理を省略することが可能となり、コンテンツ利用の効率化が実現される。
【図面の簡単な説明】
【図１】本発明のデータ処理装置の使用概念を説明する図である。
【図２】本発明のデータ処理装置のシステム構成例およびデータ経路例を示す図である。
【図３】本発明のデータ処理装置における各種キー、データの暗号化処理について説明するツリー構成図である。
【図４】本発明のデータ処理装置における各種キー、データの配布に使用される有効化キーブロック（ＥＫＢ）の例を示す図である。
【図５】本発明のデータ処理装置におけるコンテンツキーの有効化キーブロック（ＥＫＢ）を使用した配布例と復号処理例を示す図である。
【図６】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）のフォーマット例を示す図である。
【図７】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）のタグの構成を説明する図である。
【図８】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）と、コンテンツキー、コンテンツを併せて配信するデータ構成例を示す図である。
【図９】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）と、コンテンツキー、コンテンツを併せて配信した場合のデバイスでの処理例を示す図である。
【図１０】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）とコンテンツを記録媒体に格納した場合の対応について説明する図である。
【図１１】本発明のデータ処理装置における階層ツリー構造のカテゴリ分類の例を説明する図である。
【図１２】本発明のデータ処理装置における簡略化有効化キーブロック（ＥＫＢ）の生成過程を説明する図である。
【図１３】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）の生成過程を説明する図である。
【図１４】本発明のデータ処理装置における簡略化有効化キーブロック（ＥＫＢ）を説明する図である。
【図１５】本発明のデータ処理装置における再生装置と記憶装置の構成を示すブロック図である。
【図１６】本発明のデータ処理装置における記憶装置内の記憶ユニットに記憶されているデータを説明する図である。
【図１７】本発明のデータ処理装置における記憶装置のフラッシュメモリに記憶されるデータを説明するための図である。
【図１８】本発明のデータ処理装置における再生管理ファイルのデータ構成を概略的に示す図である。
【図１９】本発明のデータ処理装置におけるデータファイルのデータ構成を概略的に示す図である。
【図２０】本発明のデータ処理装置における再生管理ファイルのデータ構成をより詳細に示す図である。
【図２１】本発明のデータ処理装置におけるデータファイルのデータ構成をより詳細に示す図である。
【図２２】本発明のデータ処理装置におけるデータファイルの属性ヘッダの一部を示す図である。
【図２３】本発明のデータ処理装置におけるデータファイルの属性ヘッダの一部を示す図である。
【図２４】本発明のデータ処理装置におけるモードの種類と、各モードにおける録音時間等を示す図である。
【図２５】本発明のデータ処理装置におけるコピー制御情報を説明するための図である。
【図２６】本発明のデータ処理装置におけるデータファイルの属性ヘッダの一部を示す図である。
【図２７】本発明のデータ処理装置におけるデータファイルの各データブロックのヘッダを示す略線図である。
【図２８】本発明のデータ処理装置におけるデータ記録処理フローを示す図である。
【図２９】本発明のデータ処理装置において適用可能な相互認証処理を示す図である。
【図３０】本発明のデータ処理装置におけるデータ再生処理フローを示す図である。
【図３１】本発明のデータ処理装置における配信鍵許可情報ファイルのフオーマットを示す図である。
【図３２】本発明のデータ処理装置におけるデータ格納態様を示す図である。
【図３３】本発明のデータ処理装置におけるキー有効化ブロック（ＥＫＢ）を使用したデータ復号処理フローを示す図である。
【図３４】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）と、認証キーを併せて配信するデータ構成と、デバイスでの処理例を示す図（その１）である。
【図３５】本発明のデータ処理装置における有効化キーブロック（ＥＫＢ）と、認証キーを併せて配信するデータ構成と、デバイスでの処理例を示す図（その２）である。
【図３６】本発明のデータ処理装置における仮想メモリカードを適用したて認証処理シーケンスを示す図である。
【図３７】本発明のデータ処理装置において適用可能なインテグリティ・チェック値（ＩＣＶ）の生成に使用するＭＡＣ値生成例を示す図である。
【図３８】本発明のデータ処理装置におけるインテグリティ・チェック値（ＩＣＶ）の格納態様を説明する図である。
【図３９】本発明のデータ処理装置におけるＭＡＣ値を格納するシーケンスページフォーマットを示す図である。
【図４０】本発明のデータ処理装置におけるＩＣＶを格納するプールページフォーマットを示す図である。
【図４１】本発明のデータ処理装置におけるＩＣＶチェック処理フローを示す図である。
【図４２】本発明のデータ処理装置においてて着ようか能な拡張ＭＡＣの生成、格納処理を説明する図である。
【図４３】本発明のデータ処理装置におけるキー有効化ブロック（ＥＫＢ）を用いたコンテンツキーの取得処理態様を説明する図である。
【図４４】本発明のデータ処理装置において使用されるデバイスキーブロック（ＤＫＢ）の構成について説明する図である。
【図４５】本発明のデータ処理装置におけるデバイスキーブロック（ＤＫＢ）、キー有効化ブロック（ＥＫＢ）の格納構成例を示する図である。
【図４６】本発明のデータ処理装置におけるデバイスキーブロック（ＤＫＢ）、キー有効化ブロック（ＥＫＢ）を用いたコンテンツキーの取得処理態様を説明する図である。
【符号の説明】
１０ コンテンツ配信手段
１１ インターネット
１２ 衛星放送
１３ 電話回線
１４ メディア
２０ データ処理手段
２１ パーソナルコンピュータ（ＰＣ）
２２ ポータブルデバイス（ＰＤ）
２３ 携帯電話、ＰＤＡ
２４ 記録再生器、ゲーム端末
２５ 再生装置
３０ 記憶手段
１００ パーソナルコンピュータ（ＰＣ）
２００ 再生装置
３００ 記憶装置
６０１ バージョン
６０２ デプス
６０３ データポインタ
６０４ タグポインタ
６０５ 署名ポインタ
６０６ データ部
６０７ タグ部
６０８ 署名
３３，４３ 制御モジュール
５０，６０ 乱数発生ユニット
５１，６１ 記憶ユニット
５２，６２ 鍵生成／演算ユニット
５３，６３ 相互認証ユニット
５４，７４ 暗号化／復号ユニット
５５，６５ 制御ユニット
３４ フラッシュメモリ
４４ 編集モジュール
４５ 圧縮／伸長モジュール
４６ スピーカ
４９ メモリ
８００ 記憶装置
８０１ 制御モジュール
８０２ フラッシュメモリ
８１０ 再生装置Ａ
８１１ 制御モジュール
８３０ 再生装置Ｂ
８３１ 制御モジュール
８３２ メモリ

Claims (14)

1. 記憶装置からのコンテンツ再生または記憶装置に対するコンテンツ記録を行なうデータ処理装置において、
   前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリーを構成するパス上の更新キー、および下位キーによる上位キーの暗号化処理データを含む有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）を有し、
   前記有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置中に格納する構成としたことを特徴とするデータ処理装置。
2. 前記配信鍵許可情報ファイルは、
   コンテンツの暗号処理鍵であるコンテンツキーＫｃｏｎを前記ＥＫＢ配信キー暗号キー（ＫＥＫ）によって暗号化したコンテンツキー暗号化データ：Ｅ（ＫＥＫ，Ｋｃｏｎ）を含む構成であることを特徴とする請求項１に記載のデータ処理装置。
3. 前記データ処理装置は、
   有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数の変更に応じて、前記配信鍵許可情報ファイル中のリンクカウント・データを更新する処理を実行する構成を有することを特徴とする請求項１に記載のデータ処理装置。
4. 前記データ処理装置は、
   記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持する構成としたことを特徴とする請求項１に記載のデータ処理装置。
5. 前記データ処理装置は、
   記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持する構成とするとともに、
   記憶装置に格納したコンテンツの処理において、前記メモリに予め格納したキー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可能な場合においてメモリに予め格納したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場合においてのみ、配信鍵許可情報ファイルの読み出しを実行する構成を有することを特徴とする請求項１に記載のデータ処理装置。
6. 前記有効化キーブロック（ＥＫＢ）によって暗号化され提供されるＥＫＢ配信キー暗号キー（ＫＥＫ）は、世代（バージョン）管理がなされ、世代毎の更新処理が実行される構成であることを特徴とする請求項１に記載のデータ処理装置。
7. 前記データ処理装置は、
   前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリー構成中、自己リーフに対応して設定されたリーフキーを、該データ処理装置固有のストレージキー（Ｋｓｔｄ）で暗号化してデータ処理装置内の記憶手段に格納した構成を有することを特徴とする請求項１に記載のデータ処理装置。
8. 前記データ処理装置は、
   前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリー構成中、自己リーフに対応して設定されたリーフキーに基づいて、前記キーツリーの自己リーフから上位に至るパス上の複数段の異なるノードキーを個別に暗号化した暗号化キーの集合としてのデバイスキーブロック（ＤＫＢ）をデータ処理装置内の記憶手段に格納した構成を有することを特徴とする請求項１に記載のデータ処理装置。
9. データ処理装置において、記憶装置からのコンテンツ再生または記憶装置に対するコンテンツ記録を行なうデータ処理方法であり、
   前記データ処理装置を含む複数のデバイスをリーフとして構成したツリーのルートからリーフまでのパス上のルート、ノード、およびリーフに各々キーを対応付けたキーツリーを構成するパス上の更新キー、および下位キーによる上位キーの暗号化処理データを含む有効化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数を示すリンクカウント・データをヘッダ情報として持つ配信鍵許可情報ファイルを記憶装置中に格納することを特徴とするデータ処理方法。
10. 前記配信鍵許可情報ファイルは、
    コンテンツの暗号処理鍵であるコンテンツキーＫｃｏｎを前記ＥＫＢ配信キー暗号キー（ＫＥＫ）によって暗号化したコンテンツキー暗号化データ：Ｅ（ＫＥＫ，Ｋｃｏｎ）を含む構成であることを特徴とする請求項９に記載のデータ処理方法。
11. 前記データ処理方法は、さらに、
    有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象となるコンテンツ数の変更に応じて、前記配信鍵許可情報ファイル中のリンクカウント・データを更新する処理を実行することを特徴とする請求項９に記載のデータ処理方法。
12. 前記データ処理方法は、さらに、
    記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キーをメモリに格納し保持することを特徴とする請求項９に記載のデータ処理方法。
13. 前記データ処理方法は、さらに、
    記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持するとともに、
    記憶装置に格納したコンテンツの処理において、前記メモリに予め格納したキー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可能な場合においてメモリに予め格納したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場合においてのみ、配信鍵許可情報ファイルの読み出しを実行することを特徴とする請求項９に記載のデータ処理方法。
14. 記憶装置からのコンテンツ再生または記憶装置に対するコンテンツ記録を行なうデータ処理をコンピュータ・システム上で実行せしめるコンピュータ・プログラムを提供するプログラム提供媒体であって、前記コンピュータ・プログラムは、
    記憶装置に格納した複数の配信鍵許可情報ファイル中のリンクカウント・データの示すカウント数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号処理を実行して取得されるキー暗号キー（ＫＥＫ）をメモリに格納し保持するステップと、
    記憶装置に格納したコンテンツの処理において、前記メモリに予め格納したキー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可能な場合においてメモリに予め格納したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場合においてのみ、配信鍵許可情報ファイルの読み出しを実行するステップと、
    を実行させるプログラムを記録したことを特徴とするプログラム提供媒体。

Images