JP4479698B2 - コンテンツ提供システム - Google Patents

Description

本発明は、コンテンツ提供システムに関し、特に、コンテンツの不正な利用を確実に防止できるようにするコンテンツ提供システムに関する。

近年、各種のブロードバンド環境が整備されつつあり、音楽データや動画データなどの各種のコンテンツの配信サービスが本格的に開始され始めている。

例えば、「PressPlay（商標）」などの定期購読型（subscription型）の音楽配信サービスが行われており、この音楽配信サービスにおいては、ユーザは、月極の定額の料金を支払うことで、予め設定されている条件の範囲内（例えば、ストリーミング再生の場合１０００曲まで再生可能、ダウンロードしてパーソナルコンピュータのハードディスクに保存する場合１００曲まで保存可能、CD(Compact Disk)-Rへの書き込み（コピー）する場合２０曲までコピー可能などの条件の範囲内）で音楽コンテンツを利用することができる。

ところで、このような配信サービスによるコンテンツの提供を受けるユーザの権利情報を管理するシステムとして、例えば、特開平２００１−３５２３２１号公報には、複数のサービスに対応するノードをツリー状に配置してなるシステムにおいて、所定のサービスに対応するノードから、そのサービスに属するそれぞれのリーフのノード（デバイス）までのパス上に存在するノードに設定されている鍵情報（DNK(Device Node Key)）を含む有効化キーブロック（EKB(Enabling Key Block)）を用いることが開示されている。

このシステムでは、あるサービスにおいて配信されるコンテンツにEKBが付加されており、個々のデバイスに対して与えられているDNKを用いて、EKBに含まれる、更新された鍵情報を取得させることにより、サービスを利用できるデバイスを管理している。この場合において、DNKを利用して、EKBから、更新された鍵情報を取得できないデバイスは、その後、サービスの提供を受けることができない。

そして、これにより、コンテンツを提供するサーバとデバイスとの間で認証処理などをその都度行うことなく、それぞれのデバイスにおけるコンテンツの利用を管理できるようにしたものである。

しかしながら、このEKBを利用するシステムにおいては、EKBに記述されている情報が読み取られた場合、その情報により、あるサービスから配信される全てのコンテンツ（同一のEKBが付加されている全てのコンテンツ）が利用できてしまうという課題があった。

例えば、図１に示されるようなフォーマットにより、サービスＡからデータ１およびデータ２が提供されている場合、データ１のEKBに記述されている内容を取得したデバイスＡは、取得した鍵情報を利用することで、データ１に含まれるコンテンツ１だけでなく、データ２に含まれるコンテンツ２をも利用することができる。

すなわち、図１に示されるように、データ１は、EKB、EKBに含まれるルートキー（システムのルートのノードに対応するキー）（Ｋroot）により暗号化されたコンテンツキー１（Ｋｃ１）、およびコンテンツキー１により暗号化されたコンテンツ１（Content1）から構成されており、デバイスＡは、EKBからルートキーを取得した場合、ルートキーによりコンテンツキー１を復号し、取得したコンテンツキー１によりコンテンツ１を復号することができる。

また、デバイスＡは、データ１と同様のフォーマットのデータ２に含まれているコンテンツキー２（Ｋｃ２）を、データ１のEKBから取得したルートキーを利用して取得することができ、取得したコンテンツキー２により、コンテンツ２（Content2）を復号することができる。

従って、データ１からルートキーが取得されたデバイスにおいては、例えば、他のデバイスから記録媒体に記録されて提供されてきたものであるなど、データ２が何の権利も無しに取得されたものであっても、それが利用できることとなり、このような不正な利用により、コンテンツの正当な流通が妨げられるとともに、コンテンツを提供する事業者の利益が失われてしまう。

本発明はこのような状況に鑑みてなされたものであり、コンテンツが不正に利用されることを確実に防止できるようにするものである。

本発明のコンテンツ提供システムは、コンテンツを提供するコンテンツサーバと、前記コンテンツを利用するのに必要な利用権を提供するライセンスサーバと、前記コンテンツサーバと前記ライセンスサーバとの間でネットワークを介して情報を送受信する情報処理装置とからなるコンテンツ提供システムにおいて、前記情報処理装置は、前記ライセンスサーバに対して、前記情報処理装置に対応するデバイスノードキーと前記情報処理装置に固有の個別鍵とを含むサービスデータの送信を要求する要求手段と、前記要求手段による要求に応じて前記ライセンスサーバから送信された前記サービスデータを受信する受信手段と、前記受信手段により受信された前記サービスデータを記憶する記憶手段と、前記コンテンツサーバから、暗号化されたコンテンツデータと暗号化された第１の鍵を受信し、前記ライセンスサーバから、コンテンツの利用が指示されることに応じて取得される、前記コンテンツに対応する暗号化された第２の鍵を含む利用権を受信する受信手段と、前記記憶手段に記憶されている前記サービスデータに含まれる前記デバイスノードキーを用いて、前記暗号化された第１の鍵を復号して抽出し、前記個別鍵を用いて、前記受信された利用権から、前記暗号化された第２の鍵を復号して抽出し、抽出した前記第１の鍵と前記第２の鍵とで所定の演算を行うことで前記暗号化されたコンテンツデータの復号鍵を生成する演算手段と、前記復号鍵を用いて前記暗号化されたコンテンツデータを復号する復号手段と、前記復号手段により復号されたコンテンツデータを再生する再生手段とを備え、前記コンテンツサーバは、前記復号鍵と、前記利用権に含めて前記サービスサーバから前記情報処理装置に送信される前記第２の鍵と、前記第２の鍵とで前記所定の演算を行うことで前記復号鍵を生成することに用いられる前記第１の鍵とを生成する生成手段と、前記生成手段により生成された前記第１の鍵を、前記デバイスノードキーによって復号可能な形で暗号化し、前記コンテンツデータを、前記復号鍵を用いて暗号化する暗号化手段と、前記暗号化手段により暗号化された前記第１の鍵と前記コンテンツデータとを前記情報処理装置に送信し、前記第２の鍵を前記ライセンスサーバに送信する送信手段とを備え、前記ライセンスサーバは、前記コンテンツサーバから送信された前記第２の鍵を受信する受信手段と、前記受信手段により受信された前記第２の鍵を、前記情報処理装置の前記個別鍵に対応する公開鍵を用いて暗号化する暗号化手段と、前記デバイスノードキーと前記情報処理装置の前記個別鍵とを含む前記サービスデータを前記情報処理装置に送信し、前記暗号化手段により暗号化された前記第２の鍵を含む前記利用権を前記情報処理装置に送信する送信手段とを備える。

