JP2008035397A - 暗号情報処理方法および暗号情報処理装置 - Google Patents

Abstract

【課題】ＡＡＣＳにおけるＭＫＢ処理の冗長性低減とその処理の簡略化をはかる。
【解決手段】メディアキーＫｍと乱数データＢＮからプロテクテッドエリアキーＫｐａを生成し、暗号化されたタイトルキーＫｔｅを含むタイトルキーファイルＴＫＦとプロテクテッドエリアキーＫｐａから、コンテンツの暗号化または復号化に用いるタイトルキーＫｔを生成する方法において、タイトルキーＫｔを利用する機器に、メディアキーＫｍに対応する独自保護された暗号化メディアキーＥｎｃ＿Ｋｍを保持する（ＳＴ２５０）。この機器は、保持された暗号化メディアキー（Ｅｎｃ＿Ｋｍ）を適宜利用する（ＳＴ２１０イエス、ＳＴ２１２〜ＳＴ２１４）。
【選択図】 図１０

Description

この発明は、暗号鍵等を利用した情報アクセス管理に関する。特に、高度機密情報（Highly Confidential Data）の保護に利用される暗号情報の処理方法に関する。

近年、ディスクメディア等に記録されたコンテンツにアクセスするデジタル機器が種々開発されている。このような機器でアクセスされるディスクに記録されたデータには、不正アクセスあるいは違法コピーを防止するため、暗号化処理が施されている。この暗号化されたデータには、ＤＶＤ（Digital Versatile Disc）では主にＣＳＳ（Content Scramble System）方式に準拠した暗号化方式が採用されている。

一方、より高度な暗号化方式として、ＡＡＣＳ（Advanced Access Content System）が提案されている（特許文献１）。このＡＡＣＳ方式を採用する場合、例えばセットメーカーは、ライセンサーが持つ鍵ツリーから特定の鍵セットを入手し、異なる組み合わせの鍵を暗号化して、個々の機器に組み込んでいる。

また、アプリケーションプログラムからＤＶＤメディアに対して認証要求があるとＤＶＤメディア用のＭＫＢ（Media Key Block）の代わりにメモリカード用の最新のＭＫＢをＤＶＤメディアから読み出してアプリケーションプログラムに渡す、といった方法の提案もなされている（特許文献２）。
特開２００５−３９４８０号公報 特開２００１−２５６１１３号公報

ＡＡＣＳでは、コンテンツを正当に記録再生する機器毎に付与されたデバイス鍵とランダムに発生させた乱数とにより、複数の鍵それぞれを暗号化して乱数とともに鍵ファイルに登録して、メディアに記録する。コンテンツを再生する場合には、この鍵ファイルに登録されている暗号化鍵を、乱数と再生しようとする機器のデバイス鍵とで復号化する。そして、復号化された鍵でコンテンツを復号化して、コンテンツを再生する。

ＡＡＣＳでは、上記コンテンツ復号化のための鍵（Title Key：Ｋｔ）を得る過程に、メディアキーブロック（Media Key Block：ＭＫＢ）を処理してメディアキー（Media Key：Ｋｍ）を生成する処理が入る。このＭＫＢの処理は、同一のＭＫＢについて繰り返し行なわれる可能性が高いため、毎回処理していては冗長である。

この発明の課題の１つは、ＡＡＣＳにおけるＭＫＢ処理の冗長性を減らし処理の簡略化をはかることである。

この発明の一実施の形態に係る方法は、メディアキー（Media Key：Ｋｍ）と乱数データ（Binding Nonce：ＢＮ）からプロテクテッドエリアキー（Protected Area Key：Ｋｐａ）を生成し、暗号化されたタイトルキー（Encrypted Title Key：Ｋｔｅ）を含むタイトルキーファイル（Title Key File：ＴＫＦ）と前記プロテクテッドエリアキー（Ｋｐａ）から、コンテンツの暗号化または復号化に用いるタイトルキー（Title Key：Ｋｔ）を生成する際に用いられる。

この方法において、前記タイトルキー（Ｋｔ）を利用する機器（HD_DVD Recorder等）に、前記メディアキー（Ｋｍ）に対応する独自保護された暗号化メディアキー（Ｅｎｃ＿Ｋｍ）を保持する（図９のＳＴ１４１等）。そして、前記メディアキー（Ｋｍ）が前記独自保護とは異なる方法（ＡＡＣＳ）で暗号化されて記録された情報をメディアキーブロック（ＭＫＢ）とし、前記機器により記録または再生が行われるメディア（光ディスク）は前記メディアキーブロック（ＭＫＢ）を持ち、このメディアが持つメディアキーブロック（ＭＫＢ）を更新するために前記機器上にメディアキーブロック（ＭＫＢ）の情報が保持されているときに、前記機器が前記保持された暗号化メディアキー（Ｅｎｃ＿Ｋｍ）を利用する（図９のＳＴ１４０〜ＳＴ１４８等）。

ＡＡＣＳを用いた機器が、独自保護された暗号化メディアキーを保持することにより、その機器におけるＭＫＢの処理を簡略化できる。

以下、図面を参照してこの発明の種々な実施の形態を説明する。光ディスク等の情報記録媒体に対して情報を記録する場合、情報を暗号化して記録することが要求される場合がある。その場合、例えば著作権保護されたコンテンツを暗号鍵で暗号化して暗号化コンテンツとし、さらに暗号化に用いた前記暗号鍵を秘匿させるため、他の暗号鍵で暗号化して暗号化鍵としている。そして前記暗号化鍵と暗号化コンテンツを一緒に記録媒体に記録し、違法コピー防止している。

現在、急速にマーケットを拡大しているＤＶＤ（Digital Versatile Disc）では、著作権保護に関して、次のような対応が図られている。即ち、ＤＶＤビデオでは、ＤＶＤ ＣＣＡ（DVD Copy Control Association）がライセンスしているＣＳＳ（Content Scramble System）方式を利用しており、ＤＶＤオーディオではＣＰＰＭ（Content Protection for Prerecorded Media）方式を利用している。また、記録メディアに記録されるコンテンツの著作権保護方式ではＣＰＲＭ（Content Protection for Recordable Media）方式が利用されている。ＣＰＰＭ方式とＣＰＲＭ方式のライセンスは、特定の団体（例えば４Ｃ Ｅｎｔｉｔｙ， ＬＬＣと称される団体）が行っている。

一方では、更に高精細映像や高品質多チャネル音声信号などを記録再生可能とする、大容量の次世代ＤＶＤ等の開発が進められている。このような次世代記録媒体へ高品位著作物を記録する場合の著作権保護方式は、従来以上にセキュリティー能力を高めた方式の導入が要求されている。その具体例として、ＡＡＣＳ（Advanced Access Content System）方式がある。以下、ＨＤ＿ＤＶＤ−ＶＲ（High Density Digital Versatile Disc Video Recording）フォーマットで採用するコンテンツ保護技術であるＡＡＣＳにおけるコンテンツ鍵の管理方法を説明する。

従来のＣＰＲＭ方式では、ディスクの中に存在するメディアキーブロック（ＭＫＢ）とメディアＩＤ（Media ID）を用いて暗号鍵を生成してコンテンツを暗号化していた。一方、ＡＡＣＳ方式では、ディスク内のコンテンツは共通の１つの暗号鍵ではなく、コンテンツ毎の暗号鍵によって暗号化されている。

図１はメディア１００内のデータの構成例を示す図である。この例では、同一のメディア内には、ＭＰＥＧ２−ＰＳなどの形式のコンテンツであるビデオオブジェクト（ＶＯＢ）、ＭＰＥＧ２−ＴＳなどの形式のコンテンツであるストリームオブジェクト（ＳＯＢ）をそれぞれ規格上最大１９９８個保存することが可能となっている。従来の方式ではこれらの全オブジェクトで１つの暗号鍵を使用しているが、ＡＡＣＳ方式ではコンテンツ毎にそれぞれ異なる暗号鍵によって暗号化がなされている。そしてこのコンテンツごとの暗号鍵はタイトルキーファイル（ＴＫＦ）に記憶されている。即ち、ビデオオブジェクト用タイトルキーファイルとストリームオブジェクト用タイトルキーファイルが設けられ、それぞれのタイトルキーファイルには暗号化されたタイトルキー（Encrypted Title Key：Ｅ−ＴＫ、またはＫｔｅ）が最大１９９８個保存可能となっている。

図２は、メデイア１００に記録された暗号化コンテンツ（Encrypted Contents）を復号する処理を説明する図である。図２には、コンテンツなどを記録したメディア１００に格納されている情報と、情報記録再生装置２００に設けられた処理機能及びそれらの間のデータの流れを表している。

ＨＤ＿ＤＶＤ Video Recording Formatで採用するコンテンツ保護技術はＡＡＣＳである。ＡＡＣＳにおけるコンテンツ鍵の管理方法を図２を用いて説明する。ＡＡＣＳ処理で使用するディスクの上書き換え不能な領域に記録されているデータには、
・Media ID
・Lead-in MKB
がある。

一方、ＡＡＣＳ処理で使用するものであってディスク１００上でファイルとして存在するデータには、
・Read Write MKB
・Title Key File
・Title Usage File
がある。またTitle Key Fileの先頭アドレスのプロテクト領域にはBinding Nonceという乱数を基にしたデータが記録されている。

ＡＡＣＳでは、コンテンツを暗号化するための「タイトル鍵（Ｋｔ）」を生成する処理は、大きくいって、次の順番で実行される。すなわち、まずLead-in MKBとRead Write MKBのバージョンの新しいほうを使用してＭＫＢ処理を行う。この処理で生成される鍵を「メディア鍵（Ｋｍ）」と呼ぶ。このメディア鍵ＫｍとBinding Nonce（ＢＮ）を入力としてProtected Area Key処理（Ｋｐａ処理）を行うと「プロテクテッドエリアキー（Ｋｐａ）」が生成される。このＫｐａとTitle Usage FileのデータとTitle Key Fileのデータを入力としてTitle Key処理（ＴＫ処理）を行うことで、Title Key Fileに記載されている暗号化されたタイトル鍵（Encrypted Title Key）を本来のタイトル鍵Ｋｔに変換することができる。

ＭＫＢとはMedia Key Blockと呼ばれるデータであり、メディア鍵Ｋｍが暗号化されて記録されたものである。またＭＫＢには不正機器の情報も記録されており、不正機器はＫｍを取り出すことができないようになっている。不正機器の情報は更新されるため、ＭＫＢも新しいものを使うようにする必要がある。このためＨＤ＿ＤＶＤのＡＡＣＳでは、メディアのLead-in Areaに埋め込まれているLead-in MKB、ディスク上にファイルとして保存されているRead Write MKB、及び機器自体が内部の不揮発メモリに保存するＭＫＢ（以後、Device MKBとする）の３種類のＭＫＢが存在し、このうちもっとも新しいＭＫＢをRead Write MKBに上書きすることが定められている。但し、ＭＫＢが新しいものに更新されるということはＫｍの値が変更されることになるため、Ｋｍ以降のすべての鍵情報（Ｋｐａ等）は再生成する必要がある（なお、Ｋｔは再生成の必要はないがＴＫＦは再生成（再暗号化）の必要がある）。

なお、図２の情報記録再生装置２００には、制御部２１０、読み出し部２２０、書込み部２３０が設けられている。制御部２１０は、図２に示す情報記録再生装置２００の各機能及び各処理動作を制御する。読出し部２２０は、メディア１００よりデータを情報記録再生装置２００に読み込む。書込み部２３０は、情報記録再生装置２００内のデータをメディア１００に書き込む。

メディア１００の読み取り専用リードイン領域にはLead-in MKB（Media Key Block）が格納され、書き換え可能領域であるUser Data AreaにはRead Write MKBが格納されている。ＭＫＢは、コンテンツ暗号化のベース鍵であるメディアキー（Ｋｍ）を、情報記録再生装置２００に秘密鍵として設置されるデバイスキー（Ｋｄ）の集合体で暗号化して数学的体系を整えた、「メディアキーブロック」である。

