JP2016071923A - コンテンツ読み出し方法、コンテンツ読み出し装置、および記録媒体 - Google Patents

Abstract

【課題】適切な著作権保護を行うことができるコンテンツ読み出し方法を提供する。
【解決手段】このコンテンツ読み出し方法では、光ディスク５０におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報を、その光ディスク５０に基づいて特定し（Ｓ１１）、ホスト装置２０の認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定し（Ｓ１２）、第１のバージョン情報と第２のバージョン情報とを比較することによって、認証の是非を判定し（Ｓ１３）、その判定結果に基づいて、ホスト装置２０を認証し（Ｓ１４）、暗号化されたコンテンツの復号に用いられるＶｏｌｕｍｅ ＩＤを、光ディスク５０から読み出して、認証されたホスト装置２０に通知し（Ｓ１５）、暗号化されたコンテンツを光ディスク５０から読み出して、認証されたホスト装置２０に通知する（Ｓ１６）。
【選択図】図１３

Description

本発明は、著作権保護されたコンテンツを記録媒体から読み出す方法、装置、およびその記録媒体などに関する。

Ｂｌｕ−ｒａｙ（登録商標）ディスクをはじめとする光ディスクには、著作権保護されるべきＡＶ（Ａｕｄｉｏ Ｖｉｄｅｏ）コンテンツが暗号化されて格納されている（例えば、非特許文献１参照）。このようなＡＶコンテンツは、一般的には、Ｂｌｕ−ｒａｙ（登録商標）プレイヤーまたはレコーダーのような民生機だけではなく、他の装置でも再生される。つまり、ＡＶコンテンツは、光ディスクドライブ装置（以下、ドライブという）によって光ディスクから読み出され、さらに、汎用的なパーソナルコンピュータ上で動作するアプリケーションソフトによって再生される。

光ディスクには、ＡＶコンテンツの著作権保護に関連する特殊な情報が格納されており、このような情報は、通常の方法では読み出せないような工夫が施されている。さらに、ドライブが、光ディスクからこのような情報を読み出したとしても、この情報をパーソナルコンピュータに受け渡す際には、認証が必要とされている。つまり、ドライブと、ホストとなるパーソナルコンピュータとの間で認証が行われ、暗号化された情報がホストに受け渡される。一般的には、このような認証をドライブ・ホスト認証と呼ぶ。

"Advanced Access Content System (AACS) Blu-ray Disc Pre-recorded Book" Revision 0.953, Final, October 26,2012

しかしながら、上記非特許文献１では、コンテンツに対する適切な著作権保護が行えないという課題がある。

そこで、本発明は、適切な著作権保護を行うことが可能なコンテンツ読み出し方法等を提供する。

本発明の一態様に係るコンテンツ読み出し方法は、ホスト装置からの指示を受けて、記録媒体からコンテンツを読み出すコンテンツ読み出し方法であって、前記記録媒体におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報を、前記記録媒体に基づいて特定し、前記ホスト装置の認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定し、前記第１のバージョン情報と、前記第２のバージョン情報とを比較することによって、認証の是非を判定し、前記認証の是非の判定結果に基づいて、前記ホスト装置を認証し、前記記録媒体に格納されている暗号化された前記コンテンツの復号に用いられるメディア固有情報を、前記記録媒体から読み出して、認証された前記ホスト装置に通知し、暗号化された前記コンテンツを前記記録媒体から読み出して、認証された前記ホスト装置に通知する。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本発明のコンテンツ読み出し方法は、適切な著作権保護を行うことができる。

図１は、光ディスク再生環境の一例を示す図である。 図２Ａは、Ｖ１．０の光ディスクを用いた再生環境の一例を示す図である。 図２Ｂは、Ｖ２．０の光ディスクを用いた再生環境の一例を示す図である。 図３Ａは、共用ドライブを用いた光ディスク再生環境の例を示す図である。 図３Ｂは、共用ドライブを用いた光ディスク再生環境の例を示す図である。 図４は、実施の形態におけるドライブの構成を示すブロック図である。 図５は、実施の形態における、光ディスクに格納されているコンテンツの構造を模式的に示す図である。 図６は、実施の形態における、各Ａｌｉｇｎｅｄ Ｕｎｉｔの復号方法を説明するための図である。 図７は、実施の形態における、各Ａｌｉｇｎｅｄ Ｕｎｉｔの復号で用いるユニット鍵の記録方法を模式的に示す図である。 図８は、実施の形態における、光ディスクに記録されている、Ｋｅｙ Ｆｉｌｅ以外の、コンテンツの保護に必要となるデータを模式的に示す図である。 図９は、実施の形態におけるＨＲＬのデータ構造の一例を示す図である。 図１０は、実施の形態における、ユニット鍵をＫｅｙ Ｆｉｌｅから取得する処理を説明するための図である。 図１１は、実施の形態における、ドライブとホスト装置との間でのドライブ・ホスト認証を示すシーケンス図である。 図１２は、実施の形態におけるドライブの詳細な構成を示すブロック図である。 図１３は、実施の形態におけるドライブの処理動作を示すフローチャートである。

（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、コンテンツ読み出し方法に関し、以下の問題が生じることを見出した。以下、その問題について、図１〜図３Ｂを用いて説明する。

図１は、光ディスク再生環境の一例を示す図である。

光ディスク１０１に格納されたＡＶコンテンツ（以下、単にコンテンツという）などは、ドライブ１０２によって読み出される。こうして読み出されたコンテンツ、および著作権保護のために必要な情報は、パーソナルコンピュータ１０３に通知される。なお、ここで、著作権保護のために必要な情報など、暗号化などの保護が必要な情報を受け渡す際には、ドライブ１０２とパーソナルコンピュータ１０３との間でドライブ・ホスト認証が行われる。この認証のプロトコルをドライブ・ホスト認証プロトコルと呼ぶ。こうしてパーソナルコンピュータ１０３は、必要な情報を得ると、コンテンツを復号した上で再生し、ディスプレイ１０４にコンテンツの映像を表示する。

ここで、昨今新たな高画質のコンテンツとして４Ｋコンテンツが注目されている。従来のＨｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ（ＨＤ）コンテンツは、２Ｋコンテンツとも呼ばれ、その画素数は縦１９２０、横１０８０である。４Ｋコンテンツは、これを縦横各々２倍として、画素数を縦３８４０、横２１６０とするものである。４Ｋコンテンツでは、従来の２Ｋコンテンツと単純に比較して４倍の容量が必要となるが、昨今の動画圧縮技術の進展により、おおよそ２倍程度の容量に抑えることが可能であると言われている。

２倍の容量となる４Ｋ画質のコンテンツを格納するためには、光ディスクも新たな進化が必要となる。例えばＢｌｕ−ｒａｙ（登録商標）においては、パッケージメディアで用いられる光ディスクの１層あたりの容量は２５ＧＢであり、２層での容量は５０ＧＢである。これを１層あたりの容量を３３ＧＢとし、さらに、光ディスクに含まれる層の数を３層とすることで、１００ＧＢの容量を実現することが可能となる。勿論、このような光ディスクは従来のドライブでは読み出すことができず、新たな仕様に基づくドライブが必要である。

