以下、図面を参照して本発明によるコンテンツ送信装置、コンテンツ受信装置及びコンテンツ送信方法の実施形態を説明する。
本実施形態はコンテンツ送信装置(以下、送信装置)からコンテンツ受信装置(以下、受信装置)へコンテンツをムーブ、あるいはレンダリング・コピーするコンテンツ送受信システムに関する。ムーブとは、コンテンツの送信後、送信側でコンテンツを無効化(削除)するものであるが、レンダリング・コピーは無効化しない。コピーとは、システム内で同一のコンテンツが複数存在するものである。レンダリングとは、送信装置が蓄積しているコンテンツを受信装置が表示するものであり、システム内で同一のコンテンツは複数存在しない。以下では説明の便宜上、単にレンダリングと称する場合は、コピーとレンダリングの両方を含む。
送信装置はコンテンツを蓄積しているので、送信装置はソース、受信装置はシンクとも呼ばれる。第1実施形態は受信装置から送信装置側にコンテンツのムーブ、またはレンダリングを要求する例であり、ユーザは受信装置側にいるので、受信装置はクライアントとも呼ばれ、送信装置はサーバとも呼ばれる。第2実施形態は送信装置から受信装置側にコンテンツのムーブ、あるいはレンダリングを要求する例であり、ユーザは送信装置側にいるので、送信装置はクライアント、受信装置はサーバとも呼ばれる。
第1の実施形態
図1は第1実施形態に係る送信装置100の概略構成を示すブロック図である。図1に示すように、送信装置100はコンテンツ供給部12と、認証・鍵交換処理部14と、コンテンツリスト管理部16と、鍵選択処理部18と、暗号処理部20と、ネットワークインターフェース処理部22と、コンテンツ伝送用コネクション管理部24と、コンテンツ管理用コネクション管理部26と、認証・鍵交換用コネクション管理部28を有する。
コンテンツ供給部12は、コンテンツやコンテンツのリストを蓄積する。
認証・鍵交換処理部14は、受信装置との間で認証・鍵交換処理を行う。本実施形態では、図2に示すように、1つの送信装置X(またはY)に対して複数の受信装置A、B、C(またはD、E)の存在を許容している。認証・鍵交換処理部14は、受信装置との間で認証・鍵交換処理が成功すると、各受信装置に対して送信するコンテンツを暗号化する秘密鍵を生成する。本実施形態では、レンダリングとムーブとで別々の秘密鍵を用いてコンテンツを暗号化する。以下、レンダリング用コンテンツの暗号化に用いる秘密鍵を共通鍵Kx、ムーブ用コンテンツの暗号化に用いる秘密鍵をムーブ鍵Kxmと称する。
認証・鍵交換処理部14が生成した共通鍵Kx、ムーブ鍵Kxmは鍵交換により送信装置と受信装置とで共有された鍵により暗号化して受信装置に送信される。共通鍵Kx、ムーブ鍵Kxmはそれぞれ共通鍵ラベル、ムーブ鍵ラベルをつけて認証・鍵交換処理部14に格納される。後述するように、複数の鍵(共通鍵、ムーブ鍵)の存在が許容されているので、共通鍵ラベル及びムーブ鍵ラベルは、それぞれの鍵を区別するための識別情報である。
送信装置は認証・鍵交換処理が成功した全ての受信装置に対して同一の共通鍵Kxを共有する。すなわち、共通鍵Kxは送信装置毎に1つだけである。送信装置から同一のコンテンツを複数の受信装置に同時に配信するマルチキャスト、またはブロードキャストのモデルでは、通信効率の観点からはコンテンツは同一の鍵により暗号化する方が好ましい。従って、送信装置は複数の受信装置に対して同一の共通鍵Kxを送信する。
一方、送信装置は各受信装置と、共通鍵Kxとは異なるムーブ鍵Kxmを共有する。複数の受信装置に対してムーブを行う場合には、各受信装置に対応して複数のムーブ鍵Kxmを保持していてもよい。
ここで、認証・鍵交換処理とは、送信装置や受信装置があるライセンス機関から正しくライセンスをうけた装置であることを相互に認証し、正当な装置であると確認できた場合に、共通の鍵を生成する処理のことを指す。認証の方法としては、例えばISO/IEC 9798−3やISO/IEC 9798−2のような公知の手法がある。
コンテンツリスト管理部16は、コンテンツ供給部12に蓄積されたコンテンツのリストを管理したり、受信装置からのコンテンツ検索要求に対して蓄積コンテンツのリストを提示したりする。
鍵選択処理部18は、受信装置から受け取ったコンテンツ要求がレンダリング要求かムーブ要求かに応じて、コンテンツを共通鍵Kxで暗号化するか、あるいはムーブ鍵Kxmで暗号化するかを判別するための処理を行い、認証・鍵交換処理部14に格納された受信装置と共有している鍵の中から適切な鍵を選択し、暗号処理部20に供給する。
暗号処理部20は、鍵選択処理部18から供給された鍵を用いてコンテンツを暗号化する。これらのデータを暗号・復号化するための暗号アルゴリズムとしては、例えばAESなどの公知の手法がある。
ネットワークインターフェース処理部22は、受信装置と通信を行うための物理レイヤ処理、データリンクレイヤ処理、ネットワークレイヤ・トランスポートレイヤ処理を実行する。物理レイヤおよびリンクレイヤは、IEEE802.11に準拠した無線LAN、イサーネット(登録商標)、IEEE1394などの種々の形態をとりうる。ネットワークレイヤは、インターネットプロトコル(以下、単にIPと呼ぶ)が使用されている場合には、IPv4でもよいし、IPv6でもよい。
コンテンツ伝送用コネクション管理部24はコンテンツ送信用のコネクションを管理する。コンテンツ管理用コネクション管理部26は、受信装置からの要求に応じてコンテンツリストを提示したり、コンテンツのURLを提示したりするコネクションを管理したりする。受信装置にコンテンツのリストを提示する方法としては、例えばUPnP(Universal Plug and Play)のようなプロトコルが用いられる。またコンテンツの場所を表すための手段としては、例えばURLが用いられる。
認証・鍵交換用コネクション管理部28は認証・鍵交換用のコネクションを管理する。
図3は第1実施形態の受信装置102の概略構成を示すブロック図である。図3に示すように、受信装置102は、コンテンツ処理部32と、認証・鍵交換処理部34と、コンテンツ選択部36と、鍵選択処理部38と、暗号処理部40と、ネットワークインターフェース処理部42と、コンテンツ伝送用コネクション管理部44と、コンテンツ管理用コネクション管理部46と、認証・鍵交換用コネクション管理部48を有する。
ネットワークインターフェース処理部42、コンテンツ伝送用コネクション管理部44と、コンテンツ管理用コネクション管理部46と、認証・鍵交換用コネクション管理部48については、送信装置内の対応するブロックと同様の機能を持ち、同様のブロックで構成することができる。
コンテンツ処理部32は、受信したコンテンツを表示装置等に出力したり、図示しない記憶部に蓄積したりするための処理を行う。
認証・鍵交換処理部34は、送信装置と認証・鍵交換処理を行う。認証・鍵交換処理部34は、認証・鍵交換処理が成功すると、コンテンツを復号化するのに用いる秘密鍵である共通鍵Kx、ムーブ鍵Kxmを送信装置から受信し、それらをラベルをつけて格納する。
コンテンツ選択部36は、送信装置と通信を行い、送信装置のコンテンツ供給部12に蓄積されたコンテンツを検索したり、検索結果のリストとそれぞれのコンテンツのネットワーク上の場所を管理する。送信装置に蓄積されたコンテンツのリストを送信装置またはネットワーク上の機器から取得する手段としては、例えばUPnPといった手段が用いられる。また、コンテンツのネットワーク上の場所を特定する手段としては例えばURLといった手段が用いられる。ムーブ用のコンテンツとレンダリング用のコンテンツはURLで区別されていてもよい。
鍵選択処理部38は、コンテンツ選択部36からのコンテンツ要求がムーブ要求であるかレンダリング要求であるかを判別し、ムーブ要求であれば、ムーブ鍵ラベルを特定して送信装置に対してコンテンツ要求を送信する。一方、レンダリング要求であれば、何もつけずにコンテンツ要求を送信する。すなわち、送信装置からコンテンツを取得する際には、コンテンツ選択部36から対応するコンテンツのURLを取得し、鍵選択処理部18は当該URLに対して例えばHTTPプロトコルでGETリクエストを送信し、送信装置からコンテンツを取得する。
暗号処理部40は共通鍵またはムーブ鍵を使ってコンテンツの復号化を行う。
図4は本実施形態に係るコンテンツ送受信システムの処理手順を示すシーケンス図である。本実施形態では、送信装置100と受信装置102との間に3つの通信コネクションA,B,Cが設けられる。コネクションAはコンテンツ管理に用いられ、コネクションBは認証・鍵交換に用いられ、コネクションCはコンテンツ伝送に用いられる。
先ず、受信装置102はコネクションAを用いて送信装置100に対してコンテンツ検索を要求する(ステップ#2)。このコンテンツ検索に先立ち、ネットワーク上の送信装置のIPアドレスを検索したり、コンテンツ検索を行うメッセージの送信先IPアドレスやポート番号の特定したりする際には、UPnPなどのよく知られた方法が用いられる。
送信装置100はコンテンツ検索の結果としてコンテンツのリストとそのコンテンツのURLを提示する(ステップ#4)。このとき、送信装置100がムーブ用のコンテンツとレンダリング用のコンテンツとをURLで区別すれば、受信装置102はムーブ可能なコンテンツを知ることができる。
尚、コンテンツ検索のプロトコルとしては、UPnP Content Directory Service (UPnP CDS)で定められて方法を使ってもよい。なお、コンテンツの場所を示すURLの付加情報として、受信装置と送信装置が認証・鍵交換を行うための送信装置のIPアドレスとTCPポート番号を付与してもよい。また、送信装置が受信装置にコンテンツのリストを提示する際、同一のコンテンツに対して、レンダリング用のアドレスとムーブ用のアドレスを区別してリスティングしてもよい。ムーブ用のアドレスとレンダリング用のアドレスを区別する手段としては、(a)コンテンツのアドレスにムーブ用アドレスであることを示す付帯情報を付与する方法、(b)コンテンツのアドレスにムーブ鍵ラベルを付ける方法、などが考えられる。
受信装置102は、コンテンツのリストから所望のコンテンツを選択する。ここでは、ムーブ用コンテンツを選択したとする。受信装置は、コンテンツの場所の付加情報から認証・鍵交換処理を行うべき送信装置のアドレスとポート番号を取得し、コネクションBを用いて送信装置に対してムーブ用の認証・鍵交換処理開始を要求する(ステップ#6)。認証・鍵交換処理が成功すれば、送信装置100は各受信装置との間でコンテンツを暗号化するのに用いる秘密鍵である共通鍵Kx、ムーブ鍵Kxmを生成し、受信装置に対して共通鍵Kxやムーブ鍵Kxmをラベル情報とともに送信する(ステップ#8)。
セキュリティ確保のため、認証・鍵交換処理部34は、ムーブ鍵Kxmとして毎回異なる値を生成し、受信装置が同一であるか否かに関わらず、生成したムーブ鍵Kxmをネットワーク上に一回しか送信しないことが望ましい。
認証・鍵交換によって受信装置が以前認証・鍵交換を行った装置と同一であると確認できる場合には同じムーブ鍵Kxmを送信してもよいが、少なくとも異なる受信装置に対しては同じムーブ鍵Kxmは渡さない点が重要である。これにより、ムーブ鍵Kxmを用いて暗号化したコンテンツは1台の受信装置のみが復号できることを保証できる。
例えば、図2に示す送信装置Xが受信装置Aからはコンテンツaのムーブ要求を、受信装置Bからはコンテンツbのレンダリング要求を受信した場合、受信装置Aに対しては受信装置Aに送信したムーブ鍵Kxm1を用いてコンテンツaを暗号化し、受信装置Bに対しては共通鍵Kx1でコンテンツbを暗号化して送信する。
このようにすると、レンダリング用コンテンツbについては、受信装置B以外にも共通鍵Kx1を持つ受信装置A、Cが何らかの手段で当該コンテンツを受信することにより復号される可能性がある。しかしながらムーブ用コンテンツaについては、ムーブ鍵Kxm1を持つ受信装置Aでは復号されるが、ムーブ鍵Kxm1を持たない受信装置B、Cでは、たとえ受信することができたとしても、復号することはできない。このため、ムーブ対象のコンテンツaが2台以上の受信装置で復号されることを防止することができる。
しかも、送信装置は異なるコンテンツのレンダリング要求とムーブ要求とを同時に受け付けることが可能であるため、セキュリティとユーザの使い勝手の双方を向上させることができる。また、送信装置が複数の受信装置から異なるコンテンツのムーブ要求を受けた場合でも、それぞれの受信装置に送信した鍵を用いて個々のコンテンツを暗号化すればよいため、同時に複数のムーブ送信を実現することができる。
ムーブ鍵ラベルとは、各ムーブ鍵に対応したラベル情報であり、送信装置(例えば、図2の送信装置X)が複数のムーブ鍵(例えば、Kxm1、Kxm2、Kxm3)を有する場合にそれぞれのムーブ鍵を区別したり、受信装置が複数の送信装置からコンテンツをムーブする際に、どの送信装置とムーブ用認証・鍵交換を行い、どのムーブ鍵を保持しているか、どのムーブ鍵を用いて復号したらよいかを判別したりするために用いる。ムーブ鍵は認証・鍵交換処理によって共有した鍵を用いて暗号化して送信するが、ムーブ鍵ラベルはそれ自体が秘密の値ではないため、平文のままネットワーク上に送信してもよい。
なお、受信装置が送信装置に対してムーブ鍵Kxmを要求する手段としては、例えば、以下の例が考えられる。
(1)共通鍵を受信するための認証・鍵交換要求(図5の(a))とは別に、ムーブ鍵を受信するための認証・鍵交換要求を行う(図5の(b))
(2)共通鍵を受信するための認証・鍵交換要求を行い、一旦共通鍵を受信した後、送信装置へムーブ鍵要求を送信し、共通鍵を暗号化するのと同じ鍵で暗号化されたムーブ鍵を受信する(図6の(a))
(3)共通鍵を受信するための認証・鍵交換要求に基づいて、送信装置は共通鍵とムーブ鍵の両方を送信する(図6の(b))
なお、共通鍵のみが受信可能な受信装置や、ムーブ鍵を送信する機能のない送信装置との互換性を考慮し、図6の(a)の場合には、受信装置がムーブ鍵要求を送信する前に、図6の(b)の場合には、送信装置が共通鍵・ムーブ鍵を送信する前に、事前に互いの機能を確認してもよい。
また、送信装置のIPアドレス等から判断して、送信装置と既に認証・鍵交換を行ってムーブ鍵Kxmを既に取得していることが分かっている場合には、ムーブ鍵Kxmの認証・鍵交換の処理はスキップしてもよい。その場合、受信装置が持つムーブ鍵を送信装置が持っているか否かを確認するために、コンテンツ要求に先立ち、受信装置は送信装置に対して問い合わせを行ってもよい。その場合、問い合わせはムーブ鍵ラベルを含み、送信装置はムーブ鍵ラベルが自装置内に格納されているか否かの検索処理を行い、その検索結果を受信装置に返せばよい。
図4に戻り、受信装置102がムーブ鍵Kxmとムーブ鍵ラベルを受信すると、受信装置102はコネクションCを用いて送信装置100に対してコンテンツのムーブ要求を送信する(ステップ#10)。ムーブ要求には当該受信装置がどのムーブ鍵で暗号化されたコンテンツを受信可能かを示すムーブ鍵ラベルが含まれる。HTTPプロトコルのムーブ要求(GETリクエスト)の一例を以下に示す。5行目がムーブ鍵ラベルを示す。
Content-Type: application/x-dtcp1;
DTCP1HOST=<host>;
DTCP1PORT=<port>;
CONTENTFORMAT=<mimetype>;
DTCPKXM=<exchange_key_label>
送信装置100はムーブ要求に含まれるムーブ鍵ラベルを見てどのムーブ鍵を用いてコンテンツを暗号化したらよいかを判別し、ムーブ鍵ラベルと合致するムーブ鍵を用いてコンテンツを暗号化し、受信装置102に対して送信する(ステップ#12)。
送信されるコンテンツのフォーマットを図7に示す。コンテンツは、ヘッダ部5252と暗号化コンテンツ部54から構成されるパックの形で送信される。ヘッダ部52にはムーブ鍵ラベル58が含まれる。これ以外にもヘッダ部52内には、コピー不可、一世代のみコピー可、ムーブ、コピー可などのコンテンツのコピー制御情報56や、暗号化前コンテンツ部の長さ(コンテンツ長)60等の情報を入れても良い。
なお、受信装置から指定されたムーブ鍵が送信装置に存在しない場合には、コンテンツの送信を行わず、エラーを返す。また、このムーブ鍵ラベルとは別に、受信装置が送信装置に対して、コンテンツ要求がムーブ要求なのか、レンダリング要求なのかを区別するための付加情報をコンテンツ要求に付けてもよい。付加情報はURLの引数としてもよいし、リクエストヘッダを新たに定義し、そのパラメタとして挿入してもよい。
送信装置はムーブ送信したコンテンツについて、コンテンツの送信が完了した後、削除もしくは利用不可能(無効)な状態にする。
受信装置は暗号化コンテンツを受信すると、コンテンツのヘッダ部52に付けられたムーブ鍵ラベル58と、認証・鍵交換処理部34が格納するムーブ鍵ラベルを比較し、その値が一致すればコンテンツ復号を開始する。もしも一致しない場合には、コンテンツの受信を中止する。ムーブ鍵ラベルの値が異なる場合とは、送信装置がコンテンツの暗号化に用いたムーブ鍵と、受信装置の持つムーブ鍵の値が異なることを示す。ムーブの場合、送信装置は送信したコンテンツを削除または利用不可能な状態(無効化)にしてしまうので、受信装置がコンテンツを正しく復号できないと、コンテンツは消失してしまう。これを避けるために、コンテンツのヘッダ部52にムーブ鍵ラベル58を挿入して、受信装置がコンテンツを正しく復号できるか否かを判定している。
受信装置が受信したコンテンツのヘッダ部52に含まれるムーブ鍵ラベル58に基づいて復号可能なコンテンツかどうかを判別する代わりに、送信装置がコンテンツの送信に先立ち、コンテンツ要求に応答するコンテンツ応答を送信し、そのコンテンツ応答の中にムーブ鍵ラベルを含めてもよい。この場合、受信装置はコンテンツ応答の中のムーブ鍵ラベルが自装置が持つムーブ鍵ラベルと一致するか否かを判別する処理を行う。コンテンツ要求がHTTPプロトコルのGETリクエストで行われる場合、ムーブ鍵ラベルはHTTP Responseヘッダに含めればよい。
このように、受信装置がコンテンツ応答にて復号可能なコンテンツかどうかを判別できるため、仮に受信不可能なコンテンツである場合、受信装置はコンテンツを受信する前にコネクションを切断すれば、送信装置側はコンテンツを送信する前にコネクションを切断できるため、無駄な送信を行うことを防ぐとともに、コンテンツが消失することを防ぐことができる。
図8は送信装置の動作手順を示すフローチャートである。第1の実施形態では、受信装置が送信装置内のどのコンテンツをムーブさせるかを選択するモデルであるため、先ず送信装置100はコネクションAで受信装置102からのコンテンツ検索要求を受信し(ステップS2)、その応答としてコンテンツリストを送信する(ステップS4)。
その後、送信装置100は受信装置102からコネクションBでムーブ用の認証・鍵交換要求を受信し(ステップS6)、受信装置102と認証・鍵交換処理を行う。送信装置100は、ステップS8で認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗すれば、送信装置100はエラー処理(その旨を通知するメッセージを受信装置に送信)を行い(ステップS10)、以降の処理は行なわない。
認証・鍵交換が成功すると、送信装置100は認証・鍵交換によって受信装置102と共有した鍵を用いてムーブ鍵を暗号化し、ラベルを付けて暗号化ムーブ鍵をコネクションBで受信装置102に送信する(ステップS12)。
その後送信装置100は、実際のコンテンツをムーブするためのムーブ要求(ムーブ鍵ラベルを含む)をコネクションCで受信装置102から受信し(ステップS14)、そのムーブ要求に含まれるムーブ鍵ラベルで指定されるムーブ鍵が自装置内に存在するか否かを検索する(ステップS16)。
ムーブ要求に含まれるムーブ鍵ラベルで指定されたムーブ鍵が自装置内に存在しない場合は、送信装置100はエラー処理(その旨を通知するメッセージを受信装置に送信)を行い(ステップS10)、コンテンツの送信は行なわない。
指定されたムーブ鍵が自装置内に存在する場合は、送信装置100はそのムーブ鍵を用いてコンテンツを暗号化し(ステップS20)、コネクションCで暗号化コンテンツを受信装置102に送信する(ステップS22)。
図9は受信装置102の動作手順を示すフローチャートである。受信装置102はコンテンツ検索要求をコネクションAで送信装置100に送信し(ステップS32)、その応答として送信装置100から送信(図8のステップS4)されたコンテンツリストを受信する(ステップS34)。
その後、受信装置102はムーブ用の認証・鍵交換要求をコネクションBで送信装置100に送信し(ステップS36)、認証・鍵交換処理を開始する。受信装置102は、ステップS38で認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗と判断した場合は、受信装置102はエラー処理(その旨を通知するメッセージを送信装置に送信)を行い(ステップS40)、以降の処理は行なわない。
認証・鍵交換が成功すると受信装置102は、送信装置100が送信(図8のステップS12)した暗号化ムーブ鍵とムーブ鍵ラベルとをコネクションBで受信する(ステップS42)。受信装置102は、受信した暗号化ムーブ鍵を認証・鍵交換によって共有した鍵を用いて復号化し、ムーブ鍵ラベルとともに記憶しておく。
次に、受信装置102はコンテンツリストの中からムーブ対象コンテンツを選択し(ステップS44)、送信装置100と共有しているムーブ鍵に対応するムーブ鍵ラベルとともにムーブ要求をコネクションCで送信装置100に送信する(ステップS46)。そして受信装置102は、ムーブ要求の応答として送信装置から送信(図8のステップS22)された暗号化コンテンツを受信し(ステップS48)、そのコンテンツのヘッダ部52に含まれるムーブ鍵ラベルが、自装置の持つムーブ鍵ラベルに一致するか否かを確認する(ステップS50)。
ヘッダ部52に含まれるムーブ鍵ラベルが自装置の持つムーブ鍵ラベルに一致しない場合は、受信装置102はコンテンツ受信用コネクションを切断して(ステップS52)、エラー処理(その旨を通知するメッセージを送信装置に送信)を行い(ステップS40)、以降の処理は行なわない。
ムーブ鍵ラベルが自装置の持つムーブ鍵ラベルと一致する場合は、受信装置102は自装置の持つムーブ鍵を使って、送信装置100からコネクションCで受信した暗号化コンテンツを復号する(ステップS54)。
以上説明したように、第1実施形態によれば、レンダリング鍵とムーブ鍵を区別し、複数の受信装置に対して同一のレンダリング鍵を配布するが、ムーブ鍵は受信装置毎に別々の鍵を配布するので、コンテンツの不正利用を確実に防止できるとともに、同時にムーブとレンダリングを行うことができ、コンテンツの有効利用を図ることができる。しかも同じ鍵は一度だけしか配布しないので、さらにセキュリティの向上を図ることができる。
つまり、コンテンツをムーブする際、受信可能な受信装置の数を1台に限定し、かつ送信装置はあるコンテンツをムーブ中に、別のコンテンツを別な受信機器に送信することが可能になるため、コンテンツの不正利用を確実に防止できるとともに、コンテンツの有効利用を図ることができる。
また、コンテンツ送受信用、コンテンツ管理用、鍵送受信用のコネクションを別々に接続、使用するので、送受信装置間の伝送中の安全性が高い。
受信装置はムーブコンテンツの受信前にコンテンツの復号に必要なムーブ鍵を格納しているか否か判定し、格納していない場合は、コンテンツの受信を中止し、送信装置はコンテンツ送信後にコンテンツを削除、または無効化するので、誤ってムーブしたコンテンツの消失を防ぐことができる。
さらに、送信装置は鍵と鍵を特定するための鍵ラベルとを受信装置に送信し、受信装置から鍵ラベルにより鍵を指定する要求があった場合にその鍵を用いてコンテンツを暗号化するので、システム全体で複数の鍵の存在を許容することができ、コンテンツの利用態様を増やすことができ、コンテンツの有効利用につながる。
第2の実施形態
第1の実施形態は受信装置側が送信装置側に対してコンテンツをムーブして送信するための要求を送信するモデルであった。第2の実施形態は送信装置側が受信装置側に対してムーブ受信するように要求するモデルである。
図10は第2実施形態に係る送信装置200の概略構成を示すブロック図である。図10に示すように、送信装置200はコンテンツ供給部12と、認証・鍵交換処理部14と、コンテンツ選択部66と、鍵選択処理部18と、暗号処理部20と、ネットワークインターフェース処理部22と、コンテンツ伝送用コネクション管理部24と、コンテンツ管理用コネクション管理部26と、認証・鍵交換用コネクション管理部28を有する。
コンテンツ供給部12、認証・鍵交換処理部14、暗号処理部20、ネットワークインターフェース処理部22、コンテンツ伝送用コネクション管理部24と、コンテンツ管理用コネクション管理部26と、認証・鍵交換用コネクション管理部28については、図1と同様の機能を持ち、同様のブロックで構成することができる。
コンテンツ選択部66は、ムーブ対象のコンテンツを指定し、受信装置に対してコンテンツを受信する準備を整えるよう指示するメッセージを送信する機能を備える。
図11は第2実施形態に係る受信装置202の概略構成を示すブロック図である。図11に示すように、受信装置202はコンテンツ処理部32と、認証・鍵交換処理部34と、コンテンツ蓄積管理部68と、鍵選択処理部38と、暗号処理部40と、ネットワークインターフェース部42と、コンテンツ伝送用コネクション管理部44と、コンテンツ管理用コネクション管理部46と、認証・鍵交換用コネクション管理部48を有する。
コンテンツ処理部32、認証・鍵交換処理部34、暗号処理部40、ネットワークインターフェース処理部42、コンテンツ伝送用コネクション管理部44と、コンテンツ管理用コネクション管理部46と、認証・鍵交換用コネクション管理部48については、図3と同様の機能を持ち、同様のブロックで構成することができる。
コンテンツ蓄積管理部68は、コンテンツを受信する準備を整えるよう指示するメッセージを送信装置から受信し、その応答としてコンテンツを蓄積するためのURLを送信装置に送信する機能を持つ。
図12は本実施形態に係るコンテンツ送受信システムの処理(ここでは、ムーブ処理とする)手順を示すフローチャートである。本実施形態でも、送信装置200と受信装置202との間に3つの通信コネクションA,B,Cがあり、コネクションAはコンテンツ管理に用いられ、コネクションBは認証・鍵交換に用いられ、コネクションCはコンテンツ伝送に用いられる。
第1の実施形態とは異なり、第2の実施形態では、先ず送信装置200がコネクションAを用いて受信装置202に対してコンテンツを受信するよう指示するためのメッセージ(コンテンツ受信要求)を送信する(ステップ#22)。このメッセージには、送信するデータが暗号化したコンテンツであることを示す情報、受信装置202と送信装置200が認証・鍵交換を行うための送信装置のIPアドレスとTCPポート番号、MIME−Typeなどの暗号化前のコンテンツの種別を表す情報を含めてもよい。なお、このメッセージの送信に先立ち、ネットワークから受信装置を検索するための手段や、メッセージを送信するためのIPアドレス、ポート番号の決定には、UPnPなどよく知られた方法が用いられる。コンテンツを受信するように指示するメッセージの送信には、例えば以下のようなUPnPのCreate Objectメッセージが用いられる。
Content-Type: application/x-dtcp1;
DTCP1HOST=<host>;
DTCP1PORT=<port>;
CONTENTFORMAT=<mimetype>;
DTCOKXM=NULL
次に、受信装置202はコネクションBを用いて送信装置200に対してムーブ用の認証・鍵交換処理開始を要求する(ステップ#24)。認証・鍵交換処理が成功すると、送信装置200は各受信装置202との間でコンテンツを暗号化するのに用いる秘密鍵である共通鍵Kx、ムーブ鍵Kxmを生成し、受信装置202に対して共通鍵Kxやムーブ鍵Kxmを送信する(ステップ#26)。なお、第1の実施形態と同様に、ムーブ鍵の送信と同時に、ムーブ鍵を区別するためのムーブ鍵ラベル情報も送信する。認証・鍵交換処理が失敗した場合には、エラー処理を行い、以下の処理は行わない。
認証・鍵交換が終了すると、受信装置202はコネクションBを用いてコンテンツを受信する準備が整ったことを示すコンテンツ受信確認メッセージを送信装置200に返信する(ステップ#28)。このとき、受信装置202は返信メッセージの中に、送信装置200がどのアドレスに対してコンテンツを送信すればよいかを示すアドレス情報と、受信機器202が認証・鍵交換処理の結果送信装置から受信したムーブ鍵ラベルを含める。アドレス情報は例えばURLの形式で示せばよい。返信メッセージの一例を以下に示す。
<service>://<host>:<port>/<path>/<FileName>.<FileExtention>?CONTENTPROTECTIONTYPE=DTCP1&DTCPKXM=<exchange_key_label>
その後、送信装置200は、コンテンツ受信確認メッセージにて指定されたアドレスに対してコンテンツの送信を開始する(ステップ#30、#32)。送信装置200は送信したコンテンツについて、削除もしくは利用不可能な状態にする。コンテンツの暗号化に用いる鍵には、コンテンツ受信確認メッセージに含まれるムーブ鍵ラベルに対応するムーブ鍵を用いる。
もし、コンテンツ受信確認メッセージに含まれるムーブ鍵ラベルに対応するムーブ鍵が存在しない場合には、受信装置に対してエラーメッセージを送信する。コンテンツの形式は図7に示したフォーマットでよい。すなわち、コンテンツのヘッダ部52にムーブ鍵ラベル58をつけ、そのムーブ鍵ラベル58に対応するムーブ鍵を使ってコンテンツを暗号化する。
コンテンツの送信にはHTTPプロトコルのPOSTリクエストがを用いる。このとき、HTTPヘッダ情報として、ムーブ鍵ラベルをつけてPOSTリクエストを送信してもよい。POSTリクエストの一例を以下に示す。
Content-type: application/x-dtcp1;
DTCP1HOST=<host>;
DTCP1PORT=<port>;
CONTENTFORMAT=<mimetype>;
DTCPKXM=<exchange_key_label>
受信装置202は、コンテンツのヘッダ部52もしくはPOSTリクエスト内のHTTPヘッダに定義されたムーブ鍵ラベルと、認証・鍵交換処理の結果、送信装置から送信され自装置が格納するムーブ鍵ラベルの値が一致するかどうかを比較し、一致している場合にはムーブ鍵ラベルに対応するムーブ鍵にてコンテンツを復号する。一致しない場合には、コンテンツの受信を中止し、コンテンツ送受信用のコネクションCを切断する。
ムーブ鍵ラベルの値が異なる場合とは、送信装置がコンテンツの暗号化に用いたムーブ鍵と、受信装置の持つムーブ鍵の値が異なる場合のことである。第1の実施形態と同様に、コンテンツの暗号鍵と復号鍵が異なることにより、コンテンツが消失してしまうことを避けるために、ムーブ鍵ラベルを使って鍵が一致することを確認することで、コンテンツが不用意に消失することを避けることができる。
なお、第2の実施形態では、ムーブ対象のコンテンツを選択する処理は送信装置側で行われる。ユーザインターフェース上の観点から、ムーブするコンテンツの選択権はコンテンツを蓄積している側、すなわち送信装置側にあることが好ましい。従来の手法では認証・鍵交換処理の開始は受信装置側にあり、送信装置側から認証・鍵交換を開始することができない。しかし、本実施形態では、ムーブ対象のコンテンツを選択する権利を送信装置側に保持しつつ、受信装置がコンテンツ受信要求をトリガーとして認証・鍵交換処理を開始することでこの問題を解決している。さらに、ムーブ鍵ラベルを用いて復号不可能なコンテンツをムーブすることを防止することにより、コンテンツの不要な消失を避けることができる。
図13は送信装置の動作手順を示すフローチャートである。第2の実施形態では、送信装置が自装置内のどのコンテンツをムーブさせるかを選択するモデルであるため、送信装置200は、先ずどのコンテンツをムーブするのか決定する(ステップS52)。
その後、受信装置202に対してそのコンテンツを受信する準備を整えるよう指示するために、送信装置200はコネクションAによりコンテンツ受信要求を送信する(ステップS54)。その後、送信装置200はコネクションBにより受信装置が送信する認証・鍵交換要求を受信し(ステップS56)、受信装置と認証・鍵交換処理を行う。このように認証・鍵交換処理をコンテンツ受信要求送信直後(コンテンツ受信確認の送信前)に開始することにより、送信装置200はコンテンツ受信確認の受信直後にムーブ要求、暗号化コンテンツを送信することができ、待ち時間(認証・鍵交換)無くコンテンツの送信を開始することができる。
送信装置200は、ステップS58で認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗すれば、送信装置200はエラー処理を行い(その旨を通知するメッセージを受信装置に送信し)(ステップS60)、以降の処理は行なわない。
認証・鍵交換が成功すると、送信装置200は認証・鍵交換によって共有した鍵を用いて暗号化したムーブ鍵を生成し、ムーブ鍵ラベルを付けて暗号化ムーブ鍵をコネクションBにより受信装置202に送信する(ステップS62)。
その後送信装置200は、コンテンツ受信要求に対応する応答メッセージとしてのコンテンツ受信確認を受信装置202から受信する(ステップS64)。この応答メッセージには、コンテンツを送信する先の(コネクションCの)アドレス情報と、受信機器が持つムーブ鍵ラベルが含まれている。送信装置200は、その応答メッセージに含まれるムーブ鍵ラベルで指定されたムーブ鍵が自装置内に存在するか検索する(ステップS66)。
検索に失敗すれば、送信装置200は、その旨を通知するメッセージを受信装置202に送信し、エラー処理を行い(その旨を通知するメッセージを受信装置に送信し)(ステップS68)、コンテンツの送信は行わない。検索に成功すれば、送信装置200はそのムーブ鍵を用いてコンテンツを暗号化し(ステップS70)、受信装置に送信する(ステップS72)。
図14は受信装置202の動作手順を示すフローチャートである。受信装置202は送信装置200から送信(図13のステップS54)されたコンテンツ受信要求をコネクションAで受信する(ステップS82)。受信装置202は、ステップS84でムーブ鍵を送信装置と既に共有しているか否かを判定する。
もし、送信装置200とムーブ鍵を既に共有していれば、受信装置202はコンテンツ受信要求の応答メッセージとしてコンテンツ受信確認を送信する(ステップS94)。送信装置とムーブ鍵を既に共有していなければ、受信装置はコネクションBで認証・鍵交換要求を送信し(ステップS86)、認証・鍵交換処理を開始する。
ステップS88で受信装置202は認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗すれば、受信装置202はエラー処理(その旨を通知するメッセージを送信装置に送信)を行い(ステップS90)、以降の処理は行なわない。
認証・鍵交換が成功すると、受信装置202は送信装置200が送信(図13のステップS62)した暗号化ムーブ鍵とムーブ鍵ラベルとをコネクションBで受信する(ステップS92)。認証・鍵交換によって共有した鍵を用いて暗号化ムーブ鍵を復号化し、ムーブ鍵をムーブ鍵ラベルとともに認証・鍵交換処理部34に格納する。
その後、受信装置202はコンテンツ受信要求の応答メッセージとしてのコンテンツ受信確認を送信する(ステップS94)。次に受信装置202は、コンテンツ受信確認にて示したアドレスに対するコンテンツのムーブ要求を送信装置200から受信する(ステップS96)。このムーブ要求にはムーブ鍵ラベルが含まれる。このムーブ鍵ラベルか、コンテンツムーブ要求に引き続き受信するコンテンツのヘッダ部52に含まれるムーブ鍵ラベルが、自装置の持つムーブ鍵ラベルに一致するか否かを確認する(ステップS100)。自装置の持つムーブ鍵ラベルに一致しない場合は、コンテンツを復号できないので、ムーブを中止させるために、受信装置202はコンテンツ受信用コネクションCを切断してコンテンツの受信を中止し(ステップS104)、エラー処理を行い(ステップS90)、以降の処理は行なわない。自装置の持つムーブ鍵ラベルに一致する場合は、受信装置202はムーブ鍵を用いてコンテンツを復号する(ステップS102)。
以上説明したように、第2実施形態によれば、第1実施形態の効果に加えて、送信装置からのコンテンツ受信要求をトリガーとして受信装置から認証・鍵交換処理を開始することにより、コンテンツを蓄積している送信装置にコンテンツの選択権を与え、送信装置をクライアントとすることができる効果を奏することができる。また、コンテンツ受信要求を送信後、その確認を待たずに、認証・鍵交換を開始し、認証・鍵交換の終了後にコンテンツ受信確認を受信することにより、送信装置はコンテンツ受信確認の受信直後にムーブ要求、暗号化コンテンツを送信することができ、待ち時間(認証・鍵交換)無くコンテンツの送信を開始することができる。
上述した実施形態で説明した送信装置、受信装置は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報処理装置の少なくとも一部の機能を実現するプログラムをフロッピー(登録商標)ディスクやCD−ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の携帯可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
また、送信装置、受信装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線(無線通信も含む)を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。また、レンダリング要求が生じた時は、上述の動作でムーブ用とある説明をレンダリング用と変えればよい。