JP4686805B2 - Data storage element manufacturing method, data storage element, and data processing apparatus - Google Patents

Description

【００９９】
これらを用いて点Ｇのｕ倍を計算する（速度は遅いが、最もわかりやすい演算方法として次のように行う。Ｇ、２×Ｇ、４×Ｇ・・を計算し、uを2進数展開して1が立っているところに対応する２ⁱ×Ｇ（Ｇをｉ回２倍算した値）を加算する（ｉはｕのＬＳＢから数えた時のビット位置））。
【０１００】
ステップＳ５で、ｃ＝Ｘｖｍｏｄ ｒを計算し、ステップＳ６でこの値が０になるかどうか判定し、０でなければステップＳ７でｄ＝［（ｆ＋ｃＫｓ）／ｕ］ｍｏｄ ｒを計算し、ステップＳ８でｄが０であるかどうか判定し、ｄが０でなければ、ステップＳ９でｃおよびｄを電子署名データとして出力する。仮に、ｒを１６０ビット長の長さであると仮定すると、電子署名データは３２０ビット長となる。
【０１０１】
ステップＳ６において、ｃが０であった場合、ステップＳ３に戻って新たな乱数を生成し直す。同様に、ステップＳ８でｄが０であった場合も、ステップＳ３に戻って乱数を生成し直す。
【０１０２】
（３−３）公開鍵暗号方式による電子署名の検証
次に、公開鍵暗号方式を用いた電子署名の検証方法を、図１２を用いて説明する。ステップＳ１１で、Ｍをメッセージ、pを標数、a、bを楕円曲線の係数（楕円曲線：ｙ²=ｘ³＋ａｘ＋ｂ）、Ｇを楕円曲線上のベースポイント、rをＧの位数、ＧおよびＫｓ×Gを公開鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ１２で電子署名データｃおよびｄが０＜ｃ＜ｒ、０＜ｄ＜ｒを満たすか検証する。これを満たしていた場合、ステップＳ１３で、メッセージＭのハッシュ値を計算し、ｆ＝Ｈａｓｈ（Ｍ）とする。次に、ステップＳ１４でh=1/d mod rを計算し、ステップＳ１５でｈ１＝ｆｈ ｍｏｄ ｒ、ｈ２=ｃｈ ｍｏｄ ｒを計算する。
【０１０３】
ステップＳ１６において、既に計算したｈ１およびｈ２を用い、点Ｐ＝（Ｘｐ，Ｙｐ）＝ｈ１×Ｇ＋ｈ２・Ｋｓ×Ｇを計算する。電子署名検証者は、公開鍵ＧおよびＫｓ×Ｇを知っているので、図１１のステップＳ４と同様に楕円曲線上の点のスカラー倍の計算ができる。そして、ステップＳ１７で点Ｐが無限遠点かどうか判定し、無限遠点でなければステップＳ１８に進む（実際には、無限遠点の判定はステップＳ１６でできてしまう。つまり、Ｐ＝（Ｘ，Ｙ）、Ｑ＝（Ｘ，−Ｙ）の加算を行うと、λが計算できず、Ｐ＋Ｑが無限遠点であることが判明している）。ステップＳ１８でＸｐ ｍｏｄ ｒを計算し、電子署名データｃと比較する。最後に、この値が一致していた場合、ステップＳ１９に進み、電子署名が正しいと判定する。
【０１０４】
電子署名が正しいと判定された場合、データは改竄されておらず、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したことがわかる。
【０１０５】
ステップＳ１２において、電子署名データｃまたはｄが、０＜ｃ＜ｒ、０＜ｄ＜ｒを満たさなかった場合、ステップＳ２０に進む。また、ステップＳ１７において、点Pが無限遠点であった場合もステップＳ２０に進む。さらにまた、ステップＳ１８において、Ｘｐ ｍｏｄ ｒの値が、電子署名データｃと一致していなかった場合にもステップＳ２０に進む。
【０１０６】
ステップＳ２０において、電子署名が正しくないと判定された場合、データは改竄されているか、公開鍵に対応した秘密鍵を保持する者が電子署名を生成したのではないことがわかる。
【０１０７】
（３−４）共通鍵暗号方式による相互認証
次に、共通鍵暗号方式を用いた相互認証方法を、図１３を用いて説明する。図１３において、共通鍵暗号方式としてＤＥＳを用いているが、前述のように同様な共通鍵暗号方式であればいずれでもよい。図１３において、まず、Ｂが６４ビットの乱数Ｒｂを生成し、Ｒｂおよび自己のIDであるＩＤ（ｂ）をＡに送信する。これを受信したＡは、新たに64ビットの乱数Ｒａを生成し、Ｒａ、Ｒｂ、ＩＤ（ｂ）の順に、ＤＥＳのＣＢＣモードで鍵Ｋａｂを用いてデータを暗号化し、Ｂに返送する。図７に示すＤＥＳのＣＢＣモード処理構成によれば、ＲａがＭ１、ＲｂがＭ２、ＩＤ（ｂ）がＭ３に相当し、初期値：ＩＶ＝０としたときの出力Ｅ１、Ｅ２、Ｅ３が暗号文となる。
【０１０８】
これを受信したＢは、受信データを鍵Ｋａｂで復号化する。受信データの復号化方法は、まず、暗号文Ｅ１を鍵Ｋａｂで復号化し、乱数Ｒａを得る。次に、暗号文Ｅ２を鍵Ｋａｂで復号化し、その結果とＥ１を排他的論理和し、Ｒｂを得る。最後に、暗号文Ｅ３を鍵Ｋａｂで復号化し、その結果とＥ２を排他的論理和し、ＩＤ(ｂ)を得る。こうして得られたＲａ、Ｒｂ、ＩＤ(ｂ)の内、ＲｂおよびＩＤ(ｂ)が、Ｂが送信したものと一致するか検証する。この検証に通った場合、ＢはＡを正当なものとして認証する。
【０１０９】
次にＢは、認証後に使用するセッション鍵（Session Key（以下、Ｋｓｅｓとする））を生成する（生成方法は、乱数を用いる）。そして、Ｒｂ、Ｒａ、Ｋｓｅｓの順に、ＤＥＳのＣＢＣモードで鍵Ｋａｂを用いて暗号化し、Ａに返送する。
【０１１０】
これを受信したＡは、受信データを鍵Ｋａｂで復号化する。受信データの復号化方法は、Ｂの復号化処理と同様であるので、ここでは詳細を省略する。こうして得られたＲｂ、Ｒａ、Ｋｓｅｓの内、ＲｂおよびＲａが、Ａが送信したものと一致するか検証する。この検証に通った場合、ＡはＢを正当なものとして認証する。互いに相手を認証した後には、セッション鍵Ｋｓｅｓは、認証後の秘密通信のための共通鍵として利用される。
【０１１１】
なお、受信データの検証の際に、不正、不一致が見つかった場合には、相互認証が失敗したものとして処理を中断する。
【０１１２】
（３−５）公開鍵証明書
次に、公開鍵証明書について図１４を用いて説明する。公開鍵証明書は、公開鍵暗号方式における認証局（ＣＡ：Certificate Authority）が発行する証明書であり、ユーザが自己のＩＤ、公開鍵等を認証局に提出することにより、認証局側が認証局のＩＤや有効期限等の情報を付加し、さらに認証局による署名を付加して作成される証明書である。
【０１１３】
図１４に示す公開鍵証明書は、証明書のバージョン番号、認証局が証明書利用者に対し割り付ける証明書の通し番号、電子署名に用いたアルゴリズムおよびパラメータ、認証局の名前、証明書の有効期限、証明書利用者の名前（ユーザＩＤ）、証明書利用者の公開鍵並びに電子署名を含む。
【０１１４】
電子署名は、証明書のバージョン番号、認証局が証明書利用者に対し割り付ける証明書の通し番号、電子署名に用いたアルゴリズムおよびパラメータ、認証局の名前、証明書の有効期限、証明書利用者の名前並びに証明書利用者の公開鍵全体に対しハッシュ関数を適用してハッシュ値を生成し、そのハッシュ値に対して認証局の秘密鍵を用いて生成したデータである。この電子署名の生成には、例えば図１１で説明した処理フローが適用される。
【０１１５】
認証局は、図１４に示す公開鍵証明書を発行するとともに、有効期限が切れた公開鍵証明書を更新し、不正を行った利用者の排斥を行うための不正者リストの作成、管理、配布（これをリボケーション：Revocationと呼ぶ）を行う。また、必要に応じて公開鍵・秘密鍵の生成も行う。
【０１１６】
一方、この公開鍵証明書を利用する際には、利用者は自己が保持する認証局の公開鍵を用い、当該公開鍵証明書の電子署名を検証し、電子署名の検証に成功した後に公開鍵証明書から公開鍵を取り出し、当該公開鍵を利用する。従って、公開鍵証明書を利用する全ての利用者は、共通の認証局の公開鍵を保持している必要がある。なお、電子署名の検証方法については、図１２で説明したのでその詳細は省略する。
【０１１７】
（３−６）公開鍵暗号方式による相互認証
次に、公開鍵暗号方式である１６０ビット長の楕円曲線暗号を用いた相互認証方法を、図１５を用いて説明する。図１５において、公開鍵暗号方式としてＥＣＣを用いているが、前述のように同様な公開鍵暗号方式であればいずれでもよい。また、鍵サイズも１６０ビットでなくてもよい。図１５において、まずＢが、６４ビットの乱数Ｒｂを生成し、Aに送信する。これを受信したＡは、新たに６４ビットの乱数Ｒａおよび標数ｐより小さい乱数Ａｋを生成する。そして、ベースポイントＧをＡｋ倍した点Ａｖ＝Ａｋ×Ｇを求め、Ｒａ、Ｒｂ、Ａｖ（X座標とY座標）に対する電子署名Ａ．Ｓｉｇを生成し、Ａの公開鍵証明書とともにＢに返送する。ここで、ＲａおよびＲｂはそれぞれ６４ビット、ＡｖのＸ座標とＹ座標がそれぞれ１６０ビットであるので、合計４４８ビットに対する電子署名を生成する。電子署名の生成方法は図１１で説明したので、その詳細は省略する。また、公開鍵証明書も図１４で説明したので、その詳細は省略する。
【０１１８】
Ａの公開鍵証明書、Ｒａ、Ｒｂ、Ａｖ、電子署名Ａ．Ｓｉｇを受信したＢは、Ａが送信してきたＲｂが、Ｂが生成したものと一致するか検証する。その結果、一致していた場合には、Ａの公開鍵証明書内の電子署名を認証局の公開鍵で検証し、Ａの公開鍵を取り出す。公開鍵証明書の検証については、図１４を用いて説明したので、その詳細は省略する。そして、取り出したＡの公開鍵を用い電子署名Ａ．Ｓｉｇを検証する。電子署名の検証方法は図１２で説明したので、その詳細は省略する。電子署名の検証に成功した後、ＢはＡを正当なものとして認証する。
【０１１９】
次に、Ｂは、標数ｐより小さい乱数Ｂｋを生成する。そして、ベースポイントＧをＢｋ倍した点Ｂｖ＝Ｂｋ×Ｇを求め、Ｒｂ、Ｒａ、Ｂｖ（Ｘ座標とＹ座標）に対する電子署名Ｂ．Ｓｉｇを生成し、Ｂの公開鍵証明書とともにＡに返送する。
【０１２０】
Ｂの公開鍵証明書、Ｒｂ、Ｒａ、Ａｖ、電子署名Ｂ．Ｓｉｇを受信したＡは、Ｂが送信してきたＲａが、Ａが生成したものと一致するか検証する。その結果、一致していた場合には、Ｂの公開鍵証明書内の電子署名を認証局の公開鍵で検証し、Ｂの公開鍵を取り出す。そして、取り出したＢの公開鍵を用い電子署名Ｂ．Ｓｉｇを検証する。電子署名の検証に成功した後、ＡはＢを正当なものとして認証する。
【０１２１】
両者が認証に成功した場合には、ＢはＢｋ×Ａｖ（Ｂｋは乱数だが、Ａｖは楕円曲線上の点であるため、楕円曲線上の点のスカラー倍計算が必要）を計算し、ＡはＡｋ×Ｂｖを計算し、これら点のＸ座標の下位６４ビットをセッション鍵として以降の通信に使用する（共通鍵暗号を６４ビット鍵長の共通鍵暗号とした場合）。もちろん、Ｙ座標からセッション鍵を生成してもよいし、下位６４ビットでなくてもよい。なお、相互認証後の秘密通信においては、送信データはセッション鍵で暗号化されるだけでなく、電子署名も付されることがある。
【０１２２】
電子署名の検証や受信データの検証の際に、不正、不一致が見つかった場合には、相互認証が失敗したものとして処理を中断する。
【０１２３】
（３−７）楕円曲線暗号を用いた暗号化処理
次に、楕円曲線暗号を用いた暗号化について、図１６を用いて説明する。ステップＳ２１において、Ｍｘ、Ｍｙをメッセージ、pを標数、a、bを楕円曲線の係数（楕円曲線：ｙ²=ｘ³＋ａｘ＋ｂ）、Ｇを楕円曲線上のベースポイント、rをＧの位数、ＧおよびＫｓ×Ｇを公開鍵（０＜Ｋｓ＜ｒ）とする。ステップＳ２２で乱数ｕを０＜ｕ＜ｒになるように生成し、ステップＳ２３で公開鍵Ｋｓ×Ｇをu倍した座標Ｖを計算する。なお、楕円曲線上のスカラー倍は図１１のステップＳ４で説明したので、詳細は省略する。ステップＳ２４で、ＶのＸ座標をＭｘ倍してｐで剰余を求めＸ０とし、ステップＳ２５でＶのＹ座標をＭｙ倍してｐで剰余を求めＹ０とする。なお、メッセージの長さがｐのビット数より少ない場合、Ｍｙは乱数を使い、復号化部ではＭｙを破棄するようにする。ステップＳ２６において、u×Gを計算し、ステップＳ２７で暗号文ｕ×G、（Ｘ０、Ｙ０）を得る。
【０１２４】
（３−８）楕円曲線暗号を用いた復号化処理
次に、楕円曲線暗号を用いた復号化について、図１７を用いて説明する。ステップＳ３１において、ｕ×G、（Ｘ０、Ｙ０）を暗号文データ、ｐを標数、a、bを楕円曲線の係数（楕円曲線：ｙ²=ｘ³＋ａｘ＋ｂ）、Ｇを楕円曲線上のベースポイント、rをGの位数、Ｋｓを秘密鍵（０＜Ｋｓ＜ｒ）とする。ステップｓ３２において、暗号データｕ×Ｇを秘密鍵Ｋｓ倍し、座標Ｖ（Ｘｖ，Ｙｖ）を求める。ステップＳ３３では、暗号データの内、（Ｘ０、Ｙ０）のＸ座標を取り出し、Ｘ１＝Ｘ０／Ｘｖ mod ｐを計算し、ステップＳ３４においては、Ｙ座標を取り出し、Ｙ１＝Ｙ０／Ｙｖ mod ｐを計算する。そして、ステップＳ３５でＸ１をＭｘとし、Ｙ１をＭｙとしてメッセージを取り出す。この時、Ｍｙをメッセージにしていなかった場合、Ｙ１は破棄する。
【０１２５】
このように、秘密鍵をＫｓ、公開鍵をＧ、Ｋｓ×Ｇとすることで、暗号化に使用する鍵と復号化に使用する鍵を、異なる鍵とすることができる。
【０１２６】
また、公開鍵暗号の他の例としてはＲＳＡ暗号が知られているが、詳しい説明は省略する（PKCS #1 Version2に詳細が記述されている）。
【０１２７】
（３−９）乱数生成処理
次に、乱数の生成方法について説明する。乱数の生成方法としては、熱雑音を増幅し、そのＡ／Ｄ出力から生成する真性乱数生成法や、Ｍ系列等の線形回路を複数組み合わせて生成する疑似乱数生成法等が知られている。また、ＤＥＳ等の共通鍵暗号を用いて生成する方法も知られている。本例では、ＤＥＳを用いた疑似乱数生成方法について説明する（ANSI X9.17ベース）。
【０１２８】
まず、時間等のデータから得られた６４ビット（これ以下のビット数の場合、上位ビットを0とする）の値をＤ、Ｔｒｉｐｌｅ−ＤＥＳに使われる鍵情報をＫｒ、乱数発生用の種（Ｓｅｅｄ）をＳとする。このとき、乱数Ｒは以下のように計算される。
【０１２９】
【数２】

【０１３０】
ここで、Ｔｒｉｐｌｅ−ＤＥＳ（）は、第１引数を暗号鍵情報として、第２引数の値をＴｒｉｐｌｅ−ＤＥＳで暗号化する関数とし、演算＾は６４ビット単位の排他的論理和、最終的にでてきた値Ｓは、新規のＳｅｅｄ（種）として更新されていくものとする。
【０１３１】
以下、連続して乱数を生成する場合には、（２−２）式、（２−３）式を繰り返すものとする。
【０１３２】
以上、本発明のデータ処理装置において適用可能な暗号処理に関する各種処理態様について説明した。次に、本発明のデータ処理装置において実行される具体的な処理について、詳細に説明する。
【０１３３】
（４）記録再生器の格納データ構成
図１８は、図３で示す記録再生器３００での記録再生器暗号処理部３０２に構成された内部メモリ３０７のデータ保持内容を説明する図である。
【０１３４】
図１８に示すように、内部メモリ３０７には、以下の鍵、データが格納されている。
ＭＫａｋｅ：記録再生器３００と記録デバイス４００（図３参照）との間で実行される相互認証処理に必要な認証鍵（Authentication and Key Exchange Key（以下、Ｋａｋｅとする））を生成するための記録デバイス認証鍵用マスター鍵。
ＩＶａｋｅ：記録デバイス認証鍵用初期値。
ＭＫｄｉｓ：配送鍵Ｋｄｉｓを生成するための配送鍵用マスター鍵。
ＩＶｄｉｓ：配送鍵生成用初期値。
Ｋｉｃｖａ：チェック値ＩＣＶａを生成するための鍵であるチェック値Ａ生成鍵。
Ｋｉｃｖｂ：チェック値ＩＣＶｂを生成するための鍵であるチェック値Ｂ生成鍵。
Ｋｉｃｖｃ：各コンテンツブロックのチェック値ＩＣＶｉ（ｉ＝１〜Ｎ）を生成するための鍵であるコンテンツチェック値生成鍵。
Ｋｉｃｖｔ：総チェック値ＩＣＶｔを生成するための鍵である総チェック値生成鍵。
Ｋｓｙｓ：配信システムに共通の署名またはＩＣＶをつけるために使用するシステム署名鍵。
Ｋｄｅｖ：記録再生器毎に異なり、記録再生器が署名またはＩＣＶをつけるために使用する記録再生器固有の記録再生器署名鍵。
ＩＶｍｅｍ：初期値、相互認証処理等の際の暗号処理に用いられる初期値。記録デバイスと共通。
これらの鍵、データが記録再生器暗号処理部３０２に構成された内部メモリ３０７に格納されている。
【０１３５】
（５）記録デバイスの格納データ構成
図１９は、記録デバイス上でのデータ保持状況を示す図である。図１９において、内部メモリ４０５は、複数のブロック（本例ではＮブロック）に分割されており、それぞれのブロック中に、以下の鍵、データが格納されている。
ＩＤｍｅｍ：記録デバイス識別情報、記録デバイス固有の識別情報。
Ｋａｋｅ：認証鍵、記録再生器３００との相互認証時に用いる認証鍵。
ＩＶｍｅｍ：初期値、相互認証処理等の際の暗号処理に用いられる初期値。
Ｋｓｔｒ：保存鍵、ブロック情報鍵他のコンテンツデータの暗号鍵。
Ｋｒ：乱数生成鍵、
Ｓ：種
これらのデータを個別のブロックに各々保持している。外部メモリ４０２は複数（本例ではＭ個）のコンテンツデータを保持しており、それぞれ図４で説明したデータを、例えば図２６、または図２７のように保持している。図２６、図２７の構成の差異については後段で説明する。
【０１３６】
（６）記録再生器、記録デバイス間における相互認証処理
（６−１）相互認証処理の概要
図２０は、記録再生器３００と記録デバイス４００との認証手順を示す流れ図である。ステップＳ４１において、利用者が記録デバイス４００を記録再生器３００に挿入する。ただし非接触で通信できる記録デバイスを使用する場合には、挿入する必要はない。
【０１３７】
記録再生器３００に記録デバイス４００をセットすると、図３に示す記録再生器３００内の記録デバイス検知手段（図示せず）が、制御部３０１に記録デバイス４００の装着を通知する。次に、ステップＳ４２において、記録再生器３００の制御部３０１は、記録デバイスコントローラ３０３を介して記録デバイス４００に初期化命令を送信する。これを受信した記録デバイス４００は、記録デバイス暗号処理部４０１の制御部４０３において、通信部４０４を介して命令を受信し、認証完了フラグがセットされていればクリアする。すなわち未認証状態に設定する。
【０１３８】
次に、ステップＳ４３において、記録再生器３００の制御部３０１は、記録再生器暗号処理部３０２に初期化命令を送信する。このとき、記録デバイス挿入口番号も併せて送信する。記録デバイス挿入口番号を送信することにより、記録再生器３００に複数の記録デバイスが接続された場合であっても同時に複数の記録デバイス４００との認証処理、およびデータ送受信が可能となる。
【０１３９】
初期化命令を受信した記録再生器３００の記録再生器暗号処理部３０２は、記録再生器暗号処理部３０２の制御部３０６において、記録デバイス挿入口番号に対応する認証完了フラグがセットされていればクリアする。すなわち未認証状態に設定する。
【０１４０】
次に、ステップＳ４４において、記録再生器３００の制御部３０１は、記録デバイス４００の記録デバイス暗号処理部４０１が使う鍵ブロック番号を指定する。なお、鍵ブロック番号の詳細に関しては後述する。ステップＳ４５において、記録再生器３００の制御部３０１は、記録デバイス４００の内部メモリ４０５の指定された鍵ブロックに格納された記録デバイス識別情報ＩＤｍｅｍを読み出す。ステップＳ４６において、記録再生器３００の制御部３０１は、記録再生器暗号処理部３０２に記録デバイス識別情報ＩＤｍｅｍを送信し、記録デバイス識別情報ＩＤｍｅｍに基づく認証鍵Ｋａｋｅを生成させる。認証鍵Ｋａｋｅの生成方法としては、例えば次のように生成する。
【０１４１】
【数３】

【０１４２】
ここで、ＭＫａｋｅは、記録再生器３００と記録デバイス４００（図３参照）との間で実行される相互認証処理に必要な認証鍵Ｋａｋｅを生成するための記録デバイス認証鍵用マスター鍵であり、これは、前述したように記録再生器３００の内部メモリ３０７に格納されている鍵である。またＩＤｍｅｍは、記録デバイス４００に固有の記録デバイス識別情報である。さらにＩＶａｋｅは、記録デバイス認証鍵用初期値である。また、上記式において、ＤＥＳ（）は、第１引数を暗号鍵として、第２引数の値をＤＥＳで暗号化する関数であり、演算＾は６４ビット単位の排他的論理和を示す。
【０１４３】
例えば図７、図８に示すＤＥＳ構成を適用する場合には、図７，８に示されるメッセージＭを記録デバイス識別情報：ＩＤｍｅｍとし、鍵Ｋ１をデバイス認証鍵用マスター鍵：ＭＫａｋｅとし、初期値ＩＶを：ＩＶａｋｅとして得られる出力が認証鍵Ｋａｋｅとなる。
【０１４４】
次に、ステップＳ４７で相互認証およびセッション鍵Ｋｓｅｓの生成処理を行う。相互認証は、記録再生器暗号処理部３０２の暗号／復号化部３０８と記録デバイス暗号処理部４０１の暗号／復号化部４０６の間で行われ、その仲介を記録再生器３００の制御部３０１が行っている。
【０１４５】
相互認証処理は、例えば前述の図１３で説明した処理にしたがって実行することができる。図１３に示す構成において、Ａ、Ｂがそれぞれ記録再生器３００と記録デバイス４００に対応する。まず、記録再生器３００の記録再生器暗号処理部３０２が乱数Ｒｂを生成し、乱数Ｒｂおよび自己のＩＤである記録再生器識別情報ＩＤｄｅｖを記録デバイス４００の記録デバイス暗号処理部４０１に送信する。なお、記録再生器識別情報ＩＤｄｅｖは、記録再生器３００内に構成された記憶部に記憶された再生器固有の識別子である。記録再生器暗号処理部３０２の内部メモリ中に記録再生器識別情報ＩＤｄｅｖを記録する構成としてもよい。
【０１４６】
乱数Ｒｂおよび記録再生器識別情報ＩＤｄｅｖを受信した記録デバイス４００の記録デバイス暗号処理部４０１は、新たに６４ビットの乱数Ｒａを生成し、Ｒａ、Ｒｂ、と記録再生器識別情報ＩＤｄｅｖの順に、ＤＥＳのＣＢＣモードで認証鍵Ｋａｋｅを用いてデータを暗号化し、記録再生器３００の記録再生器暗号処理部３０２に返送する。例えば、図７に示すＤＥＳのＣＢＣモード処理構成によれば、ＲａがＭ１、ＲｂがＭ２、ＩＤｄｅｖがＭ３に相当し、初期値：ＩＶ＝ＩＶｍｅｍとしたときの出力Ｅ１、Ｅ２、Ｅ３が暗号文となる。
【０１４７】
暗号文Ｅ１、Ｅ２、Ｅ３を受信した記録再生器３００の記録再生器暗号処理部３０２は、受信データを認証鍵Ｋａｋｅで復号化する。受信データの復号化方法は、まず、暗号文Ｅ１を認証鍵Ｋａｋｅで復号化し、その結果とＩＶｍｅｍとを排他的論理和し、乱数Ｒａを得る。次に、暗号文Ｅ２を認証鍵Ｋａｋｅで復号化し、その結果とＥ１を排他的論理和し、Ｒｂを得る。最後に、暗号文Ｅ３を認証鍵Ｋａｋｅで復号化し、その結果とＥ２を排他的論理和し、記録再生器識別情報ＩＤｄｅｖを得る。こうして得られたＲａ、Ｒｂ、記録再生器識別情報ＩＤｄｅｖの内、Ｒｂおよび記録再生器識別情報ＩＤｄｅｖが、記録再生器３００が送信したものと一致するか検証する。この検証に通った場合、記録再生器３００の記録再生器暗号処理部３０２は記録デバイス４００を正当なものとして認証する。
【０１４８】
次に、記録再生器３００の記録再生器暗号処理部３０２は、認証後に使用するセッション鍵（Session Key（以下、Ｋｓｅｓとする））を生成する（生成方法は、乱数を用いる）。そして、Ｒｂ、Ｒａ、Ｋｓｅｓの順に、ＤＥＳのＣＢＣモードで鍵Ｋａｋｅ、初期値ＩＶｍｅｍを用いて暗号化し、記録デバイス４００の記録デバイス暗号処理部４０１に返送する。
【０１４９】
これを受信した記録デバイス４００の記録デバイス暗号処理部４０１は、受信データを鍵Ｋａｋｅで復号化する。受信データの復号化方法は、記録再生器３００の記録再生器暗号処理部３０２における復号化処理と同様であるので、ここでは詳細を省略する。こうして得られたＲｂ、Ｒａ、Ｋｓｅｓの内、ＲｂおよびＲａが、記録デバイス４００が送信したものと一致するか検証する。この検証に通った場合、記録デバイス４００の記録デバイス暗号処理部４０１は記録再生器３００を正当なものとして認証する。互いに相手を認証した後には、セッション鍵Ｋｓｅｓは、認証後の秘密通信のための共通鍵として利用される。
【０１５０】
なお、受信データの検証の際に、不正、不一致が見つかった場合には、相互認証が失敗したものとして処理を中断する。
【０１５１】
相互認証に成功した場合には、ステップＳ４８からステップＳ４９に進み、セッション鍵Ｋｓｅｓを記録再生器３００の記録再生器暗号処理部３０２で保持するとともに、相互認証が終了したことを示す認証完了フラグをセットする。また、相互認証に失敗した場合には、ステップＳ５０に進み、認証処理過程で生成されたセッション鍵Ｋｓｅｓを破棄するとともに、認証完了フラグをクリアする。なお、すでにクリアされている場合には必ずしもクリア処理は必要ではない。
【０１５２】
なお、記録デバイス４００が記録デバイス挿入口から取り除かれた場合には、記録再生器３００内の記録デバイス検知手段が、記録再生器３００の制御部３０１に記録デバイス４００が取り除かれたことを通知し、これを受けた記録再生器３００の制御部３０１は、記録再生器３００の記録再生器暗号処理部３０２に対し記録デバイス挿入口番号に対応する認証完了フラグをクリアするように命令し、これを受けた記録再生器３００の記録再生器暗号処理部３０２は、記録デバイス挿入口番号に対応する認証完了フラグをクリアする。
【０１５３】
なお、ここでは相互認証処理を図１３に示す手続きにしたがって実行する例について説明したが、上述した認証処理例に限らず、例えば先に説明した図１５の相互認証手続きに従った処理を実行してもよい。また、図１３に示す手続きにおいて、図１３のＡを記録再生器３００とし、Ｂを記録デバイス４００とし、Ｂ：記録デバイス４００がＡ：記録再生器３００に最初に送付するＩＤを記録デバイス中の鍵ブロック中の記録デバイス識別情報として相互認証処理を行なってもよい。本発明において実行される認証処理手続きは、様々な処理が適用可能であり、上述の認証処理に限定されるものではない。
【０１５４】
（６−２）相互認証時の鍵ブロックの切り替え
本発明のデータ処理装置における相互認証処理における１つの特徴は、記録デバイス４００側に複数の鍵ブロック（ｅｘ．Ｎ個の鍵ブロック）を構成して、記録再生器３００が１つの鍵ブロックを指定（図２０の処理フローにおけるステップＳ４４）して認証処理を実行する点である。先に図１９において説明したように、記録デバイス４００の暗号処理部４０１に構成された内部メモリ４０５には複数の鍵ブロックが形成されており、それぞれが異なる鍵データ、ＩＤ情報等各種データを格納している。図２０で説明した記録再生器３００と記録デバイス４００間で実行される相互認証処理は、図１９の記録デバイス４００の複数の鍵ブロックの１つの鍵ブロックに対して実行される。
【０１５５】
従来、記憶媒体とその再生機器間における相互認証処理を実行する構成では、相互認証に用いる鍵：認証鍵は共通なものが使用されるのが一般的であった。従って、例えば製品仕向け先（国別）ごと、あるいは製品ごとに認証鍵を変更しようとすると、記録再生器側と、記録デバイス側の認証処理に必要となる鍵データを双方の機器において変更することが必要となる。従って例えば新たに発売された記録再生器に格納された認証処理に必要となる鍵データは、先に販売された記録デバイスに格納された認証処理に必要となる鍵データに対応せず、新たな記録再生器は、古いバージョンの記録デバイスへのアクセスができなくなってしまう事態が発生する。逆に新しいバージョンの記録デバイスと古いバージョンの記録再生器との関係においても同様の事態が発生する。
【０１５６】
本発明のデータ処理装置においては、図１９に示すように予め記録デバイス４００に複数の異なる鍵セットとしての鍵ブロックが格納されている。記録再生器は例えば製品仕向け先（国別）ごと、あるいは製品、機種、バージョン、アプリケーションごとに、認証処理に適用すべき鍵ブロック、すなわち指定鍵ブロックが設定される。この設定情報は、記録再生器のメモリ部、例えば、図３における内部メモリ３０７、あるいは、記録再生器３００の有するその他の記憶素子内に格納され、認証処理時に図３の制御部３０１によってアクセスされ設定情報にしたがった鍵ブロック指定が行われる。
【０１５７】
記録再生器３００の内部メモリ３０７の記録デバイス認証鍵用マスター鍵ＭＫａｋｅは、それぞれの指定鍵ブロックの設定に従って設定された認証鍵用マスター鍵であり、指定鍵ブロックにのみ対応可能となっており、指定鍵ブロック以外の鍵ブロックとの相互認証は成立しない構成となっている。
【０１５８】
図１９から理解されるように、記録デバイス４００の内部メモリ４０５には１〜ＮのＮ個の鍵ブロックが設定され、各鍵ブロック毎に記録デバイス識別情報、認証鍵、初期値、保存鍵、乱数生成鍵、種が格納され、少なくとも認証用のかぎデータがブロック毎に異なるデータとして格納されている。
【０１５９】
このように、記録デバイス４００の鍵ブロックの鍵データ構成は、ブロック毎に異なっている。従って、例えば、ある記録再生機器Ａが内部メモリに格納された記録デバイス認証鍵用マスター鍵ＭＫａｋｅを用いて認証処理を行ない得る鍵ブロックは鍵ブロックＮｏ．１であり、また別の仕様の記録再生器Ｂが認証可能な鍵ブロックは別の鍵ブロック、例えば鍵ブロックＮｏ．２のように設定することが可能となる。
【０１６０】
後段でさらに詳細に説明するが、コンテンツを記録デバイス４００の外部メモリ４０２に格納する際、各鍵ブロックに格納された保存鍵Ｋｓｔｒを用いて暗号化処理がなされ、格納されることになる。より、具体的には、コンテンツブロックを暗号化するコンテンツ鍵を保存鍵で暗号化処理する。
【０１６１】
図１９に示すように保存鍵は、各ブロック毎に異なる鍵として構成されている。従って、異なる鍵ブロックを指定するように設定された２つの異なる設定の記録再生器間においては、ある１つの記録デバイスのメモリに格納されたコンテンツを両者で共通に利用することは防止される。すなわち、異なる設定のなされた記録再生器は、それぞれの設定に合致する記録デバイスに格納されたコンテンツのみが利用できる。
【０１６２】
なお、各鍵ブロックについて共通化可能なデータは共通化することも可能であり、例えば認証用の鍵データ、保存鍵データのみを異なるように構成してもよい。
【０１６３】
このような記録デバイスに複数の異なる鍵データからなる鍵ブロックを構成する具体例としては、例えば記録再生器３００の機種別（据え置き型、携帯型等）で指定すべき鍵ブロック番号を異なるように設定したり、あるいは、アプリケーション毎に指定鍵ブロックを異なるように設定する例がある。さらに、例えば日本で販売する記録再生器については指定鍵ブロックをＮｏ．１とし、米国で販売する記録再生器は指定鍵ブロックをＮｏ．２とするように地域ごとに異なる鍵ブロック設定を行なう構成とすることも可能である。このような構成とすることで、それぞれの異なる販売地域で使用され、記録デバイスに異なる保存鍵で格納されたコンテンツは、たとえメモリカードのような記録デバイスが米国から日本、あるいは日本から米国へ転送されてきても、異なる鍵設定のなされた記録再生器で利用することは不可能であるので、メモリに格納したコンテンツの不正、無秩序な流通を防止できる。具体的には、異なる保存鍵Ｋｓｔｒで暗号化されているコンテンツ鍵Ｋｃｏｎが２国間で相互に利用可能となる状態を排除することができる。
【０１６４】
さらに、図１９に示す記録デバイス４００の内部メモリ４０５の鍵ブロック１〜Ｎまでの少なくとも１つの鍵ブロック、例えばＮｏ．Ｎの鍵ブロックをいずれの記録再生器３００においても共通に利用可能な鍵ブロックとして構成してもよい。
【０１６５】
例えば、全ての機器に鍵ブロックＮｏ．Ｎとの認証可能な記録デバイス認証鍵用マスター鍵ＭＫａｋｅを格納することで、記録再生器３００の機種別、アプリケーション毎、仕向け国毎等に無関係に流通可能なコンテンツとして扱うことができる。例えば、鍵ブロックＮｏ．Ｎに格納された保存鍵でメモリカードに格納された暗号化コンテンツは、すべての機器において利用可能なコンテンツとなる。例えば、音楽データ等を共通に利用可能な鍵ブロックの保存鍵で暗号化してメモリカードに記憶し、このメモリカードを、やはり共通の記録デバイス認証鍵用マスター鍵ＭＫａｋｅを格納した例えば携帯型の音声再生機器等にセットすることで、メモリカードからのデータの復号再生処理を可能とすることができる。
【０１６６】
本発明のデータ処理装置における複数の鍵ブロックを有する記録デバイスの利用例を図２１に示す。記録再生器２１０１は日本向け製品の記録再生器であり、記録デバイスの鍵ブロックのＮｏ．１，４との間での認証処理が成立するマスター鍵を持っている。記録再生器２１０２はＵＳ向け製品の記録再生器であり、記録デバイスの鍵ブロックのＮｏ．２，４との間での認証処理が成立するマスター鍵を持っている。記録再生器２１０３はＥＵ向け製品の記録再生器であり、記録デバイスの鍵ブロックのＮｏ．３，４との間での認証処理が成立するマスター鍵を持っている。
【０１６７】
例えば記録再生器２１０１は、記録デバイスＡ，２１０４の鍵ブロック１または鍵ブロック４との間で認証が成立し、それぞれの鍵ブロックに格納された保存鍵を介した暗号処理を施したコンテンツが外部メモリに格納される。記録再生器２１０２は、記録デバイスＢ，２１０５の鍵ブロック２または鍵ブロック４との間で認証が成立し、それぞれの鍵ブロックに格納された保存鍵を介した暗号処理を施したコンテンツが外部メモリに格納される。記録再生器２１０３は、記録デバイスＣ，２１０６の鍵ブロック３または鍵ブロック４との間で認証が成立し、それぞれの鍵ブロックに格納された保存鍵を介した暗号処理を施したコンテンツが外部メモリに格納される。ここで、記録デバイスＡ，２１０４を記録再生器２１０２、または記録再生器２１０３に装着した場合、鍵ブロック１の保存鍵で暗号処理がなされたコンテンツは、記録再生器２１０２、記録再生器２１０３と鍵ブロック１との間での認証が成立しないので利用不可能となる。一方、鍵ブロック４の保存鍵で暗号処理がなされたコンテンツは、記録再生器２１０２、記録再生器２１０３と鍵ブロック４との間での認証が成立するので利用可能となる。
【０１６８】
上述のように、本発明のデータ処理装置においては、記録デバイスに複数の異なる鍵セットからなる鍵ブロックを構成し、一方、記録再生機器には、特定の鍵ブロックに対する認証可能なマスター鍵を格納する構成としたので、様々な利用態様に応じたコンテンツの利用制限を設定することが可能となる。
【０１６９】
なお、１つの記録再生機器において指定可能な鍵ブロックを複数、例えば１〜ｋとし、他の記録再生器において指定可能な鍵ブロックをｐ〜ｑのように複数とすることも可能であり、また、共通に利用可能な鍵ブロックを複数設ける構成としてもよい。
【０１７０】
（７）記録再生器から記録デバイスへのダウンロード処理
次に、本発明のデータ処理装置において、記録再生器３００から記録デバイス４００の外部メモリにコンテンツをダウンロードする処理について説明する。
【０１７１】
図２２は、記録再生器３００から記録デバイス４００へコンテンツをダウンロードする手順を説明する流れ図である。なお、図２２においては、既に記録再生器３００と記録デバイス４００との間で上述した相互認証処理が完了しているものとする。
【０１７２】
ステップＳ５１において、記録再生器３００の制御部３０１は、読み取り部３０４を使ってコンテンツを格納したメディア５００から所定のフォーマットに従ったデータを読み出すか、通信部３０５を使って通信手段６００から所定のフォーマットに従ってデータを受信する。そして、記録再生器３００の制御部３０１は、データの内のヘッダ（Header）部分（図４参照）を記録再生器３００の記録再生器暗号処理部３０２に送信する。
【０１７３】
次に、ステップＳ５２において、ステップＳ５１でヘッダ（Header）を受信した記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にチェック値Ａを計算させる。チェック値Ａは、図２３に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ａ生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして図７で説明したＩＣＶ計算方法に従って計算される。なお、初期値は、ＩＶ＝０としても、記録再生器暗号処理部３０２の内部メモリ３０７にチェック値Ａ生成用初期値ＩＶａを保存しておき、それを使用してもよい。最後に、チェック値Ａとヘッダ（Header）内に格納されたチェック値：ＩＣＶａを比較し、一致していた場合にはステップＳ５３へ進む。
【０１７４】
先に図４において説明したようにチェック値Ａ，ＩＣＶａは、識別情報、取扱方針の改竄を検証するためのチェック値である。記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ａ生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして図７で説明したＩＣＶ計算方法に従って計算されるチェック値Ａが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶａと一致した場合には、識別情報、取扱方針の改竄はないと判断される。
【０１７５】
次に、ステップＳ５３において、記録再生器暗号処理部３０２の制御部３０６は、配送鍵Ｋｄｉｓの生成を記録再生器暗号処理部３０２の暗号／復号化部３０８に行わせる。配送鍵Ｋｄｉｓの生成方法としては、例えば次のように生成する。
【０１７６】
【数４】

【０１７７】
ここで、ＭＫｄｉｓは、配送鍵Ｋｄｉｓを生成するための配送鍵用マスター鍵であり、これは、前述したように記録再生器３００の内部メモリに格納されている鍵である。またＣｏｎｔｅｎｔ ＩＤはコンテンツデータのヘッダ部の識別情報であり、さらにＩＶｄｉｓは、配送鍵用初期値である。また、上記式において、ＤＥＳ（）は、第1引数を暗号鍵として、第２引数の値を暗号化する関数であり、演算＾は６４ビット単位の排他的論理和を示す。
【０１７８】
ステップＳ５４において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８を使って、ステップＳ５３で生成した配送鍵Ｋｄｉｓを用いて、読み取り部３０４を介して受信したメディア５００、または、通信部３０５を介して通信手段６００から受信したデータのヘッダ部に格納されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎ（図４参照）の復号化処理を行う。図４に示されるようにこれらブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎは、ＤＶＤ，ＣＤ等のメディア、あるいはインターネット等の通信路上では、配送鍵Ｋｄｉｓによって予め暗号化処理が施されている。
【０１７９】
さらに、ステップＳ５５において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８を使って、ステップＳ５４で復号化したブロック情報鍵Ｋｂｉｔでブロック情報（ＢＩＴ）を復号化する。図４に示されるようにブロック情報（ＢＩＴ）は、ＤＶＤ，ＣＤ等のメディア、あるいはインターネット等の通信路上では、ブロック情報鍵Ｋｂｉｔによって予め暗号化処理が施されている。
【０１８０】
さらに、ステップＳ５６において、記録再生器暗号処理部３０２の制御部３０６は、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）を８バイト単位に分割し、それら全てを排他的論理和する（加算、減算等、いずれの演算でもよい）。次に、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にチェック値Ｂ（ＩＣＶｂ）を計算させる。チェック値Ｂは、図２４に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、先ほど計算した排他的論理和値をＤＥＳで暗号化して生成する。最後に、チェック値ＢとHeader内のＩＣＶｂを比較し、一致していた場合にはステップＳ５７へ進む。
【０１８１】
先に図４において説明したように、チェック値Ｂ，ＩＣＶｂは、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報（ＢＩＴ）の改竄を検証するためのチェック値である。記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）を８バイト単位に分割し排他的論理和して得られる値をＤＥＳで暗号化して生成したチェック値Ｂが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶｂと一致した場合には、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄はないと判断される。
【０１８２】
ステップＳ５７において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に中間チェック値の計算をさせる。中間チェック値は、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されている総チェック値生成鍵Ｋｉｃｖｔを鍵とし、検証したヘッダ（Header）内のチェック値Ａ、チェック値Ｂ、保持しておいた全てのコンテンツチェック値をメッセージとして図７で説明したＩＣＶ計算方法に従って計算する。なお、初期値ＩＶ=0としても、記録再生器暗号処理部３０２の内部メモリ３０７に総チェック値生成用初期値ＩＶｔを保存しておき、それを使用してもよい。また、生成した中間チェック値は、必要に応じて記録再生器３００の記録再生器暗号処理部３０２に保持しておく。
【０１８３】
この中間チェック値は、チェック値Ａ、チェック値Ｂ、全てのコンテンツチェック値をメッセージとして生成されるものであり、これらの各チェック値の検証対象となっているデータについての検証を中間チェック値の照合処理によって行なってもよい。しかし、本実施例においては、システム全体の共有データとしての非改竄性検証処理と、ダウンロード処理後に各記録再生機器３００のみが占有する占有データとして識別するための検証処理を区別して実行可能とするために、中間チェック値からさらに複数の異なるチェック値、すなわち総チェック値ＩＣＶｔと、記録再生器固有チェック値ＩＣＶｄｅｖとを別々に、中間チェック値に基づいて生成可能としている。これらのチェック値については後段で説明する。
【０１８４】
記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に総チェック値ＩＣＶｔの計算をさせる。総チェック値ＩＣＶｔは、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているシステム署名鍵Ｋｓｙｓを鍵とし、中間チェック値をＤＥＳで暗号化して生成する。最後に、生成した総チェック値ＩＣＶｔとステップＳ５１で保存しておいたHeader内のＩＣＶｔを比較し、一致していた場合には、ステップＳ５８へ進む。システム署名鍵Ｋｓｙｓは、複数の記録再生器、すなわちある一定のデータの記録再生処理を実行するシステム集合全体において共通する署名鍵である。
【０１８５】
先に図４において説明したように、総チェック値ＩＣＶｔは、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄を検証するためのチェック値である。従って、上述の処理によって生成された総チェック値がヘッダ（Header）内に格納されたチェック値：ＩＣＶｔと一致した場合には、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄はないと判断される。
【０１８６】
次に、ステップＳ５８において、記録再生器３００の制御部３０１は、ブロック情報（ＢＩＴ）内のコンテンツブロック情報を取り出し、コンテンツブロックが検証対象になっているかいないか調べる。コンテンツブロックが検証対象になっている場合には、ヘッダ中のブロック情報中にコンテンツチェック値が格納されている。
【０１８７】
コンテンツブロックが検証対象になっていた場合には、該当するコンテンツブロックを、記録再生器３００の読み取り部３０４を使ってメディア５００から読み出すか、記録再生器３００の通信部３０５を使って通信手段６００から受信し、記録再生器３００の記録再生器暗号処理部３０２へ送信する。これを受信した記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にコンテンツ中間値を計算させる。
【０１８８】
コンテンツ中間値は、ステップＳ５４で復号化したコンテンツ鍵Ｋｃｏｎで、入力されたコンテンツブロックをＤＥＳのＣＢＣモードで復号化し、その結果を８バイトごとに区切り、全て排他的論理和（加算、減算等、いずれの演算でもよい）して生成する。
【０１８９】
次に、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にコンテンツチェック値の計算をさせる。コンテンツチェック値は、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているコンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とし、コンテンツ中間値をＤＥＳで暗号化して生成する。そして、記録再生器暗号処理部３０２の制御部３０６は、当該コンテンツチェック値と、ステップＳ５１で記録再生器３００の制御部３０１から受信したコンテンツブロック内のＩＣＶを比較し、その結果を記録再生器３００の制御部３０１に渡す。これを受信した記録再生器３００の制御部３０１は、検証に成功していた場合、次の検証対象コンテンツブロックを取り出して記録再生器３００の記録再生器暗号処理部３０２に検証させ、全てのコンテンツブロックを検証するまで同様の検証処理を繰り返す。なお、Ｈｅａｄｅｒ生成側と合わせておけば、ＩＶ＝０としても、記録再生器暗号処理部３０２の内部メモリ３０７にコンテンツチェック値生成用初期値ＩＶｃを保存しておき、それを使用してもよい。また、チェックした全てのコンテンツチェック値は、記録再生器３００の記録再生器暗号処理部３０２に保持しておく。さらにまた、記録再生器３００の記録再生器暗号処理部３０２は、検証対象のコンテンツブロックの検証順序を監視し、順序が間違っていたり、同一のコンテンツブロックを２回以上検証させられたりした場合には、認証に失敗したものとする。そして、全ての検証が成功した場合には、ステップＳ５９へ進む。
【０１９０】
次に、ステップＳ５９において、記録再生器３００の記録再生器暗号処理部３０２は、ステップＳ５４で復号化しておいたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを、記録再生器暗号処理部３０２の暗号／復号化部３０８に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで暗号化させる。記録再生器３００の制御部３０１は、セッション鍵Ｋｓｅｓで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを記録再生器３００の記録再生器暗号処理部３０２から読み出し、これらのデータを記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０１９１】
次に、ステップＳ６０において、記録再生器３００から送信されてきたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化させ、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで再暗号化させる。最後に、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００から保存鍵Ｋｓｔｒで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを読み出す。そして、これらの鍵を、配送鍵Ｋｄｉｓで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎに置き換える。
【０１９２】
ステップＳ６１において、記録再生器３００の制御部３０１は、データのヘッダ部の取扱方針（Usage Policy）から利用制限情報を取り出し、ダウンロードしたコンテンツが当該記録再生器３００のみで利用できる（この場合、利用制限情報が１に設定）か、別の同様な記録再生器３００でも利用できる（この場合、利用制限情報が０に設定）か判定する。判定の結果、利用制限情報が１であった場合には、ステップＳ６２に進む。
【０１９３】
ステップＳ６２において、記録再生器３００の制御部３０１は、記録再生器固有のチェック値を記録再生器３００の記録再生器暗号処理部３０２に計算させる。記録再生器固有のチェック値は、図２５に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されている記録再生器署名鍵Ｋｄｅｖを鍵とし、ステップＳ５８で保持しておいた中間チェック値をＤＥＳで暗号化して生成する。計算された記録再生器固有のチェック値ＩＣＶｄｅｖは、総チェック値ＩＣＶｔの代わりに上書きされる。
【０１９４】
先に説明したように、システム署名鍵Ｋｓｙｓは、配信システムに共通の署名またはＩＣＶをつけるために使用するシステム署名鍵であり、また、記録再生器署名鍵Ｋｄｅｖは、記録再生器毎に異なり、記録再生器が署名またはＩＣＶをつけるために使用する記録再生器署名鍵である。すなわち、システム署名鍵Ｋｓｙｓによって署名されたデータは、同じシステム署名鍵を有するシステム（記録再生器）によってチェックが成功、すなわち総チェック値ＩＣＶｔが一致することになるので、共通に利用可能となるが、記録再生器署名鍵Ｋｄｅｖを用いて署名された場合には、記録再生器署名鍵はその記録再生器に固有の鍵であるので、記録再生器署名鍵Ｋｄｅｖを用いて署名されたデータ、すなわち、署名後、記録デバイスに格納されたデータは、他の記録再生器に、その記録デバイスを装着して再生しようとした場合、記録再生器固有のチェック値ＩＣＶｄｅｖが不一致となり、エラーとなるので再生できないことになる。
【０１９５】
従って、本発明のデータ処理装置においては、利用制限情報の設定によって、システムに共通に使用できるコンテンツ、記録再生器固有に利用できるコンテンツを自在に設定することが可能となる。
【０１９６】
ステップＳ６３において、記録再生器３００の制御部３０１は、コンテンツを記録デバイス４００の外部メモリ４０２に保存する。
【０１９７】
図２６は、利用制限情報が０の場合における記録デバイス内のコンテンツ状況を示す図である。図２７は、利用制限情報が１の場合における記録デバイス内のコンテンツ状況を示す図である。図２６が図４と異なる点は、コンテンツブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎが配送鍵Ｋｄｉｓで暗号化されているか、保存鍵Ｋｓｔｒで暗号化されているかだけである。また、図２７が図２６と異なる点は、中間チェック値から計算されるチェック値が、図２６ではシステム署名鍵Ｋｓｙｓで暗号化されているのに対し、図２７では記録再生器固有の記録再生器署名鍵Ｋｄｅｖで暗号化されていることである。
【０１９８】
なお、図２２の処理フローにおいて、ステップＳ５２でチェック値Ａの検証に失敗した場合、ステップＳ５６でチェック値Ｂの検証に失敗した場合、ステップＳ５７で総チェック値ＩＣＶｔの検証に失敗した場合、ステップＳ５８で各コンテンツブロックのコンテンツチェック値の検証に失敗した場合には、ステップＳ６４に進み、所定のエラー表示を行う。
【０１９９】
また、ステップＳ６１で利用制限情報が０であった場合には、ステップＳ６２をスキップしてステップＳ６３へ進む。
【０２００】
（８）記録デバイス格納情報の記録再生器での再生処理
次に記録デバイス４００の外部メモリ４０２に格納されたコンテンツ情報の記録再生器３００での再生処理について説明する。
【０２０１】
図２８は、記録再生器３００が記録デバイス４００からコンテンツを読み出し、コンテンツを利用する手順を説明する流れ図である。なお、図２８においても、既に記録再生器３００と記録デバイス４００との間で相互認証が完了しているものとする。
【０２０２】
ステップＳ７１において、記録再生器３００の制御部３０１は、記録デバイスコントローラ３０３を使って記録デバイス４００の外部メモリ４０２からコンテンツを読み出す。そして、記録再生器３００の制御部３０１は、データの内のヘッダ（Header）部分を記録再生器３００の記録再生器暗号処理部３０２に送信する。ステップＳ７２は、「（７）記録再生器から記録デバイスへのダウンロード処理」において説明したステップＳ５２と同様の処理であり、ヘッダ（Header）を受信した記録再生器暗号処理部３０２の制御部３０６が、記録再生器暗号処理部３０２の暗号／復号化部３０８にチェック値Ａを計算させる処理である。チェック値Ａは、先に説明した図２３に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値A生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして図７で説明したと同様のＩＣＶ計算方法に従って計算される。
【０２０３】
先に説明したようにチェック値Ａ，ＩＣＶａは、識別情報、取扱方針の改竄を検証するためのチェック値である。記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ａ生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして図７で説明したICV計算方法に従って計算されるチェック値Ａが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶａと一致した場合には、記録デバイス４００に格納された識別情報、取扱方針の改竄はないと判断される。
【０２０４】
次に、ステップＳ７３において、記録再生器３００の制御部３０１は、読み出したヘッダ（Header）部分からブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを取り出し、記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。記録再生器３００から送信されてきたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで復号化処理させ、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで再暗号化させる。そして、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００からセッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを読み出す。
【０２０５】
次に、ステップＳ７４において、記録再生器３００の制御部３０１は、受信したセッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを記録再生器３００の記録再生器暗号処理部３０２に送信する。
【０２０６】
セッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信した記録再生器３００の記録再生器暗号処理部３０２は、記録再生器暗号処理部３０２の暗号／復号化部３０８に、セッション鍵Ｋｓｅｓで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化させる。そして、復号化したブロック情報鍵Ｋｂｉｔで、ステップＳ７１で受信しておいたブロック情報を復号化させる。
【０２０７】
なお、記録再生器３００の記録再生器暗号処理部３０２は、復号化したブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報ＢＩＴを、ステップＳ７１で受信しておいたブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報ＢＩＴに置き換えて保持しておく。また、記録再生器３００の制御部３０１は、復号化されたブロック情報ＢＩＴを記録再生器３００の記録再生器暗号処理部３０２から読み出しておく。
【０２０８】
ステップＳ７５は、「（７）記録再生器から記録デバイスへのダウンロード処理」において説明したステップＳ５６と同様の処理である。記録再生器暗号処理部３０２の制御部３０６が、記録デバイス４００から読み出したブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）を８バイト単位に分割し、それら全てを排他的論理和する。次に、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にチェック値Ｂ（ＩＣＶｂ）を計算させる。チェック値Ｂは、先に説明した図２４に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、先ほど計算した排他的論理和値をＤＥＳで暗号化して生成する。最後に、チェック値ＢとHeader内のＩＣＶｂを比較し、一致していた場合にはステップＳ７６へ進む。
【０２０９】
先に説明したように、チェック値Ｂ，ＩＣＶｂは、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄を検証するためのチェック値である。記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、記録デバイス４００から読み出したブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）を８バイト単位に分割し排他的論理和して得られる値をＤＥＳで暗号化して生成したチェック値Ｂが、記録デバイス４００から読み出したデータ中のヘッダ（Header）内に格納されたチェック値：ＩＣＶｂと一致した場合には、記録デバイス４００に格納されたデータのブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄はないと判断される。
【０２１０】
ステップＳ７６において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に中間チェック値の計算をさせる。中間チェック値は、先に説明した図２５に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されている総チェック値生成鍵Ｋｉｃｖｔを鍵とし、検証したヘッダ（Header）内のチェック値Ａ、チェック値Ｂ、保持しておいた全てのコンテンツチェック値をメッセージとして図７他で説明したＩＣＶ計算方法に従って計算する。なお、初期値はＩＶ＝０としても、記録再生器暗号処理部３０２の内部メモリ３０７に総チェック値生成用初期値にＩＶｔを保存しておき、それを使用してもよい。また、生成した中間チェック値は、必要に応じて記録再生器３００の記録再生器暗号処理部３０２に保持しておく。
【０２１１】
次に、ステップＳ７７において、記録再生器３００の制御部３０１は、記録デバイス４００の外部メモリ４０２から読み出したデータのヘッダ部に含まれる取扱方針（Usage Policy）から利用制限情報を取り出し、ダウンロードしたコンテンツが当該記録再生器３００のみで利用できる（利用制限情報が１）か、別の同様な記録再生器３００でも利用できる（利用制限情報が０）か判定する。判定の結果、利用制限情報が１、すなわちダウンロードしたコンテンツが当該記録再生器３００のみで利用できる利用制限が設定されている場合には、ステップＳ８０に進み、利用制限情報が０、すなわち別の同様な記録再生器３００でも利用できる設定であった場合には、ステップＳ７８に進む。なお、ステップＳ７７の処理は、暗号処理部３０２が行なってもよい。
【０２１２】
ステップＳ７８においては、（７）記録再生器から記録デバイスへのダウンロード処理において説明したステップＳ５８と同様の総チェック値ＩＣＶｔの計算が実行される。すなわち、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に総チェック値ＩＣＶｔの計算をさせる。総チェック値ＩＣＶｔは、先に説明した図２５に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されているシステム署名鍵Ｋｓｙｓを鍵とし、中間チェック値をＤＥＳで暗号化して生成する。
【０２１３】
次に、ステップＳ７９に進み、ステップＳ７８において生成した総チェック値ＩＣＶｔとステップＳ７１で保存しておいたヘッダ（Header）内のＩＣＶｔを比較し、一致していた場合には、ステップＳ８２へ進む。
【０２１４】
先に説明したように、総チェック値ＩＣＶｔは、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄を検証するためのチェック値である。従って、上述の処理によって生成された総チェック値がヘッダ（Header）内に格納されたチェック値：ＩＣＶｔと一致した場合には、記録デバイス４００に格納されたデータにおいて、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄はないと判断される。
【０２１５】
ステップＳ７７での判定において、ダウンロードしたコンテンツが当該記録再生器３００のみで利用できる設定であった場合、すなわち設定情報が１であった場合は、ステップＳ８０に進む。
【０２１６】
ステップＳ８０において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に、記録再生器固有のチェック値ＩＣＶｄｅｖの計算をさせる。記録再生器固有のチェック値ＩＣＶｄｅｖは、先に説明した図２５に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されている記録再生器固有の記録再生器署名鍵Ｋｄｅｖを鍵とし、中間チェック値をＤＥＳで暗号化して生成する。ステップＳ８１において、ステップＳ８０で計算した記録再生器固有のチェック値ＩＣＶｄｅｖとステップＳ７１で保存しておいたHeader内のＩＣＶｄｅｖを比較し、一致していた場合には、ステップＳ８２へ進む。
【０２１７】
このように、システム署名鍵Ｋｓｙｓによって署名されたデータは、同じシステム署名鍵を有するシステム（記録再生器）によってチェックが成功、すなわち総チェック値ＩＣＶｔが一致することになるので共通に利用可能となり、記録再生器署名鍵Ｋｄｅｖを用いて署名された場合には、記録再生器署名鍵はその記録再生器に固有の鍵であるので、記録再生器署名鍵Ｋｄｅｖを用いて署名されたデータ、すなわち、署名後、記録デバイスに格納されたデータは、他の記録再生器に、その記録デバイスを装着して再生しようとした場合、記録再生器固有のチェック値ＩＣＶｄｅｖが不一致となり、エラーとなるので再生できないことになる。従って、利用制限情報の設定によって、システムに共通に使用できるコンテンツ、記録再生器固有に利用できるコンテンツを自在に設定することが可能となる。
【０２１８】
ステップＳ８２において、記録再生器３００の制御部３０１は、ステップＳ７４で読み出しておいたブロック情報ＢＩＴ内のコンテンツブロック情報を取り出し、コンテンツブロックが暗号化対象になっているかいないか調べる。暗号化対象になっていた場合には、該当するコンテンツブロックを、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００の外部メモリ４０２から読み出し、記録再生器３００の記録再生器暗号処理部３０２へ送信する。これを受信した記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にコンテンツを復号化させるとともに、コンテンツブロックが検証対象になっている場合には次のステップＳ８３においてコンテンツチェック値を検証させる。
【０２１９】
ステップＳ８３は、「（７）記録再生器から記録デバイスへのダウンロード処理」において説明したステップＳ５８と同様の処理である。記録再生器３００の制御部３０１は、ブロック情報（ＢＩＴ）内のコンテンツブロック情報を取り出し、コンテンツブロックが検証対象になっているかいないかをコンテンツチェック値の格納状況から判定し、コンテンツブロックが検証対象になっていた場合には、該当するコンテンツブロックを、記録デバイス４００の外部メモリ４０２から受信し、記録再生器３００の記録再生器暗号処理部３０２へ送信する。これを受信した記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にコンテンツ中間値を計算させる。
【０２２０】
コンテンツ中間値は、ステップＳ７４で復号化したコンテンツ鍵Ｋｃｏｎで、入力されたコンテンツブロックをＤＥＳのＣＢＣモードで復号化し、その結果を８バイトに区切り全て排他的論理和して生成する。
【０２２１】
次に、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にコンテンツチェック値の計算をさせる。コンテンツチェック値は、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているコンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とし、コンテンツ中間値をＤＥＳで暗号化して生成する。そして、記録再生器暗号処理部３０２の制御部３０６は、当該コンテンツチェック値と、ステップＳ７１で記録再生器３００の制御部３０１から受信したコンテンツブロック内のＩＣＶを比較し、その結果を記録再生器３００の制御部３０１に渡す。これを受信した記録再生器３００の制御部３０１は、検証に成功していた場合、次の検証対象コンテンツブロックを取り出して記録再生器３００の記録再生器暗号処理部３０２に検証させ、全てのコンテンツブロックを検証するまで同様の検証処理を繰り返す。なお、初期値はＩＶ＝０としても、記録再生器暗号処理部３０２の内部メモリ３０７にコンテンツチェック値生成用初期値ＩＶｃを保存しておき、それを使用してもよい。また、チェックした全てのコンテンツチェック値は、記録再生器３００の記録再生器暗号処理部３０２に保持しておく。さらにまた、記録再生器３００の記録再生器暗号処理部３０２は、検証対象のコンテンツブロックの検証順序を監視し、順序が間違っていたり、同一のコンテンツブロックを2回以上検証させられたりした場合には、認証に失敗したものとする。
【０２２２】
記録再生器３００の制御部３０１は、当該コンテンツチェック値の比較結果（検証対象になっていない場合、比較結果は全て成功とする）を受信し、検証に成功していた場合には、記録再生器３００の記録再生器暗号処理部３０２から復号化されたコンテンツを取り出す。そして、次の復号化対象コンテンツブロックを取り出して記録再生器３００の記録再生器暗号処理部３０２に復号化させ、全てのコンテンツブロックを復号化するまで繰り返す。
【０２２３】
なお、ステップＳ８３において、記録再生器３００の記録再生器暗号処理部３０２は、コンテンツチェック値の検証処理において不一致となった場合には、検証失敗としてその時点で処理を中止し、残るコンテンツの復号化は行わない。また、記録再生器３００の記録再生器暗号処理部３０２は、復号化対象のコンテンツブロックの復号化順序を監視し、順序が間違っていたり、同一のコンテンツブロックを２回以上復号化させられたりした場合には、復号化に失敗したものとする。
【０２２４】
なお、ステップＳ７２でチェック値Ａの検証に失敗した場合、ステップＳ７５でチェック値Ｂの検証に失敗した場合、ステップＳ７９で総チェック値ＩＣＶｔの検証に失敗した場合、ステップＳ８１で記録再生器固有のチェック値ＩＣＶｄｅｖの検証に失敗した場合には、ステップＳ８３で各コンテンツブロックのコンテンツチェック値の検証に失敗した場合、ステップＳ８４に進み、所定のエラー表示を行う。
【０２２５】
以上説明してきたように、コンテンツをダウンロードしたり、利用したりする際に、重要なデータやコンテンツを暗号化しておいて隠蔽化したり、改竄検証ができるだけでなく、ブロック情報ＢＩＴを復号化するためのブロック情報鍵Ｋｂｉｔ、コンテンツを復号化するためのコンテンツ鍵Ｋｃｏｎが記録デバイス固有の保存鍵Ｋｓｔｒで保存されているため、単純に記録メディア上のデータを別の記録メディアに複製したとしても、コンテンツを正しく復号化することができなくすることができる。より具体的には、例えば図２８のステップＳ７４において、記録デバイス毎に異なる保存鍵Ｋｓｔｒで暗号化されたデータを復号化するため、別の記録デバイスではデータを正しく復号化できない構成を持つからである。
【０２２６】
（９）相互認証後の鍵交換処理
本発明のデータ処理装置における特徴の１つに、上述した記録再生器３００と記録デバイス４００との間で実行される相互認証処理の後においてのみ、記録デバイスの利用を可能とし、また、その利用態様を制限した点がある。
【０２２７】
例えば、不正な複製等によってコンテンツを格納したメモリカード等の記録デバイスを生成し、これを記録再生器にセットして利用されることを排除するために、記録再生器３００と、記録デバイス４００間での相互認証処理を実行し、かつ認証ＯＫとなったことを条件として、コンテンツ（暗号化された）の記録再生器３００および記録デバイス４００間での転送を可能としている。
【０２２８】
上記の制限的処理を実現するために、本発明のデータ処理装置においては、記録デバイス４００の暗号処理部４０１での処理は、すべて、予め設定されたコマンド列に基づいて実行される構成となっている。すなわち、記録デバイスは、コマンド番号に基づくコマンドを順次レジスタから取り出して実行するコマンド処理構成を持つ。この記録デバイスでのコマンド処理構成を説明する図を図２９に示す。
【０２２９】
図２９に示すように記録再生器暗号処理部３０２を有する記録再生器３００と記録デバイス暗号処理部４０１を有する記録デバイス４００間においては、記録再生器３００の制御部３０１の制御のもとに記録デバイスコントローラ３０３から記録デバイス４００の通信部(受信レジスタを含む)４０４に対してコマンド番号（Ｎｏ．）が出力される。
【０２３０】
記録デバイス４００は、暗号処理部４０１内の制御部４０３にコマンド番号管理部２２０１を有する。コマンド番号管理部２９０１は、コマンドレジスタ２９０２を保持しており、記録再生器３００から出力されるコマンド番号に対応するコマンド列を格納している。コマンド列は、図２９の右に示すようにコマンド番号０からｙまで順次、コマンド番号に対して実行コマンドが対応付けされている。コマンド番号管理部２９０１は、記録再生器３００から出力されるコマンド番号を監視し、対応するコマンドをコマンドレジスタ２９０２から取り出して実行する。
【０２３１】
コマンドレジスタ２９０２に格納されたコマンドシーケンスは、図２９の右に示すように、認証処理シーケンスに関するコマンド列が先行するコマンド番号０〜ｋに対応付けられている。さらに、認証処理シーケンスに関するコマンド列の後のコマンド番号ｐ〜ｓに復号、鍵交換、暗号処理コマンドシーケンス１、さらに、後続するコマンド番号ｕ〜ｙに復号、鍵交換、暗号処理コマンドシーケンス２が対応付けされている。
【０２３２】
先に図２０の認証処理フローにおいて説明したように、記録デバイス４００が記録再生器３００に装着されると、記録再生器３００の制御部３０１は、記録デバイスコントローラ３０３を介して記録デバイス４００に初期化命令を送信する。これを受信した記録デバイス４００は、記録デバイス暗号処理部４０１の制御部４０３において、通信部４０４を介して命令を受信し、認証フラグ２９０３をクリアする。すなわち未認証状態に設定する。または、記録再生器３００から記録デバイス４００に電源が供給される様な場合には、パワーオン時に未承認状態としてセットを行なう方式でもよい。
【０２３３】
次に、記録再生器３００の制御部３０１は、記録再生器暗号処理部３０２に初期化命令を送信する。このとき、記録デバイス挿入口番号も併せて送信する。記録デバイス挿入口番号を送信することにより、記録再生器３００に複数の記録デバイスが接続された場合であっても同時に複数の記録デバイス４００との認証処理、およびデータ送受信が可能となる。
【０２３４】
初期化命令を受信した記録再生器３００の記録再生器暗号処理部３０２は、記録再生器暗号処理部３０２の制御部において、記録デバイス挿入口番号に対応する認証フラグ２９０４をクリアする。すなわち未認証状態に設定する。
【０２３５】
これらの初期化処理が完了すると、記録再生器３００の制御部３０１は、記録デバイスコントローラ３０３を介してコマンド番号０から順次コマンド番号を昇順に出力する。記録デバイス４００のコマンド番号管理部２９０１は、記録再生器３００から入力されるコマンド番号を監視し、０から順次入力されることを確認して、対応するコマンドをコマンドレジスタ２９０２から取り出して認証処理等各種処理を実行する。入力されるコマンド番号が規定の順でなかった場合には、エラーとし、コマンド番号受付値を初期状態、すなわち実行可能コマンド番号＝０にリセットする。
【０２３６】
図２９に示すようにコマンドレジスタ２９０２に格納されたコマンドシーケンスは、認証処理を先行して処理するようにコマンド番号が付与されており、その後の処理に復号、鍵交換、暗号化処理の処理シーケンスが格納されている。
【０２３７】
復号、鍵交換、暗号化処理の処理シーケンスの具体例を図３０，３１を用いて説明する。
【０２３８】
図３０は、先に図２２において説明した記録再生器３００から記録デバイス４００へのコンテンツのダウンロード処理において実行される処理の一部を構成するものである。具体的には図２２におけるステップＳ５９〜Ｓ６０の間で実行される
【０２３９】
図３０において、ステップＳ３００１は、記録再生器からセッション鍵Ｋｓｅｓで暗号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）を記録デバイスが受信する処理であり、その後、前述の図２９で示したコマンド列ｐ〜ｓが開始される。コマンド列ｐ〜ｓは認証処理コマンド０〜ｋが完了し、図２９に示す認証フラグ２９０３，２９０４に認証済みのフラグがセットされた後開始される。これは、コマンド番号管理部２９０１がコマンド番号を０から昇順でのみ受け付けることによって保証される。
【０２４０】
ステップＳ３００２は、記録デバイスが記録再生器から受信したセッション鍵Ｋｓｅｓで暗号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ，コンテンツ鍵Ｋｃｏｎ）をレジスタに格納する処理である。
【０２４１】
ステップＳ３００３は、セッション鍵Ｋｓｅｓで暗号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ，コンテンツ鍵Ｋｃｏｎ）をレジスタから取り出してセッション鍵Ｋｓｅｓで復号する処理を実行するステップである。
【０２４２】
ステップＳ３００４は、セッション鍵Ｋｓｅｓで復号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ，コンテンツ鍵Ｋｃｏｎ）を保存鍵Ｋｓｔｒで暗号化する処理を実行するステップである。
【０２４３】
上記の処理ステップ３００２〜３００４は、先の図２９で説明したコマンドレジスタ中のコマンド番号ｐ〜ｓに含まれる処理である。これらの処理は、記録デバイス４００のコマンド番号管理部２９０１において記録再生器３００から受信するコマンド番号ｐ〜ｓに従って記録デバイス暗号処理部４０１が順次実行する。
【０２４４】
次のステップＳ３００５は、保存鍵Ｋｓｔｒで暗号化したデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）を記録デバイスの外部メモリに格納するステップである。このステップにおいては、記録デバイス暗号処理部４０１から記録再生器３００が保存鍵Ｋｓｔｒで暗号化したデータを読み出して、その後に記録デバイス４００の外部メモリ４０２に格納してもよい。
【０２４５】
上述のステップＳ３００２〜Ｓ３００４は、連続して実行される割込み不可能な実行シーケンスであり、たとえば、ステップＳ３００３の復号処理終了時点で、記録再生器３００からのデータ読み出し命令があったとしても、その読み出しコマンドは、コマンドレジスタ２９０２のコマンド番号ｐ〜ｓに設定された昇順のコマンド番号とは異なるため、コマンド番号管理部２９０１は、読み出しの実行を受け付けない。従って、記録デバイス４００における鍵交換の際に発生する復号データを外部、例えば記録再生器３００から読み出すことは不可能となり、鍵データ、コンテンツの不正な読み出しを防止できる。
【０２４６】
図３１は、先に図２８において説明した記録デバイス４００からコンテンツを読み出して記録再生器３００において再生するコンテンツ再生処理において実行される処理の一部を構成するものである。具体的には図２８におけるステップＳ７３において実行される処理である。
【０２４７】
図３１において、ステップＳ３１０１は、記録デバイス４００の外部メモリ４０２から保存鍵Ｋｓｔｒで暗号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）の読み出しを実行するステップである。
【０２４８】
ステップＳ３１０２は、記録デバイスのメモリから読み出した保存鍵Ｋｓｔｒで暗号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）をレジスタに格納するステップである。このステップにおいては、記録デバイス４００の外部メモリ４０２から記録再生器３００が保存鍵Ｋｓｔｒで暗号化したデータを読み出して、その後に記録デバイス４００のレジスタに格納してもよい。
【０２４９】
ステップＳ３１０３は、保存鍵Ｋｓｔｒで暗号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）をレジスタから取り出して保存鍵Ｋｓｔｒで復号処理するステップである。
【０２５０】
ステップＳ３１０４は、保存鍵Ｋｓｔｒで復号化されたデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）をセッション鍵Ｋｓｅｓで暗号化処理するステップである。
【０２５１】
上記の処理ステップ３１０２〜３１０４は、先の図２９で説明したコマンドレジスタ中のコマンド番号ｕ〜ｙに含まれる処理である。これらの処理は、記録デバイスのコマンド番号管理部２９０１において記録再生器３００から受信するコマンド番号ｕ〜ｙに従って記録デバイス暗号処理部４０６が順次実行する。
【０２５２】
次のステップＳ３１０５は、セッション鍵Ｋｓｅｓで暗号化したデータ（ｅｘ．ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ）を記録デバイスから記録再生器へ送信する処理である。
【０２５３】
上述のステップＳ３１０２〜Ｓ３１０４は、連続して実行される割込み不可能な実行シーケンスであり、たとえば、ステップＳ３１０３の復号処理終了時点で、記録再生器３００からのデータ読み出し命令があったとしても、その読み出しコマンドは、コマンドレジスタ２９０２のコマンド番号ｕ〜ｙに設定された昇順のコマンド番号とは異なるため、コマンド番号管理部２９０１は、読み出しの実行を受け付けない。従って、記録デバイス４００における鍵交換の際に発生する復号データを外部、例えば記録再生器３００から読み出すことは不可能となり、鍵データあるいはコンテンツの不正な読み出しを防止できる。
【０２５４】
なお、図３０，３１に示す処理では、鍵交換によって復号、暗号化される対象が、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎである例を示したが、これらの図２９に示したコマンドレジスタ２９０２に格納されたコマンドシーケンスには、コンテンツ自体の鍵交換を伴う復号、暗号化処理を含ませてもよく、鍵交換によって復号、暗号化される対象は上述の例に限定されるものではない。
【０２５５】
以上、本発明のデータ処理装置における相互認証後の鍵交換処理について説明した。このように、本発明のデータ処理装置における鍵交換処理は、記録再生器と記録デバイス間での認証処理が終了した後においてのみ実行可能となり、さらに、鍵交換処理における復号データの外部からのアクセスが防止可能な構成となっているので、コンテンツ、鍵データの高度なセキュリティが確保される。
【０２５６】
（１０）複数のコンテンツデータフォーマットと、各フォーマットに対応するダウンロードおよび再生処理
上述した実施例では、例えば図３に示すメディア５００あるいは通信手段６００におけるデータフォーマットが図４に示す１つの種類である場合について説明してきた。しかしながら、メディア５００あるいは、通信手段６００におけるデータフォーマットは、上述の図４に示すフォーマットに限らず、コンテンツが音楽である場合、画像データである場合、ゲーム等のプログラムである場合等、コンテンツに応じたデータフォーマットを採用することが望ましい。以下、複数の異なるデータデータフォーマットと、各フォーマットに対応する記録デバイスへのダウンロード処理および記録デバイスからの再生処理について説明する。
【０２５７】
図３２〜３５に４つの異なるデータフォーマットを示す。各図の左側には、図３に示すメディア５００、または通信手段６００上におけるデータフォーマットを、また各図の右側には記録デバイス４００の外部メモリ４０２に格納される場合のデータフォーマットを示してある。先に、図３２〜３５に示すデータフォーマットの概略を説明し、その後、各フォーマットにおける各データの内容、および各フォーマットにおけるデータの差異について説明する。
【０２５８】
図３２は、フォーマットタイプ０であり、上述の説明中で例として示したタイプと共通のものである。このフォーマットタイプ０の特徴は、データ全体を任意の大きさのＮ個のデータブロック、すなわちブロック１〜ブロックＮに分割し、各ブロックについて任意に暗号化し、暗号化ブロックと非暗号化ブロック、すなわち平文ブロックを混在させてデータを構成できる点である。ブロックの暗号化は、コンテンツ鍵Ｋｃｏｎによって実行されており、コンテンツ鍵Ｋｃｏｎは、メディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。ブロック情報鍵Ｋｂｉｔについてもメディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。これらの鍵交換は、前述の「（９）相互認証後の鍵交換処理」において説明した処理にしたがって実行される。
【０２５９】
図３３は、フォーマットタイプ１であり、このフォーマットタイプ１は、フォーマットタイプ０と同様、データ全体をＮ個のデータブロック、すなわちブロック１〜ブロックＮに分割しているが、Ｎ個の各ブロックの大きさを同じ大きさとした点で前述のフォーマットタイプ０と異なる。コンテンツ鍵Ｋｃｏｎによるブロックの暗号化処理態様は前述のフォーマットタイプ０と同様である。また、メディア上で配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化されるコンテンツ鍵Ｋｃｏｎおよびブロック情報鍵Ｋｂｉｔ構成も上述のフォーマットタイプ０と同様である。フォーマットタイプ１は、フォーマットタイプ０と異なり、固定的なブロック構成としたことで、ブロック毎のデータ長等の構成データが簡略化されるので、フォーマットタイプ０に比較してブロック情報のメモリサイズを減らすことが可能となる。
【０２６０】
図３３の構成例では、各ブロックを暗号化パートと非暗号化（平文）パートの１組によって構成している。このようにブロックの長さ、構成が規則的であれば、復号処理等の際に各ブロック長、ブロック構成を確認する必要がなくなるので効率的な復号、暗号処理が可能となる。なお、フォーマット１においては、各ブロックを構成するパート、すなわち暗号化パート、非暗号化（平文）パートは、各パート毎にチェック対象として定義可能な構成となっており、要チェックパーツを含むブロックである場合は、そのブロックに関してコンテンツチェック値ＩＣＶｉが定義される。
【０２６１】
図３４は、フォーマットタイプ２であり、このフォーマットタイプ２の特徴は、同じ大きさのＮ個のデータブロック、すなわちブロック１〜ブロックＮに分割され、各ブロックについて、それぞれ個別のブロック鍵Ｋｂｌｃで暗号化されていることである。各ブロック鍵Ｋｂｌｃの暗号化は、コンテンツ鍵Ｋｃｏｎによって実行されており、コンテンツ鍵Ｋｃｏｎは、メディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。ブロック情報鍵Ｋｂｉｔについてもメディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。
【０２６２】
図３５は、フォーマットタイプ３であり、このフォーマットタイプ３の特徴は、フォーマット・タイプ２と同様、同じ大きさのＮ個のデータブロック、すなわちブロック１〜ブロックＮに分割され、各ブロックについて、それぞれ個別のブロック鍵Ｋｂｌｃで暗号化されていること、さらに、コンテンツ鍵を用いず、各ブロック鍵Ｋｂｌｃの暗号化は、メデイア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイス上では保存鍵Ｋｓｔｒによって暗号化されている点である。コンテンツ鍵Ｋｃｏｎは、メディア上、デバイス上、いずれにも存在しない。ブロック情報鍵Ｋｂｉｔはメディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。
【０２６３】
次に、上記フォーマットタイプ０〜３のデータの内容について説明する。データは先に説明したように、ヘッダ部とコンテンツ部に大きく２つに分類され、ヘッダ部にはコンテンツ識別子、取扱方針、チェック値Ａ，Ｂ，総チェック値、ブロック情報鍵、コンテンツ鍵、ブロック情報が含まれる。
【０２６４】
取扱方針には、コンテンツのデータ長、ヘッダ長、フォーマットタイプ（以下説明するフォーマット０〜３）、例えばプログラムであるか、データであるか等のコンテンツタイプ、前述のコンテンツの記録デバイスへのダウンロード、再生の欄で説明したように、コンテンツが記録再生器固有に利用可能か否かを決定するフラグであるローカリゼーション・フラグ、さらに、コンテンツのコピー、ムーブ処理に関する許可フラグ、さらに、コンテンツ暗号化アルゴリズム、モード等、コンテンツに関する各種の利用制限情報および処理情報を格納する。
【０２６５】
チェック値Ａ：ＩＣＶａは、識別情報、取扱方針に対するチェック値であり、例えば、前述の図２３で説明した手法によって生成される。
【０２６６】
ブロック情報鍵Ｋｂｉｔは、ブロック情報を暗号化するための鍵であり、先に説明したように、メディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。
【０２６７】
コンテンツ鍵Ｋｃｏｎは、コンテンツの暗号化に用いる鍵であり、フォーマットタイプ０，１では、ブロック情報鍵Ｋｂｉｔと同様にメディア上では配送鍵Ｋｄｉｓによって暗号化され、記録デバイスにおける保存時には、記録デバイスの内部メモリに格納された保存鍵Ｋｓｔｒによって暗号化される。なお、フォーマットタイプ２では、コンテンツ鍵Ｋｃｏｎは、コンテンツ各ブロックに構成されるブロック鍵Ｋｂｌｃの暗号化にも利用される。また、フォーマット・タイプ３においては、コンテンツ鍵Ｋｃｏｎは存在しない。
【０２６８】
ブロック情報は、個々のブロックの情報を記述するテーブルであり、ブロックの大きさ、暗号化されているか否かについてのフラグ、すなわち各ブロックがチェックの対象（ＩＣＶ）と、なっているか否かを示す情報が格納される。ブロックがチェックの対象となっている場合は、ブロックのチェック値ＩＣＶｉ（ブロックｉのチェック値）がテーブル中に定義されて格納される。このブロック情報は、ブロック情報暗号鍵Ｋｂｉｔによって暗号化される。
【０２６９】
なお、ブロックのチェック値、すなわちコンテンツチェック値ＩＣＶｉは、ブロックが暗号化されている場合、平文（復号文）全体を８バイト単位で排他論理和した値を記録再生器３００の内部メモリ３０７に格納されたコンテンツチェック値生成鍵Ｋｉｃｖｃで暗号化した値として生成される。また、ブロックが暗号化されていない場合は、ブロックデータ（平文）の全体を８バイト単位で図３６に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。図３６にコンテンツブロックのチェック値ＩＣＶｉを生成する構成例を示す。メッセージＭの各々が復号文データまたは平文データの各８バイトを構成する。
【０２７０】
なお、フォーマット・タイプ１においては、ブロック内のパーツのうち少なくとも１つがチェック値ＩＣＶｉの対象データ、すなわち要チェックパーツである場合は、そのブロックに関してコンテンツチェック値ＩＣＶｉが定義される。ブロックｉにおけるパーツｊのチェック値Ｐ−ＩＣＶｉｊは、パーツｊが暗号化されている場合、平文（復号文）全体を８バイト単位で排他論理和した値をコンテンツチェック値生成鍵Ｋｉｃｖｃで暗号化した値として生成される。また、パーツｊが暗号化されていない場合は、パーツのブロックのデータ（平文）の全体を８バイト単位で図３６に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。
【０２７１】
さらに、１つのブロックｉ内にチェツク対象であることを示す［ＩＣＶフラグ＝ｓｕｂｊｅｃｔ ｏｆ ＩＣＶ］であるパーツ、すなわち要チェックパーツが１つのみ存在する場合は、上述の手法で生成したチェック値Ｐ−ＩＣＶｉｊをそのままブロックのチェック値ＩＣＶｉとし、また、１つのブロックｉ内にチェツク対象であることを示す［ＩＣＶフラグ＝ｓｕｂｊｅｃｔ ｏｆ ＩＣＶ］であるパーツが複数存在する場合は、複数のパーツチェック値Ｐ−ＩＣＶｉｊをパーツ番号順に連結したデータを対象にして８バイト単位で図３７に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。図３７にコンテンツブロックのコンテンツチェック値ＩＣＶｉを生成する構成例を示す。
【０２７２】
なお、フォーマット・タイプ２，３においては、ブロックのチェック値ＩＣＶｉは定義されない。
【０２７３】
チェック値Ｂ：ＩＣＶｂは、ブロック情報鍵、コンテンツ鍵、ブロック情報全体に対するチェック値であり、例えば、前述の図２４で説明した手法によって生成される。
【０２７４】
総チェック値ＩＣＶｔは、前述のチェック値Ａ：ＩＣＶａ、チェック値Ｂ：ＩＣＶｂ、さらにコンテンツのチェック対象となっている各ブロックに含まれるチェック値ＩＣＶｉ全体に対するチェック値であり、前述の図２５で説明したようにチェック値Ａ：ＩＣＶａ等の各チェック値から生成される中間チェック値にシステム署名鍵Ｋｓｙｓを適用して暗号化処理を実行することによって生成される。
【０２７５】
なお、フォーマット・タイプ２，３においては、総チェック値ＩＣＶｔは、前述のチェック値Ａ：ＩＣＶａ、チェック値Ｂ：ＩＣＶｂにコンテンツデータ、すなわちブロック１のブロック鍵から最終ブロックまでのコンテンツデータ全体を連結したデータから生成される中間チェック値にシステム署名鍵Ｋｓｙｓを適用して暗号化処理を実行することによって生成される。図３８にフォーマット・タイプ２，３における総チェック値ＩＣＶｔを生成する構成例を示す。
【０２７６】
固有チェック値ＩＣＶｄｅｖは、前述のローカリゼーションフラグが１にセットされている場合、すなわち、コンテンツが記録再生器固有に利用可能であることを示している場合に、総チェック値ＩＣＶｔに置き換えられるチェック値であり、フォーマット・タイプ０，１の場合は、前述のチェック値Ａ：ＩＣＶａ、チェック値Ｂ：ＩＣＶｂ、さらにコンテンツのチェック対象となっている各ブロックに含まれるチェック値ＩＣＶｉ全体に対するチェック値として生成される。具体的には、前述の図２５、または図３８で説明したようにチェック値Ａ：ＩＣＶａ等の各チェック値から生成される中間チェック値に記録再生器署名鍵Ｋｄｅｖを適用して暗号化処理を実行することによって生成される。
【０２７７】
次にフォーマットタイプ０〜３各々における記録再生器３００から記録デバイス４００に対するコンテンツのダウンロード処理、および記録再生器３００における記録デバイス４００からの再生処理について図３９〜４４のフローを用いて説明する。
【０２７８】
まず、フォーマットタイプ０，１におけるコンテンツのダウンロード処理について図３９を用いて説明する。
【０２７９】
図３９に示す処理は、例えば図３に示す記録再生器３００に記録デバイス４００を装着することによって開始される。ステップＳ１０１は、記録再生器と記録デバイス間における認証処理ステップであり、先に説明した図２０の認証処理フローに従って実行される。
【０２８０】
ステップＳ１０１の認証処理が終了し、認証フラグがセットされると、記録再生器３００は、ステップＳ１０２において、例えばコンテンツデータを格納したメディア５００から、読み取り部３０４を介して所定のフォーマットに従ったデータを読み出すか、通信部３０５を使って通信手段６００から所定のフォーマットに従ってデータを受信し、記録再生器３００の制御部３０１が、データの内のヘッダ（Header）部分を記録再生器３００の記録再生器暗号処理部３０２に送信する。
【０２８１】
次に、ステップＳ１０３において、暗号処理部３０２の制御部３０６が記録再生器暗号処理部３０２の暗号／復号化部３０８にチェック値Ａを計算させる。チェック値Ａは、図２３に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ａ生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして図７を用いて説明したＩＣＶ計算方法に従って計算される。次に、ステップＳ１０４において、チェック値Ａとヘッダ（Header）内に格納されたチェック値：ＩＣＶａを比較し、一致していた場合にはステップＳ１０５へ進む。
【０２８２】
先に説明したようにチェック値Ａ，ＩＣＶａは、識別情報、取扱方針の改竄を検証するためのチェック値である。記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ａ生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして、例えばＩＣＶ計算方法に従って計算されるチェック値Ａが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶａと一致した場合には、識別情報、取扱方針の改竄はないと判断される。
【０２８３】
次に、ステップＳ１０５において、記録再生器暗号処理部３０２の制御部３０６は、配送鍵Ｋｄｉｓの取り出しまたは生成を記録再生器暗号処理部３０２の暗号／復号化部３０８に行わせる。配送鍵Ｋｄｉｓの生成方法は、先に説明した図２２のステップＳ５３と同様、例えば配送鍵用マスター鍵ＭＫｄｉｓを用いて行われる。
【０２８４】
次にステップＳ１０６において、記録再生器暗号処理部３０２の制御部３０６が、記録再生器暗号処理部３０２の暗号／復号化部３０８を使って、生成した配送鍵Ｋｄｉｓを用いて、読み取り部３０４を介して受信したメディア５００、または、通信部３０５を介して通信手段６００から受信したデータのヘッダ部に格納されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎの復号化処理を行う。
【０２８５】
さらに、ステップＳ１０７において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８において、復号化したブロック情報鍵Ｋｂｉｔでブロック情報を復号化する。
【０２８６】
さらに、ステップＳ１０８において、記録再生器暗号処理部３０２の制御部３０６は、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）から、チェック値Ｂ（ＩＣＶｂ’）を生成する。チェック値Ｂは、図２４に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）からなる排他的論理和値をＤＥＳで暗号化して生成する。次に、ステップＳ１０９において、チェック値Ｂとヘッダ（Header）内のＩＣＶｂを比較し、一致していた場合にはステップＳ１１０へ進む。
【０２８７】
先に説明したように、チェック値Ｂ，ＩＣＶｂは、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄を検証するためのチェック値である。記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）を８バイト単位に分割し排他的論理和して得られる値をＤＥＳで暗号化して生成したチェック値Ｂが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶｂと一致した場合には、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄はないと判断される。
【０２８８】
ステップＳ１１０において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に中間チェック値の計算をさせる。中間チェック値は、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されている総チェック値生成鍵Ｋｉｃｖｔを鍵とし、検証したHeader内のチェック値Ａ、チェック値Ｂ、保持しておいた全てのコンテンツチェック値をメッセージとして図７他で説明したＩＣＶ計算方法に従って計算する。なお、生成した中間チェック値は、必要に応じて記録再生器３００の記録再生器暗号処理部３０２に保持しておく。
【０２８９】
次に、ステップＳ１１１において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に総チェック値ＩＣＶｔ’の計算をさせる。総チェック値ＩＣＶｔ’は、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているシステム署名鍵Ｋｓｙｓを鍵とし、中間チェック値をＤＥＳで暗号化して生成する。次に、ステップＳ１１２において、生成した総チェック値ＩＣＶｔ’とヘッダ（Header）内のＩＣＶｔを比較し、一致していた場合には、ステップＳ１１３へ進む。
【０２９０】
先に図４において説明したように、総チェック値ＩＣＶｔは、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄を検証するためのチェック値である。従って、上述の処理によって生成された総チェック値がヘッダ（Header）内に格納されたチェック値：ＩＣＶｔと一致した場合には、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄はないと判断される。
【０２９１】
次に、ステップＳ１１３において、記録再生器３００の制御部３０１は、ブロック情報（ＢＩＴ）内のコンテンツブロック情報を取り出し、コンテンツブロックが検証対象になっているかいないか調べる。コンテンツブロックが検証対象になっている場合には、ヘッダ中のブロック情報中にコンテンツチェック値が格納されている。
【０２９２】
コンテンツブロックが検証対象になっていた場合には、ステップＳ１１４において、該当するコンテンツブロックを、記録再生器３００の読み取り部３０４を使ってメディア５００から読み出すか、記録再生器３００の通信部３０５を使って通信手段６００から受信し、記録再生器３００の記録再生器暗号処理部３０２へ送信する。これを受信した記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８にコンテンツチェック値ＩＣＶｉ’を計算させる。
【０２９３】
コンテンツチェック値ＩＣＶｉ’は、先に説明したようにブロックが暗号化されている場合、コンテンツ鍵Ｋｃｏｎで、入力されたコンテンツブロックをＤＥＳのＣＢＣモードで復号化し、その結果を全て８バイト単位で排他的論理和して生成したコンテンツ中間値を記録再生器３００の内部メモリ３０７に格納されたコンテンツチェック値生成鍵Ｋｉｃｖｃで暗号化して生成する。また、ブロックが暗号化されていない場合は、データ（平文）全体を８バイト単位で図３６に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。
【０２９４】
次にステップＳ１１５において、記録再生器暗号処理部３０２の制御部３０６は、当該コンテンツチェック値と、ステップＳ１０２で記録再生器３００の制御部３０１から受信したコンテンツブロック内のＩＣＶを比較し、その結果を記録再生器３００の制御部３０１に渡す。これを受信した記録再生器３００の制御部３０１は、検証に成功していた場合、次の検証対象コンテンツブロックを取り出して記録再生器３００の記録再生器暗号処理部３０２に検証させ、全てのコンテンツブロックを検証するまで同様の検証処理を繰り返す（ステップＳ１１６）。
【０２９５】
なお、ステップＳ１０４、ステップＳ１０９、ステップＳ１１２、ステップＳ１１５のいずれかにおいて、チェック値の一致が得られなかった場合はエラーとしてダウンロード処理は終了する。
【０２９６】
次に、ステップＳ１１７において、記録再生器３００の記録再生器暗号処理部３０２は、ステップＳ１０６で復号化したブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを、記録再生器暗号処理部３０２の暗号／復号化部３０８に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで暗号化させる。記録再生器３００の制御部３０１は、セッション鍵Ｋｓｅｓで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを記録再生器３００の記録再生器暗号処理部３０２から読み出し、これらのデータを記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０２９７】
次に、ステップＳ１１８において、記録再生器３００から送信されてきたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化させ、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで再び暗号化させ、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００から保存鍵Ｋｓｔｒで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを読み出す。すなわち、配送鍵Ｋｄｉｓで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎの鍵のかけかえを行なう。
【０２９８】
次に、ステップＳ１１９において、記録再生器３００の制御部３０１は、データのヘッダ部の取扱方針（Usage Policy）から利用制限情報を取り出し、ダウンロードしたコンテンツが当該記録再生器３００のみで利用できるか否かの判定を行なう。この判定は、ローカリゼーションフラグ（利用制限情報）＝１に設定されている場合は、ダウンロードしたコンテンツが当該記録再生器３００のみで利用でき、ローカリゼーションフラグ（利用制限情報）＝０に設定されている場合は、ダウンロードしたコンテンツが別の同様な記録再生器３００でも利用できることを示す。判定の結果、ローカリゼーションフラグ（利用制限情報）＝１であった場合には、ステップＳ１２０に進む。
【０２９９】
ステップＳ１２０において、記録再生器３００の制御部３０１は、記録再生器固有のチェック値を記録再生器３００の記録再生器暗号処理部３０２に計算させる。記録再生器固有のチェック値は、図２５に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されている記録再生器に固有の記録再生器署名鍵Ｋｄｅｖを鍵とし、ステップＳ１１０で生成した中間チェック値をＤＥＳで暗号化して生成する。計算された記録再生器固有のチェック値ＩＣＶｄｅｖは、総チェック値ＩＣＶｔの代わりに上書きされる。
【０３００】
先に説明したように、システム署名鍵Ｋｓｙｓは、配信システムに共通の署名またはICVをつけるために使用するシステム署名鍵であり、また、記録再生器署名鍵Ｋｄｅｖは、記録再生器毎に異なり、記録再生器が署名またはＩＣＶをつけるために使用する記録再生器署名鍵である。すなわち、システム署名鍵Ｋｓｙｓによって署名されたデータは、同じシステム署名鍵を有するシステム（記録再生器）によってチェックが成功、すなわち総チェック値ＩＣＶｔが一致することになるので、共通に利用可能となるが、記録再生器署名鍵Ｋｄｅｖを用いて署名された場合には、記録再生器署名鍵はその記録再生器に固有の鍵であるので、記録再生器署名鍵Ｋｄｅｖを用いて署名されたデータ、すなわち、署名後、記録デバイスに格納されたデータは、他の記録再生器に、その記録デバイスを装置して再生しようとした場合、記録再生器固有のチェック値ＩＣＶｄｅｖが不一致となり、エラーとなるので再生できないことになる。本発明のデータ処理装置においては、利用制限情報の設定によって、システムに共通に使用できるコンテンツ、記録再生器固有に利用できるコンテンツを自在に設定できるものである。
【０３０１】
次に、ステップＳ１２１において、記録再生器３００の制御部３０１は、記録再生器暗号処理部３０２に格納データフォーマットの形成を実行させる。先に説明したように、フォーマットタイプは０〜３まで各タイプがあり、ヘッダ中の取扱方針（図５参照）中に設定され、この設定タイプにしたがって、先に説明した図３２〜３５の右側の格納フォーマットにしたがってデータを形成する。この図３９に示すフローはフォーマット０，１のいずれかであるので、図３２，３３のいずれかのフォーマットに形成される。
【０３０２】
ステップＳ１２１において格納データフォーマットの形成が終了すると、ステップ１２２において、記録再生器３００の制御部３０１は、コンテンツを記録デバイス４００の外部メモリ４０２に保存する。
【０３０３】
以上が、フォーマットタイプ０，１におけるコンテンツデータのダウンロード処理の態様である。
【０３０４】
次に、フォーマットタイプ２におけるコンテンツデータのダウンロード処理について図４０を用いて説明する。上記したフォーマットタイプ０，１のダウンロード処理と異なる点を中心に説明する。
【０３０５】
ステップＳ１０１〜Ｓ１０９は、上記したフォーマットタイプ０，１のダウンロード処理と同様であるので説明は省略する。
【０３０６】
フォーマットタイプ２は、先に説明したようにコンテンツチェック値ＩＣＶｉが定義されていないので、ブロック情報中には、コンテンツチェック値ＩＣＶｉを持たない。フォーマットタイプ２における中間チェック値は、図３８に示すようにチェック値Ａ、チェック値Ｂと、第１ブロックの先頭データ（ブロック１のブロック鍵）から最終ブロックまでのコンテンツデータ全体を連結したデータに基づいて生成される中間チェック値にシステム署名鍵Ｋｓｙｓを適用して暗号化処理を実行することによって生成される。
【０３０７】
従って、フォーマットタイプ２のダウンロード処理においては、ステップＳ１５１においてコンテンツデータを読み出し、ステップＳ１５２において、チェック値Ａ、チェック値Ｂと読み出したコンテンツデータに基づいて中間チェック値の生成を実行する。なお、コンテンツデータは暗号化されている場合でも、復号処理を行なわない。
【０３０８】
フォーマットタイプ２では、前述のフォーマットタイプ０，１での処理のようにブロックデータの復号、コンテンツチェック値の照会処理を行なわないので、迅速な処理が可能となる。
【０３０９】
ステップＳ１１１以下の処理は、フォーマットタイプ０，１における処理と同様であるので説明を省略する。
【０３１０】
以上が、フォーマットタイプ２におけるコンテンツデータのダウンロード処理の態様である。上述したようにフォーマットタイプ２のダウンロード処理は、フォーマットタイプ０，１での処理のようにブロックデータの復号、コンテンツチェック値の照会処理を行なわないので、迅速な処理が可能となり、音楽データ等リアルタイム処理が要求されるデータ処理に適したフォーマットである。
【０３１１】
次に、フォーマットタイプ３におけるコンテンツデータのダウンロード処理について図４１を用いて説明する。上記したフォーマットタイプ０，１，２のダウンロード処理と異なる点を中心に説明する。
【０３１２】
ステップＳ１０１〜Ｓ１０５は、上記したフォーマットタイプ０，１，２のダウンロード処理と同様であるので説明は省略する。
【０３１３】
フォーマットタイプ３は、基本的にフォーマットタイプ２における処理と共通する部分が多いが、フォーマットタイプ３はコンテンツ鍵を有しておらず、またブロック鍵Ｋｂｌｃが記録デバイスにおいては保存鍵Ｋｓｔｒで暗号化されて格納される点がフォーマットタイプ２と異なる。
【０３１４】
フォーマットタイプ３のダウンロード処理におけるフォーマットタイプ２と相違する点を中心として説明する。フォーマットタイプ３では、ステップＳ１０５の次ステップであるステップＳ１６１において、ブロック情報鍵の復号を行なう。記録再生器暗号処理部３０２の制御部３０６が、記録再生器暗号処理部３０２の暗号／復号化部３０８を使って、ステップＳ１０５で生成した配送鍵Ｋｄｉｓを用いて、読み取り部３０４を介して受信したメディア５００、または、通信部３０５を介して通信手段６００から受信したデータのヘッダ部に格納されたブロック情報鍵Ｋｂｉｔの復号化処理を行う。フォーマットタイプ３では、データ中にコンテンツ鍵Ｋｃｏｎが存在しないため、コンテンツ鍵Ｋｃｏｎの復号化処理は実行されない。
【０３１５】
次のステップＳ１０７では、ステップＳ１６１で復号したブロック情報鍵Ｋｂｉｔを用いてブロック情報の復号が実行され、さらに、ステップＳ１６２において、記録再生器暗号処理部３０２の制御部３０６は、ブロック情報鍵Ｋｂｉｔ、およびブロック情報（ＢＩＴ）から、チェック値Ｂ（ＩＣＶｂ’）を生成する。チェック値Ｂは、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、ブロック情報鍵Ｋｂｉｔ、およびブロック情報（ＢＩＴ）からなる排他的論理和値をＤＥＳで暗号化して生成する。次に、ステップＳ１０９において、チェック値Ｂとヘッダ（Header）内のＩＣＶｂを比較し、一致していた場合にはステップＳ１５１へ進む。
【０３１６】
フォーマットタイプ３では、チェック値Ｂ，ＩＣＶｂは、ブロック情報鍵Ｋｂｉｔ、ブロック情報の改竄を検証するためのチェック値として機能する。生成したチェック値Ｂが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶｂと一致した場合には、ブロック情報鍵Ｋｂｉｔ、ブロック情報の改竄はないと判断される。
【０３１７】
ステップＳ１５１〜Ｓ１１２は、フォーマットタイプ２の処理と同様であるので説明を省略する。
【０３１８】
ステップＳ１６３では、ステップＳ１５１で読み出したコンテンツデータに含まれるブロック鍵ＫｂｌｃをステップＳ１０５で生成した配送鍵Ｋｄｉｓによって復号する。
【０３１９】
次にステップＳ１６４では、記録再生器３００の記録再生器暗号処理部３０２が、ステップＳ１６１で復号化したブロック情報鍵Ｋｂｉｔと、ステップＳ１６３で復号したブロック鍵Ｋｂｌｃを、記録再生器暗号処理部３０２の暗号／復号化部３０８に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで暗号化させる。記録再生器３００の制御部３０１は、セッション鍵Ｋｓｅｓで暗号化されたブロック情報鍵Ｋｂｉｔとブロック鍵Ｋｂｌｃを記録再生器３００の記録再生器暗号処理部３０２から読み出し、これらのデータを記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０３２０】
次に、ステップＳ１６５において、記録再生器３００から送信されてきたブロック情報鍵Ｋｂｉｔとブロック鍵Ｋｂｌｃを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化させ、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで再暗号化させ、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００から保存鍵Ｋｓｔｒで再暗号化されたブロック情報鍵Ｋｂｉｔとブロック鍵Ｋｂｌｃを読み出す。すなわち、当初、配送鍵Ｋｄｉｓで暗号化されたブロック情報鍵Ｋｂｉｔとブロック鍵Ｋｂｌｃを保存鍵Ｋｓｔｒで再暗号化されたブロック情報鍵Ｋｂｉｔとブロック鍵Ｋｂｌｃへ置き換えを行なう。
【０３２１】
以下のステップＳ１１９〜Ｓ１２２は、前述のフォーマットタイプ０，１，２と同様であるので説明を省略する。
【０３２２】
以上が、フォーマットタイプ３におけるコンテンツデータのダウンロード処理の態様である。上述したようにフォーマットタイプ３のダウンロード処理は、フォーマットタイプ２と同様、ブロックデータの復号、コンテンツチェック値の照会処理を行なわないので、迅速な処理が可能となり、音楽データ等リアルタイム処理が要求されるデータ処理に適したフォーマットである。また、ブロック鍵Ｋｂｌｃにより暗号化コンテンツを保護する範囲が局所化されているので、フォーマットタイプ２に比較して、よりセキュリティが高度となる。
【０３２３】
次に、フォーマットタイプ０〜３各々における記録再生器３００における記録デバイス４００からの再生処理について図４２〜４５のフローを用いて説明する。
【０３２４】
まず、フォーマットタイプ０におけるコンテンツの再生処理について図４２を用いて説明する。
【０３２５】
ステップＳ２０１は、記録再生器と記録デバイス間における認証処理ステップであり、先に説明した図２０の認証処理フローに従って実行される。
【０３２６】
ステップＳ２０１の認証処理が終了し、認証フラグがセットされると、記録再生器３００は、ステップＳ２０２において、記録デバイス４００から所定のフォーマットに従ったデータのヘッダを読み出し、記録再生器３００の記録再生器暗号処理部３０２に送信する。
【０３２７】
次に、ステップＳ２０３において、暗号処理部３０２の制御部３０６が記録再生器暗号処理部３０２の暗号／復号化部３０８にチェック値Ａを計算させる。チェック値Ａは、先に説明した図２３に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ａ生成鍵Ｋｉｃｖａを鍵とし、識別情報（Content ID）と取扱方針（Usage Policy）をメッセージとして計算される。次に、ステップＳ２０４において、計算されたチェック値Ａとヘッダ（Header）内に格納されたチェック値：ＩＣＶａを比較し、一致していた場合にはステップＳ２０５へ進む。
【０３２８】
チェック値Ａ，ＩＣＶａは、識別情報、取扱方針の改竄を検証するためのチェック値である。計算されたチェック値Ａが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶａと一致した場合には、記録デバイス４００に格納された識別情報、取扱方針の改竄はないと判断される。
【０３２９】
次に、ステップＳ２０５において、記録再生器３００の制御部３０１は、読み出したヘッダから記録デバイス固有の保存鍵Ｋｓｔｒで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを取り出し、記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０３３０】
記録再生器３００から送信されてきたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで復号化処理させ、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで再び暗号化させる。この処理は、前述した（９）相互認証後の鍵交換処理の欄で詳しく述べた通りである。
【０３３１】
ステップＳ２０６では、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００からセッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信する。
【０３３２】
次に、ステップＳ２０７において、記録再生器３００の制御部３０１は、受信したセッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを記録再生器３００の記録再生器暗号処理部３０２に送信し、セッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを受信した記録再生器３００の記録再生器暗号処理部３０２は、記録再生器暗号処理部３０２の暗号／復号化部３０８に、セッション鍵Ｋｓｅｓで暗号化されたブロック情報鍵Ｋｂｉｔとコンテンツ鍵Ｋｃｏｎを、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化させる。
【０３３３】
さらに、ステップＳ２０８において、復号化したブロック情報鍵Ｋｂｉｔで、ステップＳ２０２で読み出しておいたブロック情報を復号化する。なお、記録再生器３００の記録再生器暗号処理部３０２は、復号化したブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報ＢＩＴを、ステップＳ２０２で読み出したヘッダに含まれるブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報ＢＩＴに置き換えて保持しておく。また、記録再生器３００の制御部３０１は、復号化されたブロック情報ＢＩＴを記録再生器３００の記録再生器暗号処理部３０２から読み出しておく。
【０３３４】
さらに、ステップＳ２０９において、記録再生器暗号処理部３０２の制御部３０６は、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）から、チェック値Ｂ（ＩＣＶｂ’）を生成する。チェック値Ｂは、図２４に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎおよびブロック情報（ＢＩＴ）からなる排他的論理和値をＤＥＳで暗号化して生成する。次に、ステップＳ２１０において、チェック値Ｂとヘッダ（Header）内のＩＣＶｂを比較し、一致していた場合にはステップＳ２１１へ進む。
【０３３５】
チェック値Ｂ，ＩＣＶｂは、ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄を検証するためのチェック値であり、生成したチェック値Ｂが、ヘッダ（Header）内に格納されたチェック値：ＩＣＶｂと一致した場合には、記録デバイス４００に保存されたデータ中のブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄はないと判断される。
【０３３６】
ステップＳ２１１において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に中間チェック値の計算をさせる。中間チェック値は、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されている総チェック値生成鍵Ｋｉｃｖｔを鍵とし、検証したHeader内のチェック値Ａ、チェック値Ｂ、ブロック情報中の全てのコンテンツチェック値をメッセージとして図７他で説明したＩＣＶ計算方法に従って計算する。なお、生成した中間チェック値は、必要に応じて記録再生器３００の記録再生器暗号処理部３０２に保持しておく。
【０３３７】
次に、ステップＳ２１２において、記録再生器３００の制御部３０１は、記録デバイス４００の外部メモリ４０２から読み出したデータのヘッダ部に含まれる取扱方針（Usage Policy）から利用制限情報を取り出し、再生予定のコンテンツが当該記録再生器３００のみで利用できる（利用制限情報が１）か、別の同様な記録再生器３００でも利用できる（利用制限情報が０）か判定する。判定の結果、利用制限情報が１、すなわち再生コンテンツが当該記録再生器３００のみで利用できる利用制限が設定されている場合には、ステップＳ２１３に進み、利用制限情報が０、すなわち別の同様な記録再生器３００でも利用できる設定であった場合には、ステップＳ２１５に進む。なお、ステップＳ２１２の処理は暗号処理部３０２が行なってもよい。
【０３３８】
ステップＳ２１３では、記録再生器３００の制御部３０１は、記録再生器固有のチェック値ＩＣＶｄｅｖ’を記録再生器３００の記録再生器暗号処理部３０２に計算させる。記録再生器固有のチェック値ＩＣＶｄｅｖ’は、図２５に示すように記録再生器暗号処理部３０２の内部メモリ３０７に保存されている記録再生器署名鍵Ｋｄｅｖを鍵とし、ステップＳ２１１で保持しておいた中間チェック値をＤＥＳで暗号化して生成する。
【０３３９】
次に、ステップＳ２１４において、ステップＳ２１３で計算した記録再生器固有のチェック値ＩＣＶｄｅｖ’とステップＳ２０２で読み出したヘッダ内のＩＣＶｄｅｖを比較し、一致していた場合には、ステップＳ２１７へ進む。
【０３４０】
一方ステップＳ２１５では、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に総チェック値ＩＣＶｔの計算をさせる。総チェック値ＩＣＶｔ’は、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているシステム署名鍵Ｋｓｙｓを鍵とし、中間チェック値をＤＥＳで暗号化して生成する。次に、ステップＳ２１６において、生成した総チェック値ＩＣＶｔ’とヘッダ（Header）内のＩＣＶｔを比較し、一致していた場合には、ステップＳ２１７へ進む。
【０３４１】
総チェック値ＩＣＶｔ、および記録再生器固有のチェック値ＩＣＶｄｅｖは、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄を検証するためのチェック値である。従って、上述の処理によって生成されたチェック値がヘッダ（Header）内に格納されたチェック値：ＩＣＶｔまたはＩＣＶｄｅｖと一致した場合には、記録デバイス４００に格納されたＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄はないと判断される。
【０３４２】
次に、ステップＳ２１７において、記録再生器３００の制御部３０１は、記録デバイス４００からブロックデータを読み出す。さらに、ステップＳ２１８において暗号化されているか否かを判定し、暗号化されている場合は、記録再生器３００の暗号処理部３０２においてブロックデータの復号を行なう。暗号化されていない場合は、ステップＳ２１９をスキップしてステップＳ２２０に進む。
【０３４３】
次に、ステップＳ２２０において、記録再生器３００の制御部３０１は、ブロック情報（ＢＩＴ）内のコンテンツブロック情報に基づいて、コンテンツブロックが検証対象になっているかいないか調べる。コンテンツブロックが検証対象になっている場合には、ヘッダ中のブロック情報中にコンテンツチェック値が格納されている。コンテンツブロックが検証対象になっていた場合には、ステップＳ２２１において、該当するコンテンツブロックのコンテンツチェック値ＩＣＶｉ’を計算させる。コンテンツブロックが検証対象になっていない場合には、ステップＳ２２１とＳ２２２をスキップしてステップＳ２２３に進む。
【０３４４】
コンテンツチェック値ＩＣＶｉ’は、先に図３６で説明したようにブロックが暗号化されている場合、コンテンツ鍵Ｋｃｏｎで、入力されたコンテンツブロックをＤＥＳのＣＢＣモードで復号化し、その結果を全て８バイト単位で排他的論理和して生成したコンテンツ中間値を記録再生器３００の内部メモリ３０７に格納されたコンテンツチェック値生成鍵Ｋｉｃｖｃで暗号化して生成する。また、ブロックが暗号化されていない場合は、データ（平文）全体を８バイト単位で図３６に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。
【０３４５】
ステップＳ２２２においては、記録再生器暗号処理部３０２の制御部３０６は、生成したコンテンツチェック値ＩＣＶｉ’と、ステップＳ２０２で記録デバイス４００から受信したヘッダ部に格納されたコンテンツチェック値ＩＣＶｉとを比較し、その結果を記録再生器３００の制御部３０１に渡す。これを受信した記録再生器３００の制御部３０１は、検証に成功していた場合、ステップＳ２２３において、記録再生器システムＲＡＭ上に実行(再生)用コンテンツ平文データを格納する。記録再生器３００の制御部３０１は、さらに次の検証対象コンテンツブロックを取り出して記録再生器３００の記録再生器暗号処理部３０２に検証させ、全てのコンテンツブロックを検証するまで同様の検証処理、ＲＡＭ格納処理を繰り返す（ステップＳ２２４）。
【０３４６】
なお、ステップＳ２０４、ステップＳ２１０、ステップＳ２１４，ステップＳ２１６、ステップＳ２２２のいずれかにおいて、チェック値の一致が得られなかった場合はエラーとして再生処理は終了する。
【０３４７】
ステップＳ２２４において全ブロック読み出しと判定されると、ステップＳ２２５に進み、コンテンツ（プログラム、データ）の実行、再生が開始される。
【０３４８】
以上が、フォーマットタイプ０におけるコンテンツデータの再生処理の態様である。
【０３４９】
次に、フォーマットタイプ１におけるコンテンツデータの再生処理について図４３を用いて説明する。上記したフォーマットタイプ０の再生処理と異なる点を中心に説明する。
【０３５０】
ステップＳ２０１〜ステップＳ２１７までの処理は、上記したフォーマットタイプ０の再生処理と同様であるので説明は省略する。
【０３５１】
フォーマットタイプ１では、ステップＳ２３１において、暗号化パーツの復号が実行され、パーツＩＣＶが生成される。さらに、ステップＳ２３２において、ブロックＩＣＶｉ’が生成される。先に説明したように、フォーマット・タイプ１においては、ブロック内のパーツのうち少なくとも１つがチェック値ＩＣＶｉの対象データである場合は、そのブロックに関してコンテンツチェック値ＩＣＶｉが定義される。ブロックｉにおけるパーツｊのチェック値Ｐ−ＩＣＶｉｊは、パーツｊが暗号化されている場合、平文（復号文）全体を８バイト単位で排他論理和した値をコンテンツチェック値生成鍵Ｋｉｃｖｃで暗号化した値として生成される。また、パーツｊが暗号化されていない場合は、データ（平文）全体を８バイト単位で図３６に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。
【０３５２】
さらに、１つのブロックｉ内にチェツク対象であることを示す［ＩＣＶフラグ＝ｓｕｂｊｅｃｔ ｏｆ ＩＣＶ］であるパーツが１つのみ存在する場合は、上述の手法で生成したチェック値Ｐ−ＩＣＶｉｊをそのままブロックのチェック値ＩＣＶｉとし、また、１つのブロックｉ内にチェツク対象であることを示す［ＩＣＶフラグ＝ｓｕｂｊｅｃｔ ｏｆ ＩＣＶ］であるパーツが複数存在する場合は、複数のパーツチェック値Ｐ−ＩＣＶｉ，ｊをパーツ番号順に連結したデータを対象にしてデータ（平文）全体を８バイト単位で図３６に示す改竄チェック値生成関数（ＤＥＳ−ＣＢＣ−ＭＡＣ、コンテンツチェック値生成鍵Ｋｉｃｖｃを鍵とする）に入力して得た値として生成される。これは、先に図３７で説明した通りである。
【０３５３】
フォーマットタイプ１では、上述の手順で生成されたコンテンツチェック値の比較処理がステップＳ２２２で実行されることになる。以下のステップＳ２２３以下の処理はフォーマットタイプ０と同様であるので説明は省略する。
【０３５４】
次に、フォーマットタイプ２におけるコンテンツデータの再生処理について図４４を用いて説明する。上記したフォーマットタイプ０，１の再生処理と異なる点を中心に説明する。
【０３５５】
ステップＳ２０１〜Ｓ２１０は、上記したフォーマットタイプ０，１の再生処理と同様であるので説明は省略する。
【０３５６】
フォーマットタイプ２においては、フォーマットタイプ０，１において実行されたステップＳ２１１〜Ｓ２１６の処理が実行されない。また、フォーマットタイプ２においては、コンテンツチェック値を持たないため、フォーマットタイプ０，１において実行されたステップＳ２２２のコンテンツチェック値の検証も実行されない。
【０３５７】
フォーマットタイプ２のデータ再生処理においては、ステップＳ２１０のチェック値Ｂの検証ステップの後、ステップＳ２１７に進み、記録再生器３００の制御部３０１の制御によって、ブロックデータが読み出される。さらに、ステップＳ２４１において、記録再生器３００の暗号処理部３０６によるブロックデータに含まれるブロック鍵Ｋｂｌｃの復号処理が実行される。記録デバイス４００に格納されたブロック鍵Ｋｂｌｃは、図３４で示すようにコンテンツ鍵Ｋｃｏｎで暗号化されており、先のステップＳ２０７において復号したコンテンツ鍵Ｋｃｏｎを用いてブロック鍵Ｋｂｌｃの復号を行なう。
【０３５８】
次に、ステップＳ２４２において、ステップＳ２４１で復号されたブロック鍵Ｋｂｌｃを用いてブロックデータの復号処理が実行される。さらに、ステップＳ２４３において、コンテンツ（プログラム、データ）の実行、再生処理が実行される。ステップＳ２１７〜ステップＳ２４３の処理が全ブロックについて繰り返し実行される。ステップＳ２４４において全ブロック読み出しと判定されると再生処理は終了する。
【０３５９】
このようにフォーマットタイプ２の処理は、総チェック値等のチェック値検証処理を省略しており、高速な復号処理の実行に適している構成であり、音楽データ等リアルタイム処理が要求されるデータ処理に適したフォーマットである。
【０３６０】
次にフォーマットタイプ３におけるコンテンツデータの再生処理について図４５を用いて説明する。上記したフォーマットタイプ０，１，２の再生処理と異なる点を中心に説明する。
【０３６１】
フォーマットタイプ３は、基本的にフォーマットタイプ２における処理と共通する部分が多いが、フォーマットタイプ３は図３５において説明したようにコンテンツ鍵を有しておらず、またブロック鍵Ｋｂｌｃが記録デバイスにおいては保存鍵Ｋｓｔｒで暗号化されて格納される点がフォーマットタイプ２と異なる。
【０３６２】
ステップＳ２０１〜Ｓ２１０において、ステップＳ２５１、ステップＳ２５２、ステップＳ２５３、ステップＳ２５４の処理は、前述のフォーマットタイプ０，１，２における対応処理と異なりコンテンツ鍵を含まない処理として構成されている。
【０３６３】
ステップＳ２５１において、記録再生器３００の制御部３０１は、読み出したヘッダから記録デバイス固有の保存鍵Ｋｓｔｒで暗号化されたブロック情報鍵Ｋｂｉｔを取り出し、記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０３６４】
記録再生器３００から送信されてきたブロック情報鍵Ｋｂｉｔを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで復号化処理させ、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで再暗号化させる。この処理は、前述した（９）相互認証後の鍵交換処理の欄で詳しく述べた通りである。
【０３６５】
ステップＳ２５２では、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００からセッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔを受信する。
【０３６６】
次に、ステップＳ２５３において、記録再生器３００の制御部３０１は、受信したセッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔを記録再生器３００の記録再生器暗号処理部３０２に送信し、セッション鍵Ｋｓｅｓで再暗号化されたブロック情報鍵Ｋｂｉｔを受信した記録再生器３００の記録再生器暗号処理部３０２は、記録再生器暗号処理部３０２の暗号／復号化部３０８に、セッション鍵Ｋｓｅｓで暗号化されたブロック情報鍵Ｋｂｉｔを、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化させる。
【０３６７】
さらに、ステップＳ２０８において、復号化したブロック情報鍵Ｋｂｉｔで、ステップＳ２０２で読み出しておいたブロック情報を復号化する。なお、記録再生器３００の記録再生器暗号処理部３０２は、復号化したブロック情報鍵Ｋｂｉｔおよびブロック情報ＢＩＴを、ステップＳ２０２で読み出したヘッダに含まれるブロック情報鍵Ｋｂｉｔおよびブロック情報ＢＩＴに置き換えて保持しておく。また、記録再生器３００の制御部３０１は、復号化されたブロック情報ＢＩＴを記録再生器３００の記録再生器暗号処理部３０２から読み出しておく。
【０３６８】
さらに、ステップＳ２５４において、記録再生器暗号処理部３０２の制御部３０６は、ブロック情報鍵Ｋｂｉｔおよびブロック情報（ＢＩＴ）から、チェック値Ｂ（ＩＣＶｂ’）を生成する。チェック値Ｂは、図２４に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているチェック値Ｂ生成鍵Ｋｉｃｖｂを鍵とし、ブロック情報鍵Ｋｂｉｔおよびブロック情報（ＢＩＴ）からなる排他的論理和値をＤＥＳで暗号化して生成する。次に、ステップＳ２１０において、チェック値Ｂとヘッダ（Header）内のＩＣＶｂを比較し、一致していた場合にはステップＳ２１１へ進む。
【０３６９】
フオーマットタイプ３では、さらに、ブロック鍵が記録デバイスでの格納時に保存鍵によって暗号化されるため、記録デバイス４００における保存鍵での復号処理、およびセッション鍵での暗号化処理、さらに、記録再生器３００でのセッション鍵での復号処理が必要となる。これらの一連の処理がステップＳ２５５、ステップＳ２５６で示した処理ステップである。
【０３７０】
ステップＳ２５５では、記録再生器３００の制御部３０１は、ステップＳ２１７で読み出したブロックから記録デバイス固有の保存鍵Ｋｓｔｒで暗号化されたブロック鍵Ｋｂｌｃを取り出し、記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０３７１】
記録再生器３００から送信されてきたブロック鍵Ｋｂｌｃを受信した記録デバイス４００は、受信したデータを記録デバイス暗号処理部４０１の暗号／復号化部４０６に、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで復号化処理させ、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで再暗号化させる。この処理は、前述した「（９）相互認証後の鍵交換処理」の欄で詳しく述べた通りである。
【０３７２】
ステップＳ２５６では、記録再生器３００の制御部３０１は、記録再生器３００の記録デバイスコントローラ３０３を介し、記録デバイス４００からセッション鍵Ｋｓｅｓで再暗号化されたブロック鍵Ｋｂｌｃを受信する。
【０３７３】
次に、ステップＳ２５７において、記録再生器３００の暗号処理部３０６によるブロック鍵Ｋｂｌｃのセッション鍵Ｋｓｅｓを用いた復号処理が実行される。
【０３７４】
次に、ステップＳ２４２において、ステップＳ２５７で復号されたブロック鍵Ｋｂｌｃを用いてブロックデータの復号処理が実行される。さらに、ステップＳ２４３において、コンテンツ（プログラム、データ）の実行、再生処理が実行される。ステップＳ２１７〜ステップＳ２４３の処理が全ブロックについて繰り返し実行される。ステップＳ２４４において全ブロック読み出しと判定されると再生処理は終了する。
【０３７５】
以上の処理が、フォーマットタイプ３におけるコンテンツの再生処理である。総チェック値の検証処理が省略された点でフォーマットタイプ２と類似するが、ブロック鍵の鍵交換処理を含む点でフォーマットタイプ２に比較して、さらにセキュリテイ・レベルの高い処理構成となっている。
【０３７６】
（１１）コンテンツプロバイダにおけるチェック値（ＩＣＶ）生成処理態様
上述の実施例中において、各種のチェック値ＩＣＶについての検証処理が、コンテンツのダウンロード、または再生処理等の段階で実行されることを説明してきた。ここでは、これら各チェック値（ＩＣＶ）生成処理、検証処理の態様について説明する。
【０３７７】
まず、実施例で説明した各チェック値について、簡潔にまとめると、本発明のデータ処理装置において利用されるチェック値ＩＣＶには以下のものがある。
【０３７８】
チェック値Ａ，ＩＣＶａ：コンテンツデータ中の識別情報、取扱方針の改竄を検証するためのチェック値。
チェック値Ｂ，ＩＣＶｂ：ブロック情報鍵Ｋｂｉｔ、コンテンツ鍵Ｋｃｏｎ、ブロック情報の改竄を検証するためのチェック値。
コンテンツチェック値ＩＣＶｉ：コンテンツの各コンテンツブロックの改竄を検証するためのチェック値。
総チェック値ＩＣＶｔ：チェック値ＩＣＶａ、チェック値ＩＣＶｂ、各コンテンツブロックのチェック値全ての改竄を検証するためのチェック値である。
再生器固有チェック値ＩＣＶｄｅｖ：ローカリゼーションフラグが１にセットされている場合、すなわち、コンテンツが記録再生器固有に利用可能であることを示している場合に、総チェック値ＩＣＶｔに置き換えられるチェック値であり、前述のチェック値Ａ：ＩＣＶａ、チェック値Ｂ：ＩＣＶｂ、さらにコンテンツのチェック対象となっている各ブロックに含まれるチェック値ＩＣＶｉ全体に対するチェック値として生成される。
フォーマットによっては、ＩＣＶｔ、ＩＣＶｄｅｖがチェックする対象に含まれるのは、各コンテンツブロックのチェック値ではなく、コンテンツそのものとなる場合もある。
【０３７９】
以上の各チェック値が本発明のデータ処理装置において用いられる。上記各チェック値の中で、チェック値Ａ、チェック値Ｂ、総チェック値、コンテンツチェック値は、例えば図３２〜３５、および図６に示されるようにコンテンツデータを提供するコンテンツプロバイダ、あるいはコンテンツ管理者によって、それぞれの検証対象データに基づいてＩＣＶ値が生成され、コンテンツと共にデータ中に格納されて記録再生器３００の利用者に提供される。記録再生器の利用者、すなわちコンテンツ利用者は、このコンテンツを記録デバイスにダウンロードする際、または再生する際にそれぞれの検証対象データに基づいて検証用のＩＣＶを生成して、格納済みのＩＣＶとの比較を行なう。また、再生器固有チェック値ＩＣＶｄｅｖは、コンテンツが記録再生器固有に利用可能であることを示している場合に、総チェック値ＩＣＶｔに置き換えられて、記録デバイスに格納されるものである。
【０３８０】
チェック値の生成処理は、前述の実施例中では、主としてＤＥＳ−ＣＢＣによる生成処理構成を説明してきた。しかし、ＩＣＶの生成処理態様には、上述の方法に限らず様々な生成処理態様、さらに、様々な検証処理態様がある。特にコンテンツ提供者または管理者と、コンテンツ利用者との関係においては、以下に説明する各種のＩＣＶ生成および検証処理構成が可能である。
【０３８１】
図４６〜図４８にチェック値ＩＣＶの生成者における生成処理と、検証者による検証処理を説明する図を示す。
【０３８２】
図４６は、上述の実施例中で説明したＤＥＳ−ＣＢＣによるＩＣＶの生成処理を、例えばコンテンツ提供者または管理者であるＩＣＶ生成者が行ない、生成したＩＣＶをコンテンツと共に記録再生器利用者、すなわち検証者に提供する構成である。この場合に記録再生器利用者、すなわち検証者が検証処理の際に必要となる鍵は、例えば図１８に示す内部メモリ３０７に格納された各チェック値生成鍵である。コンテンツ利用者である検証者（記録再生器利用者）は、内部メモリ３０７に格納されたチェック値生成鍵を使用して、検証対象のデータにＤＥＳ−ＣＢＣを適用してチェック値を生成して格納チェック値と比較処理を実行する。この場合、各チェック値生成鍵は、ＩＣＶの生成者と、検証者が秘密に共有する鍵として構成される。
【０３８３】
図４７は、コンテンツ提供者または管理者であるＩＣＶの生成者が公開鍵暗号系のデジタル署名によりＩＣＶを生成して、生成したＩＣＶをコンテンツと共にコンテンツ利用者、すなわち検証者に提供する。コンテンツ利用者、すなわち検証者は、ＩＣＶ生成者の公開鍵を保存し、この公開鍵を用いてＩＣＶの検証処理を実行する構成である。この場合、コンテンツ利用者（記録再生器利用者）、すなわち検証者の有するＩＣＶ生成者の公開鍵は秘密にする必要がなく、管理は容易となる。ＩＣＶの生成、管理が１つのエンティテイにおいて実行される場合等、ＩＣＶの生成、管理が高いセキュリティ管理レベルで行われている場合に適した態様である。
【０３８４】
図４８は、コンテンツ提供者または管理者であるＩＣＶの生成者が公開鍵暗号系のデジタル署名によりＩＣＶを生成して、生成したＩＣＶをコンテンツと共にコンテンツ利用者、すなわち検証者に提供し、さらに、検証者が検証に用いる公開鍵を公開鍵証明書（例えば図１４参照）に格納してコンテンツデータと共に記録再生器利用者、すなわち検証者に提供する。ＩＣＶの生成者が複数存在する場合には、各生成者は、公開鍵の正当性を証明するデータ（公開鍵証明書）を鍵管理センタに作成してもらう。
【０３８５】
ＩＣＶの検証者であるコンテンツ利用者は、鍵管理センタの公開鍵を持ち、検証者は公開鍵証明書の検証を鍵管理センタの公開鍵によって実行し、正当性が確認されたら、その公開鍵証明書に格納されたＩＣＶの生成者の公開鍵を取り出す。さらに、取り出したＩＣＶの生成者の公開鍵を用いてＩＣＶの検証を実行する。
【０３８６】
この方法は、ＩＣＶの生成者が複数あり、それらの管理を実行するセンタによる管理の実行システムが確立している場合に有効な態様である。
【０３８７】
（１２）マスタ鍵に基づく暗号処理鍵生成構成
次に、本発明のデータ処理システムにおける特徴的な構成の１つである、マスタ鍵に基づく各種暗号処理用鍵の生成構成について説明する。
【０３８８】
先に図１８を用いて説明したように、本発明のデータ処理装置における記録再生器３００の内部メモリには、様々なマスタ鍵が格納され、これらの各マスタ鍵を用いて、例えば認証鍵Ｋａｋｅを生成（数３参照）したり、あるいは配送鍵Ｋｄｉｓを生成（数４参照）する構成となっている。
【０３８９】
従来、1対１のエンティテイ間、すなわちコンテンツプロバイダとコンテンツ利用者間、あるいは、上述の本発明のデータ処理装置における記録再生器３００と記録メディア４００との間において暗号通信、相互認証、ＭＡＣ生成、検証等を行なう際には、各エンティテイに共通な秘密情報、例えば鍵情報を保持させていた。また、１対多の関係、例えば１つのコンテンツプロバイダに対する多数のコンテンツ利用者、あるいは１つの記録再生器に対する多数の記録メディア等の関係においては、すべてのエンティテイ、すなわち多数のコンテンツ利用者、あるいは多数の記録メディアにおいて共有させた秘密情報、例えば鍵情報を格納保持させる構成とするか、あるいは、１つのコンテンツプロバイダが多数のコンテンツ利用者各々の秘密情報(ｅｘ．鍵)を個別に管理し、これを各コンテンツ利用者に応じて使い分けていた。
【０３９０】
しかしながら、上記のような１対多の利用関係がある場合、すべてが共有する秘密情報(ｅｘ．鍵)を所有する構成においては、１箇所の秘密漏洩が発生すると同じ秘密情報(ｅｘ．鍵)を利用している者すべてに影響が及ぶという欠点がある。また、１つの管理者、例えばコンテンツプロバイダが多数のコンテンツ利用者各々の秘密情報(ｅｘ．鍵)を個別に管理し、これを各コンテンツ利用者に応じて使い分ける構成とすると、すべての利用者を識別し、かつその識別データに固有の秘密情報(ｅｘ．鍵)を対応づけたリストが必要となり、利用者の増大に伴うリストの保守管理の負担が増加するという欠点がある。
【０３９１】
本発明のデータ処理装置においては、このようなエンティテイ間における秘密情報の共有における従来の問題点をマスター鍵の保有、およびマスター鍵から各種の個別鍵を生成する構成により解決した。以下、この構成について説明する。
【０３９２】
本発明のデータ処理装置においては、記録デバイスやコンテンツを格納したメディア、または記録再生器間での各種の暗号処理、認証処理等において異なる個別の鍵が必要になる場合、その個別の鍵を、デバイスやメディアが固有に持つ識別子データ（ＩＤ）などの個別情報と記録再生器３００内であらかじめ決められた個別鍵生成方式を用いて生成する。この構成により万が一、生成された個別の鍵が特定された場合でもマスター鍵の漏洩を防止すれば、システム全体への被害を防ぐことが可能となる。またマスター鍵によって鍵を生成する構成により対応づけリストの管理も不要となる。
【０３９３】
具体的な構成例について、図を用いて説明する。まず、図４９に各種の鍵を記録再生器３００の有する各種のマスタ鍵を用いて生成する構成を説明する図を示す。図４９のメディア５００、通信手段６００からは、すでに説明した実施例と同様、コンテンツが入力される。コンテンツはコンテンツ鍵Ｋｃｏｎによって暗号化され、またコンテンツ鍵Ｋｃｏｎは、配送鍵Ｋｄｉｓによって暗号化されている。
【０３９４】
例えば、記録再生器３００がメディア５００、通信手段６００からコンテンツを取り出して、記録デバイス４００にダウンロードしようとする場合、先の図２２、図３９〜４１において説明したように、記録再生器３００は、コンテンツ鍵を暗号化している配送鍵Ｋｄｉｓを取得することが必要となる。このＫｄｉｓをメディア５００、通信手段６００から直接取得したり、あるいは予め記録再生器３００が取得して記録再生器３００内のメモリに格納しておくことも可能であるが、このような鍵の多数のユーザに対する配布構成は、先にも説明したようにシステム全体に影響を及ぼす漏洩の可能性がある。
【０３９５】
本発明のデータ処理システムでは、この配送鍵Ｋｄｉｓを図４９の下部に示すように、記録再生器３００のメモリに格納された配送鍵用マスター鍵ＭＫｄｉｓと、コンテンツＩＤに基づく処理、すなわちＫｄｉｓ＝ＤＥＳ（ＭＫｄｉｓ，コンテンツＩＤ）を適用して配送鍵Ｋｄｉｓを生成する構成としている。本構成によれば、メディア５００、通信手段６００からコンテンツを供給するコンテンツプロバイダとそのコンテンツ利用者である記録再生器３００間におけるコンテンツ配布構成において、コンテンツプロバイダが多数存在した場合であっても、個々の配送鍵Ｋｄｉｓをメディア、通信媒体等を介して流通させる必要もなく、また、各記録再生器３００に格納する必要もなく、セキュリティを高度に保つことが可能となる。
【０３９６】
次に、認証鍵Ｋａｋｅの生成について説明する。先に説明した図２２、図３９〜４１の記録再生器３００から記録メディア４００に対するダウンロード処理、あるいは図２８，図４２〜４５で説明した記録メディア４００に格納されたコンテンツを記録再生器３００において実行、再生する場合、記録再生器３００と記録メディア４００間における相互認証処理（図２０参照）が必要となる。
【０３９７】
図２０で説明したように、この認証処理において記録再生器３００は認証鍵Ｋａｋｅが必要となる。記録再生器３００は、認証鍵を例えば記録メディア４００から直接取得したり、あるいは予め記録再生器３００が取得して記録再生器３００内のメモリに格納しておくことも可能であるが、上述の配送鍵の構成と同様、このような鍵の多数のユーザに対する配布構成は、システム全体に影響を及ぼす漏洩の可能性がある。
【０３９８】
本発明のデータ処理システムでは、この認証鍵Ｋａｋｅを図４９の下部に示すように、記録再生器３００のメモリに格納された認証鍵用マスター鍵ＭＫａｋｅと、記録デバイス識別ＩＤ：ＩＤｍｅｍに基づく処理、すなわちＫａｋｅ＝ＤＥＳ（ＭＫａｋｅ，ＩＤｍｅｍ）によって認証鍵Ｋａｋｅを求める構成としている。
【０３９９】
さらに、図２２、図３９〜４１の記録再生器３００から記録メディア４００に対するダウンロード処理、あるいは図２８，図４２〜４５で説明した記録メディア４００に格納されたコンテンツを記録再生器３００において実行、再生する場合、記録再生器固有に利用可能なコンテンツである場合の記録再生器固有チェック値ＩＣＶｄｅｖの生成処理に必要となる記録再生器署名鍵Ｋｄｅｖについても上述の配送鍵、認証鍵と同様の構成とすることができる。上述の実施例中では、記録再生器署名鍵Ｋｄｅｖは内部メモリに格納する構成としていたが、記録再生器署名鍵用マスター鍵ＭＫｄｅｖをメモリに格納し、記録再生器署名鍵Ｋｄｅｖは内部メモリに格納せず、必要に応じて図４９の下部に示すように記録再生器識別子：ＩＤｄｅｖと記録再生器署名鍵用マスター鍵ＭＫｄｅｖに基づいて、Ｋｄｅｖ＝ＤＥＳ（ＭＫｄｅｖ，ＩＤｄｅｖ）によって記録再生器署名鍵Ｋｄｅｖを求める構成とすることで、記録再生器署名鍵Ｋｄｅｖを機器個別に持たせる必要がなくなるという利点が挙げられる。
【０４００】
このように、本発明のデータ処理装置においては、プロバイダと記録再生器、あるいは記録再生器と記録デバイス間のような２つのエンテイテイ間における暗号情報処理に関する手続きに必要な鍵等の情報をマスター鍵と各ＩＤから逐次的に生成する構成としたので、鍵情報が各エンテイテイから漏洩した場合でも、個別の鍵による被害の範囲はより限定され、また前述したような個別のエンテイテイごとの鍵リストの管理も不要となる。
【０４０１】
本構成に関する複数の処理例についてフローを示して説明する。図５０は、コンテンツ製作または管理者におけるマスター鍵を用いたコンテンツ等の暗号化処理と、ユーザデバイス、例えば上述の実施例における記録再生器３００におけるマスター鍵を用いた暗号化データの復号処理例である。
【０４０２】
コンテンツ製作または管理者におけるステップＳ５０１は、コンテンツに対する識別子（コンテンツＩＤ）を付与するステップである。ステップＳ５０２は、コンテンツ製作または管理者の有するマスター鍵とコンテンツＩＤとに基づいてコンテンツ等を暗号化する鍵を生成するステップである。これは例えば、配送鍵Ｋｄｉｓを生成する工程とすれば、前述のＫｄｉｓ＝ＤＥＳ（ＭＫｄｉｓ，コンテンツＩＤ）によって配送鍵Ｋｄｉｓを生成する。次に、ステップＳ５０３は、コンテンツの一部、または全部を鍵（例えば配送鍵Ｋｄｉｓ）によって暗号化するステップである。コンテンツ製作者は、このようなステップを経て暗号化処理を行なったコンテンツをＤＶＤ等のメディア、通信手段等を介して配信する。
【０４０３】
一方、例えば記録再生器３００等のユーザデバイス側では、ステップＳ５０４において、メディア、通信手段等を介して受領したコンテンツデータ中からコンテンツＩＤを読み出す。次に、ステップＳ５０５において、読み出したコンテンツＩＤと所有するマスター鍵に基づいて暗号化コンテンツの復号に適用する鍵を生成する。この生成処理は、配送鍵Ｋｄｉｓを得るものである場合は、例えば配送鍵Ｋｄｉｓ＝ＤＥＳ（ＭＫｄｉｓ，コンテンツＩＤ）となる。ステップＳ５０６で、この鍵を用いてコンテンツを復号し、ステップＳ５０７で復号コンテンツの利用、すなわち再生またはプログラムを実行する。
【０４０４】
この例においては、図５０下段に示すように、コンテンツ製作または管理者と、ユーザデバイスの双方がマスター鍵（例えば配送鍵生成用マスター鍵ＭＫｄｉｓ）を有し、コンテンツの暗号化、復号に必要な配送鍵を逐次的にそれぞれの所有するマスター鍵と各ＩＤ（コンテンツＩＤ）に基づいて生成する。
【０４０５】
このシステムでは、万が一配送鍵が第三者に漏洩した場合、そのコンテンツの復号が第三者において可能となるが、コンテンツＩＤの異なる他のコンテンツの復号は防止することが可能であるため、１つのコンテンツ鍵の漏洩がシステム全体に及ぼす影響を最小限にすることができるという効果がある。また、ユーザデバイス側、すなわち記録再生器において、コンテンツ毎の鍵の対応付けリストを保持する必要がないという効果もある。
【０４０６】
次に図５１を用いて、コンテンツ製作または管理者が複数のマスター鍵を所有して、コンテンツの配信対象に応じた処理を実行する例について説明する。
【０４０７】
コンテンツ製作または管理者におけるステップＳ５１１は、コンテンツに対する識別子（コンテンツＩＤ）を付与するステップである。ステップＳ５１２は、コンテンツ製作または管理者の有する複数のマスター鍵（例えば複数の配送鍵生成用マスター鍵ＭＫｄｉｓ）から１つのマスター鍵を選択するステップである。この選択処理は図５２を用いてさらに説明するが、コンテンツの利用者の国ごと、機種ごと、あるいは機種のバージョンごとなどに対応付けて予め適用するマスター鍵を設定しておき、その設定に従って実行するものである。
【０４０８】
次に、ステップＳ５１３では、ステップＳ５１２で選択したマスター鍵と、ステップＳ５１１で決定したコンテンツＩＤとに基づいて暗号化用の鍵を生成する。これは例えば、配送鍵Ｋｄｉｓｉを生成する工程とすれば、Ｋｄｉｓｉ＝ＤＥＳ（ＭＫｄｉｓｉ，コンテンツＩＤ）によって生成する。次に、ステップＳ５１４はコンテンツの一部、または全部を鍵（例えば配送鍵Ｋｄｉｓｉ）によって暗号化するステップである。コンテンツ製作者は、ステップＳ５１５において、コンテンツＩＤと、使用したマスター鍵識別情報と、暗号化コンテンツを１つの配布単位として暗号化処理を行なったコンテンツをＤＶＤ等のメディア、通信手段等を介して配信する。
【０４０９】
一方、例えば記録再生器３００等のユーザデバイス側では、ステップＳ５１６において、ＤＶＤ等のメディア、通信手段等を介して配信されたコンテンツデータ中のマスター鍵識別情報に対応するマスター鍵を自己が所有するか否かについて判定する。コンテンツデータ中のマスター鍵識別情報に対応するマスター鍵を持たない場合は、その配布コンテンツは、そのユーザデバイスにおいては利用できないものであり、処理は終了する。
【０４１０】
配信されたコンテンツデータ中のマスター鍵識別情報に対応するマスター鍵を自己が所有する場合は、ステップＳ５１７において、メディア、通信手段等を介して受領したコンテンツデータ中からコンテンツＩＤを読み出す。次に、ステップＳ５１８において、読み出したコンテンツＩＤと所有するマスター鍵に基づいて暗号化コンテンツの復号に適用する鍵を生成する。この生成処理は、配送鍵Ｋｄｉｓｉを得るものである場合は、例えば配送鍵Ｋｄｉｓｉ＝ＤＥＳ（ＭＫｄｉｓｉ，コンテンツＩＤ）となる。ステップＳ５１９で、この鍵を用いてコンテンツを復号し、ステップＳ５２０で復号コンテンツの利用、すなわち再生またはプログラムを実行する。
【０４１１】
この例においては、図５１下段に示すように、コンテンツ製作または管理者は、複数のマスター鍵、例えば複数の配送鍵生成用マスター鍵ＭＫｄｉｓ１〜ｎからなるマスター鍵セットを有する。一方、ユーザデバイスには１つのマスター鍵例えば１つの配送鍵生成用マスター鍵ＫＫｄｉｓｉを有し、コンテンツ製作または管理者がＭＫｄｉｓｉを用いて暗号化処理している場合のみ、ユーザデバイスは、そのコンテンツを復号して利用することができる。
【０４１２】
この図５１のフローに示す態様の具体例として、国毎に異なるマスター鍵を適用した例を図５２に示す。コンテンツプロバイダは、マスター鍵ＭＫ１〜ｎを有し、ＭＫ１は日本向けのユーザデバイスに配信するコンテンツの暗号化処理を実行する鍵生成に用いる。例えば、コンテンツＩＤとＭＫ１から暗号化鍵Ｋ１を生成してＫ１によってコンテンツを暗号化する。また、ＭＫ２はＵＳ向けのユーザデバイスに配信するコンテンツの暗号化処理を実行する鍵生成に用い、ＭＫ３はＥＵ（ヨーロッパ）向けのユーザデバイスに配信するコンテンツの暗号化処理を実行する鍵生成に用いるよう設定している。
【０４１３】
一方、日本向けユーザデバイス、具体的には日本で販売されるＰＣまたはゲーム機器等の記録再生器には、マスター鍵ＭＫ１がその内部メモリに格納され、ＵＳ向けユーザデバイスには、マスター鍵ＭＫ２がその内部メモリに格納され、ＥＵ向けユーザデバイスには、マスター鍵ＭＫ３がその内部メモリに格納されている。
【０４１４】
このような構成において、コンテンツプロバイダは、コンテンツを利用可能なユーザデバイスに応じて、マスター鍵ＭＫ１〜ｎから、マスター鍵を選択的に使用してユーザデバイスに配信するコンテンツの暗号化処理を実行する。例えばコンテンツを日本向けのユーザデバイスのみ利用可能とするためには、マスター鍵ＭＫ１を用いて生成された鍵Ｋ１によってコンテンツを暗号化する。この暗号化コンテンツは、日本向けユーザデバイスに格納されたマスター鍵ＭＫ１を用いて復号可能、すなわち復号鍵を生成可能であるが、他のＵＳ、またはＥＵ向けのユーザデバイスに格納されたマスター鍵ＭＫ２，ＭＫ３からは鍵Ｋ１を得ることができないので、暗号化コンテンツの復号は不可能となる。
【０４１５】
このように、コンテンツプロバイダが複数のマスター鍵を選択的に使用することにより、様々なコンテンツの利用制限を設定することができる。図５２では、ユーザデバイスの国別にマスター鍵を区別する例を示したが、前述のように、ユーザデバイスの機種に応じて、あるいはバージョンに応じてマスター鍵を切り換える等、様々な利用形態が可能である。
【０４１６】
次に、図５３にメデイア固有の識別子、すなわちメディアＩＤとマスター鍵を組み合わせた処理例を示す。ここで。メディアとは例えばＤＶＤ、ＣＤ等のコンテンツを格納したメディアである。メディアＩＤは、１つ１つのメディアごとに固有としてもよいし、たとえば、映画などのコンテンツのタイトルごとに固有としてもよいし、メディアの製造ロットごとに固有としてもよい。このようにメディアＩＤの割り当て方法としては様々な方法を用いることができる。
【０４１７】
メデイア製作または管理者におけるステップＳ５２１は、メディアに対する識別子（メディアＩＤ）を決定するステップである。ステップＳ５２２は、メディア製作または管理者の有するマスター鍵とメディアＩＤとに基づいてメディア内の格納コンテンツ等を暗号化する鍵を生成するステップである。これは例えば、配送鍵Ｋｄｉｓを生成する工程とすれば、前述のＫｄｉｓ＝ＤＥＳ（ＭＫｄｉｓ，メディアＩＤ）によって配送鍵Ｋｄｉｓを生成する。次に、ステップＳ５２３は、メディア格納コンテンツの一部、または全部を鍵（例えば配送鍵Ｋｄｉｓ）によって暗号化するステップである。メディア製作者は、このようなステップを経て暗号化処理を行なったコンテンツ格納メディアを供給する。
【０４１８】
一方、例えば記録再生器３００等のユーザデバイス側では、ステップＳ５２４において、供給されたメディアからメディアＩＤを読み出す。次に、ステップＳ５２５において、読み出したメディアＩＤと所有するマスター鍵に基づいて暗号化コンテンツの復号に適用する鍵を生成する。この生成処理は、配送鍵Ｋｄｉｓを得るものである場合は、例えば配送鍵Ｋｄｉｓ＝ＤＥＳ（ＭＫｄｉｓ，メディアＩＤ）となる。ステップＳ５２６で、この鍵を用いてコンテンツを復号し、ステップＳ５２７で復号コンテンツの利用、すなわち再生またはプログラムを実行する。
【０４１９】
この例においては、図５３下段に示すように、メディア製作または管理者と、ユーザデバイスの双方がマスター鍵（例えば配送鍵生成用マスター鍵ＭＫｄｉｓ）を有し、コンテンツの暗号化、復号に必要な配送鍵を逐次的にそれぞれの所有するマスター鍵と各ＩＤ（メディアＩＤ）に基づいて生成する。
【０４２０】
このシステムでは、万が一メディア鍵が第三者に漏洩した場合、そのメディア内のコンテンツの復号が第三者において可能となるが、メディアＩＤの異なる他のメディアに格納されたコンテンツの復号は防止することが可能であるため、１つのメディア鍵の漏洩がシステム全体に及ぼす影響を最小限にすることができるという効果がある。また、ユーザデバイス側、すなわち記録再生器において、メディア毎の鍵の対応付けリストを保持する必要がないという効果もある。また、１つのメディア鍵で暗号化されるコンテンツサイズは、そのメデイア内に格納可能な容量に制限されるため、暗号文攻撃のために必要な情報量に達する可能性は少なく、暗号解読の可能性を低減させることができる。
【０４２１】
次に、図５４に記録再生器固有の識別子、すなわち記録再生器ＩＤとマスター鍵を組み合わせた処理例を示す。
【０４２２】
記録再生器利用者におけるステップＳ５３１は、記録再生器の例えば内部メモリに格納されたマスター鍵と記録再生器ＩＤとに基づいてコンテンツ等を暗号化する鍵を生成するステップである。これは例えば、コンテンツ鍵Ｋｃｏｎを生成する工程とすれば、Ｋｃｏｎ＝ＤＥＳ（ＭＫｃｏｎ，記録再生器ＩＤ）によってコンテンツ鍵Ｋｃｏｎを生成する。次に、ステップＳ５３２は、格納するコンテンツの一部、または全部を鍵（例えば配送鍵Ｋｃｏｎ）によって暗号化するステップである。ステップＳ５３３は、暗号化コンテンツを例えばハードディスク等の記録デバイスに格納する。
【０４２３】
一方、記録再生器を管理するシステム管理者側では、コンテンツを格納した記録再生器利用者から格納データの復旧を依頼されると、ステップＳ５３４において、記録再生器から、記録再生器ＩＤを読み出す。次に、ステップＳ５３５において、読み出した記録再生器ＩＤと所有するマスター鍵に基づいて暗号化コンテンツの復号に適用する鍵を生成する。この生成処理は、コンテンツ鍵Ｋｃｏｎを得るものである場合は、例えばコンテンツ鍵Ｋｃｏｎ＝ＤＥＳ（ＭＫｃｏｎ，記録再生器ＩＤ）となる。ステップＳ５３６で、この鍵を用いてコンテンツを復号する。
【０４２４】
この例においては、図５４下段に示すように、記録再生器利用者と、システム管理者の双方がマスター鍵（例えばコンテンツ鍵生成用マスター鍵ＭＫｃｏｎ）を有し、コンテンツの暗号化、復号に必要な配送鍵を逐次的にそれぞれの所有するマスター鍵と各ＩＤ（記録再生器ＩＤ）に基づいて生成する。
【０４２５】
このシステムでは、万が一コンテンツ鍵が第三者に漏洩した場合、そのコンテンツの復号が第三者において可能となるが、記録再生器ＩＤの異なる他の記録再生器用に暗号化されたコンテンツの復号は防止することが可能であるため、１つのコンテンツ鍵の漏洩がシステム全体に及ぼす影響を最小限にすることができるという効果がある。また、システム管理側、ユーザデバイス側両者において、コンテンツ毎の鍵の対応付けリストを保持する必要がないという効果もある。
【０４２６】
図５５は、スレーブデバイス、例えばメモリカード等の記録デバイスと、ホストデバイス、例えば記録再生器間における相互認証処理に用いる認証鍵をマスター鍵に基づいて生成する構成である。先に説明した認証処理（図２０参照）では、スレーブデバイスの内部メモリに認証鍵を予め格納した構成としてあるが、これを図５５に示すように認証処理時にマスター鍵に基づいて生成する構成とすることができる。
【０４２７】
例えば記録デバイスであるスレーブデバイスは、認証処理開始前の初期化処理として、ステップＳ５４１において、記録デバイスであるスレーブデバイスの内部メモリに格納したマスター鍵とスレーブデバイスＩＤとに基づいて相互認証処理に用いる認証鍵Ｋａｋｅを生成する。これは例えば、Ｋａｋｅ＝ＤＥＳ（ＭＫａｋｅ，スレーブデバイスＩＤ）によって生成する。次に、ステップＳ５４２において、生成した認証鍵をメモリに格納する。
【０４２８】
一方、例えば記録再生器等のホストデバイス側では、ステップＳ５４３において、装着された記録デバイス、すなわちスレーブデバイスから、通信手段を介してスレーブデバイスＩＤを読み出す。次に、ステップＳ５４４において、読み出したスレーブデバイスＩＤと所有する認証鍵生成用マスター鍵に基づいて相互認証処理に適用する認証鍵を生成する。この生成処理は、例えば認証鍵Ｋａｋｅ＝ＤＥＳ（ＭＫａｋｅ，スレーブデバイスＩＤ）となる。ステップＳ５４５で、この認証鍵を用いて認証処理を実行する。
【０４２９】
この例においては、図５５下段に示すように、スレーブデバイスと、マスターデバイスの双方がマスター鍵、すなわち認証鍵生成用マスター鍵ＭＫａｋｅを有し、相互認証処理に必要な認証鍵を逐次的にそれぞれの所有するマスター鍵とスレーブデバイスＩＤに基づいて生成する。
【０４３０】
このシステムでは、万が一認証鍵が第三者に漏洩した場合、その認証鍵は、そのスレーブデバイスのみに有効であるため、他のスレーブデバイスとの関係においては、認証が成立しないことになり、鍵の漏洩によって発生する影響を最小限にすることができるという効果がある。
【０４３１】
このように、本発明のデータ処理装置においては、コンテンツプロバイダと記録再生器、あるいは記録再生器と記録デバイス間のような２つのエンテイテイ間における暗号情報処理に関する手続きに必要な鍵等の情報をマスター鍵と各ＩＤから逐次的に生成する構成とした。従って、鍵情報が各エンテイテイから漏洩した場合でも、個別の鍵による被害の範囲はより限定され、また前述したような個別のエンテイテイごとの鍵リストの管理も不要となる。
【０４３２】
（１３）暗号処理における暗号強度の制御
上述した実施例において、記録再生器３００と記録デバイス４００間での暗号処理は、説明を理解しやすくするため、主として、先に図７を用いて説明したシングルＤＥＳ構成による暗号処理を用いた例について説明してきた。しかしながら、本発明のデータ処理装置において適用される暗号化処理方式は上述したシングルＤＥＳ方式に何ら限定されるものではなく、必要なセキュリティ状態に応じた暗号化方式を採用することが可能である。
【０４３３】
例えば先に説明した図８〜図１０の構成のようなトリプルＤＥＳ方式を適用してもよい。例えば図３に示す記録再生器３００の暗号処理部３０２と、記録デバイス４００の暗号処理部４０１の双方において、トリプルＤＥＳ方式を実行可能な構成とし、図８〜図１０で説明したトリプルＤＥＳ方式による暗号処理に対応する処理を実行する構成が可能である。
【０４３４】
しかしながら、コンテンツの提供者は、コンテンツに応じて処理速度を優先してコンテンツ鍵ＫｃｏｎをシングルＤＥＳ方式による６４ビット鍵構成とする場合もあり、また、セキュリティを優先してコンテンツ鍵ＫｃｏｎをトリプルＤＥＳ方式による１２８ビット、または１９２ビット鍵構成とする場合もある。従って、記録再生器３００の暗号処理部３０２と、記録デバイス４００の暗号処理部４０１の構成をトリプルＤＥＳ方式、シングルＤＥＳ方式いずれか一方の方式にのみ対応可能な構成とすることは好ましくない。従って、記録再生器３００の暗号処理部３０２と、記録デバイス４００の暗号処理部４０１は、シングルＤＥＳ、トリプルＤＥＳいずれの方式にも対応可能とする構成が望ましい。
【０４３５】
しかしながら、記録再生器３００の暗号処理部３０２と、記録デバイス４００の暗号処理部４０１の暗号処理構成をシングルＤＥＳ方式、トリプルＤＥＳ方式の双方を実行可能な構成とするためには、それぞれの別の回路、ロジックを構成しなければならない。例えば、記録デバイス４００においてトリプルＤＥＳに対応する処理を実行するためには、先の図２９に示すコマンドレジスタにトリプルＤＥＳの命令セットを新たに格納することが必要となる。これは記録デバイス４００に構成する処理部の複雑化を招くこととなる。
【０４３６】
そこで、本発明のデータ処理装置は、記録デバイス４００側の暗号処理部４０１の有するロジックをシングルＤＥＳ構成として、かつトリプルＤＥＳ暗号化処理に対応した処理が実行可能で、トリプルＤＥＳ方式による暗号化データ(鍵、コンテンツ等)を記録デバイスの外部メモリ４０２に格納することを可能とした構成を提案する。
【０４３７】
例えば図３２に示すデータフォーマットタイプ０の例において、記録再生器３００から記録デバイス４００に対してコンテンツデータのダウンロードを実行する際、先に説明したフォーマットタイプ０のダウンロードのフローを示す図３９のステップＳ１０１で認証処理を実行し、ここでセッション鍵Ｋｓｅｓを生成する。さらに、ステップＳ１１７において、記録再生器３００側の暗号処理部３０２においてセッション鍵Ｋｓｅｓによるコンテンツ鍵Ｋｃｏｎの暗号化処理が実行され、この暗号化鍵が記録デバイス４００に通信手段を介して転送され、ステップＳ１１８において、この暗号化鍵を受信した記録デバイス４００の暗号処理部４０３がセッション鍵Ｋｓｅｓによるコンテンツ鍵Ｋｃｏｎの復号処理を実行し、さらに、保存鍵Ｋｓｔｒによるコンテンツ鍵Ｋｃｏｎの暗号化処理を実行して、これを記録再生器３００の暗号処理部３０２に送信し、その後、記録再生器３００がデータフォーマットを形成（ステップＳ１２１）してフォーマット化されたデータを記録デバイス４００に送信し、記録デバイス４００が受信したデータを外部メモリ４０２に格納する処理を行なっている。
【０４３８】
上記処理においてステップＳ１１７，Ｓ１１８間において実行される記録デバイス４００の暗号処理部４０１での暗号処理をシングルＤＥＳ、またはトリプルＤＥＳいずれかの方式を選択的に実行可能な構成とすれば、コンテンツ提供業者がトリプルＤＥＳにしたがったコンテンツ鍵Ｋｃｏｎを用いたコンテンツデータを提供する場合も、またシングルＤＥＳにしたがったコンテンツ鍵Ｋｃｏｎを用いたコンテンツデータを提供する場合も、いずれの場合にも対応可能となる。
【０４３９】
図５６に本発明のデータ処理装置における記録再生器３００の暗号処理部３０２と、記録デバイス４００の暗号処理部４０１との双方を用いてトリプルＤＥＳ方式に従った暗号処理方法を実行する構成を説明するフローを示す。図５６では、一例として記録再生器３００からコンテンツデータを記録デバイス４００にダウンロードする際に実行される保存鍵Ｋｓｔｒを用いたコンテンツ鍵Ｋｃｏｎの暗号化処理例であり、コンテンツ鍵ＫｃｏｎがトリプルＤＥＳ方式による鍵である場合の例を示している。なお、ここでは、コンテンツ鍵Ｋｃｏｎを代表して、その処理例を示すが、他の鍵、またはコンテンツ等、その他のデータについても同様の処理が可能である。
【０４４０】
トリプルＤＥＳ方式においては、先の図８〜１０において説明したように、シングルＤＥＳでは６４ビット鍵、トリプルＤＥＳ方式による場合は、１２８ビット、または１９２ビット鍵構成として、２つ、または３つの鍵が用いられる処理である。これら３つのコンテンツ鍵をそれぞれＫｃｏｎ１，Ｋｃｏｎ２，（Ｋｃｏｎ３）とする。Ｋｃｏｎ３は用いられない場合もあるので、かっこで示している。
【０４４１】
図５６の処理について説明する。ステップＳ３０１は記録再生器３００と、記録デバイス４００間での相互認証処理ステップである。この相互認証処理ステップは、先に説明した図２０の処理によって実行される。なお、この認証処理の際、セッション鍵Ｋｓｅｓが生成される。
【０４４２】
ステップＳ３０１の認証処理が終了すると、ステップＳ３０２において、各チェック値、チェック値Ａ，チェック値Ｂ、コンテンツチェック値、総チェック値、各ＩＣＶの照合処理が実行される。
【０４４３】
これらのチェック値（ＩＣＶ）照合処理が終了し、データ改竄がないと判定されると、ステップＳ３０３に進み、記録再生器３００において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８を使って、先に取り出したまたは生成した配送鍵Ｋｄｉｓを用いて、受信したメディア５００、または、通信部３０５を介して通信手段６００から受信したデータのヘッダ部に格納されたコンテンツ鍵Ｋｃｏｎの復号化処理を行う。この場合のコンテンツ鍵は、トリプルＤＥＳ方式による鍵であり、コンテンツ鍵Ｋｃｏｎ１，Ｋｃｏｎ２，（Ｋｃｏｎ３）である。
【０４４４】
次に、ステップＳ３０４において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８において、ステップＳ３０３で復号化したコンテンツ鍵Ｋｃｏｎ１，Ｋｃｏｎ２，（Ｋｃｏｎ３）の中のコンテンツ鍵Ｋｃｏｎ１のみを相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで暗号化する。
【０４４５】
記録再生器３００の制御部３０１は、セッション鍵Ｋｓｅｓで暗号化されたコンテンツ鍵Ｋｃｏｎ１を含むデータを記録再生器３００の記録再生器暗号処理部３０２から読み出し、これらのデータを記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０４４６】
次に、ステップＳ３０５において、記録再生器３００から送信されてきたコンテンツ鍵Ｋｃｏｎ１を受信した記録デバイス４００は、受信したコンテンツ鍵Ｋｃｏｎ１を記録デバイス暗号処理部４０１の暗号／復号化部４０６に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化する。さらに、ステップＳ３０６において、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで再暗号化させて、通信部４０４を介して記録再生器３００に送信する。
【０４４７】
次に、ステップＳ３０７において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８において、ステップＳ３０３で復号化したコンテンツ鍵Ｋｃｏｎ１，Ｋｃｏｎ２，（Ｋｃｏｎ３）の中のコンテンツ鍵Ｋｃｏｎ２のみを相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで暗号化する。
【０４４８】
記録再生器３００の制御部３０１は、セッション鍵Ｋｓｅｓで暗号化されたコンテンツ鍵Ｋｃｏｎ２を含むデータを記録再生器３００の記録再生器暗号処理部３０２から読み出し、これらのデータを記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０４４９】
次に、ステップＳ３０８において、記録再生器３００から送信されてきたコンテンツ鍵Ｋｃｏｎ２を受信した記録デバイス４００は、受信したコンテンツ鍵Ｋｃｏｎ２を記録デバイス暗号処理部４０１の暗号／復号化部４０６に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化する。さらに、ステップＳ３０９において、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで再暗号化させて、通信部４０４を介して記録再生器３００に送信する。
【０４５０】
次に、ステップＳ３１０において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８において、ステップＳ３０３で復号化したコンテンツ鍵Ｋｃｏｎ１，Ｋｃｏｎ２，（Ｋｃｏｎ３）の中のコンテンツ鍵Ｋｃｏｎ３のみを相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで暗号化する。
【０４５１】
記録再生器３００の制御部３０１は、セッション鍵Ｋｓｅｓで暗号化されたコンテンツ鍵Ｋｃｏｎ３を含むデータを記録再生器３００の記録再生器暗号処理部３０２から読み出し、これらのデータを記録再生器３００の記録デバイスコントローラ３０３を介して記録デバイス４００に送信する。
【０４５２】
次に、ステップＳ３１１において、記録再生器３００から送信されてきたコンテンツ鍵Ｋｃｏｎ３を受信した記録デバイス４００は、受信したコンテンツ鍵Ｋｃｏｎ３を記録デバイス暗号処理部４０１の暗号／復号化部４０６に、相互認証の際に共有しておいたセッション鍵Ｋｓｅｓで復号化する。さらに、ステップＳ３１２において、記録デバイス暗号処理部４０１の内部メモリ４０５に保存してある記録デバイス固有の保存鍵Ｋｓｔｒで再暗号化させて、通信部４０４を介して記録再生器３００に送信する。
【０４５３】
次にステップＳ３１３において、記録再生器の暗号処理部は、図３２〜３５で説明した各種のデータフォーマットを形成して、記録デバイス４００に送信する。
【０４５４】
最後にステップＳ３１４において、記録デバイス４００は、フォーマット形成が終了した受信データを外部メモリ４０２に格納する。このフオーマットデータには、保存鍵Ｋｓｔｒで暗号化されたコンテンツ鍵Ｋｃｏｎ１，Ｋｃｏｎ２，（Ｋｃｏｎ３）を含んでいる。
【０４５５】
このような処理を実行することにより、記録デバイス４００に格納するコンテンツ鍵をトリプルＤＥＳ方式の暗号方式による鍵として格納することが可能となる。なお、コンテンツ鍵がＫｃｏｎ１，Ｋｃｏｎ２の２つの鍵である場合は、ステップＳ３１０〜Ｓ３１２の処理は省略される。
【０４５６】
このように、記録デバイス４００は、同じ態様の処理、すなわちステップＳ３０５，Ｓ３０６の処理ステップを複数回、その対象を変更するのみで繰り返し実行することにより、トリプルＤＥＳの適用された鍵をメモリに格納可能となる。コンテンツ鍵ＫｃｏｎがシングルＤＥＳの適用鍵である場合は、ステップＳ３０５，Ｓ３０６を実行して、ステップＳ３１３のフォーマット化処理を実行してメモリに格納すればよい。このような構成は、ステップＳ３０５，Ｓ３０６の処理を実行するコマンドを先に説明した図２９のコマンドレジスタに格納し、この処理をコンテンツ鍵の態様、すなわちトリプルＤＥＳ方式か、シングルＤＥＳ方式かによって、適宜１回〜３回実行する構成とすればよい。従って、記録デバイス４００の処理ロジック中にトリプルＤＥＳの処理方式を含ませることなく、トリプルＤＥＳ方式、シングルＤＥＳ方式、の双方の処理が可能となる。なお、暗号化方式については、コンテンツデータのヘッダ部内の取扱方針に記録し、これを参照することで判定することが可能である。
【０４５７】
（１４）コンテンツデータにおける取扱方針中の起動優先順位に基づくプログラム起動処理
先に説明した図４〜６のコンテンツデータ構成から理解されるように、本発明のデータ処理装置において利用されるコンテンツデータのヘッダ部に格納された取扱方針には、コンテンツタイプ、起動優先順位情報が含まれる。本発明のデータ処理装置における記録再生器３００は、記録デバイス４００、あるいは、ＤＶＤ、ＣＤ、ハードディスク、さらにはゲームカートリッジ等の各種記録媒体に記録されたアクセス可能なコンテンツデータが複数存在する場合、これらコンテンツの起動順位を起動優先順位情報に従って決定する。
【０４５８】
記録再生器３００は、各記録デバイスＤＶＤ装置、ＣＤドライブ装置、ハードデイスクドライブ装置等各種記録デバイスとの認証処理を実行後、コンテンツデータ中の優先順位情報に従って、最も優先順位の高いコンテンツデータ中のプログラムを優先して実行する。以下、この「コンテンツデータにおける取扱方針中の起動優先順位に基づくプログラム起動処理」について説明する。
【０４５９】
上述した本発明のデータ処理装置実施例の説明においては、記録再生器３００が１つの記録デバイス４００からコンテンツデータを再生、実行する場合の処理を中心として説明した。しかし、一般に記録再生器３００は、図２に示すように記録デバイス４００の他に、読み取り部３０４を介してＤＶＤ、ＣＤ、ハードディスク、さらに、ＰＩＯ１１１、ＳＩＯ１１２を介して接続されるメモリカード、ゲームカートリッジ等、各種記録媒体にアクセス可能な構成を有する。なお、図２では、図の複雑化を避けるため読み取り部３０４を１つのみ記載しているが、記録再生器３００は、異なる記憶媒体、例えばＤＶＤ、ＣＤ、フロッピーディスク、ハードディスクを並列に装着可能である。
【０４６０】
記録再生器３００は、複数の記憶媒体にアクセス可能であり、それぞれの記憶媒体にはそれぞれコンテンツデータが格納されている。例えばＣＤ等外部のコンテンツプロバイダが供給するコンテンツデータは、前述の図４のデータ構成でメディアに格納され、これらのメディアまたは、通信手段を介してダウンロードした場合には、図２６、図２７のコンテンツデータ構成でメモリカード等の各記憶媒体に格納されている。さらに、具体的には、コンテンツデータのフォーマットタイプに応じて図３２〜３５に示すようにメディア上、記録デバイス上でそれぞれ異なるフォーマットで格納される。しかし、いずれの場合にもコンテンツデータのヘッダ中の取扱方針にはコンテンツタイプ、起動優先順位情報が含まれる。
【０４６１】
これら、複数のコンテンツデータに対するアクセスが可能な場合の記録再生器のコンテンツ起動処理をフローに従って説明する。
【０４６２】
図５７は、起動可能コンテンツが複数ある場合の処理例（１）を示す処理フローである。ステップＳ６１１は、記録再生器３００がアクセス可能な記録デバイスの認証処理を実行するステップである。アクセス可能な記録デバイスには、メモリカード、ＤＶＤ装置、ＣＤドライブ、ハードディスク装置、さらに、例えばＰＩＯ１１１、ＳＩＯ１１２を介して接続されるゲームカートリッジ等が含まれる。認証処理は、図２で示す制御部３０１の制御のもとに各記録デバイスに対して例えば先に図２０で説明した手順に従って実行される。
【０４６３】
次に、ステップＳ６１２おいて、認証に成功した記録デバイス内のメモリに格納されたコンテンツデータから起動可能なプログラムを検出する。これは、具体的には、コンテンツデータの取扱方針に含まれるコンテンツタイプがプログラムであるものを抽出する処理として実行される。
【０４６４】
次に、ステップＳ６１３において、ステップＳ６１２で抽出された起動可能なプログラムにおける起動優先順位を判定する。これは、具体的には、ステップＳ６１２において選択された複数の起動可能なコンテンツデータのヘッダ中の取扱情報に含まれる優先情報を比較して最も高い優先順位を選択する処理である。
【０４６５】
次にステップＳ６１４で選択されたプログラムを起動する。なお、複数の起動可能なプログラムにおいて設定された優先順位が同じである場合には、記録デバイス間でデフォルトの優先順位を設定し、最優先されるデバイスに格納されたコンテンツプログラムを実行する。
【０４６６】
図５８には、複数の記録デバイスに識別子を設定し、各識別子の付された記録デバイスについて順次、認証処理、コンテンツプログラム検索を実行する処理態様、すなわち起動可能コンテンツが複数ある場合の処理例（２）を示した。
【０４６７】
ステップＳ６２１では、記録再生器３００に装着された記録デバイス（ｉ）の認証処理（図２０参照）を実行するステップである。複数(ｎ個)の記録デバイスには順次１〜ｎの識別子が付与されている。
【０４６８】
ステップＳ６２２では、ステップＳ６２１での認証が成功したか否かを判定し、認証が成功した場合は、ステップＳ６２３に進み、その記録デバイス（ｉ）の記録媒体中から起動可能プログラムを検索する。認証が成功しなかった場合は、ステップＳ６２７に進み、新たコンテンツ検索可能な記録デバイスの有無を判定し、無い場合は処理を終了し、記録デバイスが存在する場合は、ステップＳ６２８に進み記録デバイス識別子ｉを更新し、ステップＳ６２１以降の認証処理ステップを繰り返す。
【０４６９】
ステップＳ６２３における処理は、記録デバイス（ｉ）に格納されたコンテンツデータから起動可能なプログラムを検出する処理である。これは、具体的には、コンテンツデータの取扱方針に含まれるコンテンツタイプがプログラムであるものを抽出する処理として実行される。
【０４７０】
ステップＳ６２４では、コンテンツタイプがプログラムであるものが抽出されたか否かを判定し、抽出された場合は、ステップＳ６２５において、抽出プログラム中最も優先順位の高いものを選択し、ステップＳ６２６において選択プログラムを実行する。
【０４７１】
ステップＳ６２４において、コンテンツタイプがプログラムであるものが抽出されなかったと判定された場合には、ステップＳ６２７に進み、新たコンテンツ検索な記録デバイスの有無を判定し、無い場合は処理を終了し、記録デバイスが存在する場合は、ステップＳ６２８に進み記録デバイス識別子ｉを更新し、ステップＳ６２１以降の認証処理ステップを繰り返す。
【０４７２】
図５９は、起動可能コンテンツが複数ある場合の処理例（３）を示す処理フローである。ステップＳ６５１は、記録再生器３００がアクセス可能な記録デバイスの認証処理を実行するステップである。アクセス可能なＤＶＤ装置、ＣＤドライブ、ハードディスク装置、メモリカード、ゲームカートリッジ等の認証処理を実行する。認証処理は、図２で示す制御部３０１の制御のもとに各記録デバイスに対して例えば先に図２０で説明した手順に従って実行される。
【０４７３】
次に、ステップＳ６５２おいて、認証に成功した記録デバイス内のメモリに格納されたコンテンツデータから起動可能なプログラムを検出する。これは、具体的には、コンテンツデータの取扱方針に含まれるコンテンツタイプがプログラムであるものを抽出する処理として実行される。
【０４７４】
次に、ステップＳ６５３において、ステップＳ６５２で抽出された起動可能なプログラムの名称等の情報を表示手段に表示する。なお、表示手段は図２では示されていないが、ＡＶ出力データとして出力されたデータが図示しない表示手段に出力される構成となっている。なお、各コンテンツデータのプログラム名等のユーザ提供情報は、コンテンツデータの識別情報中に格納されており、図２に示すメインＣＰＵ１０６の制御のもとに制御部３０１を介して認証済みの各コンテンツデータのプログラム名称等、プログラム情報を出力手段に出力する。
【０４７５】
次にステップＳ６５４では、図２に示す入力インタフェース、コントローラ、マウス、キーボード等の入力手段からのユーザによるプログラム選択入力を入力インタフェース１１０を介してメインＣＰＵ１０６が受領し、選択入力にしたがって、ステップＳ６５５においてユーザ選択プログラムを実行する。
【０４７６】
このように本発明のデータ処理装置では、コンテンツデータ中のヘッダ内の取扱情報にプログラム起動優先順位情報を格納し、記録再生器３００がこの優先順位に従ってプログラムを起動する、あるいは表示手段に起動プログラム情報を表示してユーザによって選択する構成としたので、ユーザがプログラムを検索する必要がなく、起動に要する時間およびユーザの労力を省くことが可能となる。また、起動可能なプログラムは、すべて記録デバイスの認証処理後に起動、または起動可能プログラムであることの表示がなされるので、プログラムを選択してから正当性の確認を行なう等の処理の煩雑性が解消される。
【０４７７】
（１５）コンテンツ構成および再生（伸長）処理
本発明のデータ処理装置では、上述したように記録再生器３００は、メディア５００または通信手段６００からコンテンツをダウンロード、あるいは記録デバイス４００から再生処理を行う。上記の説明は、コンテンツのダウンロード、あるいは再生処理に伴う、暗号化データの処理を中心として説明してきた。
【０４７８】
図３の記録再生器３００における制御部３０１は、コンテンツデータを提供するＤＶＤ等のデバイス５００、通信手段６００、記録デバイスからのコンテンツデータのダウンロード処理、または再生処理に伴う認証処理、暗号化、復号化処理全般を制御する。
【０４７９】
これらの処理結果として得られた再生可能なコンテンツは、例えば音声データ、画像データ等である。復号データは制御部３０１から図２に示すメインＣＰＵの制御下に置かれ、音声データ、画像データ等に応じてＡＶ出力部に出力される。しかし、コンテンツが例えば音声データであってＭＰ３圧縮がなされていれば、図２に示すＡＶ出力部のＭＰ３デコーダによって音声データの復号処理がなされて出力される。また、コンテンツデータが画像データであり、ＭＰＥＧ２圧縮画像であれば、ＡＶ処理部のＭＰＥＧ２デコーダによって伸長処理が実行されて出力されることになる。このように、コンテンツデータに含まれるデータは、圧縮（符号化）処理がなされている場合もあり、また圧縮処理の施されていないデータもあり、コンテンツに応じた処理を施して出力する。
【０４８０】
しかしながら、圧縮処理、伸長処理プログラムには、様々な種類があり、コンテンツプロバイダから圧縮データを提供されても対応する伸長処理実行プログラムが無い場合は、これを再生することができないという事態が発生する。
【０４８１】
そこで、本発明のデータ処理装置は、データコンテンツ中に、圧縮データとその復号（伸長）処理プログラムを併せて格納する構成、あるいは圧縮データと復号（伸長）処理プログラムとのリンク情報をコンテンツデータのヘッダ情報として格納する構成を開示する。
【０４８２】
図２に示したデータ処理全体図から、本構成に関する要素および関連要素を簡潔にまとめた図を図６０に示す。記録再生器３００は、例えばＤＶＤ，ＣＤ等のデバイス５００、または通信手段６００、あるいはコンテンツを格納したメモリカード等の記録デバイス４００から様々なコンテンツの提供を受ける。これらのコンテンツは、音声データ、静止画像、動画像データ、プログラムデータ等であり、また暗号化処理の施されているもの、施されていないもの、また、圧縮処理がなされているもの、なされていないもの等、様々なデータが含まれる。
【０４８３】
受領コンテンツが暗号化されている場合は、すでに上述した項目中で説明したような手法によって制御部３０１の制御、および暗号処理部３０２の暗号処理によって復号処理が実行される。復号されたデータはメインＣＰＵ１０６の制御下で、ＡＶ処理部に１０９に転送されて、ＡＶ処理部１０９のメモリ３０９０に格納された後、コンテンツ解析部３０９１においてコンテンツ構成の解析が実行される。例えばコンテンツ中にデータ伸長プログラムが格納されていれば、プログラム記憶部３０９３にプログラムを格納し、音声データ、画像データ等のデータが含まれていればこれらをデータ記憶部３０９２に記憶する。伸長処理部３０９４では、プログラム記憶部に記憶された例えばＭＰ３等の伸長処理プログラムを用いてデータ記憶部３０９２に記憶された圧縮データの伸長処理を実行して、スピーカ３００１、モニタ３００２に出力される。
【０４８４】
次に、ＡＶ処理部１０９が制御部３０１を介して受領するデータの構成および処理のいくつかの例について説明する。なお、ここでは、コンテンツの例として音声データを示し、また圧縮プログラムの例としてＭＰ３を適用したものを代表して説明するが、本構成は、音声データのみならず、画像データにも適用できるものであり、また、圧縮伸長処理プログラムについてもＭＰ３のみならず、ＭＰＥＧ２，４等各種のプログラムを適用することが可能である。
【０４８５】
図６１にコンテンツ構成例を示す。図６１はＭＰ３によって圧縮された音楽データ６１０２、ＭＰ３復号（伸長）処理プログラム６１０１を併せて１つのコンテンツとして構成した例である。これらのコンテンツは、１コンテンツとしてメディア５００、あるいは記録デバイス４００に格納され、または通信手段６００から配信される。記録再生器３００は、これらのコンテンツが先に説明した通り、暗号化されているものであれば、暗号処理部３０３によって復号処理を実行した後、ＡＶ処理部１０９に転送される。
【０４８６】
ＡＶ処理部１０９のコンテンツ解析部３０９１では、受け取ったコンテンツを解析し、音声データ伸長プログラム（ＭＰ３デコーダ）部と、圧縮音声データ部からなるコンテンツから、音声データ伸長プログラム（ＭＰ３デコーダ）部を取り出してプログラム記憶部３０９３にプログラムを記憶し、圧縮音声データをデータ記憶部３０９２に記憶する。なお、コンテンツ解析部３０９１は、コンテンツとは別に受領したコンテンツ名、コンテンツ構成情報等の情報を受領したり、あるいはコンテンツ内に含まれるデータ名等の識別データ、データ長、データ構成等を示すデータに基づいてコンテンツ解析を実行してもよい。次に、圧縮伸長処理部３０９４は、プログラム記憶部３０９３に記憶された音声データ伸長プログラム（ＭＰ３デコーダ）に従ってデータ記憶部３０９２に記憶されたＭＰ３圧縮音声データの伸長処理を実行して、ＡＶ処理部１０９は伸長した音声データをスピーカ３００１に出力する。
【０４８７】
図６２に図６１のコンテンツ構成を持つデータの再生処理の一例を示すフローを示す。ステップＳ６７１は、ＡＶ処理部１０９のメモリ３０９０に格納されたデータ名、例えば音楽データのコンテンツであれば曲名等の情報をコンテンツとは別に受領した情報、あるいはコンテンツ内のデータから取り出し、モニタ３００２に表示する。ステップＳ６７２は、ユーザの選択をスイッチ、キーボード等の各種入力手段から入力インタフェース１１０を介して受領し、ＣＰＵ１０６の制御のもとにユーザ入力データに基づく再生処理命令をＡＶ処理部１０９に出力する。ＡＶ処理部１０９は、ステップＳ６７３においてユーザ選択によるデータの抽出、伸長処理を実行する。
【０４８８】
次に図６３に、１つのコンテンツには圧縮音声データ、あるいは伸長処理プログラムのいずれか一方が含まれ、さらに各コンテンツのヘッダ情報としてコンテンツの内容を示すコンテンツ情報が含まれる構成例を示す。
【０４８９】
図６３に示すように、コンテンツがプログラム６２０２である場合は、ヘッダ情報６２０１としてプログラムであること、およびプログラム種類がＭＰ３伸長プログラムであることを示すコンテンツ識別情報が含まれる。一方、音声データ６２０４をコンテンツとして含む場合は、ヘッダ６２０３のコンテンツ情報にはＭＰ３圧縮データであるとの情報が含まれる。このヘッダ情報は、前述した例えば図４に示すコンテンツデータ構成の取扱方針（図５参照）中に含まれるデータから再生に必要な情報のみを選択してＡＶ処理部１０９へ転送するコンテンツに付加して構成することが可能である。具体的には、図５に示す「取扱方針」中の各構成データに暗号処理部３０２において必要となる取扱方針データと、ＡＶ処理部１０９における再生処理時に必要となるデータとの識別値を付加し、これら識別値が、ＡＶ処理部１０９において必要であることを示すもののみを抽出してヘッダ情報とすることができる。
【０４９０】
図６３に示す各コンテンツを受領したＡＶ処理部１０９のコンテンツ解析部３０９１は、ヘッダ情報に従って、プログラムである場合はプログラムコンテンツをプログラム記憶部３０９３に記憶し、データである場合は、データコンテンツをデータ記憶部３０９２に記憶する。その後、圧縮伸長処理部３０９４は、データ記憶部からデータを取り出して、プログラム記憶部３０９３に記憶したＭＰ３プログラムに従って伸長処理を実行して出力する。なお、プログラム記憶部３０９３にすでに同一プログラムが格納されている場合は、プログラム格納処理は省略してもよい。
【０４９１】
図６４に図６３のコンテンツ構成を持つデータの再生処理の一例を示すフローを示す。ステップＳ６７５は、ＡＶ処理部１０９のメモリ３０９０に格納されたデータ名、例えば音楽データのコンテンツであれば曲名等の情報をコンテンツとは別に受領した情報、あるいはコンテンツ内のヘッダから取り出し、モニタ３００２に表示する。ステップＳ６７６は、ユーザの選択をスイッチ、キーボード等の各種入力手段から入力インタフェース１１０を介して受領する。
【０４９２】
次に、ステップＳ６７７では、ユーザ選択に対応するデータの再生用プログラム（例えばＭＰ３）を検索する。このプログラム検索対象は、記録再生機器３００のアクセス可能な範囲を最大検索範囲とすることが好ましく、例えば図６０に示す、各メディア５００、通信手段６００、記録デバイス４００等も検索範囲とする。
【０４９３】
ＡＶ処理部１０９に渡されるコンテンツはデータ部のみであり、プログラムコンテンツは記録再生器３００内の他の記録媒体に格納される場合もあり、ＤＶＤ、ＣＤ等のメディアを介してコンテンツ提供業者から提供されることもある。従って、検索対象を記録再生機器３００のアクセス格納な範囲を検索範囲とする。検索の結果として再生プログラムが見つかると、ＣＰＵ１０６の制御のもとにユーザ入力データに基づく再生処理命令をＡＶ処理部１０９に出力する。ＡＶ処理部１０９は、ステップＳ６７９においてユーザ選択によるデータの抽出、伸長処理を実行する。また、別の実施例として、プログラムの検索をステップＳ６７５より前に行い、ステップＳ６７５においては、プログラムが検出されたデータのみを表示するようにしてもよい。
【０４９４】
次に図６５に、１つのコンテンツに圧縮音声データ６３０３、伸長処理プログラム６３０２が含まれ、さらにコンテンツのヘッダ情報６３０１としてコンテンツの再生優先順位情報が含まれる構成例を示す。これは、先の図６１のコンテンツ構成にヘッダ情報として再生優先順位情報を付加した例である。これは、前述の「（１４）コンテンツデータにおける取扱方針中の起動優先順位に基づくプログラム起動処理」と同様、ＡＶ処理部１０９が受領したコンテンツ間において設定された再生優先順位に基づいて再生順を決定するものである。
【０４９５】
図６６に図６５のコンテンツ構成を持つデータの再生処理の一例を示すフローを示す。ステップＳ６８１は、ＡＶ処理部１０９のメモリ３０９０に格納されたデータ、すなわち再生対象データのデータ情報を検索リストに設定する。検索リストはＡＶ処理部１０９内のメモリの一部領域を使用して設定する。次に、ステップＳ６８２において、ＡＶ処理部１０９のコンテンツ解析部３０９１において検索リストから優先順位の高いデータを選択し、ステップＳ６８３において、選択されたデータの再生処理を実行する。
【０４９６】
次に図６７に、１つのコンテンツにヘッダ情報とプログラムデータ６４０２、あるいはヘッダ情報６４０３と、圧縮データ６４０４のいずれかの組合せから成る例において、データコンテンツのヘッダ６４０３にのみ、再生優先順位情報が付加されている構成例を示す。
【０４９７】
図６８に図６７のコンテンツ構成を持つデータの再生処理の一例を示すフローを示す。ステップＳ６９１は、ＡＶ処理部１０９のメモリ３０９０に格納されたデータ、すなわち再生対象データのデータ情報を検索リストに設定する。検索リストはＡＶ処理部１０９内のメモリの一部領域を使用して設定する。次に、ステップＳ６９２において、ＡＶ処理部１０９のコンテンツ解析部３０９１において検索リストから優先順位の高いデータを選択する。
【０４９８】
次に、ステップＳ６９３では、選択されたデータに対応するデータ再生用プログラム（例えばＭＰ３）を検索する。このプログラム検索対象は、先の図６４のフローにおける処理と同様、記録再生機器３００のアクセス格納な範囲を最大検索範囲とすることが好ましく、例えば図６０に示す各メディア５００、通信手段６００、記録デバイス４００等も検索範囲とする。
【０４９９】
検索の結果として再生プログラムが見つかる（ステップＳ６９４でＹｅｓ）と、ステップＳ６９５において、選択されたデータを検索の結果得られたプログラムを用いて、伸長再生処理を実行する。
【０５００】
一方、検索結果としてプログラムが検出されなかった場合（ステップＳ６９４でＹｅｓ）は、ステップＳ６９６に進み、ステップＳ６９１で設定した検索リスト中に含まれる他のデータにおいて、同一のプログラムを用いた再生処理が必要なものを削除する。これは、新たにそのデータに対する再生プログラム検索を実行しても検出されないことが明らかであるからである。さらに、ステップＳ６９７において検索リストが空であるかを判定し、からでない場合は、ステップＳ６９２に戻り、さらに次の優先順位の高いデータを抽出して、プログラム検索処理を実行する。
【０５０１】
このように、本構成によれば、圧縮処理されたコンテンツは、その復号(伸長)ブログラムと共に構成されるか、あるいはコンテンツが圧縮されたデータのみ、あるいは伸長処理プログラムのみである場合は、それぞれのコンテンツにコンテンツがどのような圧縮データであるのか、あるいはどのような処理を実行するかを示すヘッダ情報を有しているので、コンテンツを受領した処理部（例えばＡＶ処理部）は、圧縮データに付属する伸長処理プログラムを用いて伸長再生処理を実行するか、あるいは伸長処理プログラムを圧縮データのヘッダ情報に基づいて検索して、検索の結果得られたプログラムにしたがって伸長再生処理を実行するので、ユーザによるデータの伸長プログラムの選択、検索等の処理が不要となりユーザ負担が軽減され、効率的なデータ再生が可能となる。さらに、ヘッダに再生優先順位情報を有した構成によれば、再生順序を自動設定する構成が可能となり、ユーザによる再生順設定の操作を省略することができる。
【０５０２】
なお、上述の実施例では、圧縮音声データコンテンツ、および音声圧縮データの伸長処理プログラムとしてのＭＰ３を例として説明したが、圧縮データを含むコンテンツ、圧縮画像データの伸長処理プログラムを有するコンテンツであっても本構成は同様に適用可能であり、同様の効果を奏するものである。
【０５０３】
（１６）セーブデータの生成および記録デバイスへの格納、再生処理
本発明のデータ処理装置は、例えば記録再生器３００において実行されるコンテンツがゲームプログラム等である場合等、ゲームプログラムを途中で中断して、所定時間後、新たに再開したい場合には、その中断時点のゲーム状態等をセーブ、すなわち記録デバイスに格納し、これを再開時に読み出してゲームを続行することが可能な構成を持つ。
【０５０４】
従来のゲーム機器、パソコン等の記録再生器におけるセーブデータ保存構成は、例えば記録再生器に内蔵、あるいは外付け可能なメモリカード、フロッピーディスク、ゲームカートリッジ、あるいはハードディスク等の記憶媒体にセーブデータを保存する構成を持つが、特に、そのセーブデータに対するセキュリティ確保構成を有しておらず、例えばゲームアプリケーションプログラムに共通の仕様でデータのセーブ処理が行われる構成となっている。
【０５０５】
従って、例えばある１つの記録再生器Ａを用いてセーブされたセーブデータが別のゲームプログラムによって使用されたり、書換えられたりする事態が発生し、従来、セーブデータのセキュリティはほとんど考慮されていなかったのが実状である。
【０５０６】
本発明のデータ処理装置は、このようなセーブデータのセキュリティ確保を実現可能とした構成を提供する。例えばあるゲームプログラムのセーブデータは、そのゲームプログラムのみが使用可能な情報に基づいて暗号化して記録デバイスに格納する。あるいは、記録再生器固有の情報に基づいて暗号化して記録デバイスに格納する。これらの手法により、セーブデータの利用を特定の機器、特定のプログラムのみに制限することができ、セーブデータのセキュリティが確保される。以下、本発明のデータ処理装置における「セーブデータの生成および記録デバイスへの格納、再生処理」について説明する。
【０５０７】
図６９に本発明のデータ処理装置におけるセーブデータ格納処理について説明するブロック図を示す。ＤＶＤ，ＣＤ等のメディア５００、あるいは通信手段６００からコンテンツが記録再生器３００に提供される。提供されるコンテンツは、先に説明したようにコンテンツ固有の鍵であるコンテンツ鍵Ｋｃｏｎによって暗号化されており、記録再生器３００は、前述した「（７）記録再生器から記録デバイスへのダウンロード処理」の欄で説明（図２２参照）した処理に従ってコンテンツ鍵を取得して、暗号化コンテンツを復号した後、記録デバイス４００に格納する。ここでは、記録再生器３００がコンテンツプログラムをメディア、通信手段から復号して再生、実行を行ない、実行の後、得られるセーブデータを外付け、あるいは内蔵のメモリカード、ハードディスク等の各種の記録デバイス４００Ａ、４００Ｂ、４００Ｃのいずれかに格納し、再生する処理、あるいはコンテンツを記録デバイス４００Ａにダウンロードした後、記録デバイス４００Ａからコンテンツを再生、実行して、そのセーブデータを外付け、あるいは内蔵のメモリカード、ハードディスク等の各種の記録デバイス４００Ａ、４００Ｂ、４００Ｃのいずれかに格納する処理記録デバイス４００に格納し、再生する処理について説明する。
【０５０８】
記録再生器３００には、先に説明したように記録再生器識別子ＩＤｄｅｖ、システムに共通な署名鍵であるシステム署名鍵Ｋｓｙｓ、個々の記録再生器に固有の署名鍵である記録再生器署名鍵Ｋｄｅｖ、さらに各種の個別鍵を生成するマスタ鍵を有する。マスタ鍵については、「（１２）マスタ鍵に基づく暗号処理鍵生成構成」において、詳しく説明した通り、例えば、配送鍵Ｋｄｉｓ、あるいは認証鍵Ｋａｋｅ等を生成する鍵である。ここでは、特にマスタ鍵の種類を限定することなく記録再生器３００の有するマスタ鍵全般を代表するものとしてＭＫｘとして示す。図６９の下段には、セーブデータの暗号鍵Ｋｓａｖの例を示した。セーブデータ暗号鍵Ｋｓａｖは、セーブデータを各種記録デバイス４００Ａ〜Ｃに格納する場合の暗号化処理、そして、各種記録デバイス４００Ａ〜Ｃから再生する際の復号処理に用いられる暗号鍵である。図７０以下を用いて、セーブデータの格納処理および再生処理の例を説明する。
【０５０９】
図７０は、コンテンツ個有鍵、システム共通鍵のいずれかを用いてセーブデータを記録デバイス４００Ａ〜Ｃいずれかに格納する処理のフロー図である。なお、各フローにおける処理は記録再生器３００が実行する処理であり、各フローでセーブデータを格納する記録デバイスは内蔵、外付け記録デバイス４００Ａ〜Ｃのいずれかであればよく、いずれかに限定さるものではない。
【０５１０】
ステップＳ７０１は、コンテンツ識別子、例えばゲームＩＤを記録再生器３００が読み出す処理である。これは、先に説明した図４、２６、２７、３２〜３５に示すコンテンツデータ中の識別情報に含まれるデータであり、セーブデータの格納処理命令を図２に示す入力インタフェース１１０を介して受領したメインＣＰＵ１０６がコンテンツ識別子の読み取りを制御部３０１に指示する。
【０５１１】
制御部３０１は、実行プログラムがＤＶＤ、ＣＤ−ＲＯＭ等、読取部３０４を介して実行されているコンテンツの場合は、読取部３０４を介してコンテンツデータ中のヘッダに含まれる識別情報を取り出し、実行プログラムが、記録デバイス４００に格納されたコンテンツである場合は、記録デバイスコントローラ３０３を介して識別情報を取り出す。なお、記録再生器３００がコンテンツプログラムを実行中で、すでに記録再生器中のＲＡＭ、その他のアクセス可能な記録媒体にコンテンツ識別子が格納済みである場合は、新たな読み取り処理を実行せずに、読み込み済みデータに含まれる識別情報を利用してもよい。
【０５１２】
次に、ステップＳ７０２は、プログラムの使用制限を行なうか否かによって処理を変更するステップである。プログラム使用制限とは、保存するセーブデータをそのプログラムのみに固有に利用可能とする制限を付するか否かを設定する制限情報であり、プログラムのみに固有に利用可能とする場合は、「プログラム使用制限あり」とし、プログラムに利用を拘束されないセーブデータとする場合を「プログラム使用制限なし」とする。これは、ユーザが任意に設定できるようにしてもよいし、コンテンツ製作者が設定して、この情報をコンテンツプログラム中に格納しておいてもよく、設定された制限情報は、図６９の記録デバイス４００Ａ〜Ｃにデータ管理ファイルとして格納される。
【０５１３】
データ管理ファイルの例を図７１に示す。データ管理ファイルは項目としてデータ番号、コンテンツ識別子、記録再生器識別子、プログラム使用制限を含むテーブルとして生成される。コンテンツ識別子は、セーブデータを格納する対象となったコンテンツプログラムの識別データである。記録再生器識別子は、セーブデータを格納した記録再生器の識別子、例えば図６９に示す［ＩＤｄｅｖ］である。プログラム使用制限は、上述したように保存するセーブデータをそのプログラムのみに固有に利用可能とす場合、「する」の設定とし、対応プログラムに制限されない利用を可能とする場合「しない」の設定となる。プログラム使用制限は、コンテンツプログラムを利用するユーザが任意に設定できるようにしてもよいし、コンテンツ製作者が設定して、この情報をコンテンツプログラム中に格納しておいてもよい。
【０５１４】
図７０に戻り、フローの説明を続ける。ステッブＳ７０２において、プログラム使用制限について「する」の設定がされている場合は、ステップＳ７０３に進む。ステップＳ７０３では、コンテンツデータからコンテンツ固有の鍵、例えば先に説明したコンテンツ鍵Ｋｃｏｎを読み出してコンテンツ固有鍵をセーブデータ暗号鍵Ｋｓａｖとするか、あるいはコンテンツ固有鍵に基づいてセーブデータ暗号鍵Ｋｓａｖを生成する。
【０５１５】
一方、ステッブＳ７０２において、プログラム使用制限について「しない」の設定がされている場合は、ステップＳ７０７に進む。ステップＳ７０７では、記録再生器３００内に格納されたシステム共通鍵、例えばシステム署名鍵Ｋｓｙｓを記録再生器３００の内部メモリ３０７から読み出して、システム署名鍵Ｋｓｙｓをセーブデータ暗号鍵Ｋｓａｖとするか、あるいはシステム署名鍵に基づいてセーブデータ暗号鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５１６】
次に、ステップＳ７０４において、ステップＳ７０３、またはステップＳ７０７で選択、または生成されたセーブデータ暗号化鍵Ｋｓａｖを用いてセーブデータの暗号化処理を実行する。この暗号化処理は、図２における暗号処理部３０２が例えば前述のＤＥＳアルゴリズムを適用して実行する。
【０５１７】
ステップＳ７０４において暗号化処理されたセーブデータは、ステップＳ７０５において記録デバイスに格納される。セーブデータを格納可能な記録デバイスが図６９に示すように複数ある場合は、ユーザが記録デバイス４００Ａ〜Ｃのいずれかをセーブデータ格納先として予め選択する。さらに、ステップＳ７０６において先に図７１を用いて説明したデータ管理ファイルに先にステップＳ７０２で設定したプログラム使用制限情報の書き込み、すなわちプログラム使用制限「する」または「しない」の書き込みを実行する。
【０５１８】
以上で、セーブデータの格納処理が終了する。ステップＳ７０２においてＹｅｓ、すなわち「プログラム使用制限する」の選択がなされ、ステップＳ７０３においてコンテンツ固有鍵に基づいて生成されたセーブデータ暗号化鍵Ｋｓａｖによって暗号化処理されたセーブデータは、コンテンツ固有鍵情報を持たないコンテンツプログラムによる復号処理が不可能となり、セーブデータは同じコンテンツ鍵情報を有するコンテンツプログラムのみが利用できることになる。ただし、ここでは、セーブデータ暗号化鍵Ｋｓａｖは記録再生器固有の情報に基いて生成されたものではないので、例えばメモリカード等の着脱可能な記録デバイスに格納されたセーブデータは異なる記録再生器においても対応するコンテンツプログラムと共に使用する限り再生可能となる。
【０５１９】
また、ステップＳ７０２においてＮｏ、すなわち「プログラム使用制限しない」の選択がなされ、ステップＳ７０７においてシステム共通鍵に基づくセーブデータ暗号化鍵Ｋｓａｖによって暗号化処理されたセーブデータは、コンテンツ識別子が異なるプログラムを用いた場合でも、また、記録再生器が異なっていた場合でも再生して利用することが可能となる。
【０５２０】
図７２は、図７０のセーブデータ格納処理によって格納されたセーブデータを再生する処理を示したフローである。
【０５２１】
ステップＳ７１１は、コンテンツ識別子、例えばゲームＩＤを記録再生器３００が読み出す処理である。これは、先に説明した図７０のセーブデータ格納処理のステップＳ７０１と同様の処理であり、コンテンツデータ中の識別情報に含まれるデータを読み出す処理である。
【０５２２】
次に、ステップＳ７１２では、図６９に示す記録デバイス４００Ａ〜Ｃから、図７１を用いて説明したデータ管理ファイルを読み出し、ステップＳ７１１において読み出したコンテンツ識別子、および対応して設定された使用プログラム制限情報を抽出する。データ管理ファイルに設定されたプログラム使用制限が「する」であった場合は、ステップＳ７１４に進み、「しない」であった場合には、ステップＳ７１７に進む。
【０５２３】
ステップＳ７１４では、コンテンツデータからコンテンツ固有の鍵、例えば先に説明したコンテンツ鍵Ｋｃｏｎを読み出してコンテンツ固有鍵をセーブデータ復号化鍵Ｋｓａｖとするか、あるいはコンテンツ固有鍵に基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。この復号化鍵生成処理は、暗号化鍵生成処理に対応する処理アルゴリズムが適用され、あるコンテンツ固有鍵に基づいて暗号化されたデータは、同一のコンテンツ固有鍵に基づいて生成された復号鍵によって復号可能なものとなる復号化鍵生成アルゴリズムが適用される。
【０５２４】
一方、ステッブＳ７１２において、データ管理ファイルの設定がプログラム使用制限について「しない」の設定であった場合は、ステップＳ７１７において、記録再生器３００内に格納されたシステム共通鍵、例えばシステム署名鍵Ｋｓｙｓを記録再生器３００の内部メモリ３０７から読み出して、システム署名鍵Ｋｓｙｓをセーブデータ復号化鍵Ｋｓａｖとするか、あるいはシステム署名鍵に基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５２５】
次に、ステップＳ７１５において、ステップＳ７１４、またはステップＳ７１７で選択、または生成されたセーブデータ復号化鍵Ｋｓａｖを用いてセーブデータの復号化処理を実行し、ステップＳ７１６において、復号したセーブデータを記録再生器３００において再生、実行する。
【０５２６】
以上で、セーブデータの再生処理が終了する。上述のようにデータ管理ファイルに「プログラム使用制限する」の設定がなされている場合は、コンテンツ固有鍵に基づいてセーブデータ復号化鍵が生成され、「プログラム使用制限しない」の設定がある場合はシステム共通鍵に基づいてセーブデータ復号化鍵が生成される。「プログラム使用制限する」の設定がされている場合、使用しているコンテンツのコンテンツ識別子が同じものでないとセーブデータの復号処理の可能な復号化鍵を得ることができないこととなり、セーブデータのセキュリティを高めることが可能となる。
【０５２７】
図７３、図７４は、コンテンツ識別子を用いてセーブデータの暗号化鍵、復号化鍵を生成するセーブデータ格納処理フロー（図７３）、セーブデータ再生処理フロー（図７４）である。
【０５２８】
図７３において、ステップＳ７２１〜Ｓ７２２は、図７０のステップＳ７０１〜Ｓ７０２と同様の処理であり、説明を省略する。
【０５２９】
図７３のセーブデータ格納処理フローは、ステップＳ７２２において「プログラム使用制限する」の設定を行なった場合、ステップＳ７２３においてコンテンツデータからコンテンツ識別子、すなわちコンテンツＩＤを読み出してコンテンツＩＤをセーブデータ暗号化鍵Ｋｓａｖとするか、あるいはコンテンツＩＤに基づいてセーブデータ暗号化鍵Ｋｓａｖを生成する。例えば、記録再生器３００の暗号処理部３０７はコンテンツデータから読み出したコンテンツＩＤに、記録再生器３００の内部メモリに格納されたマスター鍵ＭＫｘを適用して、例えばＤＥＳ（ＭＫｘ，コンテンツＩＤ）によってセーブデータ暗号化鍵Ｋｓａｖを得ることができる。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５３０】
一方、ステッブＳ７２２において、プログラム使用制限について「しない」の設定とした場合は、ステップＳ７２７において、記録再生器３００内に格納されたシステム共通鍵、例えばシステム署名鍵Ｋｓｙｓを記録再生器３００の内部メモリ３０７から読み出して、システム署名鍵Ｋｓｙｓをセーブデータ暗号化鍵Ｋｓａｖとするか、あるいはシステム署名鍵に基づいてセーブデータ暗号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５３１】
ステップＳ７２４以下の処理は、前述の図７０の処理フローにおけるステップＳ７０４以下の処理と同様であり、説明を省略する。
【０５３２】
さらに、図７４は、図７３のセーブデータ格納処理フローで記録デバイスに格納されたセーブデータを再生、実行する処理フローであり、ステップＳ７３１〜Ｓ７３３は前述の図７２の対応処理と同様であり、ステップＳ７３４のみが異なる。ステップＳ７３４においては、コンテンツデータからコンテンツ識別子、すなわちコンテンツＩＤを読み出してコンテンツＩＤをセーブデータ復号化鍵Ｋｓａｖとするか、あるいはコンテンツＩＤに基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。この復号化鍵生成処理は、暗号化鍵生成処理に対応する処理アルゴリズムが適用され、あるコンテンツ識別子に基づいて暗号化されたデータは、同一のコンテンツ識別子に基づいて生成された復号鍵によって復号可能なものとなる復号化鍵生成アルゴリズムが適用される。
【０５３３】
以下の処理、ステップＳ７３５、Ｓ７３６、Ｓ７３７は、図７２の対応処理と同様であるので説明を省略する。図７３、図７４のセーブデータ格納および再生処理に従えば、プログラム使用制限するの設定を行なった場合、コンテンツＩＤを使用してセーブデータ暗号化鍵、復号化鍵を生成する構成としたので、先のコンテンツ固有鍵を使用したセーブデータ格納、再生処理と同様、対応するコンテンツプログラムが整合する場合以外は、セーブデータを利用することができない構成となり、セーブデータセキュリティを高めた保存が可能となる。
【０５３４】
図７５、図７７は、記録再生器固有鍵を用いてセーブデータの暗号化鍵、復号化鍵を生成するセーブデータ格納処理フロー（図７５）、セーブデータ再生処理フロー（図７７）である。
【０５３５】
図７５において、ステップＳ７４１は、図７０のステップＳ７０１と同様の処理であり、説明を省略する。ステップＳ７４２は、記録再生器の制限をするかしないかを設定するステップである。記録再生器制限は、セーブデータを利用可能な記録再生器を限定する場合、すなわちセーブデータを生成し格納した記録再生器にのみ利用可能とする場合を「する」と設定し、他の記録再生器でも利用可能とする場合を「しない」の設定とするものである。ステップＳ７４２において「記録再生器制限する」の設定をすると、ステップＳ７４３に進み、「しない」の設定をするとステップＳ７４７に進む。
【０５３６】
データ管理ファイルの例を図７６に示す。データ管理ファイルは項目としてデータ番号、コンテンツ識別子、記録再生器識別子、記録再生器制限を含むテーブルとして生成される。コンテンツ識別子は、セーブデータを格納する対象となったコンテンツプログラムの識別データである。記録再生器識別子は、セーブデータを格納した記録再生器の識別子、例えば図６９に示す［ＩＤｄｅｖ］である。記録再生器制限は、セーブデータを利用可能な記録再生器を限定する場合、すなわちセーブデータを生成し格納した記録再生器にのみ利用可能とする場合を「する」と設定し、他の記録再生器でも利用可能とする場合を「しない」の設定とするものである。記録再生器制限情報は、コンテンツプログラムを利用するユーザが任意に設定できるようにしてもよいし、コンテンツ製作者が設定して、この情報をコンテンツプログラム中に格納しておいてもよい。
【０５３７】
図７５のセーブデータ格納処理フローにおいては、ステップＳ７４２において「記録再生器制限する」の設定を行なった場合、ステップＳ７４３において記録再生器３００から記録再生器固有鍵、例えば記録再生器署名鍵Ｋｄｅｖを記録再生器３００の内部メモリ３０７から読み出して記録再生器署名鍵Ｋｄｅｖをセーブデータ暗号化鍵Ｋｓａｖとするか、あるいは記録再生器署名鍵Ｋｄｅｖに基づいてセーブデータ暗号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５３８】
一方、ステッブＳ７４２において、記録再生器制限について「しない」の設定とした場合は、ステップＳ７４７において、記録再生器３００内に格納されたシステム共通鍵、例えばシステム署名鍵Ｋｓｙｓを記録再生器３００の内部メモリ３０７から読み出して、システム署名鍵Ｋｓｙｓをセーブデータ暗号化鍵Ｋｓａｖとするか、あるいはシステム署名鍵に基づいてセーブデータ暗号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５３９】
ステップＳ７４４、Ｓ７４５の処理は、前述の図７０の処理フローにおける対応処理と同様であり、説明を省略する。
【０５４０】
ステップＳ７４６では、データ管理ファイル（図７６参照）にコンテンツ識別子、記録再生器識別子、そしてステップ７４２でユーザが設定した記録再生器制限情報「する／しない」を書き込む。
【０５４１】
さらに、図７７は、図７５のセーブデータ格納処理フローで記録デバイスに格納されたセーブデータを再生、実行する処理フローであり、ステップＳ７５１は前述の図７２の対応処理と同様、コンテンツ識別子を読み出す。次に、ステップＳ７５２においては、記録再生器３００内のメモリに格納された記録再生器識別子（ＩＤｄｅｖ）を読み出す。
【０５４２】
ステップＳ７５３では、データ管理ファイル（図７６参照）からコンテンツ識別子、記録再生器識別子、設定済みの記録再生器制限情報「する／しない」の各情報を読み出す。データ管理ファイル中のコンテンツ識別子が一致するエントリにおいて、記録再生器制限情報が「する」に設定されている場合、テーブルエントリの記録再生器識別子がステップＳ７５２で読み取られた記録再生器識別子と異なる場合は処理を終了する。
【０５４３】
次に、ステップＳ７５４でデータ管理ファイルの設定が「記録再生器制限する」である場合は、ステップＳ７５５に進み、「しない」である場合は、ステップＳ７５８に進む。
【０５４４】
ステップＳ７５５においては、記録再生器３００から記録再生器固有鍵、例えば記録再生器署名鍵Ｋｄｅｖを記録再生器３００の内部メモリ３０７から読み出して記録再生器署名鍵Ｋｄｅｖをセーブデータ復号化鍵Ｋｓａｖとするか、あるいは記録再生器署名鍵Ｋｄｅｖに基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。この復号化鍵生成処理は、暗号化鍵生成処理に対応する処理アルゴリズムが適用され、ある記録再生器固有鍵に基づいて暗号化されたデータは、同一の記録再生器固有鍵に基づいて生成された復号鍵によって復号可能なものとなる復号化鍵生成アルゴリズムが適用される。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５４５】
一方ステップＳ７５８においては、記録再生器３００内に格納されたシステム共通鍵、例えばシステム署名鍵Ｋｓｙｓを記録再生器３００の内部メモリ３０７から読み出して、システム署名鍵Ｋｓｙｓをセーブデータ復号化鍵Ｋｓａｖとするか、あるいはシステム署名鍵に基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。以下のステップＳ７５６，Ｓ７５７は、前述のセーブデータ再生処理フローの対応ステップと同様の処理である。
【０５４６】
図７５、図７７に示すセーブデータ格納、再生処理フローによれば、「記録再生器制限する」の選択がなされたセーブデータは、記録再生器固有鍵によって暗号化、復号化処理が実行されるため、同一の記録再生器個有鍵を持つ記録再生器、すなわち同一の記録再生器によってのみ復号して利用することが可能となる。
【０５４７】
次に、図７８、図７９に記録再生器識別子を用いてセーブデータの暗号化、復号化鍵を生成して格納、再生する処理フローを示す。
【０５４８】
図７８は、記録再生器識別子を用いてセーブデータの暗号化を行い記録デバイスに格納する。ステップＳ７６１〜Ｓ７６３は、先の図７５と同様の処理である。ステップＳ７６４では、記録再生器から読み出した記録再生器識別子（ＩＤｄｅｖ）を用いてセーブデータの暗号化鍵Ｋｓａｖを生成する。ＩＤｄｅｖをセーブデータ暗号化鍵Ｋｓａｖとして適用するか、あるいは記録再生器３００の内部メモリに格納されたマスター鍵ＭＫｘを適用して、ＤＥＳ（ＭＫｘ，ＩＤｄｅｖ）によってセーブデータ暗号化鍵Ｋｓａｖを得る等、ＩＤｄｅｖに基づいてセーブデータ暗号化鍵ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５４９】
以下の処理ステップＳ７６５〜Ｓ７６８は、前述の図７５の対応処理と同様であり、説明を省略する。
【０５５０】
図７９は、図７８の処理によって記録デバイスに格納されたセーブデータを再生、実行する処理フローである。ステップＳ７７１〜Ｓ７７４は、前述の図７７の対応処理と同様である。
【０５５１】
ステップＳ７７５では、記録再生器から読み出した記録再生器識別子（ＩＤｄｅｖ）を用いてセーブデータの復号化鍵Ｋｓａｖを生成する。ＩＤｄｅｖをセーブデータ復号化鍵Ｋｓａｖとして適用するか、あるいは記録再生器３００の内部メモリに格納されたマスター鍵ＭＫｘを適用して、ＤＥＳ（ＭＫｘ，ＩＤｄｅｖ）によってセーブデータ復号化鍵Ｋｓａｖを得る等、ＩＤｄｅｖに基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。この復号化鍵生成処理は、暗号化鍵生成処理に対応する処理アルゴリズムが適用され、ある記録再生器識別子に基づいて暗号化されたデータは、同一の記録再生器識別子に基づいて生成された復号鍵によって復号可能なものとなる復号化鍵生成アルゴリズムが適用される。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５５２】
以下の処理ステップＳ７７６〜Ｓ７７８は前述の図７６の対応ステップの処理と同様である。
【０５５３】
この図７８、図７９に示すセーブデータ格納、再生処理フローによれば、「記録再生器制限する」の選択がなされたセーブデータは、記録再生器識別子によって暗号化、復号化処理が実行されるため、同一の記録再生器識別子を持つ記録再生器、すなわち同一の記録再生器によってのみ復号して利用することが可能となる。
【０５５４】
次に図８０〜８２を用いて、上述のプログラム使用制限、および記録再生器使用制限を併せて実行するセーブデータ格納、再生処理について説明する。
【０５５５】
図８０は、セーブデータ格納処理フローである。ステップＳ７８１において、コンテンツ識別子をコンテンツデータから読み出し、ステップＳ７８２において、プログラム使用制限判定を行ない、ステップＳ７８３において記録再生器制限判定を行なう。
【０５５６】
「プログラム使用制限あり」、かつ「記録再生器制限あり」の場合は、ステップＳ７８５において、コンテンツ固有鍵（ｅｘ．Ｋｃｏｎ）と、記録再生器固有鍵（Ｋｄｅｖ）の双方に基づいてセーブデータ暗号化鍵Ｋｓａｖが生成される。これは、例えばＫｓａｖ＝（Ｋｃｏｎ ＸＯＲ Ｋｄｅｖ）、あるいは記録再生器３００の内部メモリに格納されたマスタ鍵ＭＫｘを適用してＫｓａｖ＝ＤＥＳ（ＭＫｘ，Ｋｃｏｎ ＸＯＲ Ｋｄｅｖ）等によって得ることができる。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５５７】
「プログラム使用制限あり」、かつ「記録再生器制限なし」の場合は、ステップＳ７８６において、コンテンツ固有鍵（ｅｘ．Ｋｃｏｎ）をセーブデータ暗号化鍵Ｋｓａｖとするか、あるいはコンテンツ固有鍵（ｅｘ．Ｋｃｏｎ）に基づいてセーブデータ暗号化鍵Ｋｓａｖを生成する。
【０５５８】
「プログラム使用制限なし」、かつ「記録再生器制限あり」の場合は、ステップＳ７８７において、記録再生器固有鍵（Ｋｄｅｖ）をセーブデータ暗号化鍵Ｋｓａｖとするか、あるいは記録再生器固有鍵（Ｋｄｅｖ）に基づいてセーブデータ暗号化鍵Ｋｓａｖが生成される。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５５９】
さらに、「プログラム使用制限なし」、かつ「記録再生器制限なし」の場合は、ステップＳ７８７において、システム共通鍵、例えばシステム署名鍵Ｋｓｙｓをセーブデータ暗号化鍵Ｋｓａｖとするか、あるいはシステム署名鍵Ｋｓｙｓに基づいてセーブデータ暗号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５６０】
ステップＳ７８９では、ステップＳ７８５〜Ｓ７８８のいずれかで生成されたセーブデータ暗号化鍵Ｋｓａｖによってセーブデータが暗号化され、記録デバイスに格納される。
【０５６１】
さらに、ステップＳ７９０では、ステップＳ７８２、Ｓ７８３において設定した制限情報がデータ管理ファイルに格納される。データ管理ファイルは、例えば図８１に示す構成となり、項目としてデータ番号、コンテンツ識別子、記録再生器識別子、プログラム使用制限、記録再生器制限を含む。
【０５６２】
図８２は、図８０の処理によって記録デバイスに格納されたセーブデータを再生、実行する処理フローである。ステップＳ７９１では、実行プログラムのコンテンツ識別子、記録再生器識別子を読み出し、ステップＳ７９２において、図８１に示すデータ管理ファイルからコンテンツ識別子、記録再生器識別子、プログラム使用制限、記録再生器制限情報を読み出す。この場合、プログラム使用制限が「する」でコンテンツ識別子が不一致である場合、または記録再生器制限情報が「する」で記録再生器識別子が不一致である場合は、処理を終了する。
【０５６３】
次に、ステップＳ７９３、Ｓ７９４、Ｓ７９５では、データ管理ファイルの記録データにしたがって復号鍵生成処理をステップＳ７９６〜Ｓ７９９の４態様のいずれかに設定する。
【０５６４】
「プログラム使用制限あり」、かつ「記録再生器制限あり」の場合は、ステップＳ７９６において、コンテンツ固有鍵（ｅｘ．Ｋｃｏｎ）と、記録再生器固有鍵（Ｋｄｅｖ）の双方に基づいてセーブデータ復号化鍵Ｋｓａｖが生成される。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。「プログラム使用制限あり」、かつ「記録再生器制限なし」の場合は、ステップＳ７９７において、コンテンツ固有鍵（ｅｘ．Ｋｃｏｎ）をセーブデータ復号化鍵Ｋｓａｖとするか、あるいはコンテンツ固有鍵（ｅｘ．Ｋｃｏｎ）に基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５６５】
「プログラム使用制限なし」、かつ「記録再生器制限あり」の場合は、ステップＳ７９８において、記録再生器固有鍵（Ｋｄｅｖ）をセーブデータ復号化鍵Ｋｓａｖとするか、あるいは記録再生器固有鍵（Ｋｄｅｖ）に基づいてセーブデータ復号化鍵Ｋｓａｖが生成される。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。さらに、「プログラム使用制限なし」、かつ「記録再生器制限なし」の場合は、ステップＳ７９９において、システム共通鍵、例えばシステム署名鍵Ｋｓｙｓをセーブデータ復号化鍵Ｋｓａｖとするか、あるいはシステム署名鍵Ｋｓｙｓに基づいてセーブデータ復号化鍵Ｋｓａｖを生成する。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５６６】
これらの復号化鍵生成処理は、暗号化鍵生成処理に対応する処理アルゴリズムが適用され、同一のコンテンツ固有鍵、記録再生器固有鍵に基づいて暗号化されたデータは、同一のコンテンツ固有鍵、記録再生器固有鍵に基づいて生成された復号鍵によって復号可能なものとなる復号化鍵生成アルゴリズムが適用される。
【０５６７】
ステップＳ８００では、上述のステップＳ７９６〜Ｓ７９９のいずれかにおいて生成されたセーブデータ復号化鍵を用いて復号処理が実行され、復号セーブデータが記録再生器３００において再生、実行される。
【０５６８】
この図８０、８２において示したセーブデータ格納、再生処理フローによれば、「プログラム使用制限する」の選択がなされたセーブデータはコンテンツ固有鍵によって暗号化、復号化処理が実行されるため、同一のコンテンツ固有鍵を持つコンテンツデータを使用する場合のみ復号して利用することが可能となる。また、「記録再生器制限する」の選択がなされたセーブデータは、記録再生器識別子によって暗号化、復号化処理が実行されるため、同一の記録再生器識別子を持つ記録再生器、すなわち同一の記録再生器によってのみ復号して利用することが可能となる。従って、コンテンツ、記録再生器両者によって利用制限を設定することが可能となり、セーブデータのセキュリテイをさらに高めることが可能となる。
【０５６９】
なお、図８０、８２においては、コンテンツ固有鍵、記録再生器個有鍵を用いたセーブデータ暗号化鍵、復号化鍵の生成構成を示したが、コンテンツ個有鍵の代わりにコンテンツ識別子、また記録再生器固有鍵の代わりに記録再生器識別子を用いて、これら識別子に基づいてセーブデータ暗号化鍵、復号化鍵の生成を実行する構成としてもよい。
【０５７０】
次に、図８３〜８５を用いてユーザの入力したパスワードに基づいてセーブデータの暗号化鍵、復号化鍵を生成する構成について説明する。
【０５７１】
図８３はユーザの入力したパスワードに基づいてセーブデータの暗号化鍵を生成して記録デバイスに格納する処理フローである。
【０５７２】
ステップＳ８２１は、コンテンツデータからコンテンツ識別子を読み出す処理であり、前述の各処理と同様である。ステップＳ８２２は、ユーザによるプログラム使用制限の設定を行なうか否かを決定するステップである。本構成において設定されるデータ管理ファイルは、例えば図８４に示す構成を持つ。
【０５７３】
図８４に示すように、データは、データ番号、コンテンツ識別子、記録再生器識別子、さらにユーザによるプログラム使用制限情報が含まれる。「ユーザによるプログラム使用制限情報」はプログラムを使用するユーザを制限するかしないかを設定する項目である。
【０５７４】
図８３における処理フローにおけるステップＳ８２２において使用制限するの設定がなされると、ステップＳ８２３においてユーザパスワードの入力がなされる。この入力は、図２に示す例えばキーボード等の入力手段から入力される。
【０５７５】
入力されたパスワードは、メインＣＰＵ１０６、制御部３０１の制御のもとに暗号処理部３０２に出力され、ステップＳ８２４における処理、すなわち入力ユーザパスワードに基づくセーブデータ暗号化鍵Ｋｓａｖが生成される。セーブデータ暗号化鍵Ｋｓａｖ生成処理としては、例えばパスワード自体を暗号化鍵Ｋｓａｖとしてもよいし、あるいは記録再生器のマスタ鍵ＭＫｘを用いて、セーブデータ暗号化鍵Ｋｓａｖ＝ＤＥＳ（ＭＫｘ，パスワード）によって生成してもよい。また、パスワードを入力として一方向性関数を適用して、その出力に基づいて暗号化鍵を生成してもよい。
【０５７６】
ステップＳ８２２におけるユーザ制限がＮｏとされている場合は、ステップＳ８２８において、記録再生器３００のシステム共通鍵に基づいてセーブデータ暗号化鍵が生成される。
【０５７７】
さらに、ステップＳ８２５でステップＳ８２４、またはステップＳ８２８で生成したセーブデータ暗号化鍵Ｋｓａｖを用いてセーブデータの暗号化処理がなされ、ステップＳ８２６において暗号化処理のなされたセーブデータが記録デバイスに格納される。
【０５７８】
さらに、ステップＳ８２７において、図８４のデータ管理ファイルにステップＳ８２２で設定したユーザによるフログラム使用制限情報が、コンテンツ識別子と記録再生器識別子に対応付けられて書き込まれる。
【０５７９】
図８５は、図８３の処理によって格納されたセーブデータの再生処理フローを示した図である。ステップＳ８３１において、コンテンツデータからコンテンツ識別子を読み出し、ステップＳ８３２において図８４に示したデータ管理ファイルからコンテンツ識別子、ユーザによるプログラム使用制限情報を読み出す。
【０５８０】
ステップＳ８３３において、データ管理ファイル中のデータに基づく判定を実行し、「ユーザによるプログラム使用制限する」が設定されている場合は、ステップＳ８３４において、パスワード入力を求め、ステップＳ８３５において、入力パスワードに基づく復号化鍵を生成する。この復号化鍵生成処理は、暗号化鍵生成処理に対応する処理アルゴリズムが適用され、あるパスワードに基づいて暗号化されたデータは、同一のパスワードに基づいて生成された復号鍵によって復号可能なものとなる復号化鍵生成アルゴリズムに設定される。
【０５８１】
ステップＳ８３３の判定がユーザによるプログラム使用制限なしの場合は、ステップＳ８３７において記録再生器３００の内部メモリに格納されたシステム共通鍵、例えばシステム署名鍵Ｋｓｙｓを用いてセーブデータ復号鍵Ｋｓａｖが生成される。または、別途、記録再生器３００の内部メモリ３０７内に保存しておいた、他の鍵とは別の暗号鍵をセーブデータ暗号鍵Ｋｓａｖとして使用してもよい。
【０５８２】
ステップＳ８３６では、ステップＳ８３５、ステップＳ８３７のいずれかにおいて生成された復号化鍵Ｋｓａｖを用いて記録デバイスに格納されたセーブデータの復号が実行され、ステップＳ８３６において記録再生器においてセーブデータの再生、実行がなされる。
【０５８３】
図８３、図８５において示したセーブデータ格納、再生処理フローによれば、「ユーザによるプログラム使用制限する」の選択がなされたセーブデータはユーザ入力パスワードに基づく鍵によって暗号化、復号化処理が実行されるため、同一のパスワードを入力した場合のみ復号して利用することが可能とり、セーブデータのセキュリテイを高めることが可能となる。
【０５８４】
以上、いくつかのセーブデータの格納処理、再生処理態様について説明してきたが、上述した処理を融合した処理、例えばパスワードと、記録再生器識別子、コンテンツ識別子等を任意に組み合わせて使用してセーブデータ暗号化鍵、復号化鍵を生成する態様も可能である。
【０５８５】
（１７）不正機器の排除（リボケーション）構成
すでに説明してきたように、本発明のデータ処理装置においては、メディア５００（図３参照）、通信手段６００から提供される様々なコンテンツデータを記録再生器３００において、認証、暗号化処理等を実行し、記録デバイスに格納する構成によって提供コンテンツのセキュリティを高めるとともに、また、正当な利用者のみが利用可能とする構成を持つ。
【０５８６】
上述の説明から理解されるように、入力コンテンツは、記録再生器３００の暗号処理部３０２に構成される内部メモリ３０７に格納された様々な署名鍵、マスター鍵、チェック値生成鍵（図１８参照）を用いて、認証処理、暗号化処理、復号化処理がなされる。この鍵情報を格納する内部メモリ３０７は、先に説明したように、基本的に外部からアクセスしにくい構造を持った半導体チップで構成され、多層構造を有し、その内部のメモリはアルミニュウム層等のダミー層に挟まれるか、最下層に構成され、また、動作する電圧または／かつ周波数の幅が狭い等、外部から不正にデータの読み出しが難しい特性とした構成とされるのが望ましいが、万が一内部メモリの不正な読み取りが実行され、これらの鍵データ等が流出し、正規なライセンスのされていない記録再生器にコピーされた場合、コピーされた鍵情報によって不正なコンテンツ利用がなされる可能性がある。
【０５８７】
ここでは、これらの不正コピーによる鍵の複製によるコンテンツの不正利用を防止する構成について説明する。
【０５８８】
図８６に、本構成「（１７）不正機器の排除構成」を説明するブロック図を示す。記録再生器３００は、前述の図２，３に示す記録再生器と同様であり、内部メモリを有し、先に説明した（図１８）各種の鍵データ、さらに、記録再生器識別子を有している。なお、ここでは、第三者によって複製されている記録再生器識別子、鍵データ等は図３に示す内部メモリ３０７に格納されるとは限らず、図８６に示す記録再生器３００の鍵データ等は、暗号処理部３０２（図２，３参照）によってアクセス可能なメモリ部にまとめて、あるいは分散して格納されている構成であるとする。
【０５８９】
不正機器の排除構成を実現するため、コンテンツデータのヘッダ部の不正な記録再生器識別子リストを記憶した構成とした。図８６に示すように、コンテンツデータには、不正な記録再生器識別子（ＩＤｄｅｖ）リストとしてのリボケーション(Revocation)リストを保有している。さらに、リボケーションリストの改竄チェック用のリストチェック値ＩＣＶｒｅｖを設けている。不正な記録再生器識別子（ＩＤｄｅｖ）リストは、コンテンツ提供者、または管理者が、例えば不正コピーの流通状態等から判明した不正な記録再生器の識別子ＩＤｄｅｖをリスト化したものである。このリボケーションリストは例えば配送鍵Ｋｄｉｓによって暗号化されて格納してもよい。記録再生器による復号処理については、例えば先の図２２のコンテンツダウンロード処理の態様と同様である。
【０５９０】
なお、ここでは、理解を容易にするため、リボケーションリストを単独のデータとして図８６のコンテンツデータ中に示してあるが、例えば先に説明したコンテンツデータのヘッダ部の構成要素である取扱方針（例えば図３２〜３５参照）中にリボケーションリストを含ませてもよい。この場合は、先に説明したチェック値ＩＣＶａによってリボケーションリストを含む取扱方針データの改竄チェックがなされる。リボケーションリストが取扱方針中に含まれる場合は、チェック値Ａ：ＩＣＶａのチェックによって代替され、記録再生器内のチェック値Ａ生成鍵Ｋｉｃｖａが利用され、チェック値生成鍵Ｋｉｃｖ−ｒｅｖを格納する必要はない。
【０５９１】
リボケーションリストを単独のデータとしてコンテンツデータ中に含ませる場合は、リボケーションリストの改竄チェック用のリストチェック値ＩＣＶｒｅｖによるリボケーションリストのチェックを実行するとともに、リストチェック値ＩＣＶｒｅｖとコンテンツデータ中の他の部分チェック値とから中間チェック値を生成して中間チェック値の検証処理を行なう構成とする。
【０５９２】
リボケーションリストの改竄チェック用のリストチェック値ＩＣＶｒｅｖによるリボケーションリストのチェック手法は、前述の図２３、図２４等で説明したＩＣＶａ、ＩＣＶｂ等のチェック値生成処理と同様の方法で実行可能である。すなわち、記録再生器暗号処理部３０２の内部メモリ３０７に保存したチェック値生成鍵Ｋｉｃｖ−ｒｅｖを鍵とし、コンテンツデータ中に含まれるリボケーションリストをメッセージとして図２３、図２４等で説明したＩＣＶ計算方法に従って計算される。計算したチェック値ＩＣＶ−ｒｅｖ’とヘッダ（Header）内に格納されたチェック値：ＩＣＶ−ｒｅｖを比較し、一致していた場合には、改竄が無いと判定する。
【０５９３】
リストチェック値ＩＣＶｒｅｖを含む中間チェック値は、例えば、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されている総チェック値生成鍵Ｋｉｃｖｔを鍵とし、検証したHeader内のチェック値Ａ、チェック値Ｂ、リストチェック値ＩＣＶｒｅｖ、さらにフォーマットに応じてコンテンツチェック値を加えたメッセージ列に図７他で説明したＩＣＶ計算方法を適用して生成する。
【０５９４】
これらのリボケーションリスト、リストチェック値は、ＤＶＤ，ＣＤ等のメデイア５００、通信手段６００を介して、あるいはメモリカード等の記録デバイス４００を介して記録再生器３００に提供される。ここで記録再生器３００は、正当な鍵データを保有する記録再生器である場合と、不正に複製された識別子ＩＤを有する場合とがある。
【０５９５】
このような構成における不正な記録再生器の排除処理の処理フローを図８７および図８８に示す。図８７は、ＤＶＤ，ＣＤ等のメディア５００、あるいは通信手段６００からコンテンツが提供される場合の不正記録再生器排除（リボケーション）処理フローであり、図８８は、メモリカード等の記録デバイス４００からコンテンツが提供される場合の不正記録再生器排除（リボケーション）処理フローである。
【０５９６】
まず、図８７の処理フローについて説明する。ステップ９０１は、メディアを装着して、コンテンツの提供、すなわち再生処理あるいはダウンロードの要求を行なうステップである。この図８７に示す処理は、例えば記録再生器にＤＶＤ等のメディアを装着してダウンロード処理等を実行する前のステップとして実行される。ダウンロード処理については、先に図２２を用いて説明している通りであり、図２２の処理フローの実行の前ステップとして、あるいは図２２の処理フロー中に挿入される処理としてこの図８７の処理が実行される。
【０５９７】
記録再生器３００がネットワーク等の通信手段を介してコンテンツ提供を受ける場合は、ステップＳ９１１においてコンテンツ配信サービス側との通信セッションを確立し、その後、ステップＳ９０２へ進む。
【０５９８】
ステップＳ９０２では、コンテンツデータのヘッダ部からリボケーションリスト(図８６参照)を取得する。このリスト取得処理は、コンテンツがメディア内にある場合は、図３に示す制御部３０１が読取部３０４を介してメデイアから読み出し、コンテンツが通信手段からである場合は、図３に示す制御部３０１が通信部３０５を介してコンテンツ配信側から受信する。
【０５９９】
次にステップＳ９０３において、制御部３０１は、暗号処理部３０２にメディア５００または通信手段６００から取得したリボケーションリストを暗号処理部３０２に渡し、チェック値生成処理を実行させる。記録再生器３００は、内部にリボケーションチェック値生成鍵Ｋｉｃｖ−ｒｅｖを有し、受領したリボケーションリストをメッセージとしてリボケーションチェック値生成鍵Ｋｉｃｖ−ｒｅｖを適用して、例えば図２３、図２４等で説明したＩＣＶ計算方法に従ってチェック値ＩＣＶ−ｒｅｖ’を計算し、計算結果とコンテンツデータのヘッダ（Header）内に格納されたチェック値：ＩＣＶ−ｒｅｖを比較し、一致していた場合には改竄が無い（ステップＳ９０４でＹｅｓ）と判定する。一致しない場合は、改竄されていると判定され、ステップＳ９０９に進み処理エラーとして処理を終了する。
【０６００】
次に、ステップＳ９０５において、記録再生器暗号処理部３０２の制御部３０６は、記録再生器暗号処理部３０２の暗号／復号化部３０８に総チェック値ＩＣＶｔ’の計算をさせる。総チェック値ＩＣＶｔ’は、図２５に示すように、記録再生器暗号処理部３０２の内部メモリ３０７に保存されているシステム署名鍵Ｋｓｙｓを鍵とし、中間チェック値をＤＥＳで暗号化して生成する。なお、各部分チェック値、例えばＩＣＶａ、ＩＣＶｂ等の検証処理は、この図８７に示す処理フロー中では省略してあるが、先に説明した図３９〜図４５の処理フローと同様の各データフォーマットに応じた部分チェック値の検証が行なわれる。
【０６０１】
次に、ステップＳ９０６において、生成した総チェック値ＩＣＶｔ’とヘッダ（Header）内のＩＣＶｔを比較し、一致していた場合（ステップＳ９０６でＹｅｓ）には、ステップＳ９０７へ進む。一致しない場合は、改竄されていると判定され、ステップＳ９０９に進み処理エラーとして処理を終了する。
【０６０２】
先に説明したように、総チェック値ＩＣＶｔは、ＩＣＶａ、ＩＣＶｂ、さらに、データフォーマットに応じて各コンテンツブロックのチェック値等、コンテンツデータに含まれる部分チェック値全体をチェックするものであるが、ここでは、これらの部分チェック値にさらに、リボケーションリストの改竄チェック用のリストチェック値ＩＣＶｒｅｖを部分チェック値として加えて、これら全ての改竄を検証する。上述の処理によって生成された総チェック値がヘッダ（Header）内に格納されたチェック値：ＩＣＶｔと一致した場合には、ＩＣＶａ、ＩＣＶｂ、各コンテンツブロックのチェック値、およびリストチェック値ＩＣＶｒｅｖ全ての改竄はないと判断される。
【０６０３】
さらにステップＳ９０７では、改竄無しと判定されたリボケーションリストと、自己の記録再生器３００に格納された記録再生器識別子（ＩＤｄｅｖ）との比較がなされる。
【０６０４】
コンテンツデータから読み出された不正な記録再生器識別子ＩＤｄｅｖのリストに自己の記録再生器の識別子ＩＤｄｅｖが含まれている場合は、その記録再生器３００は、不正に複製された鍵データを有していると判定され、ステップＳ９０９に進み、以後の手続きは中止される。例えば図２２のコンテンツダウンロード処理の手続きの実行を不可能とする。
【０６０５】
ステップＳ９０７において、不正な記録再生器識別子ＩＤｄｅｖのリストに自己の記録再生器の識別子ＩＤｄｅｖが含まれていないと判定された場合には、その記録再生器３００は、正当な鍵データを有していると判定され、ステップＳ９０８に進み、以後の手続き、例えば、プログラム実行処理、あるいは図２２等のコンテンツダウンロード処理等が実行可能となる。
【０６０６】
図８８は、メモリカード等の記録デバイス４００に格納したコンテンツデータを再生する場合の処理を示す。先に説明したように、メモリカード等の記録デバイス４００と記録再生器３００は、図２０で説明した相互認証処理（ステップＳ９２１）が実行される。ステップＳ９２２おいて、相互認証ＯＫである場合にのみ、ステップＳ９２３以降の処理に進み、相互認証に失敗した場合は、ステップＳ９３０のエラーとなり、以降の処理は実行されない。
【０６０７】
ステップＳ９２３では、コンテンツデータのヘッダ部からリボケーションリスト(図８６参照)を取得する。以降のステップＳ９２４〜Ｓ９３０の処理は、先の図８７における対応処理と同様の処理である。すなわち、リストチェック値によるリストの検証（Ｓ９２４，Ｓ９２５）、総チェック値による検証（Ｓ９２６，Ｓ９２７）、リストのエントリと自己の記録再生器識別子ＩＤｄｅｖとの比較（Ｓ９２８）を実行し、コンテンツデータから読み出された不正な記録再生器識別子ＩＤｄｅｖのリストに自己の記録再生器の識別子ＩＤｄｅｖが含まれている場合は、その記録再生器３００は、不正に複製された鍵データを有していると判定され、ステップＳ９３０に進み、以後の手続きは中止される。例えば図２８に示すコンテンツの再生処理を実行不可能とする。一方、不正な記録再生器識別子ＩＤｄｅｖのリストに自己の記録再生器の識別子ＩＤｄｅｖが含まれていないと判定された場合には、その記録再生器３００は、正当な鍵データを有していると判定され、ステップＳ９２９に進み、以後の手続きが実行可能となる。
【０６０８】
このように、本発明のデータ処理装置においては、コンテンツ提供者、または管理者が提供するコンテンツに併せて不正な記録再生器を識別するデータ、すなわち不正な記録再生器識別子ＩＤｄｅｖをリスト化したリボケーションリストをコンテンツデータのヘッダ部の構成データとして含ませて記録再生器利用者に提供し、記録再生器利用者は、記録再生器によるコンテンツの利用に先立って、自己の記録再生器のメモリに格納された記録再生器識別子ＩＤｄｅｖと、リストの識別子との照合を実行して一致するデータが存在した場合には、以後の処理を実行させない構成としたので鍵データを複製してメモリに格納した不正な記録再生器によるコンテンツ利用を排除することが可能となる。
【０６０９】
（１８）セキュアチップ構成および製造方法
先に説明したように、記録再生器暗号処理部３０２の内部メモリ３０７、あるいは記録デバイス４００の内部メモリ４０５は、暗号鍵などの重要な情報を保持しているため、外部から不正に読み出しにくい構造にしておく必要がある。従って、記録再生器暗号処理部３０２、記録デバイス暗号処理部４０１は、例えば外部からアクセスしにくい構造を持った半導体チップで構成され、多層構造を有し、その内部のメモリはアルミニュウム層等のダミー層に挟まれるか、最下層に構成され、また、動作する電圧または／かつ周波数の幅が狭い等、外部から不正にデータの読み出しが難しい特性を有する耐タンパメモリとして構成される。
【０６１０】
しかしながら、上述の説明で理解されるように、例えば記録再生器暗号処理部３０２の内部メモリ３０７には記録再生器署名鍵Ｋｄｅｖ等の記録再生器毎に異なるデータを書き込むことが必要となる。また、チップ内の不揮発性の記憶領域、例えばフラッシュメモリ、ＦｅＲＡＭ等にチップ毎の個別情報、例えば識別情報（ＩＤ）や暗号鍵情報を書き込んだ後、例えば製品出荷後におけるデータの再書き込み、読み出しを困難とすることが必要となる。
【０６１１】
従来の書き込みデータの読み出し、再書き込み処理を困難とするための手法には、例えばデータ書き込みのコマンドプロトコルを秘密にする。あるいは、チップ上のデータ書き込みコマンドを受け付ける信号線と、製品化した後に利用される通信用の信号線を分離して構成し、基板上のチップに直接信号を送らない限りデータ書き込みコマンドが有効とならないようにする等の手法がある。
【０６１２】
しかしながら、このような従来手法を採用しても、記憶素子の専門知識を有するものにとっては、回路を駆動させる設備と技術があれば、チップのデータ書き込み領域に対する信号出力が可能であり、また、たとえデータ書き込みのコマンドプロトコルが秘密であったとしても、プロトコルの解析可能性は常に存在する。
【０６１３】
このような、秘密データの改変可能性を保持した暗号処理データの格納素子を流通させることは、暗号処理システム全体を脅かす結果となる。また、データの読み出しを防止するために、データ読み出しコマンド自体を実装しない構成とすることも可能であるが、その場合、正規のデータ書き込みを実行した場合であっても、メモリに対するデータ書き込みが実際に行われたか否かを確認したり、書き込まれたデータが正確に書き込まれているか否かを判定することが不可能となり、不良なデータ書き込みの行われたチップが供給される可能性が発生する。
【０６１４】
これらの従来技術に鑑み、ここでは、、例えばフラッシュメモリ、ＦｅＲＡＭ等の不揮発性メモリに正確なデータ書き込みを可能とするとともに、データの読み出しを困難にするセキュアチップ構成およびセキュアチップ製造方法を提供する。
【０６１５】
図８９に、例えば、前述の記録再生器暗号処理部３０２または記録デバイス４００の暗号処理部４０１に適用可能なセキュリティチップ構成を示す。図８９（Ａ）はチップの製造過程、すなわちデータの書き込み過程におけるセキュリティチップ構成を示し、図８９（Ｂ）は、データを書き込んだセキュリティチップを搭載した製品の構成例、例えば記録再生器３００、記録デバイス４００の例を示す。
【０６１６】
製造過程にあるセキュリティチップは、処理部８００１にモード指定用信号線８００３、および各種コマンド信号線８００４が接続され、処理部８００１は、モード指定用信号線８００３で設定されたモード、例えばデータ書き込みモードまたはデータ読み出しモードに応じて不揮発性メモリである記憶部８００２へのデータ書き込み処理、または記憶部８００２からのデータ読み出し処理を実行する。
【０６１７】
一方、図８９（Ｂ）のセキュリティチップ搭載製品においては、セキュリティチップと外部接続インタフェース、周辺機器、他の素子等とが汎用信号線で接続されるが、モード信号線８００３は、非接続状態とされる。具体的な処理は、例えばモード信号線８００３をグランド接続する、Ｖｃｃに釣り上げる、信号線をカットする、あるいは絶縁体樹脂で封印する等である。このような処理により、製品出荷後は、セキュリティチップのモード信号線に対するアクセスが困難になり、外部からチップのデータを読み出したり書き込みを行なったりすることの困難性を高めることができる。
【０６１８】
さらに、本構成のセキュリティチップ８０００は、データの記憶部８００２に対する書き込み処理、および記憶部８００２に書き込まれたデータの読み出し処理を困難にする構成を持ち、たとえ第三者がモード信号線８００３のアクセスに成功した場合であっても不正なデータ書き込み、読み出しを防止可能である。図９０に本構成を有するセキュリティチップにおけるデータ書き込みまたは読み出し処理フローを示す。
【０６１９】
ステップＳ９５１は、モード信号線８００３をデータ書き込みモードまたはデータ読み出しモードに設定するステップである。
【０６２０】
ステップＳ９５２は、チップから認証用情報を取り出すステップである。本構成のセキュリティチップには、例えばワイヤ（Ｗｉｒｅ）、マスクＲＯＭ構成により、予めパスワード、暗号技術における認証処理用の鍵情報等、認証処理に必要な情報が格納される。ステップＳ９５２は、この認証情報を読み出して認証処理を実行する。例えば正規なデータ書き込み治具、データ読み出し装置を汎用信号線に接続して認証処理を実行した場合には、認証ＯＫ（ステップＳ９５３においてＹｅｓ）の結果が得られるが、不正なデータ書き込み治具、データ読み出し装置を汎用信号線に接続して認証処理を実行した場合には、認証に失敗（ステップＳ９５３においてＮｏ）し、その時点で処理が中止される。認証処理は、例えば先に説明した図１３の相互認証処理手続きに従って実行可能である。図８９に示す処理部８００１は、これらの認証処理を実行可能な構成を有する。これは、例えば先に説明した図２９に示す記録デバイス４００の暗号処理部４０１の制御部４０３に組み込まれたコマンドレジスタと同様の構成により実現可能である。例えば図８９のチップの処理部は、図２９に示す記録デバイス４００の暗号処理部４０１の制御部４０３に組み込まれたコマンドレジスタと同様の構成を持ち、各種コマンド信号線８００４に接続された機器から所定のコマンドＮｏが入力されると、対応する処理を実行し、認証処理シーケンスを実行することが可能となる。
【０６２１】
処理部８００１は認証処理において認証がなされた場合にのみ、データの書き込みコマンド、またはデータの読み出しコマンドを受け付けてデータの書き込み処理（ステップＳ９５５）、またはデータの読み出し処理（ステップＳ９５６）を実行する。
【０６２２】
このように本構成のセキュリティチップにおいては、データの書き込み時、読み出し時に認証処理を実行する構成としたので、正当な権利を持たない第三者によるセキュリティチップの記憶部からデータの読み出し、または記憶部へのデータ書き込みを防止することができる。
【０６２３】
次に、さらに、セキュリティの高い素子構成とした実施例を図９１に示す。この例では、セキュリティチップの記憶部８２００が２つの領域に分離され、一方はデータの読み書きが可能な読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１であり、他方はデータの書き込みのみが可能な書き込み専用領域（ＷＯ：ＷｒｉｔｅＯｎｌｙ領域）８２０２である。
【０６２４】
この構成において、書き込み専用領域（ＷＯ：ＷｒｉｔｅＯｎｌｙ領域）８２０２には、暗号鍵データ、識別子データ等のセキュリテイ要請の高いデータを書き込み、一方セキュリティ度のさほど高くない、例えばチェック用のデータ等を読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１に書き込む。
【０６２５】
処理部８００１は、読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１からのデータ読み出し処理は、前述の図９０で説明した認証処理を伴うデータ読み出し処理を実行する。しかし、データ書き込み処理は、図９２のフローに従って実行する。
【０６２６】
図９２のステップＳ９６１は、モード信号線８００３を書き込みモードに設定するステップであり、ステップ９６２では、先の図９０で説明したと同様の認証処理を実行する。認証処理で認証がなされると、ステップＳ９６３に進み、コマンド信号線８００４を介して、書き込み専用（ＷＯ）領域８２０２にセキュリテイの高い鍵データ等の情報の書き込み、読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１にセキュリティ度のさほど高くない、例えばチェック用データ書き込むコマンドを処理部８００１に対して出力する。
【０６２７】
ステップＳ９６４ではコマンドを受領した処理部８００１が、コマンドに応じたデータ書き込み処理をそれぞれ書き込み専用（ＷＯ）領域８２０２、読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１に対して実行する。
【０６２８】
また、書き込み専用（ＷＯ）領域８２０２に書き込まれたデータの検証処理フローを図９３に示す。
【０６２９】
図９３のステツプＳ９７１は、処理部８００１において、書き込み専用（ＷＯ）領域８２０２に書き込まれたデータに基づく暗号処理を実行させる。これらの実行構成は、先の認証処理実行構成と同様、コマンドレジスタに格納された暗号処理シーケンスを順次実行する構成によって実現される。また、処理部８００１において実行される暗号処理アルゴリズムは特に限定されるものではなく、例えば先に説明したＤＥＳアルゴリズムを実行する構成とすることができる。
【０６３０】
次に、ステップＳ９７２で、セキュリティチップに接続された検証装置が処理部８００１から暗号処理結果を受信する。次に、ステップＳ９７３において、先に記憶部に書き込み処理を行なった正規な書き込みデータに対して処理部８００１において実行されたアルゴリズムと同様の暗号化処理を適用して得た結果と、処理部８００１からの暗号化結果とを比較する。
【０６３１】
比較した結果が同一であれば、書き込み専用（ＷＯ）領域８２０２に書き込まれたデータは正しいことが検証される。
【０６３２】
この構成では、認証処理が破られて読み出しコマンドが万が一実行可能となっても、データの読み出し可能領域は、読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１に限定され、書き込み専用（ＷＯ）領域８２０２に書き込まれたデータの読み出しは、不可能であり、さらにセキュリティの高い構成となる。また、全く読み出しを不可能としたチップと異なり、読み出し書き込み併用領域(ＲＷ：ＲｅａｄＷｒｉｔｅ領域)８２０１が構成されているのでメモリアクセスの正否チェックが可能である。
【０６３３】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。また、上記した実施例ではコンテンツの記録、再生を可能な記録再生器を例にして説明してきたが、データ記録のみ、データ再生のみ可能な装置においても本発明の構成は適用可能なものであり、本発明はパーソナルコンピュータ、ゲーム機器、その他の各種データ処理装置一般において実施可能なものである。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０６３４】
【発明の効果】
上述したように、本発明のデータ記憶素子製造方法およびデータ記憶素子、並びにデータ処理装置によれば、データの書き込み時、読み出し時に認証処理を実行する構成としたので、正当な権利を持たない第三者によるセキュリティチップの記憶部からのデータの読み出し、または記憶部へのデータ書き込みを防止することができる。
【０６３５】
さらに、本発明のデータ記憶素子製造方法およびデータ記憶素子、並びにデータ処理装置によれば、書き込みデータに基づく暗号処理を実行して書き込みデータの検証が可能となり、データ書き込みエラー等の発生を製造時点で発見することが可能となる。また、書き込み専用領域と読み取り書き込み併用領域を設けた構成によれば、セキュリテイの高い情報を書き込み専用領域に書き込むことによりデータのセキュリティをより高めることが可能となる。
【図面の簡単な説明】
【図１】従来のデータ処理システムの構成を示す図である。
【図２】本発明の適用されるデータ処理装置の構成を示す図である。
【図３】本発明の適用されるデータ処理装置の構成を示す図である。
【図４】メディア上、通信路上におけるコンテンツデータのデータフォーマットを示す図である。
【図５】コンテンツデータ中のヘッダに含まれる取扱方針を示す図である。
【図６】コンテンツデータ中のヘッダに含まれるブロック情報を示す図である。
【図７】ＤＥＳを用いた電子署名生成方法を示す図である。
【図８】トリプルＤＥＳを用いた電子署名生成方法を示す図である。
【図９】トリプルＤＥＳの態様を説明する図である。
【図１０】一部にトリプルＤＥＳを用いた電子署名生成方法を示す図である。
【図１１】電子署名生成における処理フローを示す図である。
【図１２】電子署名検証における処理フローを示す図である。
【図１３】対称鍵暗号技術を用いた相互認証処理の処理シーケンスを説明する図である。
【図１４】公開鍵証明書を説明する図である。
【図１５】非対称鍵暗号技術を用いた相互認証処理の処理シーケンスを説明する図である。
【図１６】楕円曲線暗号を用いた暗号化処理の処理フローを示す図である。
【図１７】楕円曲線暗号を用いた復号化処理の処理フローを示す図である。
【図１８】記録再生器上のデータ保持状況を示す図である。
【図１９】記録デバイス上のデータ保持状況を示す図である。
【図２０】記録再生器と記録デバイスとの相互認証処理フローを示す図である。
【図２１】記録再生器のマスタ鍵と記録デバイスの対応鍵ブロックとの関係を示す図である。
【図２２】コンテンツのダウンロード処理における処理フローを示す図である。
【図２３】チェック値Ａ：ＩＣＶａの生成方法を説明する図である。
【図２４】チェック値Ｂ：ＩＣＶｂの生成方法を説明する図である。
【図２５】総チェック値、記録再生器固有チェック値の生成方法を説明する図である。
【図２６】記録デバイスに保存されたコンテンツデータのフォーマット（利用制限情報＝０）を示す図である。
【図２７】記録デバイスに保存されたコンテンツデータのフォーマット（利用制限情報＝１）を示す図である。
【図２８】コンテンツの再生処理における処理フローを示す図である。
【図２９】記録デバイスにおけるコマンド実行方法について説明する図である。
【図３０】記録デバイスにおけるコンテンツ格納処理におけるコマンド実行方法について説明する図である。
【図３１】記録デバイスにおけるコンテンツ再生処理におけるコマンド実行方法について説明する図である。
【図３２】コンテンツデータフォーマットのフォーマット・タイプ０の構成を説明する図である。
【図３３】コンテンツデータフォーマットのフォーマット・タイプ１の構成を説明する図である。
【図３４】コンテンツデータフォーマットのフォーマット・タイプ２の構成を説明する図である。
【図３５】コンテンツデータフォーマットのフォーマット・タイプ３の構成を説明する図である。
【図３６】フォーマット・タイプ０におけるコンテンツチェック値ＩＣＶｉの生成処理方法を説明する図である。
【図３７】フォーマット・タイプ１におけるコンテンツチェック値ＩＣＶｉの生成処理方法を説明する図である。
【図３８】フォーマット・タイプ２，３における総チェック値、記録再生器固有チェック値の生成処理方法を説明する図である。
【図３９】フォーマット・タイプ０，１におけるコンテンツダウンロード処理の処理フローを示す図である。
【図４０】フォーマット・タイプ２におけるコンテンツダウンロード処理の処理フローを示す図である。
【図４１】フォーマット・タイプ３におけるコンテンツダウンロード処理の処理フローを示す図である。
【図４２】フォーマット・タイプ０におけるコンテンツ再生処理の処理フローを示す図である。
【図４３】フォーマット・タイプ１におけるコンテンツ再生処理の処理フローを示す図である。
【図４４】フォーマット・タイプ２におけるコンテンツ再生処理の処理フローを示す図である。
【図４５】フォーマット・タイプ３におけるコンテンツ再生処理の処理フローを示す図である。
【図４６】コンテンツ生成者と、コンテンツ検証者におけるチェック値の生成、検証方法を説明する図(その１)である。
【図４７】コンテンツ生成者と、コンテンツ検証者におけるチェック値の生成、検証方法を説明する図（その２）である。
【図４８】コンテンツ生成者と、コンテンツ検証者におけるチェック値の生成、検証方法を説明する図（その３）である。
【図４９】マスタ鍵を用いて各種の鍵を個別に生成する方法について説明する図である。
【図５０】マスタ鍵を用いて各種の鍵を個別に生成する方法について、コンテンツプロバイダと、ユーザにおける処理例を示す図（例１）である。
【図５１】マスタ鍵を用いて各種の鍵を個別に生成する方法について、コンテンツプロバイダと、ユーザにおける処理例を示す図（例２）である。
【図５２】マスタ鍵の使い分けにより、利用制限を実行する構成について説明する図である。
【図５３】マスタ鍵を用いて各種の鍵を個別に生成する方法について、コンテンツプロバイダと、ユーザにおける処理例を示す図（例３）である。
【図５４】マスタ鍵を用いて各種の鍵を個別に生成する方法について、コンテンツプロバイダと、ユーザにおける処理例を示す図（例４）である。
【図５５】マスタ鍵を用いて各種の鍵を個別に生成する方法について、コンテンツプロバイダと、ユーザにおける処理例を示す図（例５）である。
【図５６】トリプルＤＥＳを適用した暗号鍵をシングルＤＥＳアルゴリズムを用いて格納する処理フローを示す図である。
【図５７】優先順位に基づくコンテンツ再生処理フロー（例１）を示す図である。
【図５８】優先順位に基づくコンテンツ再生処理フロー（例２）を示す図である。
【図５９】優先順位に基づくコンテンツ再生処理フロー（例３）を示す図である。
【図６０】コンテンツ再生処理における圧縮データの復号（伸長）処理を実行する構成について説明する図である。
【図６１】コンテンツの構成例（例１）を示す図である。
【図６２】コンテンツの構成例１における再生処理フローを示す図である。
【図６３】コンテンツの構成例（例２）を示す図である。
【図６４】コンテンツの構成例２における再生処理フローを示す図である。
【図６５】コンテンツの構成例（例３）を示す図である。
【図６６】コンテンツの構成例３における再生処理フローを示す図である。
【図６７】コンテンツの構成例（例４）を示す図である。
【図６８】コンテンツの構成例４における再生処理フローを示す図である。
【図６９】セーブデータの生成、格納処理について説明する図である。
【図７０】セーブデータの格納処理例(例１)に関する処理フローを示す図である。
【図７１】セーブデータの格納、再生処理において使用されるデータ管理ファイル構成（例１）を示す図である。
【図７２】セーブデータの再生処理例(例１)に関する処理フローを示す図である。
【図７３】セーブデータの格納処理例(例２)に関する処理フローを示す図である。
【図７４】セーブデータの再生処理例(例２)に関する処理フローを示す図である。
【図７５】セーブデータの格納処理例(例３)に関する処理フローを示す図である。
【図７６】セーブデータの格納、再生処理において使用されるデータ管理ファイル構成（例２）を示す図である。
【図７７】セーブデータの再生処理例(例３)に関する処理フローを示す図である。
【図７８】セーブデータの格納処理例(例４)に関する処理フローを示す図である。
【図７９】セーブデータの再生処理例(例４)に関する処理フローを示す図である。
【図８０】セーブデータの格納処理例(例５)に関する処理フローを示す図である。
【図８１】セーブデータの格納、再生処理において使用されるデータ管理ファイル構成（例３）を示す図である。
【図８２】セーブデータの再生処理例(例５)に関する処理フローを示す図である。
【図８３】セーブデータの格納処理例(例６)に関する処理フローを示す図である。
【図８４】セーブデータの格納、再生処理において使用されるデータ管理ファイル構成（例４）を示す図である。
【図８５】セーブデータの再生処理例(例６)に関する処理フローを示す図である。
【図８６】コンテンツ不正利用者排除（リボケーション）構成を説明する図である。
【図８７】コンテンツ不正利用者排除（リボケーション）の処理フロー（例１）を示す図である。
【図８８】コンテンツ不正利用者排除（リボケーション）の処理フロー（例２）を示す図である。
【図８９】セキュリティチップの構成（例１）を説明する図である。
【図９０】セキュリティチップの製造方法における処理フローを示す図である。
【図９１】セキュリティチップの構成（例２）を説明する図である。
【図９２】セキュリティチップ（例２）におけるデータ書き込み処理における処理フローを示す図である。
【図９３】セキュリティチップ（例２）における書き込みデータチェック処理における処理フローを示す図である。
【符号の説明】
１０６ メインＣＰＵ
１０７ ＲＡＭ
１０８ ＲＯＭ
１０９ ＡＶ処理部
１１０ 入力処理部
１１１ ＰＩＯ
１１２ ＳＩＯ
３００ 記録再生器
３０１ 制御部
３０２ 暗号処理部
３０３ 記録デバイスコントローラ
３０４ 読み取り部
３０５ 通信部
３０６ 制御部
３０７ 内部メモリ
３０８ 暗号／復号化部
４００ 記録デバイス
４０１ 暗号処理部
４０２ 外部メモリ
４０３ 制御部
４０４ 通信部
４０５ 内部メモリ
４０６ 暗号／復号化部
４０７ 外部メモリ制御部
５００ メディア
６００ 通信手段
２１０１，２１０２，２１０３ 記録再生器
２１０４，２１０５，２１０６ 記録デバイス
２９０１ コマンド番号管理部
２９０２ コマンドレジスタ
２９０３，２９０４ 認証フラグ
３００１ スピーカ
３００２ モニタ
３０９０ メモリ
３０９１ コンテンツ解析部
３０９２ データ記憶部
３０９３ プログラム記憶部
３０９４ 圧縮伸長処理部
７７０１ コンテンツデータ
７７０２ リボケーションリスト
７７０３ リストチェック値
８０００ セキュリティチップ
８００１ 処理部
８００２ 記憶部
８００３ モード信号線
８００４ コマンド信号線
８２０１ 読み出し書き込み併用領域
８２０２ 書き込み専用領域[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data storage element manufacturing method, a data storage element, and a data processing apparatus. More specifically, for example, high security information such as an encryption key and a password applied to encryption processing can be safely stored. The present invention relates to a data storage element manufacturing method, a data storage element, and a data processing apparatus.
[0002]
The present invention relates to a data storage element suitable for storing, for example, key data for encryption processing or a password, which is highly necessary to prevent leakage to a third party and keep it secret. The data storage element of the present invention is a variety of contents such as audio, images, games, programs, etc. that can be obtained via a route such as a storage medium such as a DVD or CD, or a wired or wireless communication means such as CATV, Internet, or satellite communication. It can be applied as an internal memory that stores key data for content encryption processing in a playback device that uses. It can also be applied as an internal memory element in a recording device that is connected to a recording / reproducing device and stores content, and stores data requiring high security, such as a key for content encryption processing, in this internal memory. be able to.
[0003]
[Prior art]
Recently, various software data such as game programs, audio data, image data, document creation programs, etc. (hereinafter referred to as “Contents”) are distributed via networks such as the Internet or DVDs, CDs, etc. It is distributed through possible storage media. These distribution contents can be stored in recording devices attached to recording / playback devices such as PCs (Personal Computers) and game devices owned by users, such as memory cards, hard disks, and the like. It can be used by playback from the storage medium.
[0004]
Main components of a memory card device used in information devices such as conventional video game devices and PCs are connected to control means for operation control and slots provided in the information device main body connected to the control means. And a non-volatile memory for storing data connected to the control means. The nonvolatile memory provided in the memory card is configured by an EEPROM, a flash memory, or the like.
[0005]
Various contents such as memory cards, CDs, DVDs, data acquired via a network, programs, etc. are used as user instructions or connection from game devices used as playback devices, information device bodies such as PCs, etc. It is called by the user's instruction via the input means and is reproduced through the information device main body or a connected display, speaker, or the like.
[0006]
Many software contents such as game programs, music data, and image data generally have distribution rights and the like for their creators and sellers. Therefore, when distributing these contents, certain usage restrictions, that is, license the use of software only to authorized users and prevent unauthorized copying, etc. It is common to take this configuration.
[0007]
One technique for realizing usage restrictions on users is encryption processing of distributed content. That is, for example, various contents such as encrypted audio data, image data, and game programs are distributed via the Internet, etc., and the encrypted contents distributed only to those who are confirmed to be authorized users. The decryption means, that is, a decryption key is assigned.
[0008]
The encrypted data can be returned to the decrypted data (plain text) that can be used by the decryption process according to a predetermined procedure. Data encryption and decryption methods that use an encryption key for such information encryption processing and a decryption key for decryption processing are well known.
[0009]
There are various types of data encryption / decryption methods using an encryption key and a decryption key. One example is a so-called common key encryption method. In the common key encryption method, the encryption key used for the data encryption process and the decryption key used for the data decryption are made common, and the common key used for the encryption process and the decryption is given to an authorized user. Thus, data access by an unauthorized user who does not have a key is eliminated. A typical method of this method is DES (Data Encryption Standard).
[0010]
The encryption key and decryption key used for the above-described encryption processing and decryption can be obtained by applying a one-way function such as a hash function based on a certain password, for example. A one-way function is a function that makes it very difficult to obtain an input from its output. For example, a one-way function is applied using a password determined by the user as an input, and an encryption key and a decryption key are generated based on the output. From the encryption key and the decryption key obtained in this way, it is virtually impossible to obtain the password that is the original data.
[0011]
In addition, a method in which processing using an encryption key used for encryption and processing of a decryption key used for decryption are different algorithms is a so-called public key encryption method. The public key encryption method uses a public key that can be used by an unspecified user, and encrypts an encrypted document for a specific individual using the public key issued by the specific individual. A document encrypted with a public key can be decrypted only with a secret key corresponding to the public key used for the encryption process. Since the private key is owned only by the individual who issued the public key, a document encrypted with the public key can be decrypted only by the individual who has the private key. A typical public key encryption method is RSA (Rivest-Shamir-Adleman) encryption.
[0012]
By using such an encryption method, a system that enables decryption of encrypted content only for authorized users is possible. A conventional content distribution configuration employing these encryption methods will be briefly described with reference to FIG.
[0013]
FIG. 1 shows a reproduction means 10 such as a PC (personal computer) or a game machine that reproduces a program, audio data, video data, etc. (Content) acquired from a data providing means such as a DVD, a CD 30 or the Internet 40. In addition, a configuration example is shown in which data acquired from a DVD, a CD 30, the Internet 40, etc. can be stored in the storage means 20 such as a floppy disk, a memory card, or a hard disk.
[0014]
Content such as a program, audio data, and video data is encrypted and provided to a user having the playback means 10. The authorized user obtains the key data which is the encryption / decryption key along with the encrypted data.
[0015]
The reproduction means 10 has a CPU 12 and executes reproduction processing of input data by the reproduction processing unit 14. The reproduction processing unit 14 performs a decryption process on the encrypted data, and reproduces the provided program, and reproduces content such as audio data and image data.
[0016]
The authorized user saves content such as a program / data in the storage means 20 in order to use the provided program again. The reproduction means 10 has a storage processing unit 13 for executing this content storage processing. In order to prevent unauthorized use of data stored in the storage unit 20, the storage processing unit 13 performs storage processing by performing encryption processing on the data.
[0017]
When encrypting content, a content encryption key is used. The storage processing unit 13 encrypts the content using the content encryption key and stores it in the storage unit 21 of the storage unit 20 such as an FD (floppy disk), a memory card, or a hard disk.
[0018]
When the user retrieves the stored content from the storage means 20 and reproduces it, the user retrieves the encrypted data from the storage means 20 and uses the reproduction processing unit 14 of the reproduction means 10 to decrypt the content, ie, the decryption key. Is used to execute decryption processing to obtain the decrypted data from the encrypted data and reproduce it.
[0019]
It is necessary to store the encryption key data applied to such encryption / decryption processing in the storage element with high security so as not to be leaked to a third party.
[0020]
[Problems to be solved by the invention]
As a conventional technique for making it difficult to read and rewrite write data, for example, a data write command protocol is kept secret. Alternatively, a signal line that accepts a data write command on the chip and a communication signal line that is used after commercialization are separated, and the data write command is valid unless a signal is sent directly to the chip on the board. There is a technique to prevent it from happening.
[0021]
However, even if such a conventional method is adopted, for those who have expertise in storage elements, if there is equipment and technology to drive the circuit, it is possible to output signals to the data writing area of the chip, Even if the command protocol for writing data is secret, there is always a parseability of the protocol.
[0022]
Distributing such storage elements for encrypted data that retains the possibility of altering secret data results in a threat to the entire encryption system. In addition, in order to prevent data reading, it is possible to adopt a configuration in which the data read command itself is not implemented, but in that case, even when regular data writing is executed, data writing to the memory is actually performed. It is impossible to check whether or not the written data is correctly written and whether or not the written data is written correctly, and there is a possibility that a chip on which defective data has been written is supplied. To do.
[0023]
In view of these conventional techniques, the present invention realizes a secure chip configuration and a secure chip manufacturing method that enable accurate data writing to a nonvolatile memory such as flash memory and FeRAM, and make data reading difficult. A data storage element manufacturing method, a data storage element, and a data processing device are provided.
[0027]
[Means for Solving the Problems]
The first aspect of the present invention is:
  A data storage unit comprising a non-volatile memory;
  A processing control unit that executes control of data writing and reading processing to the data storage unit;
  Mode signal line for setting data write and read modes to the data storageWhen,
A signal line for connecting an external device for performing data writing and reading processing on the data storage unit;
  An authentication information storage unit storing authentication processing data;
  The processing control unit
The mode signal line is set to a data writing or reading mode, and
  External device connected by the signal lineOnly when authentication is established in the authentication process using the authentication process data between the data storage element andDepending on the external deviceWrite data to the data storage unit or read data from the data storage unitAllowControlDo,
The processing control unit further executes encryption processing to which the encryption key stored in the data storage unit is applied to write data from the external device, and outputs the encrypted data to the external deviceThe data storage element is characterized by having a configuration.
[0028]
Furthermore, the second aspect of the present invention provides
  A data processing device having a data storage element;
  The data storage element is
  A data storage unit comprising a non-volatile memory;
  A processing control unit that executes control of data writing and reading processing to the data storage unit;
  Mode signal line for setting data write and read modes to the data storageWhen,
A signal line for connecting an external device for performing data writing and reading processing on the data storage unit;
  An authentication information storage unit storing authentication processing data;
  The processing control unit
The mode signal line is set to a data writing or reading mode, and
  External device connected by the signal lineOnly when authentication is established in the authentication process using the authentication process data between the data storage element andDepending on the external deviceWrite data to the data storage unit or read data from the data storage unitAllowControlDo,
The processing control unit further executes encryption processing to which the encryption key stored in the data storage unit is applied to write data from the external device, and outputs the encrypted data to the external deviceA data processing apparatus having a data storage element characterized by having a configuration.
[0032]
The program providing medium according to the present invention is a medium that provides a computer program in a computer-readable format to, for example, a general-purpose computer system that can execute various program codes. The form of the medium is not particularly limited, such as a storage medium such as a CD, FD, or MO, or a transmission medium such as a network.
[0033]
Such a program providing medium defines a structural or functional cooperative relationship between a computer program and a providing medium for realizing a function of a predetermined computer program on a computer system. . In other words, by installing a computer program in the computer system via the provided medium, a cooperative action is exhibited on the computer system, and the same effects as the other aspects of the present invention are obtained. Can do it.
[0034]
Other objects, features, and advantages of the present invention will become apparent from a more detailed description based on embodiments of the present invention described later and the accompanying drawings.
[0035]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below. The explanation procedure is performed according to the following items.
(1) Data processor configuration
(2) Content data format
(3) Overview of cryptographic processing applicable to data processing devices
(4) Storage data structure of recording / reproducing device
(5) Storage device storage data configuration
(6) Mutual authentication processing between recording / reproducing device and recording device
(6-1) Overview of mutual authentication processing
(6-2) Key block switching during mutual authentication
(7) Download process from recording / playback device to recording device
(8) Reproduction processing of recording device storage information by recording / reproducing device
(9) Key exchange process after mutual authentication
(10) Multiple content data formats and download and playback processing corresponding to each format
(11) Check value (ICV) generation process in content provider
(12) Cryptographic key generation configuration based on master key
(13) Control of cryptographic strength in cryptographic processing
(14) Program activation processing based on the activation priority in the handling policy for content data
(15) Content composition and playback (decompression) processing
(16) Generation of save data, storage in a recording device, and reproduction processing
(17) Unauthorized device exclusion (revocation) configuration
(18) Secure chip configuration and manufacturing method
[0036]
(1) Data processor configuration
FIG. 2 is a block diagram showing the overall configuration of an embodiment of the data processing apparatus of the present invention. The data processing apparatus of the present invention includes a recording / reproducing device 300 and a recording device 400 as main components.
[0037]
The recording / reproducing device 300 is configured by, for example, a personal computer (PC) or a game machine. As shown in FIG. 2, the recording / reproducing device 300 includes a control unit 301 that performs overall control including communication control with the recording device 400 at the time of encryption processing in the recording / reproducing device 300, and a recording / reproducing device encryption that controls overall encryption processing. A processing unit 302, a recording device controller 303 that performs authentication processing with a recording device 400 connected to a recording / reproducing device, reads and writes data, a reading unit 304 that reads at least data from a medium 500 such as a DVD, and external and data A communication unit 305 that performs transmission and reception is included.
[0038]
The recording / reproducing device 300 downloads content data to the recording device 400 and reproduces content data from the recording device 400 under the control of the control unit 301. The recording device 400 is a storage medium that is preferably detachable from the recording / reproducing device 300, such as a memory card. The recording device 400 includes an external memory 402 including a nonvolatile memory such as an EEPROM and a flash memory, a hard disk, a RAM with a battery, and the like. Have.
[0039]
The recording / reproducing device 300 receives content data distributed from a network such as the reading unit 304 as an interface capable of inputting content data stored in the storage medium, DVD, CD, FD, and HDD shown at the left end of FIG. It has a communication unit 305 as an inputable interface, and inputs content from the outside.
[0040]
The recording / reproducing device 300 includes an encryption processing unit 302 and downloads content data input from the outside via the reading unit 304 or the communication unit 305 to the recording device 400, or reproduces content data from the recording device 400. , An authentication process, an encryption process, a decryption process, and a data verification process are executed. The cryptographic processing unit 302 includes a control unit 306 that controls the entire cryptographic processing unit 302, an internal memory 307 that holds information such as a cryptographic processing key, and has been processed so that data cannot be easily read from the outside. The encryption / decryption unit 308 performs encryption processing, decryption processing, generation / verification of authentication data, generation of random numbers, and the like.
[0041]
For example, when the recording device 400 is attached to the recording / reproducing device 300, the control unit 301 transmits an initialization command to the recording device 400 via the recording device controller 303, or the control unit 301 of the recording / reproducing device encryption processing unit 302 It performs mediation processing in various processes such as mutual authentication processing, check value matching processing, encryption and decryption processing performed between the encryption / decryption unit 308 and the encryption / decryption unit 406 of the recording device encryption processing unit 401. Each of these processes will be described in detail later.
[0042]
The encryption processing unit 302 is a processing unit that executes authentication processing, encryption processing, decryption processing, and data verification processing, as described above, and includes an encryption processing control unit 306, an internal memory 307, an encryption / decryption unit. 308.
[0043]
The encryption processing control unit 306 is a control unit that performs control related to the entire encryption processing such as authentication processing and encryption / decryption processing executed in the recording / reproducing device 300. For example, the recording / reproducing device 300, the recording device 400, and the like. Setting of an authentication completion flag at the time of completion of authentication processing executed between the various processes executed in the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302, for example, check value generation relating to download or reproduction content data It performs control related to encryption processing in general, such as processing execution instructions and execution instructions for generating various key data.
[0044]
The internal memory 307, which will be described in detail later, is key data or identification data required for various processes such as mutual authentication processing, check value verification processing, encryption, decryption processing, etc. executed in the recording / reproducing device 300. Etc. are stored.
[0045]
The encryption / decryption unit 308 downloads content data input from the outside to the recording device 400 using the key data stored in the internal memory 307 or the content data stored in the recording device 400 Is executed from the recording device 400, and processing such as authentication processing, encryption processing, and decryption processing, and generation / verification of predetermined check values and electronic signatures, data verification, and random number generation are executed.
[0046]
Here, since the internal memory 307 of the recording / reproducing device encryption processing unit 302 holds important information such as an encryption key, it is necessary to have a structure that prevents unauthorized reading from the outside. Accordingly, the cryptographic processing unit 302 is configured by a semiconductor chip having a structure that is difficult to access from the outside, and has a multilayer structure, and the internal memory is sandwiched between dummy layers such as an aluminum layer or configured at the lowest layer. In addition, it is configured as a tamper-resistant memory having characteristics that make it difficult to read data illegally from the outside, such as a narrow operating voltage and / or frequency range. This configuration will be described in detail later.
[0047]
In addition to these cryptographic processing functions, the recording / reproducing device 300 includes a central processing unit (Main CPU) 106, a RAM (Random Access Memory) 107, a ROM (Read Only Memory) 108, an AV processing unit 109, An input interface 110, a PIO (parallel I / O interface) 111, and an SIO (serial I / O interface) 112 are provided.
[0048]
A central processing unit (Main CPU) 106, a RAM (Random Access Memory) 107, and a ROM (Read Only Memory) 108 are components that function as a control system of the main body of the recording / reproducing device 300. It functions as a reproduction processing unit that performs reproduction of the data decrypted by the device encryption processing unit 302. For example, the central processing unit (main CPU: Central Processing Unit) 106 reproduces content by outputting content data read from the recording device and decoded to the AV processing unit 109 under the control of the control unit 301. Executes control related to execution.
[0049]
The RAM 107 is used as a main storage memory for various processes in the CPU 106 and is used as a work area for processing by the main CPU 106. The ROM 108 stores a basic program or the like for starting up an OS or the like activated by the main CPU 106.
[0050]
Specifically, the AV processing unit 109 has a data compression / decompression processing mechanism such as an MPEG2 decoder, an ATRAC decoder, and an MP3 decoder, and outputs data such as a display or a speaker (not shown) attached to or connected to the recording / reproducing unit. Execute processing for data output to the device.
[0051]
The input interface 110 outputs input data from various input means such as a connected controller, keyboard, and mouse to the main CPU 106. The main CPU 106 executes processing in accordance with an instruction from the controller from the user based on, for example, a game program being executed.
[0052]
A PIO (parallel I / O interface) 111 and a SIO (serial I / O interface) 112 are used as a connection interface with a memory card, a storage device such as a game cartridge, a portable electronic device, or the like.
[0053]
The main CPU 106 also performs control when storing setting data or the like related to the game being executed in the recording device 400 as saved data. In this processing, the stored data is transferred to the control unit 301, and the control unit 301 causes the encryption processing unit 302 to execute encryption processing on the save data as necessary, and stores the encrypted data in the recording device 400. These encryption processes will be described in detail later.
[0054]
As described above, the recording device 400 is preferably a storage medium that can be attached to and detached from the recording / reproducing device 300, and includes, for example, a memory card. The recording device 400 includes an encryption processing unit 401 and an external memory 402.
[0055]
The recording device encryption processing unit 401 performs mutual authentication between the recording / reproducing device 300 and the recording device 400 at the time of downloading content data from the recording / reproducing device 300 or reproducing content data from the recording device 400 to the recording / reproducing device 300. The processing unit executes processing, encryption processing, decryption processing, and data verification processing, and includes a control unit, an internal memory, an encryption / decryption unit, and the like, similar to the encryption processing unit of the recording / reproducing device 300. These details are shown in FIG. As described above, the external memory 402 is configured by a nonvolatile memory such as a flash memory such as an EEPROM, a hard disk, a battery-equipped RAM, and stores encrypted content data and the like.
[0056]
FIG. 3 shows an outline of the data structure inputted from the medium 500, which is a content providing means to which the data processing apparatus of the present invention supplies data, and the communication means 600, and the contents are inputted from these content providing means 500, 600. FIG. 4 is a diagram showing configurations of a recording / reproducing device 300 and a recording device 400 with a focus on configurations related to encryption processing.
[0057]
The medium 500 is, for example, an optical disk medium, a magnetic disk medium, a magnetic tape medium, a semiconductor medium, or the like. The communication means 600 is a means capable of data communication such as Internet communication, cable communication, satellite communication and the like.
[0058]
In FIG. 3, the recording / reproducing device 300 verifies the data input from the medium 500 as the content providing means and the communication means 600, that is, the content according to a predetermined format as shown in FIG. 3, and records the content after the verification. Save to device 400.
[0059]
As shown in the media 500 and communication means 600 in FIG. 3, the content data has the following components.
Identification information: identification information as an identifier of content data.
Handling policy: Content data configuration information such as header size, content size, format version of content data, content type indicating whether the content is a program or data, etc. Furthermore, it can be used only by the device on which the content was downloaded. Handling policy including usage restriction information such as whether it can be used with other devices.
Block information: Block information composed of the number of content blocks, the block size, an encryption flag indicating the presence or absence of encryption, and the like.
Key data: Key data composed of an encryption key for encrypting the above block information, a content key for encrypting a content block, or the like.
Content block: A content block made up of program data, music, image data, and the like to be actually reproduced.
Have Details of the content data will be described in detail later with reference to FIG.
[0060]
The content data is encrypted with a content key (herein referred to as a content key (hereinafter referred to as Kcon)) and provided to the recording / reproducing device 300 from the medium 500 and the communication unit 600. The content can be stored in the external memory of the recording device 400 via the recording / reproducing device 300.
[0061]
For example, the recording device 400 uses a key unique to the recording device (herein referred to as a storage key (hereinafter referred to as “Kstr”)) stored in the internal memory 405 in the recording device to The content included in the data, the block information included as header information of the content data, and various key information such as the content key Kcon are encrypted and stored in the external memory 402. In the download processing of the content data from the recording / reproducing device 300 to the recording device 400 or the reproduction processing of the content data stored in the recording device 400 by the recording / reproducing device 300, mutual authentication processing between devices, encryption of content data A predetermined procedure such as a decryption process is required. These processes will be described in detail later.
[0062]
As shown in FIG. 3, the recording device 400 includes an encryption processing unit 401 and an external memory 402. The encryption processing unit 401 includes a control unit 403, a communication unit 404, an internal memory 405, an encryption / decryption unit 406, and an external memory. A control unit 407 is included.
[0063]
The recording device 400 is responsible for overall encryption processing, controls the external memory 402, interprets commands from the recording / reproducing device 300, and executes processing, and an external memory 402 that holds content and the like. Consists of.
[0064]
The recording device encryption processing unit 401 stores information such as a control unit 403 that controls the entire recording device encryption processing unit 401, a communication unit 404 that transmits / receives data to / from the recording / reproducing device 300, and key data for encryption processing. Internal memory 405 that has been processed so as not to be easily read from, encryption / decryption processing, authentication data generation / verification, random number generation, etc., and external memory 402 An external memory control unit 407 for reading and writing data.
[0065]
The control unit 403 is a control unit that performs control related to the overall cryptographic processing such as authentication processing and encryption / decryption processing executed in the recording device 400. For example, between the recording / reproducing device 300 and the recording device 400, Setting of an authentication completion flag at the time of completion of the authentication process executed in step S4, various processes executed in the encryption / decryption unit 406 of the encryption processing unit 401, for example, execution instructions for download or check value generation processing relating to playback content data, It performs control related to overall cryptographic processing, such as execution instructions for various key data generation processing.
[0066]
The internal memory 405, which will be described in detail later, is composed of a memory having a plurality of blocks, and includes various types of authentication such as mutual authentication processing, check value matching processing, encryption, decryption processing, and the like executed in the recording device 400. A plurality of sets of key data or identification data necessary for processing are stored.
[0067]
Similar to the internal memory 307 of the recording / reproducing device encryption processing unit 302 described above, the internal memory 405 of the recording device encryption processing unit 401 holds important information such as an encryption key, and thus is difficult to read out illegally from the outside. It needs to be structured. Therefore, the encryption processing unit 401 of the recording device 400 is configured by a semiconductor chip having a structure that is difficult to access from the outside, and has a multilayer structure, and the internal memory is sandwiched between dummy layers such as an aluminum layer or the like. It is configured in a lower layer and has a characteristic that makes it difficult to read data illegally from the outside, such as a narrow operating voltage and / or frequency range. Note that the recording / reproducing device encryption processing unit 302 may be software configured such that secret information such as a key is not easily leaked to the outside.
[0068]
The encryption / decryption unit 406 performs processing for downloading content data from the recording / reproducing device 300, processing for reproducing content data stored in the external memory 402 of the recording device 400, or mutual processing between the recording / reproducing device 300 and the recording device 400. At the time of authentication processing, using key data stored in the internal memory 405, data verification processing, encryption processing, decryption processing, generation / verification of predetermined check values and electronic signatures, generation of random numbers, etc. Execute processing etc.
[0069]
The communication unit 404 is connected to the recording device controller 303 of the recording / reproducing device 300, and according to the control of the control unit 301 of the recording / reproducing device 300 or the control unit 403 of the recording device 403, content data download processing, reproduction processing, or The transfer data is communicated between the recording / reproducing device 300 and the recording device 400 during the mutual authentication process.
[0070]
(2) Content data format
Next, a data format of data stored in the medium 500 in the system of the present invention or distributed on the data communication unit 600 will be described with reference to FIGS.
[0071]
4 is a diagram illustrating the format of the entire content data, and the configuration illustrated in FIG. 5 is a diagram illustrating details of a “handling policy” that forms a part of the header portion of the content data. It is a figure which shows the detail of the "block information" in which a structure comprises a part of header part of content data.
[0072]
Here, a typical example of a data format applied in the system of the present invention will be described. However, in the system of the present invention, for example, a format corresponding to a game program, a format suitable for real-time processing of music data, etc. A plurality of different data formats can be used, and modes of these formats will be described in more detail in “(10) Multiple content data formats and download and playback processing corresponding to each format”.
[0073]
In the data format shown in FIG. 4, the gray portion is encrypted data, the double frame portion is falsification check data, and the other white portion is plaintext data that is not encrypted. The encryption key of the encryption unit is a key shown on the left side of each frame. In the example shown in FIG. 4, encrypted blocks and unencrypted blocks are mixed in each block (content block data) of the content portion. These forms differ depending on the content data, and all the content block data included in the data may be encrypted.
[0074]
As shown in FIG. 4, the data format is divided into a header portion and a content portion. The header portion includes identification information (Content ID), a handling policy (Usage Policy), a check value A (Integrity Check Value A (hereinafter referred to as “Check Value A”). ICVa)), block information key (Block Information Table Key (hereinafter referred to as Kbit)), content key Kcon, block information (Block Information Table (hereinafter referred to as BIT)), check value B (ICVb), total The content part is composed of a plurality of content blocks (for example, encrypted content and unencrypted content).
[0075]
Here, the identification information indicates an individual identifier (Content ID) for identifying the content. As shown in detail in FIG. 5, the handling policy includes a header size indicating the size of the header portion (Header Length), a content size indicating the size of the content portion (Content Length), and a format version indicating the version information of the format (Format Version), a format type indicating the type of format (Format Type), a content type indicating the type of content such as whether the content stored in the content part is a program or data, and the content type is a program Startup priority information (Operation Priority) indicating the startup priority in case of use, and usage restriction information indicating whether the content downloaded according to this format can be used only by the downloaded device or other similar devices ( Localization Field) Copy restriction information (Copy Permission) indicating whether the content downloaded according to this format can be copied from the downloaded device to other similar devices, and the content downloaded according to this format from the downloaded device to other Move restriction information (Move Permission) indicating whether or not the device can be moved to the same device, encryption algorithm (Encryption Algorithm) indicating the algorithm used to encrypt the content block in the content part, and encrypting the content in the content part It consists of an encryption mode (Encryption Mode) indicating how to use the algorithm used in the above, and a verification method (Integrity Check Method) indicating how to generate a check value.
[0076]
Note that the data item recorded in the handling policy described above is one example, and various handling policy information can be recorded according to the mode of the corresponding content data. For example, as will be described in detail in “(17) Unauthorized Device Elimination (Revocation) Configuration” below, the identifier of the unauthorized recording / reproducing device is recorded as data, and content use by the unauthorized device is excluded by collation at the start of use. It is also possible to configure as described above.
[0077]
Check values A and ICVa are check values for verifying falsification of identification information and handling policy. It functions as a check value for partial data rather than the entire content data, that is, as a partial check value. The data block information key Kbit is used to encrypt the block information, and the content key Kcon is used to encrypt the content block. Note that the block information key Kbit and the content key Kcon are encrypted on the medium 500 and the communication means 600 with a distribution key (Distribution Key (hereinafter referred to as Kdis)) described later.
[0078]
Details of the block information are shown in FIG. Note that the block information in FIG. 6 is data that is all encrypted with the block information key Kbit as understood from FIG. As shown in FIG. 6, the block information is composed of a content block number (Block Number) indicating the number of content blocks and N pieces of content block information. The content block information includes a block size (Block Length), an encryption flag (Encryption Flag) indicating whether encryption is performed, a verification target flag (ICV Flag) indicating whether a check value needs to be calculated, It consists of a content check value (ICVi).
[0079]
The content check value is a check value used for verifying tampering of each content block. A specific example of the content check value generation method will be described later in the column “(10) Multiple data formats, download processing to a recording device corresponding to each format, and reproduction processing from the recording device”. The block information key Kbit for encrypting the block information is further encrypted with the delivery key Kdis.
[0080]
The description of the data format in FIG. 4 will be continued. The check values B and ICVb are check values for verifying falsification of the block information key Kbit, the content key Kcon, and the block information. It functions as a check value for partial data rather than the entire content data, that is, as a partial check value. The total check value ICVt is a check value for verifying falsification of ICVa, ICVb, the check value ICVi of each content block (if set), these partial check values, or all the data to be checked. .
[0081]
In FIG. 6, the block size, the encryption flag, and the verification target flag can be freely set, but a configuration in which rules are determined to some extent may be employed. For example, the block information BIT may be compressed by repeating the fixed-size ciphertext area and the plaintext area, or encrypting all content data. Further, in order to make the content key Kcon different for each content block, the content key Kcon may be included in the content block instead of the header portion. Examples of content data formats will be described in more detail in the section “(10) Multiple content data formats and download and playback processing corresponding to each format”.
[0082]
(3) Overview of cryptographic processing applicable to the data processing apparatus of the present invention
Next, aspects of various cryptographic processes that can be applied in the data processing apparatus of the present invention will be described. The description relating to the encryption processing shown in “(3) Overview of encryption processing applicable to the data processing device of the present invention” in this item is various processing in the data processing device of the present invention specifically described later, for example, a . Authentication processing between the recording / reproducing device and the recording device. b. Download processing to the content recording device. c. An outline of an aspect of encryption processing that is a basis of processing executed in processing such as playback processing of content stored in a recording device will be described. Specific processing in the recording / reproducing device 300 and the recording device 400 will be described in detail for each processing in the item (4) and thereafter in this specification.
[0083]
The following is an overview of cryptographic processing applicable in the data processing device.
(3-1) Message authentication by common key cryptography
(3-2) Electronic signature by public key cryptosystem
(3-3) Verification of electronic signature by public key cryptosystem
(3-4) Mutual authentication by common key cryptosystem
(3-5) Public key certificate
(3-6) Mutual authentication by public key cryptosystem
(3-7) Encryption processing using elliptic curve cryptography
(3-8) Decryption processing using elliptic curve cryptography
(3-9) Random number generation processing
Will be described in the order.
[0084]
(3-1) Message authentication by common key cryptography
First, falsification detection data generation processing using a common key cryptosystem will be described. The falsification detection data is data for checking falsification and author authentication by attaching to data to be falsified.
[0085]
For example, the check values A and B of the double frame portion in the data structure described in FIG. 4, the total check value, the content check value stored in each block in the block information shown in FIG. Generated as detection data.
[0086]
Here, an example using DES in the common key cryptosystem will be described as one example of a generation processing method of electronic signature data. In the present invention, in addition to DES, for example, FEAL (Fast Encipherment ALgorithm: NTT), AES (Advanced Encryption Standard), etc. can be used as the processing in the same common key cryptosystem. .
[0087]
A method of generating a digital signature using a general DES will be described with reference to FIG. First, prior to generating an electronic signature, a message to be subjected to the electronic signature is divided into units of 8 bytes (hereinafter, the divided messages are referred to as M1, M2,..., MN). Then, the initial value (Initial Value (hereinafter referred to as IV)) and M1 are exclusive ORed (the result is assumed to be I1). Next, I1 is put into the DES encryption unit and encrypted using a key (hereinafter referred to as K1) (the output is assumed to be E1). Subsequently, E1 and M2 are exclusively ORed, and the output I2 is input to the DES encryption unit and encrypted using the key K1 (output E2). Thereafter, this is repeated, and encryption processing is performed on all messages. The EN that comes out last becomes an electronic signature. This value is generally referred to as a message authentication code (MAC) and is used for checking message tampering. In addition, such a method of chaining ciphertexts is referred to as a CBC (Cipher Block Chaining) mode.
[0088]
The MAC values output in the generation example as shown in FIG. 7 are the check values A and B of the double frame portion in the data structure shown in FIG. 4, the total check values, and the block information shown in FIG. The content check values ICV1 to ICVN stored in each block can be used. At the time of verifying the MAC value, the verifier generates the MAC value by the same method as at the time of generation, and if the same value is obtained, the verification is successful.
[0089]
In the example shown in FIG. 7, the initial value IV is exclusively ORed with the first 8-byte message M1, but the initial value IV = 0 may be used so that the initial value is not exclusively ORed. .
[0090]
FIG. 8 is a processing configuration diagram showing a MAC value generation method in which security is further improved with respect to the MAC value generation method shown in FIG. FIG. 8 shows an example in which a MAC value is generated using a triple DES instead of the single DES of FIG.
[0091]
FIG. 9 shows a detailed configuration example of each Triple DES component shown in FIG. As shown in FIGS. 9A and 9B, there are two different modes in the configuration as a triple DES. FIG. 9A shows an example using two encryption keys. Processing is performed in the order of encryption processing using key 1, decryption processing using key 2, and encryption processing using key 1. Two types of keys are used in the order of K1, K2, and K1. FIG. 9B shows an example using three encryption keys. The encryption process using the key 1, the encryption process using the key 2, and the encryption process using the key 3 are performed in this order, and the encryption is performed three times. Process. Three types of keys are used in the order of K1, K2, and K3. By adopting a configuration in which a plurality of processes are continued in this manner, the security strength is improved as compared with single DES. However, this Triple DES configuration has the disadvantage that the processing time is approximately three times that of a single DES.
[0092]
FIG. 10 shows a MAC value generation configuration example obtained by improving the triple DES configuration described in FIGS. In FIG. 10, the encryption process for each message from the beginning to the middle of the message sequence to be signed is all performed by single DES, and only the encryption process for the last message is performed by the triple DES (shown in FIG. 9A). Triple DES) configuration.
[0093]
By adopting such a configuration as shown in FIG. 10, the MAC value generation processing time of the message is shortened to approximately the same time as the MAC value generation processing by the single DES, and the security is higher than the MAC value by the single DES. Can also be increased. Note that the triple DES configuration for the final message may be the configuration shown in FIG.
[0094]
(3-2) Electronic signature by public key cryptosystem
The above is a method of generating electronic signature data when the common key encryption method is applied as the encryption method. Next, FIG. 11 shows a method of generating an electronic signature using the public key encryption method as the encryption method. It explains using. The process shown in FIG. 11 is an electronic signature data generation process flow using EC-DSA ((Elliptic Curve Digital Signature Algorithm), IEEE P1363 / D3). Here, an example using elliptic curve cryptography (hereinafter referred to as ECC) as public key cryptography will be described. In the data processing apparatus of the present invention, in addition to elliptic curve cryptography, for example, RSA cryptography ((Rivest, Shamir, Adleman), etc. (ANSI X9.31)) in a similar public key cryptosystem can be used. It is.
[0095]
Each step in FIG. 11 will be described. In step S1, p is a characteristic, a and b are elliptic curve coefficients (elliptic curve: y²= x^Three+ Ax + b), G is the base point on the elliptic curve, r is the order of G, and Ks is the secret key (0 <Ks <r). In step S2, the hash value of the message M is calculated and set to f = Hash (M).
[0096]
Here, a method for obtaining a hash value using a hash function will be described. A hash function is a function that takes a message as input, compresses the message into data of a predetermined bit length, and outputs the data as a hash value. It is difficult for the hash function to predict the input from the hash value (output). When one bit of the data input to the hash function changes, many bits of the hash value change, and the same hash value is changed. It has a feature that it is difficult to find different input data. As the hash function, MD4, MD5, SHA-1, or the like may be used, or the same DES-CBC as described in FIG. 7 and others may be used. In this case, the MAC (check value: corresponding to ICV) that is the final output value is the hash value.
[0097]
Subsequently, in step S3, a random number u (0 <u <r) is generated, and in step S4, coordinates V (Xv, Yv) obtained by multiplying the base point by u are calculated. The addition and doubling on the elliptic curve are defined as follows.
[0098]
[Expression 1]

[0099]
Use these to calculate u times the point G (the speed is slow, but the easiest way to do this is as follows: calculate G, 2 × G, 4 × G,. 2 corresponding to where 1 is standingⁱXG (value obtained by doubling G times i times) is added (i is a bit position when counted from the LSB of u)).
[0100]
In step S5, c = Xvmod r is calculated. In step S6, it is determined whether or not this value is 0. If not 0, d = [(f + cKs) / u] mod r is calculated in step S7, and step S8. Whether d is 0 or not is determined. If d is not 0, c and d are output as electronic signature data in step S9. Assuming that r is 160 bits long, the electronic signature data is 320 bits long.
[0101]
If c is 0 in step S6, the process returns to step S3 to generate a new random number. Similarly, if d is 0 in step S8, the process returns to step S3 to generate a random number again.
[0102]
(3-3) Verification of electronic signature by public key cryptosystem
Next, an electronic signature verification method using a public key cryptosystem will be described with reference to FIG. In step S11, M is a message, p is a characteristic, a and b are elliptic curve coefficients (elliptic curve: y²= x^Three+ Ax + b), G is the base point on the elliptic curve, r is the order of G, and G and Ks × G are the public keys (0 <Ks <r). In step S12, it is verified whether the electronic signature data c and d satisfy 0 <c <r and 0 <d <r. If this is satisfied, the hash value of the message M is calculated in step S13, and f = Hash (M) is set. Next, h = 1 / d mod r is calculated in step S14, and h1 = fh mod r and h2 = ch mod r are calculated in step S15.
[0103]
In step S16, using the already calculated h1 and h2, the point P = (Xp, Yp) = h1 × G + h2 · Ks × G is calculated. Since the electronic signature verifier knows the public key G and Ks × G, it can calculate the scalar multiple of the points on the elliptic curve as in step S4 of FIG. In step S17, it is determined whether or not the point P is an infinite point. If not, the process proceeds to step S18 (actually, the infinite point can be determined in step S16. That is, P = (X , Y), Q = (X, −Y), it is known that λ cannot be calculated and P + Q is an infinite point). In step S18, Xp mod r is calculated and compared with the electronic signature data c. Finally, if the values match, the process proceeds to step S19, where it is determined that the electronic signature is correct.
[0104]
If it is determined that the electronic signature is correct, the data has not been tampered with, and it can be seen that the person holding the private key corresponding to the public key has generated the electronic signature.
[0105]
If the electronic signature data c or d does not satisfy 0 <c <r and 0 <d <r in step S12, the process proceeds to step S20. In step S17, the process proceeds to step S20 also when the point P is an infinite point. Furthermore, when the value of Xp mod r does not match the electronic signature data c in step S18, the process proceeds to step S20.
[0106]
If it is determined in step S20 that the electronic signature is not correct, it can be seen that the data has been tampered with or that the person holding the private key corresponding to the public key has not generated the electronic signature.
[0107]
(3-4) Mutual authentication by common key cryptosystem
Next, a mutual authentication method using a common key cryptosystem will be described with reference to FIG. In FIG. 13, DES is used as the common key encryption method, but any common key encryption method may be used as described above. In FIG. 13, first, B generates a 64-bit random number Rb, and transmits Rb and its own ID (b) to A. Upon receiving this, A newly generates a 64-bit random number Ra, encrypts the data using the key Kab in the CBC mode of DES in the order of Ra, Rb, and ID (b), and returns it to B. According to the DES CBC mode processing configuration shown in FIG. 7, Ra is equivalent to M1, Rb is equivalent to M2, ID (b) is equivalent to M3, and outputs E1, E2, and E3 when the initial value is IV = 0 are encrypted. Become a sentence.
[0108]
Upon receiving this, B decrypts the received data with the key Kab. As a method for decrypting received data, first, the ciphertext E1 is decrypted with the key Kab to obtain the random number Ra. Next, the ciphertext E2 is decrypted with the key Kab, and the result is exclusive-ORed with E1 to obtain Rb. Finally, the ciphertext E3 is decrypted with the key Kab, and the result and E2 are exclusive ORed to obtain ID (b). It is verified whether Rb and ID (b) of Ra, Rb, and ID (b) obtained in this way match those transmitted by B. If this verification is passed, B authenticates A as valid.
[0109]
Next, B generates a session key (Session Key (hereinafter referred to as Kses)) to be used after authentication (the generation method uses a random number). Then, encryption is performed using the key Kab in the DES CBC mode in the order of Rb, Ra, and Kses, and returned to A.
[0110]
Upon receiving this, A decrypts the received data with the key Kab. The method for decoding the received data is the same as the decoding process for B, so the details are omitted here. Of Rb, Ra, and Kses obtained in this way, it is verified whether Rb and Ra match those transmitted by A. If this verification is passed, A authenticates B as valid. After authenticating each other, the session key Kses is used as a common key for secret communication after authentication.
[0111]
In addition, when an illegality or a mismatch is found during the verification of the received data, the processing is interrupted on the assumption that mutual authentication has failed.
[0112]
(3-5) Public key certificate
Next, the public key certificate will be described with reference to FIG. A public key certificate is a certificate issued by a CA (Certificate Authority) in public key cryptography. When a user submits his / her ID, public key, etc. to the certificate authority, the certificate authority side The certificate is created by adding information such as the ID and expiration date of the certificate, and further adding a signature by a certificate authority.
[0113]
The public key certificate shown in FIG. 14 includes the certificate version number, the certificate serial number assigned to the certificate user by the certificate authority, the algorithm and parameters used for the electronic signature, the certificate authority name, and the certificate expiration date. , Including the certificate user's name (user ID), the certificate user's public key, and an electronic signature.
[0114]
The electronic signature consists of the certificate version number, the certificate serial number assigned to the certificate user by the certificate authority, the algorithm and parameters used for the electronic signature, the name of the certificate authority, the certificate expiration date, the certificate user This is data generated by applying a hash function to the name and the entire public key of the certificate user to generate a hash value and using the secret key of the certificate authority for the hash value. For example, the processing flow described with reference to FIG. 11 is applied to the generation of the electronic signature.
[0115]
The certificate authority issues the public key certificate shown in FIG. 14, updates the public key certificate that has expired, and creates, manages, and manages an unauthorized person list for rejecting the unauthorized user. Distribution (this is called revocation). In addition, a public key / private key is generated as necessary.
[0116]
On the other hand, when using this public key certificate, the user verifies the electronic signature of the public key certificate using the public key of the certificate authority that he / she holds, and publishes it after successfully verifying the electronic signature. The public key is extracted from the key certificate and the public key is used. Therefore, all users who use the public key certificate need to hold a common certificate authority public key. Since the electronic signature verification method has been described with reference to FIG.
[0117]
(3-6) Mutual authentication by public key cryptosystem
Next, a mutual authentication method using 160-bit elliptic curve cryptography, which is a public key cryptosystem, will be described with reference to FIG. In FIG. 15, ECC is used as the public key cryptosystem, but any public key cryptosystem may be used as described above. Also, the key size need not be 160 bits. In FIG. 15, first, B generates a 64-bit random number Rb and transmits it to A. Upon receiving this, A newly generates a 64-bit random number Ra and a random number Ak smaller than the characteristic p. Then, a point Av = Ak × G obtained by multiplying the base point G by Ak is obtained, and an electronic signature A.R. for Ra, Rb, Av (X coordinate and Y coordinate) Sig is generated and returned to B along with A's public key certificate. Here, Ra and Rb are 64 bits each, and the X coordinate and Y coordinate of Av are 160 bits each, so that an electronic signature for a total of 448 bits is generated. The method for generating the electronic signature has been described with reference to FIG. Also, since the public key certificate has been described with reference to FIG. 14, its details are omitted.
[0118]
A's public key certificate, Ra, Rb, Av, electronic signature B that receives Sig verifies whether Rb transmitted by A matches that generated by B. As a result, if they match, the electronic signature in A's public key certificate is verified with the public key of the certificate authority, and A's public key is extracted. Since the verification of the public key certificate has been described with reference to FIG. 14, its details are omitted. Then, the electronic signature A.A. Verify Sig. Since the method for verifying the electronic signature has been described with reference to FIG. After successfully verifying the electronic signature, B authenticates A as legitimate.
[0119]
Next, B generates a random number Bk smaller than the characteristic p. Then, a point Bv = Bk × G obtained by multiplying the base point G by Bk is obtained, and an electronic signature B.Rb, Ra, Bv (X coordinate and Y coordinate) is obtained. Sig is generated and returned to A along with B's public key certificate.
[0120]
B's public key certificate, Rb, Ra, Av, digital signature A who receives Sig verifies whether Ra transmitted by B matches the one generated by A. As a result, if they match, the electronic signature in B's public key certificate is verified with the public key of the certificate authority, and B's public key is extracted. Then, using the B public key extracted, the electronic signature B.B. Verify Sig. After successfully verifying the electronic signature, A authenticates B as legitimate.
[0121]
If both are successfully authenticated, B is calculated as Bk × Av (Bk is a random number, but Av is a point on the elliptic curve, so a scalar multiplication of the points on the elliptic curve is required) and A is Ak × Bv is calculated, and the lower 64 bits of the X coordinate of these points are used as a session key for subsequent communications (when the common key encryption is a 64-bit key length common key encryption). Of course, the session key may be generated from the Y coordinate, or may not be the lower 64 bits. In secret communication after mutual authentication, transmission data is not only encrypted with a session key, but an electronic signature may be attached.
[0122]
If an illegality or a mismatch is found during the verification of the electronic signature or the received data, the processing is interrupted assuming that the mutual authentication has failed.
[0123]
(3-7) Encryption processing using elliptic curve cryptography
Next, encryption using elliptic curve encryption will be described with reference to FIG. In step S21, Mx and My are messages, p is a characteristic, a and b are elliptic curve coefficients (elliptic curve: y²= x^Three+ Ax + b), G is the base point on the elliptic curve, r is the order of G, and G and Ks × G are the public keys (0 <Ks <r). In step S22, a random number u is generated so that 0 <u <r, and in step S23, a coordinate V obtained by multiplying the public key Ks × G by u is calculated. Since the scalar multiplication on the elliptic curve has been described in step S4 of FIG. In step S24, the X coordinate of V is multiplied by Mx and a remainder is obtained by p, and X0 is obtained. In step S25, the Y coordinate of V is multiplied by My and the remainder is obtained by p and Y0 is obtained. When the message length is less than the number of bits of p, My uses a random number, and the decoding unit discards My. In step S26, u × G is calculated, and ciphertext u × G, (X0, Y0) is obtained in step S27.
[0124]
(3-8) Decryption processing using elliptic curve cryptography
Next, decryption using elliptic curve encryption will be described with reference to FIG. In step S31, u × G, (X0, Y0) is ciphertext data, p is a characteristic, a, b are elliptic curve coefficients (elliptic curve: y²= x^Three+ Ax + b), G is the base point on the elliptic curve, r is the order of G, and Ks is the secret key (0 <Ks <r). In step s32, the encrypted data u × G is multiplied by the secret key Ks to obtain the coordinates V (Xv, Yv). In step S33, the X coordinate of (X0, Y0) is extracted from the encrypted data and X1 = X0 / Xv mod p is calculated. In step S34, the Y coordinate is extracted and Y1 = Y0 / Yv mod p is calculated. To do. In step S35, X1 is set to Mx and Y1 is set to My to extract a message. At this time, if My is not a message, Y1 is discarded.
[0125]
Thus, by setting the secret key as Ks and the public key as G and Ks × G, the key used for encryption and the key used for decryption can be different.
[0126]
As another example of public key encryption, RSA encryption is known, but detailed description is omitted (details are described in PKCS # 1 Version 2).
[0127]
(3-9) Random number generation processing
Next, a method for generating random numbers will be described. As a random number generation method, there are known a true random number generation method in which thermal noise is amplified and generated from its A / D output, a pseudo random number generation method in which a plurality of linear circuits such as M series are combined, and the like. Also, a method of generating using a common key encryption such as DES is known. In this example, a pseudo random number generation method using DES will be described (based on ANSI X9.17).
[0128]
First, the value of 64 bits obtained from data such as time (in the case of the number of bits less than this, the upper bit is 0) is D, the key information used for Triple-DES is Kr, and the seed for generating random numbers ( Let Seed be S. At this time, the random number R is calculated as follows.
[0129]
[Expression 2]

[0130]
Here, Triple-DES () is a function for encrypting the value of the second argument with Triple-DES using the first argument as encryption key information, and the operation ^ is an exclusive OR in 64-bit units. It is assumed that the value S that has been updated is updated as a new seed.
[0131]
Hereinafter, when generating random numbers continuously, the equations (2-2) and (2-3) are repeated.
[0132]
Heretofore, various processing modes related to cryptographic processing applicable in the data processing apparatus of the present invention have been described. Next, specific processing executed in the data processing apparatus of the present invention will be described in detail.
[0133]
(4) Storage data structure of recording / reproducing device
FIG. 18 is a diagram for explaining the data holding contents of the internal memory 307 configured in the recording / reproducing device encryption processing unit 302 in the recording / reproducing device 300 shown in FIG.
[0134]
As shown in FIG. 18, the internal memory 307 stores the following keys and data.
MKake: recording for generating an authentication key (Authentication and Key Exchange Key (hereinafter referred to as “Kake”)) necessary for mutual authentication processing executed between the recording / reproducing device 300 and the recording device 400 (see FIG. 3). Master key for device authentication key.
IVake: Initial value for recording device authentication key.
MKdis: a delivery key master key for generating a delivery key Kdis.
IVdis: Initial value for generating a delivery key.
Kicva: Check value A generation key that is a key for generating the check value ICVa.
Kicvb: Check value B generation key that is a key for generating the check value ICVb.
Kicvc: a content check value generation key that is a key for generating the check value ICVi (i = 1 to N) of each content block.
Kicvt: Total check value generation key that is a key for generating the total check value ICVt.
Ksys: System signature key used to attach a common signature or ICV to the distribution system.
Kdev: A recording / reproducing device signature key that is different for each recording / reproducing device and is used by the recording / reproducing device to attach a signature or ICV.
IVmem: Initial value and initial value used for encryption processing in mutual authentication processing. Common with recording device.
These keys and data are stored in an internal memory 307 configured in the recording / reproducing device encryption processing unit 302.
[0135]
(5) Storage device storage data configuration
FIG. 19 is a diagram illustrating a data holding state on the recording device. In FIG. 19, the internal memory 405 is divided into a plurality of blocks (N blocks in this example), and the following keys and data are stored in each block.
IDmem: recording device identification information, identification information unique to the recording device.
Kake: an authentication key, an authentication key used for mutual authentication with the recording / reproducing device 300.
IVmem: Initial value and initial value used for encryption processing in mutual authentication processing.
Kstr: Encryption key for content data such as storage key, block information key, and the like.
Kr: random number generation key,
S: Species
These data are held in individual blocks. The external memory 402 holds a plurality (M in this example) of content data, and holds the data described in FIG. 4 as shown in FIG. 26 or FIG. 27, for example. Differences between the configurations of FIGS. 26 and 27 will be described later.
[0136]
(6) Mutual authentication processing between recording / reproducing device and recording device
(6-1) Overview of mutual authentication processing
FIG. 20 is a flowchart showing an authentication procedure between the recording / reproducing device 300 and the recording device 400. In step S <b> 41, the user inserts the recording device 400 into the recording / reproducing device 300. However, it is not necessary to insert a recording device that can communicate without contact.
[0137]
When the recording device 400 is set in the recording / reproducing device 300, a recording device detecting means (not shown) in the recording / reproducing device 300 shown in FIG. 3 notifies the control unit 301 of the mounting of the recording device 400. Next, in step S <b> 42, the control unit 301 of the recording / reproducing device 300 transmits an initialization command to the recording device 400 via the recording device controller 303. Upon receiving this, the recording device 400 receives the command via the communication unit 404 in the control unit 403 of the recording device encryption processing unit 401, and clears the authentication completion flag if it is set. In other words, the unauthenticated state is set.
[0138]
Next, in step S43, the control unit 301 of the recording / reproducing device 300 transmits an initialization command to the recording / reproducing device encryption processing unit 302. At this time, the recording device insertion slot number is also transmitted. By transmitting the recording device insertion slot number, even when a plurality of recording devices are connected to the recording / reproducing device 300, authentication processing and data transmission / reception with the plurality of recording devices 400 can be performed simultaneously.
[0139]
The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 that has received the initialization command, if the authentication completion flag corresponding to the recording device insertion port number is set in the control unit 306 of the recording / reproducing device encryption processing unit 302. clear. In other words, the unauthenticated state is set.
[0140]
Next, in step S44, the control unit 301 of the recording / reproducing device 300 designates the key block number used by the recording device encryption processing unit 401 of the recording device 400. Details of the key block number will be described later. In step S <b> 45, the control unit 301 of the recording / reproducing device 300 reads the recording device identification information IDmem stored in the designated key block of the internal memory 405 of the recording device 400. In step S46, the control unit 301 of the recording / reproducing device 300 transmits the recording device identification information IDmem to the recording / reproducing device encryption processing unit 302 to generate an authentication key Kake based on the recording device identification information IDmem. For example, the authentication key Kake is generated as follows.
[0141]
[Equation 3]

[0142]
Here, MKake is a master key for recording device authentication key for generating an authentication key Kake necessary for mutual authentication processing executed between the recording / reproducing device 300 and the recording device 400 (see FIG. 3). This is a key stored in the internal memory 307 of the recording / reproducing device 300 as described above. ID mem is recording device identification information unique to the recording device 400. Further, IVake is an initial value for the recording device authentication key. In the above equation, DES () is a function for encrypting the value of the second argument with DES using the first argument as an encryption key, and the operation ^ indicates an exclusive OR in 64-bit units.
[0143]
For example, when the DES configuration shown in FIGS. 7 and 8 is applied, the message M shown in FIGS. 7 and 8 is the recording device identification information: IDmem, the key K1 is the device authentication key master key: MKake, and the initial value The output obtained with IV as IVake is the authentication key Kake.
[0144]
In step S47, mutual authentication and session key Kses generation processing is performed. The mutual authentication is performed between the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 and the encryption / decryption unit 406 of the recording device encryption processing unit 401, and the control unit 301 of the recording / reproduction device 300 acts as an intermediary. Is going.
[0145]
The mutual authentication process can be executed according to the process described with reference to FIG. In the configuration shown in FIG. 13, A and B correspond to the recording / reproducing device 300 and the recording device 400, respectively. First, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 generates a random number Rb, and transmits the random number Rb and the recording / reproducing device identification information IDdev that is its own ID to the recording device encryption processing unit 401 of the recording device 400. Note that the recording / reproducing device identification information IDdev is an identifier unique to the reproducing device stored in a storage unit configured in the recording / reproducing device 300. The recording / reproducing device identification information IDdev may be recorded in the internal memory of the recording / reproducing device encryption processing unit 302.
[0146]
The recording device encryption processing unit 401 of the recording device 400 that has received the random number Rb and the recording / reproducing device identification information IDdev newly generates a 64-bit random number Ra, and in the order of Ra, Rb, and the recording / reproducing device identification information IDdev, In the CBC mode, the data is encrypted using the authentication key Kake and returned to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. For example, according to the DES CBC mode processing configuration shown in FIG. 7, Ra is equivalent to M1, Rb is equivalent to M2, IDdev is equivalent to M3, and outputs E1, E2, and E3 when the initial value is IV = IVmem are ciphertext. It becomes.
[0147]
The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 that has received the ciphertexts E1, E2, E3 decrypts the received data with the authentication key Kake. As a method of decrypting received data, first, the ciphertext E1 is decrypted with the authentication key Kake, and the result and IVmem are exclusive ORed to obtain a random number Ra. Next, the ciphertext E2 is decrypted with the authentication key Kake, and the result is exclusive-ORed with E1 to obtain Rb. Finally, the ciphertext E3 is decrypted with the authentication key Kake, and the result and E2 are exclusive ORed to obtain the recording / reproducing device identification information IDdev. Of Ra and Rb and recording / reproducing device identification information IDdev obtained in this way, it is verified whether Rb and recording / reproducing device identification information IDdev match those transmitted by the recording / reproducing device 300. If this verification is passed, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 authenticates the recording device 400 as valid.
[0148]
Next, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 generates a session key (Session Key (hereinafter referred to as Kses)) to be used after authentication (the generation method uses a random number). Then, the data is encrypted in the order of Rb, Ra, and Kses using the key Kake and the initial value IVmem in the DES CBC mode, and returned to the recording device encryption processing unit 401 of the recording device 400.
[0149]
Receiving this, the recording device encryption processing unit 401 of the recording device 400 decrypts the received data with the key Kake. Since the decryption method of the received data is the same as the decryption process in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, the details are omitted here. Of Rb, Ra, and Kses obtained in this way, it is verified whether Rb and Ra match those transmitted by the recording device 400. If the verification is passed, the recording device encryption processing unit 401 of the recording device 400 authenticates the recording / reproducing device 300 as valid. After authenticating each other, the session key Kses is used as a common key for secret communication after authentication.
[0150]
In addition, when an illegality or a mismatch is found during the verification of the received data, the processing is interrupted on the assumption that mutual authentication has failed.
[0151]
If the mutual authentication is successful, the process proceeds from step S48 to step S49, where the session key Kses is held by the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and an authentication completion flag indicating that the mutual authentication has been completed. set. If the mutual authentication fails, the process proceeds to step S50 where the session key Kses generated in the authentication process is discarded and the authentication completion flag is cleared. It should be noted that the clearing process is not necessarily required if it has already been cleared.
[0152]
When the recording device 400 is removed from the recording device insertion slot, the recording device detection means in the recording / reproducing device 300 notifies the control unit 301 of the recording / reproducing device 300 that the recording device 400 has been removed. In response to this, the control unit 301 of the recording / reproducing device 300 instructs the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to clear the authentication completion flag corresponding to the recording device insertion slot number. The recording / reproducing device encryption processing unit 302 of the received recording / reproducing device 300 clears the authentication completion flag corresponding to the recording device insertion slot number.
[0153]
Here, the example in which the mutual authentication process is executed according to the procedure shown in FIG. 13 has been described. However, the present invention is not limited to the above-described authentication process example. For example, the process according to the previously described mutual authentication procedure in FIG. May be. In the procedure shown in FIG. 13, A in FIG. 13 is the recording / reproducing device 300, B is the recording device 400, and B: the ID that the recording device 400 first sends to the A: recording / reproducing device 300 in the recording device. Mutual authentication processing may be performed as recording device identification information in the key block. Various processing can be applied to the authentication processing procedure executed in the present invention, and the authentication processing procedure is not limited to the above-described authentication processing.
[0154]
(6-2) Key block switching during mutual authentication
One feature of the mutual authentication processing in the data processing apparatus of the present invention is that a plurality of key blocks (ex.N key blocks) are configured on the recording device 400 side, and the recording / reproducing device 300 designates one key block. (Step S44 in the processing flow of FIG. 20) and the authentication processing is executed. As described above with reference to FIG. 19, a plurality of key blocks are formed in the internal memory 405 configured in the encryption processing unit 401 of the recording device 400, and each stores various data such as different key data and ID information. is doing. The mutual authentication process executed between the recording / reproducing device 300 and the recording device 400 described with reference to FIG. 20 is executed for one key block of the plurality of key blocks of the recording device 400 of FIG.
[0155]
Conventionally, in a configuration in which mutual authentication processing is executed between a storage medium and its playback device, a common key used for mutual authentication: a common authentication key has been used. Therefore, for example, when changing the authentication key for each product destination (by country) or for each product, the key data required for authentication processing on the recording / reproducing device side and the recording device side must be changed on both devices. Is required. Therefore, for example, the key data required for the authentication process stored in the newly released recording / reproducing device does not correspond to the key data required for the authentication process stored in the previously sold recording device. The recording / reproducing device may be unable to access an old version of the recording device. Conversely, the same situation occurs in the relationship between the new version recording device and the old version recording / reproducing device.
[0156]
In the data processing apparatus of the present invention, as shown in FIG. 19, a plurality of key blocks as different key sets are stored in the recording device 400 in advance. In the recording / reproducing device, for example, a key block to be applied to the authentication process, that is, a designated key block is set for each product destination (by country), or for each product, model, version, and application. This setting information is stored in the memory unit of the recording / reproducing device, for example, the internal memory 307 in FIG. 3 or other storage element of the recording / reproducing device 300, and is accessed by the control unit 301 in FIG. 3 during the authentication process. The key block is specified according to the setting information.
[0157]
The master key MKake for the recording device authentication key in the internal memory 307 of the recording / reproducing device 300 is an authentication key master key set according to the setting of each designated key block, and can only deal with the designated key block. Mutual authentication with key blocks other than the designated key block is not established.
[0158]
As understood from FIG. 19, N key blocks 1 to N are set in the internal memory 405 of the recording device 400, and the recording device identification information, the authentication key, the initial value, the storage key, A random number generation key and seed are stored, and at least key data for authentication is stored as different data for each block.
[0159]
Thus, the key data configuration of the key block of the recording device 400 is different for each block. Therefore, for example, a key block that a certain recording / reproducing apparatus A can perform an authentication process using the recording device authentication key master key MKake stored in the internal memory is a key block No. 1 and the key block that can be authenticated by the recording / reproducing device B of another specification is another key block such as a key block No. 2 can be set.
[0160]
As will be described in more detail later, when content is stored in the external memory 402 of the recording device 400, encryption processing is performed using the storage key Kstr stored in each key block and stored. More specifically, the content key for encrypting the content block is encrypted with the storage key.
[0161]
As shown in FIG. 19, the storage key is configured as a different key for each block. Accordingly, it is possible to prevent the content stored in the memory of a certain recording device from being used in common between two recording / reproducing devices set to specify different key blocks. That is, the recording / reproducing device having different settings can use only the content stored in the recording device that matches the respective settings.
[0162]
Note that data that can be shared for each key block can be shared. For example, only the key data for authentication and the stored key data may be different.
[0163]
As a specific example of configuring a key block composed of a plurality of different key data in such a recording device, for example, the key block number to be specified differs depending on the type of the recording / reproducing device 300 (stationary type, portable type, etc.). There are examples of setting or setting different designated key blocks for each application. Further, for example, for a recording / reproducing device sold in Japan, the designated key block is No. No. 1 is used for recording / reproducing devices sold in the United States. It is also possible to adopt a configuration in which different key block settings are made for each region, such as 2. With this configuration, content that is used in different sales regions and stored on the recording device with a different storage key can be transferred from the US to Japan, or from Japan to the US, even if the recording device is a memory card. However, since it cannot be used with a recording / reproducing device with a different key setting, it is possible to prevent unauthorized and random distribution of content stored in the memory. Specifically, it is possible to eliminate a state in which the content key Kcon encrypted with a different storage key Kstr can be mutually used between the two countries.
[0164]
Furthermore, at least one key block from key blocks 1 to N of the internal memory 405 of the recording device 400 shown in FIG. The N key blocks may be configured as key blocks that can be commonly used in any recording / reproducing device 300.
[0165]
For example, the key block No. By storing the master key MKake for the recording device authentication key that can be authenticated with N, it can be handled as a content that can be distributed regardless of the type of the recording / reproducing device 300, each application, each destination country, and the like. For example, the key block No. The encrypted content stored in the memory card with the storage key stored in N becomes content that can be used in all devices. For example, music data or the like is encrypted with a storage key of a key block that can be used in common and stored in a memory card, and this memory card is also stored with, for example, a common recording device authentication key master key MKake. By setting it in a playback device or the like, it is possible to perform decoding and playback processing of data from the memory card.
[0166]
An example of use of a recording device having a plurality of key blocks in the data processing apparatus of the present invention is shown in FIG. The recording / reproducing device 2101 is a recording / reproducing device for products in Japan, and the key block No. of the recording device. 1 and 4 have a master key for authentication processing. The recording / reproducing device 2102 is a recording / reproducing device for a product for the US. 2 and 4 have a master key for authentication processing. The recording / reproducing device 2103 is a recording / reproducing device for EU products. It has a master key that enables the authentication process between 3 and 4.
[0167]
For example, the recording / reproducing device 2101 authenticates with the key block 1 or the key block 4 of the recording devices A and 2104, and the content subjected to the encryption processing via the storage key stored in each key block is externally stored. Stored in memory. The recording / reproducing device 2102 authenticates with the key block 2 or the key block 4 of the recording devices B and 2105, and the content subjected to the encryption processing via the storage key stored in each key block is stored in the external memory. Stored in The recording / reproducing device 2103 is authenticated with the key block 3 or the key block 4 of the recording devices C and 2106, and the content subjected to the encryption processing via the storage key stored in each key block is stored in the external memory. Stored in Here, when the recording devices A and 2104 are attached to the recording / reproducing device 2102 or the recording / reproducing device 2103, the content encrypted with the storage key of the key block 1 is recorded in the recording / reproducing device 2102, the recording / reproducing device 2103 and the key. Since authentication with the block 1 is not established, it cannot be used. On the other hand, the content encrypted with the storage key of the key block 4 can be used because authentication is established between the recording / reproducing device 2102, the recording / reproducing device 2103, and the key block 4.
[0168]
As described above, in the data processing apparatus of the present invention, a key block comprising a plurality of different key sets is configured on the recording device, while a master key that can be authenticated for a specific key block is stored in the recording / reproducing device. Since it is set as the structure which carries out, it becomes possible to set the utilization restrictions of the content according to various utilization aspects.
[0169]
A plurality of key blocks that can be specified in one recording / reproducing device, for example, 1 to k, and a plurality of key blocks that can be specified in another recording / reproducing device, such as p to q, can be used. Alternatively, a plurality of commonly available key blocks may be provided.
[0170]
(7) Download process from recording / playback device to recording device
Next, processing for downloading content from the recording / reproducing device 300 to the external memory of the recording device 400 in the data processing apparatus of the present invention will be described.
[0171]
FIG. 22 is a flowchart illustrating a procedure for downloading content from the recording / reproducing device 300 to the recording device 400. In FIG. 22, it is assumed that the mutual authentication process described above has already been completed between the recording / reproducing device 300 and the recording device 400.
[0172]
In step S51, the control unit 301 of the recording / reproducing device 300 reads data according to a predetermined format from the medium 500 storing the content using the reading unit 304, or from the communication unit 600 using the communication unit 305. Receive data according to the format. Then, the control unit 301 of the recording / reproducing device 300 transmits a header portion (see FIG. 4) of the data to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300.
[0173]
Next, in step S52, the control unit 306 of the recording / reproducing device encryption processing unit 302 that has received the header in step S51 calculates the check value A to the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302. Let As shown in FIG. 23, the check value A uses the check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the identification information (Content ID), and the handling policy (Usage Policy). ) As a message according to the ICV calculation method described in FIG. Note that even if the initial value is IV = 0, the check value A generating initial value IVa may be stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 and used. Finally, the check value A and the check value: ICVa stored in the header (Header) are compared, and if they match, the process proceeds to step S53.
[0174]
As described above with reference to FIG. 4, the check values A and ICVa are check values for verifying falsification of the identification information and the handling policy. The ICV calculation method described with reference to FIG. 7 using a check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption unit 302 as a key, and identification information (Content ID) and a handling policy (Usage Policy) as messages. If the check value A calculated according to the above matches the check value ICVa stored in the header (Header), it is determined that the identification information and the handling policy are not falsified.
[0175]
Next, in step S53, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 to generate the delivery key Kdis. For example, the delivery key Kdis is generated as follows.
[0176]
[Expression 4]

[0177]
Here, MKdis is a delivery key master key for generating a delivery key Kdis, which is a key stored in the internal memory of the recording / reproducing device 300 as described above. The Content ID is identification information of the header portion of the content data, and IVdis is an initial value for the delivery key. In the above equation, DES () is a function that encrypts the value of the second argument using the first argument as an encryption key, and the operation ^ indicates an exclusive OR in 64-bit units.
[0178]
In step S54, the control unit 306 of the recording / reproducing device encryption processing unit 302 uses the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 and the reading unit 304 using the delivery key Kdis generated in step S53. The block information key Kbit and the content key Kcon (see FIG. 4) stored in the header portion of the media 500 received via the communication unit 600 or the data received from the communication unit 600 via the communication unit 305 are decrypted. As shown in FIG. 4, the block information key Kbit and the content key Kcon are previously encrypted with a delivery key Kdis on a medium such as a DVD or CD, or on a communication path such as the Internet.
[0179]
In step S55, the control unit 306 of the recording / reproducing device encryption processing unit 302 uses the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to block information with the block information key Kbit decrypted in step S54. (BIT) is decrypted. As shown in FIG. 4, the block information (BIT) is pre-encrypted with a block information key Kbit on media such as DVD and CD, or on a communication path such as the Internet.
[0180]
In step S56, the control unit 306 of the recording / reproducing device encryption processing unit 302 divides the block information key Kbit, the content key Kcon, and the block information (BIT) into units of 8 bytes, and performs exclusive OR operation on all of them. Any operation such as addition and subtraction may be used). Next, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the check value B (ICVb). As shown in FIG. 24, the check value B uses the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, and the exclusive OR value calculated earlier is encrypted by DES. To generate. Finally, the check value B is compared with the ICVb in the header. If they match, the process proceeds to step S57.
[0181]
As described above with reference to FIG. 4, the check values B and ICVb are check values for verifying falsification of the block information key Kbit, the content key Kcon, and the block information (BIT). Using the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the block information key Kbit, the content key Kcon, and the block information (BIT) are divided into units of 8 bytes, and the exclusive logic If the check value B generated by encrypting the sum obtained with DES matches the check value ICVb stored in the header (Header), the block information key Kbit, the content key Kcon, and the block information It is judged that there is no tampering.
[0182]
In step S57, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate an intermediate check value. As shown in FIG. 25, the intermediate check value is a check value A in a verified header (Header) using the total check value generation key Kicvt stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. The check value B and all stored content check values are calculated as messages according to the ICV calculation method described in FIG. Even if the initial value IV = 0, the total value generation initial value IVt may be stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 and used. The generated intermediate check value is held in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 as necessary.
[0183]
This intermediate check value is generated as a message with check value A, check value B, and all content check values, and the verification of the data that is the object of verification of each of these check values is the intermediate check value. You may carry out by a collation process. However, in this embodiment, the non-tampering verification process as shared data of the entire system and the verification process for identifying as exclusive data occupied only by each recording / playback device 300 after the download process can be executed separately. Therefore, a plurality of different check values, that is, the total check value ICVt and the recording / reproducing device specific check value ICVdev can be generated separately from the intermediate check value based on the intermediate check value. These check values will be described later.
[0184]
The control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the total check value ICVt. As shown in FIG. 25, the total check value ICVt is generated by encrypting the intermediate check value with DES using the system signature key Ksys stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Finally, the generated total check value ICVt is compared with the ICVt in the header stored in step S51. If they match, the process proceeds to step S58. The system signature key Ksys is a signature key that is common to a plurality of recording / reproducing devices, that is, the entire system set that performs recording / reproducing processing of certain data.
[0185]
As described above with reference to FIG. 4, the total check value ICVt is a check value for verifying falsification of all the check values of ICVa, ICVb, and each content block. Therefore, if the total check value generated by the above processing matches the check value: ICVt stored in the header (Header), it is determined that there is no falsification of all check values of ICVa, ICVb, and each content block. Is done.
[0186]
Next, in step S58, the control unit 301 of the recording / reproducing device 300 extracts the content block information in the block information (BIT) and checks whether the content block is a verification target. When the content block is a verification target, the content check value is stored in the block information in the header.
[0187]
If the content block is to be verified, the corresponding content block is read from the medium 500 using the reading unit 304 of the recording / reproducing device 300 or the communication unit 600 using the communication unit 305 of the recording / reproducing device 300. Are transmitted to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Receiving this, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the content intermediate value.
[0188]
The content intermediate value is the content key Kcon decrypted in step S54, the input content block is decrypted in the DES CBC mode, and the result is divided every 8 bytes, and exclusive OR (addition, subtraction, etc.) Any calculation may be performed).
[0189]
Next, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the content check value. The content check value is generated by encrypting the content intermediate value with DES using the content check value generation key Kicvc stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Then, the control unit 306 of the recording / reproducing device encryption processing unit 302 compares the content check value with the ICV in the content block received from the control unit 301 of the recording / reproducing device 300 in step S51, and compares the result with the recording / reproducing device. It is passed to the control unit 301 of 300. The control unit 301 of the recording / reproducing device 300 that has received the information retrieves the next verification target content block and causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to verify the content block when all the contents are verified. The same verification process is repeated until the block is verified. If combined with the header generation side, even if IV = 0, the content check value generation initial value IVc may be stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 and used. . All the checked content check values are held in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Furthermore, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 monitors the verification order of the content blocks to be verified, and when the order is incorrect or when the same content block is verified twice or more. Is assumed to have failed authentication. If all verifications are successful, the process proceeds to step S59.
[0190]
Next, in step S59, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 uses the block information key Kbit and the content key Kcon decrypted in step S54 to encrypt / decrypt the recording / reproducing device encryption processing unit 302. The encryption unit 308 is encrypted with the session key Kses shared at the time of mutual authentication. The control unit 301 of the recording / reproducing device 300 reads the block information key Kbit and the content key Kcon encrypted with the session key Kses from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and these data are recorded on the recording / reproducing device 300. To the recording device 400 via the recording device controller 303.
[0191]
Next, in step S60, the recording device 400 that has received the block information key Kbit and the content key Kcon transmitted from the recording / reproducing device 300 sends the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401. Then, the data is decrypted with the session key Kses shared at the time of mutual authentication, and re-encrypted with the storage device-specific storage key Kstr stored in the internal memory 405 of the recording device encryption processing unit 401. Finally, the control unit 301 of the recording / reproducing device 300 reads the block information key Kbit and the content key Kcon re-encrypted with the storage key Kstr from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300. These keys are replaced with a block information key Kbit and a content key Kcon encrypted with the delivery key Kdis.
[0192]
In step S61, the control unit 301 of the recording / reproducing device 300 extracts the usage restriction information from the usage policy in the header portion of the data, and the downloaded content can be used only by the recording / reproducing device 300 (in this case, the usage) Whether the restriction information is set to 1) or another similar recording / reproducing device 300 can be used (in this case, the use restriction information is set to 0). As a result of the determination, if the usage restriction information is 1, the process proceeds to step S62.
[0193]
In step S62, the control unit 301 of the recording / reproducing device 300 causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to calculate a check value unique to the recording / reproducing device. As shown in FIG. 25, the check value unique to the recording / reproducing device uses the recording / reproducing device signing key Kdev stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, and is stored in step S58. The check value is generated by encrypting with DES. The calculated check value ICVdev specific to the recording / reproducing device is overwritten instead of the total check value ICVt.
[0194]
As described above, the system signature key Ksys is a system signature key used for attaching a common signature or ICV to the distribution system, and the recording / reproducing device signature key Kdev is different for each recording / reproducing device, This is a recording / reproducing device signature key used by the recording / reproducing device to attach a signature or ICV. That is, the data signed by the system signature key Ksys is successfully checked by a system (recording / reproducing device) having the same system signature key, that is, the total check value ICVt matches, so that it can be used in common. When the recording / reproducing device signature key Kdev is used for signing, since the recording / reproducing device signature key is a key unique to the recording / reproducing device, the data signed using the recording / reproducing device signature key Kdev, that is, After the signature, the data stored in the recording device is reproduced because when the recording device is attached to another recording / reproducing device and the recording device is to be reproduced, the check value ICVdev specific to the recording / reproducing device becomes inconsistent and an error occurs. It will not be possible.
[0195]
Therefore, in the data processing apparatus of the present invention, it is possible to freely set contents that can be used in common in the system and contents that can be used uniquely in the recording / reproducing device by setting use restriction information.
[0196]
In step S <b> 63, the control unit 301 of the recording / reproducing device 300 stores the content in the external memory 402 of the recording device 400.
[0197]
FIG. 26 is a diagram showing a content state in the recording device when the usage restriction information is 0. FIG. 27 is a diagram showing the content status in the recording device when the usage restriction information is 1. 26 differs from FIG. 4 only in whether the content block information key Kbit and the content key Kcon are encrypted with the delivery key Kdis or the storage key Kstr. Also, FIG. 27 differs from FIG. 26 in that the check value calculated from the intermediate check value is encrypted with the system signature key Ksys in FIG. 26, whereas in FIG. It is encrypted with the device signature key Kdev.
[0198]
In the processing flow of FIG. 22, if verification of the check value A fails in step S52, if verification of the check value B fails in step S56, if verification of the total check value ICVt fails in step S57, If the verification of the content check value of each content block fails in S58, the process proceeds to step S64 and a predetermined error display is performed.
[0199]
If the usage restriction information is 0 in step S61, step S62 is skipped and the process proceeds to step S63.
[0200]
(8) Reproduction processing of recording device storage information by recording / reproducing device
Next, the reproduction process of the content information stored in the external memory 402 of the recording device 400 in the recording / reproducing device 300 will be described.
[0201]
FIG. 28 is a flowchart illustrating a procedure in which the recording / reproducing device 300 reads content from the recording device 400 and uses the content. In FIG. 28, it is assumed that the mutual authentication has already been completed between the recording / reproducing device 300 and the recording device 400.
[0202]
In step S <b> 71, the control unit 301 of the recording / reproducing device 300 reads content from the external memory 402 of the recording device 400 using the recording device controller 303. Then, the control unit 301 of the recording / reproducing device 300 transmits the header portion of the data to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Step S72 is the same processing as step S52 described in “(7) Download process from recording / reproducing device to recording device”, and the control unit 306 of the recording / reproducing device encryption processing unit 302 that has received the header (Header). In this process, the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 calculates the check value A. As shown in FIG. 23 described above, the check value A uses the check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, and identification information (Content ID) and handling policy. (Usage Policy) as a message is calculated according to the same ICV calculation method as described in FIG.
[0203]
As described above, the check values A and ICVa are check values for verifying falsification of identification information and handling policy. The ICV calculation method described in FIG. 7 using the check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption unit 302 as a key and the identification information (Content ID) and the handling policy (Usage Policy) as messages. When the check value A calculated according to the above matches the check value ICVa stored in the header, it is determined that the identification information stored in the recording device 400 and the handling policy are not falsified.
[0204]
Next, in step S73, the control unit 301 of the recording / reproducing device 300 extracts the block information key Kbit and the content key Kcon from the read header portion, and the recording device via the recording device controller 303 of the recording / reproducing device 300. 400. The recording device 400 that has received the block information key Kbit and the content key Kcon transmitted from the recording / reproducing device 300 sends the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401 and the recording device encryption processing unit 401. Are decrypted with the storage key Kstr unique to the recording device stored in the internal memory 405, and re-encrypted with the session key Kses shared at the time of mutual authentication. Then, the control unit 301 of the recording / reproducing device 300 reads the block information key Kbit and the content key Kcon re-encrypted with the session key Kses from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300.
[0205]
Next, in step S74, the control unit 301 of the recording / reproducing device 300 sends the block information key Kbit and the content key Kcon re-encrypted with the received session key Kses to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Send.
[0206]
The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 that has received the block information key Kbit and the content key Kcon re-encrypted with the session key Kses sends the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 to The block information key Kbit and the content key Kcon encrypted with the session key Kses are decrypted with the session key Kses shared at the time of mutual authentication. Then, the block information received in step S71 is decrypted with the decrypted block information key Kbit.
[0207]
The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 receives the decrypted block information key Kbit, content key Kcon, and block information BIT in step S71, the block information key Kbit, content key Kcon, and It replaces and holds the block information BIT. The control unit 301 of the recording / reproducing device 300 reads the decrypted block information BIT from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300.
[0208]
Step S75 is the same processing as step S56 described in “(7) Downloading process from recording / reproducing device to recording device”. The control unit 306 of the recording / reproducing device encryption processing unit 302 divides the block information key Kbit, the content key Kcon, and the block information (BIT) read from the recording device 400 into units of 8 bytes, and performs exclusive OR operation on all of them. Next, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the check value B (ICVb). As shown in FIG. 24 described above, the check value B uses the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, and the exclusive OR value calculated above. Is generated by encrypting with DES. Finally, the check value B is compared with the ICVb in the header. If they match, the process proceeds to step S76.
[0209]
As described above, the check values B and ICVb are check values for verifying falsification of the block information key Kbit, the content key Kcon, and the block information. Using the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the block information key Kbit, content key Kcon, and block information (BIT) read from the recording device 400 are in units of 8 bytes. The check value B generated by encrypting the value obtained by the exclusive OR operation with the DES is matched with the check value: ICVb stored in the header in the data read from the recording device 400 In this case, it is determined that the block information key Kbit, the content key Kcon, and the block information of the data stored in the recording device 400 are not falsified.
[0210]
In step S76, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate an intermediate check value. The intermediate check value is a check in a verified header (Header) using the total check value generation key Kicvt stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key as shown in FIG. The value A, the check value B, and all stored content check values are calculated as messages according to the ICV calculation method described in FIG. Note that even if the initial value is IV = 0, IVt may be stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as the initial value for generating the total check value and used. The generated intermediate check value is held in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 as necessary.
[0211]
Next, in step S77, the control unit 301 of the recording / reproducing device 300 extracts the usage restriction information from the usage policy included in the header portion of the data read from the external memory 402 of the recording device 400, and the downloaded content. Can be used only by the recording / reproducing device 300 (use restriction information is 1), or can be used by another similar recording / reproducing device 300 (use restriction information is 0). As a result of the determination, when the usage restriction information is 1, that is, when the usage restriction that the downloaded content can be used only by the recording / reproducing device 300 is set, the process proceeds to step S80, and the usage restriction information is 0, that is, another similar situation. If the setting is also available for the recording / reproducing device 300, the process proceeds to step S78. Note that the encryption processing unit 302 may perform the processing in step S77.
[0212]
In step S78, the same total check value ICVt is calculated as in step S58 described in (7) Download processing from recording / reproducing device to recording device. That is, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the total check value ICVt. The total check value ICVt is generated by encrypting the intermediate check value with DES using the system signature key Ksys stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key as shown in FIG. To do.
[0213]
Next, the process proceeds to step S79. The total check value ICVt generated in step S78 is compared with the ICVt in the header (Header) saved in step S71. If they match, the process proceeds to step S82.
[0214]
As described above, the total check value ICVt is a check value for verifying falsification of all the check values of ICVa, ICVb, and each content block. Therefore, when the total check value generated by the above process matches the check value ICVt stored in the header (Header), in the data stored in the recording device 400, ICVa, ICVb, each content block It is determined that there is no falsification of all the check values.
[0215]
If it is determined in step S77 that the downloaded content is a setting that can be used only by the recording / reproducing device 300, that is, if the setting information is 1, the process proceeds to step S80.
[0216]
In step S80, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 to calculate a check value ICVdev unique to the recording / reproducing device. The check value ICVdev unique to the recording / reproducing device uses the recording / reproducing device signature key Kdev unique to the recording / reproducing device stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as shown in FIG. The intermediate check value is generated by encrypting with DES. In step S81, the recording / reproducing device specific check value ICVdev calculated in step S80 is compared with the ICVdev stored in the header stored in step S71. If they match, the process proceeds to step S82.
[0217]
As described above, the data signed by the system signature key Ksys is successfully used by the system (recording / reproducing device) having the same system signature key, that is, the total check value ICVt is matched, so that the data can be commonly used. When the recording / reproducing device signature key Kdev is used for signing, since the recording / reproducing device signature key is a key unique to the recording / reproducing device, the data signed using the recording / reproducing device signature key Kdev, that is, After signing, the data stored in the recording device cannot be reproduced because the check value ICVdev unique to the recording / reproducing device becomes inconsistent and an error occurs when the recording device is attached to another recording / reproducing device for reproduction. It will be. Therefore, it is possible to freely set contents that can be used in common in the system and contents that can be used unique to the recording / reproducing device by setting the use restriction information.
[0218]
In step S82, the control unit 301 of the recording / reproducing device 300 takes out the content block information in the block information BIT read in step S74 and checks whether the content block is an encryption target. When it is an encryption target, the corresponding content block is read from the external memory 402 of the recording device 400 via the recording device controller 303 of the recording / reproducing device 300, and the recording / reproducing device encryption processing unit of the recording / reproducing device 300 is read out. To 302. Upon receiving this, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to decrypt the content, and when the content block is a verification target. Causes the content check value to be verified in the next step S83.
[0219]
Step S83 is the same processing as step S58 described in “(7) Downloading process from recording / reproducing device to recording device”. The control unit 301 of the recording / reproducing device 300 extracts content block information in the block information (BIT), determines whether or not the content block is a verification target, and determines whether the content block is a verification target. If it is, the corresponding content block is received from the external memory 402 of the recording device 400 and transmitted to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Receiving this, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the content intermediate value.
[0220]
The content intermediate value is generated by decrypting the input content block in the DES CBC mode with the content key Kcon decrypted in step S74, and dividing the result into 8 bytes and performing an exclusive OR operation.
[0221]
Next, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the content check value. The content check value is generated by encrypting the content intermediate value with DES using the content check value generation key Kicvc stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Then, the control unit 306 of the recording / reproducing device encryption processing unit 302 compares the content check value with the ICV in the content block received from the control unit 301 of the recording / reproducing device 300 in step S71, and compares the result with the recording / reproducing device. It is passed to the control unit 301 of 300. The control unit 301 of the recording / reproducing device 300 that has received the information retrieves the next verification target content block and causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to verify the content block when all the contents are verified. The same verification process is repeated until the block is verified. Even if the initial value is IV = 0, the content check value generation initial value IVc may be stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 and used. All the checked content check values are held in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Furthermore, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 monitors the verification order of the content blocks to be verified, and when the order is wrong or when the same content block is verified twice or more. Is assumed to have failed authentication.
[0222]
The control unit 301 of the recording / reproducing device 300 receives the comparison result of the content check value (if it is not the verification target, the comparison result is all successful), and if the verification is successful, the recording / reproduction is performed. The decrypted content is extracted from the recording / reproducing device encryption processing unit 302 of the device 300. Then, the next decryption target content block is taken out and decrypted by the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and the process is repeated until all the content blocks are decrypted.
[0223]
In step S83, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, when there is a mismatch in the verification processing of the content check value, cancels the processing as the verification failure and decrypts the remaining content. No conversion is performed. The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 monitors the decryption order of the content blocks to be decrypted, and the order is incorrect or the same content block is decrypted twice or more. In this case, it is assumed that decryption has failed.
[0224]
If the verification of the check value A fails in step S72, the verification of the check value B fails in step S75, the verification of the total check value ICVt fails in step S79, the recording / reproducing device specific in step S81. If verification of the check value ICVdev fails, if verification of the content check value of each content block fails in step S83, the process proceeds to step S84, and a predetermined error display is performed.
[0225]
As described above, when downloading or using content, important data and content can be encrypted and concealed, falsified and verified, and block information BIT can be decrypted. The block information key Kbit and the content key Kcon for decrypting the content are stored with the storage key Kstr specific to the recording device, so even if the data on the recording medium is simply copied to another recording medium, the content Cannot be correctly decrypted. More specifically, for example, in step S74 of FIG. 28, the data encrypted with the storage key Kstr that differs for each recording device is decrypted, and therefore the data cannot be correctly decrypted by another recording device. is there.
[0226]
(9) Key exchange process after mutual authentication
One of the features of the data processing apparatus of the present invention is that the recording device can be used only after the mutual authentication processing executed between the recording / reproducing device 300 and the recording device 400 described above, and the use thereof. There is a point which limited the mode.
[0227]
For example, in order to exclude a recording device such as a memory card storing content by illegal duplication, etc. and setting it in a recording / reproducing device, the recording / reproducing device 300 and the recording device 400 are used. The content (encrypted) can be transferred between the recording / reproducing device 300 and the recording device 400 on the condition that the mutual authentication process is executed and the authentication is OK.
[0228]
In order to realize the above restrictive processing, in the data processing apparatus of the present invention, all processing in the encryption processing unit 401 of the recording device 400 is executed based on a preset command sequence. ing. That is, the recording device has a command processing configuration in which commands based on command numbers are sequentially extracted from the register and executed. FIG. 29 illustrates a command processing configuration in this recording device.
[0229]
As shown in FIG. 29, recording is performed between the recording / reproducing device 300 having the recording / reproducing device encryption processing unit 302 and the recording device 400 having the recording device encryption processing unit 401 under the control of the control unit 301 of the recording / reproducing device 300. A command number (No.) is output from the device controller 303 to the communication unit (including the reception register) 404 of the recording device 400.
[0230]
The recording device 400 includes a command number management unit 2201 in the control unit 403 in the encryption processing unit 401. The command number management unit 2901 holds a command register 2902 and stores a command string corresponding to the command number output from the recording / reproducing device 300. In the command string, as shown on the right side of FIG. 29, execution numbers are sequentially associated with command numbers from command numbers 0 to y. The command number management unit 2901 monitors the command number output from the recording / reproducing device 300, retrieves the corresponding command from the command register 2902, and executes it.
[0231]
As shown on the right side of FIG. 29, the command sequence stored in the command register 2902 is associated with command numbers 0 to k preceded by a command sequence related to the authentication processing sequence. Further, decryption, key exchange, and encryption processing command sequence 1 correspond to command numbers p to s after the command sequence related to the authentication processing sequence, and decryption, key exchange, and encryption processing command sequence 2 correspond to subsequent command numbers u to y. It is attached.
[0232]
As described above with reference to the authentication processing flow of FIG. 20, when the recording device 400 is attached to the recording / reproducing device 300, the control unit 301 of the recording / reproducing device 300 initializes to the recording device 400 via the recording device controller 303. Send a commutation command. Upon receiving this, the recording device 400 receives the command via the communication unit 404 in the control unit 403 of the recording device encryption processing unit 401 and clears the authentication flag 2903. In other words, the unauthenticated state is set. Alternatively, when power is supplied from the recording / reproducing device 300 to the recording device 400, a method may be used in which the setting is performed in an unapproved state when the power is turned on.
[0233]
Next, the control unit 301 of the recording / reproducing device 300 transmits an initialization command to the recording / reproducing device encryption processing unit 302. At this time, the recording device insertion slot number is also transmitted. By transmitting the recording device insertion slot number, even when a plurality of recording devices are connected to the recording / reproducing device 300, authentication processing and data transmission / reception with the plurality of recording devices 400 can be performed simultaneously.
[0234]
The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 that has received the initialization command clears the authentication flag 2904 corresponding to the recording device insertion port number in the control unit of the recording / reproducing device encryption processing unit 302. In other words, the unauthenticated state is set.
[0235]
When these initialization processes are completed, the control unit 301 of the recording / reproducing device 300 sequentially outputs command numbers from the command number 0 in ascending order via the recording device controller 303. The command number management unit 2901 of the recording device 400 monitors the command numbers input from the recording / reproducing device 300, confirms that they are sequentially input from 0, extracts corresponding commands from the command register 2902, and performs authentication processing or the like. Perform various processes. If the input command number is not in the prescribed order, an error is assumed and the command number acceptance value is reset to the initial state, that is, the executable command number = 0.
[0236]
As shown in FIG. 29, the command sequence stored in the command register 2902 is given a command number so that the authentication process is processed in advance, and the subsequent processing sequence includes decryption, key exchange, and encryption processing. Is stored.
[0237]
Specific examples of processing sequences of decryption, key exchange, and encryption processing will be described with reference to FIGS.
[0238]
FIG. 30 constitutes a part of the processing executed in the content download processing from the recording / reproducing device 300 to the recording device 400 described above with reference to FIG. Specifically, it is executed between steps S59 to S60 in FIG.
[0239]
In FIG. 30, step S3001 is a process in which the recording device receives data (ex. Block information key Kbit, content key Kcon) encrypted with the session key Kses from the recording / reproducing device, and thereafter, in FIG. The indicated command sequence p to s is started. The command sequence p to s is started after the authentication processing commands 0 to k are completed and the authenticated flag is set in the authentication flags 2903 and 2904 shown in FIG. This is guaranteed by the command number management unit 2901 accepting command numbers only in ascending order from 0.
[0240]
Step S3002 is processing for storing in the register data (ex. Block information key Kbit, content key Kcon) encrypted by the recording device with the session key Kses received from the recording / reproducing device.
[0241]
Step S3003 is a step of executing processing for taking out the data encrypted with the session key Kses (ex. Block information key Kbit, content key Kcon) from the register and decrypting it with the session key Kses.
[0242]
Step S3004 is a step of executing processing for encrypting the data (ex. Block information key Kbit, content key Kcon) decrypted with the session key Kses with the storage key Kstr.
[0243]
The processing steps 3002 to 3004 are processes included in the command numbers p to s in the command register described with reference to FIG. These processes are sequentially executed by the recording device encryption processing unit 401 in accordance with the command numbers p to s received from the recording / reproducing device 300 in the command number management unit 2901 of the recording device 400.
[0244]
The next step S3005 is a step of storing data (ex. Block information key Kbit, content key Kcon) encrypted with the storage key Kstr in the external memory of the recording device. In this step, the data encrypted by the recording / reproducing device 300 with the storage key Kstr may be read from the recording device encryption processing unit 401 and then stored in the external memory 402 of the recording device 400.
[0245]
The above-described steps S3002 to S3004 are continuously executed non-interruptible execution sequences. For example, even when there is a data read command from the recording / reproducing device 300 at the end of the decoding process in step S3003, Since the read command is different from the ascending command numbers set in the command numbers p to s of the command register 2902, the command number management unit 2901 does not accept the execution of reading. Accordingly, it becomes impossible to read out the decrypted data generated at the time of key exchange in the recording device 400 from the outside, for example, the recording / reproducing device 300, and it is possible to prevent unauthorized reading of the key data and contents.
[0246]
FIG. 31 constitutes a part of the process executed in the content reproduction process in which the content is read from the recording device 400 described above with reference to FIG. Specifically, this is the process executed in step S73 in FIG.
[0247]
In FIG. 31, step S3101 is a step of reading data (ex. Block information key Kbit, content key Kcon) encrypted with the storage key Kstr from the external memory 402 of the recording device 400.
[0248]
Step S3102 is a step of storing in the register data (ex. Block information key Kbit, content key Kcon) encrypted with the storage key Kstr read from the memory of the recording device. In this step, the data encrypted by the recording / reproducing device 300 with the storage key Kstr may be read from the external memory 402 of the recording device 400 and then stored in the register of the recording device 400.
[0249]
In step S3103, the data (ex. Block information key Kbit, content key Kcon) encrypted with the storage key Kstr is extracted from the register and decrypted with the storage key Kstr.
[0250]
Step S3104 is a step in which the data (ex. Block information key Kbit, content key Kcon) decrypted with the storage key Kstr is encrypted with the session key Kses.
[0251]
The processing steps 3102 to 3104 are processes included in the command numbers u to y in the command register described with reference to FIG. These processes are sequentially executed by the recording device encryption processing unit 406 in accordance with the command numbers u to y received from the recording / reproducing device 300 in the command number management unit 2901 of the recording device.
[0252]
The next step S3105 is processing for transmitting data (ex. Block information key Kbit, content key Kcon) encrypted with the session key Kses from the recording device to the recording / reproducing device.
[0253]
The above-described steps S3102 to S3104 are continuously executed non-interruptible execution sequences. For example, even if there is a data read command from the recording / reproducing device 300 at the end of the decoding process in step S3103, Since the read command is different from the command numbers in ascending order set in the command numbers u to y of the command register 2902, the command number management unit 2901 does not accept execution of reading. Accordingly, it becomes impossible to read out the decrypted data generated at the time of key exchange in the recording device 400 from the outside, for example, the recording / reproducing device 300, and it is possible to prevent unauthorized reading of the key data or contents.
[0254]
In the processing shown in FIGS. 30 and 31, an example is shown in which the object to be decrypted and encrypted by key exchange is the block information key Kbit and the content key Kcon. However, in the command register 2902 shown in FIG. The stored command sequence may include decryption and encryption processing accompanied by key exchange of the content itself, and the object to be decrypted and encrypted by key exchange is not limited to the above example.
[0255]
The key exchange process after mutual authentication in the data processing apparatus of the present invention has been described above. As described above, the key exchange process in the data processing apparatus of the present invention can be executed only after the authentication process between the recording / reproducing device and the recording device is completed, and the decryption data in the key exchange process is accessed from the outside. Therefore, a high level of security of content and key data is ensured.
[0256]
(10) Multiple content data formats and download and playback processing corresponding to each format
In the above-described embodiment, for example, the case where the data format in the medium 500 or the communication unit 600 shown in FIG. 3 is one type shown in FIG. 4 has been described. However, the data format in the medium 500 or the communication unit 600 is not limited to the format shown in FIG. 4 described above, and depending on the content, such as when the content is music, image data, or a program such as a game. It is desirable to adopt a different data format. Hereinafter, a plurality of different data data formats, download processing to a recording device corresponding to each format, and reproduction processing from the recording device will be described.
[0257]
32-35 show four different data formats. The left side of each figure shows the data format on the medium 500 or communication means 600 shown in FIG. 3, and the right side of each figure shows the data format when stored in the external memory 402 of the recording device 400. . First, the outline of the data format shown in FIGS. 32 to 35 will be described, and then the contents of each data in each format and the data difference in each format will be described.
[0258]
FIG. 32 shows format type 0, which is common to the types shown as examples in the above description. The feature of format type 0 is that the entire data is divided into N data blocks of an arbitrary size, that is, blocks 1 to N, and each block is arbitrarily encrypted, and an encrypted block and an unencrypted block, that is, The point is that data can be configured by mixing plaintext blocks. The encryption of the block is executed by the content key Kcon. The content key Kcon is encrypted on the medium by the delivery key Kdis, and at the time of saving in the recording device, the content key Kcon is stored by the storage key Kstr stored in the internal memory of the recording device. Encrypted. The block information key Kbit is also encrypted on the medium by the delivery key Kdis, and when stored in the recording device, it is encrypted by the storage key Kstr stored in the internal memory of the recording device. These key exchanges are executed according to the process described in the above-mentioned “(9) Key exchange process after mutual authentication”.
[0259]
FIG. 33 shows format type 1. As with format type 0, format type 1 divides the entire data into N data blocks, that is, block 1 to block N. It differs from the aforementioned format type 0 in that the size is the same. The block encryption processing mode using the content key Kcon is the same as the format type 0 described above. In addition, the content type Kcon and the block information key Kbit configuration encrypted with the delivery key Kdis on the medium and encrypted with the storage key Kstr stored in the internal memory of the recording device when stored in the recording device are also the format type 0 described above. It is the same. Unlike format type 0, format type 1 has a fixed block configuration, which simplifies configuration data such as the data length of each block. Therefore, the memory size of block information is smaller than that of format type 0. It becomes possible to reduce.
[0260]
In the configuration example of FIG. 33, each block is configured by one set of an encrypted part and a non-encrypted (plaintext) part. In this way, if the block length and configuration are regular, there is no need to confirm each block length and block configuration at the time of decryption processing or the like, and efficient decryption and encryption processing becomes possible. In format 1, the parts constituting each block, that is, the encrypted part and the unencrypted (plaintext) part can be defined as a check target for each part, and the block including the check part is required. If it is, the content check value ICVi is defined for the block.
[0261]
FIG. 34 shows format type 2. The feature of format type 2 is divided into N data blocks of the same size, that is, block 1 to block N, and each block is encrypted with an individual block key Kblc. It is that. The encryption of each block key Kblc is executed by the content key Kcon, and the content key Kcon is encrypted by the delivery key Kdis on the medium, and when stored in the recording device, the storage is stored in the internal memory of the recording device. Encrypted with the key Kstr. The block information key Kbit is also encrypted on the medium by the delivery key Kdis, and when stored in the recording device, it is encrypted by the storage key Kstr stored in the internal memory of the recording device.
[0262]
FIG. 35 shows format type 3, and the features of format type 3 are divided into N data blocks of the same size, that is, block 1 to block N, as in format type 2. Encrypted with the individual block key Kblc, and without using the content key, the encryption of each block key Kblc is encrypted on the media with the delivery key Kdis, and on the recording device with the storage key Kstr It is a point that is. The content key Kcon does not exist on the media or device. The block information key Kbit is encrypted on the medium by the delivery key Kdis, and when stored in the recording device, it is encrypted by the storage key Kstr stored in the internal memory of the recording device.
[0263]
Next, data contents of the format types 0 to 3 will be described. As described above, the data is roughly classified into two parts, a header part and a content part. The header part includes a content identifier, a handling policy, check values A and B, a total check value, a block information key, a content key, and a block. Contains information.
[0264]
The handling policy includes content data length, header length, format type (formats 0 to 3 described below), for example, content type such as program or data, download of the content to the recording device, As described in the replay section, a localization flag that is a flag for determining whether or not content can be used uniquely for a recording / playback device, a permission flag for content copying and moving processing, a content encryption algorithm, Stores various usage restriction information and processing information related to content such as mode.
[0265]
The check value A: ICVa is a check value for the identification information and the handling policy, and is generated, for example, by the method described with reference to FIG.
[0266]
The block information key Kbit is a key for encrypting the block information. As described above, the block information key Kbit is encrypted with the delivery key Kdis on the medium, and stored in the internal memory of the recording device when stored in the recording device. It is encrypted with the stored key Kstr.
[0267]
The content key Kcon is a key used for content encryption. In the format types 0 and 1, the content key Kcon is encrypted on the medium by the delivery key Kdis like the block information key Kbit. It is encrypted with the storage key Kstr stored in the memory. In format type 2, the content key Kcon is also used to encrypt the block key Kblc configured for each block of content. In format type 3, there is no content key Kcon.
[0268]
The block information is a table describing information of each block. The block size and the flag indicating whether or not the block is encrypted, that is, whether or not each block is a check target (ICV). Information to be stored is stored. When a block is a check target, the block check value ICVi (block i check value) is defined and stored in the table. This block information is encrypted by the block information encryption key Kbit.
[0269]
The block check value, that is, the content check value ICVi, is stored in the internal memory 307 of the recording / reproducing device 300 as a value obtained by exclusive ORing the entire plaintext (decrypted text) in units of 8 bytes when the block is encrypted. It is generated as a value encrypted with the content check value generation key Kicvc. If the block is not encrypted, the entire block data (plain text) is expressed in 8-byte units using the falsification check value generation function (DES-CBC-MAC, content check value generation key Kicvc) shown in FIG. ) Is generated as a value obtained by inputting to. FIG. 36 shows a configuration example for generating the check value ICVi of the content block. Each message M constitutes 8 bytes of decrypted text data or plain text data.
[0270]
In the format type 1, when at least one of the parts in the block is the target data of the check value ICVi, that is, the check required part, the content check value ICVi is defined for the block. The check value P-ICVij of the part j in the block i is obtained by encrypting a value obtained by exclusive ORing the entire plaintext (decrypted text) in units of 8 bytes when the part j is encrypted. Generated as a value. If the part j is not encrypted, the tamper check value generation function (DES-CBC-MAC, content check value generation key Kicvc) shown in FIG. As a key).
[0271]
Furthermore, if there is only one part [ICV flag = subject of ICV] indicating that it is a check target in one block i, that is, only one check part is required, the check value P− generated by the above method is used. ICVij is used as the block check value ICVi as it is, and when there are a plurality of parts with [ICV flag = subject of ICV] indicating that the block is to be checked, a plurality of part check values P− A value obtained by inputting the data obtained by concatenating ICVij in the order of part numbers into the falsification check value generation function (DES-CBC-MAC, using the content check value generation key Kicvc as a key) shown in FIG. Is generated as FIG. 37 shows a configuration example for generating the content check value ICVi of the content block.
[0272]
In format types 2 and 3, the block check value ICVi is not defined.
[0273]
The check value B: ICVb is a check value for the block information key, the content key, and the entire block information, and is generated by the method described with reference to FIG.
[0274]
The total check value ICVt is a check value for the above-described check value A: ICVa, check value B: ICVb, and the entire check value ICVi included in each block to be checked for content, and will be described with reference to FIG. As described above, the check value A is generated by executing the encryption process by applying the system signature key Ksys to the intermediate check value generated from each check value such as ICVa.
[0275]
In the format types 2 and 3, the total check value ICVt is the above-described check value A: ICVa and check value B: ICVb, which concatenates the entire content data from the block key of block 1 to the final block. It is generated by applying the system signature key Ksys to the intermediate check value generated from the processed data and executing the encryption process. FIG. 38 shows a configuration example for generating the total check value ICVt in the format types 2 and 3.
[0276]
The unique check value ICVdev is a check value that is replaced with the total check value ICVt when the above-described localization flag is set to 1, that is, when the content indicates that the recording / playback device is uniquely usable. Yes, in the case of format types 0 and 1, the check value A: ICVa, the check value B: ICVb, and the check value ICVi included in each block to be checked for content are generated as check values. The Specifically, as described above with reference to FIG. 25 or FIG. 38, the encryption process is performed by applying the recording / reproducing device signature key Kdev to the intermediate check value generated from each check value such as the check value A: ICVa. Generated by executing.
[0277]
Next, content download processing from the recording / reproducing device 300 to the recording device 400 in each of the format types 0 to 3 and reproduction processing from the recording device 400 in the recording / reproducing device 300 will be described with reference to the flowcharts of FIGS.
[0278]
First, content download processing in format types 0 and 1 will be described with reference to FIG.
[0279]
The process shown in FIG. 39 is started by attaching the recording device 400 to the recording / reproducing device 300 shown in FIG. 3, for example. Step S101 is an authentication processing step between the recording / reproducing device and the recording device, and is executed according to the authentication processing flow of FIG. 20 described above.
[0280]
When the authentication process in step S101 is completed and the authentication flag is set, the recording / reproducing device 300, in step S102, reads data according to a predetermined format from the medium 500 storing content data, for example, via the reading unit 304. Or the communication unit 305 is used to receive data from the communication unit 600 according to a predetermined format, and the control unit 301 of the recording / reproducing device 300 records and reproduces the header portion of the data in the recording / reproducing device 300. Is transmitted to the device encryption processing unit 302.
[0281]
Next, in step S103, the control unit 306 of the encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 to calculate the check value A. As shown in FIG. 23, the check value A uses the check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the identification information (Content ID), and the handling policy (Usage Policy). ) As a message according to the ICV calculation method described with reference to FIG. Next, in step S104, the check value A and the check value: ICVa stored in the header (Header) are compared. If they match, the process proceeds to step S105.
[0282]
As described above, the check values A and ICVa are check values for verifying falsification of identification information and handling policy. The check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption unit 302 is used as a key, and the identification information (Content ID) and the handling policy (Usage Policy) are used as messages, for example, according to the ICV calculation method When the check value A matches the check value: ICVa stored in the header (Header), it is determined that the identification information and the handling policy are not falsified.
[0283]
Next, in step S105, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to extract or generate the delivery key Kdis. The method of generating the delivery key Kdis is performed using the delivery key master key MKdis, for example, as in step S53 of FIG. 22 described above.
[0284]
In step S106, the control unit 306 of the recording / reproducing device encryption processing unit 302 uses the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to use the generated distribution key Kdis to change the reading unit 304. The block information key Kbit and the content key Kcon stored in the header portion of the data received from the communication unit 600 via the media 500 or the communication unit 305 are decrypted.
[0285]
In step S107, the control unit 306 of the recording / reproducing device encryption processing unit 302 decrypts the block information with the decrypted block information key Kbit in the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302.
[0286]
Further, in step S108, the control unit 306 of the recording / reproducing device encryption processing unit 302 generates a check value B (ICVb ') from the block information key Kbit, the content key Kcon, and the block information (BIT). As shown in FIG. 24, the check value B uses the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the block information key Kbit, the content key Kcon, and the block information ( BIT) is generated by encrypting an exclusive OR value with DES. Next, in step S109, the check value B is compared with the ICVb in the header (Header), and if they match, the process proceeds to step S110.
[0287]
As described above, the check values B and ICVb are check values for verifying falsification of the block information key Kbit, the content key Kcon, and the block information. Using the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the block information key Kbit, the content key Kcon, and the block information (BIT) are divided into units of 8 bytes, and the exclusive logic If the check value B generated by encrypting the sum obtained with DES matches the check value ICVb stored in the header (Header), the block information key Kbit, the content key Kcon, and the block information It is judged that there is no tampering.
[0288]
In step S110, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate an intermediate check value. As shown in FIG. 25, the intermediate check values are the total check value generation key Kicvt stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302, and the check value A and check value B in the verified header. Then, all the stored content check values are calculated as messages according to the ICV calculation method described in FIG. The generated intermediate check value is stored in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 as necessary.
[0289]
Next, in step S111, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the total check value ICVt '. As shown in FIG. 25, the total check value ICVt ′ is generated by encrypting the intermediate check value with DES using the system signature key Ksys stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Next, in step S112, the generated total check value ICVt 'is compared with the ICVt in the header (Header), and if they match, the process proceeds to step S113.
[0290]
As described above with reference to FIG. 4, the total check value ICVt is a check value for verifying falsification of all the check values of ICVa, ICVb, and each content block. Therefore, if the total check value generated by the above processing matches the check value: ICVt stored in the header (Header), it is determined that there is no falsification of all check values of ICVa, ICVb, and each content block. Is done.
[0291]
Next, in step S113, the control unit 301 of the recording / reproducing device 300 takes out the content block information in the block information (BIT) and checks whether the content block is a verification target. When the content block is a verification target, the content check value is stored in the block information in the header.
[0292]
If the content block is to be verified, in step S114, the corresponding content block is read from the medium 500 using the reading unit 304 of the recording / reproducing device 300, or the communication unit 305 of the recording / reproducing device 300 is used. The data is received from the communication unit 600 and transmitted to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. Receiving this, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the content check value ICVi ′.
[0293]
The content check value ICVi ′, when the block is encrypted as described above, decrypts the input content block in the DES CBC mode with the content key Kcon, and excludes the result in units of 8 bytes. The content intermediate value generated by performing logical OR is encrypted with the content check value generation key Kicvc stored in the internal memory 307 of the recording / reproducing device 300 and generated. If the block is not encrypted, the entire data (plain text) is converted into a falsification check value generation function (DES-CBC-MAC, using the content check value generation key Kicvc as a key) shown in FIG. 36 in units of 8 bytes. It is generated as a value obtained by input.
[0294]
In step S115, the control unit 306 of the recording / reproducing device encryption processing unit 302 compares the content check value with the ICV in the content block received from the control unit 301 of the recording / reproducing device 300 in step S102. Is transferred to the control unit 301 of the recording / reproducing device 300. The control unit 301 of the recording / reproducing device 300 that has received the information retrieves the next verification target content block and causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to verify the content block when all the contents are verified. The same verification process is repeated until the block is verified (step S116).
[0295]
Note that if any of the check values does not match in any of step S104, step S109, step S112, and step S115, the download process ends as an error.
[0296]
Next, in step S117, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 uses the block information key Kbit and the content key Kcon decrypted in step S106 as the encryption / decryption unit of the recording / reproducing device encryption processing unit 302. In 308, encryption is performed using the session key Kses shared during mutual authentication. The control unit 301 of the recording / reproducing device 300 reads the block information key Kbit and the content key Kcon encrypted with the session key Kses from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and these data are recorded on the recording / reproducing device 300. To the recording device 400 via the recording device controller 303.
[0297]
In step S118, the recording device 400 that has received the block information key Kbit and the content key Kcon transmitted from the recording / reproducing device 300 sends the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401. Decrypted with the session key Kses shared at the time of mutual authentication, re-encrypted with the storage key Kstr specific to the recording device stored in the internal memory 405 of the recording device encryption processing unit 401, and recorded / reproduced The control unit 301 of 300 reads out the block information key Kbit and the content key Kcon re-encrypted with the storage key Kstr from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300. That is, the block information key Kbit encrypted with the delivery key Kdis and the content key Kcon are exchanged.
[0298]
Next, in step S119, the control unit 301 of the recording / reproducing device 300 extracts usage restriction information from the handling policy (Usage Policy) of the header portion of the data, and whether or not the downloaded content can be used only by the recording / reproducing device 300. Judgment is made. In this determination, when the localization flag (usage restriction information) = 1 is set, the downloaded content can be used only by the recording / reproducing device 300, and the localization flag (usage restriction information) = 0 is set. Indicates that the downloaded content can be used by another similar recording / reproducing device 300. As a result of the determination, if the localization flag (usage restriction information) = 1, the process proceeds to step S120.
[0299]
In step S120, the control unit 301 of the recording / reproducing device 300 causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to calculate a check value specific to the recording / reproducing device. As shown in FIG. 25, the check value unique to the recording / reproducing device uses the recording / reproducing device signature key Kdev unique to the recording / reproducing device stored in the internal memory 307 of the recording / reproducing device encryption unit 302 as a key. The generated intermediate check value is encrypted with DES. The calculated check value ICVdev specific to the recording / reproducing device is overwritten instead of the total check value ICVt.
[0300]
As described above, the system signature key Ksys is a system signature key used for attaching a common signature or ICV to the distribution system, and the recording / reproducing device signature key Kdev is different for each recording / reproducing device, This is a recording / reproducing device signature key used by the recording / reproducing device to attach a signature or ICV. That is, the data signed by the system signature key Ksys is successfully checked by a system (recording / reproducing device) having the same system signature key, that is, the total check value ICVt matches, so that it can be used in common. When the recording / reproducing device signature key Kdev is used for signing, since the recording / reproducing device signature key is a key unique to the recording / reproducing device, the data signed using the recording / reproducing device signature key Kdev, that is, The data stored in the recording device after the signature is reproduced because the check value ICVdev peculiar to the recording / reproducing device becomes inconsistent and an error occurs when attempting to reproduce the recording device on another recording / reproducing device. It will not be possible. In the data processing apparatus of the present invention, contents that can be used in common in the system and contents that can be used unique to the recording / reproducing device can be freely set by setting use restriction information.
[0301]
Next, in step S121, the control unit 301 of the recording / reproducing device 300 causes the recording / reproducing device encryption processing unit 302 to form a storage data format. As described above, the format type has each type from 0 to 3, and is set in the handling policy (see FIG. 5) in the header. According to this setting type, the right side of FIGS. 32 to 35 described above. The data is formed according to the storage format. Since the flow shown in FIG. 39 is in one of formats 0 and 1, it is formed in one of the formats in FIGS.
[0302]
When the formation of the storage data format is completed in step S121, the control unit 301 of the recording / reproducing device 300 stores the content in the external memory 402 of the recording device 400 in step 122.
[0303]
The above is the aspect of the content data download process in the format types 0 and 1.
[0304]
Next, content data download processing in format type 2 will be described with reference to FIG. The description will focus on the differences from the download processing of the format types 0 and 1 described above.
[0305]
Steps S101 to S109 are the same as the download processing of the format types 0 and 1 described above, and thus description thereof is omitted.
[0306]
As described above, since the content check value ICVi is not defined for the format type 2, the block information does not have the content check value ICVi. As shown in FIG. 38, the intermediate check value in format type 2 is data obtained by concatenating check value A, check value B, and the entire content data from the first data of the first block (block key of block 1) to the last block. It is generated by applying the system signature key Ksys to the intermediate check value generated based on the encryption process.
[0307]
Accordingly, in the format type 2 download process, the content data is read out in step S151, and in step S152, the intermediate check value is generated based on the check value A and the check value B and the read content data. Even when the content data is encrypted, the decryption process is not performed.
[0308]
Format type 2 does not perform block data decoding or content check value inquiry processing unlike the processing in format types 0 and 1 described above, so that rapid processing is possible.
[0309]
Since the processing after step S111 is the same as the processing in the format types 0 and 1, description thereof will be omitted.
[0310]
The above is the aspect of the content data download process in format type 2. As described above, the format type 2 download process does not perform block data decryption and content check value inquiry processing unlike the format type 0 and 1 processes. This format is suitable for data processing that requires processing.
[0311]
Next, content data download processing in format type 3 will be described with reference to FIG. The description will focus on the differences from the download processing of format types 0, 1, and 2 described above.
[0312]
Steps S101 to S105 are the same as the download processing of the format types 0, 1, and 2 described above, and thus description thereof is omitted.
[0313]
Format type 3 basically has many parts in common with processing in format type 2, but format type 3 does not have a content key, and block key Kblc is encrypted with storage key Kstr in the recording device. Is different from format type 2.
[0314]
Description will be made centering on differences from the format type 2 in the format type 3 download process. In format type 3, the block information key is decrypted in step S161, which is the next step of step S105. The control unit 306 of the recording / reproducing device encryption processing unit 302 uses the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 to receive the distribution key Kdis generated in step S105 via the reading unit 304. The block information key Kbit stored in the header portion of the data received from the communication unit 600 via the communication medium 500 or the communication unit 305 is decrypted. In format type 3, since the content key Kcon does not exist in the data, the decryption process of the content key Kcon is not executed.
[0315]
In the next step S107, the block information is decrypted using the block information key Kbit decrypted in step S161. Further, in step S162, the control unit 306 of the recording / reproducing device encryption processing unit 302 performs the block information key Kbit, The check value B (ICVb ′) is generated from the block information (BIT). The check value B is an exclusive OR value composed of the block information key Kbit and the block information (BIT) using the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Generated by encrypting with DES. Next, in step S109, the check value B is compared with ICVb in the header (Header), and if they match, the process proceeds to step S151.
[0316]
In format type 3, the check values B and ICVb function as a block information key Kbit and a check value for verifying falsification of the block information. If the generated check value B matches the check value: ICVb stored in the header (Header), it is determined that the block information key Kbit and the block information are not falsified.
[0317]
Steps S151 to S112 are the same as the processing of the format type 2, and will not be described.
[0318]
In step S163, the block key Kblc included in the content data read in step S151 is decrypted with the delivery key Kdis generated in step S105.
[0319]
In step S164, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 uses the block information key Kbit decrypted in step S161 and the block key Kblc decrypted in step S163 to The encryption / decryption unit 308 is encrypted with the session key Kses shared at the time of mutual authentication. The control unit 301 of the recording / reproducing device 300 reads the block information key Kbit and the block key Kblc encrypted with the session key Kses from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and these data are recorded on the recording / reproducing device 300. To the recording device 400 via the recording device controller 303.
[0320]
Next, in step S165, the recording device 400 that has received the block information key Kbit and the block key Kblc transmitted from the recording / reproducing device 300 sends the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401. , Decrypted with the session key Kses shared at the time of mutual authentication, re-encrypted with the storage key Kstr unique to the recording device stored in the internal memory 405 of the recording device encryption processing unit 401, and recorded / reproduced The control unit 301 of 300 reads out the block information key Kbit and the block key Kblc re-encrypted with the storage key Kstr from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300. That is, the block information key Kbit and the block key Kblc encrypted with the delivery key Kdis are replaced with the block information key Kbit and the block key Kblc re-encrypted with the storage key Kstr.
[0321]
The following steps S119 to S122 are the same as the format types 0, 1, and 2 described above, and thus description thereof is omitted.
[0322]
The above is the aspect of the content data download process in the format type 3. As described above, the format type 3 download process, like the format type 2, does not perform block data decoding or content check value inquiry processing, thus enabling rapid processing and requiring real-time processing such as music data. It is a format suitable for data processing. Further, since the range for protecting the encrypted content with the block key Kblc is localized, the security is higher than that of the format type 2.
[0323]
Next, reproduction processing from the recording device 400 in the recording / reproducing device 300 in each of the format types 0 to 3 will be described with reference to the flows in FIGS.
[0324]
First, content reproduction processing in format type 0 will be described with reference to FIG.
[0325]
Step S201 is an authentication processing step between the recording / reproducing device and the recording device, and is executed according to the authentication processing flow of FIG. 20 described above.
[0326]
When the authentication process in step S201 is completed and the authentication flag is set, the recording / reproducing device 300 reads out the header of the data according to a predetermined format from the recording device 400 in step S202, and the recording / reproducing device 300 performs recording / reproduction. Is transmitted to the device encryption processing unit 302.
[0327]
Next, in step S203, the control unit 306 of the encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 to calculate the check value A. As shown in FIG. 23 described above, the check value A uses the check value A generation key Kicva stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key and is handled as identification information (Content ID). The policy is calculated as a message. Next, in step S204, the calculated check value A is compared with the check value: ICVa stored in the header (Header). If they match, the process proceeds to step S205.
[0328]
Check values A and ICVa are check values for verifying falsification of identification information and handling policy. When the calculated check value A matches the check value ICVa stored in the header, it is determined that the identification information stored in the recording device 400 and the handling policy are not falsified.
[0329]
Next, in step S205, the control unit 301 of the recording / reproducing device 300 extracts the block information key Kbit and the content key Kcon encrypted with the storage key Kstr specific to the recording device from the read header, and the recording / reproducing device 300 records it. The data is transmitted to the recording device 400 via the device controller 303.
[0330]
The recording device 400 that has received the block information key Kbit and the content key Kcon transmitted from the recording / reproducing device 300 sends the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401 and the recording device encryption processing unit 401. Is decrypted with the storage key Kstr unique to the recording device stored in the internal memory 405, and encrypted again with the session key Kses shared during mutual authentication. This process is as described in detail in the section of (9) Key exchange process after mutual authentication described above.
[0331]
In step S206, the control unit 301 of the recording / reproducing device 300 receives the block information key Kbit and the content key Kcon re-encrypted with the session key Kses from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300. .
[0332]
Next, in step S207, the control unit 301 of the recording / reproducing device 300 sends the block information key Kbit and content key Kcon re-encrypted with the received session key Kses to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300. The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 that has transmitted and received the block information key Kbit and the content key Kcon re-encrypted with the session key Kses is an encryption / decryption unit of the recording / reproducing device encryption processing unit 302. In 308, the block information key Kbit and the content key Kcon encrypted with the session key Kses are decrypted with the session key Kses shared at the time of mutual authentication.
[0333]
Further, in step S208, the block information read in step S202 is decrypted with the decrypted block information key Kbit. The recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 receives the decrypted block information key Kbit, content key Kcon, and block information BIT in the block information key Kbit and content key Kcon included in the header read in step S202. The block information BIT is replaced and held. The control unit 301 of the recording / reproducing device 300 reads the decrypted block information BIT from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300.
[0334]
In step S209, the control unit 306 of the recording / reproducing device encryption processing unit 302 generates a check value B (ICVb ′) from the block information key Kbit, the content key Kcon, and the block information (BIT). As shown in FIG. 24, the check value B uses the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, the block information key Kbit, the content key Kcon, and the block information ( BIT) is generated by encrypting an exclusive OR value with DES. Next, in step S210, the check value B is compared with ICVb in the header (Header), and if they match, the process proceeds to step S211.
[0335]
The check values B and ICVb are check values for verifying falsification of the block information key Kbit, the content key Kcon, and the block information, and the generated check value B is a check value stored in the header (Header): ICVb If it matches, it is determined that the block information key Kbit, the content key Kcon, and the block information in the data stored in the recording device 400 are not falsified.
[0336]
In step S211, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate an intermediate check value. As shown in FIG. 25, the intermediate check values are the total check value generation key Kicvt stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302, and the check value A and check value B in the verified header. Then, all content check values in the block information are calculated as messages according to the ICV calculation method described in FIG. The generated intermediate check value is stored in the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 as necessary.
[0337]
Next, in step S212, the control unit 301 of the recording / reproducing device 300 extracts the usage restriction information from the usage policy included in the header portion of the data read from the external memory 402 of the recording device 400, and plans to reproduce it. It is determined whether the content can be used only by the recording / reproducing device 300 (usage restriction information is 1) or can be used by another similar recording / reproducing device 300 (usage restriction information is 0). As a result of the determination, if the usage restriction information is 1, that is, the usage restriction that the playback content can be used only by the recording / reproducing device 300 is set, the process proceeds to step S213, and the usage restriction information is 0, that is, another similar one. If the setting can also be used by the recording / reproducing device 300, the process proceeds to step S215. Note that the encryption processing unit 302 may perform the processing in step S212.
[0338]
In step S213, the control unit 301 of the recording / reproducing device 300 causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to calculate a check value ICVdev ′ unique to the recording / reproducing device. The check value ICVdev ′ unique to the recording / reproducing device is held in step S211 using the recording / reproducing device signature key Kdev stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key, as shown in FIG. The generated intermediate check value is encrypted with DES.
[0339]
Next, in step S214, the recording / reproducing device specific check value ICVdev 'calculated in step S213 is compared with the ICVdev in the header read in step S202. If they match, the process proceeds to step S217.
[0340]
On the other hand, in step S215, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the total check value ICVt. As shown in FIG. 25, the total check value ICVt ′ is generated by encrypting the intermediate check value with DES using the system signature key Ksys stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Next, in step S216, the generated total check value ICVt 'is compared with the ICVt in the header (Header), and if they match, the process proceeds to step S217.
[0341]
The total check value ICVt and the check value ICVdev peculiar to the recording / reproducing device are check values for verifying falsification of all the check values of ICVa, ICVb, and each content block. Therefore, when the check value generated by the above processing matches the check value: ICVt or ICVdev stored in the header (Header), the ICVa and ICVb stored in the recording device 400 and the check of each content block are checked. It is determined that all values have not been tampered with.
[0342]
Next, in step S217, the control unit 301 of the recording / reproducing device 300 reads block data from the recording device 400. Further, in step S218, it is determined whether or not the data is encrypted. If the data is encrypted, the encryption processing unit 302 of the recording / reproducing device 300 decrypts the block data. If not encrypted, the process skips step S219 and proceeds to step S220.
[0343]
Next, in step S220, the control unit 301 of the recording / reproducing device 300 checks whether the content block is a verification target based on the content block information in the block information (BIT). When the content block is a verification target, the content check value is stored in the block information in the header. If the content block is to be verified, the content check value ICVi 'of the corresponding content block is calculated in step S221. If the content block is not a verification target, steps S221 and S222 are skipped and the process proceeds to step S223.
[0344]
When the block is encrypted as described above with reference to FIG. 36, the content check value ICVi ′ is decrypted with the content key Kcon in the DES CBC mode, and the result is all 8 bytes. The content intermediate value generated by exclusive ORing in units is encrypted by the content check value generation key Kicvc stored in the internal memory 307 of the recording / reproducing device 300 and generated. If the block is not encrypted, the entire data (plain text) is converted into a falsification check value generation function (DES-CBC-MAC, using the content check value generation key Kicvc as a key) shown in FIG. 36 in units of 8 bytes. It is generated as a value obtained by input.
[0345]
In step S222, the control unit 306 of the recording / reproducing device encryption processing unit 302 compares the generated content check value ICVi ′ with the content check value ICVi stored in the header part received from the recording device 400 in step S202. The result is passed to the control unit 301 of the recording / reproducing device 300. The control unit 301 of the recording / reproducing device 300 that has received the information stores the execution (reproduction) content plaintext data in the recording / reproducing device system RAM in step S223 if the verification is successful. The control unit 301 of the recording / reproducing device 300 further extracts the next verification target content block, causes the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 to verify, and performs the same verification process until all content blocks are verified. The storage process is repeated (step S224).
[0346]
Note that if any of the check values does not match in any of step S204, step S210, step S214, step S216, and step S222, the reproduction process ends as an error.
[0347]
If it is determined in step S224 that all blocks are to be read, the process proceeds to step S225, where execution (playback) of content (program, data) is started.
[0348]
The above is the aspect of the content data reproduction process in the format type 0.
[0349]
Next, content data playback processing in format type 1 will be described with reference to FIG. The description will focus on the differences from the format type 0 playback process described above.
[0350]
Since the processing from step S201 to step S217 is the same as the above-described format type 0 reproduction processing, description thereof will be omitted.
[0351]
In format type 1, in step S231, decryption of the encrypted part is executed, and a part ICV is generated. Further, in step S232, a block ICVi 'is generated. As described above, in format type 1, when at least one of the parts in the block is the target data of the check value ICVi, the content check value ICVi is defined for the block. The check value P-ICVij of the part j in the block i is obtained by encrypting a value obtained by exclusive ORing the entire plaintext (decrypted text) in units of 8 bytes when the part j is encrypted. Generated as a value. If the part j is not encrypted, the falsification check value generation function (DES-CBC-MAC, content check value generation key Kicvc as a key) shown in FIG. It is generated as a value obtained by inputting to.
[0352]
Furthermore, when there is only one part [ICV flag = subject of ICV] indicating that it is a check target in one block i, the check value P-ICVij generated by the above-described method is directly used as the block. When there are a plurality of parts having the check value ICVi and [ICV flag = subject of ICV] indicating a check target in one block i, the plurality of part check values P-ICVi, j are set to the part. For the data concatenated in numerical order, the entire data (plain text) is input to the falsification check value generation function (DES-CBC-MAC, content check value generation key Kicvc as a key) shown in FIG. 36 in units of 8 bytes. It is generated as the obtained value. This is as described above with reference to FIG.
[0353]
In the format type 1, the comparison process of the content check value generated by the above procedure is executed in step S222. Since the processing after the step S223 is the same as that of the format type 0, the description is omitted.
[0354]
Next, content data playback processing in format type 2 will be described with reference to FIG. The description will focus on the differences from the above-described playback processing of format types 0 and 1.
[0355]
Steps S201 to S210 are the same as the reproduction processing of the format types 0 and 1 described above, and a description thereof will be omitted.
[0356]
In format type 2, the processes of steps S211 to S216 executed in format types 0 and 1 are not executed. Further, since the format type 2 has no content check value, the verification of the content check value in step S222 executed in the format types 0 and 1 is not executed.
[0357]
In the format type 2 data reproduction process, after the check value B verification step in step S210, the process proceeds to step S217, and block data is read out under the control of the control unit 301 of the recording / reproducing device 300. Further, in step S241, the encryption processing unit 306 of the recording / reproducing device 300 performs a decryption process of the block key Kblc included in the block data. The block key Kblc stored in the recording device 400 is encrypted with the content key Kcon as shown in FIG. 34, and the block key Kblc is decrypted using the content key Kcon decrypted in the previous step S207.
[0358]
Next, in step S242, block data decryption processing is executed using the block key Kblc decrypted in step S241. Further, in step S243, content (program, data) execution and playback processing are executed. The processing from step S217 to step S243 is repeatedly executed for all blocks. If it is determined in step S244 that all blocks are read, the reproduction process ends.
[0359]
As described above, the format type 2 process omits the check value verification process such as the total check value, and is suitable for executing a high-speed decoding process, and is a data process that requires real-time processing such as music data. It is a format suitable for.
[0360]
Next, content data playback processing in format type 3 will be described with reference to FIG. The description will focus on the differences from the above-described playback processing of format types 0, 1, and 2.
[0361]
Format type 3 basically has many parts in common with processing in format type 2, but format type 3 does not have a content key as described in FIG. 35, and block key Kblc is not used in the recording device. It differs from the format type 2 in that it is encrypted and stored with the storage key Kstr.
[0362]
In steps S201 to S210, the processes in steps S251, S252, S253, and S254 are configured as processes that do not include a content key, unlike the corresponding processes in the format types 0, 1, and 2 described above.
[0363]
In step S251, the control unit 301 of the recording / reproducing device 300 extracts the block information key Kbit encrypted with the storage key Kstr specific to the recording device from the read header, and records it via the recording device controller 303 of the recording / reproducing device 300. To device 400.
[0364]
The recording device 400 that has received the block information key Kbit transmitted from the recording / reproducing device 300 sends the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401 and the internal memory 405 of the recording device encryption processing unit 401. Is decrypted with the storage key Kstr unique to the recording device stored in the server and re-encrypted with the session key Kses shared during mutual authentication. This process is as described in detail in the section of (9) Key exchange process after mutual authentication described above.
[0365]
In step S252, the control unit 301 of the recording / reproducing device 300 receives the block information key Kbit re-encrypted with the session key Kses from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300.
[0366]
Next, in step S253, the control unit 301 of the recording / reproducing device 300 transmits the block information key Kbit re-encrypted with the received session key Kses to the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and the session Upon receiving the block information key Kbit re-encrypted with the key Kses, the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 encrypts the encryption / decryption unit 308 of the recording / reproducing device encryption processing unit 302 with the session key Kses. The encrypted block information key Kbit is decrypted with the session key Kses shared at the time of mutual authentication.
[0367]
Further, in step S208, the block information read in step S202 is decrypted with the decrypted block information key Kbit. Note that the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300 replaces the decrypted block information key Kbit and block information BIT with the block information key Kbit and block information BIT included in the header read out in step S202 and holds them. Keep it. The control unit 301 of the recording / reproducing device 300 reads the decrypted block information BIT from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300.
[0368]
Further, in step S254, the control unit 306 of the recording / reproducing device encryption processing unit 302 generates a check value B (ICVb ′) from the block information key Kbit and the block information (BIT). As shown in FIG. 24, the check value B includes a block value key Kbit and block information (BIT) using the check value B generation key Kicvb stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. The exclusive OR value is generated by encrypting with DES. Next, in step S210, the check value B is compared with ICVb in the header (Header), and if they match, the process proceeds to step S211.
[0369]
In format type 3, since the block key is encrypted with the storage key when stored in the recording device, decryption processing with the storage key in the recording device 400, encryption processing with the session key, and recording / reproducing device Decryption processing with the session key at 300 is required. These series of processes are the process steps shown in steps S255 and S256.
[0370]
In step S255, the control unit 301 of the recording / reproducing device 300 extracts the block key Kblc encrypted with the storage device-specific storage key Kstr from the block read in step S217, and the recording device controller 303 of the recording / reproducing device 300 passes through the recording device controller 303. To the recording device 400.
[0371]
The recording device 400 that has received the block key Kblc transmitted from the recording / reproducing device 300 transmits the received data to the encryption / decryption unit 406 of the recording device encryption processing unit 401 and to the internal memory 405 of the recording device encryption processing unit 401. Decryption is performed with the stored storage key Kstr unique to the recording device, and re-encryption is performed with the session key Kses shared at the time of mutual authentication. This processing is as described in detail in the section of “(9) Key exchange processing after mutual authentication” described above.
[0372]
In step S256, the control unit 301 of the recording / reproducing device 300 receives the block key Kblc re-encrypted with the session key Kses from the recording device 400 via the recording device controller 303 of the recording / reproducing device 300.
[0373]
Next, in step S257, decryption processing using the session key Kses of the block key Kblc by the encryption processing unit 306 of the recording / reproducing device 300 is executed.
[0374]
Next, in step S242, block data decryption processing is executed using the block key Kblc decrypted in step S257. Further, in step S243, content (program, data) execution and playback processing are executed. The processing from step S217 to step S243 is repeatedly executed for all blocks. If it is determined in step S244 that all blocks are read, the reproduction process ends.
[0375]
The above processing is content reproduction processing in format type 3. Similar to the format type 2 in that the verification process of the total check value is omitted, but the processing configuration has a higher security level than the format type 2 in that the key exchange process of the block key is included. .
[0376]
(11) Check value (ICV) generation process in content provider
In the above-described embodiments, it has been described that the verification processing for various check values ICV is executed at the stage of content download or playback processing. Here, modes of each check value (ICV) generation process and verification process will be described.
[0377]
First, the check values ICV used in the data processing apparatus of the present invention are as follows.
[0378]
Check value A, ICVa: Check value for verifying falsification of identification information and handling policy in content data.
Check value B, ICVb: Check value for verifying block information key Kbit, content key Kcon, and block information tampering.
Content check value ICVi: a check value for verifying tampering of each content block of the content.
Total check value ICVt: Check value ICVa, check value ICVb, and a check value for verifying tampering of all check values of each content block.
Player-specific check value ICVdev: This is a check value that is replaced with the total check value ICVt when the localization flag is set to 1, that is, when the content indicates that it is available for recording and playback devices. The check value A: ICVa, the check value B: ICVb, and the check value ICVi included in each block to be checked for content are generated as check values.
Depending on the format, what is to be checked by ICVt and ICVdev may be the content itself, not the check value of each content block.
[0379]
Each of the above check values is used in the data processing apparatus of the present invention. Among the above check values, the check value A, the check value B, the total check value, and the content check value are, for example, a content provider that provides content data or content management as shown in FIGS. 32 to 35 and FIG. An ICV value is generated by each person based on the data to be verified, stored in the data together with the content, and provided to the user of the recording / reproducing device 300. When the user of the recording / reproducing device, that is, the content user downloads or reproduces the content to the recording device, the ICV for verification is generated based on the data to be verified, and the stored ICV Compare. Further, the player-specific check value ICVdev is stored in the recording device in place of the total check value ICVt when the content indicates that the content can be used unique to the recorder / player.
[0380]
In the above-described embodiment, the check value generation processing has been mainly described with reference to the generation processing configuration by DES-CBC. However, the ICV generation processing mode is not limited to the above-described method, but includes various generation processing modes and various verification processing modes. In particular, in the relationship between a content provider or administrator and a content user, various ICV generation and verification processing configurations described below are possible.
[0381]
46 to 48 are diagrams illustrating the generation process of the check value ICV by the creator and the verification process by the verifier.
[0382]
In FIG. 46, the ICV generation processing by DES-CBC described in the above-described embodiment is performed by, for example, an ICV generator that is a content provider or an administrator, and the generated ICV is recorded together with the content, that is, a recording / reproducing user. This configuration is provided to the verifier. In this case, the key required for the verification process by the recording / reproducing device user, that is, the verifier is, for example, each check value generation key stored in the internal memory 307 shown in FIG. A verifier (recording / reproducing device user) who is a content user uses the check value generation key stored in the internal memory 307 to generate a check value by applying DES-CBC to the verification target data. Executes the stored check value and comparison processing. In this case, each check value generation key is configured as a key shared secretly between the ICV generator and the verifier.
[0383]
In FIG. 47, an ICV generator, which is a content provider or an administrator, generates an ICV with a digital signature of a public key cryptosystem, and provides the generated ICV together with the content to a content user, that is, a verifier. The content user, that is, the verifier saves the ICV creator's public key, and executes the ICV verification processing using this public key. In this case, the public key of the ICV generator owned by the content user (recording / reproducing device user), that is, the verifier need not be kept secret, and management becomes easy. This is a mode suitable for the case where ICV generation and management are performed at a high security management level, such as when ICV generation and management are executed in one entity.
[0384]
48, an ICV generator, which is a content provider or administrator, generates an ICV using a digital signature of a public key cryptosystem, and provides the generated ICV together with the content to a content user, that is, a verifier. The public key used for verification by the verifier is stored in a public key certificate (see, for example, FIG. 14) and provided to the recording / reproducing device user, that is, the verifier together with the content data. When there are a plurality of ICV generators, each generator has the key management center create data (public key certificate) that proves the validity of the public key.
[0385]
The content user who is the verifier of the ICV has the public key of the key management center, and the verifier executes the verification of the public key certificate with the public key of the key management center. The ICV creator's public key stored in the certificate is extracted. Furthermore, the ICV verification is executed using the public key of the ICV creator taken out.
[0386]
This method is effective when there are a plurality of ICV creators and a management execution system is established by the center that executes the management.
[0387]
(12) Cryptographic key generation configuration based on master key
Next, the generation configuration of various cryptographic processing keys based on the master key, which is one of the characteristic configurations in the data processing system of the present invention, will be described.
[0388]
As described above with reference to FIG. 18, various master keys are stored in the internal memory of the recording / reproducing device 300 in the data processing apparatus of the present invention. For example, an authentication key Kake is used by using these master keys. Is generated (see Equation 3), or the distribution key Kdis is generated (see Equation 4).
[0389]
Conventionally, encryption communication, mutual authentication, MAC generation, between one-to-one entities, that is, between content providers and content users, or between the recording / reproducing device 300 and the recording medium 400 in the data processing apparatus of the present invention described above, When performing verification or the like, secret information common to each entity, for example, key information, is held. In a one-to-many relationship, for example, a large number of content users for a single content provider, or a large number of recording media for a single recording / playback device, all entities, that is, a large number of content users, or a large number of content users. The secret information shared in the recording media, for example, the key information is stored and held, or one content provider individually manages the secret information (ex. Key) of each of the many content users. Was used according to each content user.
[0390]
However, when there is a one-to-many usage relationship as described above, in the configuration in which all the secret information (ex. Key) is shared, the same secret information (ex. Key) is generated when one secret leak occurs. The disadvantage is that it affects all who use the. In addition, if one administrator, for example, a content provider, individually manages the secret information (ex. Key) of each of many content users and uses it separately according to each content user, all users are There is a disadvantage that a list that identifies and associates unique identification information (ex. Key) with the identification data is necessary, and the burden of list maintenance management increases with the increase of users.
[0390]
In the data processing apparatus of the present invention, such a conventional problem in sharing secret information between entities is solved by holding a master key and generating various individual keys from the master key. Hereinafter, this configuration will be described.
[0392]
In the data processing apparatus of the present invention, when different individual keys are required in various encryption processing, authentication processing, etc. between the recording device and the medium storing the content, or between the recording / reproducing devices, It is generated using individual information such as identifier data (ID) inherent to the device or medium and an individual key generation method determined in advance in the recording / reproducing device 300. Even if the generated individual key is specified by this configuration, damage to the entire system can be prevented by preventing the leakage of the master key. Further, the management of the association list becomes unnecessary due to the configuration in which the key is generated by the master key.
[0393]
A specific configuration example will be described with reference to the drawings. First, FIG. 49 is a diagram illustrating a configuration in which various keys are generated using various master keys included in the recording / reproducing device 300. Content is input from the medium 500 and the communication unit 600 in FIG. 49 as in the embodiment described above. The content is encrypted with the content key Kcon, and the content key Kcon is encrypted with the delivery key Kdis.
[0394]
For example, when the recording / reproducing device 300 takes out the content from the medium 500 and the communication unit 600 and tries to download it to the recording device 400, as described in FIG. 22 and FIGS. It is necessary to acquire the delivery key Kdis that encrypts the content key. The Kdis can be acquired directly from the medium 500 and the communication means 600, or can be acquired in advance by the recording / reproducing device 300 and stored in the memory in the recording / reproducing device 300. As described above, there is a possibility that the distribution configuration for these users may affect the entire system.
[0395]
In the data processing system of the present invention, as shown in the lower part of FIG. 49, the delivery key Kdis is processed based on the delivery key master key MKdis stored in the memory of the recording / reproducing device 300 and the content ID, that is, Kdis = DES. The distribution key Kdis is generated by applying (MKdis, content ID). According to this configuration, even if there are many content providers in the content distribution configuration between the content provider that supplies content from the media 500 and the communication means 600 and the recording / playback device 300 that is the content user, The distribution key Kdis is not required to be distributed via media, communication media, etc., and is not required to be stored in each recording / reproducing device 300, so that security can be maintained at a high level.
[0396]
Next, generation of the authentication key Kake will be described. The recording / reproducing device 300 executes the download processing from the recording / reproducing device 300 in FIGS. 22 and 39 to 41 described above to the recording medium 400 or the content stored in the recording medium 400 described in FIGS. 28 and 42 to 45. When reproducing, mutual authentication processing (see FIG. 20) between the recording / reproducing device 300 and the recording medium 400 is required.
[0397]
As described with reference to FIG. 20, in this authentication process, the recording / reproducing device 300 requires the authentication key Kake. The recording / reproducing device 300 can acquire the authentication key directly from the recording medium 400, for example, or can be acquired in advance by the recording / reproducing device 300 and stored in the memory in the recording / reproducing device 300. Similar to the distribution key configuration, the distribution configuration of such a key to a large number of users can be a leak that affects the entire system.
[0398]
In the data processing system of the present invention, the authentication key Kake is processed based on the authentication key master key MKake stored in the memory of the recording / reproducing device 300 and the recording device identification ID: IDmem, as shown in the lower part of FIG. That is, the authentication key Kake is obtained by Kake = DES (MKake, IDmem).
[0399]
Further, the recording / playback device 300 executes the download processing from the recording / playback device 300 of FIGS. 22 and 39 to 41 to the recording medium 400 or the content stored in the recording media 400 described in FIGS. In this case, the recording / reproducing device signature key Kdev required for the process of generating the recording / reproducing device specific check value ICVdev in the case of content that can be used uniquely for the recording / reproducing device has the same configuration as the above distribution key and authentication key. can do. In the above embodiment, the recording / reproducing device signature key Kdev is stored in the internal memory. However, the recording / reproducing device signing key master key MKdev is stored in the memory, and the recording / reproducing device signing key Kdev is stored in the internal memory. Otherwise, as shown in the lower part of FIG. 49, based on the recording / reproducing identifier: IDdev and the recording / reproducing device signing key master key MKdev, the recording / reproducing device signature key Kdev is represented by Kdev = DES (MKdev, IDdev). In this configuration, there is an advantage that it is not necessary to provide the recording / reproducing device signature key Kdev individually for each device.
[0400]
As described above, in the data processing apparatus of the present invention, information such as a key necessary for a procedure related to cryptographic information processing between two entities such as a provider and a recording / reproducing device or between a recording / reproducing device and a recording device is stored as a master key. Since the ID is generated sequentially from each ID, even if key information is leaked from each entity, the scope of damage due to individual keys is more limited, and the key list for each individual entity as described above is also included. Management is also unnecessary.
[0401]
A plurality of processing examples related to this configuration will be described with reference to a flow. FIG. 50 shows an example of content encryption processing using a master key in content production or an administrator, and decryption processing of encrypted data using a master key in a user device, for example, the recording / reproducing device 300 in the above-described embodiment. is there.
[0402]
Step S501 in the content production or manager is a step of assigning an identifier (content ID) for the content. Step S502 is a step of generating a key for encrypting the content or the like based on the master key and the content ID held by the content production or administrator. For example, if the delivery key Kdis is generated, the delivery key Kdis is generated by the aforementioned Kdis = DES (MKdis, content ID). Next, step S503 is a step of encrypting a part or all of the content with a key (for example, a delivery key Kdis). The content producer distributes the content that has been encrypted through these steps via a medium such as a DVD, communication means, or the like.
[0403]
On the other hand, for example, on the user device side such as the recording / reproducing device 300, in step S504, the content ID is read out from the content data received via the media, the communication means, and the like. Next, in step S505, a key to be applied to decryption of the encrypted content is generated based on the read content ID and the owned master key. If this generation process is to obtain the delivery key Kdis, for example, the delivery key Kdis = DES (MKdis, content ID). In step S506, the content is decrypted using this key, and in step S507, the decrypted content is used, that is, reproduced or programmed.
[0404]
In this example, as shown in the lower part of FIG. 50, both the content production or management and the user device have a master key (for example, a delivery key generation master key MKdis), which is necessary for content encryption and decryption. A delivery key is sequentially generated based on each master key and each ID (content ID).
[0405]
In this system, if the delivery key is leaked to a third party, the content can be decrypted by the third party. However, since it is possible to prevent decryption of other content having a different content ID, 1 There is an effect that the influence of leakage of one content key on the entire system can be minimized. Also, there is an effect that it is not necessary to maintain a key association list for each content on the user device side, that is, the recording / reproducing device.
[0406]
Next, with reference to FIG. 51, an example will be described in which a content producer or administrator owns a plurality of master keys and executes processing according to content distribution targets.
[0407]
Step S511 in the content production or management is a step of assigning an identifier (content ID) to the content. Step S512 is a step of selecting one master key from a plurality of master keys (for example, a plurality of delivery key generation master keys MKdis) possessed by the content production or administrator. This selection process will be further described with reference to FIG. 52. A master key to be applied in advance is set in association with each country, model, or model version of the content user, and executed according to the setting. To do.
[0408]
In step S513, an encryption key is generated based on the master key selected in step S512 and the content ID determined in step S511. For example, if the delivery key Kdisi is generated, it is generated by Kdis = DES (MKdisi, content ID). Next, step S514 is a step of encrypting part or all of the content with a key (for example, a delivery key Kdisi). In step S515, the content producer distributes the content ID, the master key identification information used, and the content encrypted using the encrypted content as one distribution unit via a medium such as a DVD or a communication means. To do.
[0409]
On the other hand, for example, on the user device side such as the recording / reproducing device 300, in step S516, the user device owns the master key corresponding to the master key identification information in the content data distributed via media such as a DVD or communication means. It is determined whether or not. If the master key corresponding to the master key identification information in the content data is not possessed, the distributed content cannot be used in the user device, and the process ends.
[0410]
When the master key corresponding to the master key identification information in the distributed content data is owned by itself, in step S517, the content ID is read out from the content data received via the media, communication means, and the like. Next, in step S518, a key to be applied to the decryption of the encrypted content is generated based on the read content ID and the owned master key. When this generation process is to obtain the delivery key Kdisi, for example, the delivery key Kdisi = DES (MKdisi, content ID). In step S519, the content is decrypted using this key, and in step S520, the decrypted content is used, that is, reproduced or programmed.
[0411]
In this example, as shown in the lower part of FIG. 51, the content creator or administrator has a master key set including a plurality of master keys, for example, a plurality of delivery key generation master keys MKdis1 to MKdis1. On the other hand, only when the user device has one master key, for example, one delivery key generation master key KKdisi, and the content creator or the administrator encrypts the content using MKdisi, the user device only stores the content. It can be decrypted and used.
[0412]
FIG. 52 shows an example in which a different master key is applied for each country as a specific example of the mode shown in the flow of FIG. The content provider has master keys MK1 to MKn, and MK1 is used to generate a key for executing encryption processing of content distributed to a user device for Japan. For example, an encryption key K1 is generated from the content ID and MK1, and the content is encrypted with K1. Further, MK2 is used for key generation for executing encryption processing of content distributed to the user device for US, and MK3 is used for key generation for executing encryption processing of content distributed to the user device for EU (Europe). It is set as follows.
[0413]
On the other hand, a master device MK1 is stored in an internal memory of a user device for Japan, specifically, a recording / playback device such as a PC or a game machine sold in Japan, and a master key MK2 is stored in a user device for US. The master key MK3 is stored in the internal memory of the EU user device.
[0414]
In such a configuration, the content provider executes encryption processing of content to be distributed to the user device using the master key selectively from the master keys MK1 to MKn according to the user device that can use the content. . For example, in order to make the content available only to user devices for Japan, the content is encrypted with the key K1 generated using the master key MK1. This encrypted content can be decrypted using the master key MK1 stored in the user device for Japan, that is, the decryption key can be generated, but the master key MK2 stored in the user device for other US or EU , MK3 cannot obtain the key K1, so that the encrypted content cannot be decrypted.
[0415]
In this way, the content provider can use various master keys selectively to set various content usage restrictions. In FIG. 52, an example in which the master key is distinguished for each country of the user device is shown. However, as described above, various usage forms such as switching the master key according to the model of the user device or according to the version are possible. It is.
[0416]
Next, FIG. 53 shows a processing example in which an identifier unique to media, that is, a media ID and a master key is combined. here. The medium is a medium storing content such as a DVD and a CD. The media ID may be unique for each medium, may be unique for each title of content such as a movie, or may be unique for each production lot of media. As described above, various methods can be used as the media ID assignment method.
[0417]
Step S521 in the media production or manager is a step of determining an identifier (media ID) for the media. Step S522 is a step of generating a key for encrypting the content stored in the media based on the master key and media ID possessed by the media production or administrator. For example, if the delivery key Kdis is generated, the delivery key Kdis is generated by the aforementioned Kdis = DES (MKdis, media ID). Next, step S523 is a step of encrypting part or all of the media storage content with a key (for example, a delivery key Kdis). The media producer supplies the content storage medium that has been encrypted through these steps.
[0418]
On the other hand, on the user device side such as the recording / reproducing device 300, for example, in step S524, the media ID is read from the supplied media. Next, in step S525, a key to be applied to decryption of the encrypted content is generated based on the read media ID and the owned master key. If this generation process is to obtain the delivery key Kdis, for example, the delivery key Kdis = DES (MKdis, media ID). In step S526, the content is decrypted using this key, and in step S527, the decrypted content is used, that is, reproduced or programmed.
[0419]
In this example, as shown in the lower part of FIG. 53, both the media production or administrator and the user device have a master key (for example, a delivery key generation master key MKdis), which is necessary for content encryption and decryption. A delivery key is sequentially generated based on each master key and each ID (media ID).
[0420]
In this system, in the unlikely event that the media key is leaked to a third party, the content in that media can be decrypted by the third party, but the content stored in other media with a different media ID is prevented from being decrypted. Therefore, there is an effect that the influence of leakage of one media key on the entire system can be minimized. Also, there is an effect that it is not necessary to maintain a key association list for each medium on the user device side, that is, the recording / reproducing device. Also, the size of content encrypted with one media key is limited to the capacity that can be stored in the media, so there is little possibility of reaching the amount of information necessary for ciphertext attacks, and decryption is possible Can be reduced.
[0421]
Next, FIG. 54 shows a processing example in which an identifier unique to a recording / reproducing device, that is, a recording / reproducing device ID and a master key are combined.
[0422]
Step S531 in the user of the recording / reproducing device is a step of generating a key for encrypting the content based on the master key and the recording / reproducing device ID stored in the internal memory of the recording / reproducing device. For example, if the content key Kcon is generated, the content key Kcon is generated by Kcon = DES (MKcon, recording / reproducing device ID). Next, step S532 is a step of encrypting a part or all of the content to be stored with a key (for example, a delivery key Kcon). In step S533, the encrypted content is stored in a recording device such as a hard disk.
[0423]
On the other hand, when the system administrator who manages the recording / reproducing device is requested to restore the stored data by the recording / reproducing device user who stores the content, the recording / reproducing device ID is read from the recording / reproducing device in step S534. Next, in step S535, a key to be applied to decryption of the encrypted content is generated based on the read recording / reproducing device ID and the master key owned. When this generation process is to obtain the content key Kcon, for example, the content key Kcon = DES (MKcon, recording / reproducing device ID). In step S536, the content is decrypted using this key.
[0424]
In this example, as shown in the lower part of FIG. 54, both the recording / reproducing device user and the system administrator have a master key (for example, a master key MKcon for content key generation), which is necessary for content encryption and decryption. New delivery keys are sequentially generated based on the respective master keys and IDs (recording / reproducing device IDs).
[0425]
In this system, in the unlikely event that the content key is leaked to a third party, the third party can decrypt the content, but the decryption of the content encrypted for another recording / reproducing device with a different recording / reproducing device ID is possible. Since it can be prevented, the effect of leakage of one content key on the entire system can be minimized. In addition, there is an effect that it is not necessary to maintain a key association list for each content on both the system management side and the user device side.
[0426]
FIG. 55 shows a configuration in which an authentication key used for mutual authentication processing between a recording device such as a memory device such as a memory device and a host device such as a recording / reproducing device is generated based on the master key. In the above-described authentication process (see FIG. 20), the authentication key is stored in advance in the internal memory of the slave device. As shown in FIG. 55, this is generated based on the master key during the authentication process. can do.
[0427]
For example, the slave device that is the recording device is used for the mutual authentication process based on the master key and the slave device ID stored in the internal memory of the slave device that is the recording device in step S541 as an initialization process before the start of the authentication process. An authentication key Kake is generated. This is generated by, for example, Kake = DES (MKake, slave device ID). Next, in step S542, the generated authentication key is stored in the memory.
[0428]
On the other hand, for example, on the host device side such as a recording / reproducing device, in step S543, the slave device ID is read from the attached recording device, that is, the slave device, via the communication means. Next, in step S544, an authentication key to be applied to the mutual authentication process is generated based on the read slave device ID and the owned authentication key generation master key. This generation processing is, for example, authentication key Kake = DES (MKake, slave device ID). In step S545, an authentication process is executed using this authentication key.
[0429]
In this example, as shown in the lower part of FIG. 55, both the slave device and the master device have a master key, that is, an authentication key generation master key MKake. Generated based on the owned master key and slave device ID.
[0430]
In this system, in the unlikely event that the authentication key is leaked to a third party, the authentication key is valid only for that slave device, so authentication is not established in relation to other slave devices. This has the effect of minimizing the influence caused by the leakage of the image.
[0431]
As described above, in the data processing apparatus of the present invention, information such as a key necessary for a procedure related to cryptographic information processing between two entities such as a content provider and a recording / reproducing device or between a recording / reproducing device and a recording device is mastered. It was set as the structure which produces | generates sequentially from a key and each ID. Therefore, even if key information is leaked from each entity, the range of damage caused by individual keys is further limited, and management of the key list for each individual entity as described above becomes unnecessary.
[0432]
(13) Control of cryptographic strength in cryptographic processing
In the above-described embodiment, the encryption process between the recording / reproducing device 300 and the recording device 400 is an example in which the encryption process using the single DES configuration described above with reference to FIG. 7 is mainly used for easy understanding of the description. Have explained. However, the encryption processing method applied in the data processing apparatus of the present invention is not limited to the single DES method described above, and an encryption method according to a required security state can be adopted.
[0433]
For example, a triple DES method such as the configuration of FIGS. 8 to 10 described above may be applied. For example, the encryption processing unit 302 of the recording / reproducing device 300 shown in FIG. 3 and the encryption processing unit 401 of the recording device 400 are configured to execute the triple DES method, and the triple DES method described with reference to FIGS. A configuration for executing processing corresponding to encryption processing is possible.
[0434]
However, the content provider may give the content key Kcon a 64-bit key configuration based on the single DES method by giving priority to the processing speed according to the content, and the content key Kcon is given the triple DES method by giving priority to security. In some cases, a 128-bit or 192-bit key configuration is used. Therefore, it is not preferable to configure the encryption processing unit 302 of the recording / reproducing device 300 and the encryption processing unit 401 of the recording device 400 to be compatible with only one of the triple DES method and the single DES method. Therefore, it is desirable that the encryption processing unit 302 of the recording / reproducing device 300 and the encryption processing unit 401 of the recording device 400 be compatible with both single DES and triple DES systems.
[0435]
However, in order to make the cryptographic processing configurations of the cryptographic processing unit 302 of the recording / reproducing device 300 and the cryptographic processing unit 401 of the recording device 400 execute both the single DES method and the triple DES method, The circuit and logic must be configured. For example, in order to execute processing corresponding to triple DES in the recording device 400, it is necessary to newly store a triple DES instruction set in the command register shown in FIG. This leads to complication of the processing unit configured in the recording device 400.
[0436]
Therefore, the data processing apparatus of the present invention can execute the processing corresponding to the triple DES encryption processing with the logic of the encryption processing unit 401 on the recording device 400 side having a single DES configuration, and the encrypted data by the triple DES method. A configuration is proposed in which (key, content, etc.) can be stored in the external memory 402 of the recording device.
[0437]
For example, in the example of the data format type 0 shown in FIG. 32, when the content data is downloaded from the recording / reproducing device 300 to the recording device 400, the step of FIG. In S101, an authentication process is executed, and a session key Kses is generated here. Further, in step S117, the encryption processing unit 302 on the recording / reproducing device 300 side performs the encryption process of the content key Kcon using the session key Kses, and the encryption key is transferred to the recording device 400 via the communication unit. In S118, the encryption processing unit 403 of the recording device 400 that has received the encryption key executes the decryption process of the content key Kcon using the session key Kses, and further executes the encryption process of the content key Kcon using the storage key Kstr. This is transmitted to the encryption processing unit 302 of the recording / reproducing device 300, and then the recording / reproducing device 300 forms a data format (step S121) and transmits the formatted data to the recording device 400. The received data is stored in the external memory 402 It has carried out the process of pay.
[0438]
If the encryption processing in the encryption processing unit 401 of the recording device 400 executed between steps S117 and S118 in the above processing is configured to selectively execute either the single DES or triple DES method, the content provider Both can provide content data using the content key Kcon according to triple DES, and can provide content data using the content key Kcon according to single DES.
[0439]
FIG. 56 illustrates a configuration for executing an encryption processing method according to the triple DES method using both the encryption processing unit 302 of the recording / reproducing device 300 and the encryption processing unit 401 of the recording device 400 in the data processing apparatus of the present invention. The flow to do is shown. FIG. 56 shows an example of encryption processing of the content key Kcon using the storage key Kstr executed when downloading the content data from the recording / reproducing device 300 to the recording device 400, and the content key Kcon is based on the triple DES method. An example in the case of a key is shown. Here, the processing example is shown on behalf of the content key Kcon, but the same processing can be performed for other data such as other keys or content.
[0440]
In the triple DES method, as described in FIGS. 8 to 10 above, a single DES has a 64-bit key, and in the triple DES method, a 128-bit or 192-bit key configuration includes two or three keys. The process used. These three content keys are denoted as Kcon1, Kcon2, (Kcon3), respectively. Since Kcon3 may not be used, it is shown in parentheses.
[0441]
The processing of FIG. 56 will be described. Step S301 is a mutual authentication processing step between the recording / reproducing device 300 and the recording device 400. This mutual authentication processing step is executed by the processing of FIG. 20 described above. Note that a session key Kses is generated during this authentication process.
[0442]
When the authentication process in step S301 ends, in step S302, each check value, check value A, check value B, content check value, total check value, and each ICV collation process are executed.
[0443]
When these check value (ICV) verification processes are completed and it is determined that there is no data falsification, the process proceeds to step S303, and the control unit 306 of the recording / reproducing device encryption processing unit 302 in the recording / reproducing device 300 Using the encryption / decryption unit 308 of the encryption processing unit 302, the received media 500 or the data received from the communication unit 600 via the communication unit 305 using the delivery key Kdis previously extracted or generated. The content key Kcon stored in the header part is decrypted. The content key in this case is a key based on the triple DES method, and is the content key Kcon1, Kcon2, (Kcon3).
[0444]
Next, in step S304, the control unit 306 of the recording / reproducing device encryption processing unit 302 uses the content keys Kcon1, Kcon2, (Kcon3) decrypted in step S303 by the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302. Only the content key Kcon1 is encrypted with the session key Kses shared at the time of mutual authentication.
[0445]
The control unit 301 of the recording / reproducing device 300 reads data including the content key Kcon1 encrypted with the session key Kses from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and records these data in the recording / reproducing device 300. The data is transmitted to the recording device 400 via the device controller 303.
[0446]
Next, in step S 305, the recording device 400 that has received the content key Kcon 1 transmitted from the recording / reproducing device 300 sends the received content key Kcon 1 to the encryption / decryption unit 406 of the recording device encryption processing unit 401 for mutual authentication. Decrypt with the session key Kses shared at the time. In step S 306, the data is re-encrypted with the storage device-specific storage key Kstr stored in the internal memory 405 of the recording device encryption processing unit 401 and transmitted to the recording / reproducing device 300 via the communication unit 404.
[0447]
Next, in step S307, the control unit 306 of the recording / reproducing device encryption processing unit 302 uses the content keys Kcon1, Kcon2, (Kcon3) decrypted in step S303 by the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302. Only the content key Kcon2 is encrypted with the session key Kses shared at the time of mutual authentication.
[0448]
The control unit 301 of the recording / reproducing device 300 reads data including the content key Kcon2 encrypted with the session key Kses from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and records these data in the recording / reproducing device 300. The data is transmitted to the recording device 400 via the device controller 303.
[0449]
Next, in step S 308, the recording device 400 that has received the content key Kcon 2 transmitted from the recording / reproducing device 300 sends the received content key Kcon 2 to the encryption / decryption unit 406 of the recording device encryption processing unit 401 for mutual authentication. Decrypt with the session key Kses shared at the time. Further, in step S 309, the data is re-encrypted with the storage device-specific storage key Kstr stored in the internal memory 405 of the recording device encryption processing unit 401, and transmitted to the recording / reproducing device 300 via the communication unit 404.
[0450]
Next, in step S310, the control unit 306 of the recording / reproducing device encryption processing unit 302 uses the content keys Kcon1, Kcon2, (Kcon3) decrypted in step S303 by the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302. ) Is encrypted with the session key Kses shared at the time of mutual authentication.
[0451]
The control unit 301 of the recording / reproducing device 300 reads data including the content key Kcon3 encrypted with the session key Kses from the recording / reproducing device encryption processing unit 302 of the recording / reproducing device 300, and records these data in the recording / reproducing device 300. The data is transmitted to the recording device 400 via the device controller 303.
[0452]
Next, in step S311, the recording device 400 that has received the content key Kcon3 transmitted from the recording / reproducing device 300 transmits the received content key Kcon3 to the encryption / decryption unit 406 of the recording device encryption processing unit 401 for mutual authentication. Decrypt with the session key Kses shared at the time. In step S 312, the data is re-encrypted with the storage device-specific storage key Kstr stored in the internal memory 405 of the recording device encryption processing unit 401, and transmitted to the recording / reproducing device 300 via the communication unit 404.
[0453]
In step S313, the encryption processing unit of the recording / reproducing device forms various data formats described with reference to FIGS.
[0454]
Finally, in step S <b> 314, the recording device 400 stores the received data whose format has been completed in the external memory 402. The format data includes content keys Kcon1, Kcon2, (Kcon3) encrypted with the storage key Kstr.
[0455]
By executing such processing, it is possible to store the content key stored in the recording device 400 as a key based on the triple DES encryption method. If the content key is two keys Kcon1 and Kcon2, the processes in steps S310 to S312 are omitted.
[0456]
In this way, the recording device 400 stores the key to which the triple DES is applied in the memory by repeatedly executing the processing of the same mode, that is, the processing steps of Steps S305 and S306 a plurality of times only by changing the target. It becomes possible. If the content key Kcon is a single DES application key, steps S305 and S306 may be executed, and the formatting process of step S313 may be executed and stored in the memory. In such a configuration, the command for executing the processing of steps S305 and S306 is stored in the command register of FIG. 29 described above, and this processing is performed depending on the content key mode, that is, the triple DES method or the single DES method. What is necessary is just to set it as the structure performed 1-3 times suitably. Therefore, both the triple DES method and the single DES method can be performed without including the triple DES processing method in the processing logic of the recording device 400. The encryption method can be determined by recording it in the handling policy in the header part of the content data and referring to it.
[0457]
(14) Program activation processing based on the activation priority in the handling policy for content data
As can be understood from the content data configurations shown in FIGS. 4 to 6 described above, the handling policy stored in the header portion of the content data used in the data processing apparatus of the present invention includes the content type and the activation priority information. Is included. The recording / reproducing device 300 in the data processing apparatus of the present invention includes a recording device 400 or a plurality of accessible content data recorded on various recording media such as a DVD, a CD, a hard disk, and a game cartridge. The content activation order is determined according to the activation priority information.
[0458]
The recording / reproducing device 300 executes the authentication process with each recording device such as a DVD device, a CD drive device, and a hard disk drive device, and then executes the program in the content data with the highest priority according to the priority information in the content data. Execute with priority. Hereinafter, the “program activation process based on the activation priority in the handling policy in the content data” will be described.
[0459]
In the description of the embodiment of the data processing apparatus of the present invention described above, the description has been made focusing on the processing when the recording / reproducing device 300 reproduces and executes content data from one recording device 400. However, in general, the recording / reproducing device 300 includes a recording device 400, a DVD, a CD, a hard disk via a reading unit 304, and a memory card and game cartridge connected via a PIO 111 and SIO 112 as shown in FIG. Etc., and can access various recording media. In FIG. 2, only one reading unit 304 is shown in order to avoid complication of the drawing, but the recording / reproducing device 300 can mount different storage media such as DVD, CD, floppy disk, and hard disk in parallel. It is.
[0460]
The recording / reproducing device 300 can access a plurality of storage media, and each storage medium stores content data. For example, content data supplied by an external content provider such as a CD is stored in a medium with the data structure shown in FIG. 4 described above, and when downloaded via these media or communication means, the contents shown in FIGS. The data structure is stored in each storage medium such as a memory card. More specifically, the data is stored in different formats on the medium and on the recording device as shown in FIGS. 32 to 35 in accordance with the format type of the content data. However, in any case, the handling policy in the header of the content data includes the content type and activation priority information.
[0461]
The content activation processing of the recording / reproducing device when access to a plurality of content data is possible will be described according to the flow.
[0462]
FIG. 57 is a processing flow showing a processing example (1) when there are a plurality of startable contents. Step S611 is a step of executing authentication processing of a recording device accessible by the recording / reproducing device 300. The accessible recording device includes a memory card, a DVD device, a CD drive, a hard disk device, and a game cartridge connected via, for example, the PIO 111 and the SIO 112. The authentication process is executed for each recording device under the control of the control unit 301 shown in FIG. 2, for example, according to the procedure described above with reference to FIG.
[0463]
Next, in step S612, a startable program is detected from the content data stored in the memory in the recording device that has been successfully authenticated. Specifically, this is executed as a process of extracting the content type included in the content data handling policy is a program.
[0464]
Next, in step S613, the boot priority in the bootable program extracted in step S612 is determined. Specifically, this is a process of selecting the highest priority by comparing the priority information included in the handling information in the headers of the plurality of startable content data selected in step S612.
[0465]
Next, the program selected in step S614 is activated. When the priority order set in a plurality of startable programs is the same, a default priority order is set between the recording devices, and the content program stored in the highest priority device is executed.
[0466]
FIG. 58 shows a processing mode in which identifiers are set for a plurality of recording devices, and authentication processing and content program search are sequentially executed for the recording devices to which the identifiers are attached. 2).
[0467]
In step S621, the authentication process (see FIG. 20) of the recording device (i) attached to the recording / reproducing device 300 is executed. The identifiers 1 to n are sequentially assigned to a plurality (n) of recording devices.
[0468]
In step S622, it is determined whether or not the authentication in step S621 is successful. If the authentication is successful, the process proceeds to step S623 to search for a startable program in the recording medium of the recording device (i). If the authentication is not successful, the process proceeds to step S627, where it is determined whether there is a recording device capable of searching for a new content. If there is no recording device, the process ends. If there is a recording device, the process proceeds to step S628. i is updated, and the authentication processing steps after step S621 are repeated.
[0469]
The process in step S623 is a process for detecting a startable program from the content data stored in the recording device (i). Specifically, this is executed as a process of extracting the content type included in the content data handling policy is a program.
[0470]
In step S624, it is determined whether or not the content type is a program. If it is extracted, the highest priority among the extracted programs is selected in step S625, and the selected program is selected in step S626. Execute.
[0471]
If it is determined in step S624 that the content type is a program, the process proceeds to step S627 to determine the presence or absence of a recording device that is a new content search. If YES in step S628, the flow advances to step S628 to update the recording device identifier i, and repeat the authentication processing steps in and after step S621.
[0472]
FIG. 59 is a process flow showing a process example (3) when there are a plurality of startable contents. Step S651 is a step of executing authentication processing of a recording device accessible by the recording / reproducing device 300. An authentication process for an accessible DVD device, CD drive, hard disk device, memory card, game cartridge, etc. is executed. The authentication process is executed for each recording device under the control of the control unit 301 shown in FIG. 2, for example, according to the procedure described above with reference to FIG.
[0473]
Next, in step S652, a startable program is detected from the content data stored in the memory in the recording device that has been successfully authenticated. Specifically, this is executed as a process of extracting the content type included in the content data handling policy is a program.
[0474]
Next, in step S653, information such as the name of the startable program extracted in step S652 is displayed on the display means. Although the display means is not shown in FIG. 2, the data output as AV output data is output to the display means (not shown). The user-provided information such as the program name of each content data is stored in the identification information of the content data, and each content that has been authenticated via the control unit 301 under the control of the main CPU 106 shown in FIG. Program information such as the program name of the data is output to the output means.
[0475]
In step S654, the main CPU 106 receives a program selection input by the user from the input means such as the input interface, controller, mouse, and keyboard shown in FIG. 2 via the input interface 110, and in accordance with the selection input, in step S655. Execute the user selection program.
[0476]
As described above, in the data processing apparatus of the present invention, the program activation priority information is stored in the handling information in the header of the content data, and the recording / reproducing device 300 activates the program according to this priority, or the activation program is displayed on the display means. Since the configuration is such that the information is displayed and selected by the user, the user does not need to search for the program, and the time required for activation and the user's labor can be saved. In addition, since all startable programs are displayed after the authentication process of the recording device or are displayed as being startable programs, the complexity of processing such as checking the validity after selecting the program is reduced. It will be resolved.
[0477]
(15) Content composition and playback (decompression) processing
In the data processing apparatus of the present invention, as described above, the recording / reproducing device 300 downloads content from the medium 500 or the communication means 600 or performs reproduction processing from the recording device 400. The above description has been centered on the processing of encrypted data associated with content download or playback processing.
[0478]
The control unit 301 in the recording / reproducing device 300 in FIG. 3 includes a device 500 such as a DVD that provides content data, a communication unit 600, a process for downloading content data from the recording device, or an authentication process, an encryption process, and a decryption process. Controls overall processing.
[0479]
The reproducible content obtained as a result of these processes is, for example, audio data, image data, or the like. The decoded data is placed from the control unit 301 under the control of the main CPU shown in FIG. 2, and is output to the AV output unit in accordance with audio data, image data, and the like. However, if the content is, for example, audio data and MP3 compression is performed, the audio data is decoded and output by the MP3 decoder of the AV output unit shown in FIG. If the content data is image data and is an MPEG2 compressed image, the expansion processing is executed by the MPEG2 decoder of the AV processing unit and output. As described above, the data included in the content data may be subjected to compression (encoding) processing, or may be data that has not been subjected to compression processing, and is output after being subjected to processing according to the content.
[0480]
However, there are various types of compression processing and decompression processing programs, and if compressed data is provided from a content provider and there is no corresponding decompression processing execution program, it cannot be reproduced. .
[0481]
Therefore, the data processing apparatus of the present invention stores the compressed data and the decoding (decompression) processing program in the data content together, or the link information between the compressed data and the decoding (decompression) processing program in the content data. The structure stored as header information is disclosed.
[0482]
FIG. 60 is a diagram summarizing elements related to this configuration and related elements from the overall data processing diagram shown in FIG. The recording / reproducing device 300 receives various contents from a device 500 such as a DVD or CD, a communication unit 600, or a recording device 400 such as a memory card storing the contents. These contents are audio data, still images, moving image data, program data, etc., and those that have been subjected to encryption processing, those that have not been subjected to processing, and those that have been subjected to compression processing. Various data are included, such as those that do not exist.
[0483]
When the received content is encrypted, the decryption process is executed by the control of the control unit 301 and the encryption process of the encryption processing unit 302 by the method already described in the above items. Under the control of the main CPU 106, the decrypted data is transferred to the AV processing unit 109 and stored in the memory 3090 of the AV processing unit 109, and then the content analysis unit 3091 performs content structure analysis. For example, if a data decompression program is stored in the content, the program is stored in the program storage unit 3093. If data such as audio data and image data is included, these are stored in the data storage unit 3092. The decompression processing unit 3094 executes decompression processing of the compressed data stored in the data storage unit 3092 using an decompression processing program such as MP3 stored in the program storage unit, and outputs the decompressed data to the speaker 3001 and the monitor 3002. .
[0484]
Next, some examples of the configuration and processing of data received by the AV processing unit 109 via the control unit 301 will be described. Here, audio data is shown as an example of content, and MP3 is applied as an example of a compression program. However, this configuration can be applied not only to audio data but also to image data. In addition, not only MP3 but also various programs such as MPEG2 and 4 can be applied to the compression / decompression processing program.
[0485]
FIG. 61 shows a content configuration example. FIG. 61 shows an example in which music data 6102 compressed by MP3 and an MP3 decoding (decompression) processing program 6101 are combined into one content. These contents are stored as one content in the medium 500 or the recording device 400, or distributed from the communication means 600. If these contents are encrypted as described above, the recording / reproducing device 300 performs decryption processing by the encryption processing unit 303 and then transfers the decrypted processing to the AV processing unit 109.
[0486]
The content analysis unit 3091 of the AV processing unit 109 analyzes the received content and extracts the audio data expansion program (MP3 decoder) unit from the content including the audio data expansion program (MP3 decoder) unit and the compressed audio data unit. The program is stored in the program storage unit 3093, and the compressed audio data is stored in the data storage unit 3092. The content analysis unit 3091 receives information such as content name and content configuration information received separately from the content, or data indicating identification data such as a data name included in the content, data length, data configuration, etc. Content analysis may be performed based on the above. Next, the compression / decompression processing unit 3094 executes the decompression process of the MP3 compressed audio data stored in the data storage unit 3092 according to the audio data decompression program (MP3 decoder) stored in the program storage unit 3093, and the AV processing unit 109 outputs the decompressed audio data to the speaker 3001.
[0487]
FIG. 62 shows a flow showing an example of data reproduction processing having the content configuration shown in FIG. In step S671, the data name stored in the memory 3090 of the AV processing unit 109, for example, if the content is music data, information such as the song name is extracted from the received information separately from the content or the data in the content, and is stored in the monitor 3002. indicate. In step S672, the user's selection is received from various input means such as a switch and a keyboard via the input interface 110, and a reproduction processing command based on the user input data is output to the AV processing unit 109 under the control of the CPU. In step S673, the AV processing unit 109 performs data extraction / decompression processing according to user selection.
[0488]
Next, FIG. 63 shows a configuration example in which one content includes either compressed audio data or an expansion processing program, and further includes content information indicating the content as content header information.
[0489]
As shown in FIG. 63, if the content is a program 6202, the header information 6201 includes content identification information indicating that the program is a program and that the program type is an MP3 decompression program. On the other hand, when the audio data 6204 is included as content, the content information of the header 6203 includes information indicating that the data is MP3 compressed data. This header information is added to the content to be transferred to the AV processing unit 109 by selecting only the information necessary for reproduction from the data included in the handling policy (see FIG. 5) of the content data structure shown in FIG. Can be configured. Specifically, an identification value between the handling policy data required in the encryption processing unit 302 and the data required in the reproduction processing in the AV processing unit 109 is added to each configuration data in the “handling policy” shown in FIG. Then, only those indicating that these identification values are necessary in the AV processing unit 109 can be extracted and used as header information.
[0490]
The content analysis unit 3091 of the AV processing unit 109 that has received each content shown in FIG. 63 stores the program content in the program storage unit 3093 in the case of a program and the data content in the case of data in accordance with the header information. Store in the storage unit 3092. Thereafter, the compression / decompression processing unit 3094 retrieves data from the data storage unit, executes decompression processing according to the MP3 program stored in the program storage unit 3093, and outputs it. When the same program is already stored in the program storage unit 3093, the program storage process may be omitted.
[0491]
FIG. 64 shows a flow showing an example of data reproduction processing having the content configuration shown in FIG. In step S675, the data name stored in the memory 3090 of the AV processing unit 109, for example, if the content is music data, the information such as the song name is extracted from the received information separately from the content or the header in the content, and is sent to the monitor 3002. indicate. In step S676, the user's selection is received from various input means such as a switch and a keyboard via the input interface 110.
[0492]
In step S677, a data reproduction program (for example, MP3) corresponding to the user selection is searched. The program search target preferably has a maximum search range accessible by the recording / reproducing device 300. For example, each medium 500, communication unit 600, recording device 400, and the like shown in FIG.
[0493]
The content passed to the AV processing unit 109 is only the data portion, and the program content may be stored in another recording medium in the recording / reproducing device 300, and is provided from a content provider via media such as DVD and CD. Sometimes it is done. Therefore, the search range is the range where the access to the recording / reproducing apparatus 300 is stored. When a reproduction program is found as a result of the search, a reproduction processing command based on user input data is output to the AV processing unit 109 under the control of the CPU 106. In step S679, the AV processing unit 109 performs data extraction / decompression processing according to user selection. As another example, the program search may be performed before step S675, and in step S675, only the data in which the program is detected may be displayed.
[0494]
Next, FIG. 65 shows a configuration example in which one piece of content includes compressed audio data 6303 and an expansion processing program 6302, and further includes content reproduction priority information as content header information 6301. This is an example in which playback priority information is added as header information to the content structure of FIG. This is the same as the above-mentioned “(14) Program activation process based on activation priority in the handling policy in content data”, and the reproduction order is set based on the reproduction priority set between the contents received by the AV processing unit 109. To decide.
[0495]
FIG. 66 shows a flow showing an example of a reproduction process of data having the content configuration of FIG. In step S681, the data stored in the memory 3090 of the AV processing unit 109, that is, the data information of the reproduction target data is set in the search list. The search list is set using a partial area of the memory in the AV processing unit 109. Next, in step S682, the content analysis unit 3091 of the AV processing unit 109 selects high priority data from the search list, and in step S683, the selected data is reproduced.
[0496]
Next, in FIG. 67, reproduction priority information is added only to the header 6403 of the data content in an example in which one content is a combination of header information and program data 6402 or header information 6403 and compressed data 6404. An example configuration is shown.
[0497]
FIG. 68 shows a flow showing an example of data reproduction processing having the content configuration shown in FIG. In step S691, the data stored in the memory 3090 of the AV processing unit 109, that is, the data information of the reproduction target data is set in the search list. The search list is set using a partial area of the memory in the AV processing unit 109. In step S692, the content analysis unit 3091 of the AV processing unit 109 selects data with high priority from the search list.
[0498]
In step S693, a data reproduction program (for example, MP3) corresponding to the selected data is searched. As for the program search target, it is preferable that the access storage range of the recording / playback apparatus 300 is the maximum search range, as in the processing in the flow of FIG. 64. For example, each medium 500 shown in FIG. The device 400 and the like are also included in the search range.
[0499]
If a reproduction program is found as a result of the search (Yes in step S694), in step S695, the decompressed reproduction process is executed using the program obtained as a result of the search for the selected data.
[0500]
On the other hand, if a program is not detected as a search result (Yes in step S694), the process proceeds to step S696, and reproduction processing using the same program is performed for other data included in the search list set in step S691. Delete what you need. This is because it is clear that even if a reproduction program search is newly performed on the data, it is not detected. In step S697, it is determined whether the search list is empty. If not, the process returns to step S692, and the next higher priority data is extracted and the program search process is executed.
[0501]
As described above, according to this configuration, the compressed content is configured with the decryption (decompression) program, or when the content is only compressed data or only the decompression processing program, Since the content of the header has header information indicating what kind of compressed data the content is or what kind of processing is to be performed, the processing unit (for example, AV processing unit) that has received the content The decompression / reproduction processing is executed using the decompression processing program attached to the file, or the decompression processing program is searched based on the header information of the compressed data, and the decompression / reproduction processing is executed according to the program obtained as a result of the search. This eliminates the need for the user to select and retrieve data decompression programs, reducing the burden on the user. Efficient data playback is possible. Furthermore, according to the configuration having the playback priority information in the header, it is possible to automatically set the playback order, and the operation of setting the playback order by the user can be omitted.
[0502]
In the above-described embodiments, the compressed audio data content and MP3 as the compressed audio data decompression processing program have been described as examples. However, the content includes compressed data and the compressed image data decompression processing program. The present configuration is also applicable in the same manner and has the same effect.
[0503]
(16) Generation of save data, storage in a recording device, and reproduction processing
The data processing apparatus of the present invention interrupts the game program when it is desired to resume the game program after a predetermined time, for example, when the content executed in the recording / reproducing device 300 is a game program or the like. The game state and the like at the time are saved, that is, stored in a recording device, read out at the time of resumption, and the game can be continued.
[0504]
The save data storage configuration in the conventional recording / playback device such as a game machine or personal computer stores the save data in a storage medium such as a memory card, a floppy disk, a game cartridge, or a hard disk that can be built in or attached to the recording / playback device. However, in particular, it does not have a security ensuring configuration for the saved data, and for example, is configured to perform data saving processing with specifications common to the game application program.
[0505]
Therefore, for example, a situation occurs in which save data saved by using one recording / reproducing device A is used or rewritten by another game program, and conventionally, the security of the save data has been hardly considered. This is the actual situation.
[0506]
The data processing apparatus of the present invention provides a configuration that can realize security of such saved data. For example, save data of a certain game program is encrypted and stored in a recording device based on information that can be used only by that game program. Alternatively, it is encrypted based on information unique to the recording / reproducing device and stored in the recording device. By these methods, the use of the save data can be restricted to only a specific device and a specific program, and the security of the save data is ensured. Hereinafter, “save data generation and storage / reproduction processing in a recording device” in the data processing apparatus of the present invention will be described.
[0507]
FIG. 69 is a block diagram for explaining the save data storage process in the data processing apparatus of the present invention. Content is provided to the recording / reproducing device 300 from a medium 500 such as a DVD or CD, or from the communication means 600. The provided content is encrypted with the content key Kcon which is a content-specific key as described above, and the recording / reproducing device 300 performs the above-described download processing from the recording / reproducing device to the recording device. The content key is acquired according to the processing described in the column “see FIG. 22”, the encrypted content is decrypted, and then stored in the recording device 400. Here, the recording / reproducing device 300 decodes the content program from the media and communication means, reproduces and executes it, and after the execution, save data obtained is externally attached, or various recording devices such as a built-in memory card and hard disk A process of storing and reproducing in 400A, 400B, 400C, or downloading content to the recording device 400A, then reproducing and executing the content from the recording device 400A, externally attaching the save data, or built-in memory Processing stored in any one of various recording devices 400A, 400B, 400C such as a card and a hard disk The processing stored in the recording device 400 and played back will be described.
[0508]
As described above, the recording / reproducing device 300 includes a recording / reproducing device identifier IDdev, a system signature key Ksys that is a signature key common to the system, and a recording / reproducing device signature key Kdev that is a signature key unique to each recording / reproducing device. And a master key for generating various individual keys. The master key is a key for generating, for example, a delivery key Kdis or an authentication key Kake, as described in detail in “(12) Cryptographic key generation configuration based on master key”. Here, the master key of the recording / reproducing device 300 is represented as MKx as a representative of the master key in general without limiting the type of the master key. The lower part of FIG. 69 shows an example of the save data encryption key Ksav. The save data encryption key Ksav is an encryption key used for encryption processing when saving data is stored in the various recording devices 400A to 400C, and decryption processing when reproducing from the various recording devices 400A to 400C. An example of save data storage processing and playback processing will be described with reference to FIG.
[0509]
FIG. 70 is a flowchart of processing for storing save data in any of the recording devices 400A to 400C using either the content-unique key or the system common key. The process in each flow is a process executed by the recording / reproducing device 300, and the recording device for storing the save data in each flow may be any of the built-in and external recording devices 400A to 400C, and is limited to any one. It's not trivial.
[0510]
Step S701 is processing in which the recording / reproducing device 300 reads a content identifier, for example, a game ID. This is data included in the identification information in the content data shown in FIGS. 4, 26, 27 and 32-35 described above, and a save data storage processing command is received via the input interface 110 shown in FIG. The main CPU 106 instructs the control unit 301 to read the content identifier.
[0511]
When the execution program is a content that is executed via the reading unit 304 such as a DVD or CD-ROM, the control unit 301 extracts the identification information included in the header of the content data via the reading unit 304 and executes it. If the program is content stored in the recording device 400, identification information is extracted via the recording device controller 303. If the recording / reproducing device 300 is executing the content program and the content identifier has already been stored in the RAM or other accessible recording medium in the recording / reproducing device, the new reading process is not executed. The identification information included in the read data may be used.
[0512]
Next, step S702 is a step in which the process is changed depending on whether or not to restrict the use of the program. The program usage restriction is restriction information that sets whether or not to attach the restriction that the saved data to be saved can be used only for that program. “Use restriction” is used, and save data that is not restricted by the program is called “no program use restriction”. This may be arbitrarily set by the user, or may be set by the content creator and stored in the content program. The set restriction information is recorded in the record shown in FIG. It is stored in the devices 400A-C as a data management file.
[0513]
An example of the data management file is shown in FIG. The data management file is generated as a table including items including a data number, a content identifier, a recording / reproducing device identifier, and a program usage restriction. The content identifier is identification data of a content program for which save data is stored. The recording / reproducing device identifier is an identifier of the recording / reproducing device storing the save data, for example, [IDdev] shown in FIG. As described above, the program usage restriction is set to “Yes” when the save data to be saved can be used only for the program as described above, and set to “No” when the usage is not limited to the corresponding program. Become. The program use restriction may be arbitrarily set by a user who uses the content program, or may be set by a content producer and this information may be stored in the content program.
[0514]
Returning to FIG. 70, the description of the flow will be continued. If “Yes” is set for the program use restriction in step S702, the process proceeds to step S703. In step S703, a content-specific key, for example, the content key Kcon described above is read from the content data and the content-specific key is used as the save data encryption key Ksav, or a save data encryption key Ksav is generated based on the content-specific key. To do.
[0515]
On the other hand, if “NO” is set for the program use restriction in step S702, the process proceeds to step S707. In step S707, the system common key stored in the recording / reproducing device 300, for example, the system signature key Ksys is read from the internal memory 307 of the recording / reproducing device 300, and the system signature key Ksys is used as the save data encryption key Ksav. A save data encryption key Ksav is generated based on the system signature key. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0516]
Next, in step S704, save data encryption processing is executed using the save data encryption key Ksav selected or generated in step S703 or step S707. This encryption processing is executed by the encryption processing unit 302 in FIG. 2 using, for example, the DES algorithm described above.
[0517]
The save data encrypted in step S704 is stored in the recording device in step S705. When there are a plurality of recording devices capable of storing save data as shown in FIG. 69, the user selects one of the recording devices 400A to 400C as a save data storage destination in advance. Furthermore, in step S706, the program use restriction information previously set in step S702 is written to the data management file described with reference to FIG. 71, that is, the program use restriction “Yes” or “No” is written.
[0518]
This completes the save data storage process. In step S702, “Yes”, that is, “Restrict program use” is selected, and the save data encrypted by the save data encryption key Ksav generated based on the content unique key in step S703 includes the content unique key information. Decryption processing by a content program that does not have becomes impossible, and save data can be used only by content programs having the same content key information. However, here, since the save data encryption key Ksav is not generated based on information unique to the recording / reproducing device, the save data stored in a removable recording device such as a memory card is different from the recording / reproducing device. Can be reproduced as long as it is used together with the corresponding content program.
[0519]
In step S702, No, that is, “no program use restriction” is selected. In step S707, the save data encrypted by the save data encryption key Ksav based on the system common key uses a program with a different content identifier. Even if the recording / reproducing device is different, it can be reproduced and used.
[0520]
FIG. 72 is a flowchart showing a process of reproducing the save data stored by the save data storage process of FIG.
[0521]
Step S711 is a process in which the recording / reproducing device 300 reads a content identifier, for example, a game ID. This is the same process as step S701 of the save data storage process of FIG. 70 described above, and is a process of reading data included in the identification information in the content data.
[0522]
Next, in step S712, the data management file described with reference to FIG. 71 is read from the recording devices 400A to C shown in FIG. 69, the content identifier read in step S711, and the use program restriction information set correspondingly. To extract. If the program use restriction set in the data management file is “Yes”, the process proceeds to step S714. If it is “No”, the process proceeds to step S717.
[0523]
In step S714, the content-specific key, for example, the content key Kcon described above is read from the content data and the content-specific key is used as the save data decryption key Ksav, or the save-data decryption key Ksav is based on the content-specific key. Is generated. In this decryption key generation process, a processing algorithm corresponding to the encryption key generation process is applied, and data encrypted based on a certain content unique key is generated by a decryption key generated based on the same content unique key. A decryption key generation algorithm that can be decrypted is applied.
[0524]
On the other hand, if the setting of the data management file is “No” for the program use restriction in step S712, the system common key stored in the recording / reproducing device 300, for example, the system signature key Ksys is obtained in step S717. The data is read from the internal memory 307 of the recording / reproducing device 300, and the system signature key Ksys is used as the save data decryption key Ksav, or the save data decryption key Ksav is generated based on the system signature key. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0525]
Next, in step S715, the save data decryption process is executed using the save data decryption key Ksav selected or generated in step S714 or step S717. In step S716, the decrypted save data is recorded and reproduced. Playback and execution in the device 300.
[0526]
This completes the save data playback process. As described above, when “Restrict program use” is set in the data management file, a save data decryption key is generated based on the content unique key, and when “Restrict program use” is set. A save data decryption key is generated based on the system common key. When “Restrict program use” is set, the decryption key that enables decryption of save data cannot be obtained unless the content identifier of the content being used is the same. Can be increased.
[0527]
73 and 74 are a save data storage processing flow (FIG. 73) and a save data playback processing flow (FIG. 74) for generating an encryption key and a decryption key of the save data using the content identifier.
[0528]
In FIG. 73, steps S721 to S722 are the same as steps S701 to S702 of FIG.
[0529]
In the save data storage processing flow of FIG. 73, when “Restrict program use” is set in step S722, the content identifier, that is, the content ID is read from the content data in step S723, and the content ID is saved as the save data encryption key Ksav. Or a save data encryption key Ksav is generated based on the content ID. For example, the encryption processing unit 307 of the recording / reproducing device 300 applies the master key MKx stored in the internal memory of the recording / reproducing device 300 to the content ID read from the content data, and saves it by, for example, DES (MKx, content ID). The data encryption key Ksav can be obtained. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0530]
On the other hand, if “No” is set for the program use restriction in step S722, the system common key stored in the recording / reproducing device 300, for example, the system signature key Ksys is stored in the internal memory of the recording / reproducing device 300 in step S727. Read from 307 and use the system signature key Ksys as the save data encryption key Ksav, or generate the save data encryption key Ksav based on the system signature key. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0531]
The processing after step S724 is the same as the processing after step S704 in the processing flow of FIG.
[0532]
74 is a process flow for reproducing and executing the save data stored in the recording device in the save data storage process flow of FIG. 73. Steps S731 to S733 are the same as the corresponding process of FIG. Only step S734 is different. In step S734, the content identifier, that is, the content ID is read from the content data, and the content ID is used as the save data decryption key Ksav, or the save data decryption key Ksav is generated based on the content ID. In this decryption key generation process, a processing algorithm corresponding to the encryption key generation process is applied, and data encrypted based on a certain content identifier can be decrypted with a decryption key generated based on the same content identifier A decryption key generation algorithm is applied.
[0533]
The following processes, steps S735, S736, and S737 are the same as the corresponding processes in FIG. According to the save data storage and playback process of FIGS. 73 and 74, when the setting to restrict the use of the program is made, the save data encryption key and the decryption key are generated using the content ID. As in the case of save data storage and playback processing using the previous content unique key, save data cannot be used unless the corresponding content program matches, and save with enhanced save data security is possible. .
[0534]
75 and 77 are a save data storage processing flow (FIG. 75) and a save data playback processing flow (FIG. 77) for generating an encryption key and a decryption key of save data using the recording / playback device unique key.
[0535]
75, step S741 is the same processing as step S701 in FIG. 70, and a description thereof will be omitted. Step S742 is a step for setting whether or not to limit the recording / reproducing device. Recording / playback device restriction is set to “Yes” when recording / playback devices that can use save data are restricted, that is, when the save data is generated and stored only for the recording / playback device. The case where the device can be used is set to “No”. If “Restrict recording / reproducing device” is set in step S742, the process proceeds to step S743. If “No” is set, the process proceeds to step S747.
[0536]
An example of the data management file is shown in FIG. The data management file is generated as a table including data numbers, content identifiers, recording / reproducing device identifiers, and recording / reproducing device restrictions as items. The content identifier is identification data of a content program for which save data is stored. The recording / reproducing device identifier is an identifier of the recording / reproducing device storing the save data, for example, [IDdev] shown in FIG. Recording / playback device restriction is set to “Yes” when recording / playback devices that can use save data are restricted, that is, when the save data is generated and stored only for the recording / playback device. The case where the device can be used is set to “No”. The recording / reproducing device restriction information may be arbitrarily set by the user using the content program, or may be set by the content producer and stored in the content program.
[0537]
In the save data storage processing flow of FIG. 75, when “Restrict recording / reproducing device” is set in step S742, the recording / reproducing device unique key, for example, the recording / reproducing device signature key Kdev is obtained from the recording / reproducing device 300 in step S743. It reads out from the internal memory 307 of the recording / reproducing device 300 and uses the recording / reproducing device signature key Kdev as the save data encryption key Ksav, or generates the save data encryption key Ksav based on the recording / reproducing device signature key Kdev. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0538]
On the other hand, if the recording / reproducing device restriction is set to “No” in step S742, the system common key stored in the recording / reproducing device 300, for example, the system signature key Ksys is stored in the recording / reproducing device 300 in step S747. Read from the memory 307 and use the system signature key Ksys as the save data encryption key Ksav or generate the save data encryption key Ksav based on the system signature key. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0539]
The processing in steps S744 and S745 is the same as the corresponding processing in the processing flow of FIG. 70 described above, and description thereof is omitted.
[0540]
In step S746, the content identifier, the recording / reproducing device identifier, and the recording / reproducing device restriction information set by the user in step 742 are written in the data management file (see FIG. 76).
[0541]
Further, FIG. 77 is a processing flow for reproducing and executing the save data stored in the recording device in the save data storage processing flow of FIG. 75. Step S751 reads the content identifier as in the corresponding processing of FIG. 72 described above. . Next, in step S752, the recording / reproducing device identifier (IDdev) stored in the memory in the recording / reproducing device 300 is read.
[0542]
In step S753, the content identifier, the recording / reproducing device identifier, and the set recording / reproducing device restriction information “Yes / No” are read from the data management file (see FIG. 76). When the recording / reproducing device restriction information is set to “Yes” in the entry having the same content identifier in the data management file, the recording / reproducing device identifier of the table entry is different from the recording / reproducing device identifier read in step S752. Ends the process.
[0543]
Next, when the setting of the data management file is “Restrict recording / playback device” in Step S754, the process proceeds to Step S755, and when it is “No”, the process proceeds to Step S758.
[0544]
In step S755, the recording / reproducing device unique key, for example, the recording / reproducing device signature key Kdev is read from the recording / reproducing device 300 from the internal memory 307 of the recording / reproducing device 300, and the recording / reproducing device signature key Kdev is used as the save data decryption key Ksav. Alternatively, the save data decryption key Ksav is generated based on the recording / reproducing device signature key Kdev. In this decryption key generation process, a processing algorithm corresponding to the encryption key generation process is applied, and data encrypted based on a certain recording / reproducing device unique key is generated based on the same recording / reproducing device unique key. A decryption key generation algorithm that can be decrypted by the decryption key is applied. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0545]
On the other hand, in step S758, the system common key stored in the recording / reproducing device 300, for example, the system signature key Ksys is read from the internal memory 307 of the recording / reproducing device 300, and the system signature key Ksys is used as the save data decryption key Ksav. Alternatively, the save data decryption key Ksav is generated based on the system signature key. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav. The following steps S756 and S757 are the same as the corresponding steps in the save data reproduction processing flow described above.
[0546]
According to the save data storage / reproduction process flow shown in FIGS. 75 and 77, the save data for which “Restrict recording / reproducing device” is selected is encrypted and decrypted by the recording / reproducing device unique key. Therefore, it can be decrypted and used only by the recording / reproducing device having the same recording / reproducing device unique key, that is, the same recording / reproducing device.
[0547]
Next, FIGS. 78 and 79 show processing flows for generating, storing, and reproducing the encryption / decryption key of the save data using the recording / reproducing device identifier.
[0548]
In FIG. 78, the save data is encrypted using the recording / reproducing device identifier and stored in the recording device. Steps S761 to S763 are the same processing as in FIG. In step S764, a save data encryption key Ksav is generated using the recording / reproducing device identifier (IDdev) read from the recording / reproducing device. Apply IDdev as the save data encryption key Ksav, or apply the master key MKx stored in the internal memory of the recording / reproducing device 300 to obtain the save data encryption key Ksav by DES (MKx, IDdev), etc. A save data encryption key ksav is generated based on IDdev. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0549]
The following processing steps S765 to S768 are the same as the corresponding processing in FIG. 75 described above, and a description thereof will be omitted.
[0550]
FIG. 79 is a processing flow for reproducing and executing the save data stored in the recording device by the processing of FIG. Steps S771 to S774 are the same as the corresponding processing in FIG. 77 described above.
[0551]
In step S775, the save data decryption key Ksav is generated using the recording / reproducing device identifier (IDdev) read from the recording / reproducing device. Applying IDdev as the save data decryption key Ksav, or applying the master key MKx stored in the internal memory of the recording / reproducing device 300 to obtain the save data decryption key Ksav by DES (MKx, IDdev), etc. A save data decryption key Ksav is generated based on IDdev. In this decryption key generation processing, a processing algorithm corresponding to the encryption key generation processing is applied, and data encrypted based on a certain recording / reproducing device identifier is decrypted based on the same recording / reproducing device identifier. A decryption key generation algorithm that can be decrypted by a key is applied. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0552]
The following processing steps S776 to S778 are the same as the corresponding steps in FIG.
[0553]
According to the save data storage and reproduction processing flow shown in FIGS. 78 and 79, the save data for which “Restrict recording / reproducing device” has been selected is encrypted and decrypted by the recording / reproducing device identifier. Therefore, the recording / reproducing device having the same recording / reproducing device identifier, that is, only the same recording / reproducing device can be used by decoding.
[0554]
Next, with reference to FIGS. 80 to 82, a description will be given of save data storage and reproduction processing that is executed in combination with the above-described program use restriction and recording / playback apparatus use restriction.
[0555]
FIG. 80 is a save data storage processing flow. In step S781, the content identifier is read from the content data. In step S782, a program use restriction determination is performed, and in step S783, a recording / reproducing apparatus restriction determination is performed.
[0556]
In the case of “program usage restricted” and “recording / reproducing device restricted”, in step S785, save data encryption is performed based on both the content unique key (ex. Kcon) and the recording / reproducing device unique key (Kdev). A key Ksav is generated. This can be obtained by, for example, Ksav = (Kcon XOR Kdev), or Ksav = DES (MKx, Kcon XOR Kdev) by applying the master key MKx stored in the internal memory of the recording / reproducing device 300. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0557]
In the case of “with program use restriction” and “without recording / playback apparatus restriction”, in step S786, the content unique key (ex.Kcon) is used as the save data encryption key Ksav or the content unique key (ex.Kcon). ) To generate a save data encryption key Ksav.
[0558]
In the case of “no program use restriction” and “recording / reproducing apparatus restriction”, in step S787, the recording / reproducing apparatus unique key (Kdev) is used as the save data encryption key Ksav, or the recording / reproducing apparatus unique key (Kdev). ) To generate a save data encryption key Ksav. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0559]
Further, if “no program use restriction” and “no recording / reproducing apparatus restriction”, in step S787, the system common key, for example, the system signature key Ksys is used as the save data encryption key Ksav or the system signature key Ksys. A save data encryption key Ksav is generated based on the above. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0560]
In step S789, the save data is encrypted by the save data encryption key Ksav generated in any of steps S785 to S788 and stored in the recording device.
[0561]
In step S790, the restriction information set in steps S782 and S783 is stored in the data management file. The data management file has the configuration shown in FIG. 81, for example, and includes data number, content identifier, recording / reproducing device identifier, program usage restriction, and recording / reproducing device restriction as items.
[0562]
FIG. 82 is a processing flow for reproducing and executing the save data stored in the recording device by the processing of FIG. In step S791, the content identifier and recording / reproducing device identifier of the execution program are read. In step S792, the content identifier, recording / reproducing device identifier, program usage restriction, and recording / reproducing device restriction information are read from the data management file shown in FIG. In this case, if the program usage restriction is “Yes” and the content identifiers do not match, or if the recording / reproducing device restriction information is “Yes” and the recording / reproducing device identifiers do not match, the processing ends.
[0563]
Next, in steps S793, S794, and S795, the decryption key generation process is set to one of the four modes of steps S796 to S799 according to the recording data of the data management file.
[0564]
In the case of “program use restricted” and “recording / reproducing device restricted”, in step S796, the save data decryption is performed based on both the content unique key (ex.Kcon) and the recording / reproducing device unique key (Kdev). A key Ksav is generated. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav. In the case of “with program use restriction” and “without recording / playback device restriction”, in step S797, the content unique key (ex.Kcon) is used as the save data decryption key Ksav or the content unique key (ex.Kcon). ) To generate a save data decryption key Ksav. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0565]
In the case of “no program use restriction” and “recording / reproducing apparatus restriction”, in step S798, the recording / reproducing apparatus unique key (Kdev) is used as the save data decryption key Ksav or the recording / reproducing apparatus unique key (Kdev). ) To generate a save data decryption key Ksav. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav. Further, if “no program use restriction” and “no recording / reproducing apparatus restriction”, in step S799, the system common key, for example, the system signature key Ksys is used as the save data decryption key Ksav or the system signature key Ksys. The save data decryption key Ksav is generated based on the above. Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0566]
In these decryption key generation processes, a processing algorithm corresponding to the encryption key generation process is applied, and data encrypted based on the same content specific key and recording / playback device specific key is the same content specific key, A decryption key generation algorithm that can be decrypted by the decryption key generated based on the recording / reproducing device unique key is applied.
[0567]
In step S800, the decryption process is executed using the save data decryption key generated in any of steps S796 to S799 described above, and the decrypted save data is reproduced and executed in the recording / reproducing device 300.
[0568]
According to the save data storage and playback processing flow shown in FIGS. 80 and 82, the save data for which “Restrict program use” is selected is encrypted and decrypted by the content unique key, and therefore the same. It is possible to decrypt and use only content data having the content unique key. In addition, the save data for which “Restrict recording / reproducing device” is selected is encrypted and decrypted by the recording / reproducing device identifier, so that the recording / reproducing device having the same recording / reproducing device identifier, that is, the same It is possible to decode and use only by the recording / reproducing device. Accordingly, usage restrictions can be set by both the content and the recording / reproducing device, and the security of the save data can be further increased.
[0569]
In FIGS. 80 and 82, the content unique key, the save data encryption key using the recording / reproducing device unique key, and the decryption key generation configuration are shown, but the content identifier, A recording / reproducing device identifier may be used instead of the recording / reproducing device unique key, and a save data encryption key and a decryption key may be generated based on these identifiers.
[0570]
Next, the configuration for generating the save data encryption key and decryption key based on the password input by the user will be described with reference to FIGS.
[0571]
FIG. 83 is a processing flow for generating the save data encryption key based on the password input by the user and storing it in the recording device.
[0572]
Step S821 is a process of reading the content identifier from the content data, and is the same as each process described above. Step S822 is a step of determining whether or not to set a program use restriction by the user. The data management file set in this configuration has, for example, the configuration shown in FIG.
[0573]
As shown in FIG. 84, the data includes a data number, a content identifier, a recording / playback device identifier, and program usage restriction information by the user. “Program usage restriction information by user” is an item for setting whether to restrict users who use the program.
[0574]
If the use restriction is set in step S822 in the processing flow in FIG. 83, a user password is input in step S823. This input is input from input means such as a keyboard shown in FIG.
[0575]
The input password is output to the encryption processing unit 302 under the control of the main CPU 106 and the control unit 301, and the save data encryption key Ksav based on the process in step S824, that is, the input user password is generated. As the save data encryption key Ksav generation process, for example, the password itself may be used as the encryption key Ksav, or the save data encryption key Ksav = DES (MKx, password) using the master key MKx of the recording / reproducing device. It may be generated. Alternatively, a one-way function may be applied using a password as an input, and an encryption key may be generated based on the output.
[0576]
If the user restriction in step S822 is No, a save data encryption key is generated based on the system common key of the recording / reproducing device 300 in step S828.
[0577]
Further, in step S825, the save data is encrypted using the save data encryption key Ksav generated in step S824 or step S828, and the save data subjected to the encryption process is stored in the recording device in step S826. .
[0578]
Further, in step S827, the program usage restriction information set by the user set in step S822 is written in the data management file of FIG. 84 in association with the content identifier and the recording / playback device identifier.
[0579]
FIG. 85 is a diagram showing a flow of reproducing saved data stored by the process of FIG. In step S831, the content identifier is read from the content data, and in step S832, the content identifier and the program usage restriction information by the user are read from the data management file shown in FIG.
[0580]
In step S833, a determination based on the data in the data management file is executed, and when “Restrict program use by user” is set, a password input is requested in step S834, and based on the input password in step S835. Generate a decryption key. In this decryption key generation process, a processing algorithm corresponding to the encryption key generation process is applied, and data encrypted based on a certain password can be decrypted with a decryption key generated based on the same password Is set to the decryption key generation algorithm.
[0581]
If the determination in step S833 is that there is no program use restriction by the user, a save data decryption key Ksav is generated in step S837 using the system common key stored in the internal memory of the recording / reproducing device 300, for example, the system signature key Ksys. . Alternatively, an encryption key separately stored in the internal memory 307 of the recording / reproducing device 300 and different from other keys may be used as the save data encryption key Ksav.
[0582]
In step S836, the save data stored in the recording device is decrypted using the decryption key Ksav generated in either step S835 or step S837. In step S836, the save data is reproduced and executed in the recording / reproducing device. Is made.
[0583]
According to the save data storage and playback processing flow shown in FIGS. 83 and 85, the save data for which “restrict use of program by user” is selected is encrypted and decrypted by the key based on the user input password. Therefore, only when the same password is input can be decrypted and used, and the security of the save data can be increased.
[0584]
As described above, several save data storage processing and playback processing modes have been described. However, the save data is obtained by combining the above-described processing, for example, a password, a recording / playback device identifier, a content identifier, and the like in any combination. An aspect in which an encryption key and a decryption key are generated is also possible.
[0585]
(17) Unauthorized device exclusion (revocation) configuration
As described above, in the data processing apparatus of the present invention, various contents data provided from the medium 500 (see FIG. 3) and the communication means 600 are subjected to authentication, encryption processing, etc. in the recording / reproducing device 300. In addition, the security of the provided content is enhanced by the configuration stored in the recording device, and the configuration is such that only authorized users can use it.
[0586]
As can be understood from the above description, the input content includes various signature keys, master keys, and check value generation keys (see FIG. 18) stored in the internal memory 307 configured in the encryption processing unit 302 of the recording / reproducing device 300. ) Is used for authentication processing, encryption processing, and decryption processing. As described above, the internal memory 307 for storing the key information is basically composed of a semiconductor chip having a structure that is difficult to access from the outside, and has a multilayer structure. The internal memory is an aluminum layer or the like. It is desirable to have a configuration that makes it difficult to read data illegally from the outside, such as being sandwiched between the dummy layers or being configured at the lowest layer, and having a narrow operating voltage or / and frequency range, In the unlikely event that unauthorized reading of the internal memory is performed and these key data, etc. are leaked and copied to a recording / playback device that is not licensed properly, unauthorized use of the content may be made with the copied key information There is sex.
[0587]
Here, a configuration for preventing unauthorized use of content due to duplication of keys by unauthorized copying will be described.
[0588]
FIG. 86 is a block diagram for explaining this configuration “(17) Unauthorized device elimination configuration”. The recording / reproducing device 300 is the same as the recording / reproducing device shown in FIGS. 2 and 3 described above, has an internal memory, has various key data described above (FIG. 18), and further has a recording / reproducing device identifier. ing. Here, the recording / reproducing device identifier, key data, etc. copied by a third party are not necessarily stored in the internal memory 307 shown in FIG. 3, but the key data, etc. of the recording / reproducing device 300 shown in FIG. Are configured to be stored in a memory unit that is accessible by the cryptographic processing unit 302 (see FIGS. 2 and 3) or distributed.
[0589]
In order to realize an illegal device exclusion configuration, an illegal recording / reproducing device identifier list in the header portion of the content data is stored. As shown in FIG. 86, the content data has a revocation list as an unauthorized recording / reproducing device identifier (IDdev) list. Further, a list check value ICVrev for tampering check of the revocation list is provided. The unauthorized recording / reproducing device identifier (IDdev) list is a list of unauthorized recording / reproducing device identifiers IDdev found by the content provider or administrator from the distribution status of unauthorized copying, for example. This revocation list may be encrypted and stored with the delivery key Kdis, for example. The decoding process by the recording / reproducing device is the same as that of the content download process of FIG. 22, for example.
[0590]
Here, in order to facilitate understanding, the revocation list is shown as single data in the content data in FIG. 86. For example, the handling policy (components of the header portion of the content data described above) For example, the revocation list may be included in FIGS. In this case, the handling policy data including the revocation list is tampered with the check value ICVa described above. When the revocation list is included in the handling policy, it is necessary to store the check value generation key Kicv-rev by using the check value A: ICVa check instead of the check value A: the check value A generation key Kicva in the recording / reproducing device is used. There is no.
[0591]
When the revocation list is included in the content data as single data, the revocation list is checked by the list check value ICVrev for tampering check of the revocation list, and the list check value ICVrev and other contents in the content data are also checked. The intermediate check value is generated from the partial check value of the intermediate check value and the intermediate check value is verified.
[0592]
The revocation list check method using the list check value ICVrev for revocation check of the revocation list can be executed by the same method as the check value generation processing of ICVa, ICVb, etc. described with reference to FIGS. . That is, the ICV calculation described with reference to FIGS. 23, 24, etc., using the check value generation key Kicv-rev stored in the internal memory 307 of the recording / reproducing device encryption unit 302 as a key and the revocation list included in the content data as a message. Calculated according to the method. The calculated check value ICV-rev 'is compared with the check value ICV-rev stored in the header (Header). If they match, it is determined that there is no falsification.
[0593]
The intermediate check value including the list check value ICVrev is, for example, as shown in FIG. 25, with the total check value generation key Kicvt stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. The check value A, the check value B, the list check value ICVrev, and the message string to which the content check value is added according to the format are generated by applying the ICV calculation method described in FIG.
[0594]
These revocation lists and list check values are provided to the recording / reproducing device 300 via the media 500 such as DVD and CD, the communication means 600, or the recording device 400 such as a memory card. Here, the recording / reproducing device 300 may be a recording / reproducing device that holds valid key data, or may have an identifier ID that has been illegally copied.
[0595]
FIG. 87 and FIG. 88 show the processing flow of the illegal recording / reproducing device elimination processing in such a configuration. FIG. 87 is an unauthorized recording / reproducing device revocation process flow when content is provided from a medium 500 such as a DVD or CD, or communication means 600, and FIG. 88 is a flowchart from a recording device 400 such as a memory card. It is an unauthorized recording / reproducing device exclusion (revocation) processing flow when content is provided.
[0596]
First, the processing flow of FIG. 87 will be described. Step 901 is a step in which a medium is loaded and content is provided, that is, a reproduction process or a download request is made. The process shown in FIG. 87 is executed as a step before executing a download process or the like by mounting a medium such as a DVD on a recording / reproducing device, for example. The download process is as described above with reference to FIG. 22. The process of FIG. 87 is performed as a step before the execution of the process flow of FIG. 22 or as a process inserted in the process flow of FIG. Is executed.
[0597]
When the recording / reproducing device 300 receives content provision via a communication means such as a network, the communication session with the content distribution service side is established in step S911, and then the process proceeds to step S902.
[0598]
In step S902, a revocation list (see FIG. 86) is acquired from the header portion of the content data. In the list acquisition process, when the content is in the medium, the control unit 301 shown in FIG. 3 reads from the media via the reading unit 304, and when the content is from the communication unit, the control unit 301 shown in FIG. Is received from the content distribution side via the communication unit 305.
[0599]
In step S903, the control unit 301 passes the revocation list acquired from the medium 500 or the communication unit 600 to the encryption processing unit 302 and causes the encryption processing unit 302 to execute check value generation processing. The recording / reproducing device 300 has a revocation check value generation key Kicv-rev inside, and applies the revocation check value generation key Kicv-rev with the received revocation list as a message, for example, FIG. 23, FIG. The check value ICV-rev ′ is calculated according to the ICV calculation method described in the above item, and the check result: ICV-rev stored in the header of the content data (Header) is compared. Is determined to be absent (Yes in step S904). If they do not match, it is determined that they have been tampered with, and the process advances to step S909 to end the process as a processing error.
[0600]
Next, in step S905, the control unit 306 of the recording / reproducing device encryption processing unit 302 causes the encryption / decryption unit 308 of the recording / reproduction device encryption processing unit 302 to calculate the total check value ICVt '. As shown in FIG. 25, the total check value ICVt ′ is generated by encrypting the intermediate check value with DES using the system signature key Ksys stored in the internal memory 307 of the recording / reproducing device encryption processing unit 302 as a key. Note that verification processing of each partial check value, for example, ICVa, ICVb, etc. is omitted in the processing flow shown in FIG. 87, but each data format is the same as the processing flow of FIGS. 39 to 45 described above. Verification of the partial check value according to is performed.
[0601]
Next, in step S906, the generated total check value ICVt 'is compared with the ICVt in the header (Header). If they match (Yes in step S906), the process proceeds to step S907. If they do not match, it is determined that they have been tampered with, and the process advances to step S909 to end the process as a processing error.
[0602]
As described above, the total check value ICVt is for checking the entire partial check value included in the content data, such as ICVa, ICVb, and the check value of each content block according to the data format. Then, in addition to these partial check values, a list check value ICVrev for checking the alteration of the revocation list is added as a partial check value to verify all of these falsifications. When the total check value generated by the above processing matches the check value stored in the header (ICVt): ICVt, all of ICVa, ICVb, the check value of each content block, and the list check value ICVrev are falsified. Not determined.
[0603]
In step S907, the revocation list determined not to be falsified is compared with the recording / reproducing device identifier (IDdev) stored in its own recording / reproducing device 300.
[0604]
If the list of the unauthorized recording / reproducing device identifier IDdev read from the content data includes the recording / reproducing device identifier IDdev, the recording / reproducing device 300 has the illegally copied key data. In step S909, the subsequent procedure is stopped. For example, it is impossible to execute the content download processing procedure of FIG.
[0605]
If it is determined in step S907 that the list of the illegal recording / reproducing device identifier IDdev does not include the recording / reproducing device identifier IDdev, the recording / reproducing device 300 has valid key data. The process proceeds to step S908, and the subsequent procedure, for example, the program execution process or the content download process shown in FIG.
[0606]
FIG. 88 shows a process for reproducing content data stored in a recording device 400 such as a memory card. As described above, the recording device 400 such as a memory card and the recording / reproducing device 300 execute the mutual authentication process (step S921) described in FIG. In step S922, only when mutual authentication is OK, the process proceeds to step S923 and subsequent steps. If mutual authentication fails, an error occurs in step S930, and the subsequent processing is not executed.
[0607]
In step S923, a revocation list (see FIG. 86) is acquired from the header portion of the content data. The subsequent processing in steps S924 to S930 is the same processing as the corresponding processing in FIG. That is, the verification of the list based on the list check value (S924, S925), the verification based on the total check value (S926, S927), the comparison between the list entry and the own recording / playback device identifier IDdev (S928) is executed, When the list of the read / unauthorized recording / reproducing device identifier IDdev contains the identifier IDdev of its own recording / reproducing device, the recording / reproducing device 300 has the illegally copied key data. The process proceeds to step S930, and the subsequent procedure is stopped. For example, it is assumed that the content reproduction process shown in FIG. 28 cannot be executed. On the other hand, when it is determined that the recording / reproducing device identifier IDdev does not include the recording / reproducing device identifier IDdev, the recording / reproducing device 300 has valid key data. The process proceeds to step S929, and the subsequent procedure can be executed.
[0608]
As described above, in the data processing apparatus of the present invention, the data for identifying an unauthorized recording / reproducing device in combination with the content provided by the content provider or administrator, that is, the rebodies in which the unauthorized recording / reproducing device identifier IDdev is listed. The application list is included as configuration data of the header portion of the content data and provided to the recording / reproducing device user. The recording / reproducing device user stores the content list in the memory of his / her recording / reproducing device before using the content by the recording / reproducing device. When the stored recording / reproducing device identifier IDdev and the identifier of the list are collated and there is a matching data, the subsequent processing is not executed, so the key data is copied and stored in the memory. It is possible to eliminate the use of content by an unauthorized recording / reproducing device.
[0609]
(18) Secure chip configuration and manufacturing method
As described above, since the internal memory 307 of the recording / reproducing device encryption processing unit 302 or the internal memory 405 of the recording device 400 holds important information such as an encryption key, it is difficult to read out illegally from the outside. It is necessary to keep it. Accordingly, the recording / reproducing device encryption processing unit 302 and the recording device encryption processing unit 401 are composed of, for example, a semiconductor chip having a structure that is difficult to access from the outside, and have a multilayer structure, and the internal memory thereof is a dummy such as an aluminum layer. It is configured as a tamper-resistant memory having a characteristic that it is difficult to read data illegally from the outside, such as being sandwiched between layers or configured in the lowermost layer, and having a narrow operating voltage and / or frequency range.
[0610]
However, as will be understood from the above description, for example, it is necessary to write different data for each recording / reproducing device such as the recording / reproducing device signature key Kdev in the internal memory 307 of the recording / reproducing device encryption processing unit 302. Also, after writing individual information for each chip, such as identification information (ID) and encryption key information, in a nonvolatile storage area in the chip, such as flash memory, FeRAM, etc., for example, rewriting and reading data after product shipment It is necessary to make it difficult.
[0611]
As a conventional technique for making it difficult to read and rewrite write data, for example, a data write command protocol is kept secret. Alternatively, a signal line that accepts a data write command on the chip and a communication signal line that is used after commercialization are separated, and the data write command is valid unless a signal is sent directly to the chip on the board. There is a technique to prevent it from happening.
[0612]
However, even if such a conventional method is adopted, for those who have expertise in storage elements, if there is equipment and technology to drive the circuit, it is possible to output signals to the data writing area of the chip, Even if the command protocol for writing data is secret, there is always a parseability of the protocol.
[0613]
Distributing such storage elements for encrypted data that retains the possibility of altering secret data results in a threat to the entire encryption system. In addition, in order to prevent data reading, it is possible to adopt a configuration in which the data read command itself is not implemented, but in that case, even when regular data writing is executed, data writing to the memory is actually performed. It is impossible to check whether or not the written data is correctly written and whether or not the written data is written correctly, and there is a possibility that a chip on which defective data has been written is supplied. To do.
[0614]
In view of these conventional techniques, here, a secure chip configuration and a secure chip manufacturing method are provided that enable accurate data writing to a nonvolatile memory such as flash memory and FeRAM, and make data reading difficult. .
[0615]
FIG. 89 shows a security chip configuration applicable to, for example, the recording / reproducing device encryption processing unit 302 or the encryption processing unit 401 of the recording device 400 described above. 89A shows a security chip configuration in a chip manufacturing process, that is, a data writing process, and FIG. 89B shows a configuration example of a product including a security chip into which data is written, for example, a recording / reproducing device 300, An example of a recording device 400 is shown.
[0616]
In the security chip in the manufacturing process, a mode designation signal line 8003 and various command signal lines 8004 are connected to the processing unit 8001, and the processing unit 8001 is configured to use a mode set by the mode designation signal line 8003, for example, a data write mode. Alternatively, data write processing to the storage unit 8002 which is a nonvolatile memory or data read processing from the storage unit 8002 is executed according to the data read mode.
[0617]
On the other hand, in the product equipped with the security chip in FIG. 89B, the security chip and the external connection interface, peripheral devices, other elements, and the like are connected by general-purpose signal lines, but the mode signal line 8003 is in a non-connected state. Is done. Specific processing includes, for example, connecting the mode signal line 8003 to the ground, raising it to Vcc, cutting the signal line, or sealing with an insulating resin. By such processing, it becomes difficult to access the mode signal line of the security chip after the product is shipped, and the difficulty of reading and writing the chip data from the outside can be increased.
[0618]
Further, the security chip 8000 having this configuration has a configuration that makes it difficult to write data to the storage unit 8002 and to read data written to the storage unit 8002, even if a third party accesses the mode signal line 8003. Even if successful, illegal data writing and reading can be prevented. FIG. 90 shows a data write or read process flow in the security chip having this configuration.
[0619]
Step S951 is a step of setting the mode signal line 8003 to the data write mode or the data read mode.
[0620]
Step S952 is a step of extracting authentication information from the chip. In the security chip of this configuration, information necessary for authentication processing, such as a password and key information for authentication processing in encryption technology, is stored in advance by, for example, a wire or mask ROM configuration. In step S952, the authentication information is read and an authentication process is executed. For example, when an authentication process is executed by connecting a regular data writing jig or data reading device to a general-purpose signal line, an authentication OK result (Yes in step S953) is obtained. When the authentication process is executed by connecting the data reading device to the general-purpose signal line, the authentication fails (No in step S953), and the process is stopped at that time. The authentication process can be executed, for example, according to the mutual authentication process procedure of FIG. 13 described above. A processing unit 8001 shown in FIG. 89 has a configuration capable of executing these authentication processes. This can be realized, for example, by the same configuration as the command register incorporated in the control unit 403 of the encryption processing unit 401 of the recording device 400 shown in FIG. For example, the processing unit of the chip in FIG. 89 has the same configuration as the command register incorporated in the control unit 403 of the encryption processing unit 401 of the recording device 400 shown in FIG. 29, and is connected to various command signal lines 8004. When a predetermined command No is input, it is possible to execute a corresponding process and execute an authentication process sequence.
[0621]
The processing unit 8001 accepts a data write command or a data read command only when authentication is performed in the authentication process, and executes a data write process (step S955) or a data read process (step S956).
[0622]
As described above, the security chip of this configuration is configured to execute the authentication process at the time of data writing or reading, so that data read from or stored in the security chip storage unit by a third party who does not have a legitimate right. Data writing to the part can be prevented.
[0623]
Next, FIG. 91 shows an embodiment in which an element configuration with higher security is provided. In this example, the security chip storage unit 8200 is separated into two areas, one is a read / write combined area (RW: ReadWrite area) 8201 in which data can be read and written, and the other is a write in which only data can be written. A dedicated area (WO: Write Only area) 8202.
[0624]
In this configuration, a write-only area (WO: Write Only area) 8202 is written with high security request data such as encryption key data and identifier data, while the security level is not so high, for example, check data is read and written. Data is written in a combined area (RW: ReadWrite area) 8201.
[0625]
The processing unit 8001 executes the data reading process with the authentication process described above with reference to FIG. 90 as the data reading process from the read / write combined area (RW: ReadWrite area) 8201. However, the data writing process is executed according to the flow of FIG.
[0626]
Step S961 in FIG. 92 is a step for setting the mode signal line 8003 to the write mode, and in step 962, the same authentication process as described in FIG. 90 is executed. When authentication is performed in the authentication process, the process proceeds to step S963, where information such as high-security key data is written to the write-only (WO) area 8202 via the command signal line 8004, and a read / write combined use area (RW: ReadWrite area). ) 8201, for example, a command for writing check data is output to the processing unit 8001 which is not so high in security level.
[0627]
In step S964, the processing unit 8001 that has received the command executes data write processing corresponding to the command for the write-only (WO) area 8202 and the read / write combined area (RW: ReadWrite area) 8201, respectively.
[0628]
FIG. 93 shows a verification processing flow of data written in the write-only (WO) area 8202.
[0629]
Step S971 in FIG. 93 causes the processing unit 8001 to execute encryption processing based on the data written in the write-only (WO) area 8202. These execution configurations are realized by a configuration that sequentially executes the cryptographic processing sequence stored in the command register, as in the previous authentication processing execution configuration. Further, the cryptographic processing algorithm executed in the processing unit 8001 is not particularly limited, and for example, a configuration in which the DES algorithm described above is executed can be adopted.
[0630]
In step S972, the verification device connected to the security chip receives the cryptographic processing result from the processing unit 8001. In step S973, the result obtained by applying the same encryption process as the algorithm executed in the processing unit 8001 to the regular write data that has been previously written in the storage unit, and the processing unit 8001 Compare the encryption result from
[0631]
If the comparison results are the same, it is verified that the data written in the write-only (WO) area 8202 is correct.
[0632]
In this configuration, even if the authentication process is broken and the read command can be executed, the data readable area is limited to the read / write combined area (RW: ReadWrite area) 8201 and the write only (WO) area 8202 is used. It is impossible to read out the data written in the, and the configuration becomes higher in security. Further, unlike a chip in which reading is impossible at all, a read / write combined use area (RW: ReadWrite area) 8201 is configured, so that it is possible to check the correctness of memory access.
[0633]
The present invention has been described in detail above with reference to specific embodiments. However, it is obvious that those skilled in the art can make modifications and substitutions of the embodiments without departing from the gist of the present invention. In other words, the present invention has been disclosed in the form of exemplification, and should not be interpreted in a limited manner. In the above-described embodiment, the recording / reproducing device capable of recording and reproducing contents has been described as an example. However, the configuration of the present invention can be applied to an apparatus capable of only data recording and data reproduction. The present invention can be implemented in personal computers, game machines, and other various data processing devices in general. In order to determine the gist of the present invention, the claims section described at the beginning should be considered.
[0634]
【The invention's effect】
As described above, according to the data storage element manufacturing method, the data storage element, and the data processing apparatus of the present invention, since the authentication process is executed at the time of writing and reading of data, there is no right right. It is possible to prevent data from being read from or written to the storage unit of the security chip by the three parties.
[0635]
Furthermore, according to the data storage element manufacturing method, the data storage element, and the data processing apparatus of the present invention, it is possible to verify the write data by executing encryption processing based on the write data, and to prevent occurrence of data write errors and the like at the time of manufacture. It becomes possible to discover with. In addition, according to the configuration in which the write-only area and the read / write combined area are provided, it is possible to further increase the security of data by writing high-security information in the write-only area.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of a conventional data processing system.
FIG. 2 is a diagram showing a configuration of a data processing apparatus to which the present invention is applied.
FIG. 3 is a diagram showing a configuration of a data processing apparatus to which the present invention is applied.
FIG. 4 is a diagram showing a data format of content data on a medium and a communication path.
FIG. 5 is a diagram showing a handling policy included in a header in content data.
FIG. 6 is a diagram illustrating block information included in a header in content data.
FIG. 7 is a diagram illustrating an electronic signature generation method using DES.
FIG. 8 is a diagram illustrating an electronic signature generation method using triple DES.
FIG. 9 is a diagram illustrating an aspect of triple DES.
FIG. 10 is a diagram illustrating an electronic signature generation method using triple DES in part.
FIG. 11 is a diagram showing a processing flow in electronic signature generation.
FIG. 12 is a diagram showing a processing flow in electronic signature verification.
FIG. 13 is a diagram illustrating a processing sequence of mutual authentication processing using symmetric key encryption technology.
FIG. 14 is a diagram illustrating a public key certificate.
FIG. 15 is a diagram illustrating a processing sequence of mutual authentication processing using asymmetric key encryption technology.
FIG. 16 is a diagram showing a processing flow of encryption processing using elliptic curve cryptography.
FIG. 17 is a diagram showing a processing flow of decryption processing using elliptic curve cryptography.
FIG. 18 is a diagram showing a data holding state on the recording / reproducing device.
FIG. 19 is a diagram illustrating a data holding status on a recording device.
FIG. 20 is a diagram showing a mutual authentication processing flow between a recording / reproducing device and a recording device.
FIG. 21 is a diagram illustrating a relationship between a master key of a recording / reproducing device and a corresponding key block of a recording device.
FIG. 22 is a diagram showing a processing flow in content download processing;
FIG. 23 is a diagram for explaining a method of generating a check value A: ICVa.
FIG. 24 is a diagram illustrating a method for generating a check value B: ICVb.
FIG. 25 is a diagram for explaining a method for generating a total check value and a recording / reproducing device specific check value;
FIG. 26 is a diagram illustrating a format of content data (usage restriction information = 0) stored in a recording device.
FIG. 27 is a diagram illustrating a format of content data stored in a recording device (usage restriction information = 1).
FIG. 28 is a diagram illustrating a processing flow in content reproduction processing;
FIG. 29 is a diagram illustrating a command execution method in a recording device.
FIG. 30 is a diagram illustrating a command execution method in content storage processing in a recording device.
FIG. 31 is a diagram illustrating a command execution method in content reproduction processing in a recording device.
Fig. 32 is a diagram for describing a configuration of format type 0 of a content data format.
FIG. 33 is a diagram for describing a configuration of format type 1 of a content data format.
[Fig. 34] Fig. 34 is a diagram for describing the configuration of format type 2 of a content data format.
[Fig. 35] Fig. 35 is a diagram describing a configuration of format type 3 of a content data format.
FIG. 36 is a diagram illustrating a content check value ICVi generation processing method in format type 0.
FIG. 37 is a diagram illustrating a content check value ICVi generation processing method in format type 1.
FIG. 38 is a diagram for explaining a generation processing method of total check values and recording / reproducing device specific check values in format types 2 and 3;
FIG. 39 is a diagram showing a processing flow of content download processing in format types 0 and 1;
FIG. 40 is a diagram showing a processing flow of content download processing in format type 2;
FIG. 41 is a diagram showing a processing flow of content download processing in format type 3;
FIG. 42 is a diagram showing a processing flow of content reproduction processing in format type 0.
FIG. 43 is a diagram showing a processing flow of content reproduction processing in format type 1;
44 is a diagram showing a processing flow of content reproduction processing in format type 2. FIG.
45 is a diagram showing a processing flow of content reproduction processing in format type 3. FIG.
FIG. 46 is a diagram (part 1) illustrating a content creator and a check value generation and verification method performed by the content verifier;
FIG. 47 is a diagram (part 2) illustrating a content creator and a check value generation and verification method performed by the content verifier;
FIG. 48 is a diagram (No. 3) for explaining a content creator and a method for generating and verifying a check value by the content verifier.
FIG. 49 is a diagram for describing a method for individually generating various keys using a master key.
FIG. 50 is a diagram (example 1) illustrating a processing example in a content provider and a user regarding a method for individually generating various keys using a master key.
FIG. 51 is a diagram (example 2) illustrating a processing example in a content provider and a user regarding a method of individually generating various keys using a master key.
FIG. 52 is a diagram for describing a configuration for executing usage restriction by using different master keys.
FIG. 53 is a diagram (example 3) illustrating a processing example in a content provider and a user regarding a method of individually generating various keys using a master key.
FIG. 54 is a diagram (example 4) illustrating a processing example in a content provider and a user regarding a method of individually generating various keys using a master key.
FIG. 55 is a diagram (example 5) illustrating a processing example in a content provider and a user regarding a method of individually generating various keys using a master key.
FIG. 56 is a diagram showing a processing flow for storing an encryption key to which triple DES is applied using a single DES algorithm;
FIG. 57 is a diagram showing a content reproduction processing flow (example 1) based on the priority order;
FIG. 58 is a diagram illustrating a content reproduction processing flow (example 2) based on priority.
FIG. 59 is a diagram showing a content reproduction processing flow (example 3) based on the priority order;
[Fig. 60] Fig. 60 is a diagram for describing a configuration for executing a compression (decompression) process of compressed data in a content reproduction process.
[Fig. 61] Fig. 61 is a diagram illustrating a configuration example (example 1) of content.
[Fig. 62] Fig. 62 is a diagram illustrating the playback processing flow in Content Configuration Example 1.
[Fig. 63] Fig. 63 is a diagram illustrating a configuration example (example 2) of content.
[Fig. 64] Fig. 64 is a diagram illustrating a playback processing flow in Content Configuration Example 2.
[Fig. 65] Fig. 65 is a diagram illustrating a configuration example (example 3) of content.
FIG. 66 is a diagram showing a playback processing flow in Content Configuration Example 3;
[Fig. 67] Fig. 67 is a diagram illustrating a configuration example (example 4) of content.
[Fig. 68] Fig. 68 is a diagram showing a playback processing flow in Content Configuration Example 4.
FIG. 69 is a diagram for describing save data generation and storage processing;
FIG. 70 is a diagram showing a processing flow relating to a save data storage processing example (Example 1);
FIG. 71 is a diagram showing a data management file configuration (example 1) used in save data storage and playback processing;
FIG. 72 is a diagram showing a process flow relating to a save data reproduction process example (example 1);
FIG. 73 is a diagram showing a processing flow relating to a save data storage processing example (example 2);
74 is a diagram showing a process flow relating to a save data reproduction process example (example 2); FIG.
FIG. 75 is a diagram showing a process flow relating to a save data storage process example (Example 3);
FIG. 76 is a diagram showing a data management file configuration (example 2) used in save data storage and playback processing;
FIG. 77 is a diagram showing a process flow relating to a save data reproduction process example (example 3);
FIG. 78 is a diagram showing a process flow relating to a save data storage process example (example 4);
FIG. 79 is a diagram showing a process flow relating to a save data reproduction process example (example 4);
FIG. 80 is a diagram showing a process flow relating to a save data storage process example (Example 5);
FIG. 81 is a diagram showing a data management file configuration (example 3) used in save data storage and playback processing;
FIG. 82 is a diagram illustrating a process flow relating to a save data reproduction process example (example 5);
FIG. 83 is a diagram showing a process flow relating to a save data storage process example (Example 6);
84 is a diagram showing a data management file configuration (example 4) used in save data storage and playback processing; FIG.
FIG. 85 is a diagram showing a process flow relating to a save data reproduction process example (Example 6);
[Fig. 86] Fig. 86 is a diagram for explaining an unauthorized content user exclusion (revocation) configuration.
FIG. 87 is a diagram illustrating a processing flow (example 1) of content unauthorized user exclusion (revocation);
FIG. 88 is a diagram illustrating a processing flow (example 2) of content unauthorized user exclusion (revocation);
FIG. 89 is a diagram illustrating a configuration (example 1) of a security chip.
FIG. 90 is a diagram showing a process flow in a security chip manufacturing method.
FIG. 91 is a diagram illustrating a configuration (example 2) of a security chip.
FIG. 92 is a diagram showing a processing flow in data writing processing in a security chip (example 2).
FIG. 93 is a diagram showing a process flow of a write data check process in a security chip (example 2).
[Explanation of symbols]
106 Main CPU
107 RAM
108 ROM
109 AV processing section
110 Input processor
111 PIO
112 SIO
300 recording / reproducing device
301 Control unit
302 Cryptographic processing unit
303 Recording device controller
304 Reading unit
305 communication unit
306 Control unit
307 internal memory
308 Encryption / decryption unit
400 recording device
401 Cryptographic processing unit
402 External memory
403 control unit
404 Communication Department
405 Internal memory
406 Encryption / Decryption Unit
407 External memory control unit
500 media
600 Communication means
2101, 2102, 2103 Recording / reproducing device
2104, 2105, 2106 Recording device
2901 Command Number Manager
2902 Command register
2903, 2904 Authentication flag
3001 Speaker
3002 Monitor
3090 memory
3091 Content Analysis Department
3092 Data storage unit
3093 Program storage unit
3094 Compression / decompression processor
7701 Content data
7702 Revocation List
7703 List check value
8000 Security chip
8001 Processing unit
8002 Storage unit
8003 Mode signal line
8004 Command signal line
8201 Read / write combined area
8202 Write-only area

Claims (2)

A data storage unit comprising a non-volatile memory;
A processing control unit that executes control of data writing and reading processing to the data storage unit;
A mode signal line for setting a mode for writing and reading data to the data storage unit ;
A signal line for connecting an external device for performing data writing and reading processing on the data storage unit;
An authentication information storage unit storing authentication processing data;
The processing control unit
The mode signal line is set to a data writing or reading mode, and
Data writing processing or data to the data storage unit by the external device only when authentication is established in the authentication processing using the authentication processing data between the external device connected by the signal line and the data storage element Perform control to allow data reading from the storage unit ,
The processing control unit further has a configuration in which encryption processing using an encryption key stored in the data storage unit is executed on write data from an external device and output to the external device. A data storage element. A data processing device having a data storage element;
The data storage element is
A data storage unit comprising a non-volatile memory;
A processing control unit that executes control of data writing and reading processing to the data storage unit;
A mode signal line for setting a mode for writing and reading data to the data storage unit ;
A signal line for connecting an external device for performing data writing and reading processing on the data storage unit;
An authentication information storage unit storing authentication processing data;
The processing control unit
The mode signal line is set to a data writing or reading mode, and
Data writing processing or data to the data storage unit by the external device only when authentication is established in the authentication processing using the authentication processing data between the external device connected by the signal line and the data storage element Perform control to allow data reading from the storage unit ,
The processing control unit further has a configuration in which encryption processing using an encryption key stored in the data storage unit is executed on write data from an external device and output to the external device. A data processing apparatus having a data storage element.

Images