本発明のコンテンツ提供システムにおいては、情報処理装置により、ライセンスサーバに対して、前記情報処理装置に対応するデバイスノードキーと前記情報処理装置に固有の個別鍵とを含むサービスデータの送信が要求され、要求に応じて前記ライセンスサーバから送信された前記サービスデータが受信され、受信された前記サービスデータが記憶される。また、コンテンツサーバから、暗号化されたコンテンツデータと暗号化された第１の鍵が受信され、前記ライセンスサーバから、コンテンツの利用が指示されることに応じて取得される、前記コンテンツに対応する暗号化された第２の鍵を含む利用権が受信される。前記サービスデータに含まれる前記デバイスノードキーを用いて、前記暗号化された第１の鍵が復号されて抽出され、前記個別鍵を用いて、前記受信された利用権から、前記暗号化された第２の鍵が復号されて抽出され、抽出された前記第１の鍵と前記第２の鍵とで所定の演算を行うことで前記暗号化されたコンテンツデータの復号鍵が生成される。前記復号鍵を用いて前記暗号化されたコンテンツデータが復号され、復号されたコンテンツデータが再生される。また、前記コンテンツサーバにより、前記復号鍵と、前記利用権に含めて前記サービスサーバから前記情報処理装置に送信される前記第２の鍵と、前記第２の鍵とで前記所定の演算を行うことで前記復号鍵を生成することに用いられる前記第１の鍵とが生成され、生成された前記第１の鍵が、前記デバイスノードキーによって復号可能な形で暗号化され、前記コンテンツデータが、前記復号鍵を用いて暗号化される。また、暗号化された前記第１の鍵と前記コンテンツデータとが前記情報処理装置に送信され、前記第２の鍵が前記ライセンスサーバに送信される。さらに、前記ライセンスサーバにより、前記コンテンツサーバから送信された前記第２の鍵が受信され、受信された前記第２の鍵が、前記情報処理装置の前記個別鍵に対応する公開鍵を用いて暗号化され、前記デバイスノードキーと前記情報処理装置の前記個別鍵とを含む前記サービスデータが前記情報処理装置に送信され、暗号化された前記第２の鍵を含む前記利用権が前記情報処理装置に送信される。

本発明によれば、コンテンツを提供することができる。また、不正なコンテンツの利用を防止することができる。

図２は、本発明を適用したコンテンツ提供システムの構成を示している。インターネット２には、クライアント１−１，１−２（以下、これらのクライアントを個々に区別する必要がない場合、単にクライアント１と称する）が接続されている。この例においては、クライアントが２台のみ示されているが、インターネット２には、任意の台数のクライアントが接続される。

また、インターネット２には、クライアント１に対してコンテンツを提供するコンテンツサーバ３、コンテンツサーバ３が提供するコンテンツを利用するのに必要な利用権をクライアント１に対して付与するライセンスサーバ４、およびクライアント１が利用権を受け取った場合に、そのクライアント１に対して課金処理を行う課金サーバ５が接続されている。

これらのコンテンツサーバ３、ライセンスサーバ４、および課金サーバ５も、任意の台数だけ、インターネット２に接続される。

図３はクライアント１の構成を表している。

図３において、CPU(Central Processing Unit)２１は、ROM(Read Only Memory)２２に記憶されているプログラム、または記憶部２８からRAM(Random Access Memory)２３にロードされたプログラムに従って各種の処理を実行する。タイマ２０は、計時動作を行い、時刻情報をCPU２１に供給する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。

暗号化復号部２４は、コンテンツを暗号化するとともに、既に暗号化されているコンテンツを復号する処理を行う。コーデック部２５は、例えば、ATRAC(Adaptive Transform Acoustic Coding)３方式などでコンテンツをエンコードし、入出力インタフェース３２を介してドライブ３０に接続されている半導体メモリ４４に供給し、記録させる。あるいはまた、コーデック部２５は、ドライブ３０を介して半導体メモリ４４より読み出した、エンコードされているデータをデコードする。半導体メモリ４４は、例えば、メモリスティック（商標）などにより構成される。

CPU２１、ROM２２、RAM２３、暗号化復号部２４、およびコーデック部２５は、バス３１を介して相互に接続されている。このバス３１にはまた、入出力インタフェース３２も接続されている。

入出力インタフェース３２には、キーボード、マウスなどよりなる入力部２６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、インターネット２を介しての通信処理を行う。通信部２９はまた、他のクライアントとの間で、アナログ信号またはデジタル信号の通信処理を行う。

入出力インタフェース３２にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。

なお、図示は省略するが、コンテンツサーバ３、ライセンスサーバ４、課金サーバ５も、図３に示したクライアント１と基本的に同様の構成を有するコンピュータにより構成される。そこで、以下の説明においては、図３の構成は、コンテンツサーバ３、ライセンスサーバ４、課金サーバ５などの構成としても引用される。

本発明においては、図４に示されるように、ブロードキャストインクリプション（Broadcast Encryption）方式の原理に基づいて、デバイスとキーが管理される。キーは、階層ツリー構造とされ、最下段のリーフ（leaf）が個々のデバイス固有のキーに対応する。本発明のシステムに用いられる階層ツリー構造鍵管理については特開２００１−３５２３２１号公報に記載されている。図４の例の場合、番号０から番号１５までの１６個のデバイスに対応するキーが生成される。

各キーは、図中丸印で示されるツリー構造の各ノードに対応して規定される。この例では、最上段のルートノードに対応してルートキーＫＲ（適宜、Ｋrootとも称する）が規定され、２段目のノードに対応してキーＫ０，Ｋ１が規定される。また、３段目のノードに対応してキーＫ00乃至Ｋ11が規定され、第４段目のノードに対応してキーＫ000乃至キーＫ111が規定される。そして、最下段のノードとしてのリーフ（デバイスノード）に、キーＫ0000乃至Ｋ1111が、それぞれ対応されている。

階層構造とされているため、例えば、キーＫ0010とキーＫ0011の上位のキーは、Ｋ001とされ、キーＫ000とキーＫ001の上位のキーは、Ｋ00とされている。以下、同様に、キーＫ00とキーＫ01の上位のキーは、Ｋ０とされ、キーＫ０とキーＫ１の上位のキーは、ＫＲとされている。

コンテンツを利用するキーは、最下段のデバイスノード（リーフ）から、最上段のルートノードまでの１つのパスの各ノードに対応するキーで管理される。例えば、番号３のリーフに対応するデバイスにおいて、コンテンツを利用するためのキーは、キーＫ0011，Ｋ001，Ｋ00，Ｋ０，ＫＲを含むパスの各キーで管理される。

本発明のシステムにおいては、図５に示されるように、図４の原理に基づいて構成されるキーシステムで、デバイスのキーとコンテンツのキーの管理が行われる。図５の例では、８＋２４＋３２段のノードがツリー構造とされ、ルートノードから下位の８段までの各ノードにカテゴリが対応される。ここにおけるカテゴリとは、例えばメモリスティックなどの半導体メモリを使用する機器のカテゴリ、或いは、デジタル放送を受信する機器のカテゴリといったカテゴリを意味する。そして、このカテゴリノードのうちの１つのノードに、利用権を管理するシステムとして本システム（適宜、Ｔシステムと称する）が対応する。

すなわち、Ｔシステムのノードよりさらに下の階層の２４段のノードに対応するキーにより、サービスプロバイダ、あるいはサービスプロバイダが提供するサービスが対応される。従って、図５の例においては、２²⁴（約１６メガ）のサービスプロバイダ、あるいはサービスを規定することができる。また、最下段の３２段の階層により、２³²（約４ギガ）のユーザ（クライアント１）を規定することができる。最下段の３２段のノードからＴシステムのノードまでのパス上の各ノードに対応するキーが、DNK(Device Node Key)を構成し、最下段のリーフに対応するIDがリーフIDとされる。

コンテンツを暗号化したコンテンツキーは更新されたルートキーＫＲ'によって暗号化され、上位の階層の更新ノードキーは、その直近の下位の階層の更新ノードキーを用いて暗号化され、EKB（Enabling Key Block：有効化キーブロック）（図７を参照して後述する）内に配置される。

EKBにおける末端から１つ上の段の更新ノードキーはEKBの末端のノードキーあるいはリーフキーによって暗号化され、EKB内に配置される。クライアント１は、サービスデータに記述されているDNKのいずれかのキーを用いて、コンテンツとともに配布されるEKBに記述されている直近の上位の階層の更新ノードキーを復号し、復号して得たノードキーを用いて、EKBに記述されている、さらにその上の階層の更新ノードキーを復号する。同様の処理を順次行うことで、クライアント１は、更新ルートキーＫＲ'を得ることができる。サービスデータは、クライアント１についての情報を登録したときにライセンスサーバ４から供給されるものであり、このサービスデータと、後述する、特定のコンテンツの利用を許可する情報である利用権の組み合わせをライセンスと呼ぶ。