さて、既に述べたドライブ・ホスト認証でも、新たな画質のコンテンツに見合った著作権保護の仕組みが必要となる。Ｂｌｕ−ｒａｙ（登録商標）が市場に導入された２０００年代前半当時は、ハッシュ関数または楕円暗号では鍵の長さとして１６０ｂｉｔｓのものが標準的に利用されていた。しかしながら、２０１０年代も半ばにさしかかる時期となれば、その長さは不十分と考えられる。つまり、ハッシュ関数または楕円関数には、２５６ｂｉｔｓ程度の長さの鍵を利用することが望まれる。よって、ドライブ・ホスト認証も新たな方式が必要となる。

図２Ａおよび図２Ｂは、異なるタイプの光ディスクを用いた再生環境の一例を示す図である。

図２Ａに示すように、従来タイプ（バージョンＶ１．０）の光ディスク２１１には、そのバージョンＶ１．０に対応する、ドライブ２１２およびパーソナルコンピュータ２１３の組み合わせが用いられる。これに対して、図２Ｂに示すように、新たなタイプ（バージョンＶ２．０）の光ディスク２２１には、そのバージョンＶ２．０に対応する、ドライブ２２２およびパーソナルコンピュータ２２３の組み合わせが必要となる。

ここで、新たなタイプであるバージョンＶ２．０の光ディスク２２１に対しては、従来タイプのバージョン１．０の光ディスク２１１のよりも、レベルの高い著作権保護が要求されている。したがって、図２Ａに示したバージョンＶ１．０の組み合わせでは、ドライブ・ホスト認証は、バージョンＶ１．０で定める方式で行われる。これに対して図２Ｂに示したバージョンＶ２．０の組み合わせでは、ドライブ・ホスト認証は、バージョンＶ２．０で定める方式で行われる。

なお、一般的には、バージョンＶ２．０専用のドライブは考えにくく、一般的に市場に導入されるドライブは、バージョンＶ１．０とＶ２．０の共用ドライブとなると考えられる。これに対して、パーソナルコンピュータ２１３，２２３は、一定レベルの性能を持っていれば、バージョンＶ１．０でもＶ２．０でもどちらでも対応が可能である。ただし、バージョンＶ１．０の光ディスク２１１を再生するために必要な機能と、バージョンＶ２．０の光ディスク２２１を再生するために必要な機能は異なる。このため、その再生のために用いられるアプリケーションソフト（ＰＣソフト）は異なるものとなる。なお、パーソナルコンピュータ２２３で実行されるＰＣソフトは、バージョンＶ２．０専用であるとしたが、バージョンＶ１．０とＶ２．０の兼用であってもよい。兼用の場合、ＰＣソフトは、例えば、ユーザに対しては一つのＰＣソフトであるような表示を行い、内部的にそれらのバージョンの機能を区分するように構成される。

さて、ここで、バージョンＶ１．０とＶ２．０の共用のドライブを持つユーザが、Ｖ１．０の光ディスクとＶ２．０の光ディスクの両方を再生するケースを記載したものが図３Ａおよび図３Ｂである。

図３Ａおよび図３Ｂは、共用ドライブを用いた光ディスク再生環境の例を示す図である。

図３Ａおよび図３Ｂに示すように、ユーザは、共用ドライブ２２２とＰＣソフトの組み合わせによって、バージョンＶ１．０の光ディスク２１１と、バージョンＶ２．０の光ディスク２２１とを再生する。この際、パーソナルコンピュータ２１３によって実行されるバージョンＶ１．０のＰＣソフトは、バージョンＶ１．０の光ディスク２１１に対して、バージョンＶ１．０で定めるドライブ・ホスト認証のプロトコルで読み出しを行う。一方、パーソナルコンピュータ２２３によって実行されるバージョンＶ２．０のＰＣソフトは、バージョンＶ２．０の光ディスク２２１に対して、バージョンＶ２．０で定めるドライブ・ホスト認証のプロトコルで読み出しを行う必要がある。

しなしながら、共用ドライブ２２２は、ホストとなるパーソナルコンピュータ２１３、２２３からの読み出し命令に応じたバージョンＶ１．０のプロトコル、またはバージョンＶ２．０のプロトコルにしたがって、ドライブ・ホスト認証を行う。つまり、バージョンＶ２．０の光ディスク２２１からの読み出しであるにも関わらず、パーソナルコンピュータ２１３が読み出しを行おうとした場合には、共用ドライブ２２２は、バージョンＶ１．０のプロトコルでドライブ・ホスト認証を行う。このように、光ディスク２２１では、バージョンＶ２．０のレベルの高い著作権保護が要求されているにも関わらず、セキュリティレベルの低いバージョンＶ１．０のプロトコルでドライブ・ホスト認証が行われてしまう。したがって、光ディスクのコンテンツに対して適切な著作権保護を行うことができないという問題がある。

このような問題を解決するために、本発明の一態様に係るコンテンツ読み出し方法は、ホスト装置からの指示を受けて、記録媒体からコンテンツを読み出すコンテンツ読み出し方法であって、前記記録媒体におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報を、前記記録媒体に基づいて特定し、前記ホスト装置の認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定し、前記第１のバージョン情報と、前記第２のバージョン情報とを比較することによって、認証の是非を判定し、前記認証の是非の判定結果に基づいて、前記ホスト装置を認証し、前記記録媒体に格納されている暗号化された前記コンテンツの復号に用いられるメディア固有情報を、前記記録媒体から読み出して、認証された前記ホスト装置に通知し、暗号化された前記コンテンツを前記記録媒体から読み出して、認証された前記ホスト装置に通知する。例えば、記録媒体は、Ｂｌｕ−ｒａｙ（登録商標）ディスクなどの光ディスクである。

これにより、第１のバージョン情報と第２のバージョン情報との比較によって、ドライブ・ホスト認証などの認証の是非が判定される。したがって、例えば、第１のバージョン情報と第２のバージョン情報とが共にバージョンＶ１．０またはＶ２．０を示す場合には、認証を行うと判定し、ドライブ・ホスト認証を行うことができる。つまり、記録媒体において要求されている著作権保護のレベルに応じたドライブ・ホスト認証を適切に行うことができる。一方、第１のバージョン情報がバージョンＶ２．０を示し、第２のバージョン情報がバージョンＶ１．０を示す場合には、認証を行わないと判定し、ドライブ・ホスト認証を中止することができる。その結果、認証されていないホスト装置に対して、メディア固有情報と、暗号化されたコンテンツとが通知されてしまうことを防ぐことができる。つまり、記録媒体では、バージョンＶ２．０のレベルの高い著作権保護が要求されているにも関わらず、セキュリティレベルの低いバージョンＶ１．０のプロトコルでドライブ・ホスト認証が行われてしまうことを防ぐことができる。その結果、記録媒体のコンテンツに対して適切な著作権保護を行うことができる。

また、前記第１のバージョン情報の特定では、不正なホスト装置のリストであって前記記録媒体に格納されているホストリボケーションリストに含まれている前記第１のバージョン情報を読み出すことによって、当該第１のバージョン情報を特定してもよい。