図２のＳ１０において、メディア１００に記録されているLead-in MKBとRead Write MKBのバージョンを比較して、Read Write MKB のバージョンが、Lead-in MKBのバージョン以上であることを確認した上で、Read Write MKBをMedia MKBとして読み出す。また、メディア１００にLead-in MKBのみしか存在しない場合には、Lead-in MKBをMedia MKBとして読み出す。そして、Ｓ１１において情報記録再生装置２００で保存されているデバイスキーセット（Set of Device KeysあるいはDevice Key Set）とMedia MKBとを用いてＭＫＢ処理を行う。このデバイスキーセットは、複数のデバイスキーＫｄで構成されている。

ここで、ＭＫＢにはプロテクテッドエリアキー（Ｋｐａ）を生成するための情報が暗号化されて保存されているが、そのほかに、リボーク情報（Revoke Information：取消情報あるいは無効化情報）も含まれている。即ち、あるデバイスキーセットにセキュリティホールが存在し、ライセンサが該当するデバイスキーＫｄを使用禁止としたときは、該当するデバイスキーＫｄに関するリボーク情報が記載される。このリボーク情報によって、該当するデバイスキーＫｄを持ったデバイスでは暗号を解くことができなくなる（つまりリボークされた情報を再生できなくなる）。不正機器の情報は時間経過に伴い漸次更新されるため、ＭＫＢも新しいもの（最新の更新されたＭＫＢ）を使うようにする必要がある。そのため上述のようにバージョンの新しいほうをMedia MKBとして使用する。

このＭＫＢ処理によって、メディア鍵（Ｋｍ）が生成される。図２のＳ１２において、生成されたメディア鍵を検証する。生成されたメディア鍵が検証結果不正である場合は、デバイスキーセットが不正であるとみなして、ＡＡＣＳに関する処理を終了する。

一方、タイトルキーファイル（ＴＫＦ）の先頭アドレスのプロテクト領域には、Binding Nonceというファイルと結合した「乱数を基にしたデータ」が記録されている。このBinding Nonceは、例えば、ＰＣ（パソコン）のWrite命令ではコピー不可であり、ＡＡＣＳで定義された命令のみによってコピーが可能である。このように、ＡＡＣＳのライセンスを受けたハードでのみコピー可能とすることで、ＰＣを介した情報の流出を防いでいる。

次に、図２のＳ１３において、ＫｍとBinding Nonceを用いて、暗号処理であるＫｐａ処理を実施する。このＫｐａ処理には、暗号アルゴリズムであるＡＥＳ（Advanced Encrypted Standard）−Ｇを用いる。このＫｐａ処理の結果としてプロテクテッドエリアキー（Ｋｐａ）が生成される。

次に、Ｋｐａからタイトルキー（ＴＫ）を生成するための、タイトルキー処理について説明する。この処理は図２のＳ１４で示されている。タイトルキーファイル（ＴＫＦ）には、ＴＫＦＮ（Title Key File Nonce）という乱数データが記憶されている。このＴＫＦＮは暗号化処理（後述）において、タイトルキーを暗号化するために用いられた乱数データである。また、ディスク１００にはコンテンツの利用規則を記述したTitle Usage Fileが備わっている。このTitle Usage Fileには、複数の使用規則それぞれについて、その使用規則を適用するか否かの情報（Usage Rule）が、０または１のＢｉｔ情報として記述されている。

さらに、ディスク１００のリードイン領域より内側に設けられた読取専用のバーストカッティングエリア（ＢＣＡ）には、Media IDが記録されている。Media IDは、メディア毎に付加されている固有ＩＤである。そして、書き換え可能領域であるユーザデータエリアには、Media IDを用いた改ざん防止コードＭＡＣ（Message Authentication Code）であるMedia ID MACが格納されている。

図２のＳ１４に示すタイトルキー処理では、上述のUsage Ruleを処理した結果とＫｐａとＴＫＦＮとに基いてＡＥＳ−Ｄのアルゴリズムを用いた処理を行い、暗号化されたタイトルキー（Ｅ−ＴＫまたはＫｔｅ）を復号してタイトルキー（ＴＫ）を生成する。なお、この際ＢＣＡに格納されているMedia IDを用いて生成したＭＡＣと、ディスクに格納されているMedia ID MACとを比較して改ざんがなされていないことが検証される。図２のＳ１５において、このようにして生成されたＴＫと暗号化されたコンテンツ（Encrypted contents）とをＡＥＳ−Ｇのアルゴリズムで処理してコンテンツキーを生成し、Ｓ１６において、このコンテンツキーを用いて暗号化されたコンテンツ（Encrypted contents）を復号してコンテンツを生成する。

図３は、コンテンツを暗号化してHD_DVD-R/RW/RAM等の光ディスク１００に記録する処理を説明する図である。なお、使用する用語は図２と同一であるため、重複する説明は省略する。図３のＳ２０において、メディア１００に記録されているLead-in MKBとRead Write MKBのバージョンを比較して、バージョンの新しいＭＫＢをMedia MKBとして読み出す。次に、Media MKBと、情報記録再生装置２００が保有するDevice MKBとのバージョンを比較する。Device MKBのバージョンの方が新しい場合は、Ｓ２１において、ＭＫＢ更新処理を起動しRead Write MKBにDevice MKBの値を更新する。但し、Media MKBのバージョンの方が新しい場合にDevice MKBの値を更新するかどうかは、セット仕様となる。そして、図３のＳ２２において、情報記録再生装置２００で保存されているデバイスキーセットとMedia MKBとを用いてＭＫＢ処理を行う。このＭＫＢ処理によって、メディア鍵（Ｋｍ）が生成される。

図３のＳ２３において、生成されたメディア鍵を検証し、生成されたメディア鍵が検証結果不正である場合は、デバイスキーセットが不正であるとみなしてＡＡＣＳに関する処理を終了する。一方、図３のＳ２４において、ＫｍとBinding Nonceとを用いて、暗号処理であるＫｐａ処理を実施する。ＡＥＳ−Ｇを用いたＫｐａ処理の結果としてプロテクテッドエリアキー（Ｋｐａ）が生成される。

図３のＳ２５において、タイトルキー（ＴＫ）とコンテンツとをＡＥＳ−Ｇのアルゴリズムで処理してコンテンツキーを生成する。そして、Ｓ２６において、このコンテンツキーを用いてコンテンツを暗号化してEncrypted contentsを生成し、メディア１００に記録する。また、Ｓ２７において、Media IDとＴＫとを用いてＭＡＣを生成し、メディア１００にMedia ID MACとして格納する。一方、Ｓ２８において、タイトルキーを暗号化するために用いられる乱数データを生成し、Title Key File Nonceとしてメディア１００に記録する。そして、Ｓ２９において、Usage Ruleをハッシュ処理（公知技術）した結果とＫｐａとＴＫとに基いてＡＥＳ−Ｅのアルゴリズムを用いた処理を行い、暗号化されたタイトルキー（Ｅ−ＴＫまたはＫｔｅ）を生成してメディア１００に格納する。なお、Usage RuleはＳ３０においてメディア１００に記録する。

上述のように、コンテンツの暗号化、復号化においてはタイトルキー等が重要な役割を担っている。しかし、このタイトルキー等はRead/Write可能なファイルとしてメディア１００に記録されているため、メディア表面が例えば指紋などで汚れた場合、簡単にコンテンツの読み出し不能の状態に至るおそれがある。そこで、ＡＡＣＳではこれらのタイトルキー等の情報を格納したタイトルキーファイル（ＴＫＦ）についてバックアップが図られている。

図４は、タイトルキーファイルとそのバックアップファイルとしてのタイトルキーファイルの構造例を示す説明図である。なお、このバックアップ方法の説明では、タイトルキーファイルをＴＫＦ１とし、バックアップファイルとしてのタイトルキーファイルをＴＫＦ２，ＴＫＦ３と表す。なお、ＴＫＦ１〜３は、メディア１００に格納している。

それぞれのタイトルキーファイル（ＴＫＦ１〜３）は、Binding Nonce１〜３（ＢＮ１〜３）と、Title Key File Generation１〜３（ＴＫＦＧ１〜３）と、Title Key File Nonce１〜３（ＴＫＦＮ１〜３）と、Encrypted Title Key１〜３（暗号化タイトルキーＥＴＫ１〜３）とをそれぞれ登録した構成となっている。ここで、Binding Nonce１〜３（ＢＮ１〜３）は、上述のように自身のタイトルキーファイルの暗号化に用いられる乱数データである。Title Key File Generation１〜３（ＴＫＦＧ１〜３）は、タイトルキーファイル（ＴＫＦ１〜３）それぞれの変更回数を表している。Title Key File Nonce〜３（ＴＫＦＮ１〜３）は、自身のタイトルキーファイルまたはバックアップファイル以外のファイルの暗号化タイトルキー（ＥＴＫ１〜３）を生成するための乱数である。

Encrypted Title Key１〜３（暗号化タイトルキー：ＥＴＫ１，ＥＴＫ２，ＥＴＫ３）は、次の（eq.1）〜（eq.3）式で示される：
ＥＴＫ１＝f（ＴＫ，Ｋｐａ１，ＴＫＦＮ３） …（eq.1）
ＥＴＫ２＝f（ＴＫ，Ｋｐａ２，ＴＫＦＮ１） …（eq.2）
ＥＴＫ３＝f（ＴＫ，Ｋｐａ３，ＴＫＦＮ２） …（eq.3）
ここで、Ｋｐａ＝ＡＥＳ−Ｇ（Ｋｍ，ＢＮ）である。また、ＴＫは暗号化されていない平文のタイトルキーを示し、暗号処理関数fは、第１パラメタ（ＴＫ）に第２パラメタ（ＢＮ１〜３）と第３パラメタ（ＴＫＦＮ１〜３）を暗号鍵として暗号処理を施すことを示している。暗号処理fには、たとえばＡＥＳ（Advanced Encryption Standard）などの公知の暗号アルゴリズムを用いればよい。

すなわち、ＴＫＦ１は、ＴＫＦ３と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ１）と、関連づけられたＴＫＦ３の（ＴＫＦＮ３）とで暗号化したものとなっている。また、ＴＫＦ２は、ＴＫＦ１と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ２）と、関連づけられたＴＫＦ１の（ＴＫＦＮ１）とで暗号化したものとなっている。さらに、ＴＫＦ３は、ＴＫＦ２と関連づけられており、タイトルキー（ＴＫ）を、（ＢＮ３）と、関連づけられたＴＫＦ２の（ＴＫＦＮ２）とで暗号化したものとなっている。

このようにタイトルキーファイルＴＫＦ１と各バックアップファイルＴＫＦ２，ＴＫＦ３は、互いに他のファイルと関連付けられており、暗号化タイトルキー（Ｅ−ＴＫ１，Ｅ−ＴＫ２，Ｅ−ＴＫ３）は、自己のファイルに登録された（ＢＮ１，ＢＮ２，ＢＮ２）と、関連づけられている他のファイルに登録されている（ＴＫＦＮ１，ＴＫＦＮ２，ＴＫＦＮ３）とでタイトルキー（ＴＫ）を暗号化したものとなっている。

上記のようにＴＫＦを３つ保存し、ＴＫＦＮを別ファイルに保存することにより、１つのＴＫＦがデータ破損などにより壊れてしまっても、残り２つのＴＫＦのデータから、壊れたデータを復元できる。

なお、前述したBinding Nonceを特殊なドライブ用コマンドでしか読み書きできないデータとしておくことにより、不正コピーを防止できる。すなわち、仮にＴＫＦがコピーされてもそれに付随するBinding Nonceはコピーされないため、悪意のある第三者による不正な暗号化／復号化行為を防ぐことができる。

なお、タイトルキーファイルと各バックアップファイルの他のファイルのＴＫＦＮとの関連づけは、上記（eq.1）〜（eq.3）式に限定されるものではなく、（eq.1）〜（eq.3）式以外のパターンでタイトルキーファイルとバックアップファイルのＴＫＦＮと関連付けるように構成してもよい。

図５、図６、図７を参照しつつ、ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを詳細に説明する。メディア１００上のProtected Area、即ち、Ｅ−ＴＫ（またはＫｔｅ）が格納されているファイルのProtected Areaには、Binding Nonce及びそのバックアップデータが格納されている。また、メディア１００の読取専用エリアにあるＢＣＡ（Burst Cutting Area）にはMedia IDが記録され、リードイン領域にはLead-in MKBが記録されている。