図６は、階層ツリー構造のカテゴリの分類の具体的な例を示す図である。

図６において、階層ツリー構造の最上段には、ルートキーＫＲ2301が設定され、以下の中間段にはノードキー2302が設定され、最下段には、リーフキー2303が設定される。各デバイスは、個々のリーフキーと、リーフキーからルートキーに至る一連のノードキー、ルートキーからなるデバイスノードキー（DNK）を保有する。

最上段から第Ｍ段目（図５の例では、Ｍ＝８）の所定のノードがカテゴリノード2304として設定される。すなわち、第Ｍ段目のノードの各々が特定カテゴリのデバイス設定ノードとされる。第Ｍ段の１つのノードを頂点としてＭ＋１段以下のノード、リーフは、そのカテゴリに含まれるデバイスに関するノードおよびリーフとされる。

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

Ｍ段から数段分下位の段をサブカテゴリノード2306として設定することができる。図６の例では、カテゴリ［メモリスティック］ノード2305の２段下のノードに、メモリスティックを使用したデバイスのカテゴリに含まれるサブカテゴリノードとして、［再生専用器］のノード2306が設定されている。また、サブカテゴリノードである再生専用器のノード2306以下に、再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード2307が設定され、さらにその下位に、音楽再生機能付き電話のカテゴリに含まれる［PHS］ノード2308と、［携帯電話］ノード2309が設定されている。

カテゴリ、サブカテゴリは、デバイスの種類のみならず、例えば、あるメーカー、コンテンツプロバイダ、決済機関等が独自に管理するノード、すなわち処理単位、管轄単位、或いは提供サービス単位等、任意の単位（これらを総称して以下、エンティティと呼ぶ）で設定することが可能である。

例えば、１つのカテゴリノードをゲーム機器メーカーの販売するゲーム機器XYZ専用の頂点ノードとして設定することにより、メーカーの販売するゲーム機器XYZに、その頂点ノード以下の下段のノードキー、リーフキーを格納して販売することができ、その後、その頂点ノードキー以下のノードキー、リーフキーによって構成されるEKBを生成して配信することで、暗号化コンテンツの配信処理、各種キーの配信処理、更新処理等を、頂点ノード以下のデバイス（ゲーム機器XYZ）に対してのみ行うことができる。

すなわち、頂点ノードに属さない、他のカテゴリのノードに属するデバイスには全く影響を及ぼすことなく、キーの更新等を実行することができる。

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

更新キーの配布処理ついて説明する。キーの更新は、例えば、図７に示されるEKBによって構成されるテーブルを、ネットワークを介して、あるいは所定の記録媒体に格納してデバイス０，１，２に供給することによって実行される。なお、EKBは、図４に示されるようなツリー構造を構成する各リーフ（最下段のノード）に対応するデバイスに、新たに更新されたキーを配布するための暗号化キーによって構成される。

図７に示されるEKBは、ノードキーの更新の必要なデバイスのみが更新可能なデータ構成を持つブロックデータとして構成される。図７の例は、図４に示されるツリー構造中のデバイス０，１，２において、世代ｔの更新ノードキーを配布することを目的として形成されたブロックデータである。

図４から明らかなように、デバイス０，１に対しては、更新ノードキーとしてＫ(ｔ)00，Ｋ(ｔ)０，Ｋ(ｔ)Ｒを提供することが必要であり、デバイス２に対しては、更新ノードキーとしてＫ(ｔ)001，Ｋ(ｔ)00，Ｋ(ｔ)０，Ｋ(ｔ)Ｒを提供することが必要である。

図７のEKBに示されるように、EKBには複数の暗号化キーが含まれ、例えば、図７の最下段の暗号化キーは、Enc（Ｋ0010，Ｋ(ｔ)001）である。これは、デバイス２の持つリーフキーＫ0010によって暗号化された更新ノードキーＫ(ｔ)001であり、デバイス２は、自分自身が有するリーフキーＫ0010によって、暗号化キーを復号し、更新ノードキーＫ(ｔ)001を取得できる。

また、デバイス２は、復号により得た更新ノードキーＫ(ｔ)001を用いて、図７の下から２段目の暗号化キーEnc（Ｋ(ｔ)001，Ｋ(ｔ)00）を復号することができ、更新ノードキーＫ(ｔ)00を取得することができる。

デバイス２は、同様に、図７の上から２段目の暗号化キーEnc（Ｋ(ｔ)00，Ｋ(ｔ)０）を復号することで、更新ノードキーＫ(ｔ)０を取得でき、これを用いて、図７の上から１段目の暗号化キーEnc（Ｋ(ｔ)０，Ｋ(ｔ)Ｒ）を復号することで、更新ルートキーＫ(ｔ)Ｒを取得できる。

一方、ノードキーＫ000は、更新する対象のキーに含まれておらず、ノード０，１が更新ノードキーとして必要なのは、Ｋ(ｔ)00，Ｋ(ｔ)０，Ｋ(ｔ)Ｒである。

ノード０，１は、デバイスキーＫ0000，Ｋ0001を用いて、図７の上から３段目の暗号化キーEnc（Ｋ000，Ｋ(ｔ)00）を復号することにより更新ノードキーＫ(ｔ)00を取得し、同様に、順次、図７の上から２段目の暗号化キーEnc（Ｋ(ｔ)00，Ｋ(ｔ)０）を復号することで、更新ノードキーＫ(ｔ)０を取得し、さらに、図７の上から１段目の暗号化キーEnc（Ｋ(ｔ)０，Ｋ(ｔ)Ｒ）を復号することで、更新ルートキーＫ(ｔ)Ｒを取得する。このようにして、デバイス０，１，２は、更新したキーＫ(ｔ)Ｒを得ることができる。

なお、図７のインデックスは、図の右側に示される暗号化キーを復号するための復号キーとして使用するノードキー、リーフキーの絶対番地を示す。

図４に示されるツリー構造の上位段のノードキーＫ(ｔ)０，Ｋ(ｔ)Ｒの更新が不要であり、ノードキーＫ00のみの更新処理が必要である場合には、図８のEKBを用いることで、更新ノードキーＫ(ｔ)00をデバイス０，１，２に配布することができる。

図８に示されるEKBは、例えば、特定のグループにおいて共有される新たなコンテンツキーを配布する場合に利用可能である。

例えば、図４の一点鎖線で示されるグループ内のデバイス０，１，２，３が、ある記録媒体を用いており、それらのデバイスに対して新たな共通のコンテンツキーＫ(ｔ)conを設定することが必要であるとする。このとき、デバイス０，１，２，３の共通のノードキーＫ00を更新したＫ(ｔ)00により、新たな共通の更新コンテンツキーＫ(ｔ)conが暗号化されたデータEnc（Ｋ(ｔ)00，Ｋ(ｔ)con）が、図８に示されるEKBとともに配布される。この配布により、デバイス４など、その他のグループの機器が復号することができないデータとしての配布が可能となる。

すなわち、デバイス０，１，２は、EKBを処理して得たキーＫ(ｔ)00を用いて暗号データを復号することで、ｔ時点におけるコンテンツキーＫ(ｔ)conを得ることができる。