一般的に、ドライブ・ホスト認証などの認証には、ホストリボケーションリストであるＨＲＬを記録媒体から読み出す必要がある。したがって、このようなＨＲＬに含まれている第１のバージョン情報を読み出すことによって、第１のバージョン情報を特定することは、実質的に新たな処理負荷をかけることなく簡単に行うことができる。したがって、記録媒体のコンテンツに対する適切な著作権保護を、処理負荷の増加を抑えて簡単に行うことができる。

また、前記第１のバージョン情報の特定では、前記記録媒体の物理特性に基づいて、前記第１のバージョン情報を特定してもよい。

これにより、第１のバージョン情報が記録媒体に記録されていなくても、例えば、記録媒体のレイヤーの数などの物理特性から、第１のバージョン情報を適切に特定することができる。

また、前記第１のバージョン情報の特定では、ディスクとして形成された前記記録媒体の先頭部分に格納されているメタデータであるディスク情報に基づいて、前記第１のバージョン情報を特定してもよい。

これにより、第１のバージョン情報を適切に特定することができる。

また、本発明の一態様に係る記録媒体は、著作権保護された暗号化コンテンツと、前記暗号化コンテンツの復号に用いられるメディア固有情報と、不正なホスト装置のリストであるホストリボケーションリストとが記録され、前記ホストリボケーションリストは、前記暗号化コンテンツの著作権保護方式のバージョンを示すバージョン情報と、署名とを含み、前記暗号化コンテンツと前記メディア固有情報との読み出しを指示するホスト装置と、前記ホスト装置からの指示を受けたコンテンツ読み出し装置との間の認証に用いられる。

これにより、記録媒体のホストリボケーションリストであるＨＲＬには、その記録媒体における著作権保護方式のバージョンを示すバージョン情報が含まれている。したがって、コンテンツ読み出し装置であるドライブは、ホスト装置との間での認証を行うか否かを、そのバージョン情報に基づいて適切に判定することができる。その結果、記録媒体において要求されている著作権保護のレベルに満たないセキュリティレベルの認証が行われることを防ぐことができる。したがって、記録媒体のコンテンツに対して適切な著作権保護を行うことができる。また、一般的に、ドライブ・ホスト認証などの認証には、ドライブはＨＲＬを記録媒体から読み出す必要がある。したがって、このようなＨＲＬに第１のバージョン情報が含まれているため、ドライブは、実質的に新たな処理負荷をかけることなく簡単に第１のバージョン情報を特定することができる。これにより、記録媒体のコンテンツに対する適切な著作権保護を、処理負荷の増加を抑えて簡単に行うことができる。さらに、ＨＲＬには署名が含まれているため、バージョン情報などの改竄に対する耐性を確保することができる。

以下、実施の形態について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態）
図４は、本実施の形態におけるドライブの構成を示すブロック図である。

ドライブ１０は、ホスト装置２０からの指示を受けて、記録媒体である光ディスク５０からコンテンツを読み出すコンテンツ読み出し装置である。光ディスク５０は、例えばＢｌｕ−ｒａｙ（登録商標）ディスクなどである。このようなドライブ１０は、光ディスク５０から情報を読み出してホスト装置２０に通知する読み出し処理部１０ａと、ホスト装置２０との間で上述のドライブ・ホスト認証を行う認証処理部１０ｂとを備えている。

ここで、光ディスク５０について詳細に説明する。

図５は、光ディスク５０に格納されているコンテンツの構造を模式的に示す図である。光ディスク５０上にはコンテンツとしてＭＰＥＧ２−ＴＳ形式でエンコードされたＳｔｅｒｅｍ Ｆｉｌｅが格納される。図５ではＳｔｒｅａｍ Ｆｉｌｅを一つしか記載していないが、複数になることもありえる。またここでは、Ｓｔｒｅａｍ ＦｉｌｅをＸＸＸＸＸ．Ｍ２ＴＳというファイル名で記録することとしている。ＸＸＸＸＸには番号が記載され、複数のコンテンツが格納される場合に、これのコンテンツを個別に管理することが可能である。

各Ｓｔｒｅａｍ Ｆｉｌｅは、６１４４ＢｙｔｅｓのＡｌｉｇｎｅｄ Ｕｎｉｔと呼ばれる単位に区分される。Ａｌｉｇｎｅｄ Ｕｎｉｔが暗号化の単位となる。なお、Ｓｔｒｅａｍ Ｆｉｌｅに格納されるコンテンツのデータ量は、必ずしも６１４４ Ｂｙｔｅｓの倍数にならない可能性もある。この場合には、コンテンツの末尾にＮＵＬＬ Ｄａｔａを格納する等の方法によって、コンテンツのデータ量を６１４４ Ｂｙｔｅｓの倍数にすることが望ましい。

図６は、各Ａｌｉｇｎｅｄ Ｕｎｉｔの復号方法を説明するための図である。光ディスク５０上のコンテンツは、ユニット鍵Ｋｕと呼ばれるデータを用いて暗号化されている。ここで、各Ａｌｉｇｎｅｄ Ｕｎｉｔの６１４４ Ｂｙｔｅｓのデータは、先頭の１６Ｂｙｔｅｓと、残る６１２８Ｂｙｔｅｓとに分離される。先頭の１６Ｂｙｔｅｓを対象として、先述したユニット鍵Ｋｕを用いて、ＡＥＳ暗号方式の復号処理であるＡＥＳ＿Ｅを行う。こうして得られたデータと、その先頭の１６Ｂｙｔｅｓとに対する排他的論理和（ＸＯＲ）を行う。次に、その排他的論理和によって得られたデータを鍵として用いて、残る６１２８Ｂｙｔｅｓ分のデータを、ＡＥＳ−ＤＣＢＣモードで復号する。こうして得られた平文のデータに、先頭の１６Ｂｙｔｅｓのデータを付け加えることで、６１４４Ｂｙｔｅｓ分の平文が得られる。

図７は、各Ａｌｉｇｎｅｄ Ｕｎｉｔの復号で用いるユニット鍵の記録方法を模式的に示す図である。この図７では、図５で示したＳｔｒｅａｍ Ｆｉｌｅに加えて、各Ｓｔｒｅａｍ Ｆｉｌｅを復号するための鍵を記録するためのデータであるＫｅｙ Ｆｉｌｅの構成が模式的に示されている。光ディスク５０には、Ｓｔｒｅａｍ Ｆｉｌｅとは別にＫｅｙ Ｆｉｌｅが格納される。図７の例では、「Ｓｔｒｅａｍ Ｆｉｌｅ ＃１」、「Ｓｔｒｅａｍ Ｆｉｌｅ ＃２」、および「Ｓｔｒｅａｍ Ｆｉｌｅ ＃３」の三つのファイルが光ディスク５０に記録されている。光ディスク５０には、この各々のＳｔｒｅａｍ Ｆｉｌｅに対応して、Ｋｅｙ Ｆｉｌｅの中に「Ｋｅｙ ＃１」、「Ｋｅｙ ＃２」、および「Ｋｅｙ ＃３」が記録されている。「Ｋｅｙ ＃１」にはその値として「Ｙ！４．ｄ」というデータが格納されている。ホスト装置２０（Ｐｌａｙｅｒ）がＳｔｒｅａｍ Ｆｉｌｅを復号する場合には、先述したユニット鍵Ｋｕとしてこの値が利用される。なお、ここでは、ユニット鍵Ｋｕが光ディスク５０に直接格納されているとしたが、実際には、ユニット鍵Ｋｕが平文で格納されていることはない。例えば、ユニット鍵Ｋｕは、ホスト装置２０などのＰｌａｙｅｒが保持するデバイス鍵で暗号化された状態で光ディスク５０に記録されている。