メディア１００上のユーザデータエリアには、ビデオオブジェクト（ＶＯＢ）および／またはストリームオブジェクト（ＳＯＢ）のCopy Protection Pointerに関する情報である管理情報が格納されている。また、ユーザデータエリアには、Read Write MKB、暗号化されたタイトルキー（Ｅ−ＴＫ）、Media ID MAC、Usage Rule及びそれらのバックアップファイルが格納されている。さらに、ユーザデータエリアは、暗号化されたコンテンツが最大１９９８個まで格納が可能となっている。

なお、図７のサイズ欄において“−”となっている個所には、対応情報の実際のサイズを記載することができる。例えば、Read/Write MKBというデータのサイズ欄にはこのRead/Write MKBの実サイズを記載できる。

図８は、暗号化されたタイトルキーファイル（Ｅ−ＴＫＦ）の構造を示している。なお、図８はストリームオブジェクト（ＳＯＢ）についてのＥ−ＴＫＦの構造であるが、ビデオオブジェクト（ＶＯＢ）についても同様の構造である。バイト位置でいって０〜１５バイトには、タイトルキーファイルを特定するための固定情報（ＳＴＫＦ＿ＩＤ、ＨＲ＿ＳＴＫＦ＿ＥＡ）が記載され、３２〜３３バイトの“ＶＥＲＮ”には、ＴＫＦのバージョン番号が記載されている。

そして、１２８〜１４３バイトには、Title Key File Generationが格納され、１４４〜１５９バイトにはTitle Key File Nonceが格納されている。また、１６０〜６４０９５バイトには、Title Key Information（ＫＴＩ）として、暗号化されたタイトルキー（Ｅ−ＴＫ、またはＫｔｅ）とMedia ID MACとが１９９８組記載されている。

それぞれのコンテンツはこの１９９８個のタイトルキーのうちの１つの鍵を使って暗号化されている。但し、１９９８個すべてにEncrypted Title Keyを記録しておく必要は無く、未使用のものは０という数値をＴＫ処理で暗号化したものを記述する。またTitle Key File Generationにはこのファイルの更新のたびにインクリメントされる値が記されている。上述のようにタイトルキーファイルはバックアップ用に合計３つのファイルを備えている。そしてこの３つのファイルのTitle Key File Generationの値がすべて一致していない場合、ファイル書き込み中に何らかの障害があったことを意味する。

次にタイトルキーファイルの更新方法について説明する。ＡＡＣＳが適用されるメディアの種類には、リライタブルメディアとライトワンスメディアがある。リライタブルメディアでは、例えば、新しいコンテンツが追加記録される毎に新しいタイトルキーが追加されるため、タイトルキーファイル中の全タイトルキーを新しいＫｐａを用いて再暗号化する必要がある。即ち、タイトルキーファイルの更新が必要となる。

ところで、タイトルキーファイルのプロテクト領域には、Binding Nonceという乱数を基にした数値が記載されているが、このBinding Nonceは不正な暗号解除を防止するために使用されるものであり、従って、Binding Nonceもタイトルキーファイルを更新する都度、更新される。

一方、ライトワンスメディアでは、タイトルキーファイルを更新すると毎回新しいアドレスにタイトルキーファイルが書き込まれることになる。このためBinding Nonceの書き込まれるアドレスも毎回異なる。しかし、ＡＡＣＳではBinding Nonceは同一個所に上書きすることが求められているため、ライトワンスメディアの場合は、タイトルキーファイルの更新を行わないようにしなければならない。従って、リライタブルメディアとライトワンスメディアでは、タイトルキーファイルの更新条件が異なることになる。

図８のTitle Key Fileの中には１９９８個の暗号化されたタイトル鍵（Encrypted Title Key）が記録されている。コンテンツはこの１９９８個のうちの1つの鍵を使って暗号化されている。１９９８個すべてにEncrypted Title Keyを記録しておく必要は無く、未使用のものは“０”という数値をＴＫ処理で暗号化したものを記述することになっている。またTitle Key File Generationにはこのファイルの更新のたびにインクリメントされる値が記されている。Title Key Fileはタイトル鍵を保存するものであり、メディア上の欠陥等により読めなくなるとコンテンツの再生がまったく不能になる。このためバックアップ用に３つのファイルに書き込んでいる。この３つのファイルのTitle Key File Generationの値がすべて一致していない場合、ファイル書き込み中に何らかの障害があったことを意味する。

メディア１００上のTitle Key Fileが書き込まれているアドレスのプロテクト領域に、Binding Nonceという乱数を基にした数値を記録している。プロテクト領域とはＡＡＣＳ専用の特殊コマンドでのみ読み書きができる領域であり、この部分にＫｐａを構成する要素を記録しておくことで、パソコン等を使った不正な暗号解除を防ぐことができる。

Title Key File内のタイトル鍵は、プロテクテッドエリアキーとTitle Key FileNonce
（ＴＫＦＮ）を組み合わせてＴＫ処理を行うことで暗号化している。このとき、Title Key File#1の暗号化にはTitle Key File#2のTitle Key File Nonceを使い、Title Key File#2の暗号化のTitle Key File Nonceを使う、というようにしている。こうすることにより、３つのTitle Key Fileのうち1つが破損してしまっても、他の２つのファイルを用いることによって復元ができる。このようにTitle Key File Nonceはタイトル鍵の暗号に用いているものであるので、Title Key Fileを更新する都度更新する。

なお、Binding Nonceも、プロテクテッドエリアキーを生成するデータとしてタイトル鍵の暗号に用いているものであるので、同様に、Title Key Fileを更新する都度更新する必要がある。

一方、Binding Nonceはファイルが書き込まれるアドレスに依存しており、HD_DVD-R等のライトワンスメディアの場合、Title Key File自体が毎回新しいアドレスに保存されることになり、Binding Nonceの書き込まれる位置も一箇所ではなくなる。しかしＡＡＣＳではBinding Nonceは同一箇所に上書きすることが求められているので、ライトワンスメディアの場合はTitle Key Fileの更新を行わないようにする。

Title Key Fileには１９９８個の暗号化されたタイトル鍵を保存することが出来る。これはビデオオブジェクト（ＶＯＢ）及びストリームオブジェクト（ＳＯＢ）の個数と一致しており、ビデオオブジェクト毎にタイトル鍵（Ｋｔ）を変えることを前提としている。これは、例えばそのディスクから他のメディアにコンテンツをムーブする場合、使用しているタイトル鍵を消去しないと不正コピーができる抜け穴が残ってしまうためである。タイトル鍵を削除すると、同じタイトル鍵を共用している他のオブジェクトが復号できなくなるので、極力オブジェクトごとに異なる鍵を割り当てる必要がある。このため、録画再生装置においては、1回の録画処理毎にタイトル鍵を新規に生成し、そのタイトル鍵によってビデオオブジェクト及びストリームオブジェクトを暗号化する。

一方、特にストリームオブジェクト（ＳＯＢ）による録画の場合、記録対象のデジタル放送の内容によってストリームオブジェクトを動的に分割する必要がある。具体的には番組の境界で音声ストリームの個数が変わるなどストリームオブジェクト（ＳＯＢ）の構成要素が変わった場合は、自動的にそこでＳＯＢを分割する。このような場合、そこでタイトル鍵を切り替えるのは事実上不可能である（タイトル鍵を切り替えようとすると、新たな鍵の生成に時間を要するため、分割後のＳＯＢの録画を開始する際その先頭部分の録画が欠けてしまう）。このような場合は同じタイトル鍵を使った暗号を引き続き行う。

なお、ディスクがライトワンスメディア（上書きできないメディア）である場合はTitle Key Fileの更新ができないため、録画開始時に鍵を生成する処理において、既に存在するタイトル鍵を用いることになる。

メディア１００としてリライタブルメディア（HD_DVD-RW/RAMあるいはHDD等）を用いる場合において、リライタブルメディアのタイトルキーファイルの更新手続きは、例えば次のようになる。ここで、リライタブルメディアには、既にタイトルキーファイルが生成されて書き込まれているとする。この処理動作は、情報記録再生装置２００の制御部２１０（あるいは後述する図１５の鍵処理制御部２１０もしくは図２１のＣＰＵ１１のファームウエア等）により実現される。

例えばユーザが情報記録再生装置２００の電源をＯＮし、リライタブルメディアを挿入すると、ＭＫＢ処理とＴＫＦ読み込み処理が一括して実行される。ＭＫＢ処理では、Read Write MKB及びLead-in MKBに付加している署名を検証し、検証結果が正当であると判定した場合は、それぞれのＭＫＢのバージョンを取得する。Read Write MKBのバージョンはLead-in MKBのバージョンと同じかもしくは新しくなければならないが、もしそうでない場合は、再生及び記録を制限する。ＴＫＦ読み込み処理では、メディアにあるタイトルキーファイルをＳＤＲＡＭ等の上に展開する。

そして、ユーザのコンテンツ記録操作、コンテンツ編集操作、コンテンツ削除操作、メディア排出操作、情報記録再生装置２００の電源ＯＦＦ操作に対応して、タイトルキーファイルの更新を行うかどうかを判断する。即ち、以下の３つの条件のうちの少なくとも１つが満たされたときのみ、タイトルキーファイルを更新する。

（１）コンテンツの記録、削除が行われた場合
コンテンツの記録、削除が行われると、タイトルキーファイル内のEncrypted Title Keyが新たに追加、削除される。そのため、タイトルキーファイルを更新する。

（２）ＭＫＢが更新された場合
例えば、情報記録再生装置２００の内部で保持しているＭＫＢであるDevice MKBのバージョンがRead Write MKBのバージョンよりも新しい場合、Device MKBの値をRead Write MKBにコピーしてDevice MKBのメディア鍵（Ｋｍ）が変更される。Ｋｍが変更されると、Ｋｐａも更新される。このため、タイトルキーファイルを更新してタイトルキーの再暗号化を行う。

（３）３つのTitle Key File Generationの１つだけが異なる場合
上述のように３つのタイトルキーファイルの内の１つが破損していることになる。そのため、正常な残りの２つのタイトルキーファイルを用いて破損したタイトルキーファイルを修復（更新）する。すなわち、上述の３つの条件のうちの少なくとも１つが成立する場合は、タイトルキーファイルの更新を行う。上述の３つの条件の全てが成立しない場合は、タイトルキーファイルを更新せずに処理を終了する。

メディア１００としてライトワンスメディア（片面１層のHD_DVD-Rあるいは片面２層のHD_DVD-R:DL等）を用いる場合は、ライトワンスメディアのタイトルキーファイルの書込み手続きは例えば次のようになる。この処理動作は、情報記録再生装置２００の制御部２１０等により実行できる。

例えばユーザが情報記録再生装置２００の電源をＯＮし、ライトワンスメディアを挿入すると、ＭＫＢ処理とＴＫＦ読み込み処理が一括して実行される。ＭＫＢ処理では、Read Write MKB及びLead-in MKBに付加している署名を検証し、検証結果が正当であると判定した場合は、それぞれのＭＫＢのバージョンを取得する。Read Write MKBのバージョンはLead-in MKBのバージョンと同じかもしくは新しくなければならないが、もしそうでない場合は、再生及び記録を制限する。ＴＫＦ読み込み処理では、メディアにあるタイトルキーファイルをＳＤＲＡＭ等の上に展開する。

そして、ユーザのコンテンツ記録操作、コンテンツ編集操作、コンテンツ削除操作、メディア排出操作、情報記録再生装置２００の電源ＯＦＦ操作に対応して、タイトルキーファイルの書込みを行うかどうかを判断する。即ち、以下の２つの条件が満たされれば、タイトルキーファイルを書き込む。

（１＊）コンテンツの記録が行われた場合
（２＊）ディスクにタイトルキーファイルが記録されていなかった場合。

ＡＡＣＳではTitle Key Fileを同一箇所に上書きすることが求められているため、ライトワンスメディアの場合は、（１＊）と（２＊）の条件を同時に満たしたときにのみTitle Key Fileを書き込む。そうする理由を以下に述べる。

