JP2002111648A

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

Info

Publication number: JP2002111648A
Application number: JP2000247462A
Authority: JP
Inventors: Takumi Okanoe; 拓己岡上
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2000-07-24
Filing date: 2000-08-17
Publication date: 2002-04-12
Anticipated expiration: 2020-08-17
Also published as: JP4660899B2; HK1046961A1; KR100840829B1; US20070121950A1; EP1176755A2; US20020094088A1; HK1046961B; US8098827B2; CN1337649A; TW532027B; KR20020009465A; EP1176755B1; SG99923A1; EP1176755A3; US7116785B2; CN1190751C

Abstract

(57)【要約】【課題】コンテンツの記録または再生を実行するデー
タ処理装置におけるコンテンツ利用の効率化を実現した
データ処理装置を提供する。【解決手段】キーツリー構成によって提供される有効
化キーブロック（ＥＫＢ）によって暗号化されたＥＫＢ
配信キー暗号キー（ＫＥＫ）に基づいて復号可能なコン
テンツキーの適用コンテンツ数を示すリンクカウント・
データをヘッダ情報として持つ配信鍵許可情報ファイル
を記憶装置に格納する。複数の有効化キーブロック（Ｅ
ＫＢ）を記憶装置に格納する場合、多くのリンクカウン
トを持つＥＫＢに含まれるキー暗号キー（ＫＥＫ）を予
め復号してメモリに格納し、コンテンツ利用時に格納Ｋ
ＥＫを利用可能としてＥＫＢ処理を省略してコンテンツ
利用の効率化を実現した。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ処理装置お
よびデータ処理方法、並びにプログラム提供媒体に関す
る。特に、ツリー構造の階層的鍵配信方式を用いること
により、メッセージ量を小さく押さえて、例えばコンテ
ンツキー配信、あるいはその他の暗号処理鍵の配信の負
荷を軽減し、かつデータの安全性を保持することを可能
とするとともに、有効化キーブロック（ＥＫＢ）によっ
て暗号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基
づいて取得可能な暗号処理鍵の適用対象となるコンテン
ツ数を示すリンクカウント・データをヘッダ情報として
持つ配信鍵許可情報ファイルを記憶装置に格納すること
により効率的なコンテンツ処理を可能としたデータ処理
装置およびデータ処理方法、並びにプログラム提供媒体
に関する。

【０００２】

【従来の技術】昨今、音楽データ、ゲームプログラム、
画像データ等、様々なソフトウエアデータ（以下、これ
らをコンテンツ（Content）と呼ぶ）を、インターネッ
ト等のネットワーク、あるいは、メモリカード、ＤＶ
Ｄ、ＣＤ等の流通可能な記憶媒体を介して流通させるコ
ンテンツ流通が盛んになってきている。これらの流通コ
ンテンツは、ユーザの所有するＰＣ（Personal Compute
r）、再生専用器、あるいはゲーム機器におけるコンテ
ンツデータの受信、あるいはメモリカード、ＣＤ、ＤＶ
Ｄ等の記憶媒体の装着により、コンテンツ再生処理が実
行されたり、あるいは外部からの入力コンテンツを再生
器、ＰＣ等に内蔵の記録デバイス、例えばメモリカー
ド、ハードディスク等に格納し、再度、格納媒体から再
生する等の方法により利用される。

【０００３】再生装置、ゲーム機器、ＰＣ等の情報機器
には、流通コンテンツをネットワークから受信するた
め、あるいはＤＶＤ、ＣＤ等にアクセスするためのイン
タフェースを有し、さらにコンテンツの再生に必要とな
る制御手段、プログラム、データのメモリ領域として使
用されるＲＡＭ、ＲＯＭ等を有する。

【０００４】音楽データ、画像データ、あるいはプログ
ラム等の様々なコンテンツは、再生機器として利用され
る再生装置、ゲーム機器、ＰＣ等の情報機器本体からの
ユーザ指示、あるいは接続された入力手段を介したユー
ザの指示により、例えば内蔵、あるいは着脱自在の記憶
媒体から呼び出され、情報機器本体、あるいは接続され
たディスプレイ、スピーカ等を通じて再生される。

【０００５】ゲームプログラム、音楽データ、画像デー
タ等、多くのソフトウエア・コンテンツは、一般的にそ
の作成者、販売者に頒布権等が保有されている。従っ
て、これらのコンテンツの配布に際しては、一定の利用
制限、すなわち、正規なユーザに対してのみ、ソフトウ
エアの使用を許諾し、許可のない複製等が行われないよ
うにする、すなわちセキュリティを考慮した構成をとる
のが一般的となっている。

【０００６】ユーザに対する利用制限を実現する１つの
手法が、配布コンテンツの暗号化処理である。すなわ
ち、例えばインターネット等を介して暗号化された音声
データ、画像データ、ゲームプログラム等の各種コンテ
ンツを配布するとともに、正規ユーザであると確認され
た者に対してのみ、配布された暗号化コンテンツを復号
する手段、すなわち復号鍵を付与する構成である。

【０００７】暗号化データは、所定の手続きによる復号
化処理によって利用可能な復号データ（平文）に戻すこ
とができる。このような情報の暗号化処理に暗号化鍵を
用い、復号化処理に復号化鍵を用いるデータ暗号化、復
号化方法は従来からよく知られている。

【０００８】暗号化鍵と復号化鍵を用いるデータ暗号化
・復号化方法の態様には様々な種類あるが、その１つの
例としていわゆる共通鍵暗号化方式と呼ばれている方式
がある。共通鍵暗号化方式は、データの暗号化処理に用
いる暗号化鍵とデータの復号化に用いる復号化鍵を共通
のものとして、正規のユーザにこれら暗号化処理、復号
化に用いる共通鍵を付与して、鍵を持たない不正ユーザ
によるデータアクセスを排除するものである。この方式
の代表的な方式にＤＥＳ（データ暗号標準：Deta encry
ption standard）がある。

【０００９】上述の暗号化処理、復号化に用いられる暗
号化鍵、復号化鍵は、例えばあるパスワード等に基づい
てハッシュ関数等の一方向性関数を適用して得ることが
できる。一方向性関数とは、その出力から逆に入力を求
めるのは非常に困難となる関数である。例えばユーザが
決めたパスワードを入力として一方向性関数を適用し
て、その出力に基づいて暗号化鍵、復号化鍵を生成する
ものである。このようにして得られた暗号化鍵、復号化
鍵から、逆にそのオリジナルのデータであるパスワード
を求めることは実質上不可能となる。

【００１０】また、暗号化するときに使用する暗号化鍵
による処理と、復号するときに使用する復号化鍵の処理
とを異なるアルゴリズムとした方式がいわゆる公開鍵暗
号化方式と呼ばれる方式である。公開鍵暗号化方式は、
不特定のユーザが使用可能な公開鍵を使用する方法であ
り、特定個人に対する暗号化文書を、その特定個人が発
行した公開鍵を用いて暗号化処理を行なう。公開鍵によ
って暗号化された文書は、その暗号化処理に使用された
公開鍵に対応する秘密鍵によってのみ復号処理が可能と
なる。秘密鍵は、公開鍵を発行した個人のみが所有する
ので、その公開鍵によって暗号化された文書は秘密鍵を
持つ個人のみが復号することができる。公開鍵暗号化方
式の代表的なものにはＲＳＡ（Rivest-Shamir-Adlema
n）暗号がある。このような暗号化方式を利用すること
により、暗号化コンテンツを正規ユーザに対してのみ復
号可能とするシステムが可能となる。

【００１１】

【発明が解決しようとする課題】上記のようなコンテン
ツ配信システムでは、コンテンツを暗号化してユーザに
ネットワーク、あるいはＤＶＤ、ＣＤ等の記録媒体に格
納して提供し、暗号化コンテンツを復号するコンテンツ
キーを正当なユーザにのみ提供する構成が多く採用され
ている。コンテンツキー自体の不正なコピー等を防ぐた
めのコンテンツキーを暗号化して正当なユーザに提供
し、正当なユーザのみが有する復号キーを用いて暗号化
コンテンツキーを復号してコンテンツキーを使用可能と
する構成が提案されている。

【００１２】正当なユーザであるか否かの判定は、一般
には、例えばコンテンツの送信者であるコンテンツプロ
バイダとユーザデバイス間において、コンテンツ、ある
いはコンテンツキーの配信前に認証処理を実行すること
によって行なう。一般的な認証処理においては、相手の
確認を行なうとともに、その通信でのみ有効なセッショ
ンキーを生成して、認証が成立した場合に、生成したセ
ッションキーを用いてデータ、例えばコンテンツあるい
はコンテンツキーを暗号化して通信を行なう。認証方式
には、共通鍵暗号方式を用いた相互認証と、公開鍵方式
を使用した認証方式があるが、共通鍵を使った認証にお
いては、システムワイドで共通な鍵が必要になり、更新
処理等の際に不便である。また、公開鍵方式において
は、計算負荷が大きくまた必要なメモリ量も大きくな
り、各デバイスにこのような処理手段を設けることは望
ましい構成とはいえない。

【００１３】本発明では、上述のようなデータの送信
者、受信者間の相互認証処理に頼ることなく、正当なユ
ーザに対してのみ、安全にデータを送信することを可能
とする階層的鍵配信ツリーを用い、正当なライセンスを
持つデバイスにのみ安全に鍵を配信する管理構成を実現
する暗号鍵ブロックを用いたシステムを提供するととも
に、有効化キーブロック（ＥＫＢ）によって暗号化され
たＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可
能な暗号処理鍵の適用対象となるコンテンツ数を示すリ
ンクカウント・データをヘッダ情報として持つ配信鍵許
可情報ファイルを記憶装置に格納することにより効率的
なコンテンツ処理を可能としたデータ処理装置およびデ
ータ処理方法、並びにプログラム提供媒体を提供するこ
とを目的とする。

【００１４】

【課題を解決するための手段】本発明の第１の側面は、
記憶装置からのコンテンツ再生または記憶装置に対する
コンテンツ記録を行なうデータ処理装置において、複数
のデバイスをリーフとして構成したツリーのルートから
リーフまでのパス上のルート、ノード、およびリーフに
各々キーを対応付けたキーツリーを構成するパス上の更
新キー、および下位キーによる上位キーの暗号化処理デ
ータを含む有効化キーブロック（ＥＫＢ）によって暗号
化されたＥＫＢ配信キー暗号キー（ＫＥＫ）を有し、前
記有効化キーブロック（ＥＫＢ）に格納されたＥＫＢ配
信キー暗号キー（ＫＥＫ）に基づいて取得可能な暗号処
理鍵の適用対象となるコンテンツ数を示すリンクカウン
ト・データをヘッダ情報として持つ配信鍵許可情報ファ
イルを記憶装置中に格納する構成としたことを特徴とす
るデータ処理装置にある。

【００１５】さらに、本発明のデータ処理装置の一実施
態様において、前記配信鍵許可情報ファイルは、コンテ
ンツの暗号処理用の鍵であるコンテンツキーＫｃｏｎを
前記キー暗号キー（ＫＥＫ）によって暗号化したコンテ
ンツキー暗号化データ：Ｅ（ＫＥＫ，Ｋｃｏｎ）を含む
構成であることを特徴とする。

【００１６】さらに、本発明のデータ処理装置の一実施
態様において、前記データ処理装置は、有効化キーブロ
ック（ＥＫＢ）に格納されたＥＫＢ配信キー暗号キー
（ＫＥＫ）に基づいて取得可能な暗号処理鍵の適用対象
となるコンテンツ数の変更に応じて、前記配信鍵許可情
報ファイル中のリンクカウント・データを更新する処理
を実行する構成を有することを特徴とする。

【００１７】さらに、本発明のデータ処理装置の一実施
態様において、前記データ処理装置は、記憶装置に格納
した複数の配信鍵許可情報ファイル中のリンクカウント
・データの示すカウント数の多い配信鍵許可情報ファイ
ルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号
処理を実行して取得されるキー暗号化キーをメモリに格
納し保持する構成としたことを特徴とする。

【００１８】さらに、本発明のデータ処理装置の一実施
態様において、前記データ処理装置は、記憶装置に格納
した複数の配信鍵許可情報ファイル中のリンクカウント
・データの示すカウント数の多い配信鍵許可情報ファイ
ルに含まれるＥＫＢ配信キー暗号キー（ＫＥＫ）の復号
処理を実行して取得されるキー暗号化キーをメモリに格
納し保持する構成とするとともに、記憶装置に格納した
コンテンツの処理において、前記メモリに予め格納した
キー暗号キー（ＫＥＫ）の適用可能性を判定し、適用可
能な場合においてメモリに予め格納したキー暗号キー
（ＫＥＫ）を使用し、適用不可能な場合においてのみ、
配信鍵許可情報ファイルの読み出しを実行する構成を有
することを特徴とする。

【００１９】さらに、本発明のデータ処理装置の一実施
態様において、前記有効化キーブロック（ＥＫＢ）によ
って暗号化され提供されるＥＫＢ配信キー暗号キー（Ｋ
ＥＫ）は、世代（バージョン）管理がなされ、世代毎の
更新処理が実行される構成であることを特徴とする。

【００２０】さらに、本発明のデータ処理装置の一実施
態様において、前記データ処理装置は、複数の情報処理
装置をリーフとして構成したツリーのルートからリーフ
までのパス上のルート、ノード、およびリーフに各々キ
ーを対応付けたキーツリー構成中、自己リーフに対応し
て設定されたリーフキーを、該データ処理装置固有のス
トレージキー（Ｋｓｔｄ）で暗号化してデータ処理装置
内の記憶手段に格納した構成を有することを特徴とす
る。

【００２１】さらに、本発明のデータ処理装置の一実施
態様において、前記データ処理装置は、複数のデータ処
理装置をリーフとして構成したツリーのルートからリー
フまでのパス上のルート、ノード、およびリーフに各々
キーを対応付けたキーツリー構成中、自己リーフに対応
して設定されたリーフキーに基づいて、前記キーツリー
の自己リーフから上位に至るパス上の複数段の異なるノ
ードキーを個別に暗号化した暗号化キーの集合としての
デバイスキーブロック（ＤＫＢ）をデータ処理装置内の
記憶手段に格納した構成を有することを特徴とする。

【００２２】さらに、本発明の第２の側面は、記憶装置
からのコンテンツ再生または記憶装置に対するコンテン
ツ記録を行なうデータ処理方法において、複数のデバイ
スをリーフとして構成したツリーのルートからリーフま
でのパス上のルート、ノード、およびリーフに各々キー
を対応付けたキーツリーを構成するパス上の更新キー、
および下位キーによる上位キーの暗号化処理データを含
む有効化キーブロック（ＥＫＢ）によって暗号化された
ＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得可能
な暗号処理鍵の適用対象となるコンテンツ数を示すリン
クカウント・データをヘッダ情報として持つ配信鍵許可
情報ファイルを記憶装置中に格納することを特徴とする
データ処理方法にある。

【００２３】さらに、本発明のデータ処理方法の一実施
態様において、前記配信鍵許可情報ファイルは、コンテ
ンツの暗号処理用の鍵であるコンテンツキーＫｃｏｎを
前記キー暗号キー（ＫＥＫ）によって暗号化したコンテ
ンツキー暗号化データ：Ｅ（ＫＥＫ，Ｋｃｏｎ）を含む
構成であることを特徴とする。

【００２４】さらに、本発明のデータ処理方法の一実施
態様において、有効化キーブロック（ＥＫＢ）に格納さ
れたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づいて取得
可能な暗号処理鍵の適用対象となるコンテンツ数の変更
に応じて、前記配信鍵許可情報ファイル中のリンクカウ
ント・データを更新する処理を実行することを特徴とす
る。

【００２５】さらに、本発明のデータ処理方法の一実施
態様において、記憶装置に格納した複数の配信鍵許可情
報ファイル中のリンクカウント・データの示すカウント
数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信
キー暗号キー（ＫＥＫ）の復号処理を実行して取得され
るキー暗号化キーをメモリに格納し保持することを特徴
とする。

【００２６】さらに、本発明のデータ処理方法の一実施
態様において、記憶装置に格納した複数の配信鍵許可情
報ファイル中のリンクカウント・データの示すカウント
数の多い配信鍵許可情報ファイルに含まれるＥＫＢ配信
キー暗号キー（ＫＥＫ）の復号処理を実行して取得され
るキー暗号化キーをメモリに格納し保持するとともに、
記憶装置に格納したコンテンツの処理において、前記メ
モリに予め格納したキー暗号キー（ＫＥＫ）の適用可能
性を判定し、適用可能な場合においてメモリに予め格納
したキー暗号キー（ＫＥＫ）を使用し、適用不可能な場
合においてのみ、配信鍵許可情報ファイルの読み出しを
実行することを特徴とする。

【００２７】さらに、本発明の第３の側面は、記憶装置
からのコンテンツ再生または記憶装置に対するコンテン
ツ記録を行なうデータ処理をコンピュータ・システム上
で実行せしめるコンピュータ・プログラムを提供するプ
ログラム提供媒体であって、前記コンピュータ・プログ
ラムは、記憶装置に格納した複数の配信鍵許可情報ファ
イル中のリンクカウント・データの示すカウント数の多
い配信鍵許可情報ファイルに含まれるＥＫＢ配信キー暗
号キー（ＫＥＫ）の復号処理を実行して取得されるキー
暗号化キーをメモリに格納し保持するステップと、記憶
装置に格納したコンテンツの処理において、前記メモリ
に予め格納したキー暗号キー（ＫＥＫ）の適用可能性を
判定し、適用可能な場合においてメモリに予め格納した
キー暗号キー（ＫＥＫ）を使用し、適用不可能な場合に
おいてのみ、配信鍵許可情報ファイルの読み出しを実行
するステップと、を有することを特徴とするプログラム
提供媒体にある。