図８は、光ディスク５０に記録されている、Ｋｅｙ Ｆｉｌｅ以外の、コンテンツの保護に必要となるデータを模式的に示す図である。

光ディスク５０には、Ｖｏｌｕｍｅ ＩＤ、Ｈｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ（ＨＲＬ）、およびＭｅｄｉａ Ｋｅｙ Ｂｌｏｃｋ（ＭＫＢ）が記録されている。

Ｖｏｌｕｍｅ ＩＤは、メディア固有情報であって、コンテンツが格納された光ディスク５０を一意に特定するための識別子である。なお、パッケージメディアで利用されるＢＤ−ＲＯＭでは、スタンパによってディスクが制作されるため、同じコンテンツが格納されるＢＤ−ＲＯＭでは全て同じＶｏｌｕｍｅ ＩＤが記録されている。Ｖｏｌｕｍｅ ＩＤは、コピーや改竄が困難になるように、通常のデータとは異なる特殊な方法で記録されている。ホスト装置２０からの通常のコマンドでは、Ｖｏｌｕｍｅ ＩＤを読み出すことはできず、後述するドライブ・ホスト認証を実行した上でしかＶｏｌｕｍｅ ＩＤを読み出せない。

Ｈｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ（ＨＲＬ）は、ドライブ・ホスト認証のプロトコルにおいて利用されるデータであり、不正なホスト装置のリストを示す。ドライブ１０の認証処理部１０ｂは、このリストを読み出し、認証相手のホスト装置が不正なものであるかどうかを確認する。認証処理部１０ｂは、不正であると判断した場合には、Ｖｏｌｕｍｅ ＩＤなどの重要なデータをホスト装置には渡さない。ＨＲＬは、通常のデータとは異なる特殊な位置に記録される。ただし、記録の方法については他の通常のデータと変わらない。ドライブ１０が簡単に読み出せる位置（一般的には光ディスク５０内の固定位置）にＨＲＬが格納されていることによって、ドライブ１０はホスト装置２０からの指示無しでも、このＨＲＬを読み出すことが可能である。

Ｍｅｄｉａ Ｋｅｙ Ｂｌｏｃｋ（ＭＫＢ）は、ホスト装置２０によって処理されるデータである。ホスト装置２０は、このデータを処理することによって、先述したユニット鍵Ｋｕを生成するために必要となるメディア鍵を取得することが可能である。なお、ＭＫＢは、通常のデータと同様の方法で光ディスク５０に格納されており、ホスト装置２０からの一般的な読み出しコマンドで読み出される。

図９は、ＨＲＬのデータ構造の一例を示す図である。

ＨＲＬは、Ｔｙｐｅ ａｎｄ Ｖｅｒｓｉｏｎ Ｒｅｃｏｒｄと、Ｈｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｒｅｃｏｒｄとから構成される。

本実施の形態におけるＴｙｐｅ ａｎｄ Ｖｅｒｓｉｏｎ Ｒｅｃｏｒｄには、先頭から順に、Ｒｅｃｏｒｄ Ｔｙｐｅ、Ｒｅｃｏｒｄ Ｌｅｎｇｔｈ、ＭＫＢ ＴｙｐｅおよびＶｅｒｓｉｏｎ Ｎｕｍｂｅｒが記録されている。Ｒｅｃｏｒｄ Ｔｙｐｅは、記録されている情報の種別がＴｙｐｅ ａｎｄ Ｖｅｒｓｉｏｎ Ｒｅｃｏｒｄであることを示す。Ｒｅｃｏｒｄ Ｌｅｎｇｔｈは、Ｔｙｐｅ ａｎｄ Ｖｅｒｓｉｏｎ Ｒｅｃｏｒｄの長さを示す。ＭＫＢ Ｔｙｐｅは、記録されているＭＫＢのタイプを示す。Ｖｅｒｓｉｏｎ Ｎｕｍｂｅｒは、光ディスク５０におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報であって、例えば、上述のバージョンＶ１．０またはＶ２．０を示す。また、第１のバージョン情報は、例えば、ＡＡＣＳ（Ａｄｖａｎｃｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｅｎｔ Ｓｙｓｔｅｍ）の規格におけるバージョンを示す。

本実施の形態における認証処理部１０ｂは、光ディスク５０に格納されているＨＲＬに含まれているＶｅｒｓｉｏｎ Ｎｕｍｂｅｒを読み出すことによって、そのＶｅｒｓｉｏｎ Ｎｕｍｂｅｒを特定する。そして、認証処理部１０ｂは、ホスト装置２０からの光ディスク５０に対する読み出しの指示に対して、用いられるドライブ・ホスト認証プロトコルのバージョンを、このＶｅｒｓｉｏｎ Ｎｕｍｂｅｒに基づいて判断する。つまり、認証処理部１０ｂは、バージョンＶ１．０のドライブ・ホスト認証プロトコルを用いれば良いのか、それともバージョンＶ２．０のホスト・ドライブ認証プロトコルを用いれば良いのかを判断する。ＨＲＬは、ドライブ１０によって必ず読み出される。したがって、Ｖｅｒｓｉｏｎ ＮｕｍｂｅｒがＨＲＬに格納されていることは、ドライブ・ホスト認証プロトコルのバージョンを判定するためには好適である。さらに、ＨＲＬには、後述するように署名が付与されているため、改竄に対しても耐性がある。

Ｈｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｒｅｃｏｒｄには、先頭から順に、Ｒｅｃｏｒｄ Ｔｙｐｅ、Ｒｅｃｏｒｄ Ｌｅｎｇｔｈ、Ｎｕｍｂｅｒ ｏｆ Ｅｎｔｒｉｅｓ、Ｈｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｅｎｔｒｙ（０）〜（ｎ−１）、Ｖ１ Ｓｉｇｎａｔｕｒｅ ｆｏｒ Ｂｌｏｃｋ、およびＶ２ Ｓｉｇｎａｔｕｒｅ ｆｏｒ Ｂｌｏｃｋ、が記録されている。