（１＊）の条件のみでは、コンテンツの記録が行われる度に書き込み要求が起こるため、同一箇所に上書き不可能なライトワンスメディアでは問題となる。（２＊）の条件のみでは、ディスクにコンテンツを記録していない状態では、有効なコンテンツキーは生成されていないため、無効なEncrypted Title KeyのみのTitle Key Fileとなり問題となる。（１＊）と（２＊）の条件を共に満たす場合には、ディスクにTitle Key Fileが記録されていない状態で記録が行われたときに書き込むこととなるため、有効なEncrypted Title Keyが１つだけ生成されたTitle Key Fileが記録されることになる。

上述の２つの条件がともに成立する場合は、タイトルキーファイルをディスクに書き込む。上述の２つの条件が全て成立しない場合は、タイトルキーファイルの書き込みを行わずに処理を終了する。

以上説明した実施の形態によれば、メディア種別ごとにタイトルキーファイルを書き込む条件を設け、その条件に合致するときのみにディスクに書き込む。この条件によれば、リライタブルメディアの場合は無駄にTitle Key Fileを更新することがなくなり、ディスクに書き込む回数を削減することができる。ライトワンスメディアの場合は、問題のあるTitle Key Fileを書き込こんでしまうことを排除することができる。

図１５は、この発明が実施される機器の構成および機器に保持しているIndexデータ等のデータ構造の一例を説明する図である。ここではMediaとしてＭＫＢ（Media Key Block）およびＴＫＦ（Title Key File）が記録された光ディスク１００が用いられる。ディスク１００がディスクドライブ部３００に装填されると、このディスク１００からＭＫＢ、ＴＫＦ等の情報が読み取られる。読み取られたＭＫＢ、ＴＫＦ等の情報（ＡＡＣＳで用いる情報）は鍵処理制御部３１０に送られる。鍵処理制御部（ＡＡＣＳ処理部）３１０は、ＭＫＢ情報等をMedia Key Block保持部３２０に送るとともに、Media Key等を独自保護部３３０に送る。

独自保護部３３０は、（１）デバイス鍵保持部３４０からデバイス鍵等を取り寄せて独自の暗号化を復号し、デバイス鍵等を使用可能な状態にすること、（２）Media Keyに独自の暗号化処理を施すこと、（３）Media Keyの独自の暗号化を復号すること、といった機能を有する（後述する図１７、図１９参照）。独自暗号化処理が施された暗号化Media Keyは、対応するIndexの情報とともに、Media Key/Index保持部（不揮発性メモリ）３５０に格納される。

このMedia Key/Index保持部３５０に格納される情報のデータ構造は、図１５の右側に例示するようになっている。すなわち、図１５に例示されるMedia Key/Index保持部３５０には、先頭から順に、Max_Index_countと、Ｅｎｃ＿Ｋｍポインタと、１以上のインデックスデータ（Index00〜Index4A：この例では各データは８ビットで構成され、２桁のHex-decimalで表記されている）が格納される。Max_Index_countは、現在、機器（図１５の左側のブロック構成）のMedia Key/Index保持部（不揮発性メモリ）３５０に保持しているインデックスデータの数を示す。Ｅｎｃ＿Ｋｍポインタは、Media Key/Index保持部３５０を構成するメモリ上の暗号化メディアキーＥｎｃ＿Ｋｍのデータの開始位置を示すもので、Ｅｎｃ＿Ｋｍポインタは保持しているインデックスデータと同数ある。そして、各インデックスデータは対応する暗号化メディアキーＥｎｃ＿Ｋｍのデータとペアになっている。

Media Key/Index保持部３５０に保持された暗号化Media Keyを利用できる場合では、この暗号化Media Keyを復号化し、復号化されたMedia KeyからタイトルキーＫｔを生成する。このタイトルキーＫｔを用いて、ディスク１００から再生した暗号化コンテンツをコンテンツ復号化／暗号化部３６０で復号化して、コンテンツ再生部３７０に送る。あるいは、前記生成されたタイトルキーＫｔを用いて、コンテンツ受信部（デジタルＴＶチューナ等）３８０からの（ＡＡＣＳで保護しようとする）コンテンツをコンテンツ復号化／暗号化部３６０で暗号化して、ディスクドライブ部３００に送る。送られた暗号化コンテンツはディスク１００に記録される。

図１５のMedia Key/Index保持部３５０にとって必要な条件、およびそこで保持すべき情報は、
・ＭＫＢ上から取得してきたIndexデータであること；
・暗号化された状態のMedia Keyデータであること；
・Media KeyとIndexデータの対応付けがされており、Indexデータの番号から、暗号化Media Keyを取り出す位置が分かること
・現状のIndexの個数が把握でき、適宜Indexを追加できること
である。

また、図１５のMedia Key/Index保持部３５０に対する付帯条件（なるべく満足したい条件）として、
・Indexと暗号化Media Keyの対応関係が維持されていれば、それぞれを並べ替えても、復号処理や新しいIndexの追加に支障をきたさないこと（前後のデータを関連付けた暗号化や、並び順に依存する暗号化はソートに適さない）
がある。
図１５の右側に例示したデータ構造は、上記の必要条件および付帯条件のいずれも満たす構成を採っている。

図１６は、暗号化データの構造の一例を説明する図で、図１５の左側に例示したデータ構造をより詳細に示している。この例では、図１５のMedia Key/Index保持部３５０を構成する不揮発性メモリのアドレスとして、BaseAddressと00000000hや00004000h等のアドレスオフセットとの組み合わせを用いている。先頭のMax_Index_Countから最終のEnc_Kmまでのアドレス範囲にあるデータの格納位置は、BaseAddressを変更することで、メモリ内の任意の位置に容易に配置換えできる。また、このアドレス範囲内において、Enc_KmポインタにリンクするEnc_Kmの格納位置の変更も容易に行うことができる。例えば、Index03に対応するEnc_Kmを取り出す場合には、「BaseAddress + Enc_Kmポインタ + 03h * 10h(Enc_Kmのサイズ)」を先頭アドレスとしてデータを取り出す。この例では、IndexとEnc_Kmとの対応関係は、Indexの並びで規定される「Index番号」に依存している。

上記のように構成すると、以下の利点が得られる：
（イ）IndexとEnc_Kmを離れた場所に置いておくことができる；
（ロ）固定フォーマットではないため、運用上、Index数などが増加した場合にも、最適なアドレスにEnc_Kmのデータを移動させることができる；
（ハ）IndexとEnc_Kmをそれぞれソートして、対応するIndexが上（アドレスの若い方）に来るように操作すれば、使用頻度・優先度の高いEnc_Kmの検索効率を上げることができる。

図１７は、機器に保持される鍵情報（Media Key）の独自暗号化処理の一例を説明する図である。ＡＥＳ一方向性関数処理部（入力128bit：鍵128bit：出力128bit）１７０には、固定値（128bit）１７１と機器に固有の乱数（128bit）１７２が入力される。この乱数１７２としては、例えばＡＡＣＳが機器毎に発行する鍵のセットには鍵の他に乱数値が含まれているので、その値の一部を使用することができる。ＡＥＳ一方向性関数処理部１７０の処理結果は、ＡＥＳ暗号化処理部（入力128bit：鍵128bit：出力128bit）１７３側に出力される。ＡＥＳ暗号化処理部１７３には、Media Key（Km：128bit）１７４が入力される。ＡＥＳ暗号化処理部１７３は、入力された情報を、ＡＥＳ一方向性関数処理部１７０の処理結果を鍵とするＡＥＳで暗号化して、暗号化Media Key（Ｅｎｃ＿Ｋｍ）１７５を出力する（図１９を参照して後述）。

ここで、暗号器自体としてＡＥＳ以外の暗号器（例えばＡＥＳを一部修正した暗号器など）を用いても良いが、必ずしもその必要はない。ＡＡＣＳで使用するＡＥＳを元に、独自に定義した手順と、独自に定めて秘匿されている鍵を用いれば、十分に暗号化Media Keyの保護が可能である。

図１８は、機器に保持される鍵情報（Media Key）の独自復号化処理の一例を説明する図である。ＡＥＳ一方向性関数処理部（入力128bit：鍵128bit：出力128bit）１８０には、固定値（128bit）１８１と機器に固有の乱数（128bit）１８２が入力される。ＡＥＳ一方向性関数処理部１８０の処理結果は、ＡＥＳ復号化処理部（入力128bit：鍵128bit：出力128bit）１８３側に出力される。ＡＥＳ復号化処理部１８３には、暗号化Media Key（Enc_Km：128bit）１８４が入力される。ＡＥＳ復号化処理部１８３は、入力された情報を、ＡＥＳ一方向性関数処理部１８０の処理結果を鍵とするＡＥＳで復号化して、復号されたMedia Key（Km：128bit）１８５を出力する（図２０を参照して後述）。

図１９は、独自暗号化処理手順の一例を説明するフローチャートである。まず、ＭＫＢのIndexとして扱う領域からIndexデータ取得し（ＳＴ７００）、機器に実装している不揮発性メモリ（Media Key/Index保持部３５０）の最大Index番号（図１５のデータ構造におけるMax_Index_Count）をインクリメントする（Max_Index_Countを例えば４Ａｈを４Ｂｈにインクリメントする）（ＳＴ７０２）。次に、機器に実装している不揮発性メモリの最大Index番号位置に、Indexデータを書き込む（ＳＴ７０４）。続いて、入力を「機器に固有の乱数（図１７の１７２）」とし、鍵を「ハードウエアＨＷあるいはファームウエアＦＷ内で秘匿された固定値（図１７の１７１）」として、ＡＥＳ一方向性関数処理（図１７の１７０）を実行する（ＳＴ７０６）。この処理が済んだら、入力を「Media Key（Km）（図１７の１７４）」とし鍵を「ＳＴ７０６の処理の一方向性関数処理結果」として、ＡＥＳ暗号化処理（図１７の１７３）を実行する（ＳＴ７０８）。ＳＴ７０８の処理の暗号化結果が、独自方法で保護された、暗号化Media Key（Enc_Km）（図１７の１７５）となる（ＳＴ７１０）。そして、機器に実装している不揮発性メモリ（Media Key/Index保持部３５０）の「Enc_Kmポインタ＋10h*Index」アドレスに、暗号化Media Key（Enc_Km）を書き込んで（ＳＴ７１２）、Media Keyに対する独自保護処理（暗号化）を終了する。

図２０は、独自復号化処理手順の一例を説明するフローチャートである。まず、Indexの検索結果からIndexアドレスを取得し（ＳＴ８００）、機器に実装している不揮発性メモリ（Media Key/Index保持部３５０）から、Indexアドレスに対応する暗号化Media Key（図１５のデータ構造例に示すようにIndexとペアになっているEnc_Km）を取得する（ＳＴ８０３）。続いて、入力を「機器に固有の乱数（図１８の１８２）」とし、鍵を「ハードウエアＨＷあるいはファームウエアＦＷ内で秘匿された固定値（図１８の１８１）」として、ＡＥＳ一方向性関数処理（図１８の１８０）を実行する（ＳＴ８０６）。この処理が済んだら、入力を「暗号化Media Key（Enc_Km）（図１８の１８４）」とし、鍵を「ＳＴ８０６の処理の一方向性関数処理結果」として、ＡＥＳ復号化処理（図１８の１８３）を実行する（ＳＴ８０８）。ＳＴ８０８の処理の復号化結果が、独自方法の保護が解除されたMedia Key（Km）（図１８の１８５）となる（ＳＴ８１０）。こうして、Media Keyに対する独自保護処理（復号化）を終了する。

図９は、機器またはディスクのＭＫＢ更新処理の一例（機器にＭＫＢ更新機能が実装されている場合）を説明するフローチャートである。（この発明の一実施の形態に係る機器では、ディスクのＭＫＢを更新する機能の実装は必須とし、機器上のＭＫＢを更新する機能の実装はオプションとすることができる。但し、ディスクのＭＫＢを更新する機能の実装および機器上のＭＫＢを更新する機能の実装の双方を必須とする実施の形態も可能である。）
機器（図２、図３、図１５、図２１等）またはディスク１００のＭＫＢ更新時などにおいてＭＫＢ処理が開始されると、まず、ディスク１００よりＭＫＢのバージョン情報を取得する（ＳＴ１１６）。取得したディスクのＭＫＢバージョンと機器上に保持しているＭＫＢのバージョンとを比較する（ＳＴ１１８）。両者のバージョンが異ならない（換言すれば同一である）ときは（ＳＴ１１８ノー）、ＭＫＢ更新せずに処理を終了する。