図９は、ｔ時点でのコンテンツキーＫ(ｔ)conを得る処理の例として、Ｋ(ｔ)00により新たな共通のコンテンツキーＫ(ｔ)conが暗号化されたデータEnc（Ｋ(ｔ)00，Ｋ(ｔ)con）と、図８に示されるEKBが、所定の記録媒体を介して提供されたデバイス０の処理を模式的に示す図である。すなわち、図９の例は、EKBによる暗号化メッセージデータをコンテンツキーＫ(ｔ)conとした例である。

図９に示されるように、デバイス０は、記録媒体に格納されている世代ｔ時点のEKBと、自分自身に予め用意されているノードキーＫ000を用いて、上述したようなEKB処理（鍵を順次解く処理）により、ノードキーＫ(ｔ)00を生成する。また、デバイス０は、復号した更新ノードキーＫ(ｔ)00を用いて、更新コンテンツキーＫ(ｔ)conを復号し、それを後に使用するために、自分だけが有するリーフキーＫ0000で、更新コンテンツキーＫ(ｔ)conを暗号化して格納する。

図１０は、EKBのフォーマットの例を示す図であり、このような各種の情報からなるEKBが、コンテンツデータのヘッダに含まれる。

バージョン６１は、EKBのバージョンを示す識別子である。このバージョン６１は、最新のEKBを識別する機能と、コンテンツとの対応関係を示す機能を有する。デプス６２は、EKBの配布先のデバイスに対する階層ツリーの階層数を示す。データポインタ６３は、EKB中のデータ部６６の位置を示すポインタであり、タグポインタ６４および署名ポインタ６５は、タグ部６７および署名６８の位置をそれぞれ示すポインタである。

データ部６６には、例えば、更新するノードキーが暗号化されて得られたデータが格納される。例えば、図９に示されるような、更新されたノードキーに関する各暗号化キー等がデータ部６６に格納される。

タグ部６７は、データ部６６に格納された、暗号化されたノードキー、リーフキーの位置関係を示すタグである。このタグの付与ルールを、図１１を参照して説明する。

図１１の例においては、送付されるデータは、図１１Ｂに示されるように、図７の暗号化キーとされている。なお、暗号化キーに含まれるトップノードのアドレスをトップノードアドレスとする。

この例においては、ルートキーの更新キーＫ(ｔ)Ｒが含まれているため、トップノードアドレスはＫＲとなる。このとき、例えば、最上段のデータEnc（Ｋ(ｔ)０，Ｋ(ｔ)Ｒ）は、図１１Ａに示す階層ツリーに示す位置Ｐ０に対応する。次の段のデータは、Enc（Ｋ(ｔ)00，Ｋ(ｔ)０）であり、ツリー上では前のデータEnc（Ｋ(ｔ)０，Ｋ(ｔ)Ｒ）の左下の位置Ｐ00に対応する。

すなわち、ツリー構造の所定の位置から見て、その下にデータがある場合には、タグが０に設定され、データがない場合には、タグが１に設定される。タグは｛左（Ｌ）タグ，右（Ｒ）タグ｝として設定される。

図１１Ｂの最上段のデータEnc（Ｋ(ｔ)０，Ｋ(ｔ)Ｒ）に対応する位置Ｐ０の左下の位置Ｐ00にはデータがあるため、Ｌタグ＝０となり、位置Ｐ０の右下にはデータがないため、Ｒタグ＝１となる。以下、すべてのデータにタグが設定され、図１１Ｃに示すデータ列、およびタグ列が構成される。

タグは、対応するデータEnc（Ｋxxx，Ｋyyy）が、ツリー構造のどこに位置しているのかを示すために設定される。データ部６６に格納されるキーデータEnc（Ｋxxx，Ｋyyy）・・・は、単純に暗号化されたキーの羅列データに過ぎないが、上述したタグによって、データとして格納された暗号化キーのツリー上の位置が判別可能となる。タグを用いずに、図７または図８に示されるように、暗号化データに対応させたノード・インデックスを用いて、例えば、
０：Enc（Ｋ(ｔ)０，Ｋ(ｔ)Ｒ）
00：Enc（Ｋ(ｔ)00，Ｋ(ｔ)０）
000：Enc（Ｋ（(ｔ)000，Ｋ(ｔ)00）
・・・
のようなデータ構成とすることも可能であるが、このようなインデックスを用いた構成とした場合、そのデータ量が増大し、ネットワークを介する配信等においては好ましくない。これに対し、以上のようなタグを、キーの位置を示す索引データとして用いることにより、より少ないデータ量で、キーの位置の判別が可能となる。

図１０の説明に戻り、署名（Signature）６８は、EKBを発行した、例えば、鍵管理センタ（ライセンスサーバ４）、コンテンツロバイダ（コンテンツサーバ３）、決済機関（課金サーバ５）等が実行する電子署名である。EKBを受領したデバイスは、EKBに含まれる署名を検証することにより、取得したEKBが、正当な発行者が発行したEKBであるか否かを判定する。

図１２は、以上のような鍵管理システムにおいて、コンテンツを復号するためのコンテンツ鍵Ｋｃがクライアント１により取得されるまでの処理を模式的に示す図である。

図１２の左端に示されるDNKは、登録時に生成されるサービスデータに含まれて、ライセンスサーバ４からクライアント１に提供される。また、後述するように、サービスデータには、クライアント１に固有の個別鍵Ｋpriが含まれており、その鍵情報も提供される（図１２の右端）。

クライアント１は、あるコンテンツと、そのコンテンツを利用するための条件等が記述された利用権を取得し、ユーザの指示に応じてコンテンツを利用するとき、始めに、サービスデータにより取得されたDNKを用いて、コンテンツのEKBに含まれるEKBキーＫekbを取得する。また、クライアント１は、サービスデータにより取得された個別鍵Ｋpriを用いて、EKBキーＫekbに対応する、利用権に含まれるサブキーＫsubを取得する。なお、図１２において、EKB（Ｋekb）は、EKBキーＫekbが、EKBに含まれるルートキーＫrootにより暗号化されていることを表している。

クライアント１は、EKBキーＫekbとサブキーＫsubを取得したとき、それらの鍵情報に基づいて、コンテンツを復号するためのコンテンツキーＫｃを排他的論理和演算により生成し、生成したコンテンツキーＫｃを利用して、コンテンツ（コンテンツデータ）を復号する。

このように、EKBに含まれるEKBキーＫekbと、利用権に含まれるサブキーＫsubに基づいて生成されたコンテンツキーＫｃにより、コンテンツを利用できるようにすることにより（鍵情報を分割してクライアント１に提供することにより）、仮に、EKBの内容が読み取られた場合であっても、そこに記述されている鍵情報のみではコンテンツを利用できないこととなる。すなわち、コンテンツを利用するためには、EKB（コンテンツ）、コンテンツを利用するための利用権、およびサービスデータが必要となる。

以下、分割されて提供された鍵情報に基づいてコンテンツを利用するまでの、クライアント１、コンテンツサーバ３、およびライセンスサーバ４の処理について、フローチャートを参照して説明する。

始めに、図１３のフローチャートを参照して、サービスデータを取得するクライアント１の処理について説明する。

入力部２６が操作され、ライセンスサーバ４に対するアクセスがユーザにより指示されたとき、クライアント１のCPU２１は、ステップＳ１において、通信部２９を制御し、インターネット２を介して、ライセンスサーバ４にアクセスする。ステップＳ２において、入力部２６が操作され、提供を受けるサービスがユーザにより指定されたとき、CPU２１は、この指定情報を受け取り、ライセンスサーバ４に対して、指定されたサービスを利用するためのサービスデータを要求する。

図１５のフローチャートを参照して後述するように、この通知を受けたライセンスサーバ４は、サービスデータを送信してくるため、CPU２１は、ステップＳ３において、ライセンスサーバ４から送信されてきたサービスデータを受信し、ステップＳ４に進み、ハードディスクなどにより構成される記憶部２８にサービスデータを記憶させる。