Ｒｅｃｏｒｄ Ｔｙｐｅは、記録されている情報の種別がＨｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｒｅｃｏｒｄであることを示す。Ｒｅｃｏｒｄ Ｌｅｎｇｔｈは、Ｈｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｒｅｃｏｒｄの長さを示す。Ｎｕｍｂｅｒ ｏｆ Ｅｎｔｒｉｅｓは、実際のＨｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｅｎｔｒｙの数を示す。実際のＨｏｓｔ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ Ｅｎｔｒｙ（０）〜（ｎ−１）はそれぞれ、無効化の対象となったホスト装置のＩＤを示す。Ｖ１ Ｓｉｇｎａｔｕｒｅ ｆｏｒ ＢｌｏｃｋおよびＶ２ Ｓｉｇｎａｔｕｒｅ ｆｏｒ Ｂｌｏｃｋはそれぞれ、署名である。ここで、ドライブ・ホスト認証プロトコルＶ１．０では、１６０ビットの鍵が使われるため、Ｖ１ Ｓｉｇｎａｔｕｒｅ ｆｏｒ Ｂｌｏｃｋの署名は３２０ビットである。一方、ドライブ・ホスト認証プロトコルＶ２．０では、２５６ビットの鍵が使われるため、Ｖ２ Ｓｉｇｎａｔｕｒｅ ｆｏｒ Ｂｌｏｃｋの署名は、５１２ビットである。ドライブ１０は、ドライブ・ホスト認証プロトコルＶ１．０で動作するときには、３２０ビットの署名を検証し、ドライブ・ホスト認証プロトコルＶ２．０で動作するときには、５１２ビットの署名を検証する。

図１０は、ユニット鍵ＫｕをＫｅｙ Ｆｉｌｅから取得する処理を説明するための図である。ここでは、ユニット鍵Ｋｕは、暗号化された状態で光ディスク５０に格納されている。

再生プレイヤーであるホスト装置２０は、光ディスク５０に格納されているＭＫＢを、ドライブ１０を介して読み出す。このとき、ドライブ１０の読み出し処理部１０ａは、光ディスク５０からＭＫＢを読み出してホスト装置２０に通知する。そして、ホスト装置２０は、自らが保持するデバイス鍵を用いてそのＭＫＢを処理することにより、メディア鍵Ｋｍを生成する。ここで、ＭＫＢは、不正なホスト装置が保持するデバイス鍵では、正しいメディア鍵が取得できないように、予め生成されている。

さらに、ホスト装置２０は、光ディスク５０に格納されているＶｏｌｕｍｅ ＩＤを、ドライブ１０を介して読み出す。このとき、ドライブ１０の認証処理部１０ｂは、ホスト装置２０との間でドライブ・ホスト認証を行う。その認証後に、ドライブ１０の読み出し処理部１０ａは、Ｖｏｌｕｍｅ ＩＤを光ディスク５０から読み出して暗号化し、その暗号化されたＶｏｌｕｍｅ ＩＤをホスト装置２０に通知する。

ホスト装置２０は、このＶｏｌｕｍｅ ＩＤに対して、メディア鍵ＫｍとＨａｓｈ関数とを用いた処理を行うことにより、メディアユニーク鍵Ｋｍｕを取得する。このように、メディアユニーク鍵Ｋｍｕを取得するためには、Ｖｏｌｕｍｅ ＩＤが必須である。その理由は、通常手段では複製が極めて困難なＶｏｌｕｍｅ ＩＤによって、光ディスク５０の単純なｂｉｔ−ｂｙ−ｂｉｔコピーを防止するためである。

次に、ホスト装置２０は、ドライブ１０を介して、暗号化タイトル鍵Ｅｍｕ（Ｋｕ ＸＯＲ ＵＲ）をＫｅｙ Ｆｉｌｅから読み出す。このとき、ドライブ１０の読み出し処理部１０ａは、光ディスク５０から暗号化タイトル鍵Ｅｍｕ（Ｋｕ ＸＯＲ ＵＲ）を読み出してホスト装置２０に通知する。そして、ホスト装置２０は、この暗号化タイトル鍵Ｅｍｕ（Ｋｕ ＸＯＲ ＵＲ）を、メディアユニーク鍵Ｋｍｕを用いて復号することによって、変形ユニット鍵“Ｋｕ ＸＯＲ ＵＲ”を取得する。

さらに、ホスト装置２０は、光ディスク上から利用条件“Ｕｓａｇｅ Ｒｕｌｅ”を、ドライブ１０を介して読み出す。このとき、ドライブ１０の読み出し処理部１０ａは、光ディスク５０から利用条件“Ｕｓａｇｅ Ｒｕｌｅ”を読み出してホスト装置２０に通知する。そして、ホスト装置２０は、この利用条件“Ｕｓａｇｅ Ｒｕｌｅ”をＨａｓｈ関数にかけることによって得られる値ＵＲと、前述の変形ユニット鍵“Ｋｕ ＸＯＲ ＵＲ”との排他的論理和（ＸＯＲ）を行うことによって、ユニット鍵Ｋｕを得る。このように、ユニット鍵Ｋｕを取得するためには、利用条件“Ｕｓａｇｅ Ｒｕｌｅ”が必須である。その理由は、光ディスク５０における利用条件“Ｕｓａｇｅ Ｒｕｌｅ”の改竄を防止するためである。

上述のように、Ｖｏｌｕｍｅ ＩＤの読み出しには、ドライブ・ホスト認証が行われる。ドライブ１０の読み出し処理部１０ａは、この認証によって得られたバス鍵を用いて、Ｖｏｌｕｍｅ ＩＤを暗号化したうえでホスト装置２０に通知する。ホスト装置２０は、暗号化されたＶｏｌｕｍｅ ＩＤを復号することによって、Ｖｏｌｕｍｅ ＩＤを取得する。不正なホスト装置、またはホスト装置以外のモジュールは、ドライブ１０との間でバス鍵を共有することができない。したがって、不正なホスト装置などは、Ｖｏｌｕｍｅ ＩＤを正しく取得することはできない。

なお、上述の例では、Ｖｏｌｕｍｅ ＩＤは暗号化されるが、暗号化されなくてもよい。つまり、ドライブ１０の読み出し処理部１０ａは、Ｖｏｌｕｍｅ ＩＤをそのまま平文でホスト装置２０に通知する。このとき、読み出し処理部１０ａは、先述したバス鍵を用いてＭｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ（ＭＡＣ）をＶｏｌｕｍｅ ＩＤに付与し、ＭＡＣが付されたＶｏｌｕｍｅ ＩＤをホスト装置２０に通知する。これにより、Ｖｏｌｕｍｅ ＩＤの改竄を防ぐことができる。これは、Ｖｏｌｕｍｅ ＩＤそのものは秘密ではなく、改竄されないこと、または不正に記録されないことが要求されるためである。

図１１は、ドライブ１０とホスト装置２０との間でのドライブ・ホスト認証を示すシーケンス図である。

まず最初に、ステップＳ１０１にて、ドライブ１０の認証処理部１０ｂは、光ディスク５０からＨＲＬを読み出す。認証処理部１０ｂは、読み出したＨＲＬと、既にドライブ１０が保持しているＨＲＬとのバージョンの比較を行い、新しいバージョンのＨＲＬのみを保持する。このＨＲＬの読み出しによって、認証処理部１０ｂは、ＨＲＬに含まれる上述のＶｏｌｕｍｅ ＩＤを読み出す。これによって、認証処理部１０ｂは、光ディスク５０の著作権保護方式のバージョンを示す第１のバージョン情報を特定する。さらに、認証処理部１０ｂは、ドライブ１０とホスト装置２０との間での一連のやりとりを識別するための情報であるＡＧＩＤを生成し、これをホスト装置２０に通知する。