機器のＭＫＢバージョンの方が新しければ（ＳＴ１１８イエスの場合の１つ）、ディスク１００のＭＫＢを更新する。このとき、ＴＫＦの再暗号化が発生するので、機器のMedia KeyおよびディスクのMedia Keyの両方が必要になる。機器のMedia Keyは独自保護していたものを使用できる（後述するＳＴ１４２参照）。

一方、ディスクのＭＫＢバージョンの方が新しければ（ＳＴ１１８イエスの場合の他の１つ）、機器のＭＫＢを更新する。すなわち、ディスク１００よりＭＫＢを取得し（ＳＴ１２０）、AACS_VerifyＭＫＢのSignatureを検証する（ＳＴ１２２）。このSignature検証については、図２４等を参照して後述する。Signature検証が不可であれば（ＳＴ１２４ノー）、このＭＫＢ処理は異常終了する。Signature検証がＯＫであれば（ＳＴ１２４イエス）、機器上（図１５の例ではデバイス鍵保持部３４０）に保持しているDevice Keyを取得する（ＳＴ１２６）。ＭＫＢ上のDevice Keyに対応する処理可能なノードを探索し、見つかったノードに対応するデータを取得する（ＳＴ１２８）。取得したデータからMedia Key導出演算を行う（ＳＴ１３０）。この演算としては、ＡＥＳ（Advanced Encrypted Standard）の処理を２〜２３回程度行う（ＡＥＳについては図２の説明等参照）。その後ＭＫＢ上のVerification Dataの検証を行い（ＳＴ１３２）、検証に失敗すれば（ＳＴ１３４ノー）、このＭＫＢ処理は異常終了する。このVerification Dataの検証がＯＫであれば（ＳＴ１３４イエス）、ディスク１００のMedia Keyを取得する（ＳＴ１３６）。上記ＳＴ１２０〜ＳＴ１３６の処理（ディスクのMedia Keyを取得する処理）は、図１０以降を参照して説明する処理により簡易化可能となる。

ディスク１００のMedia Keyを取得したあと、そのディスクのＭＫＢバージョンと機器上に保持しているＭＫＢのバージョンとを比較する（ＳＴ１３８）。ディスクのＭＫＢバージョンが機器のＭＫＢのバージョンより新しいときは（ＳＴ１３８イエス）、機器上に保持されているＭＫＢをディスク１００のＭＫＢで更新（上書き）する（ＳＴ１４１）。このとき、機器のＭＫＢを上書きするのに加え、Media Keyを独自保護して、ＭＫＢと共に機器に保持する（ＳＴ１４１）。ここで、機器のＭＫＢのMedia Keyとして独自保護しておくのは１つだけなので、古いMedia Key（独自保護対象のもの）は破棄される。但し、破棄せずに、図１０以降を参照して説明する処理と同様に、過去に処理したMedia Keyの1つとしてIndex管理して残すことは可能である。

ディスク１００のＭＫＢバージョンが機器のＭＫＢのバージョンより新しくないときは（ＳＴ１３８ノー）、機器上の独自保護されたMedia Key（暗号化メディアキーＥｎｃ＿Ｋｍ）を取得し（ＳＴ１４２）、取得したMedia Keyの独自保護を解除する（つまり暗号化されたメディアキーを復号化する）（ＳＴ１４４）。なお、「機器のＭＫＢのMedia Key保持機能」が実装されていない場合（図１５の例で言えばMedia Key/Index保持部３５０が機器に実装されていない場合）は、ここ（ＳＴ１４２）でもう一度Media Key導出処理が必要になる。従い、この「機器のＭＫＢのMedia Key保持機能」は、この発明の実施の形態における重要ポイントの１つとなる。

独自保護が解除されたMedia Keyが得られたあと、ＴＫＦの再暗号化が行われる（ＳＴ１４６）。この再暗号化では、復号鍵としてディスクのMedia Keyが用いられ、暗号鍵として機器に保持していた（独自保護が解除された）Media Keyが用いられる。そして、ディスクのＭＫＢを機器上に保持しているＭＫＢで更新して（ＳＴ１４８）、ディスクのＭＫＢ更新処理が完了する。

なお、機器のＭＫＢを更新する機能を持たない機器の場合では、その機器が製造メーカから出荷される段階で組み込まれたＭＫＢと、対応する独自保護されたMedia Keyが使われ続けることになる。 図１０は、ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の一例を説明するフローチャートである。まず、ディスク１００からＭＫＢのIndex情報を取得し（ＳＴ２０６）、機器上のMedia Key/Index保持部３５０内に保持しているIndex情報を検索する（ＳＴ２０８）。検索対象に対応するIndexがMedia Key/Index保持部３５０内にあれば（ＳＴ２１０イエス）、そのIndexに対応する機器上の独自保護されたMedia Key（図１５のデータ構造例では、例えばIndex02に対応するEnc_Km02）を取得する（ＳＴ２１２）。そして取得したMedia Keyの独自保護を解除して（つまり暗号化されたメディアキーを復号化するなどして）（ＳＴ２１４）、ＭＫＢ処理を終える。これにより、冗長性の少ない簡素化された処理（ＳＴ２１２〜ＳＴ２１４）で、Media Keyの取得が完了する。

検索対象に対応するIndexがMedia Key/Index保持部３５０内にないときは（ＳＴ２１０ノー）、ディスク１００からＭＫＢを取得し（ＳＴ２２０）、AACS_VerifyＭＫＢのSignatureを検証する（ＳＴ２２２）。このSignature検証は図９のＳＴ１２２における検証と同様である。

Signature検証が不可であれば（ＳＴ２２４ノー）、このＭＫＢ処理は異常終了する。この場合は、Media Keyは未取得となる。Signature検証がＯＫであれば（ＳＴ２２４イエス）、図９のＳＴ１２６〜ＳＴ１３４と同様な処理（ＳＴ２３６〜ＳＴ２４４）を行い、Verification Dataの検証がＯＫであれば（ＳＴ２４４イエス）、ＭＫＢ処理が終了し、これによりMedia Keyの取得が完了する。こうして取得したMedia Keyに対して、Media Key保持処理が実行される（ＳＴ２５０）。すなわち、ＭＫＢからIndexを取得し（ＳＴ２５２）、Media Keyを独自保護方法で秘匿（暗号化）する（ＳＴ２５４）。そして、取得済みのIndexと独自暗号化で秘匿したMedia Keyとのペアを、順次、Media Key/Index保持部３５０内に保存（累積）する（ＳＴ２５６）。この保存を繰り返すと、図１５の右側に示すようなデータ構造の情報がMedia Key/Index保持部３５０内に保持されるようになる。

図１１は、ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャートである。まず、ディスク１００からＭＫＢのIndex情報を取得し（ＳＴ３００）、AACS_VerifyＭＫＢのSignatureを検証する（ＳＴ３０２）。このSignature検証は図９のＳＴ１２２における検証と同様である。

Signature検証が不可であれば（ＳＴ３０４ノー）、このＭＫＢ処理は異常終了する。この場合は、Media Keyは未取得となる。Signature検証がＯＫであれば（ＳＴ３０４イエス）、図１０のＳＴ２０６〜ＳＴ２１４、ＳＴ２３６〜ＳＴ２４４と同様な処理（ＳＴ３０６〜ＳＴ３１４、ＳＴ３３６〜ＳＴ３４４）を行い、Verification Dataの検証がＯＫであれば（ＳＴ３４４イエス）、ＭＫＢ処理が終了し、これによりMedia Keyの取得が完了する。こうして取得したMedia Keyに対して、Media Key保持処理が実行される（ＳＴ３５０）。

なお、Media Keyが取得できるのはＳＴ３１０の判定結果がイエスのときとノーのときの２通りある。そのうち、ＳＴ３５０の処理が実行されるのは、ＳＴ３１０の判定結果がノーであり、その後にMedia Keyが取得できた場合だけである。その場合、ＭＫＢからIndexを取得し（ＳＴ３５２）、Media Keyを独自保護方法で秘匿（暗号化）する（ＳＴ３５４）。そして、取得済みのIndexと独自暗号化で秘匿したMedia Keyとのペアを、順次、Media Key/Index保持部３５０内に保存（累積）する（ＳＴ３５６）。この保存を繰り返すと、図１５の右側に示すようなデータ構造の情報がMedia Key/Index保持部３５０内に保持されるようになる。なお、図１１のＳＴ３３６以降の処理（ＳＴ３３６〜ＳＴ３４４）は、図９のＳＴ１２６〜ＳＴ１３４と同様である。

図１２は、ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャートである。図１２の処理ＳＴ４００〜ＳＴ４１４とＳＴ４３６〜ＳＴ４５６は、図１１の処理ＳＴ３００〜ＳＴ３１４とＳＴ３３６〜ＳＴ３５６にそれぞれ対応している。図１１と異なるのは、図１２の処理では、独自保護の解除（ＳＴ４１４）のあと、ＭＫＢ上のVerification Dataの検証を行っている（ＳＴ４３２）ことである。このVerification Dataの検証がＯＫであれば（ＳＴ４３４イエス）、ＭＫＢ処理が終了し、Media Keyの取得が完了する。この検証に失敗すれば（ＳＴ４３４ノー）、ＳＴ４３６の処理に移行する。ＳＴ４３６以降の処理（ＳＴ４３６〜ＳＴ４４４）は、図９のＳＴ１２６〜ＳＴ１３４と同様である。

図１３は、ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャートである。図１３の処理ＳＴ５００〜ＳＴ５０４とＳＴ５３６〜ＳＴ５５６は、図１１の処理ＳＴ３００〜ＳＴ３０４とＳＴ３３６〜ＳＴ３５６にそれぞれ対応している。図１１と異なるのは、図１３のＳＴ５０６〜ＳＴ５１４の処理である。すなわち、ディスク１００からＭＫＢのVerification Dataを取得し（ＳＴ５０６）、機器上に保持しているVerification Dataを検索する（ＳＴ５０８）。検索対象に対応するVerification Dataがあれば（ＳＴ５１０イエス）、そのVerification Dataに対応する機器上の独自保護されたMedia Keyを取得する（ＳＴ５１２）。そして取得したMedia Keyの独自保護を解除して（ＳＴ５１４）、ＭＫＢ処理を終える。これにより、冗長性の少ない簡素化された処理（ＳＴ５１２〜ＳＴ５１４）で、Media Keyの取得が完了する。検索対象に対応するVerification Dataがないときは（ＳＴ５１０ノー）、ＳＴ５３６の処理に移行する。ＳＴ５３６以降の処理（ＳＴ５３６〜ＳＴ５４４）は、図９のＳＴ１２６〜ＳＴ１３４と同様である。

図１４は、（ＳＴ４３６〜ＳＴ４４４）フローチャートである。図１４の処理ＳＴ６００〜ＳＴ６０４とＳＴ６０６〜ＳＴ６５６は、図１３の処理ＳＴ５００〜ＳＴ５０４とＳＴ５０６〜ＳＴ５５６にそれぞれ対応している。図１３と異なるのは、図１４のＳＴ６０５Ａ〜ＳＴ６０５Ｂのバージョン比較処理である。すなわち、ＳＴ６０４でSignature検証がＯＫであれば、ディスク１００よりＭＫＢのVersionを取得する（ＳＴ６０５Ａ）。このVersionが、その時点で機器が指定するバージョン番号より新しければ（あるいは同じバージョンであれば）（ＳＴ６０５Ｂイエス）ＳＴ６０６の処理へ移行し、古ければ（ＳＴ６０５Ｂノー）ＳＴ６３６の処理へ移行する。ＳＴ６０６以降の処理（ＳＴ６０６〜ＳＴ６１４）は、図１３のＳＴ５０６〜ＳＴ５１４と同様である。また、ＳＴ６３６以降の処理（ＳＴ６３６〜ＳＴ６４４）は、図１３のＳＴ５３６〜ＳＴ５４４あるいは図９のＳＴ１２６〜ＳＴ１３４と同様である。