図１４は、クライアント１に提供されるサービスデータの例を示す図である。

図１４に示されるように、サービスデータには、クライアント１を識別するリーフID、EKBに記述されている鍵情報を復号するためのDNK、クライアント１に対して個別に与えられる個別鍵Ｋpri、個別鍵Ｋpriに対応する公開鍵Ｋpubが含まれている。また、サービスデータには、ライセンスサーバ４が有する個別鍵に対応する、ライセンスサーバ４の公開鍵、およびサービスデータの証明書が含まれている。

次に、図１５のフローチャートを参照して、図１３に示される処理に対応して実行される、ライセンスサーバ４のサービスデータ提供処理について説明する。

ステップＳ１１において、ライセンスサーバ４のCPU２１は、クライアント１からアクセスを受けたか否かを判定し、アクセスを受けたと判定するまで待機する。ライセンスサーバ４のCPU２１は、ステップＳ１１において、クライアント１からアクセスを受けたと判定した場合、ステップＳ１２に進み、クライアント１から要求されたサービスを利用するための、図１４に示されるような各種の情報が記述されたサービスデータを生成する。

ステップＳ１３において、ライセンスサーバ４のCPU２１は、通信部２９を制御し、ステップＳ１２で生成したサービスデータを、サービスのデフォルトの使用条件を表す情報とともにクライアント１に送信する。

以上のような処理によって、クライアント１により、サービスデータが取得される。なお、以上のような処理によりサービスデータがクライアント１に提供されるのはなく、クライアント１に予め格納された状態（クライアント１の製造の段階で埋め込まれた状態）で、そのクライアント１のユーザに提供されるようにしてもよい。

次に、図１６のフローチャートを参照して、クライアント１に提供するコンテンツを生成するコンテンツサーバ３の処理について説明する。なお、コンテンツサーバ３から提供されるコンテンツに含まれる音楽データや映像データなどのそのものであるコンテンツデータは、図示せぬコンテンツホルダにより提供されたものである。

ステップＳ２１において、コンテンツサーバ３のCPU２１は、クライアント１に提供するコンテンツ（コンテンツデータ）を暗号化するコンテンツキーＫｃを生成する。また、CPU２１は、ステップＳ２２において、クライアント１においてコンテンツキーＫｃを生成するために必要なサブキーＫsubを生成する。上述したように、このサブキーＫsubは、利用権に含まれる形で、ライセンスサーバ４からクライアント１に提供される。

CPU２１は、ステップＳ２３において、サブキーＫsubとEKBキーＫekbに基づいて、クライアント１がコンテンツキーＫｃを生成できるように、そのEKBキーＫekbを生成する。具体的には、CPU２１は、ステップＳ２１で生成したコンテンツキーＫｃと、ステップＳ２２で生成したサブキーＫsubの排他的論理和演算（Exclusive OR）を行い、その演算結果をEKBキーＫekbとする。

ステップＳ２４において、CPU２１は、ステップＳ２３で生成したEKBキーＫekbを、EKBに含まれるルートキーＫrootで暗号化し、Ｅ（Ｋroot，Ｋekb）を取得する。また、CPU２１は、ステップＳ２５において、ステップＳ２１で生成したコンテンツキーＫｃを用いて、クライアント１に提供するコンテンツ（Content）に暗号化を施し、Ｅ（Ｋｃ，Cont）を取得する。

CPU２１は、ステップＳ２６において、ステップＳ２４で取得したＥ（Ｋroot，Ｋekb）、およびステップＳ２５で取得したＥ（Ｋｃ，Cont）を含むフォーマットのコンテンツを生成し、それを記憶部２８に保存する。

図１７は、コンテンツサーバ３により生成されるコンテンツのフォーマットの例を示す図である。

図１７に示されるように、基本的に、コンテンツはヘッダ（Header）とデータ（Data）（コンテンツデータ）により構成される。

ヘッダには、コンテンツ情報（Content information）、URL（Uniform Resource Locator）、ライセンスID(License ID)、クライアント１に提供されたDNKにより暗号化されたＫrootを含むEKB、EKBから取得されたキーＫrootによりEKBキーＫekbが暗号化されて得られたＥ（Ｋroot，Ｋekb）、コンテンツの属性を表す属性情報（Attribute）、およびヘッダの署名（Signatures）が記述されている。

コンテンツ情報には、データとして格納されているコンテンツを識別するためのコンテンツID（CID）、および、コンテンツのコーデックの方式を表す情報などが含まれている。

URLは、そのコンテンツを利用するために必要な利用権を取得するときアクセスする、ライセンスサーバ４のアドレスを表している。コンテンツの属性には、コンテンツID、コンテンツの提供者を識別するための識別情報としてのレコードカンパニーID、アーティストを識別するための識別情報としてのアーティストID、および、ユニークIDなどが含まれる。本実施例では、属性は利用権の対象となるコンテンツを特定するために用いられる。

データは、任意の数の暗号化ブロック（Encryption Block）により構成される。各暗号化ブロックは、イニシャルベクトル（IV（Initial Vector））、シード（Seed）、およびコンテンツをキーＫ'ｃで暗号化したデータEK'c(data)により構成されている。

キーＫ'ｃは、次式により示されるように、コンテンツキーＫｃと、乱数で設定される値Seedをハッシュ関数に適用して演算された値により構成される。

Ｋ'ｃ＝Hash(Ｋｃ，Seed)

イニシャルベクトルIVとシードSeedは、暗号化ブロック毎に、異なる値が設定される。

例えば、コンテンツの暗号化は、コンテンツのデータを８バイト単位で区分して、その区分毎に行われる。後段の８バイトの暗号化は、前段の８バイトの暗号化の結果を利用して行われるCBC（Cipher Block Chaining）モードで行われる。

CBCモードの場合、最初の８バイトのコンテンツを暗号化するとき、その前段の８バイトの暗号化結果が存在しないため、最初の８バイトのコンテンツを暗号化するときは、イニシャルベクトルIVを初期値として暗号化が行われる。

CBCモードによる暗号化を行うことにより、１つの暗号化ブロックが解読されたとしても、その影響が、他の暗号化ブロックに及ぶことが抑制される。なお、コンテンツが、他の暗号化方式により暗号化されるようにしてもよい。

以上のようなフォーマットでコンテンツを構成することにより、コンテンツを取得したクライアント１は、サービスデータにより予め与えられているDNKを用いてルートキーＫrootを復号し、取得したルートキーＫrootにより、EKBキーＫekbを復号することができる。また、クライアント１は、EKBキーＫekbと、利用権に含まれているサブキーＫsubに基づいてコンテンツキーＫｃを生成し、それを用いてコンテンツを復号することができる。

図１６の説明に戻り、ステップＳ２７において、コンテンツサーバ３のCPU２１は、ステップＳ２２で生成したサブキーＫsubを、インターネット２を介して、または、所定の記録媒体を介して、ライセンスサーバ４に提供する。

コンテンツサーバ３によるサブキーＫsubの提供に応じて、ライセンスサーバ４においては、図１８のフローチャートに示される処理が行われる。

ステップＳ４１において、ライセンスサーバ４のCPU２１は、コンテンツサーバ３からサブキーＫsubが取得されてきたか否かを判定する。CPU２１は、サブキーＫsubが取得されてきたと判定するまで待機し、例えば、インターネット２を介してサブキーＫsubを表す情報が送信されてきたと判定した場合、ステップＳ４２に進み、それを取得する。取得されたサブキーＫsubは、記憶部２８に記憶され、クライアント１から利用権が要求されたとき、その利用権に含まれてクライアント１に提供される。