次に、ステップＳ１１１では、ホスト装置２０は、通知されたＡＧＩＤを保持するとともに、ランダム値であるＨｎを生成する。なお、ホスト・ドライブ認証プロトコルＶ１．０では、楕円関数において１６０ビットの鍵を利用するため、ホスト装置２０は、１６０ビットのランダム値Ｈｎを生成する。これに対して、ホスト・ドライブ認証プロトコルＶ２．０では、楕円関数において２５６ビットの鍵を利用するため、ホスト装置２０は、２５６ビットのランダム値Ｈｎを生成する。ホスト装置２０は、生成されたランダム値Ｈｎに、ホスト装置２０に付与された公開鍵証明書Ｈｃｅｒｔを付けて、ドライブ１０に対して通知する。

ステップＳ１０２では、ドライブ１０の認証処理部１０ｂは、ホスト装置２０から通知された、公開鍵証明書Ｈｃｅｒｔに記述されている鍵または署名などに基づいて、ドライブ・ホスト認証プロトコルのバージョンを示す第２のバージョン情報を特定する。例えば、公開鍵証明書Ｈｃｅｒｔには、図１１に示すように、Ｃｅｒｔｉｆｉｃａｔｅ Ｔｙｐｅと、Ｒｅｓｅｒｖｅｄと、Ｌｅｎｇｔｈと、Ｃｅｒｔｉｆｉｃａｔｅ ＩＤと、Ｒｅｓｅｒｖｅｄと、Ｐｕｂｌｉｃ Ｋｅｙと、Ｅｎｔｉｔｙ Ｓｉｇｎａｔｕｒｅとが記述されている。この公開鍵証明書Ｈｃｅｒｔに記述されているこれらの要素のうち、Ｐｕｂｌｉｃ ＫｅｙまたはＥｎｔｉｔｙ Ｓｉｇｎａｔｕｒｅの長さ（ビット数）は、ドライブ・ホスト認証プロトコルのバージョンによって異なる。したがって、認証処理部１０ｂは、そのＰｕｂｌｉｃ ＫｅｙまたはＥｎｔｉｔｙ Ｓｉｇｎａｔｕｒｅの長さに基づいて、第２のバージョン情報を特定する。また、公開鍵証明書Ｈｃｅｒｔにバージョン番号が記述されている場合には、認証処理部１０ｂは、そのバージョン番号を第２のバージョン情報として特定してもよい。なお、認証処理部１０ｂは、ランダム値Ｈｎに基づいて、第２のバージョン情報を特定してもよい。例えば、ランダム値Ｈｎの上述のビット数に応じて第２のバージョン情報を特定する。なお、第２のバージョン情報は、例えば、ＡＡＣＳ（Ａｄｖａｎｃｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｅｎｔ Ｓｙｓｔｅｍ）の規格におけるバージョンを示す。さらに、認証処理部１０ｂは、上述の特定された第１のバージョン情報であるＶｏｌｕｍｅ ＩＤと、第２のバージョン情報とを比較することによって、認証の是非を判定する。第１および第２のバージョン情報が共にＶ１．０またはＶ２．０であれば、認証処理部１０ｂは、認証を行うと判定する。一方、第１のバージョン情報がＶ２．０であって、第２のバージョン情報がＶ１．０であれば、認証処理部１０ｂは、認証を行わないと判定する。認証を行わないと判定したときには、認証処理部１０ｂは、ホスト装置２０にエラーを通知して、ドライブ・ホスト認証を中止する。

一方、認証を行うと判定したときには、ドライブ１０の認証処理部１０ｂは、公開鍵証明書Ｈｃｅｒｔの検証を行う。公開鍵証明書Ｈｃｅｒｔにはルートの公開鍵を用いて署名が付与されている。認証処理部１０ｂは、この署名を、ドライブ１０が保持するルートの公開鍵を用いて検証する。万が一、検証が失敗した場合には、認証処理部１０ｂは、一連のホスト・ドライブ認証をこの段階で中止する。さらに、署名検証が成功したとしても、公開鍵証明書Ｈｃｅｒｔの中に含まれるホスト装置２０のＩＤが、万が一先述するＨＲＬの中に登録されていた場合には、認証処理部１０ｂは、ホスト装置２０が不正であると判断する。その結果、認証処理部１０ｂは、ホスト・ドライブ認証をこの段階で中止する。これら一連の検証が無事に成功した段階で、認証処理部１０ｂは、ランダム値Ｄｎを生成する。ここで生成されるランダム値Ｄｎのビット長は、先述したランダム値Ｈｎのビット長と同一である。こうして認証処理部１０ｂは、ホスト装置２０に対して、生成されたランダム値Ｄｎと、ドライブ１０に付与された公開鍵証明書Ｄｃｅｒｔとをあわせてホスト装置２０に通知する。

ステップＳ１１２にて、上記通知を受け取ったホスト装置２０は、公開鍵証明書Ｄｃｅｒｔの検証を行う。公開鍵証明書Ｄｃｅｒｔには、ルートの公開鍵を用いて署名が付与されている。ホスト装置２０は、ホスト装置２０が保持するルートの公開鍵を用いて、その署名を検証する。万が一、検証が失敗した場合には、ホスト装置２０は、一連のドライブ・ホスト認証をこの段階で中止する。ここで、ホスト装置２０は、ドライブ１０が保持するＨＲＬと同様に、Ｄｒｉｖｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ（ＤＲＬ）を保有する。ＤＲＬは先述したＭＫＢの中に格納されている。ホスト装置２０は、このＭＫＢから新たなＤＲＬを取得して蓄積しておく。ホスト装置２０は、上述の署名検証が成功すると、公開鍵証明書Ｄｃｅｒｔの中に含まれるドライブ１０のＩＤが、ＤＲＬに登録されているか否かを判定する。ＤＲＬに登録されていると判定すると、ホスト装置２０は、このドライブ１０が不正であると判断して、ドライブ・ホスト認証をこの段階で中止する。

ステップＳ１０３では、ドライブ１０の認証処理部１０ｂは、ランダム値Ｄｋを生成する。このランダム値Ｄｋのビット長は先述したランダム値Ｄｎと同じ長さである。次に、認証処理部１０ｂは、予め定められた楕円関数のベース値とランダム値Ｄｋとから、値Ｄｖを計算する。さらに、認証処理部１０ｂは、ランダム値Ｈｎと値Ｄｖとを連結することによって得られる連結値に対して、ドライブ１０が保有する秘密鍵で署名Ｄｓｉｇを生成する。認証処理部１０ｂは、こうして得られた値Ｄｖと署名Ｄｓｉｇとを連結してホスト装置２０に通知する。