【００２８】なお、本発明の第３の側面に係るプログラ
ム提供媒体は、例えば、様々なプログラム・コードを実
行可能な汎用コンピュータ・システムに対して、コンピ
ュータ・プログラムをコンピュータ可読な形式で提供す
る媒体である。媒体は、ＣＤやＦＤ、ＭＯなどの記録媒
体、あるいは、ネットワークなどの伝送媒体など、その
形態は特に限定されない。

【００２９】このようなプログラム提供媒体は、コンピ
ュータ・システム上で所定のコンピュータ・プログラム
の機能を実現するための、コンピュータ・プログラムと
提供媒体との構造上又は機能上の協働的関係を定義した
ものである。換言すれば、該提供媒体を介してコンピュ
ータ・プログラムをコンピュータ・システムにインスト
ールすることによって、コンピュータ・システム上では
協働的作用が発揮され、本発明の他の側面と同様の作用
効果を得ることができるのである。

【００３０】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。

【００３１】

【発明の実施の形態】［システム概要］図１に本発明の
データ処理システムの適用可能なコンテンツ配信システ
ム例を示す。コンテンツ配信手段１０は、データ処理手
段２０に対して、コンテンツあるいはコンテンツキー、
その他、認証処理キー等のデータを暗号化して送信す
る。データ処理手段２０では、受信した暗号化コンテン
ツ、あるいは暗号化コンテンツキー等を復号してコンテ
ンツあるいはコンテンツキー等を取得して、画像デー
タ、音声データの再生、あるいは各種プログラムを実行
する。コンテンツの配信手段１０とデータ処理手段２０
との間のデータ交換は、インターネット等のネットワー
クを介して、あるいはＤＶＤ、ＣＤ、その他の流通可能
な記憶媒体を介して実行される。