次に、図１９のフローチャートを参照して、コンテンツサーバ３からコンテンツの提供を受けるクライアント１の処理について説明する。

クライアント１のCPU２１は、ユーザからコンテンツサーバ３にアクセスすることが指示されたとき、ステップＳ５１において、コンテンツサーバ３にアクセスする。ステップＳ５２において、ユーザが、入力部２６を操作して、提供を受けるコンテンツを指定すると、CPU２１は、この指定情報を受け取り、コンテンツサーバ３に、指定されたコンテンツのコンテンツIDを通知する。

図２０のフローチャートを参照して後述するように、この通知を受けたコンテンツサーバ３は、コンテンツを送信してくるため、ステップＳ５３において、CPU２１は、送信されてきたコンテンツを受信し、ステップＳ５４において、そのコンテンツを記憶部２８に記憶させる。

次に、図２０のフローチャートを参照して、クライアント１による図１９の処理に対応して実行される、コンテンツサーバ３のコンテンツ提供処理について説明する。

ステップＳ６１において、コンテンツサーバ３のCPU２１は、クライアント１からアクセスを受けるまで待機し、アクセスを受けたと判定したとき、ステップＳ６２に進み、クライアント１から送信されてきたコンテンツIDを取り込む。このコンテンツIDは、クライアント１が、図１９のステップＳ５２において通知してきた情報である。

ステップＳ６３において、コンテンツサーバ３のCPU２１は、記憶部２８に記憶されているコンテンツデータの中から、ステップＳ６２の処理で取り込まれたコンテンツIDで指定されたコンテンツデータを読み出す。ステップＳ６４において、CPU２１は、通信部２９を制御し、読み出したコンテンツデータを含むコンテンツを、コンテンツを要求してきたクライアント１に送信する。

次に、図２１のフローチャートを参照して、コンテンツを再生するクライアント１の処理について説明する。

ステップＳ７１において、クライアント１のCPU２１は、ユーザが入力部２６を操作することで指示したコンテンツの識別情報（CID）を取得する。CIDは、例えば、コンテンツのタイトルや、記憶されている各コンテンツに付与されている番号などにより構成される。CPU２１は、コンテンツが指示されると、そのコンテンツの属性（Attributes）を読み取る。この属性は、図１７に示されるように、コンテンツのヘッダに記述されているものである。

ステップＳ７２において、CPU２１は、ステップＳ７１で読み取られた属性が各利用権に含まれているコンテンツ条件を満たすような利用権が、クライアント１により既に取得され、記憶部２８に記憶されているか否かを判定する。まだ、利用権が取得されていない場合には、ステップＳ７３に進み、CPU２１は、利用権取得処理を実行する。この利用権取得処理の詳細は、図２２のフローチャートを参照して後述する。

ステップＳ７２において、利用権が既に取得されていると判定された場合、または、ステップＳ７３において、利用権取得処理が実行され、利用権が取得された場合、ステップＳ７４に進み、CPU２１は、取得されている利用権が有効期限内のものであるか否かを判定する。利用権が有効期限内のものであるか否かは、利用権の記述内容としての有効期限（図２４参照）と、タイマ２０により計時されている現在日時が比較されて判断される。

利用権の有効期限が既に満了していると判定された場合、CPU２１は、ステップＳ７５に進み、利用権更新処理を実行する。ステップＳ７５で実行される利用権更新処理は、基本的には、ステップＳ７３で実行される利用権取得処理と同様の処理である。

ステップＳ７４において、利用権が有効期限内のものであると判定された場合、または、ステップＳ７５において、利用権が更新された場合、ステップＳ７６に進み、CPU２１は、記憶部２８に記憶されている、利用権に含まれる使用条件及び使用状態を読み出し、再生の条件を満たしているかどうかを判定する。

ステップＳ７６において、利用権に含まれる使用条件、及び使用状態に基づき、再生が許可されると判定された場合には、ステップＳ７７に進み、CPU２１は、コンテンツを記憶部２８から読み出し、RAM２３に格納させる。そして、ステップＳ７８において、CPU２１は、RAM２３に記憶されたコンテンツを復号する処理を実行する。ステップＳ７８において行われるコンテンツ復号処理については、図２５のフローチャートを参照して後述する。

CPU２１は、ステップＳ７９において、暗号化復号部２４により復号されたコンテンツをコーデック部２５に供給し、デコードさせる。そして、CPU２１は、コーデック部２５によりデコードされたデータを入出力インタフェース３２を介して出力部２７に供給し、ディジタルアナログ変換させ、スピーカから出力させる。

次に、図２２のフローチャートを参照して、図２１のステップＳ７３で行われる利用権取得処理の詳細について説明する。

ステップＳ８１において、クライアント１のCPU２１は、コンテンツのヘッダに記述されているURLを取得する。上述したように、このURLは、そのコンテンツを利用するために必要な利用権を取得するときアクセスするライセンスサーバ４のアドレスを表している。ステップＳ８２において、CPU２１は、通信部２９を制御し、ステップＳ８１で取得したURL、すなわちライセンスサーバ４にアクセスする。

このアクセスに応じて、ライセンスサーバ４は、クライアント１に対して、購入する利用権（コンテンツを使用するのに必要な利用権）を指定する利用権指定情報、ユーザID、およびパスワードの入力を要求してくる（後述する図２３のステップＳ１０２）。CPU２１は、この要求を出力部２７の表示部に表示させる。ユーザは、この表示に基づいて、入力部２６を操作し、利用権指定情報、ユーザID、およびパスワードを入力する。なお、このユーザIDとパスワードは、クライアント１のユーザが、インターネット２を介してライセンスサーバ４にアクセスし、予め取得しておいたものである。

CPU２１は、ステップＳ８３において、入力部２６から入力された利用権指定情報を取り込み、ステップＳ８４において、ユーザID、パスワードを取り込む。CPU２１は、ステップＳ８５において、通信部２９を制御し、入力されたユーザIDとパスワード、利用権指定情報、およびサービスデータに含まれるリーフIDを含む利用権要求をライセンスサーバ４に送信させる。

ライセンスサーバ４は、図２３を参照して後述するように、ユーザIDとパスワード、並びに利用権指定情報に基づいて生成した利用権を送信してくる（ステップＳ１１１）か、または、条件が満たされない場合には、利用権を送信してこない（ステップＳ１１４）。

ステップＳ８６において、CPU２１は、ライセンスサーバ４から利用権が送信されてきたか否かを判定し、利用権が送信されてきたと判定した場合、ステップＳ８７に進み、受信した利用権を記憶部２８に記憶させる。

ステップＳ８６において、利用権が送信されてこないと判定した場合、CPU２１は、ステップＳ８８に進み、コンテンツの再生処理を禁止するなどのエラー処理を実行する。

なお、図２２に示される利用権取得処理は、各ユーザが、コンテンツを取得する前に予め行っておくようにすることも可能である。

次に、図２３のフローチャートを参照して、図２２のクライアント１の利用権取得処理に対応して実行される、ライセンスサーバ４の利用権提供処理について説明する。

ステップＳ１０１において、ライセンスサーバ４のCPU２１は、クライアント１よりアクセスを受けるまで待機し、アクセスを受けたとき、ステップＳ１０２に進み、アクセスしてきたクライアント１に対して、各利用権に関する情報を含む利用権のリストを送信するとともに、ユーザIDとパスワード、並びに、利用権指定情報の送信を要求する。クライアント１から、ユーザIDとパスワード、リーフID並びに利用権指定情報（利用権IDであってもよい）が送信されてきたとき（図２２のステップＳ８５の処理）、ライセンスサーバ４のCPU２１は、通信部２９を介してこれを取り込む。