なお、図１４のＳＴ６０５Ａ〜ＳＴ６０５Ｂの処理は、メディアキーブロック（ＭＫＢ）のサイズ（例えば図７のＭＫＢのサイズ欄で“−”となっている個所の内容）の大小比較処理であってもよい。すなわち、ＭＫＢのサイズ情報を取得し（ＳＴ６０５Ａ）、サイズがそれ以前よりも大きくなっていれば（ＳＴ６０５Ｂノー）ＳＴ６３６の処理へ移行し、サイズがそれ以前と変わらないなら（ＳＴ６０５Ｂイエス）ＳＴ６０６の処理へ移行するようにしてもよい。

図２１は、この発明の一実施の形態に係る再生装置を示す概略的な全体構成図である。再生装置１０は、ＣＰＵ（またはＭＰＵ）１１、ＲＡＭ１２、ＲＯＭ１３および入力データベースとしてのSignature Verification Input Table１４およびディスクドライブ２０を有する。再生装置１０は、HD_DVD Recorderなどの記録再生装置により構成することができる。

ＣＰＵ１１は、ＲＯＭ１３内に記憶されたプログラム（ファームウエア）にしたがって、再生装置１０の処理動作を制御する。ＣＰＵ１１は、ＲＯＭ１３内に記憶された署名検証プログラムおよびプログラムの実行のために必要なデータをＲＡＭ１２へロードし、署名検証プログラムにしたがって署名検証演算する処理を実行する。また、ＣＰＵ１１は、ＲＯＭ１３内に記憶されたドライブ制御プログラムおよびプログラムの実行のために必要なデータをＲＡＭ１２へロードし、ドライブ制御プログラムによる制御にしたがって、ディスクドライブ２０の動作を制御する。

ＲＡＭ１２は、ＣＰＵ１１が実行するプログラムおよびデータを一時的に格納するワークエリアを提供する。ＲＯＭ１３は、再生装置１０の起動プログラム、署名検証プログラム、ドライブ制御プログラムや、これらのプログラムを実行するために必要な各種データを記憶する。なお、ＲＯＭ１３は、磁気的もしくは光学的記録媒体または半導体メモリなどのＣＰＵ１１により読み取り可能な記録媒体を含んだ構成を有し、ＲＯＭ１３内のプログラムおよびデータの一部または全部は電子ネットワークを介してダウンロードされるように構成してもよい。

Signature Verification Input Table１４は、過去に挿入された媒体の、ＭＫＢのデータ部のＨａｓｈ値（圧縮値）およびＭＫＢの最終ブロックのSignature（以下、このＨａｓｈ値およびSignatureを総称して入力データという）を格納する。

ディスクドライブ２０は、ＣＰＵ（またはＭＰＵ）２１、ＲＡＭ２２、ＲＯＭ２３およびピックアップ部２４を有する。ディスクドライブ２０は、HD_DVDなどの光ディスクドライブにより構成することができる。このディスクドライブ２０の処理動作は、再生装置１０のＣＰＵ１１によって制御される。

ＣＰＵ２１は、ＲＯＭ２３内に記憶されたプログラムにしたがって、ディスクドライブ２０の処理動作を制御する。ＣＰＵ２１は、ＲＯＭ２３内に記憶された署名検証プログラムおよびプログラムの実行のために必要なデータをＲＡＭ２２へロードし、署名検証プログラムにしたがって署名検証演算する処理を実行する。また、ＣＰＵ２１は、ＲＯＭ２３内に記憶されたデータ読み取り、制御プログラムおよびプログラムの実行のために必要なデータをＲＡＭ２２へロードし、再生装置１０のＣＰＵ１１による制御に従いデータ読み取り制御プログラムによりピックアップ部２４の動作を制御し、媒体１に記録された情報を読み取る。

ＲＡＭ２２は、ＣＰＵ２１が実行するプログラムおよびデータを一時的に格納するワークエリアを提供する。ＲＯＭ２３は、たとえば、署名検証プログラム、データ読み取り制御プログラム、これらのプログラムを実行するために必要な各種データ等を記憶する。なお、ＲＯＭ２３は、磁気的もしくは光学的記録媒体または半導体メモリなどの、ＣＰＵ２１により読み取り可能な記録媒体を含んだ構成を有し、ＲＯＭ２３内のプログラムおよびデータの一部または全部は電子ネットワークを介してダウンロードされるように構成してもよい。

ピックアップ部２４は、レーザ発振部、各種レンズなどを有し、再生装置１０のＣＰＵ１１による制御を受けたＣＰＵ２１の制御により記録媒体１の情報記録面にレーザを照射し、反射光を集光し、この反射光の情報をディスクドライブ２０に与える。この反射光の情報をもとに、ＣＰＵ２１は、読み取り制御プログラムによって媒体１に記録されたＭＫＢなどの情報を読み取り、この情報を再生装置１０へ与える。

図２２は、ＣＰＵ１１の構成例を示す概略的なブロック図である。ＣＰＵ１１は、署名検証プログラムによって、少なくとも、Ｈａｓｈ値計算手段１１ａ、入力データ検索手段１１ｂ、署名検証演算手段１１ｃ、署名検証判定手段１１ｄおよび最終判定手段１１ｅとして機能できる。この各手段１１ａ〜１１ｅは、ＲＡＭ１２の所要のワークエリアを、データの一時的な格納場所として利用する。

ＣＰＵ１１の各手段１１ａ〜１１ｅを説明するにあたり、まず、この発明に係る再生装置があつかうＭＫＢの構成について説明する。図２３は、この発明の一実施の形態に係る再生装置による署名検証におけるＭＫＢのデータの取り扱い方を模式的に示した説明図である。図２３に示すように、ＭＫＢは全体で１Ｍbyte以内となるよう構成されている。ＭＫＢの先頭ブロックには１２bytesのVersion情報が付されている。ＭＫＢのデータ部には、いくつかのデータが記録される場合がある。このデータとして、Host Revocation Listなどが挙げられる。各データにはそれぞれに対応する署名が付されている。ＭＫＢの最終ブロックに対しては、Version情報およびデータ部をメッセージとする４０bytesのSignature（署名）が付加されている。このSignatureは、ＡＡＣＳ ＬＡが保持する秘密鍵により作成される。

次に、ＣＰＵ１１の各手段１１ａ〜１１ｅについて説明する。Ｈａｓｈ値計算手段１１ａは、ディスクドライブ２０から媒体１のＭＫＢを受け、このＭＫＢのデータ部を、ＳＨＡ−１（Secure Hash Algorithm 1：ハッシュ関数の一つ）による計算を行うことにより圧縮し、２０bytesのＨａｓｈ値を生成する機能を有する。

入力データ検索手段１１ｂは、Ｈａｓｈ値計算手段１１ａからＭＫＢのデータ部のＨａｓｈ値およびＭＫＢのSignature（入力データ）を受け、Signature Verification Input Table１４にしたがって入力データを検索し、同一の入力データの有無を判定する機能を有する。また、入力データ検索手段１１ｂは、同一の入力データがあった場合には、媒体１のＭＫＢの署名検証が成功したと判定し、この判定結果を最終判定手段１１ｅに与える。

署名検証演算手段１１ｃは、媒体１のＭＫＢについて、ＥＣ−ＤＳＡによる署名検証の演算を行う機能を有する。

署名検証判定手段１１ｄは、この演算結果を受け、署名検証が成功したかどうかを判定し、成功した場合にはSignature Verification Input Table１４に対応する入力データを記録する機能を有する。また、署名検証判定手段１１ｄは、判定結果（成功か失敗か）を最終判定手段１１ｅに与える機能を有する。

最終判定手段１１ｅは、媒体１のＭＫＢの署名検証について、判定結果を入力データ検索手段または署名検証判定手段１１ｄから受け、ディスクドライブ２０に対し、判定結果が署名検証成功だった場合には、媒体１のコンテンツ読み取りを開始する許可を与え、失敗だった場合には、媒体１のコンテンツ読み取りは行わないよう制御する機能を有する。

次に、この発明に係る再生装置１０および再生方法の作用について説明する。図２４は、図２１に示す再生装置１０のＣＰＵ１１により、一度署名検証が成功した署名について、必要なデータを保持しておくことにより、二度目以降の署名検証に要する時間を大幅に短縮する際の手順を示すフローチャートである。このフローチャートの手順は、媒体１（図１〜図３あるいは図１５の光ディスク１００に相当）がディスクドライブ２０に挿入され、ディスクドライブ２０により媒体１のＭＫＢが読み取られ、このＭＫＢを再生装置１０のＣＰＵ１１が受けた時点でスタートとなる。

まず、ステップＳ１において、Ｈａｓｈ値計算手段１１ａは、ディスクドライブ２０から受けた媒体１のＭＫＢのデータ部を、ＳＨＡ−１（Secure Hash Algorithm 1：ハッシュ関数の一つ）による計算を行うことにより圧縮し、２０bytesのＨａｓｈ値を生成する（図２３参照）。次に、ステップＳ２において、入力データ検索手段１１ｂは、Ｈａｓｈ値計算手段１１ａからＭＫＢのデータ部のＨａｓｈ値およびＭＫＢのSignatureを受け、Signature Verification Input Table１４にしたがって入力データを検索する。

ステップＳ３において、入力データ検索手段１１ｂは、媒体１のＭＫＢから導出した入力データと同一の入力データの有無を判定する。同一の入力データがある場合は媒体１のＭＫＢの署名検証が成功したと判定し、この判定結果を最終判定手段１１ｅに与えステップＳ７に進む。一方、同一の入力データがない場合は、ステップＳ４に進む。

ステップＳ４において、署名検証演算手段１１ｃは、媒体１のＭＫＢについて、ＥＣ−ＤＳＡによる署名検証の演算を行う。ステップＳ５において、署名検証判定手段１１ｄは、署名検証の演算結果を受け、署名検証が成功したかどうかを判定する。成功したと判定する場合はステップＳ６に進む。一方、失敗したと判定する場合は、この判定結果を最終判定手段１１ｅに与えステップＳ８に進む。

次に、ステップＳ６において、署名検証判定手段１１ｄは、媒体１のＭＫＢから導出した入力データを、Signature Verification Input Table１４に記録し、署名検証成功の判定結果を最終判定手段１１ｅに与える。ステップＳ７において、最終判定手段１１ｅは、媒体１のＭＫＢの署名検証が成功したという判定結果を入力データ検索手段１１ｂまたは署名検証判定手段１１ｄから受け、媒体１のＭＫＢを正当なＭＫＢと判定する。続いて、最終判定手段１１ｅは、ディスクドライブ２０のＣＰＵ２１に対し、媒体１のコンテンツ読み取りを開始する許可を与える信号を送信し、一連の署名検証は終了となる。

また、ステップＳ８において、最終判定手段１１ｅは、媒体１のＭＫＢの署名検証が失敗したという判定結果を署名検証判定手段１１ｄから受け、媒体１のＭＫＢを不正なＭＫＢと判定する。続いて、最終判定手段１１ｅは、ディスクドライブ２０のＣＰＵ２１に対し、媒体１のコンテンツ読み取りは行わないよう制御するための信号を送信し、一連の署名検証は終了となる。

以上の手順により、一度署名検証が成功した署名について、対応する入力データを保持しておくことにより、二度目以降の署名検証に要する時間を大幅に短縮することができる。また、この署名検証により、使用するＭＫＢの信頼性が高まる（ＭＫＢが不正に改竄されている恐れを殆ど払拭できる）。

図２１に示した再生装置１０によれば、一度署名検証が成功した署名について、対応する入力データを保持しておくことにより、二度目以降の署名検証においては、入力データを比較することのみによって、署名の正当性を判定することができる。入力データを導出するために必要な計算はＳＨＡ−１のみであり、この計算はＥＣ−ＤＳＡによる署名検証演算にくらべ、はるかに短時間で終えることができる。したがって、一度署名検証が成功した署名について、二度目以降の署名検証に要する時間を大幅に短縮することができ、記録媒体を挿入してから記録媒体のコンテンツを読み込むまでの時間を容易に大幅に短縮することができる。