【００３２】データ処理手段２０は、例えばフラッシュ
メモリ等の記憶手段を備えたメモリーカード等のデータ
記憶手段３０にデータを格納して保存する。データ記憶
手段３０には、暗号処理機能を有する記憶手段としての
例えばメモリーカード（具体例としてはメモリスティッ
ク(Memory Stick:商標））が含まれる。データ処理手段
２０からデータ記憶手段３０に対するデータ格納処理、
およびデータ記憶手段３０からデータ処理手段に対する
データ移動の際には、相互認証処理、およびデータの暗
号処理が実行され不正なデータコピーの防止が図られ
る。

【００３３】なお、データ処理手段２０に含まれる各機
器間でのコンテンツデータの移動も可能であり、この際
にも機器間の相互認証処理、データの暗号処理が実行さ
れる。

【００３４】コンテンツ配信手段１０としては、インタ
ーネット１１、衛星放送１２、電話回線１３、ＤＶＤ、
ＣＤ等のメディア１４等があり、一方、データ処理手段
２０のデバイスとしては、パーソナルコンピュータ（Ｐ
Ｃ）２１、ポータブルデバイス（ＰＤ）２２、携帯電
話、ＰＤＡ（Personal Digital Assistants）等の携帯
機器２３、ＤＶＤ、ＣＤプレーヤ等の記録再生器、ゲー
ム端末２４、メモリーカード（ｅｘ．メモリースティッ
ク（商標））を利用した再生装置２５等がある。これら
データ処理手段２０の各デバイスは、コンテンツ配信手
段１０から提供されるコンテンツをネットワーク等の通
信手段あるいは、他のデータ処理手段、または、データ
記憶手段３０から取得可能である。

【００３５】図２に、代表的なコンテンツデータの移動
処理例を示す。図２に示すシステムは、パーソナルコン
ピュータ（ＰＣ）１００、再生装置２００および記憶装
置３００間でのデータ（コンテンツ）の移動処理例を示
した図である。ＰＣ１００は、プログラムおよびデータ
記憶用のハードディスク（ＨＤ）を有し、さらに、外部
記憶媒体としてのＣＤ，ＤＶＤ等を装着可能な構成を持
つ。

【００３６】パーソナルコンピュータ（ＰＣ）１００
は、インターネット、公衆回線等の各種ネットワークに
接続可能であり、例えば、ＥＭＤ(Electronic Music Di
stribution: 電子音楽配信）などのサービスを提供する
図示しないサービスプロバイダのホストコンピュータか
ら、ネットワークをしてオーディオデータ、画像デー
タ、プログラム等の各種データを受信し、受信したデー
タを必要に応じて復号して、再生装置２００に出力す
る。また、パーソナルコンピュータ（ＰＣ）１００は、
コンテンツデータを受信するに当たって、必要に応じ
て、サービスプロバイダのホストコンピュータとの間で
認証処理および課金処理などを行う。また、パーソナル
コンピュータ（ＰＣ）１００は、例えば、ＣＤ、ＤＶＤ
から入力したデータを再生装置２００に出力する。

【００３７】記憶装置３００は、再生装置２００に対し
て着脱自在な装置、例えばメモリスティック(Memory St
ick:商標）であり、フラッシュメモリなどの書き換え可
能な半導体メモリを内蔵している。

【００３８】図２に示すように、ＰＣ１００、再生装置
２００、記憶装置３００間におけるデータ移動、例えば
音楽データ、画像データ等のデータ再生、データ記録、
データコピー等の処理の際にはデータ移動機器間におい
て、相互認証処理が実行され、不正な機器を用いたデー
タ移動は防止される。これらの処理については後述す
る。また、コンテンツデータのネットワークまたは各種
記憶媒体を介する配信、また、ＰＣと再生装置相互間、
あるいは再生装置とメモリカード等の記憶装置間でのコ
ンテンツ移動の際にはコンテンツを暗号化することでデ
ータのセキュリティが保全される。

【００３９】［キー配信構成としてのツリー（木）構造
について］上述のようなコンテンツに対する暗号処理に
適用する暗号鍵、例えばコンテンツの暗号処理に適用す
るコンテンツキー、またはコンテンツキーを暗号化する
ためのコンテンツキー暗号化キー等の様々な暗号処理キ
ーを、安全に正当なライセンスを持つデバイスに配信す
る構成として、階層キー・ツリー構成について図３以下
を用いて説明する。

【００４０】図３の最下段に示すナンバ０〜１５がコン
テンツデータの再生、実行を行なうデータ処理手段２０
を構成する個々のデバイス、例えばコンテンツ（音楽デ
ータ）再生装置である。すなわち図３に示す階層ツリー
（木）構造の各葉(リーフ：leaf)がそれぞれのデバイス
に相当する。

【００４１】各デバイス０〜１５は、製造時あるいは出
荷時、あるいはその後において、図３に示す階層ツリー
（木）構造における、自分のリーフからルートに至るま
でのノードに割り当てられた鍵（ノードキー）および各
リーフのリーフキーからなるキーセットをメモリに格納
する。図３の最下段に示すＫ００００〜Ｋ１１１１が各
デバイス０〜１５にそれぞれ割り当てられたリーフキー
であり、最上段のＫＲ（ルートキー）から、最下段から
２番目の節（ノード）に記載されたキー：ＫＲ〜Ｋ１１
１をノードキーとする。

【００４２】図３に示すツリー構成において、例えばデ
バイス０はリーフキーＫ００００と、ノードキー：Ｋ０
００、Ｋ００、Ｋ０、ＫＲを所有する。デバイス５はＫ
０１０１、Ｋ０１０、Ｋ０１、Ｋ０、ＫＲを所有する。
デバイス１５は、Ｋ１１１１、Ｋ１１１、Ｋ１１、Ｋ
１、ＫＲを所有する。なお、図３のツリーにはデバイス
が０〜１５の１６個のみ記載され、ツリー構造も４段構
成の均衡のとれた左右対称構成として示しているが、さ
らに多くのデバイスがツリー中に構成され、また、ツリ
ーの各部において異なる段数構成を持つことが可能であ
る。

【００４３】また、図３のツリー構造に含まれる各デバ
イスには、様々な記録媒体、例えば、デバイス埋め込み
型あるいはデバイスに着脱自在に構成されたフラッシュ
メモリ等を使用したメモリカード、ＤＶＤ、ＣＤ、ＭＤ
等、様々なタイプの記憶装置を利用可能なデバイスが含
まれている。さらに、様々なアプリケーションサービス
が共存可能である。このような異なるデバイス、異なる
アプリケーションの共存構成の上に図３に示すコンテン
ツあるいは鍵配布構成である階層ツリー構造が適用され
る。

【００４４】これらの様々なデバイス、アプリケーショ
ンが共存するシステムにおいて、例えば図３の点線で囲
んだ部分、すなわちデバイス０，１，２，３を同一の記
録媒体を用いる１つのグループとして設定する。例え
ば、この点線で囲んだグループ内に含まれるデバイスに
対しては、まとめて、共通のコンテンツを暗号化してプ
ロバイダから送付したり、各デバイス共通に使用するコ
ンテンツキーを送付したり、あるいは各デバイスからプ
ロバイダあるいは決済機関等にコンテンツ料金の支払デ
ータをやはり暗号化して出力するといった処理が実行さ
れる。コンテンツプロバイダ、あるいは決済処理機関
等、各デバイスとのデータ送受信を行なう機関は、図３
の点線で囲んだ部分、すなわちデバイス０，１，２，３
を１つのグループとして一括してデータを送付する処理
を実行する。このようなグループは、図３のツリー中に
複数存在する。コンテンツプロバイダ、あるいは決済処
理機関等、各デバイスとのデータ送受信を行なう機関
は、メッセージデータ配信手段として機能する。

【００４５】なお、ノードキー、リーフキーは、ある１
つの鍵管理センタによって統括して管理してもよいし、
各グループに対する様々なデータ送受信を行なうプロバ
イダ、決済機関等のメッセージデータ配信手段によって
グループごとに管理する構成としてもよい。これらのノ
ードキー、リーフキーは例えばキーの漏洩等の場合に更
新処理が実行され、この更新処理は鍵管理センタ、プロ
バイダ、決済機関等が実行する。

【００４６】このツリー構造において、図３から明らか
なように、１つのグループに含まれる３つのデバイス
０，１，２，３はノードキーとして共通のキーＫ００、
Ｋ０、ＫＲを保有する。このノードキー共有構成を利用
することにより、例えば共通のコンテンツキーをデバイ
ス０，１，２，３のみに提供することが可能となる。た
とえば、共通に保有するノードキーＫ００自体をコンテ
ンツキーとして設定すれば、新たな鍵送付を実行するこ
となくデバイス０，１，２，３のみに共通のコンテンツ
キーの設定が可能である。また、新たなコンテンツキー
ＫｃｏｎをノードキーＫ００で暗号化した値Ｅｎｃ（Ｋ
００，Ｋｃｏｎ）を、ネットワークを介してあるいは記
録媒体に格納してデバイス０，１，２，３に配布すれ
ば、デバイス０，１，２，３のみが、それぞれのデバイ
スにおいて保有する共有ノードキーＫ００を用いて暗号
Ｅｎｃ（Ｋ００，Ｋｃｏｎ）を解いてコンテンツキー：
Ｋｃｏｎを得ることが可能となる。なお、Ｅｎｃ（Ｋ
ａ，Ｋｂ）はＫｂをＫａによって暗号化したデータであ
ることを示す。

【００４７】また、ある時点ｔにおいて、デバイス３の
所有する鍵：Ｋ００１１,Ｋ００１,Ｋ００,Ｋ０,ＫＲが
攻撃者（ハッカー）により解析されて露呈したことが発
覚した場合、それ以降、システム（デバイス０，１，
２，３のグループ）で送受信されるデータを守るため
に、デバイス３をシステムから切り離す必要がある。そ
のためには、ノードキー：Ｋ００１,Ｋ００,Ｋ０,ＫＲ
をそれぞれ新たな鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ
（ｔ）０,Ｋ（ｔ）Ｒに更新し、デバイス０，１，２に
その更新キーを伝える必要がある。ここで、Ｋ（ｔ）ａ
ａａは、鍵Ｋａａａの世代（Generation）：ｔの更新キ
ーであることを示す。

【００４８】更新キーの配布処理ついて説明する。キー
の更新は、例えば、図４（Ａ）に示す有効化キーブロッ
ク（ＥＫＢ：Enabling Key Block）と呼ばれるブロック
データによって構成されるテーブルをたとえばネットワ
ーク、あるいは記録媒体に格納してデバイス０，１，２
に供給することによって実行される。なお、有効化キー
ブロック（ＥＫＢ）は、図３に示すようなツリー構造を
構成する各リーフに対応するデバイスに新たに更新され
たキーを配布するための暗号化キーによって構成され
る。有効化キーブロック（ＥＫＢ）は、キー更新ブロッ
ク（ＫＲＢ：KeyRenewal Block）と呼ばれることもあ
る。

【００４９】図４（Ａ）に示す有効化キーブロック（Ｅ
ＫＢ）には、ノードキーの更新の必要なデバイスのみが
更新可能なデータ構成を持つブロックデータとして構成
される。図４の例は、図３に示すツリー構造中のデバイ
ス０，１，２において、世代ｔの更新ノードキーを配布
することを目的として形成されたブロックデータであ
る。図３から明らかなように、デバイス０，デバイス１
は、更新ノードキーとしてＫ（ｔ）００、Ｋ（ｔ）０、
Ｋ（ｔ）Ｒが必要であり、デバイス２は、更新ノードキ
ーとしてＫ（ｔ）００１、Ｋ（ｔ）００、Ｋ（ｔ）０、
Ｋ（ｔ）Ｒが必要である。

【００５０】図４（Ａ）のＥＫＢに示されるようにＥＫ
Ｂには複数の暗号化キーが含まれる。最下段の暗号化キ
ーは、Ｅｎｃ（Ｋ００１０，Ｋ（ｔ）００１）である。
これはデバイス２の持つリーフキーＫ００１０によって
暗号化された更新ノードキーＫ（ｔ）００１であり、デ
バイス２は、自身の持つリーフキーによってこの暗号化
キーを復号し、Ｋ（ｔ）００１を得ることができる。ま
た、復号により得たＫ（ｔ）００１を用いて、図４
（Ａ）の下から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）０
０１，Ｋ（ｔ）００）を復号可能となり、更新ノードキ
ーＫ（ｔ）００を得ることができる。以下順次、図４
（Ａ）の上から２段目の暗号化キーＥｎｃ（Ｋ（ｔ）０
０，Ｋ（ｔ）０）を復号し、更新ノードキーＫ（ｔ）
０、図４（Ａ）の上から１段目の暗号化キーＥｎｃ（Ｋ
（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒを得る。一
方、デバイスＫ００００．Ｋ０００１は、ノードキーＫ
０００は更新する対象に含まれておらず、更新ノードキ
ーとして必要なのは、Ｋ（ｔ）００、Ｋ（ｔ）０、Ｋ
（ｔ）Ｒである。デバイスＫ００００．Ｋ０００１は、
図４（Ａ）の上から３段目の暗号化キーＥｎｃ（Ｋ００
０，Ｋ（ｔ）００）を復号しＫ（ｔ）００、を取得し、
以下、図４（Ａ）の上から２段目の暗号化キーＥｎｃ
（Ｋ（ｔ）００，Ｋ（ｔ）０）を復号し、更新ノードキ
ーＫ（ｔ）０、図４（Ａ）の上から１段目の暗号化キー
Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）を復号しＫ（ｔ）Ｒ
を得る。このようにして、デバイス０，１，２は更新し
た鍵Ｋ（ｔ）００１,Ｋ（ｔ）００,Ｋ（ｔ）０,Ｋ
（ｔ）Ｒを得ることができる。なお、図４（Ａ）のイン
デックスは、復号キーとして使用するノードキー、リー
フキーの絶対番地を示す。

【００５１】図３に示すツリー構造の上位段のノードキ
ー：Ｋ（ｔ）０,Ｋ（ｔ）Ｒの更新が不要であり、ノー
ドキーＫ００のみの更新処理が必要である場合には、図
４（Ｂ）の有効化キーブロック（ＥＫＢ）を用いること
で、更新ノードキーＫ（ｔ）００をデバイス０，１，２
に配布することができる。

【００５２】図４（Ｂ）に示すＥＫＢは、例えば特定の
グループにおいて共有する新たなコンテンツキーを配布
する場合に利用可能である。具体例として、図３に点線
で示すグループ内のデバイス０，１，２，３がある記録
媒体を用いており、新たな共通のコンテンツキーＫ
（ｔ）ｃｏｎが必要であるとする。このとき、デバイス
０，１，２，３の共通のノードキーＫ００を更新したＫ
（ｔ）００を用いて新たな共通の更新コンテンツキー：
Ｋ（ｔ）ｃｏｎを暗号化したデータＥｎｃ（Ｋ（ｔ），
Ｋ（ｔ）ｃｏｎ）を図４（Ｂ）に示すＥＫＢとともに配
布する。この配布により、デバイス４など、その他のグ
ループの機器においては復号されないデータとしての配
布が可能となる。

【００５３】すなわち、デバイス０，１，２はＥＫＢを
処理して得たＫ（ｔ）００を用いて上記暗号文を復号す
れば、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎを得る
ことが可能になる。

【００５４】［ＥＫＢを使用したコンテンツキーの配
布］図５に、ｔ時点でのコンテンツキーＫ（ｔ）ｃｏｎ
を得る処理例として、Ｋ（ｔ）００を用いて新たな共通
のコンテンツキーＫ（ｔ）ｃｏｎを暗号化したデータＥ
ｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）ｃｏｎ）と図４（Ｂ）に
示すＥＫＢとを記録媒体を介して受領したデバイス０の
処理を示す。すなわちＥＫＢによる暗号化メッセージデ
ータをコンテンツキーＫ（ｔ）ｃｏｎとした例である。

【００５５】図５に示すように、デバイス０は、記録媒
体に格納されている世代：t時点のＥＫＢと自分があら
かじめ格納しているノードキーＫ０００を用いて上述し
たと同様のＥＫＢ処理により、ノードキーＫ（ｔ）００
を生成する。さらに、復号した更新ノードキーＫ（ｔ）
００を用いて更新コンテンツキーＫ（ｔ）ｃｏｎを復号
して、後にそれを使用するために自分だけが持つリーフ
キーＫ００００で暗号化して格納する。

【００５６】［ＥＫＢのフォーマット］図６に有効化キ
ーブロック（ＥＫＢ）のフォーマット例を示す。バージ
ョン６０１は、有効化キーブロック（ＥＫＢ）のバージ
ョンを示す識別子である。なお、バージョンは最新のＥ
ＫＢを識別する機能とコンテンツとの対応関係を示す機
能を持つ。デプスは、有効化キーブロック（ＥＫＢ）の
配布先のデバイスに対する階層ツリーの階層数を示す。
データポインタ６０３は、有効化キーブロック（ＥＫ
Ｂ）中のデータ部の位置を示すポインタであり、タグポ
インタ６０４はタグ部の位置、署名ポインタ６０５は署
名の位置を示すポインタである。

【００５７】データ部６０６は、例えば更新するノード
キーを暗号化したデータを格納する。例えば図５に示す
ような更新されたノードキーに関する各暗号化キー等を
格納する。

【００５８】タグ部６０７は、データ部に格納された暗
号化されたノードキー、リーフキーの位置関係を示すタ
グである。このタグの付与ルールを図７を用いて説明す
る。図７では、データとして先に図４（Ａ）で説明した
有効化キーブロック（ＥＫＢ）を送付する例を示してい
る。この時のデータは、図７の表（ｂ）に示すようにな
る。このときの暗号化キーに含まれるトップノードのア
ドレスをトップノードアドレスとする。この場合は、ル
ートキーの更新キーＫ（ｔ）Ｒが含まれているので、ト
ップノードアドレスはＫＲとなる。このとき、例えば最
上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）Ｒ）は、図
７の（ａ）に示す階層ツリーに示す位置にある。ここ
で、次のデータは、Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）
０）であり、ツリー上では前のデータの左下の位置にあ
る。データがある場合は、タグが０、ない場合は１が設
定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝とし
て設定される。最上段のデータＥｎｃ（Ｋ（ｔ）０，Ｋ
（ｔ）Ｒ）の左にはデータがあるので、Ｌタグ＝０、右
にはデータがないので、Ｒタグ＝１となる。以下、すべ
てのデータにタグが設定され、図７（ｃ）に示すデータ
列、およびタグ列が構成される。

【００５９】タグは、データＥｎｃ（Ｋｘｘｘ，Ｋｙｙ
ｙ）がツリー構造のどこに位置しているのかを示すため
に設定されるものである。データ部に格納されるキーデ
ータＥｎｃ（Ｋｘｘｘ，Ｋｙｙｙ）．．．は、単純に暗
号化されたキーの羅列データに過ぎないので、上述した
タグによってデータとして格納された暗号化キーのツリ
ー上の位置を判別可能としたものである。上述したタグ
を用いずに、先の図４で説明した構成のように暗号化デ
ータに対応させたノード・インデックスを用いて、例え
ば、０：Ｅｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）００：Ｅｎｃ（Ｋ（ｔ）００，Ｋ（ｔ）０）０００：Ｅｎｃ（Ｋ（（ｔ）０００，Ｋ（Ｔ）００）．．．のようなデータ構成とすることも可能であるが、このよ
うなインデックスを用いた構成とすると冗長なデータと
なりデータ量が増大し、ネットワークを介する配信等に
おいては好ましくない。これに対し、上述したタグをキ
ー位置を示す索引データとして用いることにより、少な
いデータ量でキー位置の判別が可能となる。

【００６０】図６に戻って、ＥＫＢフォーマットについ
てさらに説明する。署名（Signature）は、有効化キー
ブロック（ＥＫＢ）を発行した例えば鍵管理センタ、コ
ンテンツロバイダ、決済機関等が実行する電子署名であ
る。ＥＫＢを受領したデバイスは署名検証によって正当
な有効化キーブロック（ＥＫＢ）発行者が発行した有効
化キーブロック（ＥＫＢ）であることを確認する。

【００６１】［ＥＫＢを使用したコンテンツキーおよび
コンテンツの配信］上述の例では、コンテンツキーのみ
をＥＫＢとともに送付する例について説明したが、コン
テンツキーで暗号化したコンテンツと、コンテンツキー
暗号キーで暗号化したコンテンツキーと、ＥＫＢによっ
て暗号化したコンテンツキー暗号キーを併せて送付する
構成について以下説明する。

【００６２】図８にこのデータ構成を示す。図８（ａ）
に示す構成において、Ｅｎｃ（Ｋｃｏｎ，ｃｏｎｔｅｎ
ｔ）８０１は、コンテンツ（Content）をコンテンツキ
ー（Ｋｃｏｎ）で暗号化したデータであり、Ｅｎｃ（Ｋ
ＥＫ，Ｋｃｏｎ）８０２は、コンテンツキー（Ｋｃｏ
ｎ）をコンテンツキー暗号キー（ＫＥＫ：Key Encrypti
on Key）で暗号化したデータであり、Ｅｎｃ（ＥＫＢ，
ＫＥＫ）８０３は、コンテンツキー暗号キーＫＥＫを有
効化キーブロック（ＥＫＢ）によって暗号化したデータ
であることを示す。

【００６３】ここで、コンテンツキー暗号キーＫＥＫ
は、図３で示すノードキー（Ｋ０００，Ｋ００…）、あ
るいはルートキー（ＫＲ）自体であってもよく、またノ
ードキー（Ｋ０００，Ｋ００…）、あるいはルートキー
（ＫＲ）によって暗号化されたキーであってもよい。

【００６４】図８（ｂ）は、複数のコンテンツがメディ
アに記録され、それぞれが同じＥｎｃ（ＥＫＢ，ＫＥ
Ｋ）８０５を利用している場合の構成例を示す、このよ
うな構成においては、各データに同じＥｎｃ（ＥＫＢ，
ＫＥＫ）を付加することなく、Ｅｎｃ（ＥＫＢ，ＫＥ
Ｋ）にリンクするリンク先を示すデータを各データに付
加する構成とすることができる。

【００６５】図９にコンテンツキー暗号キーＫＥＫを、
図３に示すノードキーＫ００を更新した更新ノードキー
Ｋ（ｔ）００として構成した場合の例を示す。この場
合、図３の点線枠で囲んだグループにおいてデバイス３
が、例えば鍵の漏洩によりリボーク（排除）されている
として、他のグループのメンバ、すなわち、デバイス
０，１，２に対して図９に示す（ａ）有効化キーブロッ
ク（ＥＫＢ）と、（ｂ）コンテンツキー（Ｋｃｏｎ）を
コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）で暗
号化したデータと、（ｃ）コンテンツ（content）をコ
ンテンツキー（Ｋｃｏｎ）で暗号化したデータとを配信
することにより、デバイス０，１，２はコンテンツを得
ることができる。

【００６６】図９の右側には、デバイス０における復号
手順を示してある。デバイス０は、まず、受領した有効
化キーブロックから自身の保有するリーフキーＫ０００
を用いた復号処理により、コンテンツキー暗号キー（Ｋ
ＥＫ＝Ｋ（ｔ）００）を取得する。次に、Ｋ（ｔ）００
による復号によりコンテンツキーＫｃｏｎを取得し、さ
らにコンテンツキーＫｃｏｎによりコンテンツの復号を
行なう。これらの処理により、デバイス０はコンテンツ
を利用可能となる。デバイス１，２においても各々異な
る処理手順でＥＫＢを処理することにより、コンテンツ
キー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を取得すること
が可能となり、同様にコンテンツを利用することが可能
となる。

【００６７】図３に示す他のグループのデバイス４，
５，６…は、この同様のデータ（ＥＫＢ）を受信したと
しても、自身の保有するリーフキー、ノードキーを用い
てコンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）００）を
取得することができない。同様にリボークされたデバイ
ス３においても、自身の保有するリーフキー、ノードキ
ーでは、コンテンツキー暗号キー（ＫＥＫ＝Ｋ（ｔ）０
０）を取得することができず、正当な権利を有するデバ
イスのみがコンテンツを復号して利用することが可能と
なる。

【００６８】このように、ＥＫＢを利用したコンテンツ
キーの配送を用いれば、データ量を少なくして、かつ安
全に正当権利者のみが復号可能とした暗号化コンテンツ
を配信することが可能となる。

【００６９】なお、有効化キーブロック（ＥＫＢ）、コ
ンテンツキー、暗号化コンテンツ等は、ネットワークを
介して安全に配信することが可能な構成であるが、有効
化キーブロック（ＥＫＢ）、コンテンツキー、暗号化コ
ンテンツをＤＶＤ、ＣＤ等の記録媒体に格納してユーザ
に提供することも可能である。この場合、記録媒体に格
納された暗号化コンテンツの復号には、同一の記録媒体
に格納された有効化キーブロック（ＥＫＢ）の復号によ
り得られるコンテンツキーを使用するように構成すれ
ば、予め正当権利者のみが保有するリーフキー、ノード
キーによってのみ利用可能な暗号化コンテンツの配布処
理、すなわち利用可能なユーザデバイスを限定したコン
テンツ配布が簡易な構成で実現可能となる。

【００７０】図１０に記録媒体に暗号化コンテンツとと
もに有効化キーブロック（ＥＫＢ）を格納した構成例を
示す。図１０に示す例においては、記録媒体にコンテン
ツＣ１〜Ｃ４が格納され、さらに各格納コンテンツに対
応するの有効化キーブロック（ＥＫＢ）を対応付けたデ
ータが格納され、さらにバージョンＭの有効化キーブロ
ック（ＥＫＢ＿Ｍ）が格納されている。例えばＥＫＢ＿
１はコンテンツＣ１を暗号化したコンテンツキーＫｃｏ
ｎ１を生成するのに使用され、例えばＥＫＢ＿２はコン
テンツＣ２を暗号化したコンテンツキーＫｃｏｎ２を生
成するのに使用される。この例では、バージョンＭの有
効化キーブロック（ＥＫＢ＿Ｍ）が記録媒体に格納され
ており、コンテンツＣ３，Ｃ４は有効化キーブロック
（ＥＫＢ＿Ｍ）に対応付けられているので、有効化キー
ブロック（ＥＫＢ＿Ｍ）の復号によりコンテンツＣ３，
Ｃ４のコンテンツキーを取得することができる。ＥＫＢ
＿１、ＥＫＢ＿２はディスクに格納されていないので、
新たな提供手段、例えばネットワーク配信、あるいは記
録媒体による配信によってそれぞれのコンテンツキーを
復号するために必要なＥＫＢ＿１，ＥＫＢ＿２を取得す
ることが必要となる。

【００７１】［階層ツリー構造のカテゴリー分類］暗号
鍵をルートキー、ノードキー、リーフキー等、図３の階
層ツリー構造として構成し、コンテンツキー、認証キ
ー、ＩＣＶ生成キー、あるいはプログラムコード、デー
タ等を有効化キーブロック（ＥＫＢ）とともに暗号化し
て配信する構成について説明してきたが、ノードキー等
を定義している階層ツリー構造を各デバイスのカテゴリ
ー毎に分類して効率的なキー更新処理、暗号化キー配
信、データ配信を実行する構成について、以下説明す
る。

【００７２】図１１に階層ツリー構造のカテゴリーの分
類の一例を示す。図１１において、階層ツリー構造の最
上段には、ルートキーＫｒｏｏｔ１１０１が設定され、
以下の中間段にはノードキー１１０２が設定され、最下
段には、リーフキー１１０３が設定される。各デバイス
は個々のリーフキーと、リーフキーからルートキーに至
る一連のノードキー、ルートキーを保有する。

【００７３】ここで、一例として最上段から第Ｍ段目の
あるノードをカテゴリノード１１０４として設定する。
すなわち第Ｍ段目のノードの各々を特定カテゴリのデバ
イス設定ノードとする。第Ｍ段の１つのノードを頂点と
して以下、Ｍ＋１段以下のノード、リーフは、そのカテ
ゴリに含まれるデバイスに関するノードおよびリーフと
する。

【００７４】例えば図１１の第Ｍ段目の１つのノード１
１０５にはカテゴリ［メモリステッイク（商標）］が設
定され、このノード以下に連なるノード、リーフはメモ
リステッイクを使用した様々なデバイスを含むカテゴリ
専用のノードまたはリーフとして設定される。すなわ
ち、ノード１１０５以下を、メモリスティックのカテゴ
リに定義されるデバイスの関連ノード、およびリーフの
集合として定義する。

【００７５】さらに、Ｍ段から数段分下位の段をサブカ
テゴリノード１１０６として設定することができる。例
えば図に示すようにカテゴリ［メモリスティック］ノー
ド１１０５の２段下のノードに、メモリスティックを使
用したデバイスのカテゴリに含まれるサブカテゴリノー
ドとして、［再生専用器］のノードを設定する。さら
に、サブカテゴリノードである再生専用器のノード１１
０６以下に、再生専用器のカテゴリに含まれる音楽再生
機能付き電話のノード１１０７が設定され、さらにその
下位に、音楽再生機能付き電話のカテゴリに含まれる
［ＰＨＳ］ノード１１０８と［携帯電話］ノード１１０
９を設定することができる。

【００７６】さらに、カテゴリ、サブカテゴリは、デバ
イスの種類のみならず、例えばあるメーカー、コンテン
ツプロバイダ、決済機関等が独自に管理するノード、す
なわち処理単位、管轄単位、あるいは提供サービス単位
等、任意の単位（これらを総称して以下、エンティティ
と呼ぶ）で設定することが可能である。例えば１つのカ
テゴリノードをゲーム機器メーカーの販売するゲーム機
器ＸＹＺ専用の頂点ノードとして設定すれば、メーカー
の販売するゲーム機器ＸＹＺにその頂点ノード以下の下
段のノードキー、リーフキーを格納して販売することが
可能となり、その後、暗号化コンテンツの配信、あるい
は各種キーの配信、更新処理を、その頂点ノードキー以
下のノードキー、リーフキーによって構成される有効化
キーブロック（ＥＫＢ）を生成して配信し、頂点ノード
以下のデバイスに対してのみ利用可能なデータが配信可
能となる。

【００７７】このように、１つのノードを頂点としし
て、以下のノードをその頂点ノードに定義されたカテゴ
リ、あるいはサブカテゴリの関連ノードとして設定する
構成とすることにより、カテゴリ段、あるいはサブカテ
ゴリ段の１つの頂点ノードを管理するメーカー、コンテ
ンツプロバイダ等がそのノードを頂点とする有効化キー
ブロック（ＥＫＢ）を独自に生成して、頂点ノード以下
に属するデバイスに配信する構成が可能となり、頂点ノ
ードに属さない他のカテゴリのノードに属するデバイス
には全く影響を及ぼさずにキー更新を実行することがで
きる。

【００７８】［簡略ＥＫＢによるキー配信構成］先に説
明した例えば図３のツリー構成において、キー、例えば
コンテンツキーを所定デバイス（リーフ）宛に送付する
場合、キー配布先デバイスの所有しているリーフキー、
ノードキーを用いて復号可能な有効化キーブロック（Ｅ
ＫＢ）を生成して提供する。例えば図１２（ａ）に示す
ツリー構成において、リーフを構成するデバイスａ，
ｇ，ｊに対してキー、例えばコンテンツキーを送信する
場合、ａ，ｇ，ｊの各ノードにおいて復号可能な有効化
キーブロック（ＥＫＢ）を生成して配信する。

【００７９】例えば更新ルートキーＫ（ｔ）ｒｏｏｔで
コンテンツキーＫ（ｔ）ｃｏｎを暗号化処理し、ＥＫＢ
とともに配信する場合を考える。この場合、デバイス
ａ，ｇ，ｊは、それぞれが図１２（ｂ）に示すリーフお
よびノードキーを用いて、ＥＫＢの処理を実行してＫ
（ｔ）ｒｏｏｔを取得し、取得した更新ルートキーＫ
（ｔ）ｒｏｏｔによってコンテンツキーＫ（ｔ）ｃｏｎ
の復号処理を実行してコンテンツキーを得る。

【００８０】この場合に提供される有効化キーブロック
（ＥＫＢ）の構成は、図１３に示すようになる。図１３
に示す有効化キーブロック（ＥＫＢ）は、先の図６で説
明した有効化キーブロック（ＥＫＢ）のフォーマットに
したがって構成されたものであり、データ（暗号化キ
ー）と対応するタグとを持つ。タグは、先に図７を用い
て説明したように左（Ｌ）、右（Ｒ）、それぞれの方向
にデータがあれば０、無ければ１を示している。

【００８１】有効化キーブロック（ＥＫＢ）を受領した
デバイスは、有効化キーブロック（ＥＫＢ）の暗号化キ
ーとタグに基づいて、順次暗号化キーの復号処理を実行
して上位ノードの更新キーを取得していく。図１３に示
すように、有効化キーブロック（ＥＫＢ）は、ルートか
らリーフまでの段数（デプス）が多いほど、そのデータ
量は増加していく。段数（デプス）は、デバイス（リー
フ）数に応じて増大するものであり、キーの配信先とな
るデバイス数が多い場合は、ＥＫＢのデータ量がさらに
増大することになる。

【００８２】このような有効化キーブロック（ＥＫＢ）
のデータ量の削減を可能とした構成について説明する。
図１４は、有効化キーブロック（ＥＫＢ）をキー配信デ
バイスに応じて簡略化して構成した例を示すものであ
る。

【００８３】図１３と同様、リーフを構成するデバイス
ａ，ｇ，ｊに対してキー、例えばコンテンツキーを送信
する場合を想定する。図１４の（ａ）に示すように、キ
ー配信デバイスによってのみ構成されるツリーを構築す
る。この場合、図１２（ｂ）に示す構成に基づいて新た
なツリー構成として図１４（ｂ）のツリー構成が構築さ
れる。ＫｒｏｏｔからＫｊまでは全く分岐がなく１つの
枝のみが存在すればよく、ＫｒｏｏｔからＫａおよびＫ
ｇに至るためには、Ｋ０に分岐点を構成するのみで、２
分岐構成の図１４（ａ）のツリーが構築される。

【００８４】図１４（ａ）に示すように、ノードとして
Ｋ０のみを持つ簡略化したツリーが生成される。更新キ
ー配信のための有効化キーブロック（ＥＫＢ）は、これ
らの簡略ツリーに基づいて生成する。図１４（ａ）に示
すツリーは、有効化キーブロック（ＥＫＢ）を復号可能
な末端ノードまたはリーフを最下段とした２分岐型ツリ
ーを構成するパスを選択して不要ノードを省略すること
により再構築される再構築階層ツリーである。更新キー
配信のための有効化キーブロック（ＥＫＢ）は、この再
構築階層ツリーのノードまたはリーフに対応するキーの
みに基づいて構成される。

【００８５】先の図１３で説明した有効化キーブロック
（ＥＫＢ）は、各リーフａ，ｇ，ｊからＫｒｏｏｔに至
るまでのすべてのキーを暗号化したデータを格納してい
たが、簡略化ＥＫＢは、簡略化したツリーを構成するノ
ードについてのみの暗号化データを格納する。図１４
（ｂ）に示すようにタグは３ビット構成を有する。第１
および第２ビットは、図１３の例と、同様の意味を持
ち、左（Ｌ）、右（Ｒ）、それぞれの方向にデータがあ
れば０、無ければ１を示す。第３番目のビットは、ＥＫ
Ｂ内に暗号化キーが格納されているか否かを示すための
ビットであり、データが格納されている場合は１、デー
タが無い場合は、０として設定される。

【００８６】データ通信網、あるいは記憶媒体に格納さ
れてデバイス（リーフ）に提供される有効化キーブロッ
ク（ＥＫＢ）は、図１４（ｂ）に示すように、図１３に
示す構成に比較すると、データ量が大幅に削減されたも
のとなる。図１４に示す有効化キーブロック（ＥＫＢ）
を受領した各デバイスは、タグの第３ビットに１が格納
された部分のデータのみを順次復号することにより、所
定の暗号化キーの復号を実現することができる。例えば
デバイスａは、暗号化データＥｎｃ（Ｋａ，Ｋ（ｔ）
０）をリーフキーＫａで復号して、ノードキーＫ（ｔ）
０を取得して、ノードキーＫ（ｔ）０によって暗号化デ
ータＥｎｃ（Ｋ（ｔ）０，Ｋ（ｔ）ｒｏｏｔ）を復号し
てＫ（ｔ）ｒｏｏｔを取得する。デバイスｊは、暗号化
データＥｎｃ（Ｋｊ，Ｋ（ｔ）ｒｏｏｔ）をリーフキー
Ｋｊで復号して、Ｋ（ｔ）ｒｏｏｔを取得する。

【００８７】このように、配信先のデバイスによっての
み構成される簡略化した新たなツリー構成を構築して、
構築されたツリーを構成するリーフおよびノードのキー
のみを用いて有効化キーブロック（ＥＫＢ）を生成する
ことにより、少ないデータ量の有効化キーブロック（Ｅ
ＫＢ）を生成することが可能となり、有効化キーブロッ
ク（ＥＫＢ）のデータ配信が効率的に実行可能となる。

【００８８】なお、簡略化した階層ツリー構成は、後段
で説明するエンティテイ単位のＥＫＢ管理構成において
特に有効に活用可能である。エンティテイは、キー配信
構成としてのツリー構成を構成するノードあるいはリー
フから選択した複数のノードあるいはリーフの集合体ブ
ロックである。エンティテイは、デバイスの種類に応じ
て設定される集合であったり、あるいはデバイス提供メ
ーカー、コンテンツプロバイダ、決済機関等の管理単位
等、ある共通点を持った処理単位、管轄単位、あるいは
提供サービス単位等、様々な態様の集合として設定され
る。１つのエンティテイには、ある共通のカテゴリに分
類されるデバイスが集まっており、例えば複数のエンテ
ィテイの頂点ノード（サブルート）によって上述したと
同様の簡略化したツリーを再構築してＥＫＢを生成する
ことにより、選択されたエンティテイに属するデバイス
において復号可能な簡略化された有効化キーブロック
（ＥＫＢ）の生成、配信が可能となる。エンティテイ単
位の管理構成については後段で詳細に説明する。

【００８９】なお、このような有効化キーブロック（Ｅ
ＫＢ）は、光ディスク、ＤＶＤ等の情報記録媒体に格納
した構成とすることが可能である。例えば、上述の暗号
化キーデータによって構成されるデータ部と、暗号化キ
ーデータの階層ツリー構造における位置識別データとし
てのタグ部とを含む有効化キーブロック（ＥＫＢ）にさ
らに、更新ノードキーによって暗号化したコンテンツ等
のメッセージデータとを格納した情報記録媒体を各デバ
イスに提供する構成が可能である。デバイスは有効化キ
ーブロック（ＥＫＢ）に含まれる暗号化キーデータをタ
グ部の識別データにしたがって順次抽出して復号し、コ
ンテンツの復号に必要なキーを取得してコンテンツの利
用を行なうことが可能となる。もちろん、有効化キーブ
ロック（ＥＫＢ）をインターネット等のネットワークを
介して配信する構成としてもよい。

【００９０】［暗号処理機能を有する記憶装置とデータ
処理装置間のデータ移動］次に、上述した階層ツリー構
成を適用した有効化キーブロック（ＥＫＢ）によって配
信される暗号処理キーを適用した処理構成について、暗
号処理機能を有する記憶装置、例えばメモリスティック
（商標）等のメモリカードと、データ再生装置間におけ
るデータ移動処理を中心として説明する。

【００９１】図１５は、相互にコンテンツデータの移動
を実行可能な再生装置と暗号処理機能を有するメモリカ
ード等の記憶装置の詳細構成を示したブロック図であ
る。

【００９２】図１５に示すように、記憶装置３００は、
例えば、主制御モジュール３１、通信インターフェイス
３２、制御モジュール３３、フラッシュメモリ３４およ
びフラッシュメモリ管理モジュール３５を有する。以
下、各モジュールについて説明する。

【００９３】〔制御モジュール３３〕図１５に示すよう
に、制御モジュール３３は、例えば、乱数発生ユニット
５０、記憶ユニット５１、鍵生成／演算ユニット５２、
相互認証ユニット５３、暗号化／復号ユニット５４およ
び制御ユニット５５を有する。制御モジュール３３は、
シングルチップの暗号処理専用の集積回路であり、多層
構造を有し、内部のメモリセルはアルミニウム層などの
ダミー層に挟まれている。また、制御モジュール３３
は、動作電圧または動作周波数の幅が狭く、外部から不
正にデータを読み出せないように耐タンパー性を有して
いる。乱数発生ユニット５０は、乱数発生指示を受ける
と、６４ビット（８バイト）の乱数を発生する。

【００９４】記憶ユニット５１は、例えば、ＥＥＰＲＯ
Ｍ(Electrically Erasable Programmable Read Only Me
mory) などの不揮発性メモリであり、認証処理に必要な
鍵データなどの種々のデータを記憶している。図１６
は、記憶ユニット５１に記憶されているデータを説明す
るための図である。図１６に示すように、記憶ユニット
５１は、認証鍵データＩＫ0〜ＩＫ31、装置識別データ
ＩＤmおよび記憶用鍵データＫｓｔｍを記憶している。

【００９５】認証鍵データＩＫ0〜ＩＫ31は、記憶装置
３００が再生装置２００との間で相互認証を行う際に用
いられる鍵データであり、後述するように相互認証を行
う度に認証鍵データＩＫ0〜ＩＫ31のうち一の認証鍵デ
ータがランダムに選択される。なお、認証鍵データＩＫ
0〜ＩＫ31および記憶用鍵データＫｓｔｍは、記憶装置
３００の外部から読めないようになっている。装置識別
データＩＤmは、記憶装置３００に対してユニークに付
けられた識別データであり、後述するように、記憶装置
３００が再生装置２００との間で相互認証を行う際に読
み出されて再生装置２００に出力される。記憶用鍵デー
タＫｓｔｍは、後述するように、コンテンツの暗号化に
用いられるコンテンツ鍵データＣＫを暗号化してフラッ
シュメモリ３４に記憶する際に用いられる。

【００９６】鍵生成／演算ユニット５２は、例えば、Ｉ
ＳＯ／ＩＥＣ９７９７のＭＡＣ(Message Authenticatio
n Code) 演算などの種々の演算を行って鍵データを生成
する。このとき、ＭＡＣ演算には、例えば、"Block cip
her Algorithm"としてＦＩＰＳＰＵＢ４６−２に規定さ
れるＤＥＳ(Data Encryption Standard)が用いられる。
ＭＡＣ演算は、任意の長さのデータを固定の長さに圧縮
する一方向性ハッシュ関数演算であり、関数値が秘密鍵
に依存して定まる。

【００９７】相互認証ユニット５３は、再生装置２００
からオーディオデータを入力してフラッシュメモリ３４
に書き込む動作を行うのに先立って、再生装置２００と
の間で相互認証処理を行う。また、相互認証ユニット５
３は、フラッシュメモリ３４からオーディオデータを読
み出して再生装置２００に出力する動作を行うのに先立
って、再生装置２００との間で相互認証処理を行う。ま
た、相互認証ユニット５３は、相互認証処理において、
前述したＭＡＣ演算を行う。当該相互認証処理では、記
憶ユニット５１に記憶されているデータが用いられる。

【００９８】暗号化／復号ユニット５４は、ＤＥＳ、Ｉ
ＤＥＡ、ＭＩＳＴＹなどのブロック暗号アルゴリズムで
の暗号化を行う。使用するモードは、ＦＩＰＳＰＵＢ
８１”ＤＥＳＭＯＤＥＳＯＦＯＰＥＲＡＴＩＯ
Ｎ”に規定されているようなＥＣＢ(Electronic Code B
ook)モードおよびＣＢＣ(Cipher Block Chaining) モー
ドである。また、暗号化／復号ユニット５４は、ＤＥ
Ｓ、ＩＤＥＡ、ＭＩＳＴＹなどのブロック復号アルゴリ
ズムでの復号を行う。使用するモードは、上記ＥＣＢモ
ードおよびＣＢＣモードである。当該ＥＣＢモードおよ
びＣＢＣモードのブロック暗号化／復号では、指定され
た鍵データを用いて指定されたデータを暗号化／復号す
る。制御ユニット５５は、乱数発生ユニット５０、記憶
ユニット５１、鍵生成／演算ユニット５２、相互認証ユ
ニット５３および暗号化／復号ユニット５４の処理を統
括して制御する。

【００９９】〔フラッシュメモリ３４〕フラッシュメモ
リ３４は、例えば、３２Ｍバイトの記憶容量を有する。
フラッシュメモリ３４には、相互認証ユニット５３によ
る再生装置２００と記憶装置３００との間の相互認証処
理によって双方が正当な装置であると認められたとき
に、再生装置２００から入力したオーディオデータある
いは画像データ等、各種データが書き込まれる。また、
フラッシュメモリ３４からは、相互認証ユニット５３に
よる再生装置２００と記憶装置３００との間の相互認証
処理によって正当な相手であると認められたときに、オ
ーディオデータ、画像データ等が読み出されて再生装置
２００に出力される。

【０１００】以下、フラッシュメモリ３４に記憶される
データおよびそのフォーマットについて説明する。図１
７は、フラッシュメモリ３４に記憶されるデータを説明
するための図である。図１７に示すように、フラッシュ
メモリ３４には、例えば、再生管理ファイル、複数のト
ラックデータ（再生データ）ファイルが記憶されてい
る。ここで、再生管理ファイルはトラックデータファイ
ルの再生を管理する管理データを有し、トラックデータ
ファイルはそれぞれ対応するトラックデータ（オーディ
オデータ）を有している。なお、本実施形態では、トラ
ックデータは、例えば、１曲分のオーディオデータを意
味する。以下、フラッシュメモリ３４に記憶されるデー
タをオーディオデータとした場合の例について説明す
る。

【０１０１】図１８は、再生管理ファイルの構成を示
し、図１９が一つ（１曲）のＡＴＲＡＣ（登録商標）３
データファイルの構成を示す。再生管理ファイルは、１
６ＫＢ固定長のファイルである。ＡＴＲＡＣ３データフ
ァイルは、曲単位でもって、先頭の属性ヘッダと、それ
に続く実際の暗号化された音楽データとからなる。属性
ヘッダも１６ＫＢ固定長とされ、再生管理ファイルと類
似した構成を有する。

【０１０２】再生管理ファイルは、ヘッダ、１バイトコ
ードのメモリカードの名前ＮＭ１−Ｓ、２バイトコード
のメモリカードの名前ＮＭ２−Ｓ、曲順の再生テーブル
ＴＲＫＴＢＬ、メモリカード全体の付加情報ＩＮＦ−Ｓ
とからなる。データファイルの先頭の属性ヘッダは、ヘ
ッダ、１バイトコードの曲名ＮＭ１、２バイトコードの
曲名ＮＭ２、トラックのキー情報等のトラック情報ＴＲ
ＫＩＮＦ、パーツ情報ＰＲＴＩＮＦと、トラックの付加
情報ＩＮＦとからなる。ヘッダには、総パーツ数、名前
の属性、付加情報のサイズの情報等が含まれる。

【０１０３】属性ヘッダに対してＡＴＲＡＣ３の音楽デ
ータが続く。音楽データは、１６ＫＢのブロック毎に区
切られ、各ブロックの先頭にヘッダが付加されている。
ヘッダには、暗号を復号するための初期値が含まれる。
なお、暗号化の処理を受けるのは、ＡＴＲＡＣ３データ
ファイル中の音楽データ等のコンテンツデータのみであ
って、それ以外の再生管理ファイル、ヘッダ等のデータ
は、暗号化されない。

【０１０４】図２０は、再生管理ファイルＰＢＬＩＳＴ
の詳細なデータ構成を示す。再生管理ファイルＰＢＬＩ
ＳＴは、１クラスタ（１ブロック＝１６ＫＢ）のサイズ
である。図２０Ａに示すヘッダは、３２バイトから成
る。図２０Ｂに示すヘッダ以外の部分は、メモリカード
全体に対する名前ＮＭ１−Ｓ（２５６バイト）、名前Ｎ
Ｍ２−Ｓ（５１２バイト）、暗号化されたコンテンツキ
ー（ＣＯＮＴＥＮＴＳＫＥＹ）、ＭＡＣ、Ｓ−ＹＭＤｈ
ｍｓと、再生順番を管理するテーブルＴＲＫＴＢＬ（８
００バイト）、メモリカード全体に対する付加情報ＩＮ
Ｆ−Ｓ（１４７２０バイト）および最後にヘッダ中の情
報の一部が再度記録されている。これらの異なる種類の
データ群のそれぞれの先頭は、再生管理ファイル内で所
定の位置となるように規定されている。

【０１０５】再生管理ファイルは、図２０Ａに示す（０
ｘ００００）および（０ｘ００１０）で表される先頭か
ら３２バイトがヘッダである。なお、ファイル中で先頭
から１６バイト単位で区切られた単位をスロットと称す
る。ファイルの第１および第２のスロットに配されるヘ
ッダには、下記の意味、機能、値を持つデータが先頭か
ら順に配される。なお、Ｒｅｓｅｒｖｅｄと表記されて
いるデータは、未定義のデータを表している。通常ヌル
（０ｘ００）が書かれるが、何が書かれていてもＲｅｓ
ｅｒｖｅｄのデータが無視される。将来のバージョンで
は、変更がありうる。また、この部分への書き込みは禁
止する。Ｏｐｔｉｏｎと書かれた部分も使用しない場合
は、全てＲｅｓｅｒｖｅｄと同じ扱いとされる。

【０１０６】ＢＬＫＩＤ−ＴＬ０（４バイト）意味：BLOCKID FILE ID 機能：再生管理ファイルの先頭であることを識別するた
めの値値：固定値＝”ＴＬ＝０”（例えば０ｘ５４４Ｃ２Ｄ３
０）ＭＣｏｄｅ（２バイト）意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード値：上位１０ビット（メーカーコード）下位６ビット
（機種コード）ＲＥＶＩＳＩＯＮ（４バイト）意味：ＰＢＬＩＳＴの書き換え回数機能：再生管理ファイルを書き換える度にインクリメン
ト値：０より始まり＋１づつ増加する

【０１０７】ＳＮ１Ｃ＋Ｌ（２バイト）意味：ＮＭ１−Ｓ領域に書かれるメモリカードの名前
（１バイト）の属性を表す機能：使用する文字コードと言語コードを各１バイトで
表す値：文字コード（Ｃ）は上位１バイトで下記のように文
字を区別する 00: 文字コードは設定しない。単なる２進数として扱う
こと 01: ASCII(American Standard Code for Information I
nterchange) 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 Voic
e)。

【０１０８】言語コード（Ｌ）は下位１バイトで下記の
ように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 Se
rial Copy ManagementSystem)におけるコピー許可回数機能：コピー１回か、コピーフリーかの区別を拡張し、
回数で指定する。コピー第１世代の場合にのみ有効であ
り、コピーごとに減算する値：００：コピー禁止、０１から０ｘＦＥ：回数、０ｘ
ＦＦ：回数無制限。

【０１５８】上述したトラック情報領域ＴＲＫＩＮＦに
続いて、０ｘ０３７０から始まる２４バイトのデータを
パーツ管理用のパーツ情報領域ＰＲＴＩＮＦと呼び、１
つのトラックを複数のパーツで構成する場合に、時間軸
の順番にＰＲＴＩＮＦを並べていく。図２６にＰＲＴＩ
ＮＦの部分を示す。ＰＲＴＩＮＦ内のデータについて、
配置順序に従って以下に説明する。

【０１５９】ＰＲＴＳＩＺＥ（４バイト）意味：パーツサイズ機能：パーツの大きさを表す。クラスタ：２バイト（最
上位）、開始ＳＵ：１バイト（上位）、終了ＳＵ：１バ
イト（最下位）値：クラスタ：１から０ｘ１Ｆ４０（８０００）、開始
ＳＵ：０から０ｘＡ０（１６０）、終了ＳＵ：０から０
ｘＡ０（１６０）（但し、ＳＵの数え方は、０，１，
２，と０から開始する）

【０１６０】ＰＲＴＫＥＹ（８バイト）意味：パーツを暗号化するための値機能：初期値＝０、編集時は編集の規則に従うこと値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ

【０１６１】ＣＯＮＮＵＭ０（４バイト）意味：最初に作られたコンテンツ累積番号キー機能：コンテンツをユニークにするためのＩＤの役割値：コンテンツ累積番号初期値キーと同じ値とされる。

【０１６２】図２１に戻る。ＡＴＲＡＣ３データファイ
ルの属性ヘッダ中には、図２１に示すように、付加情報
ＩＮＦが含まれる。ＩＮＦは、トラックに関する付加情
報データであり、ヘッダを伴った可変長の付加情報デー
タ。複数の異なる付加情報が並べられることがある。そ
れぞれにＩＤとデータサイズが付加されている。個々の
ヘッダを含む付加情報データは、最小１６バイト以上で
４バイトの整数倍の単位である。

【０１６３】上述した属性ヘッダに対して、ＡＴＲＡＣ
３データファイルの各ブロックのデータが続く。図２７
に示すように、ブロック毎にヘッダが付加される。各ブ
ロックのデータについて以下に説明する。

【０１６４】ＢＬＫＩＤ−Ａ３Ｄ（４バイト）意味：BLOCKID FILE ID 機能：ＡＴＲＡＣ３データの先頭であることを識別する
ための値値：固定値＝”Ａ３Ｄ”（例えば０ｘ４１３３４４２
０）

【０１６５】ＭＣｏｄｅ（２バイト）意味：MAKER CODE 機能：記録した機器の、メーカー、モデルを識別するコ
ード値：上位１０ビット（メーカーコード）下位６ビット
（機種コード）

【０１６６】ＣＯＮＮＵＭ０（４バイト）意味：最初に作られたコンテンツ累積番号機能：コンテンツをユニークにするためのＩＤの役割、
編集されても値は変化させない値：コンテンツ累積番号初期値キーと同じ値とされる

【０１６７】ＢＬＯＣＫＳＥＲＩＡＬ（４バイト）意味：トラック毎に付けられた連続番号機能：ブロックの先頭は０から始まり次のブロックは＋
１づつインクリメント編集されても値を変化させない値：０より始まり０ｘＦＦＦＦＦＦＦＦまで

【０１６８】ＢＬＯＣＫ−ＳＥＥＤ（８バイト）意味：１ブロックを暗号化するための１つの鍵機能：ブロックの先頭は、記録機器のセキュリティブロ
ックで乱数を生成、続くブロックは、＋１インクリメン
トされた値、この値が失われると、１ブロックに相当す
る約１秒間、音が出せないために、ヘッダとブロック末
尾に同じものが二重に書かれる。編集されても値を変化
させない値：初期は８バイトの乱数

【０１６９】ＩＮＩＴＩＡＬＩＺＡＴＩＯＮＶＥＣＴ
ＯＲ（８バイト）意味：ブロック毎にＡＴＲＡＣ３データを暗号化、復号
化する時に必要な初期値機能：ブロックの先頭は０から始まり、次のブロックは
最後のＳＵの最後の暗号化された８バイトの値。デバイ
ドされたブロックの途中からの場合は開始ＳＵの直前の
最後の８バイトを用いる。編集されても値を変化させな
い値：０から０ｘＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ

【０１７０】ＳＵ−ｎｎｎ意味：サウンドユニットのデータ機能：１０２４サンプルから圧縮されたデータ、圧縮モ
ードにより出力されるバイト数が異なる。編集されても
値を変化させない（一例として、ＳＰモードの時では、
Ｎ＝３８４バイト）値：ＡＴＲＡＣ３のデータ値。

【０１７１】図２１では、Ｎ＝３８４であるので、１ブ
ロックに４２ＳＵが書かれる。また、１ブロックの先頭
の２つのスロット（４バイト）がヘッダとされ、最後の
１スロット（２バイト）にＢＬＫＩＤ−Ａ３Ｄ、ＭＣｏ
ｄｅ、ＣＯＮＮＵＭ０、ＢＬＯＣＫＳＥＲＩＡＬが二
重に書かれる。従って、１ブロックの余りの領域Ｍバイ
トは、（１６，３８４−３８４×４２−１６×３＝２０
８（バイト）となる。この中に上述したように、８バイ
トのＢＬＯＣＫＳＥＥＤが二重に記録される。

【０１７２】ここで、フラッシュメモリ３４に記憶され
ているデータは、後述するように例えば、ＡＴＲＡＣ３
方式で圧縮されている。圧縮の単位がサウンドユニット
ＳＵである。従って、記憶装置３００から再生装置２０
０にデータを読み出す場合には、読み出しの最小単位は
当該サウンドユニットＳＵとなる。オーディオデータの
圧縮方式は、ＡＴＲＡＣ３などのＡＴＲＡＣ方式以外の
ＣＯＤＥＣ方式でもよい。

【０１７３】ブロックシードデータＢＳは、各ブロック
毎に例えば乱数を発生して生成されたデータである。

【０１７４】〔フラッシュメモリ管理モジュール３５〕
フラッシュメモリ管理モジュール３５は、フラッシュメ
モリ３４へのデータの書き込み、フラッシュメモリ３４
からのデータの読み出しなどの制御を行う。

【０１７５】図１５に示す再生装置２００の構成につい
て説明する。再生装置２００は、例えば、主制御モジュ
ール４１、通信インターフェイス４２、制御モジュール
４３、編集モジュール４４、圧縮／伸長モジュール４
５、スピーカ４６、Ｄ／Ａ変換器４７およびＡ／Ｄ変換
器４８を有する。

【０１７６】〔主制御モジュール４１〕主制御モジュー
ル４１は、再生装置２００の処理を統括的に制御する。

【０１７７】〔制御モジュール４３〕図１５に示すよう
に、制御モジュール４３は、例えば、乱数発生ユニット
６０、記憶ユニット６１、鍵生成／鍵演算ユニット６
２、相互認証ユニット６３、暗号化／復号ユニット６４
および制御ユニット６５を有する。制御モジュール４３
は、制御モジュール３３と同様に、シングルチップの暗
号処理専用の集積回路であり、多層構造を有し、内部の
メモリセルはアルミニウム層などのダミー層に挟まれて
いる。また、制御モジュール４３は、動作電圧または動
作周波数の幅が狭く、外部から不正にデータを読み出せ
ないように耐タンパー性を有している。乱数発生ユニッ
ト６０は、乱数発生指示を受けると、６４ビット（８バ
イト）の乱数を発生する。記憶ユニット６１は、認証処
理に必要な種々のデータを記憶している。

【０１７８】鍵生成／鍵演算ユニット６２は、例えば、
ＩＳＯ／ＩＥＣ９７９７のＭＡＣ演算方式を用いた演算
などの種々の演算を行って鍵データを生成する。このと
き、"Block cipher Algorithm"としてＦＩＰＳＰＵＢ
４６−２に規定されるＤＥＳが用いられる。

【０１７９】相互認証ユニット６３は、例えば、コンピ
ュータから入力したオーディオデータを記憶装置３００
に出力する動作を行うのに先立って、記憶装置３００と
の間で相互認証処理を行う。また、相互認証ユニット６
３は、記憶装置３００からオーディオデータを入力する
動作を行うのに先立って、記憶装置３００との間で相互
認証処理を行う。また、相互認証ユニット６３は、相互
認証処理において、前述したＭＡＣ演算を行う。当該相
互認証処理では、記憶ユニット６１に記憶されているデ
ータが用いられる。なお、相互認証ユニット６３は、必
要に応じて、例えば、パーソナルコンピュータ（ＰＣ）
１００あるいはネットワーク上のコンピュータとの間で
オーディオデータの入出力を行う動作に先立って、パー
ソナルコンピュータ（ＰＣ）１００あるいはネットワー
ク上のコンピュータとの間で相互認証処理を行う。

【０１８０】暗号化／復号ユニット６４は、前述したよ
うに、ＦＩＰＳＰＵＢ８１に規定されたＥＣＢモード
およびＣＢＣモードを選択的に用いてブロック暗号化を
行う。

【０１８１】暗号化／復号ユニット６４は、ＦＩＰＳ８
１のモードのうち、ＥＣＢモードおよびＣＢＣモードの
復号を選択的に行う。ここで、暗号化／復号ユニット６
４は、ＣＢＣモードにおいて、例えば５６ビットの鍵デ
ータｋを用いて、暗号文を、６４ビットからなる暗号化
ブロックを単位として復号して平文を生成する。

【０１８２】制御ユニット６５は、乱数発生ユニット６
０、記憶ユニット６１、鍵生成／鍵演算ユニット６２、
相互認証ユニット６３および暗号化／復号ユニット６４
の処理を統括的に制御する。

【０１８３】〔編集モジュール４４〕編集モジュール４
４は、例えば、図１６に示すように記憶装置３００のフ
ラッシュメモリ３４内に記憶されたトラックデータファ
イルを、ユーザからの操作指示に基づいて編集して新た
なトラックデータファイルを生成する。

【０１８４】〔圧縮／伸長モジュール４５〕圧縮／伸長
モジュール４５は、例えば、記憶装置３００から入力し
た暗号化されたオーディオデータを復号した後に再生す
る際に、ＡＴＲＡＣ３方式で圧縮されているオーディオ
データを伸長し、当該伸長したオーディオデータをＤ／
Ａ変換器４７に出力する。また、例えば、ＣＤ、ＤＶＤ
あるいはＰＣ１から入力したオーディオデータを、記憶
装置３００に記憶する際に、当該オーディオデータをＡ
ＴＲＡＣ３方式で圧縮する。

【０１８５】〔Ｄ／Ａ変換器４７〕Ｄ／Ａ変換器４７
は、圧縮／伸長モジュール４５から入力したデジタル形
式のオーディオデータをアナログ形式のオーディオデー
タに変換してスピーカ４６に出力する。

【０１８６】〔スピーカ４６〕スピーカ４６は、Ｄ／Ａ
変換器４７から入力したオーディオデータに応じた音響
を出力する。

【０１８７】〔Ａ／Ｄ変換器４８〕Ａ／Ｄ変換器４８
は、例えば、ＣＤプレーヤ７から入力したアナログ形式
のオーディオデータをデジタル形式に変換して圧縮／伸
長モジュール４５に出力する。

【０１８８】〔メモリ４９〕メモリ４９は、例えば、Ｅ
２ＰＲＯＭ（ｅｘ．フラッシュメモリ）であり、前述し
たキー有効化ブロック（ＥＫＢ）、あるいはＥＫＢに基
づいて生成されるデバイスキーブロック（ＤＫＢ）等の
鍵データ、デバイス識別子としてのデバイスＩＤ等が格
納される。

【０１８９】［コンテンツデータの記憶装置に対する格
納処理および再生処理］図１５に示す再生装置２００
と、記憶装置３００との間では、コンテンツデータの移
動、すなわち、再生装置２００から記憶装置３００のフ
ラッシュメモリ３４に対するデータ記録処理が実行さ
れ、さらに、記憶装置３００のフラッシュメモリ３４か
ら再生装置２００に対するデータ再生処理が実行され
る。

【０１９０】このデータ記録および再生処理について、
以下説明する。まず、再生装置２００から記憶装置３０
０のフラッシュメモリ３４に対するデータ記録処理を図
２８のフローを用いて説明する。

【０１９１】再生装置および記憶装置は、データ移動に
先立ち、まずステップＳ２７０１、Ｓ２７０２に示す相
互認証処理を実行する。図２９に、共通鍵暗号方式を用
いた相互認証方法（ISO/IEC 9798-2）を示す。図２９に
おいては、共通鍵暗号方式としてＤＥＳを用いている
が、共通鍵暗号方式であれば他の方式も可能である。図
２９において、まず、Ｂが６４ビットの乱数Ｒｂを生成
し、Ｒｂおよび自己のＩＤであるＩＤ（ｂ）をＡに送信
する。これを受信したＡは、新たに６４ビットの乱数Ｒ
ａを生成し、Ｒａ、Ｒｂ、ＩＤ（ｂ）の順に、ＤＥＳの
ＣＢＣモードで鍵Ｋａｂを用いてデータを暗号化し、Ｂ
に返送する。なお、鍵Ｋａｂは、ＡおよびＢに共通の秘
密鍵としてそれぞれの記録素子内に格納する鍵である。
ＤＥＳのＣＢＣモードを用いた鍵Ｋａｂによる暗号化処
理は、例えばＤＥＳを用いた処理においては、初期値と
Ｒａとを排他的論理和し、ＤＥＳ暗号化部において、鍵
Ｋａｂを用いて暗号化し、暗号文Ｅ１を生成し、続けて
暗号文Ｅ１とＲｂとを排他的論理和し、ＤＥＳ暗号化部
において、鍵Ｋａｂを用いて暗号化し、暗号文Ｅ２を生
成し、さらに、暗号文Ｅ２とＩＤ（ｂ）とを排他的論理
和し、ＤＥＳ暗号化部において、鍵Ｋａｂを用いて暗号
化して生成した暗号文Ｅ３とによって送信データ（Toke
n-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 機能：配信鍵許可情報ファイルを構成するデータの署名
（Ｓｉｇｎａｔｕｒｅ）部分のデータ値：すべての値

【０２３０】上述の説明および図３１によって示される
ように、デバイスに対して提供される配信鍵許可情報フ
ァイルには、その配信鍵許可情報ファイルから取得され
るＫＥＫが適用可能なコンテンツデータであるリンクフ
ァイルを識別するための識別データ［ＬＫＦ］が格納さ
れ、さらに、リンクしているファイル（例えばＡＴＲＡ
ＣＫ３ファイル）数としてのデータ［ＬｉｎｃＣｏｕ
ｎｔ］が格納される。再生装置は、［ＬＫＦ］、［Ｌｉ
ｎｋＣｏｕｎｔ］を参照することにより、その配信鍵
許可情報ファイルから取得されるＫＥＫを適用すべきデ
ータが存在するか否かおよびその数を知ることが可能と
なる。

【０２３１】［リンク情報を用いたデータ復号、再生処
理］上述した配信鍵許可情報ファイルに含まれるリンク
ファイルを識別するための識別データ［ＬＫＦ］、リン
クしているファイル（例えばＡＴＲＡＣＫ３ファイル）
数としてのデータ［ＬｉｎｃＣｏｕｎｔ］を用いて、
効率的にデータの復号、再生を実行する処理態様につい
て、以下説明する。

【０２３２】図３２に記憶装置のデータ格納領域、例え
ば図１５に示す記憶装置３００のフラッシュメモリ３４
に格納されたデータファイル構成例を示す。ここでは、
音楽データ（ＨＩＦＩ）のディレクトリ構成のみを例と
して示しているが、さらに、画像ファイル等のディレク
トリが存在してもよい。

【０２３３】図３２に示す音楽データのディレクトリに
は、再生管理ファイル（ＰＢＬＩＳＴ）、暗号化コンテ
ンツとして複数のＡＴＲＡＣＫ３データファイル（Ａ３
Ｄ）含まれる。さらに、記憶装置には、複数の有効化キ
ーブロックファイル（ＥＫＢｎ）が格納される。ＡＴＲ
ＡＣＫ３データファイル（Ａ３Ｄ）の復号処理に適用す
るコンテンツキーを取得するための有効化キーブロック
ファイル（ＥＫＢｎ）は、ＡＴＲＡＣＫ３データファイ
ル（Ａ３Ｄ）に含まれるポインタによって判別される。
図３２に示すように、１つの有効化キーブロックファイ
ル（ＥＫＢ１）３１０１は複数（３）のＡＴＲＡＣＫ３
データファイル（Ａ３Ｄ）の復号処理に適用される。

【０２３４】この場合、有効化キーブロックファイル
（ＥＫＢ１）３１０１に対応する配信鍵許可情報ファイ
ルの［ＬｉｎｃＣｏｕｎｔ］には３つのコンテンツに
適用されることを示すデータが格納されることになる。

【０２３５】図３２のような複数のコンテンツファイ
ル、複数の有効化キーブロックファイルを格納した記憶
装置であるメモリカードからコンテンツを復号して、再
生する場合の処理フローを図３３に示す。

【０２３６】図３３の処理は、例えば記憶装置としての
メモリカードを再生装置にセットした際、あるいはメモ
リカードを装着した再生装置の電源をＯＮした際に再生
装置が実行する処理である。

【０２３７】まず、ステップＳ３２０１において、再生
装置は、各々のＥＫＢファイルのトラック情報を読み取
り、［ＬｉｎｃＣｏｕｎｔ］をチェックする。さら
に、［ＬｉｎｃＣｏｕｎｔ］のカウント数が多いもの
から順に、予め定められた個数［ｎ］のＥＫＢファイル
を選択する。個数［ｎ］は、再生装置の所定メモリ領
域、すなわちキー暗号化キー：ＫＥＫを格納保持する領
域に格納可能な個数に相当する個数として設定される。

【０２３８】次に、ステップＳ３２０２において、選択
したＥＫＢの処理により、複数［ｎ］のキー暗号化キ
ー：ＫＥＫを取得し、これらを再生装置の鍵格納領域と
して設定されたＲＡＭの所定領域に格納する。

【０２３９】次に、再生装置は、ステップＳ３２０３に
おいて、復号、再生するコンテンツを選択する。さら
に、ステップＳ３２０４において、その選択コンテンツ
の復号に適用するＫＥＫがＲＡＭに格納されているか否
かを判定し、Ｙｅｓの場合は、ステップＳ３２０５に進
み、その対応ＫＥＫに基づいて、Ｅ（ＫＥＫ，Ｋｃｏ
ｎ）を復号してコンテンツキーを取得して、ステップＳ
３２０９で再生、すなわち、取得したコンテンツキーに
よるデータの復号、再生処理を実行する。

【０２４０】ステップＳ３２０４において、選択コンテ
ンツの復号に適用するＫＥＫがＲＡＭに格納されていな
い場合は、ステップＳ３２０６において、ストレージキ
ーで暗号化されたコンテンツキー、すなわち、Ｅ（Ｋｓ
ｔｍ，Ｋｃｏｎ）の有無を判定し、ある場合は、ステッ
プＳ３２０７において、Ｅ（Ｋｓｔｍ，Ｋｃｏｎ）の復
号処理によりコンテンツキーを取得して、ステップＳ３
２０９で再生、すなわち、取得したコンテンツキーによ
るデータの復号、再生処理を実行する。

【０２４１】また、ステップＳ３２０６において、Ｅ
（Ｋｓｔｍ，Ｋｃｏｎ）がないと判定されると、その復
号対象コンテンツに適用すべきＥＫＢを記憶装置から取
得して、取得したＥＫＢの復号処理によりＫＥＫを取得
し、取得したＫＥＫによるＥ（ＫＥＫ，Ｋｃｏｎ）の復
号処理を実行してコンテンツキーを取得して、ステップ
Ｓ３２０９で再生、すなわち、取得したコンテンツキー
によるデータの復号、再生処理を実行する。

【０２４２】このように、再生装置は、予め記憶装置に
格納した複数のキー有効化ブロック（ＥＫＢ）の［Ｌｉ
ｎｃＣｏｕｎｔ］をチェックし、［ＬｉｎｃＣｏｕ
ｎｔ］のカウント数が多いＥＫＢの復号を実行して、キ
ー暗号化キー：ＫＥＫを格納しておく構成とすることに
より、コンテンツ再生処理の際に、高い確率でＲＡＭに
格納したＫＥＫを適用可能となり、効率的なコンテンツ
再生が実行できる。

【０２４３】［キー有効化ブロック（ＥＫＢ）による認
証キー配信］上述の有効化キーブロック（ＥＫＢ）を使
用したキーの配信において、認証処理を実行する際に使
用する認証キーＩＫｎを配信することにより、安全な秘
密鍵として共有する認証キーを提供し、共通鍵方式に従
った認証処理を実行する構成について説明する。

【０２４４】共通鍵暗号方式を用いた相互認証方法（IS
O/IEC 9798-2）は、先に図２９を用いて説明した処理で
あり、データ送受信が実行される前の処理として、双方
の正当性を確認するための処理として実行される。認証
処理においては、データの送受信を行なう、例えば再生
装置と記憶装置は認証キーＫａｂを共有する。この共通
鍵Ｋａｂを上述の有効化キーブロック（ＥＫＢ）を使用
して再生装置に配信する。

【０２４５】図３４および図３５に複数のデバイスに共
通の認証キーＩＫｎを有効化キーブロック（ＥＫＢ）に
よって配信する構成例を示す。図３４はデバイス０，
１，２，３に対して復号可能な認証キーＩＫｎを配信す
る例、図３５はデバイス０，１，２，３中のデバイス３
をリボーク（排除）してデバイス０，１，２に対しての
み復号可能な認証キーを配信する例を示す。

【０２４６】図３４の例では、更新ノードキーＫ（ｔ）
００によって、認証キーＩＫｎを暗号化したデータ
（ｂ）とともに、デバイス０，１，２，３においてそれ
ぞれの有するノードキー、リーフキーを用いて更新され
たノードキーＫ（ｔ）００を復号可能な有効化キーブロ
ック（ＥＫＢ）を生成して配信する。それぞれのデバイ
スは、図３４の右側に示すようにまず、ＥＫＢを処理
（復号）することにより、更新されたノードキーＫ
（ｔ）００を取得し、次に、取得したノードキーＫ
（ｔ）００を用いて暗号化された認証キー：Ｅｎｃ（Ｋ
（ｔ）００，ＩＫｎ）を復号して認証キーＩＫｎを得る
ことが可能となる。

【０２４７】その他のデバイス４，５，６，７…は同一
の有効化キーブロック（ＥＫＢ）を受信しても自身の保
有するノードキー、リーフキーでは、ＥＫＢを処理して
更新されたノードキーＫ（ｔ）００を取得することがで
きないので、安全に正当なデバイスに対してのみ認証キ
ーを送付することができる。

【０２４８】一方、図３５の例は、デバイス３が、例え
ば鍵の漏洩によりリボーク（排除）されているとして、
他のグループのメンバ、すなわち、デバイス０，１，
２，に対してのみ復号可能な有効化キーブロック（ＥＫ
Ｂ）を生成して配信した例である。図３５に示す（ａ）
有効化キーブロック（ＥＫＢ）と、（ｂ）認証キー（Ｉ
Ｋｎ）をノードキー（Ｋ（ｔ）００）で暗号化したデー
タを配信する。

【０２４９】図３５の右側には、復号手順を示してあ
る。デバイス０，１，２は、まず、受領した有効化キー
ブロックから自身の保有するリーフキーまたはノードキ
ーを用いた復号処理により、更新ノードキー（Ｋ（ｔ）
００）を取得する。次に、Ｋ（ｔ）００による復号によ
り認証キーＩＫｎを取得する。

【０２５０】他のグループのデバイス、例えばデバイス
４，５，６…は、この同様のデータ（ＥＫＢ）を受信し
たとしても、自身の保有するリーフキー、ノードキーを
用いて更新ノードキー（Ｋ（ｔ）００）を取得すること
ができない。同様にリボークされたデバイス３において
も、自身の保有するリーフキー、ノードキーでは、更新
ノードキー（Ｋ（ｔ）００）を取得することができず、
正当な権利を有するデバイスのみが認証キーを復号して
利用することが可能となる。

【０２５１】このように、ＥＫＢを利用した認証キーの
配送を用いれば、データ量を少なくして、かつ安全に正
当権利者のみが復号可能とした認証キーを配信すること
が可能となる。また、有効化キーブロック（ＥＫＢ）に
よって暗号化され提供されるＥＫＢ配信認証鍵は、世代
（バージョン）管理がなされ、世代毎の更新処理が実行
され、任意のタイミングでのデバイスのリボーク（排
除）が可能である。

【０２５２】上述したＥＫＢによる認証キーの提供処理
により、リボークされたデバイス（再生装置）では、記
憶装置（例えばメモリカード）との認証処理が成立せ
ず、データの不正な復号が不可能となる。

【０２５３】さらに、ＥＫＢを利用した認証キーの配送
を用いれば、メモリカード以外の記憶媒体、例えば再生
装置に内蔵したハードディスク等の記憶媒体に対するデ
ータ格納、再生処理に対する制御も可能となる。

【０２５４】先の図２８〜３０を用いて説明したよう
に、記憶装置を利用したコンテンツの記録、再生処理に
おいては、相互認証処理が実行され、相互認証処理の成
立を条件として、データの記録および再生が可能とな
る。この認証処理プログラムは、メモリカードのような
相互認証処理が可能な記憶装置との間での処理において
は有効に作用するが、例えば、再生装置がハードディス
ク、ＣＤ−Ｒ等、暗号処理機能を持たない、すなわち相
互認証を実行不可能な記憶媒体に対してデータ格納、デ
ータ再生時には意味をなさないことになる。シカシ、本
発明のシステムでは、このような認証不可能な機器を利
用したデータ格納、あるいはデータ再生処理においても
認証処理プログラムを実行させる構成とする。ハードデ
ィスク、ＣＤ−Ｒ等は相互認証が不可能であるので、仮
想のメモリカード（メモリスティック）を再生装置に構
成し、仮想メモリカードと再生装置間において認証処理
を実行させて、認証成立を条件として、認証機能を持た
ない記憶媒体に対するデータ格納処理、あるいは記憶媒
体からのデータ再生を可能とする。

【０２５５】これらの仮想メモリカードを使用したデー
タ記録、再生処理フローを図３６に示す。まず、再生装
置は、再生装置内の仮想メモリカードとの間で相互認証
処理を実行する。ステップＳ３５０２において、認証成
立したか否かを判定し、成立したことを条件としてステ
ップＳ３５０３に進み、認証機能を持たない記憶媒体、
例えばハードディスク、ＣＤ−Ｒ、ＤＶＤ等を用いたデ
ータ記録、再生処理を実行する。

【０２５６】ステップＳ３５０２において、認証が成立
しなかったと判定された場合は、ステップＳ３５０３の
認証機能を持たない記憶媒体、例えばハードディスク、
ＣＤ−Ｒ、ＤＶＤ等を用いたデータ記録、再生処理が実
行されない。

【０２５７】ここで、仮想メモリカードには、予め、先
の図１６で説明した認証鍵データを格納した構成とし、
再生装置が使用する認証キーを前述したように、キー有
効化ブロックで提供する構成とする。

【０２５８】このように、再生装置の認証キーをキー有
効化ブロック（ＥＫＢ）で提供することにより、正当な
ライセンスを持つデバイス（再生装置）に対してのみ、
仮想メモリカードとの相互認証可能な認証キーを配信す
ることが可能となる。従って、不正な機器、すなわちリ
ボークされた再生装置には、有効な認証キーが配信しな
い処理が可能となる。有効な認証キーが提供されない再
生装置は、相互認証が不成立となり、認証機能を持つメ
モリカードのみならず、認証機能を持たない記憶媒体、
例えばハードディスク、ＣＤ−Ｒ、ＤＶＤ等を用いたデ
ータ記録、再生処理が実行されず、不正な機器によるデ
ータ記録、再生を排除することが可能となる。

【０２５９】すなわち、認証鍵を提供する有効化キーブ
ロック（ＥＫＢ）をキーツリーのリーフを構成するデー
タ処理装置中、正当なライセンスを持つデータ処理装置
においてのみ復号可能で、正当ライセンスを持たない不
正なデータ処理装置においては復号不可能な有効化キー
ブロック（ＥＫＢ）として提供することにより、不正な
データ処理装置における仮想メモリデバイスとの認証成
立を防止して、不正データ処理装置におけるコンテンツ
利用を排除可能とした構成を有するライセンスシステム
が実現される。

【０２６０】［チェック値（ＩＣＶ:Integrity Check V
alue）格納構成］次に、コンテンツの改竄を防止するた
めにコンテンツのインテグリティ・チェック値（ＩＣ
Ｖ）を生成して、コンテンツに対応付けて、ＩＣＶの計
算により、コンテンツ改竄の有無を判定する処理構成に
ついて説明する。

【０２６１】コンテンツのインテグリティ・チェック値
（ＩＣＶ）は、例えばコンテンツに対するハッシュ関数
を用いて計算され、ＩＣＶ＝ｈａｓｈ（Ｋｉｃｖ，Ｃ
１，Ｃ２，…）によって計算される。ＫｉｃｖはＩＣＶ
生成キーである。Ｃ１，Ｃ２はコンテンツの情報であ
り、コンテンツの重要情報のメッセージ認証符号（ＭＡ
Ｃ：Message authentication Code）が使用される。前
述したように、［ＭＡＣ］は、図２１で説明したＡＴＲ
ＡＣ３データファイルにも含まれる。これらを使用して
インテグリティ・チェック値（ＩＣＶ）の計算がなされ
る。

【０２６２】ＤＥＳ暗号処理構成を用いたＭＡＣ値生成
例を図３７に示す。図３７の構成に示すように対象とな
るメッセージを８バイト単位に分割し、（以下、分割さ
れたメッセージをＭ１、Ｍ２、・・・、ＭＮとする）、
まず、初期値（Initial Value（以下、ＩＶとする））
とＭ１を排他的論理和する（その結果をＩ１とする）。
次に、Ｉ１をＤＥＳ暗号化部に入れ、鍵（以下、Ｋ１と
する）を用いて暗号化する（出力をＥ１とする）。続け
て、Ｅ１およびＭ２を排他的論理和し、その出力Ｉ２を
ＤＥＳ暗号化部へ入れ、鍵Ｋ１を用いて暗号化する（出
力Ｅ２）。以下、これを繰り返し、全てのメッセージに
対して暗号化処理を施す。最後に出てきたＥＮがメッセ
ージ認証符号（ＭＡＣ（Message Authentication Cod
e））となる。なお、メッセージとしては、検証対象と
なるコンテンツおよびヘッダ情報等のコンテンツ関連デ
ータを構成する部分データが使用可能である。

【０２６３】このようなコンテンツのＭＡＣ値とＩＣＶ
生成キーＫｉｃｖにハッシュ関数を適用して用いてコン
テンツのインテグリティ・チェック値（ＩＣＶ）が生成
される。改竄のないことが保証された例えばコンテンツ
生成時に生成したＩＣＶと、新たにコンテンツに基づい
て生成したＩＣＶとを比較して同一のＩＣＶが得られれ
ばコンテンツに改竄のないことが保証され、ＩＣＶが異
なれば、改竄があったと判定される。

【０２６４】上述のようなインテグリティ・チェック値
（ＩＣＶ）は、コンテンツ個々に対して生成される複数
のコンテンツＭＡＣ値により、１つのインテグリティ・
チェック値（ＩＣＶ）を生成することが可能である。複
数のＭＡＣによるＩＣＶの計算は、例えば、ＩＣＶ＝Ｍ
ＡＣ（Ｋｉｃｖ，Ｃ＿ＭＡＣ［０］||Ｃ＿ＭＡＣ［１］
||Ｃ＿ＭＡＣ［２］||…）によって生成する。

【０２６５】コンテンツ生成時に生成したＩＣＶを格納
しておき、チェック処理時に生成ＩＣＶと格納ＩＣＶの
比較処理を行なう。両ＩＣＶが一致すれば改竄無しと判
定し、ＩＣＶが不一致の場合は、改竄が有りと判定さ
れ、データ再生等の処理制限がなされる。

【０２６６】メモリカード等の記憶装置には、音楽コン
テンツのみならず、画像データ、ゲームプログラムデー
タ等、カテゴリの異なるが格納される。これら各カテゴ
リのコンテンツも改竄の防止を図るため、各カテゴリ毎
にインテグリティ・チェック値（ＩＣＶ）を生成して格
納することがコンテンツ改竄チェックのためには有効な
手段となる。

【０２６７】しかしながら、メモリに格納するコンテン
ツ数が増大すると、検証用のチェック値を正規のコンテ
ンツデータに基づいて生成し、格納し管理することが困
難となる。特に、昨今フラッシュメモリを使用したメモ
リカード等の容量の大きい媒体においては、音楽デー
タ、画像データ、プログラムデータ等、様々なカテゴリ
のコンテンツデータがメモリに格納されることとなる。
このような環境においては、チェック値の生成処理、格
納処理、改竄チェック処理の管理は困難となる。格納デ
ータ全体に対するチェック値を生成すると、チェック対
象となったデータ全体に対するチェック値生成処理を実
行することが必要となる。例えばＤＥＳ−ＣＢＣモード
において生成されるメッセージ認証符号（ＭＡＣ）によ
り、チェック値ＩＣＶを求める手法を行なう場合、デー
タ全体に対するＤＥＳ−ＣＢＣの処理を実行することが
必要となる。この計算量は、データ長が長くなるにつれ
増大することとなり、処理効率の点で問題がある。

【０２６８】記憶装置として使用可能なメモリカードに
は、多くのカテゴリの異なるコンテンツが格納される。
これらのカテゴリの異なるコンテンツの改竄チェック管
理をカテゴリ毎に独立したインテグリティ・チェック値
（ＩＣＶ）を生成して実行する構成とすることにより、
ＩＣＶのチェック時、あるいはＩＣＶの変更時、例えば
データ変更時の新たなインテグリティ・チェック値（Ｉ
ＣＶ）の生成処理が、１つのカテゴリ内のデータを対象
として実行可能となり、他のカテゴリに影響を及ぼすこ
とがない。このようにカテゴリ毎の複数のインテグリテ
ィ・チェック値（ＩＣＶ）を格納する構成について説明
する。

【０２６９】図３８に記憶装置に格納されるデータ構成
と、それぞれのインテグリティ・チェック値（ＩＣＶ）
の格納構成例を示す。メモリカード等の記憶部（フラッ
シュメモリ）には、図３８に示されるように音楽データ
のディレクトリに、再生管理ファイル（ＰＢＬＩＳ
Ｔ）、暗号化コンテンツとして複数のＡＴＲＡＣＫ３デ
ータファイル（Ａ３Ｄ）が含まれ、さらに、メモリに
は、複数のカテゴリに属するコンテンツデータ（＃１〜
＃ｎ）が格納される。複数のカテゴリとは、例えば、音
楽データ、画像データ、ゲームプログラム等である。さ
らに、同様の画像データであっても、それぞれのデータ
提供元に応じて別のディレクトリとして独立のカテゴリ
として管理してもよい。

【０２７０】また、前述の有効化キーブロック（ＥＫ
Ｂ）の管理単位（エンティテイ）を１カテゴリとして設
定してもよい。すなわち、ある有効化キーブロック（Ｅ
ＫＢ）によって取得されるキー暗号キー：ＫＥＫによっ
て復号されるコンテンツキーＫｃｏｎを適用可能なコン
テンツ集合を１つのカテゴリとして設定してもよい。

【０２７１】再生管理ファイル（ＰＢＬＩＳＴ）、暗号
化コンテンツとして複数のＡＴＲＡＣＫ３データファイ
ル（Ａ３Ｄ）の各々には、改竄チェックのためのメッセ
ージ認証符号（ＭＡＣ（Message Authentication Cod
e））が含まれ、これらのＭＡＣ値に基づいてインテグ
リティ・チェック値（ＩＣＶ（ｃｏｎ））が生成され
る。複数のコンテンツのＭＡＣ値は、フラッシュメモリ
のシーケンスページにＭＡＣリストとして格納、管理さ
れ、これらのＭＡＣリストに基づいてＩＣＶ生成キーＫ
ｉｃｖを適用して得られるインテグリティ・チェック値
（ＩＣＶ（ｃｏｎ））が格納保存される。

【０２７２】コンテンツＭＡＣ値を格納するシーケンス
ページフォーマットを図３９に示す。シーケンスページ
領域は、一般コンテンツデータの書き込み禁止領域とし
て設定された領域である。図３９のシーケンスページ構
成について説明する。

【０２７３】Ｅ（ｋＳＴＲ，ｋＣＯＮ）は、メモリカー
ドのストレージキーで暗号化したコンテンツキーであ
る。ＩＤ（ｕｐｐｅｒ），（ｌｏｗｅｒ）は、メモリカ
ードの識別子（ＩＤ）の格納領域である。Ｃ＿ＭＡＣ
［０］は、再生管理ファイル（ＰＢＬＩＳＴ）の構成デ
ータに基づいて生成されたＭＡＣ値である。Ｃ＿ＭＡＣ
［１］は、コンテンツ、例えばＡＴＲＡＣＫ３データフ
ァイル＃１のデータに基づいて生成されたＭＡＣ値、以
下、コンテンツ毎にＭＡＣ値が格納される。これらのＭ
ＡＣ値に基づいてインテグリティ・チェック値（ＩＣＶ
（ｃｏｎ））が生成され、生成されたＩＣＶ（ｃｏｎ）
がシリアルプロトコルを通してメモリに書き込まれる。
なお、異なる鍵システムに対応するため、それぞれの鍵
システムから生成されるＩＣＶをそれぞれ違うエリアに
格納する構成とすることが好ましい。

【０２７４】また、カテゴリ毎に改竄チェックのために
生成される各カテゴリ毎のインテグリティ・チェック値
（ＩＣＶ）は、メモリカードの記憶部（フラッシュメモ
リ）のプールページに記録される。プールページもま
た、一般データの書き込みの禁止された領域として設定
されている。

【０２７５】各カテゴリ毎のインテグリティ・チェック
値（ＩＣＶ）を格納するプールページフォーマットを図
４０に示す。＃０＿ｒｅｖｉｓｉｏｎは、カテゴリ＃０
の更新データが設定され、更新された場合はインクリメ
ントされる。＃０＿ｖｅｒｓｉｏｎは、カテゴリ＃０の
バージョン、＃０＿Ｅ（ＫＥＫ，Ｋｉｃｖ）は、カテゴ
リ＃０のキー暗号化キー（ＫＥＫ）で暗号化したＩＣＶ
生成キー（Ｋｉｃｖ）であり、ＩＣＶ０は、カテゴリ＃
０のインテグリティ・チェック値（ＩＣＶ）値である。
以下、同様のデータが各カテゴリ毎にＥＫＢ＃１５まで
格納可能となっている。

【０２７６】ＩＣＶのチェックは、パワーオン時、また
はメモリカード等の記憶装置が再生装置にセットされた
ことを条件として開始される。図４１にＩＣＶチェック
を含む処理フローを示す。

【０２７７】まず、再生装置がパワーオン、または新た
なメモリカード等が装着されたことを検知すると、ステ
ップＳ４００１において、再生装置と記憶装置間の相互
認証が可能か否かが判定され、可能である場合は、ステ
ップＳ４００２において記憶装置と再生装置間での相互
認証処理（図２９参照）が実行される。また、ステップ
Ｓ４００１において、再生装置と記憶装置間の相互認証
が可能でないと判定された場合は、ステップＳ４００３
において、前述した仮想メモリカードと再生装置間の相
互認証処理が実行される。

【０２７８】ステップＳ４００４で相互認証が成立した
か否かが判定され、不成立の場合は、以下の処理は実行
されないで終了する。相互認証が成立の場合は、ステッ
プＳ４００５においてＩＣＶの計算が実行される。ＩＣ
Ｖは、前述したように各ファイルのＭＡＣ値に基づいて
算出される。

【０２７９】次にステップＳ４００６において、計算に
よって算出された生成ＩＣＶと、予め格納してある格納
ＩＣＶとの比較が実行される。両ＩＣＶが一致した場合
は、データ改竄がないと判定され、ステップＳ４００７
において、データ再生等の様々な処理が実行される。一
方、ＩＣＶが不一致であった場合は、データ改竄がある
と判定され、データの再生等を行なわず処理を終了す
る。このような処理を実行することによりデータ改竄の
防止、改竄されたデータの再生が排除される。

【０２８０】このように、カテゴリの異なるコンテンツ
について、カテゴリ毎に独立したインテグリティ・チェ
ック値（ＩＣＶ）を生成して管理する構成とすることに
より、ＩＣＶのチェック時、あるいはＩＣＶの変更時、
例えばデータ変更時の新たなインテグリティ・チェック
値（ＩＣＶ）の生成処理が、１つのカテゴリ内のデータ
を対象として実行可能となり、他のカテゴリに影響を及
ぼすことがない。

【０２８１】［拡張ＭＡＣ構成］前述の再生管理ファイ
ルまたは、ＡＴＲＡＣＫ３データファイルのデータ内容
の欄で説明したデータ改竄チェック用のＭＡＣ(Message
Authentication Code)の生成、および各ファイルに対
する格納処理の変形例として、拡張ＭＡＣの生成、格納
処理について、以下説明する。

【０２８２】図４２に拡張ＭＡＣの生成、格納処理例を
示す。図４２には、先の図２１〜２３で示したＡＴＲＡ
ＣＫ３データファイルの一部を示している。データ改竄
チェック用のＭＡＣ(Message Authentication Code)
は、例えばＡＴＲＡＣＫ３データファイル中のいくつか
のデータ項目のデータに基づいて、先の図３７で説明し
た処理によって生成される値であり、予めファイルに格
納されたＭＡＣと、チェック時の生成ＭＡＣとの比較に
より、データ改竄の有無を判定する。

【０２８３】例えば、図４２に示すＡＴＲＡＣＫ３デー
タファイルに格納されるＭＡＣは、そのＭＡＣによる改
竄チェック対象データが、「ＩＮＦ−ｓｅｑ＃」からの
複数のデータ項目に設定され、予めそれらのＭＡＣ対象
データ項目に基づいて生成されたＭＡＣがファイルに格
納されることになる。すなわち、ＭＡＣ（ＩＮＦ−ｓｅ
ｑ＃||Ａ||ＬＴ||…）である。（）内のデータがＭＡＣ
の対象、すなわち、改竄の有無の判定対象となるデータ
である。

【０２８４】しかしながら、ＡＴＲＡＣＫ３データファ
イル中には、様々な情報データが格納され、改竄チェッ
ク対象データが増加する場合がある。このような増加し
たチェック対象データも含めて新たなＭＡＣを生成し、
これを拡張ＭＡＣとしてファイル中に格納するととも
に、従来の改竄チェック対象データのみを対象として生
成されるオリジナルＭＡＣについては、基本的に改竄チ
ェック対象領域を不変として設定した構成について説明
する。

【０２８５】図４２には、先に説明したＩＮＦ−ｓｅｑ
＃以下のデータを改竄チェック対象データとして設定し
て、生成されるオリジナルＭＡＣ７０１がＡＴＲＡＣＫ
３データファイルに格納されている。

【０２８６】さらに、ＡＴＲＡＣＫ３データファイル中
のＩＮＦスペースに記録されるいくつかの情報中に、改
竄チェックの対象とすべきデータが存在する場合、オリ
ジナルＭＡＣ７０１のＭＡＣ生成対象データを構成する
データ、ここでは、［ＩＮＦ−ｓｅｑ＃］を含めて、そ
の他のＩＮＦスペース内の改竄チェック対象データに基
づいて新たなＭＡＣを生成し、これを拡張ＭＡＣとして
データファイル中に格納する。

【０２８７】図４２において、拡張ＭＡＣ［ＭＡＣ（Ｉ
ＮＦ）］７０２は、ＭＡＣ（INF−Seq#||path||MAC（pr
ofile）||Others…）によって生成される、このよう
に、拡張ＭＡＣは、オリジナルＭＡＣのＭＡＣ生成対象
データの一部を含み、その他の改竄チェック対象と併せ
たデータに基づいて生成される。

【０２８８】また、拡張ＭＡＣの書き換え時、すなわ
ち、拡張ＭＡＣの対象データ、すなわちＩＮＦ領域の
［ｐａｔｈ］以下のデータの書き換えにより、新たな拡
張ＭＡＣを、その書き換えデータに基づいて再生成して
再格納する処理を実行する際には、拡張ＭＡＣに含ま
れ、かつオリジナルＭＡＣの対象データでもある［ＩＮ
Ｆ−ｓｅｑ＃］の書き換えを行なって新たな拡張ＭＡＣ
の生成、格納処理を実行する。

【０２８９】この場合、オリジナルＭＡＣについても、
その対象データである［ＩＮＦ−ｓｅｑ＃］の書き換え
が実行されているので、新たにオリジナルＭＡＣの計算
を実行する。すなわち、拡張ＭＡＣの更新時には、オリ
ジナルＭＡＣの再生成、再格納処理を併せて実行する。

【０２９０】［ＩＮＦ−ｓｅｑ＃］の書き換えは、例え
ば新たな乱数の発生による書き換え処理、あるいは、Ｉ
ＮＦ−ｓｅｑ＃データのインクリメント処理等によって
実行可能である。

【０２９１】このように、改竄チェック対象データの増
加に対応して生成される拡張ＭＡＣのＭＡＣ生成対象デ
ータに、オリジナルＭＡＣのＭＡＣ対象データの一部を
含めて、双方のＭＡＣの共通するＭＡＣ対象データを存
在させ、拡張ＭＡＣの更新時には、オリジナルＭＡＣの
再生成も併せて実行する構成としたので、オリジナルＭ
ＡＣのＭＡＣ対象データ領域を広げることなく、新たな
改竄チェック用データである例えばＩＮＦ内のデータの
書き換え処理を常にオリジナルＭＡＣに反映させること
が可能となる。

【０２９２】［記憶装置および再生装置間におけるＥＫ
Ｂ処理］次に、前述のツリー構造の鍵配信システムを適
用した有効化キーブロック（ＥＫＢ）を用いて、暗号化
コンテンツの復号処理に適用するコンテンツキーを取得
する具体的処理構成について説明する。

【０２９３】図４３にＡＴＲＡＣＫ３データ等の暗号化
コンテンツを格納した例えばメモリスティック等の記憶
装置１００と、コンテンツ再生を実行する再生装置Ａ２
００，再生装置Ｂ３００を示す。

【０２９４】記憶装置１００には、暗号化コンテンツと
して、図２１等を用いて説明したＡＴＲＡＣＫ３データ
ファイルが格納され、再生装置においてコンテンツを再
生するためには、コンテンツの復号に必要なコンテンツ
キーＫｃｏｎを取得することが必要となる。

【０２９５】まず、再生装置が記憶装置からコンテンツ
キーを直接取得する処理態様について、図４３に示す記
憶装置８００と再生装置Ａ８１０とで説明する。まず、
記憶装置８００と、再生装置Ａ８１０は、認証処理機能
を実行する相互の制御モジュール８０１，８１１間にお
いて相互認証処理を実行する。相互認証は、例えば先に
説明した図８の共通鍵暗号方式、あるいは公開鍵暗号方
式による相互認証処理として実行する。この場合、記憶
装置８００と、再生装置Ａ８１０は、それぞれの制御処
理モジュール８０１，８１１が認証処理実行アルゴリズ
ムを有し、さらに、認証処理に必要な鍵を格納している
ことが必要である。

【０２９６】記憶装置８００は、再生装置Ａ８１０との
相互認証の成立後、記憶装置８００内の制御モジュール
８０１において、フラッシュメモリ８０２に格納したＡ
ＴＲＡＣＫ３データファイルから、記憶装置のストレー
ジキーＫｓｔｍで暗号化されたコンテンツキー：Ｅ（Ｋ
ｓｔｍ，Ｋｃｏｎ）または、先に説明したＥＫＢファイ
ルの処理によって取得可能なキー暗号キー（ＫＥＫ）で
暗号化されたコンテンツキー：Ｅ（ＫＥＫ，Ｋｃｏｎ）
のいずれかを取り出し、復号処理を実行して、コンテン
ツキーＫｃｏｎを取得する。

【０２９７】記憶装置８００は、再生装置Ａ８１０との
相互認証時に生成したセッションキーＫｓｅｓを用いて
コンテンツキーＫｃｏｎの再暗号化を実行し、生成した
暗号化データ：Ｅ（Ｋｓｅｓ，Ｋｃｏｎ）を再生装置Ａ
８１０に送付する。再生装置Ａ８１０は、制御モジュー
ル８１１において、受領した暗号化コンテンツキーＥ
（Ｋｓｅｓ，Ｋｃｏｎ）をセッションキーＫｓｅｓで復
号してコンテンツキーを取得する。

【０２９８】以上、説明した手法が、記憶装置側におい
て、コンテンツキーを復号して取り出して、これを再度
セッションキーで暗号化して再生装置に送付する手法で
ある。

【０２９９】次に、記憶装置側では復号処理を実行せ
ず、再生装置側においてコンテンツキーを取得する処理
を実行形態について説明する。

【０３００】この処理形態を図４３の記憶装置８００と
再生装置Ｂ８３０との間の処理として説明する。記憶装
置８００は、ＡＴＲＡＣＫ３データフアイル中の有効化
キーブロック（ＥＫＢ）バージョン（またはジェネレー
ション）から、コンテンツキーの取得に必要となる対応
有効化キーブロック（ＥＫＢ）を特定し、特定されたＥ
ＫＢを再生装置Ｂ８３０に送付する。

【０３０１】再生装置Ｂ８３０は、記憶装置からＥＫＢ
を受領し、予め再生装置内のメモリ、例えばＥ２ＰＲＯ
Ｍ（ｅｘ．フラッシュメモリ）内に格納したデバイスキ
ーブロック（ＤＫＢ）を用いて受領ＥＫＢの処理を実行
し、キー暗号キー（ＫＥＫ）を取得する。

【０３０２】ここで、デバイスキーブロック（ＤＫＢ）
について説明する。図４４を用いてデバイスキーブロッ
ク（ＤＫＢ）の構成を説明する。前述したように、コン
テンツ再生装置等の各デバイスは、図４４（ａ）に示す
ツリー構造の鍵配信構成の末端すなわちリーフから上位
のルートに連なる各ノードのキーを有する。例えば図４
４（ａ）に示す末端ノードのセット５（ＳＥＴ５）に対
応するデバイスは、リーフキーとしてのＫ１０１，ノー
ドキーとしてＫ１０，Ｋ１から、ルートキーＫｒｏｏｔ
に至るキーセット、または、サブカテゴリーノードキー
に至るキーセット、あるいはカテゴリーノードに至るキ
ーセットを保有する。

【０３０３】これらの各キーは、デバイスにおいて暗号
化されてデバイス内のメモリ、例えばＥ２ＰＲＯＭに格
納される。このような各デバイスに保存されるリーフか
ら特定ノード（ｅｘ．サブカテゴリーノード）またはル
ートまでのキーに対応するキーセットの暗号化キーセッ
トがデバイスキーブロック（ＤＫＢ）である。

【０３０４】デバイスキーブロック（ＤＫＢ）のデータ
構成例を図４４（ｂ）に示す。図４４（ｂ）に示すよう
に、ＤＫＢはノードキー、およびルートキーをリーフキ
ーで暗号化したデータと、リーフキーをデバイス（ｅ
ｘ．再生装置）のストレージキー：Ｋｓｔｄで暗号化し
たデータを有する暗号化キーブロックとして構成され
る。デバイス（ｅｘ．再生装置）は、このデバイスキー
ブロック（ＤＫＢ）中のＥｎｃ（Ｋｓｔｄ，Ｋｌｅａ
ｆ）を、自身のストレージキー：Ｋｓｔｄを用いて復号
し、リーフキーＫｌｅａｆを取得し、さらに、取得した
リーフキーＫｌｅａｆを用いて高位の暗号化ノードキ
ー、暗号化ルートキーを直接復号することが可能とな
り、ＥＫＢの下位キーから順次復号して上位キーを取得
していく処理の省略が可能となる。なおデバイスキーブ
ロック（ＤＫＢ）には、リーフの識別子であるリーフＩ
Ｄを含む。

【０３０５】デバイス固有のストレージキーは、各セッ
ト（デバイス）毎に異なる鍵であり、予めデバイス中の
セキュアメモリ（ｅｘ．ＳＡＭ）中に格納するか、ある
いはリーフＩＤに基づいて求めることの可能な構成とし
てもよい。すなわち、デバイスの制御モジュール（暗号
処理部）において、リーフＩＤに基づいて生成する構成
としてもよい。具体的には、所定のセット単位で共通に
格納されたマスターキーＫｍａｓに基づいてリーフＩＤ
に対するハッシュを適用し、Ｋｓｔｄ＝ｈａｓｈ（Ｋｍ
ａｓ，リーフＩＤ）として求める構成としてもよい。

【０３０６】図４３に戻ってコンテンツキーの取得処理
の説明を続ける。記憶装置８００から有効化キーブロッ
ク（ＥＫＢ）を受領した再生装置Ｂ８３０は、制御モジ
ュール８３１において、メモリ８３２に格納したデバイ
スキーブロック（ＤＫＢ）の復号によって得られるノー
ドーキー、ルートキー等を適用してＥＫＢにより暗号化
されたキー暗号化キー（ＫＥＫ）を取得する。ＥＫＢの
処理手法は、先に図５あるいは図９を用いて説明したと
同様の手法である。

【０３０７】再生装置Ｂ８３０は、有効化キーブロック
（ＥＫＢ）の処理によって取得したキー暗号化キー（Ｋ
ＥＫ）を用い、さらに、記憶装置８００から受領した暗
号化コンテンツキー：Ｅ（ＫＥＫ，Ｋｃｏｎ）の復号処
理を実行してコンテンツキーを取得する。

【０３０８】なお、図４３の再生装置Ｂ８３０のメモリ
（Ｅ２ＰＲＯＭ）８３２に格納されたイニシャルＥＫＢ
は、デバイス（再生装置Ｂ８３０）に当初から格納され
る簡略化したＥＫＢファイルであり、例えば、前述の図
１１を用いた説明中に記載したカテゴリーノードにおい
て、１つのカテゴリノード（例えばカテゴリ＝メモリス
テイック）の下位に接続されるリーフに対応するデバイ
スに共通に格納される暗号化キーブロックである。

【０３０９】例えばカテゴリーノードの持つキーがＫ０
１であればＫ０１で暗号化されたルートキー：Ｅｎｃ
（Ｋ０１，Ｋｒｏｏｔ）がイニシャルＥＫＢとして格納
される。デバイスはイニシャルＥＫＢの処理によりルー
トキーを取得することが可能となり、例えばルートキー
によって暗号化されたキー暗号化キー（ＫＥＫ）を格納
したＥＫＢを受領した場合には、イニシャルＥＫＢから
得たルートキーを用いてキー暗号化キー（ＫＥＫ）を取
得することが可能となる。

【０３１０】なお、イニシャルＥＫＢは、１つのカテゴ
リーノードに属するデバイスに共通に提供する構成とす
る態様に限らず、複数のカテゴリノードに共通に構成し
てもよい。例えばメモリスティックのカテゴリノードの
ノードキーＫ０１、コンテンツ再生機能を持つＰＣのカ
ンテゴリノードのノードキーをＫ１０、ネットワーク対
応の形態再生装置のカテゴリノードのノードキーをＫ１
１としたとき、これらの各デバイスに予め、Ｅｎｃ（Ｋ
０１，Ｋｒｏｏｔ）、Ｅｎｃ（Ｋ１０，Ｋｒｏｏｔ）、
Ｅｎｃ（Ｋ１１，Ｋｒｏｏｔ）の３種類の暗号化ルート
キーを格納したイニシャルＥＫＢを設定して出荷するこ
とにより、それぞれの異なるデバイスにおいて共通に利
用可能な暗号化コンテンツの配信を行なうことが可能と
なる。

【０３１１】図４５に、再生装置のメモリ（ｅｘ．Ｅ２
ＰＲＯＭ）にデバイスキーブロック（ＤＫＢ）と、イニ
シャルＥＫＢとして自己録音、自己再生用の有効化キー
ブロック（ＥＫＢ）を格納した構成例を示す。また、図
４６にこれらのキーブロックを利用したコンテンツキー
の取得処理例を示す。

【０３１２】図４５の構成について説明する。デバイス
（ｅｘ．記録再生器）は、図４５（ａ）のリーフに対応
するデバイスであり、ツリー構成の第８段目に構成され
るカテゴリーノードＫｎ８のカテゴリーに属するデバイ
スである。デバイスには、（ｂ）に示すＥｎｃ（Ｋｓｔ
ｄ，Ｋｌｅａｆ）〜Ｅｎｃ（Ｋｌｅａｆ，Ｋｎ８）のデ
バイスキーブロック（ＤＫＢ）が格納される。この構成
は、先に説明したＤＫＢと同様であるが、リーフキーに
よって直接暗号化されて格納されたデータは、リーフキ
ーの直上のノードキーＫｎ４７からカテゴリーノードキ
ーであるＫｎ８までのキーとして構成される。

【０３１３】さらに、デバイスは、自己録音、再生用の
有効化キーブロック（ＥＫＢ）を保有し、自己のデバイ
スでのコンテンツ録音、再生時には、この自己録音、再
生用の有効化キーブロック（ＥＫＢ）とデバイスキーブ
ロック（ＤＫＢ）との処理によりコンテンツキーＫｃｏ
ｎを取得して、コンテンツの復号、暗号化を実行する。

【０３１４】図４６に、図４５（ｂ）のＤＫＢ，ＥＫＢ
を持つデバイスにおけるコンテンツキーの取得処理にお
いて実行するステップを示す。まずステップＳ４６０１
において、デバイスは、リーフＩＤに基づいてストレー
ジキーＫｓｔｄを抽出する。ストレージキーＫｓｔｄ
は、リーフＩＤに基づいてデバイス中のセキュアメモリ
から抽出するか、あるいは前述したように、マスターキ
ーＫｍａｓとリーフＩＤに基づいて算出する。

【０３１５】次に、Ｓ４６０２において、ストレージキ
ーＫｓｔｄに基づいてデバイスキーブロック（ＤＫＢ）
の処理、すなわちＥｎｃ（Ｋｓｔｄ，Ｋｌｅａｆ）の復
号を実行し、リーフキーを求める。次に、Ｓ４６０３に
おいて、リーフキーＫｌｅａｆに基づいてデバイスキー
ブロック（ＤＫＢ）の処理、すなわちＥｎｃ（Ｋｌｅａ
ｆ，Ｋｎ８）の復号を実行し、カテゴリーノードキーを
求める。ＤＫＢは、リーフキーにより直接暗号化された
ノードキーが格納されているので、高位のノードキーを
直接リーフキーによる復号処理によって取得することが
可能となる。

【０３１６】次に、ステップＳ４６０４において、ノー
ドキーＫｎ８からＥＫＢ処理を実行し、順次高位のノー
ドキーを求めて、最上位キーであるルートキーを算出す
る。次に、ステップＳ４６０５において、有効化キーブ
ロック（ＥＫＢ）の処理によって求めたルートキーＫｒ
ｏｏｔを用いてＥｎｃ（Ｋｒｏｏｔ，ＫＥＫ）の復号処
理を実行してキー暗号化キーＫＥＫを求める。最後にス
テップＳ４６０６において、取得したキー暗号化キーＫ
ＥＫを用いて、コンテンツデータに付随したデータ中に
格納されたＥｎｃ（ＫＥＫ，Ｋｃｏｎ）の復号処理を実
行してコンテンツキーＫｃｏｎを取得する。

【０３１７】図４５（ｂ）に示す有効化キーブロック
（ＥＫＢ）は自己録再用のＥＫＢであるが、様々なコン
テンツをデバイスにダウンロードする際に、そのコンテ
ンツに対応するＥＫＢを併せてダウンロードし、コンテ
ンツに対応付けてＥＫＢをメモリに格納し、コンテンツ
の再生時にダウンロードしたコンテンツ対応のＥＫＢに
対して図４６の処理を実行することも可能である。ま
た、図４５（ｂ）に示すデバイスキーブロック（ＤＫ
Ｂ）は、上位から８段のノードＫｎ８のノードキーまで
を直接リーフキーで暗号化したデータをＤＫＢの暗号化
キーデータとした構成であるが、格納するノードキー
は、さらに上位、あるいは下位までのノードキーとして
もよい。

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

【０３１９】

【発明の効果】以上、説明したように、本発明のデータ
処理装置および方法によれば、複数のデバイスをリーフ
として構成したツリーのルートからリーフまでのパス上
のルート、ノード、およびリーフに各々キーを対応付け
たキーツリーを構成するパス上の更新キー、および下位
キーによる上位キーの暗号化処理データを含む有効化キ
ーブロック（ＥＫＢ）によって暗号化された鍵を提供
し、選択された正当なデバイスにおいてのみ復号可能な
構成として、セキュリティの高い暗号処理鍵、あるいは
コンテンツ配信システムが実現される。

【０３２０】さらに、本発明のデータ処理装置および方
法によれば、有効化キーブロック（ＥＫＢ）によって暗
号化されたＥＫＢ配信キー暗号キー（ＫＥＫ）に基づい
て取得可能な暗号処理鍵の適用対象となるコンテンツ数
を示すリンクカウント・データをヘッダ情報として持つ
配信鍵許可情報ファイルを記憶装置に格納する構成とし
たので、適用可能なコンテンツ数が容易に把握可能とな
り、複数の有効化キーブロック（ＥＫＢ）を記憶装置に
格納する場合に、多くのリンクカウントを持つ有効化キ
ーブロック（ＥＫＢ）に含まれるキー暗号キー（ＫＥ
Ｋ）を予め復号してメモリに格納しておくことにより、
コンテンツ利用時のＥＫＢ処理を省略することが可能と
なり、コンテンツ利用の効率化が実現される。

【図面の簡単な説明】

【図１】本発明のデータ処理装置の使用概念を説明する
図である。

【図２】本発明のデータ処理装置のシステム構成例およ
びデータ経路例を示す図である。

【図３】本発明のデータ処理装置における各種キー、デ
ータの暗号化処理について説明するツリー構成図であ
る。

【図４】本発明のデータ処理装置における各種キー、デ
ータの配布に使用される有効化キーブロック（ＥＫＢ）
の例を示す図である。

【図５】本発明のデータ処理装置におけるコンテンツキ
ーの有効化キーブロック（ＥＫＢ）を使用した配布例と
復号処理例を示す図である。

【図６】本発明のデータ処理装置における有効化キーブ
ロック（ＥＫＢ）のフォーマット例を示す図である。

【図７】本発明のデータ処理装置における有効化キーブ
ロック（ＥＫＢ）のタグの構成を説明する図である。

【図８】本発明のデータ処理装置における有効化キーブ
ロック（ＥＫＢ）と、コンテンツキー、コンテンツを併
せて配信するデータ構成例を示す図である。

【図９】本発明のデータ処理装置における有効化キーブ
ロック（ＥＫＢ）と、コンテンツキー、コンテンツを併
せて配信した場合のデバイスでの処理例を示す図であ
る。

【図１０】本発明のデータ処理装置における有効化キー
ブロック（ＥＫＢ）とコンテンツを記録媒体に格納した
場合の対応について説明する図である。

【図１１】本発明のデータ処理装置における階層ツリー
構造のカテゴリ分類の例を説明する図である。

【図１２】本発明のデータ処理装置における簡略化有効
化キーブロック（ＥＫＢ）の生成過程を説明する図であ
る。

【図１３】本発明のデータ処理装置における有効化キー
ブロック（ＥＫＢ）の生成過程を説明する図である。

【図１４】本発明のデータ処理装置における簡略化有効
化キーブロック（ＥＫＢ）を説明する図である。

【図１５】本発明のデータ処理装置における再生装置と
記憶装置の構成を示すブロック図である。

【図１６】本発明のデータ処理装置における記憶装置内
の記憶ユニットに記憶されているデータを説明する図で
ある。

【図１７】本発明のデータ処理装置における記憶装置の
フラッシュメモリに記憶されるデータを説明するための
図である。

【図１８】本発明のデータ処理装置における再生管理フ
ァイルのデータ構成を概略的に示す図である。

【図１９】本発明のデータ処理装置におけるデータファ
イルのデータ構成を概略的に示す図である。

【図２０】本発明のデータ処理装置における再生管理フ
ァイルのデータ構成をより詳細に示す図である。

【図２１】本発明のデータ処理装置におけるデータファ
イルのデータ構成をより詳細に示す図である。

【図２２】本発明のデータ処理装置におけるデータファ
イルの属性ヘッダの一部を示す図である。

【図２３】本発明のデータ処理装置におけるデータファ
イルの属性ヘッダの一部を示す図である。

【図２４】本発明のデータ処理装置におけるモードの種
類と、各モードにおける録音時間等を示す図である。

【図２５】本発明のデータ処理装置におけるコピー制御
情報を説明するための図である。

【図２６】本発明のデータ処理装置におけるデータファ
イルの属性ヘッダの一部を示す図である。

【図２７】本発明のデータ処理装置におけるデータファ
イルの各データブロックのヘッダを示す略線図である。

【図２８】本発明のデータ処理装置におけるデータ記録
処理フローを示す図である。

【図２９】本発明のデータ処理装置において適用可能な
相互認証処理を示す図である。

【図３０】本発明のデータ処理装置におけるデータ再生
処理フローを示す図である。

【図３１】本発明のデータ処理装置における配信鍵許可
情報ファイルのフオーマットを示す図である。

【図３２】本発明のデータ処理装置におけるデータ格納
態様を示す図である。

【図３３】本発明のデータ処理装置におけるキー有効化
ブロック（ＥＫＢ）を使用したデータ復号処理フローを
示す図である。

【図３４】本発明のデータ処理装置における有効化キー
ブロック（ＥＫＢ）と、認証キーを併せて配信するデー
タ構成と、デバイスでの処理例を示す図（その１）であ
る。

【図３５】本発明のデータ処理装置における有効化キー
ブロック（ＥＫＢ）と、認証キーを併せて配信するデー
タ構成と、デバイスでの処理例を示す図（その２）であ
る。

【図３６】本発明のデータ処理装置における仮想メモリ
カードを適用したて認証処理シーケンスを示す図であ
る。

【図３７】本発明のデータ処理装置において適用可能な
インテグリティ・チェック値（ＩＣＶ）の生成に使用す
るＭＡＣ値生成例を示す図である。

【図３８】本発明のデータ処理装置におけるインテグリ
ティ・チェック値（ＩＣＶ）の格納態様を説明する図で
ある。

【図３９】本発明のデータ処理装置におけるＭＡＣ値を
格納するシーケンスページフォーマットを示す図であ
る。

【図４０】本発明のデータ処理装置におけるＩＣＶを格
納するプールページフォーマットを示す図である。

【図４１】本発明のデータ処理装置におけるＩＣＶチェ
ック処理フローを示す図である。

【図４２】本発明のデータ処理装置においてて着ようか
能な拡張ＭＡＣの生成、格納処理を説明する図である。

【図４３】本発明のデータ処理装置におけるキー有効化
ブロック（ＥＫＢ）を用いたコンテンツキーの取得処理
態様を説明する図である。

【図４４】本発明のデータ処理装置において使用される
デバイスキーブロック（ＤＫＢ）の構成について説明す
る図である。

【図４５】本発明のデータ処理装置におけるデバイスキ
ーブロック（ＤＫＢ）、キー有効化ブロック（ＥＫＢ）
の格納構成例を示する図である。

【図４６】本発明のデータ処理装置におけるデバイスキ
ーブロック（ＤＫＢ）、キー有効化ブロック（ＥＫＢ）
を用いたコンテンツキーの取得処理態様を説明する図で
ある。

【符号の説明】

１０コンテンツ配信手段１１インターネット１２衛星放送１３電話回線１４メディア２０データ処理手段２１パーソナルコンピュータ（ＰＣ）２２ポータブルデバイス（ＰＤ）２３携帯電話、ＰＤＡ２４記録再生器、ゲーム端末２５再生装置３０記憶手段１００パーソナルコンピュータ（ＰＣ）２００再生装置３００記憶装置６０１バージョン６０２デプス６０３データポインタ６０４タグポインタ６０５署名ポインタ６０６データ部６０７タグ部６０８署名３３，４３制御モジュール５０，６０乱数発生ユニット５１，６１記憶ユニット５２，６２鍵生成／演算ユニット５３，６３相互認証ユニット５４，７４暗号化／復号ユニット５５，６５制御ユニット３４フラッシュメモリ４４編集モジュール４５圧縮／伸長モジュール４６スピーカ４９メモリ８００記憶装置８０１制御モジュール８０２フラッシュメモリ８１０再生装置Ａ８１１制御モジュール８３０再生装置Ｂ８３１制御モジュール８３２メモリ

Claims

【特許請求の範囲】

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