ライセンスサーバ４のCPU２１は、ステップＳ１０３において、通信部２９から課金サーバ５にアクセスし、ユーザIDとパスワードに対応するユーザの与信処理を要求する。課金サーバ５は、インターネット２を介してライセンスサーバ４から与信処理の要求を受けると、そのユーザIDとパスワードに対応するユーザの過去の支払い履歴などを調査し、そのユーザが、過去に利用権の対価の不払いの実績があるか否かなどを調べ、そのような実績がない場合には、利用権の付与を許容する与信結果を送信し、不払いの実績などがある場合には、利用権付与の不許可の与信結果を送信する。なお、クライアント１のユーザは、課金サーバ５に対して、自分自身のユーザID、パスワード、課金先の情報などを予め登録している。

ステップＳ１０４において、ライセンスサーバ４のCPU２１は、課金サーバ５からの与信結果が、利用権を付与することを許容するものであるか否かを判定し、利用権の付与が許容されている場合には、ステップＳ１０５に進み、ステップＳ１０２の処理で取り込まれた利用権指定情報に対応する利用権を、記憶部２８に記憶されている利用権の中から取り出す。記憶部２８に記憶されている利用権には、利用権ID、バージョン、作成日時、有効期限等の情報が記述されている。

ステップＳ１０６において、CPU２１は、その利用権に、クライアント１から通知されてきたリーフIDを付加する。また、ステップＳ１０７において、CPU２１は、ステップＳ１０５で選択された利用権に対応づけられている使用条件を選択する。なお、ステップＳ１０２の処理で、ユーザから使用条件が指定された場合には、その使用条件が、予め用意されている使用条件に付加される。CPU２１は、選択した使用条件を利用権に付加する。使用条件は利用権に予め付加されていてもよい。

ステップＳ１０８において、CPU２１は、ライセンスサーバ４の個別鍵により利用権に署名する。

CPU２１は、ステップＳ１０９において、コンテンツサーバ３から通知されてきたサブキーＫsubを、クライアント１の個別鍵Ｋpri（図１４）に対応するライセンスサーバ４の公開鍵Ｋpubを用いて暗号化し、Ｅ（Ｋpub，Ｋsub）を取得する。CPU２１は、ステップＳ１１０において、ステップＳ１０９で取得したＥ（Ｋpub，Ｋsub）を、ステップＳ１０５で選択した利用権に付加する。

図２４は、以上のような処理により生成される利用権の例を示す図である。

バージョンは、メジャーバージョンおよびマイナーバージョンをドットで区切って、利用権のバージョンを記述する情報である。プロファィルは、１０進の整数値から記述され、利用権の記述方法に対する制限を規定する情報である。利用権IDは、１６進定数で記述される、利用権を識別するための識別情報である。作成日時は、利用権が作成された日時を示す。有効期限は、利用権の有効期限を示す。９９９９年２３時５９分５９秒である有効期限は、有効期限に制限がないことを示す。使用条件には、その利用権に基づいて、コンテンツを使用することが可能な使用期限、その利用権に基づいて、コンテンツを再生することが可能な再生期限、コンテンツの最大再生回数、その利用権に基づいて、コンテンツをコピーすることが可能な回数（許されるコピー回数）、最大チェックアウト回数、その利用権に基づいて、コンテンツをCD-Rに記録することができるか否か、PD(Portable Device)にコピーすることが可能な回数、利用権の移動の可否、使用ログをとる義務の有無等を示す情報が含まれる。使用条件の電子署名は、使用条件に対応する電子署名である。

定数は、使用条件または使用状態で参照される定数である。リーフIDは、クライアントを識別するための識別情報である。電子署名は、利用権全体に対応する、電子署名である。証明書は、ライセンスサーバ４の公開鍵を含む証明書である。

また、クライアント１の記憶部２８には、利用権の使用条件とあわせて、コンテンツや利用権の状態を表す情報である使用状態（コンテンツ条件）が記憶される。使用状態には、対応する利用権に基づいてコンテンツを再生した回数、コンテンツをコピーした回数、コンテンツをチェックアウトした回数、コンテンツを初めて再生した日時、コンテンツをCD-Rに記録した回数、その他コンテンツあるいは利用権に関する履歴情報等を示す情報が含まれる。コンテンツの再生の条件の判定は、利用権に含まれる使用条件と、記憶部２８に利用権と共に記憶されている使用状態とを基に行われる。例えば、使用状態に記憶されているコンテンツを再生した回数が、使用条件に含まれるコンテンツ最大再生回数より少ない場合には、再生の条件が満たされていると判定される。

なお、利用権には、ステップＳ１０９の処理により生成されたＥ（Ｋpub，Ｋsub）が含まれている。

図２３の説明に戻り、ステップＳ１１１において、CPU２１は、以上のようにして生成した利用権を、通信部２９からクライアント１に送信させる。

ステップＳ１１２において、ライセンスサーバ４のCPU２１は、ステップＳ１１１で送信した利用権の内容を、ステップＳ１０２の処理で取り込んだユーザIDとパスワードに対応させて、記憶部２８に記憶させる。また、ステップＳ１１３において、CPU２１は、課金処理を実行する。

具体的には、CPU２１は、通信部２９から課金サーバ５に、ユーザIDとパスワードに対応するユーザに対する課金処理を要求する。課金サーバ５は、この課金の要求に基づいて、そのユーザに対する課金処理を実行する。上述したように、この課金処理に対して、ユーザが支払いを行わなかったような場合には、以後、そのユーザは、利用権の付与を要求したとしても、利用権を受けることができないことになる。

すなわち、この場合には、課金サーバ５から利用権の付与を不許可とする与信結果が送信されてくるので、ステップＳ１０４からステップＳ１１４に進み、CPU２１は、クライアント１に対して、利用権を付与することができない旨のメッセージを出力するなどのエラー処理を実行する。

次に、図２５のフローチャートを参照して、図２１のステップＳ７８において行われる、コンテンツを再生するクライアント１の処理の詳細について説明する。

ステップＳ１２１において、クライアント１のCPU２１は、サービスデータにより予め提供されているDNKにより、コンテンツのEKB（図１７）に含まれる鍵情報を復号し、ルートキーＫrootを取得する。

ステップＳ１２２において、CPU２１は、ステップＳ１２１で取得したルートキーＫrootを用いてＥ（Ｋroot，Ｋekb）を復号し、EKBキーＫekbを取得する。

CPU２１は、ステップＳ１２３において、利用権に含まれているＥ（Ｋpub，Ｋsub）を、ライセンスサーバ４の公開鍵Ｋpubに対応する個別鍵Ｋpri（サービスデータにより予め取得されている個別鍵）を用いて復号し、サブキーＫsubを取得する。

CPU２１は、ステップＳ１２４において、ステップＳ１２２で取得したEKBキーＫekbと、ステップＳ１２３で取得したサブキーＫsubに基づいて、コンテンツキーＫｃを生成する。具体的には、CPU２１は、EKBキーＫekbとサブキーＫsubの排他的論理和演算を行い、その演算結果をコンテンツキーＫｃとして取得する。

ステップＳ１２５において、CPU２１は、ステップＳ１２４で取得したコンテンツキーＫｃを利用して、Ｅ（Ｋｃ，Cont）を復号し、コンテンツを取得する。その後、取得されたコンテンツは、図２１のステップＳ７９において、CPU２１の制御により再生され、出力部２７から出力される。