また、再生装置１０およびこの再生装置１０を用いた再生方法においては、Signature Verification Input Table１４に記録されるＭＫＢの入力データのうち、ＭＫＢのデータ部については、Ｈａｓｈ関数により圧縮したＨａｓｈ値として保持する。したがって、一度署名検証が成功した署名について、二度目以降の署名検証を行うにあたり必要なデータとして、本来は最大１ＭbyteあるＭＫＢの全データ（メッセージ（Version情報とデータ部）とSignature）を保持する必要はなく、小さな容量の入力データを保持しておくことで足りる。

また、入力データのＨａｓｈ値として、ＭＫＢのメッセージ（Version情報とデータ部）をＳＨＡ−１で圧縮したものを用いてもよい。この場合、ＭＫＢの全データを反映した入力データを保持することになるが、Ｈａｓｈ関数の計算結果は常に２０bytesになるようになっているため、入力データとしての容量は２０bytesで変わらない。

なお、ＭＫＢの最終ブロックに付加されたSignature（署名）ではなく、ＭＫＢのデータ部に存在するデータに付された署名についての署名検証を行う場合にも、上記手順を行うことにより、同様の効果を得ることができる。この場合、入力データとは、データ部のデータのみをＨａｓｈ値化したものまたはデータ部のデータとVersion情報をＳＨＡ−１によりＨａｓｈ値化したものと、このデータ部のデータに付された署名との総称を指す。この場合において、最終判定手段１１ｅは、署名検証の判定結果により、署名が正当なものか判定し、ＣＰＵ１１およびＣＰＵ２１に対しこの署名が付されたデータの使用許可を与えるかどうか判定する。

また、ディスクドライブ２０のＣＰＵ２１についても、再生装置１０のＣＰＵ１１による署名検証と同様の署名検証を行うことができる。なぜなら、ディスクドライブ２０のＣＰＵ２１が、署名検証プログラムによって、少なくともＨａｓｈ値計算手段２１ａ、入力データ検索手段２１ｂ、署名検証演算手段２１ｃ、署名検証判定手段２１ｄおよび最終判定手段２１ｅとして機能し、各手段はＣＰＵ１１の同一名称の手段と同様の作用効果を奏するためである。

ディスクドライブ２０は、一般に、再生装置１０に比べて、ＣＰＵの処理能力が劣り、メモリサイズも小さいことが多い。したがって、ディスクドライブ２０のＣＰＵ２１に対し上記手順を適用すれば、不要な署名検証処理のスキップによる処理時間の削減や、入力データのＨａｓｈ値化による記憶領域削減の効果が、大きなものになることが期待できる。

図２５は、この発明の一実施の形態に係る再生装置１０のSignature Verification Input Table１４に記録された入力データの、更新の態様を模式的に示した説明図である。Signature Verification Input Table１４に格納できる入力データは有限である。したがって、あらかじめ定められたSignature Verification Input Table１４の容量を超えた場合、新規な入力データを記録するため、すでに記録されている入力データのいずれかを削除する必要が生じる。

たとえば、入力データのＨａｓｈ値として、ＭＫＢのメッセージ（Version情報とデータ部）をＳＨＡ−１で圧縮したものを用いた場合、図２５に示すように、ＭＫＢのVersion情報を比較し、Version情報の古いものから削除（上書き）するようにしてもよい。また、記録媒体の挿入回数を入力データと対応付けて保持しておき、挿入回数の少ないものから削除（上書き）するようにしてもよい。また、前回アクセスした時間を入力データと対応付けて保持しておき、前回アクセスした時間が最も古い入力データから削除（上書き）するようにしてもよい。さらに、これらの削除方法を自由に組み合わせて実施してもよい。

図２１〜図２５を参照して上述した方法は、Signatureのデータとその演算の途中データであるHash値を機器内に保持することで、署名検証を効率化する方法の一例である。この方法は、例えば図１１のＳＴ３０２の処理において利用できる。

なお、この発明の実施の形態は、ＡＡＣＳ Pre-recorded Mediaを扱うPlayer機器にも適用可能である。ただし、Player機器ではＭＫＢの更新を行わないため、Recorder機器に実装した場合の方がこの発明の実施による効果は大きい。

ところで、ＡＡＣＳ Recordable Mediaを扱う機器は、暗号化・復号化処理の為の鍵の１つにMedia Keyを使用する。Media KeyはＡＡＣＳ Recordable Media上に１つ格納されるMedia Key Block（ＭＫＢ）に暗号技術を用いることで秘匿して格納されており、機器に割り当てられるDevice Key等のデータを使用してＭＫＢから暗号的処理を用いて導出される。ＭＫＢとMedia Keyは１対１に対応しており、１つのＭＫＢからは正当な処理を経て１つのMedia Keyが導出される。このＭＫＢおよびそこに含まれるMedia KeyはＡＡＣＳ Recordable Mediaの１枚毎に異なるものではなく、同じ時期に生産された同一プロダクトタイプのディスクでは同じである場合が多い。

また、ＡＡＣＳ Recordable Mediaを扱う機器では機器上にもＭＫＢを持っており、ＡＡＣＳ Recordable Media上のＭＫＢのバージョンが、機器に格納されているＭＫＢよりも古ければ、ＡＡＣＳ Recordable Media上のＭＫＢを書き換える処理を行う。一方で、機器によっては、機器上のＭＫＢよりもバージョンの新しいＭＫＢを検出した場合、機器上のＭＫＢを最新のＭＫＢに置き換える場合もある。

このような処理のために、ＡＡＣＳ Recordable MediaにおかれるＭＫＢは常にRecorder機器が持つ最新のものに置き換えられていく可能性がある。このため各Recorderが扱うＭＫＢは必ずしも毎回異なるものではなく、同一のＭＫＢを何度も処理する可能性がある。類似する著作権保護技術ではＭＫＢの置き換えが定義されていないものがあるが、それと比べても、同一のＭＫＢを繰り返し処理する可能性はより高まっている。

ＭＫＢ処理の概要は例えば以下のようになる。（図９参照）
１．ＭＫＢの正当性検証（ＡＡＣＳ_Verify）（ＳＴ１２２）
２．該当Recorderが演算可能なＭＫＢ内のノードの探索（２５３本保持しているDevice Keyから、そのＭＫＢの処理に利用可能なDevice Keyを選び出す処理、あるいはＭＫＢ上の処理可能なデータを探し出す処理）（ＳＴ１２８）
３．Media Keyの導出（２回〜２３回程度のＡＥＳ処理）（ＳＴ１３０）
４．導出したMedia Keyの正当性検証（ＡＥＳ処理）（ＳＴ１３２）。

これらの処理はMedia Keyの使用時に必要になるが、例えばMedia Keyを使用する機会には以下の様なものがある：
１．Title Keyの復号化（コンテンツ再生時、コンテンツ記録・編集時、ディスク上のＭＫＢ更新時）
２．Title Keyの暗号化（コンテンツ記録・編集時、ディスク上のＭＫＢ更新時）。

また、ＭＫＢの更新を行う場合には、ディスク上のＭＫＢと機器上のＭＫＢ両方を処理して、ディスク上のMedia KeyによるTitle Keyの復号化、機器上のMedia Keyによる再暗号化を行い、ディスク上のＭＫＢを機器上のものに置き換える。

Media Keyは、ＡＡＣＳ規格上、秘匿して保護することが要求されているデータである。そのため、Media KeyをHigh Definition Digital Video Recorder等の機器上に保持する場合には、例えば独自定義した保護方式により保護した状態で、Media Keyを保持する必要がある。同様のデータとして、Device Keyがある。ＡＡＣＳ準拠の機器はDevice Keyを機器上に秘匿して保持することが義務付けられているので、例えばDevice Keyと同程度の保護をすれば、Media Keyに対するＡＡＣＳ規格上の保護要求は満たせる。この秘匿保護の要求はＭＫＢ自体には適用されないため、Indexとなるデータ、あるいはVerification Dataは秘匿の必要は無く、Media Keyのみを秘匿の対象とすればよい（ただしMedia Key以外を秘匿の対象にできないということではない）。

＜まとめ＞
（ポイント１）通常、ディスク上のＭＫＢがRecorder上のＭＫＢよりも古いバージョンものであり、かつディスクが書き換え可能なメディアであれば、ディスク上のＭＫＢを更新して置き換えるため、Recorder上に保持している最新のＭＫＢからMedia Keyを導出する必要がある。しかし、この処理は保持している最新のＭＫＢが変わらない限り、毎回同じ演算を行い、同じ結果を得るものであるから冗長である。この発明の実施の形態では独自保護したMedia Keyを用いることで図９のＳＴ１４０〜ＳＴ１４１（機器のＭＫＢ更新）あるいはＳＴ１４２〜ＳＴ１４８（メディアのＭＫＢ更新）のように処理を簡略化する。

（ポイント２）通常、ディスク上のＭＫＢからMedia Keyを導出する処理は図１０のＳＴ２２０〜ＳＴ２４４のようになる。ポイント２では、まずRecorderはＭＫＢを処理する必要が生じた場合、そのＭＫＢが過去に処理したことがあり、Recorder内にMedia Keyを保持しているＭＫＢであるか判定する。そのＭＫＢが過去に処理したことのないものであれば（ＳＴ２１０ノー）、通常のＭＫＢ処理（ＳＴ２２０〜ＳＴ２４４）を実行しMedia Keyを取得する。続いて、取得したMedia KeyとＭＫＢの特徴を示すようなIndex情報をRecorder上に保持する（ＳＴ２５０〜ＳＴ２５６）。この場合、Media Keyの値は暗号化等の独自の手法によって秘匿保護されることが望ましい（ＳＴ２５４）。

次に、RecorderがＭＫＢを処理する必要が生じた場合に、Recorder上に処理すべきＭＫＢに対応するIndex情報があり（ＳＴ２１０イエス）、ＭＫＢを過去に処理したことがあると考えられるとき、Indexに対応するRecorder上に秘匿して保持されているMedia Keyを復号等の処理（ＳＴ２１２〜ＳＴ２１４）を通じて取得し、ディスク上のＭＫＢから得られるものと等価なMedia Keyとして用いる（図１０参照）。このとき、Indexとして用いる情報は、ＭＫＢのデータの一部で、ヘッダ等の固定値が入りやすい部分以外を用いることが望ましい。

（ポイント３）ポイント３では、ポイント２の処理に加え、ＭＫＢのSignatureを検証する（図２４参照）ことで、改竄を防止する。ポイント２の実装だけの場合には、ＭＫＢの値を書き換え、Indexに用いるデータを偽装することで、偽装したＭＫＢを処理させることが可能であるが、Signatureを検証することで、Indexを含むＭＫＢ全体が改竄されていないことを保証できる（図１１参照）。

（ポイント４）ポイント４では、ポイント２またはポイント３の処理によってRecorder上に保持していたMedia Keyを使用する場合に、通常のMedia Key導出で行われるＭＫＢのVerification Dataの検証を実施することで、Media Keyの正当性を保証する。これにより、異なるＭＫＢにおいて偶然Indexデータが一致していた場合の混同を避けることができる。また、これにより同一IndexのMedia Keyを保持しておき、Verification Dataの検証結果によって、正当なMedia Keyを見分けることも可能である。この結果、Indexのbit長をより短くすることも可能である。また、Verification Dataの検証に失敗した場合は、通常のＭＫＢ処理を行う。これによって、Indexを短くした場合や、保持していたデータが破損した場合などの例外的な状況においても、最終的に正しくMedia Keyを導出することを保証できる（図１２参照）。

（ポイント５）ポイント５では、ポイント２またはポイント３の処理で、機器上に持つIndexとしてVerification Dataを持つ。これによりIndex上の比較を行って一致を確認することで、同時にVerification Dataの検証を簡易的に済ませることができる。特にポイント３で行ったようにSignatureの検証を行っていれば、処理すべきＭＫＢのVerification Dataが改竄されている可能性も排除できるため、この発明の実施の形態の実装として好適である（図１３参照）。

