トップ :: G 物理学 :: G06 計算;計数




【発明の名称】 データ処理装置およびデータ処理方法、並びにプログラム提供媒体
【発明者】 【氏名】岡上 拓己
【要約】 【課題】コンテンツの利用を行なうデータ処理装置におけるコンテンツ改竄チェックの効率化を実現した構成を提供する。

【解決手段】記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行する構成において、検証値をコンテンツのカテゴリ毎に生成して格納する。カテゴリは、コンテンツの種類、あるいは、コンテンツの暗号処理鍵として設定されるコンテンツキーＫｃｏｎを暗号化して提供する有効化キーブロック（ＥＫＢ）の管理エンティテイ等に基づいて設定することにより、例えば有効化キーブロック（ＥＫＢ）の管理エンティテイ別に、コンテンツデータの検証処理を独立して実行可能となり、効率的な処理が可能となる。
【特許請求の範囲】
【請求項１】記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行するデータ処理装置であり、前記検証値は、コンテンツのカテゴリ毎に独立した検証値として生成して格納する構成を有することを特徴とするデータ処理装置。
【請求項２】前記データ処理装置は、コンテンツ利用に際して、利用対象コンテンツ構成データに基づいて検証値を算出し、該算出検証値と、予め格納された検証値との比較処理を実行し、一致する場合にのみコンテンツ利用を可能とした構成を有することを特徴とする請求項１に記載のデータ処理装置。
【請求項３】前記記憶装置は、複数のディレクトリの各々に異なるカテゴリのコンテンツデータを格納する構成を有し、前記検証値は、前記複数のディレクトリの各々を単位とするコンテンツの集合に対して生成される値であることを特徴とする請求項１に記載のデータ処理装置。
【請求項４】前記記憶装置は、フラッシュメモリであり、前記カテゴリ毎の検証値は、フラッシュメモリの使用禁止ブロックとして設定された領域に格納される構成を有することを特徴とする請求項１に記載のデータ処理装置。
【請求項５】前記カテゴリは、コンテンツの種類に基づいて設定された構成であり、コンテンツの種類別に独立した検証値を設定し、格納する構成を有することを特徴とする請求項１に記載のデータ処理装置。
【請求項６】前記カテゴリは、コンテンツの暗号処理鍵として設定されるコンテンツキーＫｃｏｎを暗号化して提供する有効化キーブロック（ＥＫＢ）の管理エンティテイに基づいて設定された構成であり、有効化キーブロック（ＥＫＢ）の管理エンティテイ別に独立した検証値を設定し、格納する構成を有することを特徴とする請求項１に記載のデータ処理装置。
【請求項７】前記検証値は、検証対象となるコンテンツおよびヘッダ情報等のコンテンツ関連データを構成する部分データをメッセージとしてＤＥＳ暗号処理によって生成されるメッセージ認証符号（ＭＡＣ）に基づいて生成されるデータであることを特徴とする請求項１に記載のデータ処理装置。
【請求項８】記憶装置に格納されるコンテンツまたはヘッダ情報中の改竄有無検証データとしてのメッセージ認証符号（ＭＡＣ）を生成して格納するデータ処理装置であり、コンテンツまたはヘッダ情報中の異なるデータ領域をＭＡＣ生成対象として複数のメッセージ認証符号（ＭＡＣ）を生成するとともに、前記複数のメッセージ認証符号（ＭＡＣ）の各ＭＡＣ生成対象データ領域の一部を共通データとし、いずれかのＭＡＣ更新時に、前記共通データを更新し、他方のＭＡＣ更新処理も併せて実行する構成としたことを特徴とするデータ処理装置。
【請求項９】記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行するデータ処理方法であり、前記検証値を、コンテンツのカテゴリ毎に独立した検証値として生成して格納することを特徴とするデータ処理方法。
【請求項１０】前記データ処理方法において、さらに、コンテンツ利用に際して、利用対象コンテンツ構成データに基づいて検証値を算出し、該算出検証値と、予め格納された検証値との比較処理を実行し、一致する場合にのみコンテンツ利用を行なうことを特徴とする請求項９に記載のデータ処理方法。
【請求項１１】前記記憶装置は、複数のディレクトリの各々に異なるカテゴリのコンテンツデータを格納する構成を有し、前記検証値は、前記複数のディレクトリの各々を単位とするコンテンツの集合に対して生成することを特徴とする請求項９に記載のデータ処理方法。
【請求項１２】前記記憶装置は、フラッシュメモリであり、前記カテゴリ毎の検証値は、フラッシュメモリの使用禁止ブロックとして設定された領域に格納することを特徴とする請求項９に記載のデータ処理方法。
【請求項１３】前記カテゴリは、コンテンツの種類に基づいて設定され、コンテンツの種類別に独立した検証値を設定し、格納することを特徴とする請求項９に記載のデータ処理方法。
【請求項１４】前記カテゴリは、コンテンツの暗号処理鍵として設定されるコンテンツキーＫｃｏｎを暗号化して提供する有効化キーブロック（ＥＫＢ）の管理エンティテイに基づいて設定され、有効化キーブロック（ＥＫＢ）の管理エンティテイ別に独立した検証値を設定し、格納することを特徴とする請求項９に記載のデータ処理方法。
【請求項１５】前記検証値は、検証対象となるコンテンツおよびヘッダ情報等のコンテンツ関連データを構成する部分データをメッセージとしてＤＥＳ暗号処理によって生成されるメッセージ認証符号（ＭＡＣ）に基づいて生成されるデータであることを特徴とする請求項９に記載のデータ処理方法。
【請求項１６】前記検証対象となるコンテンツおよびヘッダ情報には、異なるデータ領域をＭＡＣ生成対象とした複数のメッセージ認証符号（ＭＡＣ）を含み、前記複数のメッセージ認証符号（ＭＡＣ）は、各々のＭＡＣ生成対象データ領域の一部を共通とし、いずれかのＭＡＣ更新時に他方のＭＡＣ更新処理も併せて実行することを特徴とする請求項１５に記載のデータ処理方法。
【請求項１７】記憶装置に格納されるコンテンツまたはヘッダ情報中の改竄有無検証データとしてのメッセージ認証符号（ＭＡＣ）を生成して格納するデータ処理方法であり、コンテンツまたはヘッダ情報中の異なるデータ領域をＭＡＣ生成対象として複数のメッセージ認証符号（ＭＡＣ）を生成するとともに、前記複数のメッセージ認証符号（ＭＡＣ）の各ＭＡＣ生成対象データ領域の一部を共通データとし、いずれかのＭＡＣ更新時に、前記共通データを更新し、他方のＭＡＣ更新処理も併せて実行することを特徴とするデータ処理方法。
【請求項１８】記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行するデータ処理をコンピュータ・システム上で実行せしめるコンピュータ・プログラムを提供するプログラム提供媒体であって、前記コンピュータ・プログラムは、検証値を、コンテンツのカテゴリ毎に独立した検証値として生成して格納するステップを有することを特徴とするプログラム提供媒体。
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、データ処理装置およびデータ処理方法、並びにプログラム提供媒体に関する。特に、記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行する構成において、検証値をコンテンツのカテゴリ毎に独立した検証値として生成して格納する構成とし、コンテンツ改竄チェック処理の効率化を実現したデータ処理装置およびデータ処理方法、並びにプログラム提供媒体に関する。
【０００２】
【従来の技術】昨今、音楽データ、ゲームプログラム、画像データ等、様々なソフトウエアデータ（以下、これらをコンテンツ（Content）と呼ぶ）を、インターネット等のネットワーク、あるいは、メモリカード、ＤＶＤ、ＣＤ等の流通可能な記憶媒体を介して流通させるコンテンツ流通が盛んになってきている。これらの流通コンテンツは、ユーザの所有するＰＣ（Personal Computer）、再生専用器、あるいはゲーム機器におけるコンテンツデータの受信、あるいはメモリカード、ＣＤ、ＤＶＤ等の記憶媒体の装着により、コンテンツ再生処理が実行されたり、あるいは外部からの入力コンテンツを再生器、ＰＣ等に内蔵の記録デバイス、例えばメモリカード、ハードディスク等に格納し、再度、格納媒体から再生する等の方法により利用される。
【０００３】再生装置、ゲーム機器、ＰＣ等の情報機器には、流通コンテンツをネットワークから受信するため、あるいはＤＶＤ、ＣＤ等にアクセスするためのインタフェースを有し、さらにコンテンツの再生に必要となる制御手段、プログラム、データのメモリ領域として使用されるＲＡＭ、ＲＯＭ等を有する。
【０００４】音楽データ、画像データ、あるいはプログラム等の様々なコンテンツは、再生機器として利用される再生装置、ゲーム機器、ＰＣ等の情報機器本体からのユーザ指示、あるいは接続された入力手段を介したユーザの指示により、例えば内蔵、あるいは着脱自在の記憶媒体から呼び出され、情報機器本体、あるいは接続されたディスプレイ、スピーカ等を通じて再生される。
【０００５】ゲームプログラム、音楽データ、画像データ等、多くのソフトウエア・コンテンツは、一般的にその作成者、販売者に頒布権等が保有されている。従って、これらのコンテンツの配布に際しては、一定の利用制限、すなわち、正規なユーザに対してのみ、ソフトウエアの使用を許諾し、許可のない複製等が行われないようにする、すなわちセキュリティを考慮した構成をとるのが一般的となっている。
【０００６】ユーザに対する利用制限を実現する１つの手法が、配布コンテンツの暗号化処理である。すなわち、例えばインターネット等を介して暗号化された音声データ、画像データ、ゲームプログラム等の各種コンテンツを配布するとともに、正規ユーザであると確認された者に対してのみ、配布された暗号化コンテンツを復号する手段、すなわち復号鍵を付与する構成である。
【０００７】暗号化データは、所定の手続きによる復号化処理によって利用可能な復号データ（平文）に戻すことができる。このような情報の暗号化処理に暗号化鍵を用い、復号化処理に復号化鍵を用いるデータ暗号化、復号化方法は従来からよく知られている。
【０００８】暗号化鍵と復号化鍵を用いるデータ暗号化・復号化方法の態様には様々な種類あるが、その１つの例としていわゆる共通鍵暗号化方式と呼ばれている方式がある。共通鍵暗号化方式は、データの暗号化処理に用いる暗号化鍵とデータの復号化に用いる復号化鍵を共通のものとして、正規のユーザにこれら暗号化処理、復号化に用いる共通鍵を付与して、鍵を持たない不正ユーザによるデータアクセスを排除するものである。この方式の代表的な方式にＤＥＳ（データ暗号標準：Deta encryption standard）がある。
【０００９】上述の暗号化処理、復号化に用いられる暗号化鍵、復号化鍵は、例えばあるパスワード等に基づいてハッシュ関数等の一方向性関数を適用して得ることができる。一方向性関数とは、その出力から逆に入力を求めるのは非常に困難となる関数である。例えばユーザが決めたパスワードを入力として一方向性関数を適用して、その出力に基づいて暗号化鍵、復号化鍵を生成するものである。このようにして得られた暗号化鍵、復号化鍵から、逆にそのオリジナルのデータであるパスワードを求めることは実質上不可能となる。
【００１０】また、暗号化するときに使用する暗号化鍵による処理と、復号するときに使用する復号化鍵の処理とを異なるアルゴリズムとした方式がいわゆる公開鍵暗号化方式と呼ばれる方式である。公開鍵暗号化方式は、不特定のユーザが使用可能な公開鍵を使用する方法であり、特定個人に対する暗号化文書を、その特定個人が発行した公開鍵を用いて暗号化処理を行なう。公開鍵によって暗号化された文書は、その暗号化処理に使用された公開鍵に対応する秘密鍵によってのみ復号処理が可能となる。秘密鍵は、公開鍵を発行した個人のみが所有するので、その公開鍵によって暗号化された文書は秘密鍵を持つ個人のみが復号することができる。公開鍵暗号化方式の代表的なものにはＲＳＡ（Rivest-Shamir-Adleman）暗号がある。このような暗号化方式を利用することにより、暗号化コンテンツを正規ユーザに対してのみ復号可能とするシステムが可能となる。
【００１１】
【発明が解決しようとする課題】コンテンツデータの正当性、すなわちデータが改竄されていないことをチェックするために検証用のチェック値を正規のコンテンツデータに基づいて生成して予めメモリに格納し、コンテンツ利用時に検証対象のデータに基づいて生成したチェック値と格納チェック値とを照合処理することによって、データ検証を行なう方法が従来から行なわれている。
【００１２】しかしながら、メモリに格納するコンテンツ数が増大すると、検証用のチェック値を正規のコンテンツデータに基づいて生成し、格納し管理することが困難となる。特に、昨今フラッシュメモリを使用したメモリカード等の容量の大きい媒体においては、音楽データ、画像データ、プログラムデータ等、様々なカテゴリのコンテンツデータがメモリに格納されることとなる。このような環境においては、コンテンツ。チェック値の生成処理、格納処理、改竄チェック処理の管理は困難となる。格納データ全体に対するチェック値を生成すると、チェック対象となったデータ全体に対するチェック値生成処理を実行することが必要となる。例えばＤＥＳ−ＣＢＣモードにおいて生成されるメッセージ認証符号（ＭＡＣ）により、チェック値ＩＣＶを求める手法を行なう場合、データ全体に対するＤＥＳ−ＣＢＣの処理を実行することが必要となる。この計算量は、データ長が長くなるにつれ増大することとなり、処理効率の点で問題がある。
【００１３】本発明は、このような従来技術の問題点を解決するものであり、データ正当性の確認処理を効率的に実行し、コンテンツデータの検証処理の効率化、さらに検証後の記録デバイスに対するダウンロード処理、あるいは検証後の再生処理等を効率的に実行することを可能とするデータ処理装置およびデータ処理方法、並びにプログラム提供媒体を提供することを目的とする。
【００１４】
【課題を解決するための手段】本発明の第１の側面は、記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行するデータ処理装置であり、前記検証値は、コンテンツのカテゴリ毎に独立した検証値として生成して格納する構成を有することを特徴とするデータ処理装置にある。
【００１５】さらに、本発明のデータ処理装置の一実施態様において、前記データ処理装置は、コンテンツ利用に際して、利用対象コンテンツ構成データに基づいて検証値を算出し、該算出検証値と、予め格納された検証値との比較処理を実行し、一致する場合にのみコンテンツ利用を可能とした構成を有することを特徴とする。
【００１６】さらに、本発明のデータ処理装置の一実施態様において、前記記憶装置は、複数のディレクトリの各々に異なるカテゴリのコンテンツデータを格納する構成を有し、前記検証値は、前記複数のディレクトリの各々を単位とするコンテンツの集合に対して生成される値であることを特徴とする。
【００１７】さらに、本発明のデータ処理装置の一実施態様において、前記記憶装置は、フラッシュメモリであり、前記カテゴリ毎の検証値は、フラッシュメモリの使用禁止ブロックとして設定された領域に格納される構成を有することを特徴とする。
【００１８】さらに、本発明のデータ処理装置の一実施態様において、前記カテゴリは、コンテンツの種類に基づいて設定された構成であり、コンテンツの種類別に独立した検証値を設定し、格納する構成を有することを特徴とする。
【００１９】さらに、本発明のデータ処理装置の一実施態様において、前記カテゴリは、コンテンツの暗号処理鍵として設定されるコンテンツキーＫｃｏｎを暗号化して提供する有効化キーブロック（ＥＫＢ）の管理エンティテイに基づいて設定された構成であり、有効化キーブロック（ＥＫＢ）の管理エンティテイ別に独立した検証値を設定し、格納する構成を有することを特徴とする。
【００２０】さらに、本発明のデータ処理装置の一実施態様において、前記検証値は、検証対象となるコンテンツおよびヘッダ情報等のコンテンツ関連データを構成する部分データをメッセージとしてＤＥＳ暗号処理によって生成されるメッセージ認証符号（ＭＡＣ）に基づいて生成されるデータであることを特徴とする。
【００２１】さらに、本発明の第２の側面は、記憶装置に格納されるコンテンツまたはヘッダ情報中の改竄有無検証データとしてのメッセージ認証符号（ＭＡＣ）を生成して格納するデータ処理装置であり、コンテンツまたはヘッダ情報中の異なるデータ領域をＭＡＣ生成対象として複数のメッセージ認証符号（ＭＡＣ）を生成するとともに、前記複数のメッセージ認証符号（ＭＡＣ）の各ＭＡＣ生成対象データ領域の一部を共通データとし、いずれかのＭＡＣ更新時に、前記共通データを更新し、他方のＭＡＣ更新処理も併せて実行する構成としたことを特徴とするデータ処理装置にある。
【００２２】さらに、本発明の第３の側面は、記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行するデータ処理方法であり、前記検証値を、コンテンツのカテゴリ毎に独立した検証値として生成して格納することを特徴とするデータ処理方法にある。
【００２３】さらに、本発明のデータ処理方法の一実施態様において、コンテンツ利用に際して、利用対象コンテンツ構成データに基づいて検証値を算出し、該算出検証値と、予め格納された検証値との比較処理を実行し、一致する場合にのみコンテンツ利用を行なうことを特徴とする。
【００２４】さらに、本発明のデータ処理方法の一実施態様において、前記記憶装置は、複数のディレクトリの各々に異なるカテゴリのコンテンツデータを格納する構成を有し、前記検証値は、前記複数のディレクトリの各々を単位とするコンテンツの集合に対して生成することを特徴とする。
【００２５】さらに、本発明のデータ処理方法の一実施態様において、前記記憶装置は、フラッシュメモリであり、前記カテゴリ毎の検証値は、フラッシュメモリの使用禁止ブロックとして設定された領域に格納することを特徴とする。
【００２６】さらに、本発明のデータ処理方法の一実施態様において、前記カテゴリは、コンテンツの種類に基づいて設定され、コンテンツの種類別に独立した検証値を設定し、格納することを特徴とする。
【００２７】さらに、本発明のデータ処理方法の一実施態様において、前記カテゴリは、コンテンツの暗号処理鍵として設定されるコンテンツキーＫｃｏｎを暗号化して提供する有効化キーブロック（ＥＫＢ）の管理エンティテイに基づいて設定され、有効化キーブロック（ＥＫＢ）の管理エンティテイ別に独立した検証値を設定し、格納することを特徴とする。
【００２８】さらに、本発明のデータ処理方法の一実施態様において、前記検証値は、検証対象となるコンテンツおよびヘッダ情報等のコンテンツ関連データを構成する部分データをメッセージとしてＤＥＳ暗号処理によって生成されるメッセージ認証符号（ＭＡＣ）に基づいて生成されるデータであることを特徴とする。
【００２９】さらに、本発明のデータ処理方法の一実施態様において、前記検証対象となるコンテンツおよびヘッダ情報には、異なるデータ領域をＭＡＣ生成対象とした複数のメッセージ認証符号（ＭＡＣ）を含み、前記複数のメッセージ認証符号（ＭＡＣ）は、各々のＭＡＣ生成対象データ領域の一部を共通とし、いずれかのＭＡＣ更新時に他方のＭＡＣ更新処理も併せて実行することを特徴とする。
【００３０】さらに、本発明の第４の側面は、記憶装置に格納されるコンテンツまたはヘッダ情報中の改竄有無検証データとしてのメッセージ認証符号（ＭＡＣ）を生成して格納するデータ処理方法であり、コンテンツまたはヘッダ情報中の異なるデータ領域をＭＡＣ生成対象として複数のメッセージ認証符号（ＭＡＣ）を生成するとともに、前記複数のメッセージ認証符号（ＭＡＣ）の各ＭＡＣ生成対象データ領域の一部を共通データとし、いずれかのＭＡＣ更新時に、前記共通データを更新し、他方のＭＡＣ更新処理も併せて実行することを特徴とするデータ処理方法にある。
【００３１】さらに、本発明の第５の側面は、記憶装置に格納されるコンテンツの検証値を生成してコンテンツに対応付けて格納し、コンテンツ改竄の有無を前記検証値により実行するデータ処理をコンピュータ・システム上で実行せしめるコンピュータ・プログラムを提供するプログラム提供媒体であって、前記コンピュータ・プログラムは、検証値を、コンテンツのカテゴリ毎に独立した検証値として生成して格納するステップを有することを特徴とするプログラム提供媒体にある。
【００３２】なお、本発明の第３の側面に係るプログラム提供媒体は、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ・プログラムをコンピュータ可読な形式で提供する媒体である。媒体は、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの伝送媒体など、その形態は特に限定されない。
【００３３】このようなプログラム提供媒体は、コンピュータ・システム上で所定のコンピュータ・プログラムの機能を実現するための、コンピュータ・プログラムと提供媒体との構造上又は機能上の協働的関係を定義したものである。換言すれば、該提供媒体を介してコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の他の側面と同様の作用効果を得ることができるのである。
【００３４】本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【００３５】
【発明の実施の形態】［システム概要］図１に本発明のデータ処理システムの適用可能なコンテンツ配信システム例を示す。コンテンツ配信手段１０は、データ処理手段２０に対して、コンテンツあるいはコンテンツキー、その他、認証処理キー等のデータを暗号化して送信する。データ処理手段２０では、受信した暗号化コンテンツ、あるいは暗号化コンテンツキー等を復号してコンテンツあるいはコンテンツキー等を取得して、画像データ、音声データの再生、あるいは各種プログラムを実行する。コンテンツの配信手段１０とデータ処理手段２０との間のデータ交換は、インターネット等のネットワークを介して、あるいはＤＶＤ、ＣＤ、その他の流通可能な記憶媒体を介して実行される。
【００３６】データ処理手段２０は、例えばフラッシュメモリ等の記憶手段を備えたメモリーカード等のデータ記憶手段３０にデータを格納して保存する。データ記憶手段３０には、暗号処理機能を有する記憶手段としての例えばメモリーカード（具体例としてはメモリスティック(Memory Stick:商標））が含まれる。データ処理手段２０からデータ記憶手段３０に対するデータ格納処理、およびデータ記憶手段３０からデータ処理手段に対するデータ移動の際には、相互認証処理、およびデータの暗号処理が実行され不正なデータコピーの防止が図られる。
【００３７】なお、データ処理手段２０に含まれる各機器間でのコンテンツデータの移動も可能であり、この際にも機器間の相互認証処理、データの暗号処理が実行される。
【００３８】コンテンツ配信手段１０としては、インターネット１１、衛星放送１２、電話回線１３、ＤＶＤ、ＣＤ等のメディア１４等があり、一方、データ処理手段２０のデバイスとしては、パーソナルコンピュータ（ＰＣ）２１、ポータブルデバイス（ＰＤ）２２、携帯電話、ＰＤＡ（Personal Digital Assistants）等の携帯機器２３、ＤＶＤ、ＣＤプレーヤ等の記録再生器、ゲーム端末２４、メモリーカード（ｅｘ．メモリースティック（商標））を利用した再生装置２５等がある。これらデータ処理手段２０の各デバイスは、コンテンツ配信手段１０から提供されるコンテンツをネットワーク等の通信手段あるいは、他のデータ処理手段、または、データ記憶手段３０から取得可能である。
【００３９】図２に、代表的なコンテンツデータの移動処理例を示す。図２に示すシステムは、パーソナルコンピュータ（ＰＣ）１００、再生装置２００および記憶装置３００間でのデータ（コンテンツ）の移動処理例を示した図である。ＰＣ１００は、プログラムおよびデータ記憶用のハードディスク（ＨＤ）を有し、さらに、外部記憶媒体としてのＣＤ，ＤＶＤ等を装着可能な構成を持つ。
【００４０】パーソナルコンピュータ（ＰＣ）１００は、インターネット、公衆回線等の各種ネットワークに接続可能であり、例えば、ＥＭＤ(Electronic Music Distribution: 電子音楽配信）などのサービスを提供する図示しないサービスプロバイダのホストコンピュータから、ネットワークをしてオーディオデータ、画像データ、プログラム等の各種データを受信し、受信したデータを必要に応じて復号して、再生装置２００に出力する。また、パーソナルコンピュータ（ＰＣ）１００は、コンテンツデータを受信するに当たって、必要に応じて、サービスプロバイダのホストコンピュータとの間で認証処理および課金処理などを行う。また、パーソナルコンピュータ（ＰＣ）１００は、例えば、ＣＤ、ＤＶＤから入力したデータを再生装置２００に出力する。
【００４１】記憶装置３００は、再生装置２００に対して着脱自在な装置、例えばメモリスティック(Memory Stick:商標）であり、フラッシュメモリなどの書き換え可能な半導体メモリを内蔵している。
【００４２】図２に示すように、ＰＣ１００、再生装置２００、記憶装置３００間におけるデータ移動、例えば音楽データ、画像データ等のデータ再生、データ記録、データコピー等の処理の際にはデータ移動機器間において、相互認証処理が実行され、不正な機器を用いたデータ移動は防止される。これらの処理については後述する。また、コンテンツデータのネットワークまたは各種記憶媒体を介する配信、また、ＰＣと再生装置相互間、あるいは再生装置とメモリカード等の記憶装置間でのコンテンツ移動の際にはコンテンツを暗号化することでデータのセキュリティが保全される。
【００４３】［キー配信構成としてのツリー（木）構造について］上述のようなコンテンツに対する暗号処理に適用する暗号鍵、例えばコンテンツの暗号処理に適用するコンテンツキー、またはコンテンツキーを暗号化するためのコンテンツキー暗号化キー等の様々な暗号処理キーを、安全に正当なライセンスを持つデバイスに配信する構成として、階層キー・ツリー構成について図３以下を用いて説明する。
【００４４】図３の最下段に示すナンバ０〜１５がコンテンツデータの再生、実行を行なうデータ処理手段２０を構成する個々のデバイス、例えばコンテンツ（音楽データ）再生装置である。すなわち図３に示す階層ツリー（木）構造の各葉(リーフ：leaf)がそれぞれのデバイスに相当する。
【００４５】各デバイス０〜１５は、製造時あるいは出荷時、あるいはその後において、図３に示す階層ツリー（木）構造における、自分のリーフからルートに至るまでのノードに割り当てられた鍵（ノードキー）および各リーフのリーフキーからなるキーセットをメモリに格納する。図３の最下段に示すＫ００００〜Ｋ１１１１が各デバイス０〜１５にそれぞれ割り当てられたリーフキーであり、最上段のＫＲ（ルートキー）から、最下段から２番目の節（ノード）に記載されたキー：ＫＲ〜Ｋ１１１をノードキーとする。
【００４６】図３に示すツリー構成において、例えばデバイス０はリーフキーＫ００００と、ノードキー：Ｋ０００、Ｋ００、Ｋ０、ＫＲを所有する。デバイス５はＫ０１０１、Ｋ０１０、Ｋ０１、Ｋ０、ＫＲを所有する。デバイス１５は、Ｋ１１１１、Ｋ１１１、Ｋ１１、Ｋ１、ＫＲを所有する。なお、図３のツリーにはデバイスが０〜１５の１６個のみ記載され、ツリー構造も４段構成の均衡のとれた左右対称構成として示しているが、さらに多くのデバイスがツリー中に構成され、また、ツリーの各部において異なる段数構成を持つことが可能である。
【００４７】また、図３のツリー構造に含まれる各デバイスには、様々な記録媒体、例えば、デバイス埋め込み型あるいはデバイスに着脱自在に構成されたフラッシュメモリ等を使用したメモリカード、ＤＶＤ、ＣＤ、ＭＤ等、様々なタイプの記憶装置を利用可能なデバイスが含まれている。さらに、様々なアプリケーションサービスが共存可能である。このような異なるデバイス、異なるアプリケーションの共存構成の上に図３に示すコンテンツあるいは鍵配布構成である階層ツリー構造が適用される。
【００４８】これらの様々なデバイス、アプリケーションが共存するシステムにおいて、例えば図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を同一の記録媒体を用いる１つのグループとして設定する。例えば、この点線で囲んだグループ内に含まれるデバイスに対しては、まとめて、共通のコンテンツを暗号化してプロバイダから送付したり、各デバイス共通に使用するコンテンツキーを送付したり、あるいは各デバイスからプロバイダあるいは決済機関等にコンテンツ料金の支払データをやはり暗号化して出力するといった処理が実行される。コンテンツプロバイダ、あるいは決済処理機関等、各デバイスとのデータ送受信を行なう機関は、図３の点線で囲んだ部分、すなわちデバイス０，１，２，３を１つのグループとして一括してデータを送付する処理を実行する。このようなグループは、図３のツリー中に複数存在する。コンテンツプロバイダ、あるいは決済処理機関等、各デバイスとのデータ送受信を行なう機関は、メッセージデータ配信手段として機能する。
【００４９】なお、ノードキー、リーフキーは、ある１つの鍵管理センタによって統括して管理してもよいし、各グループに対する様々なデータ送受信を行なうプロバイダ、決済機関等のメッセージデータ配信手段によってグループごとに管理する構成としてもよい。これらのノードキー、リーフキーは例えばキーの漏洩等の場合に更新処理が実行され、この更新処理は鍵管理センタ、プロバイダ、決済機関等が実行する。
【００５０】このツリー構造において、図３から明らかなように、１つのグループに含まれる３つのデバイス０，１，２，３はノードキーとして共通のキーＫ００、Ｋ０、ＫＲを保有する。このノードキー共有構成を利用することにより、例えば共通のコンテンツキーをデバイス０，１，２，３のみに提供することが可能となる。たとえば、共通に保有するノードキーＫ００自体をコンテンツキーとして設定すれば、新たな鍵送付を実行することなくデバイス０，１，２，３のみに共通のコンテンツキーの設定が可能である。また、新たなコンテンツキーＫｃｏｎをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を、ネットワークを介してあるいは記録媒体に格納してデバイス０，１，２，３に配布すれば、デバイス０，１，２，３のみが、それぞれのデバイスにおいて保有する共有ノードキーＫ００を用いて暗号Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を解いてコンテンツキー：Ｋｃｏｎを得ることが可能となる。なお、Ｅｎｃ（Ｋａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであることを示す。
【００５１】また、ある時点ｔにおいて、デバイス３の所有する鍵：Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,ＫＲが攻撃者（ハッカー）により解析されて露呈したことが発覚した場合、それ以降、システム（デバイス０，１，２，３のグループ）で送受信されるデータを守るために、デバイス３をシステムから切り離す必要がある。そのためには、ノードキー：Ｋ００１,Ｋ００,Ｋ０,ＫＲをそれぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２にその更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａａａは、鍵Ｋａａａの世代（Generation）：ｔの更新キーであることを示す。
【００５２】更新キーの配布処理ついて説明する。キーの更新は、例えば、図４（Ａ）に示す有効化キーブロック（ＥＫＢ：Enabling Key Block）と呼ばれるブロックデータによって構成されるテーブルをたとえばネットワーク、あるいは記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、有効化キーブロック（ＥＫＢ）は、図３に示すようなツリー構造を構成する各リーフに対応するデバイスに新たに更新されたキーを配布するための暗号化キーによって構成される。有効化キーブロック（ＥＫＢ）は、キー更新ブロック（ＫＲＢ：KeyRenewal 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-181:MS-JIS 82:KS C 5601-1989 83:GB(Great Britain)2312-8090:S-JIS(Japanese Industrial Standards)(for Voice)。
【０１１２】言語コード（Ｌ）は下位１バイトで下記のようにEBU Tech 3258 規定に準じて言語を区別する00: 設定しない 08:German 09:English 0A:Spanish0F:French 15:Italian 1D:Dutch65: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 ManagementSystem)におけるコピー許可回数機能：コピー１回か、コピーフリーかの区別を拡張し、回数で指定する。コピー第１世代の場合にのみ有効であり、コピーごとに減算する値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘＦＦ：回数無制限。
【０１６２】上述したトラック情報領域ＴＲＫＩＮＦに続いて、０ｘ０３７０から始まる２４バイトのデータをパーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１つのトラックを複数のパーツで構成する場合に、時間軸の順番にＰＲＴＩＮＦを並べていく。図２６にＰＲＴＩＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、配置順序に従って以下に説明する。
【０１６３】ＰＲＴＳＩＺＥ（４バイト）
意味：パーツサイズ機能：パーツの大きさを表す。クラスタ：２バイト（最上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バイト（最下位）
値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，２，と０から開始する）
【０１６４】ＰＲＴＫＥＹ（８バイト）
意味：パーツを暗号化するための値機能：初期値＝０、編集時は編集の規則に従うこと値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ【０１６５】ＣＯＮＮＵＭ０（４バイト）
意味：最初に作られたコンテンツ累積番号キー機能：コンテンツをユニークにするためのＩＤの役割値：コンテンツ累積番号初期値キーと同じ値とされる。
【０１６６】図２１に戻る。ＡＴＲＡＣ３データファイルの属性ヘッダ中には、図２１に示すように、付加情報ＩＮＦが含まれる。ＩＮＦは、トラックに関する付加情報データであり、ヘッダを伴った可変長の付加情報データ。複数の異なる付加情報が並べられることがある。それぞれにＩＤとデータサイズが付加されている。個々のヘッダを含む付加情報データは、最小１６バイト以上で４バイトの整数倍の単位である。
【０１６７】上述した属性ヘッダに対して、ＡＴＲＡＣ３データファイルの各ブロックのデータが続く。図２７に示すように、ブロック毎にヘッダが付加される。各ブロックのデータについて以下に説明する。
【０１６８】ＢＬＫＩＤ−Ａ３Ｄ（４バイト）
意味：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…）によって生成される、このように、拡張ＭＡＣは、オリジナルＭＡＣのＭＡＣ生成対象データの一部を含み、その他の改竄チェック対象と併せたデータに基づいて生成される。
【０２９２】また、拡張ＭＡＣの書き換え時、すなわち、拡張ＭＡＣの対象データ、すなわちＩＮＦ領域の［ｐａｔｈ］以下のデータの書き換えにより、新たな拡張ＭＡＣを、その書き換えデータに基づいて再生成して再格納する処理を実行する際には、拡張ＭＡＣに含まれ、かつオリジナルＭＡＣの対象データでもある［ＩＮＦ−ｓｅｑ＃］の書き換えを行なって新たな拡張ＭＡＣの生成、格納処理を実行する。
【０２９３】この場合、オリジナルＭＡＣについても、その対象データである［ＩＮＦ−ｓｅｑ＃］の書き換えが実行されているので、新たにオリジナルＭＡＣの計算を実行する。すなわち、拡張ＭＡＣの更新時には、オリジナルＭＡＣの再生成、再格納処理を併せて実行する。
【０２９４】［ＩＮＦ−ｓｅｑ＃］の書き換えは、例えば新たな乱数の発生による書き換え処理、あるいは、ＩＮＦ−ｓｅｑ＃データのインクリメント処理等によって実行可能である。
【０２９５】このように、改竄チェック対象データの増加に対応して生成される拡張ＭＡＣのＭＡＣ生成対象データに、オリジナルＭＡＣのＭＡＣ対象データの一部を含めて、双方のＭＡＣの共通するＭＡＣ対象データを存在させ、拡張ＭＡＣの更新時には、オリジナルＭＡＣの再生成も併せて実行する構成としたので、オリジナルＭＡＣのＭＡＣ対象データ領域を広げることなく、新たな改竄チェック用データである例えばＩＮＦ内のデータの書き換え処理を常にオリジナルＭＡＣに反映させることが可能となる。
【０２９６】［記憶装置および再生装置間におけるＥＫＢ処理］次に、前述のツリー構造の鍵配信システムを適用した有効化キーブロック（ＥＫＢ）を用いて、暗号化コンテンツの復号処理に適用するコンテンツキーを取得する具体的処理構成について説明する。
【０２９７】図４３にＡＴＲＡＣＫ３データ等の暗号化コンテンツを格納した例えばメモリスティック等の記憶装置１００と、コンテンツ再生を実行する再生装置Ａ２００，再生装置Ｂ３００を示す。
【０２９８】記憶装置１００には、暗号化コンテンツとして、図２１等を用いて説明したＡＴＲＡＣＫ３データファイルが格納され、再生装置においてコンテンツを再生するためには、コンテンツの復号に必要なコンテンツキーＫｃｏｎを取得することが必要となる。
【０２９９】まず、再生装置が記憶装置からコンテンツキーを直接取得する処理態様について、図４３に示す記憶装置８００と再生装置Ａ８１０とで説明する。まず、記憶装置８００と、再生装置Ａ８１０は、認証処理機能を実行する相互の制御モジュール８０１，８１１間において相互認証処理を実行する。相互認証は、例えば先に説明した図８の共通鍵暗号方式、あるいは公開鍵暗号方式による相互認証処理として実行する。この場合、記憶装置８００と、再生装置Ａ８１０は、それぞれの制御処理モジュール８０１，８１１が認証処理実行アルゴリズムを有し、さらに、認証処理に必要な鍵を格納していることが必要である。
【０３００】記憶装置８００は、再生装置Ａ８１０との相互認証の成立後、記憶装置８００内の制御モジュール８０１において、フラッシュメモリ８０２に格納したＡＴＲＡＣＫ３データファイルから、記憶装置のストレージキーＫｓｔｍで暗号化されたコンテンツキー：Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）または、先に説明したＥＫＢファイルの処理によって取得可能なキー暗号キー（ＫＥＫ）で暗号化されたコンテンツキー：Ｅ（ＫＥＫ，Ｋｃｏｎ）のいずれかを取り出し、復号処理を実行して、コンテンツキーＫｃｏｎを取得する。
【０３０１】記憶装置８００は、再生装置Ａ８１０との相互認証時に生成したセッションキーＫｓｅｓを用いてコンテンツキーＫｃｏｎの再暗号化を実行し、生成した暗号化データ：Ｅ（Ｋｓｅｓ，Ｋｃｏｎ）を再生装置Ａ８１０に送付する。再生装置Ａ８１０は、制御モジュール８１１において、受領した暗号化コンテンツキーＥ（Ｋｓｅｓ，Ｋｃｏｎ）をセッションキーＫｓｅｓで復号してコンテンツキーを取得する。
【０３０２】以上、説明した手法が、記憶装置側において、コンテンツキーを復号して取り出して、これを再度セッションキーで暗号化して再生装置に送付する手法である。
【０３０３】次に、記憶装置側では復号処理を実行せず、再生装置側においてコンテンツキーを取得する処理を実行形態について説明する。
【０３０４】この処理形態を図４３の記憶装置８００と再生装置Ｂ８３０との間の処理として説明する。記憶装置８００は、ＡＴＲＡＣＫ３データフアイル中の有効化キーブロック（ＥＫＢ）バージョン（またはジェネレーション）から、コンテンツキーの取得に必要となる対応有効化キーブロック（ＥＫＢ）を特定し、特定されたＥＫＢを再生装置Ｂ８３０に送付する。
【０３０５】再生装置Ｂ８３０は、記憶装置からＥＫＢを受領し、予め再生装置内のメモリ、例えばＥ２ＰＲＯＭ（ｅｘ．フラッシュメモリ）内に格納したデバイスキーブロック（ＤＫＢ）を用いて受領ＥＫＢの処理を実行し、キー暗号キー（ＫＥＫ）を取得する。
【０３０６】ここで、デバイスキーブロック（ＤＫＢ）について説明する。図４４を用いてデバイスキーブロック（ＤＫＢ）の構成を説明する。前述したように、コンテンツ再生装置等の各デバイスは、図４４（ａ）に示すツリー構造の鍵配信構成の末端すなわちリーフから上位のルートに連なる各ノードのキーを有する。例えば図４４（ａ）に示す末端ノードのセット５（ＳＥＴ５）に対応するデバイスは、リーフキーとしてのＫ１０１，ノードキーとしてＫ１０，Ｋ１から、ルートキーＫｒｏｏｔに至るキーセット、または、サブカテゴリーノードキーに至るキーセット、あるいはカテゴリーノードに至るキーセットを保有する。
【０３０７】これらの各キーは、デバイスにおいて暗号化されてデバイス内のメモリ、例えばＥ２ＰＲＯＭに格納される。このような各デバイスに保存されるリーフから特定ノード（ｅｘ．サブカテゴリーノード）またはルートまでのキーに対応するキーセットの暗号化キーセットがデバイスキーブロック（ＤＫＢ）である。
【０３０８】デバイスキーブロック（ＤＫＢ）のデータ構成例を図４４（ｂ）に示す。図４４（ｂ）に示すように、ＤＫＢはノードキー、およびルートキーをリーフキーで暗号化したデータと、リーフキーをデバイス（ｅｘ．再生装置）のストレージキー：Ｋｓｔｄで暗号化したデータを有する暗号化キーブロックとして構成される。デバイス（ｅｘ．再生装置）は、このデバイスキーブロック（ＤＫＢ）中のＥｎｃ（Ｋｓｔｄ，Ｋｌｅａｆ）を、自身のストレージキー：Ｋｓｔｄを用いて復号し、リーフキーＫｌｅａｆを取得し、さらに、取得したリーフキーＫｌｅａｆを用いて高位の暗号化ノードキー、暗号化ルートキーを直接復号することが可能となり、ＥＫＢの下位キーから順次復号して上位キーを取得していく処理の省略が可能となる。な