図２６は、以上のようにしてクライアント１により行われるコンテンツの再生処理を模式的に表す図である。図２６において、Ｓ１２１乃至Ｓ１２５は、図２５のステップＳ１２１乃至Ｓ１２５のそれぞれの処理に対応する。また、図２６において、コンテンツは、主な情報のみが示されている。

図２６に示されるように、クライアント１においては、コンテンツサーバ３から取得されたコンテンツに配置されているEKBが、クライアント１に対して予め与えられているDNKにより処理され、ルートキーＫrootが取得される（ステップＳ１２１）。

また、EKBの右隣に配置されているＥ（Ｋroot，Ｋekb）が、ルートキーＫrootにより復号され、EKBキーＫekbが取得される（ステップＳ１２２）。

一方、ライセンスサーバ４から提供された利用権に含まれるＥ（Ｋpub，Ｋsub）が、サービスデータによりクライアントに予め与えられている個別鍵Ｋpriにより復号され、サブキーＫsubが取得される（ステップＳ１２３）。

そして、サブキーＫsubとEKBキーＫekbに基づく排他的論理和演算が行われ、その出力としてのコンテンツキーＫｃが生成され（ステップＳ１２４）、生成されたコンテンツキーＫｃにより、コンテンツの右端に配置されているＥ（Ｋｃ，Cont）が復号され、コンテンツ（Content）が取得される（ステップＳ１２５）。

以上のように、DNKに基づいてEKBからルートキーＫrootを取得するオフラインの認証、および、公開鍵Ｋpubにより暗号化されたサブキーＫsubを個別鍵Ｋpriにより復号するオフラインの認証を組み合わせることにより、第１に、EKBの内容が不正に読み取られた場合であっても、コンテンツの利用には個別鍵Ｋpriが必要となるため、不正なコンテンツの利用を防止することができる。

また、第２に、所定の期間、クライアント１のユーザがライセンスサーバ４にアクセスしない場合であっても、EKBの情報を変更し、サービスに属する他のクライアントに配布することにより、不正な行為を行うクライアント１の無効化（ルートキーＫrootを取得できなくすること）が可能となる。

さらに、第３に、コンテンツが音楽コンテンツである場合に、試聴用のコンテンツをDNKのみで暗号化し、購入用のコンテンツを、EKBキーＫekbとサブキーＫsubにより取得されるコンテンツキーＫｃにより暗号化することにより、コンテンツのみをダウンロードして試聴用コンテンツを利用し、購入用のコンテンツを実際に購入するときにのみ、ユーザにより利用権を取得させるなどのように、サービスに幅を持たせることができる。

また、上記実施例では、コンテンツを利用するために必要な利用権を特定するためにコンテンツの属性と利用権のコンテンツ条件を用いたが、これに限らない。例えば、コンテンツに、該コンテンツを利用するために必要な利用権の利用権IDを含むようにしても良く、この場合、コンテンツを指定すればそれを利用するために必要な利用権は一意に決まるため、両者のマッチングを決定する処理を行う必要はない。

従来のコンテンツの復号処理を示す模式図である。 本発明を適用したコンテンツ提供システムの構成例を示す図である。 図２のクライアントの構成例を示すブロック図である。 キーの構成を示す図である。 カテゴリノードを示す図である。 ノードとデバイスの対応例を示す図である。 有効化キーブロックの構成例を示す図である。 有効化キーブロックの他の構成例を示す図である。 有効化キーブロックの利用の模式図である。 有効化キーブロックのフォーマットの例を示す図である。 有効化キーブロックのタグの構成を説明する図である。 本発明を適用した鍵情報の分割の模式図である。 図２のクライアントのサービスデータ取得処理を説明するフローチャートである。 サービスデータの例を示す図である。 図２のライセンスサーバのサービスデータ提供処理を説明するフローチャートである。 図２のコンテンツサーバのコンテンツ生成処理を説明するフローチャートである。 コンテンツのフォーマットの例を示す図である。 図２のライセンスサーバのサブキー取得処理を説明するフローチャートである。 図２のクライアントのダウンロード処理を説明するフローチャートである。 図２のコンテンツサーバのコンテンツ提供処理を説明するフローチャートである。 図２のクライアントの再生処理を説明するフローチャートである。 図２１のステップＳ７３における利用権取得処理の詳細を説明するフローチャートである。 図２のライセンスサーバの利用権提供処理を説明するフローチャートである。 利用権の例を示す図である。 図２１のステップＳ７７における復号処理の詳細を説明するフローチャートである。 図２５の処理を模式的に表す図である。

符号の説明

１−１，１−２ クライアント， ２ インターネット， ３ コンテンツサーバ， ４ ライセンスサーバ， ５ 課金サーバ， ２０ タイマ， ２１ CPU， ２４ 暗号化復号部， ２５ コーデック部， ２６ 入力部， ２７ 出力部， ２８ 記憶部， ２９ 通信部

Claims (1)

1. コンテンツを提供するコンテンツサーバと、前記コンテンツを利用するのに必要な利用権を提供するライセンスサーバと、前記コンテンツサーバと前記ライセンスサーバとの間でネットワークを介して情報を送受信する情報処理装置とからなるコンテンツ提供システムにおいて、
   前記情報処理装置は、
   前記ライセンスサーバに対して、前記情報処理装置に対応するデバイスノードキーと前記情報処理装置に固有の個別鍵とを含むサービスデータの送信を要求する要求手段と、
   前記要求手段による要求に応じて前記ライセンスサーバから送信された前記サービスデータを受信する受信手段と、
   前記受信手段により受信された前記サービスデータを記憶する記憶手段と、
   前記コンテンツサーバから、暗号化されたコンテンツデータと暗号化された第１の鍵を受信し、前記ライセンスサーバから、コンテンツの利用が指示されることに応じて取得される、前記コンテンツに対応する暗号化された第２の鍵を含む利用権を受信する受信手段と、
   前記記憶手段に記憶されている前記サービスデータに含まれる前記デバイスノードキーを用いて、前記暗号化された第１の鍵を復号して抽出し、前記個別鍵を用いて、前記受信された利用権から、前記暗号化された第２の鍵を復号して抽出し、抽出した前記第１の鍵と前記第２の鍵とで所定の演算を行うことで前記暗号化されたコンテンツデータの復号鍵を生成する演算手段と、
   前記復号鍵を用いて前記暗号化されたコンテンツデータを復号する復号手段と、
   前記復号手段により復号されたコンテンツデータを再生する再生手段と
   を備え、
   前記コンテンツサーバは、
   前記復号鍵と、前記利用権に含めて前記サービスサーバから前記情報処理装置に送信される前記第２の鍵と、前記第２の鍵とで前記所定の演算を行うことで前記復号鍵を生成することに用いられる前記第１の鍵とを生成する生成手段と、
   前記生成手段により生成された前記第１の鍵を、前記デバイスノードキーによって復号可能な形で暗号化し、前記コンテンツデータを、前記復号鍵を用いて暗号化する暗号化手段と、
   前記暗号化手段により暗号化された前記第１の鍵と前記コンテンツデータとを前記情報処理装置に送信し、前記第２の鍵を前記ライセンスサーバに送信する送信手段と
   を備え、
   前記ライセンスサーバは、
   前記コンテンツサーバから送信された前記第２の鍵を受信する受信手段と、
   前記受信手段により受信された前記第２の鍵を、前記情報処理装置の前記個別鍵に対応する公開鍵を用いて暗号化する暗号化手段と、
   前記デバイスノードキーと前記情報処理装置の前記個別鍵とを含む前記サービスデータを前記情報処理装置に送信し、前記暗号化手段により暗号化された前記第２の鍵を含む前記利用権を前記情報処理装置に送信する送信手段と
   を備えるコンテンツ提供システム。

Images