ステップＳ１１３では、ホスト装置２０は、まず、受け取った署名Ｄｓｉｇを検証する。具体的には、ホスト装置２０は、既にドライブ１０から受け取っている公開鍵証明書Ｄｃｅｒｔの中から公開鍵を取得し、この公開鍵を用いて署名Ｄｓｉｇを検証する。この検証に失敗した場合には、ホスト装置２０は、一連のホスト・ドライブ認証が失敗したと判断する。次に、ホスト装置２０は、ランダム値Ｈｋを生成する。このランダム値Ｈｋのビット長は先述したランダム値Ｈｎと同じ長さである。次に、ホスト装置２０は、予め定められた楕円関数のベース値とランダム値Ｈｋから値Ｈｖを計算する。さらに、ホスト装置２０は、ランダム値Ｄｎと値Ｈｖとを連結することによって得られた連結値に対して、ホスト装置２０が保有する秘密鍵で署名Ｈｓｉｇを生成する。ホスト装置２０は、こうして得られた値Ｈｖと署名Ｈｓｉｇとを連結してドライブ１０に通知する。

ステップＳ１０４では、ドライブ１０の認証処理部１０ｂは、受け取った署名Ｈｓｉｇを検証する。具体的には、認証処理部１０ｂは、既にホスト装置２０から受け取っている公開鍵証明書Ｈｃｅｒｔの中から公開鍵を取得し、この公開鍵を用いて署名Ｈｓｉｇを検証する。この検証に失敗した場合には、認証処理部１０ｂは、一連のホスト・ドライブ認証が失敗したと判断する。そして、認証処理部１０ｂは、ランダム値Ｄｋと値Ｈｖとを楕円曲線上で処理することにより、最終的にバス鍵Ｋｂを取得する。

ステップＳ１１４では、ホスト装置２０は、ドライブ１０と同様に、ランダム値Ｈｋと値Ｄｖを楕円曲線上で処理することにより、最終的に、ドライブ１０と同じバス鍵Ｋｂを取得する。

ドライブ１０の読み出し処理部１０ａは、上述のステップＳ１０１〜Ｓ１１４の処理からなるホスト・ドライブ認証が失敗することなく行われた後に、その認証によって得られたバス鍵Ｋｂを用いてＶｏｌｕｍｅ ＩＤを暗号化する。そして、読み出し処理部１０ａは、その暗号化されたＶｏｌｕｍｅ ＩＤをホスト装置２０に通知する。

なお、本実施の形態では、ＨＲＬに含まれている第１のバージョン情報であるＶｅｒｓｉｏｎ Ｎｕｍｂｅｒを読み出すことによって、その第１のバージョン情報を特定したが、このような読み出し以外の手法で、第１のバージョン情報を特定してもよい。

例えば、ドライブ１０の認証処理部１０ｂは、光ディスク５０の物理特性に基づいて、第１のバージョン情報を特定してもよい。つまり、認証処理部１０ｂは、光ディスク５０の物理特性として、例えばトラックピッチまたはレイヤーの数などを検出する。そして、検出されたトラックピッチが閾値よりも長ければ、あるいは、検出されたレイヤーの数が２層であれば、認証処理部１０ｂは、バージョンＶ１．０を示す第１のバージョン情報を特定する。一方、検出されたトラックピッチが閾値よりも短ければ、あるいは、検出されたレイヤーの数が３層であれば、認証処理部１０ｂは、バージョンＶ２．０を示す第１のバージョン情報を特定する。

また、ドライブ１０の認証処理部１０ｂは、ＨＲＬ以外の場所に記録されている第１のバージョン情報を読み出すことによって、その第１のバージョン情報を特定してもよい。ＨＲＬ以外の場所は、例えば、光ディスク５０の先頭部分に記録されているメタデータのＤｉｓｃ Ｉｎｆｏｒｍａｔｉｏｎである。このＤｉｓｃ Ｉｎｆｏｒｍａｔｉｏｎに、第１のバージョン情報がバージョン番号として含まれている。したがって、認証処理部１０ｂは、そのＤｉｓｃ Ｉｎｆｏｒｍａｔｉｏｎに基づいて、つまり、Ｄｉｓｃ Ｉｎｆｏｒｍａｔｉｏｎに含まれるバージョン番号を読み出すことによって、第１のバージョン情報を特定する。

また、ドライブ１０の認証処理部１０ｂは、ＨＲＬ、Ｄｉｓｃ Ｉｎｆｏｒｍａｔｉｏｎ、および、光ディスク５０の物理特性の全てに基づいて、第１のバージョン情報を特定してもよい。これにより、第１のバージョン情報をより正確に特定することができる。

図１２は、本実施の形態におけるドライブ１０の詳細な構成を示すブロック図である。

ドライブ１０は、ホスト装置２０からの指示を受けて、記録媒体である光ディスク５０からコンテンツを読み出す。このようなドライブ１０は、第１のバージョン特定部１１と、第２のバージョン特定部１２と、判定部１３と、認証部１４と、情報読み出し部１５と、コンテンツ読み出し部１６とを備える。

第１のバージョン特定部１１は、光ディスク５０におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報を、その光ディスク５０に基づいて特定する。具体的には、第１のバージョン特定部１１は、光ディスク５０に格納されているＨＲＬに含まれているＶｏｌｕｍｅ ＩＤを第１のバージョン情報として読み出すことによって、当該第１のバージョン情報を特定する。あるいは、第１のバージョン特定部１１は、光ディスク５０のレイヤーの数などの物理特性に基づいて、第１のバージョン情報を特定する。あるいは、第１のバージョン特定部１１は、光ディスク５０の先頭に格納されているメタデータであるＤｉｓｃ Ｉｎｆｏｒｍａｔｉｏｎに基づいて、第１のバージョン情報を特定する。

第２のバージョン特定部１２は、ホスト装置２０のドライブ・ホスト認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定する。具体的には、第２のバージョン特定部１２は、ホスト装置２０から通知される情報に基づいて、第２のバージョン情報を特定する。

判定部１３は、第１のバージョン情報と第２のバージョン情報とを比較することによって、ドライブ・ホスト認証の是非を判定する。例えば、判定部１３は、第１および第２のバージョン情報が共にＶ１．０またはＶ２．０であれば、認証を行うと判定する。一方、第１のバージョン情報がＶ２．０であって、第２のバージョン情報がＶ１．０である場合には、プロトコルのセキュリティレベルが、光ディスク５０のコンテンツに要求されている著作権保護のレベルよりも低い。したがって、このような場合には、判定部１３は、ドライブ・ホスト認証を行わないと判定する。

認証部１４は、ドライブ・ホスト認証の是非の判定結果に基づいて、ホスト装置２０との間でのドライブ・ホスト認証を行う。

情報読み出し部１５は、光ディスク５０に格納されている暗号化されたコンテンツの復号に用いられるＶｏｌｕｍｅ ＩＤであるメディア固有情報を、光ディスク５０から読み出して、認証されたホスト装置２０に通知する。

コンテンツ読み出し部１６は、暗号化されたコンテンツを光ディスク５０から読み出して、認証されたホスト装置２０に通知する。

なお、第１のバージョン特定部１１、第２のバージョン特定部１２、判定部１３、および認証部１４は、上記実施の形態における認証処理部１０ｂに含まれる。また、情報読み出し部１５およびコンテンツ読み出し部１６は、上記実施の形態における読み出し処理部１０ａに含まれる。

図１３は、本実施の形態におけるドライブ１０の処理動作を示すフローチャートである。