（ポイント６）ポイント６では、Recorder機器上に保持するMedia KeyとIndexのペアの一覧の中にポイント１の機器上に保持しているＭＫＢのMedia Keyを加える。ポイント１では機器で保持しているＭＫＢを用いたディスク上のＭＫＢの更新について扱っていたため、Indexを用いていないが、ポイント２〜ポイント６と同様にIndexを保持することで、ＭＫＢの更新時だけでなく、再生時にも該当Media Keyを用いることが出来き、かつポイント１の処理とポイント２〜ポイント５の処理を別々に実装するよりも保持するデータを若干節約できる。

（ポイント７）ポイント２〜ポイント６では、Indexを用いたMedia Keyの導出を示したが、前述のようにRecorder機器上で扱うＭＫＢとそこから導出されるMedia Keyの使用頻度は必ずしも均一ではない。これはユーザの嗜好によるものもあるが、使用確率の高いMedia Keyと使用確率の低いMedia Keyを類推可能な要素もある。例えばMediaに書き込んだことのあるＭＫＢはその後、再び使用される可能性が高いので、対応するMedia Keyの検索の優先順位を上げて効率化をはかる。あるいは、Recordable Media上で検出したＭＫＢから取得したMedia Keyで、そのMediaに対しＭＫＢの更新を行った場合、検索の優先順位を下げて、効率化をはかる。これに対し、Recordable Media上で検出したＭＫＢから取得したMedia Keyで、そのMediaに対しＭＫＢの更新を行わなかった場合、検索の優先順位を上げて効率化をはかる、などの方法が考えられる。また、単純に再生や記録でMedia Keyを使用する頻度を記録して、使用頻度の高いものの検索の優先順位を上げて、効率化をはかることも可能である。

また、機器上に保持するMedia KeyやIndexの個数を制限したい場合にも、このような優先順位が存在すれば、取捨選択の指針となりうる。例えばディスクに対して機器から書き込んだＭＫＢについてはMedia Keyを保持しておくが、ディスクから読み出しただけのＭＫＢについては保持しないなど、さまざまな実装が可能である。この発明の実施の形態では、個々の優先順位付けをどのようにするかについては制限をせず、Mediaに対して行った処理、機器内部で行った処理に応じて、Media Keyデータの優先順位を変化させる事を発明実施の対象とする。

（ポイント８）通常のＭＫＢの処理負荷は、ＭＫＢ内部の構造の複雑さによって異なる。これはＭＫＢのサイズやＭＫＢ内に示されているバージョンによって変化する。よって、サイズが大きいものやバージョンの値が大きい（新しい）もの、あるいは特定のバージョンに対してのみ、ポイント２〜ポイント５の処理を適用する。そうではなく、通常のＭＫＢ処理を実行しても処理負荷が低いと予想されるときは、通常の処理を行うことで、処理負荷を軽減する（図１４参照）。

＜実施の形態の効果＞
Media Keyの過去の処理結果の保持と、Verification DataをIndexとして扱う処理により、ＡＡＣＳ を用いる機器（次世代の高精細ビデオレコーダ等）でのＭＫＢの処理を簡略化することができる。また保持するMedia Keyの優先度設定によってデータの検索や保持の効率を向上させることができる。さらに、ＭＫＢ処理に好適なデータソートの基準を示すことができる。

ＡＡＣＳが実装されたRecorderにおいてこの発明を実施することにより、ＭＫＢの構造が複雑化した場合に、記録の開始時、終了時、あるいは起動時の処理を軽減できる。

SignatureとHashを機器内部に保持してSignature検証の処理を簡略化させる方法を組み合わせ、Signature等をIndexとして使用することで、簡略化した署名検証と同時にMedia Keyを導出することも可能となる。

Media Keyの過去の処理結果の保持と、Verification DataをIndexとして扱う処理により、ＡＡＣＳ RecoerderでのＭＫＢの処理を簡略化できる。また、保持するMedia Keyの優先度設定によってデータの検索や保持の効率を向上させることができる。

なお、この発明は前述した実施の形態に限定されるものではなく、現在または将来の実施段階では、その時点で利用可能な技術に基づき、その要旨を逸脱しない範囲で種々に変形することが可能である。たとえば、この発明の実施において利用される情報記憶媒体は、光ディスクあるいはハードディスクドライブだけには限らず、大容量フラッシュメモリ等が利用されてもよい。また、この発明が実施可能なシステムは、ＨＤ＿ＤＶＤに限られず、青ないし青紫レーザ等を用いる別規格の次世代のデジタル記録再生システムでもよい。

また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、この構成要件が削除された構成が発明として抽出され得る。

この発明の一実施の形態に係るメディア（情報記録媒体）内のデータ（タイトルキーファイル）の構成を説明する図。 メデイアに記録された暗号化コンテンツを復号する処理例を説明する図。 コンテンツを暗号化してＤＶＤに記録する処理例を説明する図。 タイトルキーファイルとそのバックアップファイルとしてのタイトルキーファイルの構造を示す説明図。 この発明の一実施の形態で採用される暗号化方式（ＡＡＣＳ方式）を用いた記録再生処理で必要となるメデイア上のデータを示す図。 ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを示す図。 ＡＡＣＳ方式の記録再生処理で必要となるメデイア上のデータを示す図。 暗号化されたタイトルキーファイル（Ｅ−ＴＫＦまたはＫｔｅ＃０〜＃ｎのファイル）の構造例を示す図。 ＭＫＢ更新処理の一例（機器にＭＫＢ更新機能が実装されている場合）を説明するフローチャート図。 ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の一例を説明するフローチャート図。 ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャート図。 ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャート図。 ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャート図。 ディスク上のコンテンツを再生しあるいはディスク上にコンテンツを記録する場合における、効率的なMedia Key導出処理の他例を説明するフローチャート図。 この発明が実施される機器の構成および機器に保持しているIndexデータ等のデータ構造の一例を説明する図。 暗号化データの構造の一例を説明する図。 機器に保持される鍵情報（Media Key）の独自暗号化処理の一例を説明する図。 機器に保持される鍵情報（Media Key）の独自復号化処理の一例を説明する図。 独自暗号化処理手順の一例を説明するフローチャート図。 独自復号化処理手順の一例を説明するフローチャート図。 この発明の一実施の形態に係る再生装置の概略的な全体構成図。 この発明の一実施の形態に係る再生装置の情報処理部の構成例を示す概略的なブロック図。 この発明の一実施の形態において、署名検証におけるＭＫＢのデータの取り扱い方を模式的に説明する図。 一度署名検証が成功した署名について、必要なデータを保持しておくことにより、二度目以降の署名検証に要する時間を大幅に短縮する際の手順を説明するフローチャート図。 この発明の一実施の形態において、Signature Verification Input Tableに記録された入力データの更新の態様を模式的に説明する図。

符号の説明

１００…情報記憶媒体（光ディスク）；２００…情報記録再生装置；２１０…制御部；２２０…読出し部；２３０…書込み部；３００…ディスクドライブ部；３１０…鍵処理制御部（ＡＡＣＳ処理部）；３２０…Media Key Block保持部；３３０…独自保護部；３４０…デバイス鍵保持部；３５０…Media Key/Index保持部（不揮発性メモリ）。

Claims (10)

1. メディアキーと乱数データからプロテクテッドエリアキーを生成し、暗号化されたタイトルキーを含むタイトルキーファイルと前記プロテクテッドエリアキーから、コンテンツの暗号化または復号化に用いるタイトルキーを生成する方法において、
   前記タイトルキーを利用する機器に、前記メディアキーに対応する独自保護された暗号化メディアキーを保持し、
   前記メディアキーが前記独自保護とは異なる方法で暗号化されて記録された情報をメディアキーブロックとし、前記機器により記録または再生が行われるメディアは前記メディアキーブロックを持ち、このメディアが持つメディアキーブロックを更新するために前記機器上にメディアキーブロックの情報が保持されているときに、前記機器が前記保持された暗号化メディアキーを利用する暗号情報処理方法。
2. メディアキーと乱数データからプロテクテッドエリアキーを生成し、暗号化されたタイトルキーを含むタイトルキーファイルと前記プロテクテッドエリアキーから、コンテンツの暗号化または復号化に用いるタイトルキーを生成する方法において、
   前記メディアキーについては独自保護によって暗号化メディアキーに変換し、
   前記メディアキーが前記独自保護とは異なる方法で暗号化されて記録された情報をメディアキーブロックとしたときに、前記タイトルキーを利用する機器が、前記暗号化メディアキーとそれを識別する前記メディアキーブロック上のデータを用いたインデックスの一覧を保持し、
   前記メディアキーを導出する処理をする際に、所定のインデックス情報を用いて前記インデックスの一覧を参照し、このインデックスの一覧中に前記所定のインデックス情報に対応するインデックスがあるときは、このインデックスに対応して前記機器が保持している独自保護された前記暗号化メディアキーを取得し、取得した前記暗号化メディアキーの独自保護を解除して、独自保護が解除された前記メディアキーを前記タイトルキーの生成に利用する暗号情報処理方法。
3. 前記メディアキーブロックの情報に電子的な署名が付加されている場合に、この署名を検証することで、前記メディアキーブロックの情報が正当なものであるか不正なものであるかを判定する請求項２に記載の方法。
4. 前記メディアキーの導出過程で行われる前記メディアキーブロック上の検証を実施することで、前記メディアキーの正当性を保証する請求項２または請求項３に記載の方法。
5. 前記機器上には所定の検証データを持ち、前記メディアキーブロックの処理の際に、前記所定の検証データに対応するところの前記独自保護された前記暗号化メディアキーが前記機器にある場合は、前記所定の検証データに対応するところの前記暗号化メディアキーを取得し、取得した前記暗号化メディアキーの独自保護を解除して、独自保護が解除された前記メディアキーを前記タイトルキーの生成に利用する請求項２または請求項３に記載の方法。
6. 前記メディアキーについては独自保護によって暗号化メディアキーに変換し、
   前記メディアキーが前記独自保護とは異なる方法で暗号化されて記録された情報をメディアキーブロックとしたときに、前記タイトルキーを利用する機器が、過去に導出した前記暗号化メディアキーとそれを識別する前記メディアキーブロック上のデータを用いたインデックスの一覧を保持し、この一覧中に前記機器上に保持している前記メディアキーブロックのメディアキーの情報が加わる請求項１に記載の方法。
7. 前記機器が所定のメディアに対して行った処理、前記機器内部で行った処理、あるいは前記メディアの種類に応じて、前記機器上に保持する前記メディアキーの検索および／または保持の優先順位を上下させる請求項２ないし請求項６のいずれか１項に記載の方法。
8. 前記メディアキーブロックのサイズあるいはバージョンの情報を取得し、その値によって、前記暗号化メディアキーを利用した処理を行うか否かを決定する請求項２ないし請求項６のいずれか１項に記載の方法。
9. メディアキーと乱数データからプロテクテッドエリアキーを生成し、暗号化されたタイトルキーを含むタイトルキーファイルと前記プロテクテッドエリアキーから、コンテンツの暗号化または復号化に用いるタイトルキーを生成する装置において、
   前記メディアキーに対応する独自保護された暗号化メディアキーを保持する手段と、
   前記保持された暗号化メディアキーの独自保護を復号する手段を具備した暗号情報処理装置。
10. メディアキーと乱数データからプロテクテッドエリアキーを生成し、暗号化されたタイトルキーを含むタイトルキーファイルと前記プロテクテッドエリアキーから、コンテンツの暗号化または復号化に用いるタイトルキーを生成する装置において、
    前記メディアキーについては独自保護によって暗号化メディアキーに変換する手段と、
    前記メディアキーが前記独自保護とは異なる方法で暗号化されて記録された情報をメディアキーブロックとしたときに、前記暗号化メディアキーとそれを識別するインデックスの一覧を保持する手段と、
    所定のインデックス情報を用いて前記インデックスの一覧を参照し、このインデックスの一覧中に前記所定のインデックス情報に対応するインデックスがあるときは、このインデックスに対応して前記暗号化メディアキーを取得し、取得した前記暗号化メディアキーの独自保護を解除する手段と、
    前記独自保護が解除された前記メディアキーを前記タイトルキーの生成に利用する手段を具備した暗号情報処理装置。

Images