まず、ドライブ１０は、光ディスク５０におけるコンテンツの保護方式のバージョンを示す第１のバージョン情報を、その光ディスク５０に基づいて特定する（ステップＳ１１）。そして、ドライブ１０は、ホスト装置２０との間のドライブ・ホスト認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定する（ステップＳ１２）。

次に、ドライブ１０は、第１のバージョン情報と第２のバージョン情報とを比較することによって、ドライブ・ホスト認証の是非を判定する（ステップＳ１３）。ここで、ドライブ・ホスト認証を行うと判定すると（ステップＳ１３のＹｅｓ）、ドライブ１０は、ホスト装置２０との間でドライブ・ホスト認証を行う（ステップＳ１４）。一方、ドライブ・ホスト認証を行わない、つまり認証失敗と判定すると（ステップＳ１３のＮｏ）、ドライブ１０は、ホスト装置２０にエラーを通知して、光ディスク５０からの情報の読み出しを中止する。

ステップＳ１４の後には、ドライブ１０は、光ディスク５０に格納されている暗号化されたコンテンツの復号に用いられるＶｏｌｕｍｅ ＩＤであるメディア固有情報を、光ディスク５０から読み出して、認証されたホスト装置２０に通知する（ステップＳ１５）。そして、ドライブ１０は、暗号化されたコンテンツを光ディスク５０から読み出して、認証されたホスト装置２０に通知する（ステップＳ１６）。

このように、本実施の形態では、第１のバージョン情報と第２のバージョン情報との比較によって、ドライブ・ホスト認証などの認証の是非が判定される。したがって、例えば、第１のバージョン情報と第２のバージョン情報とが共にバージョンＶ１．０またはＶ２．０を示す場合には、認証を行うと判定し、ドライブ・ホスト認証を行うことができる。つまり、記録媒体において要求されている著作権保護のレベルに応じたドライブ・ホスト認証を適切に行うことができる。一方、第１のバージョン情報がバージョンＶ２．０を示し、第２のバージョン情報がバージョンＶ１．０を示す場合には、認証を行わないと判定し、ドライブ・ホスト認証を中止することができる。その結果、認証されていないホスト装置に対して、メディア固有情報と、暗号化されたコンテンツとが通知されてしまうことを防ぐことができる。つまり、記録媒体では、バージョンＶ２．０のレベルの高い著作権保護が要求されているにも関わらず、セキュリティレベルの低いバージョンＶ１．０のプロトコルでドライブ・ホスト認証が行われてしまうことを防ぐことができる。その結果、記録媒体のコンテンツに対して適切な著作権保護を行うことができる。

また、本実施の形態では、不正なホスト装置のリストであって光ディスク５０に格納されているＨＲＬに含まれているＶｏｌｕｍｅ ＩＤを読み出すことによって、第１のバージョン情報を特定する。一般的に、ドライブ・ホスト認証などの認証には、ＨＲＬを記録媒体から読み出す必要がある。したがって、このようなＨＲＬに含まれているＶｏｌｕｍｅ ＩＤを読み出すことによって、第１のバージョン情報を特定することは、実質的に新たな処理負荷をかけることなく簡単に行うことができる。したがって、光ディスク５０のコンテンツに対する適切な著作権保護を、処理負荷の増加を抑えて簡単に行うことができる。

なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態のドライブ１０などを実現するソフトウェアは、コンピュータに、図１１または図１３に示す各ステップを実行させる。

以上、一つまたは複数の態様に係るコンテンツ読み出し方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。

本発明は、例えば光ディスクなどの記録媒体からコンテンツを読み出すドライブなどに適用することができる。つまり、本発明は、従来型の光ディスクと、より高画質なコンテンツを格納する光ディスクの両方に対応するドライブにおいて、再生する光ディスクの種別によって、正しくホスト機器と認証を行うための仕組みとして利用することができる。

１０ ドライブ
１０ａ 読み出し処理部
１０ｂ 認証処理部
１１ 第１のバージョン特定部
１２ 第２のバージョン特定部
１３ 判定部
１４ 認証部
１５ 情報読み出し部
１６ コンテンツ読み出し部
２０ ホスト装置
５０ 光ディスク

Claims (6)

1. ホスト装置からの指示を受けて、記録媒体からコンテンツを読み出すコンテンツ読み出し方法であって、
   前記記録媒体におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報を、前記記録媒体に基づいて特定し、
   前記ホスト装置の認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定し、
   前記第１のバージョン情報と、前記第２のバージョン情報とを比較することによって、認証の是非を判定し、
   前記認証の是非の判定結果に基づいて、前記ホスト装置を認証し、
   前記記録媒体に格納されている暗号化された前記コンテンツの復号に用いられるメディア固有情報を、前記記録媒体から読み出して、認証された前記ホスト装置に通知し、
   暗号化された前記コンテンツを前記記録媒体から読み出して、認証された前記ホスト装置に通知する
   コンテンツ読み出し方法。
2. 前記第１のバージョン情報の特定では、
   不正なホスト装置のリストであって前記記録媒体に格納されているホストリボケーションリストに含まれている前記第１のバージョン情報を読み出すことによって、当該第１のバージョン情報を特定する
   請求項１に記載のコンテンツ読み出し方法。
3. 前記第１のバージョン情報の特定では、
   前記記録媒体の物理特性に基づいて、前記第１のバージョン情報を特定する
   請求項１に記載のコンテンツ読み出し方法。
4. 前記第１のバージョン情報の特定では、
   ディスクとして形成された前記記録媒体の先頭部分に格納されているメタデータであるディスク情報に基づいて、前記第１のバージョン情報を特定する
   請求項１に記載のコンテンツ読み出し方法。
5. ホスト装置からの指示を受けて、記録媒体からコンテンツを読み出すコンテンツ読み出し装置であって、
   前記記録媒体におけるコンテンツの著作権保護方式のバージョンを示す第１のバージョン情報を、前記記録媒体に基づいて特定する第１のバージョン特定部と、
   前記ホスト装置の認証で用いられるプロトコルのバージョンを示す第２のバージョン情報を特定する第２のバージョン特定部と、
   前記第１のバージョン情報と、前記第２のバージョン情報とを比較することによって、認証の是非を判定する判定部と、
   前記認証の是非の判定結果に基づいて、前記ホスト装置を認証する認証部と、
   前記記録媒体に格納されている暗号化されたコンテンツの復号に用いられるメディア固有情報を、前記記録媒体から読み出して、認証された前記ホスト装置に通知する情報読み出し部と、
   暗号化された前記コンテンツを前記記録媒体から読み出して、認証された前記ホスト装置に通知するコンテンツ読み出し部と
   を備えるコンテンツ読み出し装置。
6. 著作権保護された暗号化コンテンツと、
   前記暗号化コンテンツの復号に用いられるメディア固有情報と、
   不正なホスト装置のリストであるホストリボケーションリストとが記録され、
   前記ホストリボケーションリストは、
   前記暗号化コンテンツの著作権保護方式のバージョンを示すバージョン情報と、署名とを含み、
   前記暗号化コンテンツと前記メディア固有情報との読み出しを指示するホスト装置と、前記ホスト装置からの指示を受けたコンテンツ読み出し装置との間の認証に用いられる、
   記録媒体。

Images