本発明は、著作権やその他の目的で保護が必要となる情報コンテンツを所定のコピー制御情報に従って暗号化伝送するコンテンツ伝送システムに関するものである。かかるシステムの具体例は、DTCP−IP機器の間で行なわれるHTTPプロトコルを利用したコンテンツ伝送である。以下、図面を参照しながら本発明の実施形態について詳解する。
A.システム構成
DTCP−IPに従ったコンテンツ伝送は、コンテンツを送信するSourceと、コンテンツを受信して再生若しくは記録するSinkで構成される。コンテンツの伝送方法としては、サーバとして動作するSourceがクライアントとして動作するSinkからの要求に応じてコンテンツを送信するダウンロード転送と、クライアントとして動作するSinkからの要求によりサーバとして動作するSinkへコンテンツを送信するアップロード転送が考えられる。
図1には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。図示の例では、SourceとSinkの各装置により、DTCP−IP AKEシステムが構築されている。DTCP−IPに準拠した認証サーバであるSourceとDTCP−IPに準拠した認証クライアントであるSinkはネットワークを経由して接続されている。ここで言うネットワークには、Ethernet(登録商標)や、インターネット、その他のIPネットワークが含まれる。
図2及び図3には、図1に示したコンテンツ伝送システムにおいて、Sink及びSourceとして動作するコンテンツ伝送装置の、特に認証及びコンテンツ伝送に着目した機能構成をそれぞれ模式的に示している。但し、図2及び図3では、サーバとして動作するSourceがクライアントとして動作するSinkからの要求に応じてコンテンツをダウンロード転送する場合の機能構成を示したものであり、アップロード転送時の機能構成については説明を省略する。SinkとSourceは、インターネットなどのTCP/IPネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
図2に示すSinkは、DTCP−IP認証ブロック10と、DTCP−IPコンテンツ受信ブロック20と、コンテンツ再生/記録ブロック30を備え、HTTPクライアントとして動作し、HTTPサーバとして動作するSourceからダウンロード転送されるコンテンツを受信するようになっている。
DTCP−IP認証ブロック10は、AKEブロック11と、メッセージ・ダイジェスト生成ブロック12と、コンテンツ復号ブロック13で構成される。DTCP−IP認証ブロック10は、より好ましくは耐タンパ性を備えている。
AKEブロック11は、DTCP−IPにおけるAKE機構(Sink側)を実現するブロックである。このAKEブロック11は後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。AKEブロック11は、コピーなど通常のコンテンツ伝送手続を行なう際のAKEとは別に、MOVE専用のAKE手続を規定し、スクランブル方法などを異ならせることによってMOVEモードの詐称を防止するようにしてもよい。
メッセージ・ダイジェスト生成ブロック12は、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばMD5やSHA−1といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる(SHA−1は、MD5と同様、MD4を改良したものに相当するが、160ビットのハッシュ値を生成するので、強度はMDシリーズを上回る)。
メッセージ・ダイジェスト生成ブロック12は、DTCP−IP認証ブロック10の外に公開してはならないAKEブロック11が保持するパラメータのメッセージ・ダイジェストを生成できるようにAKEブロック11と密に配置され、AKEブロック11へパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
コンテンツ復号ブロック13は、AKEで交換した鍵Kxを用いてコンテンツの復号鍵Kcを算出し、Sourceから受信した暗号コンテンツをこの復号鍵Kcで復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生/記録ブロックへ渡される。MOVE専用のAKE手続を規定した場合も同様である。
コンテンツ再生/記録ブロック30は、コンテンツ復号ブロック13から渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合はハード・ディスク又はその他の記録媒体(図示しない)に保存する。但し、コンテンツの記録動作は、コンテンツ伝送用のパケットPCP内に挿入されているコピー制御情報の規定に従う。
DTCP−IPコンテンツ受信ブロック20は、AKEを実施した後にSourceとのコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、DTCP−IPコンテンツ受信ブロック20はHTTPクライアント・ブロック21を持ち、HTTPクライアントとしてHTTPサーバ(すなわちSource)へコンテンツを要求し、応答されたコンテンツをHTTPサーバから受信する。
HTTPクライアント・ブロック21は、HTTPリクエスト管理ブロック22とHTTPレスポンス管理ブロック23に分かれる。さらに、HTTPリクエスト管理ブロックは、HTTPリクエスト送信ブロック22AとHTTPリクエスト生成ブロック22Bに分かれる。
HTTPリクエスト生成ブロック22Bは、送信するコンテンツ伝送要求(HTTPリクエスト)を生成する。ここで生成されたHTTPリクエスト(例えば、HTTP GETリクエスト)は、HTTPリクエスト送信ブロック22AによりHTTPサーバ(すなわちSource)へ送信される。
HTTPレスポンス管理ブロック23は、HTTPレスポンス受信ブロック23AとHTTPレスポンス解釈ブロック23Bに分かれる。サーバから返信されるHTTPレスポンスと暗号化されたコンテンツは、HTTPレスポンス受信ブロック23Aで受信される。ここで受信したHTTPレスポンスは、HTTPレスポンス解釈ブロック23Bでチェックされる。ここでのチェックがOKの場合は受信した暗号化コンテンツをDTCP−IP認証ブロック10内のコンテンツ復号ブロック13へ送る。また、このチェックがNGの場合は、エラー・レスポンスとしての処理を行なう。SourceからのHTTPレスポンスは1つ以上のPCPからなる。
DTCP−IP認証ブロック10とDTCP−IPコンテンツ受信ブロック20は、サーバ機器との間で個別のTCP/IPコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
また、図3に示すSourceは、DTCP−IP認証ブロック40と、DTCP−IPコンテンツ送信ブロック50と、コンテンツ管理ブロック60を備え、HTTPサーバとして動作し、HTTPクライアントとして動作するSinkに対してコンテンツをダウンロード転送するようになっている。
DTCP−IP認証ブロック40は、AKEブロック41と、メッセージ・ダイジェスト生成ブロック42と、コンテンツ暗号化ブロック43で構成される。DTCP−IP認証ブロック40は、より好ましくは耐タンパ性を備えている。
AKEブロック41は、DTCP−IPにおけるAKE機構(Source側)を実現するブロックである。このブロックは、メッセージ・ダイジェスト生成ブロック42から要求されたパラメータ(後述)を渡す機能も備えている。AKEブロック41は認証したSinkに関する情報をAKE認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。AKEブロック41は、コピーなど通常のコンテンツ伝送手続を行なう際のAKEとは別に、MOVE専用のAKE手続を規定し、スクランブル方法などを異ならせることによってMOVEモードの詐称を防止するようにしてもよい。
メッセージ・ダイジェスト生成ブロック42は指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばMD5やSHA−1といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる(同上)。
メッセージ・ダイジェスト生成ブロック42は、DTCP−IP認証ブロック40の外に公開してはならないAKEブロック41が保持するパラメータのメッセージ・ダイジェストを生成できるようにAKEブロック41と密に配置され、AKEブロック41へパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
コンテンツ暗号化ブロック43は、DTCP−IPコンテンツ送信ブロック50の要求に応じてコンテンツ管理ブロック60より読み出したコンテンツ・データを、AKEで交換した鍵Kxから生成したコンテンツ鍵Kcを用いて暗号化するブロックである。ここで暗号化されたコンテンツは、クライアントへ送信するために、DTCP−IPコンテンツ送信ブロック50へ渡される。
コンテンツ管理ブロック60は、DTCP−IPの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
DTCP−IPコンテンツ送信ブロック50は、HTTPサーバ・ブロック51を持ち、HTTPサーバとしてクライアント(すなわちSink)からのリクエスト(例えば、HTTP GETリクエスト)を受理し、要求に応じた処理を実行する。
HTTPサーバ・ブロック51は、HTTPリクエスト管理ブロック52とHTTPレスポンス管理ブロック53に分かれる。
HTTPリクエスト管理ブロック52は、さらに、HTTPリクエスト受信ブロック52Aと、HTTPリクエスト解釈ブロック52Bに分かれる。HTTPリクエスト受信ブロック52Aは、クライアントからのHTTPリクエストを受信する。受信したHTTPリクエストはHTTPリクエスト解釈ブロック52Bに送られ、チェックされる。HTTPリクエスト解釈ブロック52BにおけるチェックがOKの場合、HTTPリクエストの情報をDTCP−IP認証ブロック40へ通知する。
HTTPレスポンス管理ブロック53は、さらに、HTTPレスポンス生成ブロック53BとHTTPレスポンス送信ブロック53Aに分かれる。
HTTPレスポンス生成ブロック53Bは、HTTPリクエスト解釈ブロック52BでのチェックがOKの場合、暗号化されたコンテンツを返すためのHTTPレスポンスを作成する。HTTPレスポンスは1つ以上のPCPからなる。一方、HTTPリクエスト解釈ブロック52BでのチェックがNGの場合、エラーを返すためのHTTPレスポンスを作成する。
HTTPレスポンス送信ブロック53Aは、作成されたHTTPレスポンスを、要求元のクライアントへ送信する。また、HTTPリクエスト解釈ブロック52BでのチェックがOKの場合には、HTTPレスポンス・ヘッダに続けて、DTCP−IP認証ブロック40内のコンテンツ暗号化ブロック43で暗号化したコンテンツを送信する。
DTCP−IP認証ブロック40とDTCP−IPコンテンツ送信ブロック50は、Sinkとの間で個別のTCP/IPコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
なお、DTCP−Sink及びDTCP−SourceのいずれもがDTCP−IP認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、DTCP−IP自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。
B.HTTPを利用したコンテンツ伝送
続いて、DTCP−IPに従ったコンテンツの伝送手順について説明する。図4には、SourceとSinkの間でAKEに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。コンテンツ伝送の形態は、Source上のコンテンツをSinkにコピーする方法と、SourceからSinkへコンテンツを移動してSourceにコンテンツを残さない方法がある。この項では、前者のコピーによるコンテンツ伝送方法を前提にして説明する。後者のコンテンツ伝送方法はMOVE機能によって実現されるが、MOVE伝送を行なう際のAKE手続の詳細については後述に譲る。
SourceとSinkは、まず1つのTCP/IPコネクションを確立し、機器同士の認証を行なう。この認証を、DTCP認証若しくはAKE(Authentication and Key Exchange)と言う。DTCP準拠機器には、DTLA(前述)により発行された機器証明書が埋め込まれている。DTCP認証手続きでは、互いが正規のDTCP準拠機器であることを確かめた後、認証鍵KauthをSourceとSinkで共有することができる。
AKE手続きが成功すると、Sourceはコンテンツ鍵Kcの種となる交換鍵Kxを生成し、認証鍵Kauthで暗号化してSinkに送る。Source及びSinkそれぞれにおいて、交換鍵Kxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Kcが生成される。コンテンツ伝送方法に応じて交換鍵Kxからコンテンツ鍵Kcを生成するための計算式を変えるようにしてもよいが(例えば、コンテンツのコピー伝送とMOVE伝送で計算式を切り替えるようにしてもよい)、この点の詳細については後述に譲る。
そして、DTCP準拠の機器間でAKEによる認証及び鍵交換手続きが済んだ後、SinkはSource上のコンテンツを要求する。Sourceは、UPnP(登録商標)で規定されているCDS(Content Directory Service)などを通じてSinkにSource上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。Sinkがコンテンツを要求するとき、HTTPやRTPなどのプロトコルを利用することができる。
図4に示す例では、HTTPの手続きに従ってHTTPクライアントとしてのSinkがHTTPサーバとしてのSourceに対してコンテンツを要求するダウンロード形式となるコンテンツ伝送の場合、例えばHTTP GETメソッドを用いてコンテンツの伝送を開始する。また、図示しないが、HTTPの手続きに従ってHTTPクライアントとしてのSourceがHTTPサーバとしてのSinkに対してコンテンツをプッシュするアップロード形式となるコンテンツ伝送の場合、例えばHTTP POSTメソッドを用いてコンテンツの伝送を開始する。あるいは、RTPによる伝送を要求するとき、SourceがRTP Senderとなり、SinkがRTP Receiverとなってコンテンツの伝送を開始する。
HTTPでコンテンツ伝送を行なう際、AKE手続すなわちDTCP認証のためのTCP/IPコネクションとは別に、HTTPのためのTCP/IPコネクションがHTTPクライアントより作成される(すなわち、SourceとSinkはそれぞれ、AKE手続き用とコンテンツ伝送用に個別のソケット情報(IPアドレスとポート番号の組み合わせ)を持つ)。そして、HTTPクライアントとしてのSinkは、通常のHTTPと全く同様の動作手順により、GETメソッドを用いたHTTPリクエストによりHTTPサーバ上のコンテンツを要求する。これに対し、HTTPサーバは、要求通りのコンテンツをHTTPレスポンスとして返す。
HTTPレスポンスとして伝送されるデータは、HTTPサーバすなわちSourceがAKE認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Sourceは、乱数を用いてノンスNcを生成して、交換鍵KxとノンスNcと暗号モードを表すE−EMIを基にコンテンツ鍵Kcを生成する。そして、Sinkから要求されているコンテンツを、コンテンツ鍵Kcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスNcとE−EMIを含んだヘッダからなるパケットであるPCP(Protected Content Packet)をTCPストリーム上に乗せて送信する。そして、IPプロトコルは、TCPストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したIPパケットにし、指定されたIPアドレス宛てに届ける。
Sink側では、Sourceからの各IPパケットを受信すると、これをTCPストリームに組み立てて、送信されたPCPを取り出す。そして、ストリームからノンスNcとE−EMIを取り出すと、これらと交換鍵Kxを用いてコンテンツ鍵Kcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。このようにしてHTTPプロトコルを利用したコンテンツ伝送が終了すると、例えばSink側から、コンテンツ伝送に使用したTCPコネクションを適宜切断する。
図5には、DTCP−IPにおいてコンテンツ伝送に用いられるパケットPCPのデータ構造を模式的に示している。図示のように、PCPは、ノンスNcを含んだヘッダと、暗号化コンテンツからなるペイロードで構成されるパケットである。ちなみに、HTTPレスポンスは1つ以上のPCPからなり、RTPペイロードは1つのPCPからなる。
PCPヘッダは平文であり、ノンスNcが含まれている。また、PCPペイロードはノンスNcで決まるコンテンツ鍵Kcで暗号化されたコンテンツ(但し、コピー制御情報として“copy−free”が指定されているコンテンツは暗号化不要)で構成される。
PCPペイロードは、データ長すなわちprotected_content_lengthの値が常に16バイトの倍数になるように規定されている。protected_content_lengthの値が16の整数倍でないときは、必要に応じて暗号化前にパディング(padding)が行なわれ、コンテンツに1〜15バイトのパディングが付く。図6には、PCPをパディングする様子を示している。
ここで、長大なTCPストリーム全体に亘り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、DTCP−IPでは、Sourceは128MB毎にノンスNcすなわちコンテンツ鍵Kcを更新する(1ずつインクリメントする)よう取り決められ、コンテンツの安全化が図られている。定期的にノンスNcを更新する時点でも、PCPはパディングされる(コンテンツ鍵Kcを更新しなくても複数のPCPにpaddingすることは可能)。
また、DTCP−IPでは、ノンスNcの更新に伴い、コンテンツ鍵確認手続を起動するようになっている。コンテンツ鍵確認手続では、Sinkは、コンテンツ伝送用のTCPコネクションとは別に、コンテンツ鍵の確認用のTCPコネクションをさらに確立し、Sourceに対しコンテンツ鍵確認のための手続きを行なう。Sinkは、コンテンツ鍵の確認が必要になると、適宜このTCPコネクションを確立する。例えば、DTCP−IP Volume 1 Supplement E.8.6には、コンテンツ鍵の確認手続きとして“Content Key Confirmation”を規定している。これによれば、Sinkは、CONT_KEY_CONF subfunctionを用いて、現在のノンスNcに関連付けられたコンテンツ鍵の確認を行なう。
C.コンテンツのMOVE伝送
DTCP−IPでは、Source側でNo More Copiesとして符号化されているコンテンツをSinkで利用できるようにする手段として、MOVE機能が用意されている。
ネットワーク通信におけるMOVEは、機器間でデータを移動させることに相当し、移動先の機器にデータが移動した後は基本的に移動元の機器にはデータを残さない。DTCP−IPで言うMOVE機能は、Sinkは受信したコンテンツをNo More Copiesとして符号化して扱うこと、及び、Source側では伝送した後のコンテンツを消去又は利用不能にするという条件の下で、暗号化コンテンツをSourceからSinkへ伝送することを意味し、単一のSourceと単一のSink間でのみMOVEが許容される。
以下では、DTCP−IPに準拠する機器同士の相互運用を実現するためのMOVEシーケンスについて説明する。最低限の相互運用を確保するには、単一のHTTP GETメソッド又はPOSTメソッドを用いたMOVE伝送が推奨されるが、勿論、他のシーケンスを用いた実装が禁止されている訳ではない。
DTCP−IPにおけるMOVEシーケンスでは、Source側でコンテンツを消去又は利用不能にするという条件を一貫して遵守することが課されている。このため、Source側で送信後のデータを逐次的に利用不能にするとともに、Sink側で受信データを逐次的に利用可能にしていくという“INCREMENTAL MOVE”を行なう必要がある。ところが、伝送路での障害が発生したことやその他の原因によりMOVEシーケンスが中断すると、コンテンツがSourceとSink間で分断されたり欠落が発生したりしてしまう。そして、MOVEシーケンスが途切れた結果として、ユーザは、そもそも適正に取得したコンテンツを消失してしまうことになる。
そこで、本実施形態に係るコンテンツ伝送システムでは、Sinkは、MOVE伝送中のコンテンツを順次記録媒体に記録するが、MOVEの終了処理が成功するまでは順次記録したコンテンツを利用できない状態に保つようにした。そして、MOVE伝送の終了処理の確認すなわちCommitmentが行なわれると、Sink側の記録コンテンツを有効化して利用できる状態にすると同時に、Source側で元のコンテンツを消去若しくは利用不能にする処理を行なう。このような伝送手順によれば、MOVE伝送中にSourceとSinkでNo More Copyコンテンツが二重に存在することはない。且つ、伝送路で障害が発生するなどによりMOVE伝送処理が途切れても、コンテンツが分断することはなく、Sink側から改めてコンテンツ伝送を再開(resume)することができる。
このようなコンテンツのMOVE伝送は、コンテンツ全体を一括してSourceとSink間で移動することと等価である。Source側で送信後のデータを逐次的に利用不能にするとともにSink側で受信データを逐次的に利用可能にしていくINCREMENTEL MOVEとは異なり、“BLOCK MOVE”と呼ぶこともできる。BLOCK MOVEも、SourceとSinkで同じコンテンツが二重に存在することはないから、DTCPで規定されている条件を満たしたコンテンツのMOVE処理であると言える。
なお、Sinkは、MOVE伝送の終了処理が成功するまでは、記録したコンテンツを再生することはできないが、受信コンテンツを無効化した状態で記録する動作と並行して、受信コンテンツを再生出力(レンダリング)するように構成することも可能である。何故ならば、BLOCK MOVEがDTCPで既定する条件を満足するMOVE処理であるとするならば、これに並行したレンダリング処理は、MOVE伝送用のTCPコネクションと並行してコンテンツ・ストリーミング伝送用のTCPコネクションを確立して、ストリーミング・データを再生出力することと等価であるからである。BLOCK MOVEに並行してレンダリング処理を行なう場合、TCPコネクションは1本で済むから通信路を節約することができる。また、SourceやSinkの機器にとってはMOVE伝送とレンダリングの双方の処理を単一のコンテンツ伝送処理で済ますことができるから負荷を軽減することになる。
コンテンツのMOVE処理と受信コンテンツの再生処理を並行して行なうためには、図2に示したSink内のコンテンツ再生/記録ブロック30を、コンテンツ再生ブロック31とコンテンツ記録ブロック32という2つの独立したモジュールとして構成すればよい。図7には、この場合の機能ブロック図を示している。
コンテンツ復号ブロック13では、AKEで交換した交換鍵Kxから算出されるコンテンツの復号鍵Kcを用いて、Sourceから受信した暗号化コンテンツを復号すると、これをコンテンツ再生ブロック31とコンテンツ記録ブロック32の各々に供給する。
コンテンツ記録ブロック32では、コンテンツをNo More Copiesとして規定の符号化処理を施して、まず無効化された状態でハード・ディスク又はその他の記録媒体(図示しない)に保存する。コンテンツ記録ブロック32により保存された符号化コンテンツは、MOVE伝送全体が完了するまでは有効化されないので、記録媒体から読み出して復号して利用(例えばコンテンツ再生ブロックで再生)することはできない。また、コンテンツ記録ブロック32を、コンテンツ復号ブロック13と同様に、耐タンパ性のあるDTCP−IP認証ブロック10内に配置することで、コンテンツ復号ブロック13とコンテンツ記録ブロック32間での復号コンテンツの漏洩の問題はなくなる。
一方、コンテンツ再生ブロック31では、コンテンツ復号ブロック13から供給されるコンテンツを、そのままビデオ及びオーディオ信号に変換(レンダリング)して、ディスプレイなどのAV出力部から映像並びに音響出力する。このような復号コンテンツの出力は、出力とともにデータが失われるのでコンテンツのコピーには相当せず、SourceとSinkの両方に重複して存在する再生可能なコンテンツがあってはならないというDTCP規格に抵触しない。
このようにMOVE処理と並行して受信コンテンツの再生処理を実行することにより、ユーザは、MOVE伝送中にそのコンテンツの内容を確認するとともに、リアルタイムでコンテンツ視聴を享受することができる。
ここで、SourceとSink間のコンテンツ伝送が、コンテンツ再生ブロックにおける再生の実時間より高速に行なわれる場合には、コンテンツ再生ブロック31はAV出力用バッファ33をローカルに備えていてもよい。上述したような並列処理を行なう際、コンテンツ復号ブロック13から直接供給されるコンテンツをこのAV出力用バッファ33に蓄積し、FIFO形式で再生出力するようにすれば、コンテンツ再生ブロック31を通じたコンテンツの実時間再生を行なうことができる。AV出力用バッファ33の実装方法としては、コンテンツ再生ブロック31専用のバッファ・メモリを設ける以外に、コンテンツ記録ブロック32が持つハード・ディスクなどの記録媒体(図示しない)とAV出力用バッファ33とを統合し、AV出力用のコンテンツと記録用のコンテンツを一元化することも考えられる。
本発明者らは、SourceとSink間のMOVE伝送を、ダウンロードとアップロードに大別して扱うことにしている。ここで言うダウンロードとは、Sinkを操作するユーザがSourceからコンテンツをプル配信することを意味し、例えばSourceがHTTPサーバとして動作するとともにSinkがHTTPクライアントとして動作し、HTTP GETメソッドを用いてMOVEシーケンスを実装することができる。また、アップロードとは、Sourceを操作するユーザがSinkに対してコンテンツをプッシュ配信することを意味し、例えばSourceがHTTPクライアントとして動作するとともにSinkがHTTPサーバとして動作し、HTTP POSTメソッドを用いてMOVEシーケンスを実装することができる。最低限の相互運用を確保するには、単一のHTTP GETメソッド又はPOSTメソッドを用いたMOVE伝送が推奨されるが、勿論、他のシーケンスを用いた実装が禁止されている訳ではない。
従来のDTCP−IPではSinkからコンテンツ伝送のトリガが発生するダウンロード形式でコピー伝送が行なわれるのが一般的であるが(例えば、図4を参照のこと)、以下ではダウンロード伝送とアップロード伝送それぞれの場合についてのBLOCK MOVE伝送シーケンスについて説明する。
C−1.ダウンロード形式のBLOCK MOVE
図8には、ダウンロード形式でSourceとSink間のBLOCK MOVE伝送を行なう場合の動作シーケンスを示している。図示の通り、この場合のMOVE伝送は、Source及びコンテンツ選択、MOVE用AKE手続き、コンテンツ移動(MOVE)手続き、MOVE終了処理手続きという4段階のフェーズで構成される。このうち、MOVE用AKE手続き、コンテンツ移動(MOVE)手続き、MOVE終了処理手続きは、DTCP上で規定される手順に従って実行される。
Source及びコンテンツ選択のフェーズは、例えばUPnP(登録商標)ベースで行なうことができ、この場合、SinkはCDS(ContentDirectory Service)を利用してコンテンツ情報を取得することができる。CDSは、UPnP(登録商標)メディア・サーバの主要なサービスの1つである。通常、SinkはCDSを用いてコンテンツの閲覧や検索、コンテンツのメタデータの編集などを行なう。図9には、この場合のSourceとSink間の動作シーケンスを示している。
まず、Sinkは、CDS::Browse requestを発行し、SourceからのCDS::Browse responseによってコンテンツ一覧情報(content list information)を引き取ることができる。同図に示すように、このレスポンス内では、コンテンツはitem IDとparentIDで識別され、コンテンツ毎に、コンテンツのタイトル、コンテンツのUPnP(登録商標)クラス、CDS::Browse requestに対するレスポンス情報が記載されている。そして、レスポンス属性情報(res protocolInfo property)の第3フィールドにコンテンツ毎のソケット情報(DTCP Socket Info)が記載されるとともに、別のレスポンス属性情報(res@allwedUse)でコンテンツがMOVE伝送可能かどうかを示すMovable情報が記載され、これらに続いてコンテンツの保管場所を示すURLが含まれている。なお、Movable情報の記載手段はこれに限定されることはなく、例えばDTCPでレスポンス属性情報を定義してこれを用いることも考えられる。可能なMOVE方法としてBLOCK MOVEとINCREMENTAL MOVEを個別に表現することも考えられる。
図9に示す例では、Sourceは、resのprotocolInfoアトリビュートの3番目のフィールドにソケット情報としての文字列“DTCP1HOST=(host);DTCP1PORT=(port)”を記載するとともに、allowedUseアトリビュートには当該コンテンツがDTCP−IPによりMOVE可能であることを示す文字列“MOVE:1”を記載している。したがって、Sinkは、図示のレスポンス中から、ユーザが選択したコンテンツに関するresタグ内のprotocolInfo並びにallowedUseの各アトリビュートの値を読み出すことで、コンテンツ毎のソケット情報と、コンテンツがMOVE伝送可能かどうかを取得することができる。
なお、res@allowedUseはDTCP規格で規定されているものではなく、“MOVE:1”の運用方法も詳細に定義されていないため、将来の定義内容にとっては不適切なものになるおそれがある。そこで、res@allowedUseに代えて、「DTCP.COM_FLAGS param」というパラメータをres@protocolInfoの第4フィールドに設けて、コンテンツのMOVE伝送の可否を示すことが考えられる。DTCP.COM_FLAGS paramは32ビット長のフィールドであり、ビット定義は以下の通りとする。ビット30に1が記載されているときには、ビット31にも1が記載される。Sinkは予備のビット・フィールドを無視する。
ビット31:DTCPに基づくMOVE伝送可。
ビット30:DTCP仕様書で規定されている条件を満足するBLOCK MOVEプロトコルをサポートしている。
ビット29〜0:予備
DTCP.COM_FLAGS paramはres@protocolInfoの第4フィールドに設けられ、32ビット値が16進数表記される。また、DTCP.COM_FLAGS paramを用いた場合のres@protocolInfoアトリビュートの記述例は以下の通りとなる。
Sinkは、1以上のSourceからCDS::Browseレスポンスを引き取ると、Sourceの選択(Select Source)、選択したSourceからMOVEすべきコンテンツの選択(Select Content)、並びに移動先の選択(Select Destination)を行なう。そして、Sink側でのコンテンツの選択に引き続いて、選択したコンテンツのMOVE伝送処理が開始される。
MOVE伝送に先駆けて、まずSourceとSink間の相互認証及びMOVE用の鍵共有を行なうために、MOVE用AKE手続きを実施する。ここでは、SinkからSourceへAKEトリガ情報が渡されるより前に、SourceはSinkからのAKEを受け付けられる状態になっているものとする。本実施形態では、通常のDTCP−IPにおけるAKE手続(前述並びに図4を参照のこと)と同様の手順に従ってSourceとSink間の相互認証と、コンテンツ復号鍵の元となる種鍵を共有するための処理を実行する。但し、MOVE実行時には、通常のコンテンツ伝送時とは異なる交換鍵KxMを生成し、且つ、1回のMOVE伝送毎に交換鍵を消滅させるようにしている。これによって、MOVE伝送をコピー伝送と偽装してコンテンツのコピー動作を行なうことをより困難にすることができる。
図10には、MOVE用AKE手続きの動作シーケンスを示している。図示のように、チャレンジ・レスポンス認証手続を用いて手続きが行なわれる。Sourceは、SinkからMOVE用のチャレンジ要求(MV−CHALLENGE)に応答して、1回のMOVE用AKE手続毎に、MOVE用の交換鍵KXMを生成し、後続のレスポンスを経て、SourceとSink間で鍵KXM及びKXM_labelの共有が実現する。但し、EXCHANGE KEYコマンドでは、通常のAKE手続の場合とは異なるスクランブル方法が適用され、MOVE伝送をコピー伝送と偽られるのを防止する。
鍵KXM及びKXM_labelの生成方法は、通常のコンテンツ伝送時(前述並びに図4を参照のこと)と同様なので、ここでは詳細な説明を省略する。また、鍵KXM及びKXM_labelを消滅させる規則も鍵KX及びKX_labelの場合と同様なので、説明を省略する。
SourceとSinkはともに、1回のMOVE手続が終了する度に、当該MOVE手続き用の鍵KXM及びKXM_labelを消滅させる。
図27には、MOVE用AKE手続きの他の動作シーケンス例を示している。図示の例では、Sinkは、MV−INITIATEコマンドを送信するというMOVEプロトコルを用いて、MOVE伝送を初期化して、MOVE RTT−AKEプロセスを起動する。RTT−AKEプロセスでは、通常のAKEと同じ手順を追って、チャレンジ−レスポンス手続きによる相互認証が行なわれる。RTTによればSink及びSourceのLocalizationチェックが行なわれるが、本発明の要旨には直接関連しない。そして、MV_EXCHANGE_KEYコマンドによって交換鍵の共有が行なわれる。
既に述べたように、本実施形態に係るコンテンツ伝送システムでは、コンテンツのMOVEモードとして、INCREMENTAL MOVEとBLOCK MOVEの2種類を備えている。INCREMENTAL MOVEはDTCP−IPで取り決められたMOVE伝送により実装することが可能である。これに対し、BLOCK MOVEは現在の仕様に含まれている訳ではない。そこで、例えばMOVE用AKE手続きを行なう際に、互いの機器がBLOCK MOVEに対応しているかどうか、すなわちケイパビリティを確認することが好ましい。
図16には、ケイパビリティの確認シーケンスを含んだMOVE用AKE手続きの動作シーケンス例を示している。図示の例では、MOVE用のチャレンジ・レスポンス認証手続きを行なう前に、SinkとSource間で互いのケイパビリティを交換する手続き(CAPABILITY_EXCHANGE)が実行される。
図17には、図16中のケイパビリティ交換手続きの部分をさらに詳細に示している。このコマンド/レスポンスに使用されるメッセージは、それぞれの機器が持つケイパビリティを記述したCAPABILITYフィールドと、CAPABILITYフィールドに対する電子署名で構成される。
メッセージの先頭1ビットはSink又はSourceを識別するために使用される。機器がSinkとしてのケイパビリティを送る場合には1を記載し、Sourceとしてのケイパビリティを送る場合には0を記載する。これによって、SourceとしてのケイパビリティのようにSinkとしてのケイパビリティを送り(あるいはその逆の振る舞いをし)、ケイパビリティの詐称をすることを防止する。CAPABILITYフィールドの末尾のフィールドを使って、機器がMOVE(若しくはBLOCK MOVE)に対応しているかどうかを記載する。
電子署名は、メッセージ先頭のSink/SourcビットとCAPABILITYフィールドに対して各機器の秘密鍵で求めた電子署名で構成される。CAPABILITY_EXCHANGEコマンドを受け取ったSourceは、Sinkの公開鍵を使って署名を検証し、CAPABILITY_EXCHANGEレスポンスを受け取ったSinkはSourceの公開鍵を使って署名を検証することができる。
例えば、SinkがBLOCK MOVEモードでのコンテンツのMOVEを要求するときに、まず、Sink側からCAPABILITY_EXCHANGEコマンドが発行され、これに対し、SourceからはCAPABILITY_EXCHANGEレスポンスが返される。いずれか一方の機器がBLOCK MOVEに対応していない場合には、従来のINCREMENTAL MOVEにモードを切り替えてコンテンツのMOVE処理を行なうようにしてもよい。
CAPABILITY_EXCHANGEシーケンスは、MOVE伝送モード詐称攻撃に対する対策として十分である。但し、この種の詐称攻撃に対する他の対策がとられている場合には、CAPABILITY_EXCHANGEシーケンスを通じたセキュアな情報交換手続は不要となる。
MOVE伝送用のAKE手続きが無事に完了すると、続いてコンテンツ移動(MOVE伝送)手続きが開始される。Sink側のユーザ操作によりSourceからコンテンツをMOVE伝送する場合、SourceがHTTPサーバとして動作するとともにSinkがHTTPクライアントとして動作し、HTTPプロトコルを用いてダウンロードMOVE伝送を行なうようにすれば良い。コンテンツのデータ・エンティティの伝送自体には、INCREMENTAL MOVEもBLOCK MOVEも同様に行なうことができるが、いずれの場合もHTTPプロトコルを使用することができる。すなわち、HTTPクライアントとしてのSinkはHTTP GETリクエストを用いてコンテンツを要求し、これに対し、HTTPサーバとしてのSourceはHTTP GETレスポンスを用い、コンテンツ選択フェーズで選択されたコンテンツのMOVE伝送を行なうことができる。GETは、特定のURIから情報を取得する際に、リクエストとして送信するHTTPメソッドである(周知)。
図28には、HTTPプロトコルを用いてコンテンツをダウンロードMOVE伝送する場合の動作シーケンスを例示している。例えば図27に示したMOVE RTT−AKE手続が無事に完了すると、HTTPクライアントとして動作するSinkは、HTTP GETリクエストを送信することによって、MOVE伝送プロセスを初期化する。
HTTPプロトコルを用いてコンテンツをダウンロードMOVE伝送するとき、Sourceは、E−EMIのモードをC1(すなわちMOVEモード(表1を参照のこと))に設定する。Sinkは、C1以外のE−EMIモードを受け取ったときには、受信したコンテンツをMOVE対象として扱わない。
Sinkは、HTTPのGETリクエストのヘッダに“MOVE.dtcp.com:<KxM_label>”(若しくは、“MOVE.dtcp.com”ではなく“BLKMOVE.dtcp.com”)というヘッダ情報を設定したHTTP GETリクエストを送信して、ダウンロードMOVE伝送を開始する。Sourceは、このヘッダ情報を検知したら、リクエストされたコンテンツを鍵IDであるKxM_labelに対応するMOVE用の鍵KXMから得た暗号鍵Kcで暗号化し、E−EMIをC1に設定してGETレスポンスとして伝送する。
図14A及び図14Bには、HTTPサーバとしてのSourceからHTTPクライアントとしてのSinkへコンテンツをダウンロードMOVE伝送する場合のSource及びSinkがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
Sinkは、HTTPサーバとして動作するSourceを発見して、そこからコンテンツをMOVEすることを選択すると(ステップS21)、当該Source宛てにCDS::Browse requestを送信し(ステップS22)、Sourceからのレスポンスを待機する(ステップS23)。
Source側では、SinkからのCDS::Browse request又はその他のリクエストの受信を待機しており(ステップS1)、当該リクエストを受信すると、Sinkに対してCDS::Browse responseを返信し(ステップS2)、MOVE用のAKE要求を受信するまで待機する(ステップS3)。
Sinkは、SourceからのCDS::Browse responseによってコンテンツ一覧を引き取ると、MOVEしようとするコンテンツを決定するとともに(ステップS24)、Sourceに対してMOVE用のAKE処理を要求する(ステップS25)。
そして、SinkとSource間では、MOVE用のAKE手続きが開始され、互いにMOVE用のAKE処理を実行する(ステップS4、S26)。MOVE用のAKEの認証に成功すると(ステップS5、S27)、SourceはMOVE用の鍵と鍵IDを生成してSinkに送信し(ステップS6)、SinkはSourceからMOVE用の鍵と鍵IDを受信する(ステップS28)。但し、SourceとSink間でMOVE用のAKEの認証に失敗すると、SourceとSinkはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
Sinkは、MOVE用AKE手続きを成功裏に終えると、 “MOVE.dtcp.com:<KxM_label>”(若しくは、“MOVE.dtcp.com”ではなく“BLKMOVE.dtcp.com”)というヘッダ情報を伴った、HTTP GETリクエストを送信する(ステップS29)。
Sourceは、SinkからMOVE用ヘッダを伴うHTTP GETリクエストを受信すると(ステップS7)、当該リクエストで要求されているコンテンツが他のSinkに対してMOVEしている最中かどうかをチェックする(ステップS8)。そして、MOVE伝送中であれば、エラー応答をSinkに返す(ステップS15)。
Sink側では、SourceからのHTTP GETレスポンスの受信を待機する(ステップS30)。この受信待機中に、要求したコンテンツをMOVEできない旨のエラー応答をSourceから受信すると(ステップS31)、ここで本処理ルーチン全体を終了する。
また、Sourceは、SinkからMOVE要求されているコンテンツが他のSinkに対してMOVE伝送中ではなく、当該Sinkに対してMOVE伝送することができるときには、当該コンテンツに対して「MOVE伝送中」フラグをセットしてから(ステップS9)、当該コンテンツをMOVE用の鍵を用いて暗号化して、要求元Sink宛てに送信する(ステップS10)。「MOVE伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、暗号化コンテンツの伝送処理を終了すると、SinkからのMOVE終了処理の要求の受信を待機する(ステップS11)。
Sinkは、Sourceから暗号化コンテンツを成功裏にダウンロードすることができたならば(ステップS32)、Sourceに対してMOVE終了処理の要求を送信する(ステップS33)。そして、SourceとSinkは、それぞれMOVE終了処理手続きを実行して(ステップS12、S34)、Sink側でコンテンツを有効化するとともに、Source側の元のコンテンツを削除する。Source及びSink間におけるMOVE伝送終了処理手続きの動作シーケンスの詳細については後述に譲る。
そして、SourceとSinkは、MOVE終了処理手続きを完了すると(ステップS13、S35)、いずれもMOVE用の鍵と鍵IDを破棄して(ステップS14、S36)、本処理ルーチン全体を終了する。
図14A及び図14Bに示したダウンロードMOVE処理手続きの期間中、MOVE対象となるコンテンツを他のSinkからMOVE要求できないようにロックして、多重MOVEの発生を防止する。ダウンロードによりMOVEを行なう場合、Sourceはサーバに相当するが、保持する個々のコンテンツについてMOVE伝送中であるかどうかを、例えば下記の表2に示すようなテーブルを使って管理する。同表では、コンテンツを特定するURIと、それがMOVE伝送中かどうかを示すフラグを関係付けて、コンテンツの状態を確認することができるようになっている。また、Sourceは、ダウンロードによりコンテンツのMOVEを要求する他のSinkに対して、CDS::Browse responseでMOVE伝送中のコンテンツについては存在を示さないことで、混乱を防止することができる(視聴途中でのMOVE完了による伝送中断など)。
また、Sinkは、BLOCK MOVEモードでダウンロードMOVE伝送処理が行なわれている期間中は、コンテンツはまだ有効化されていないので、リアルタイムでレンダリングする以外の目的で受信したコンテンツを利用することはできない。リアルタイム・レンダリングの仕組みについては、図7を参照しながら既に説明したので、ここでは説明を省略する。
なお、MOVE用AKE手続き並びにコンテンツ移動(MOVE)手続きの期間中には、MOVE伝送を途中で取り止めるCancelやAbortといった中断処理が起動することがあるが、この点の詳細については後述に譲る。
SinkがHTTPプロトコルのGETリクエストにより、選択したSourceから所望のコンテンツを成功裏にダウンロードすることができたならば、SinkとSource間でコンテンツ伝送が無事に終了したことの確認すなわちCommitmentを行なうためのMOVE終了処理手続きを実施する。この終了処理では、Sink側ではこのダウンロードしたコンテンツを有効化すると同時に、Source側では元のコンテンツの削除を行なう。また、SinkとSourceはそれぞれ、コンテンツ伝送に使用した交換鍵の削除を行なう。BLOCK MOVEモードでは、このようなCommitmentを実施することで、コンテンツ全体を一括してSourceとSink間で移動することと等価なMOVE処理を実現することができる。BLOCK MOVEも、SourceとSinkで同じコンテンツが二重に存在することはないから、DTCPで規定されている条件を満たしたコンテンツのMOVE処理であると言える。
図11には、Source及びSink間でMOVE終了処理手続きを実行する動作シーケンスを示している。図示の動作シーケンスは、図14Bに示したフローチャートのステップS12並びにS34において実施される。
Sinkは、MOVE対象となるコンテンツを無事に受信し終えると、Sourceからレスポンスを受け取るまで、MOVE終了処理用コマンドCMD1(若しくはMV_FINALIZEコマンド)を送信し続ける。
一方、Sourceは、MOVE終了処理用コマンドCMD1を受信すると、MOVE終了処理用レスポンスRSP1を返信する。また、Sourceは、有効状態(Valid)であった元のコンテンツを、中間的(interim)な無効状態(Invalid)に遷移させる。
Sinkは、受信したRSP1において、Sourceが既にMOVE処理手続を終了していると記載されていれば、同様にMOVE処理手続を終了する。これに伴って、SourceからMOVEしたコンテンツを無効状態から有効状態に遷移させる。
続いて、Sinkは、Sourceからレスポンスを受け取るまで、次のMOVE終了処理用コマンドCMD2(若しくは、MV_COMPLETEコマンド)を送信し続ける。これに対し、Sourceは、元のコンテンツを中間的な無効状態から完全な無効状態に遷移させてから、MOVE終了処理用レスポンスRSP2を返信する。
図18には、図11に示したダウンロードMOVE伝送終了シーケンス上でSink及びSourceがそれぞれ実施する処理内容をフローチャートの形式で具体的に示している。
Sink側では、まず乱数Rを生成し(ステップS81)、この乱数Rに対し所定の演算処理を適用して、メッセージ・ダイジェストMAC5A及びMAC6Aを計算する。MAC5AはSourceに渡す値、MAC6AはSourceから返されることが期待される値である。MAC5A及びMAC6Aの計算式は、例えば以下の通りである。この計算には、KxM_labelに対応するKxMが使用される。
続いて、Sinkは、鍵IDであるKxM_labelと乱数R、MAC5A、MAC6A、MOVEしたコンテンツのID、SourceのIDを不揮発的に格納する(ステップS82)。これらのデータを不揮発的に格納しておくことにより、電源遮断などによりコンテンツ伝送終了処理が途切れても、再開処理が可能となり、SinkとSourceの双方でコンテンツが無効になることを避けることができる。
そして、Sinkは、KxM_labelと乱数R、MAC5Aを含んだMOVE終了用コマンドCMD1(若しくは、MV_FINALIZEコマンド)をSourceに送信する。Sinkは、Sourceからレスポンスを受け取るまでは、受信タイムアウトが発生する度にCMD1を送信し続ける(ステップS83)。
一方、Sourceは、MOVE用コマンドCMD1を受け取ると、これに含まれる乱数Rに対し所定の演算処理(同上)を適用して、メッセージ・ダイジェストMAC5B及びMAC6Bを計算する。MAC6BはSinkに渡す値、MAC5BはSinkから得られることが期待される値である。そして、Sourceは、CMD1に含まれるMAC5Aと、自ら求めたMAC5Bを照合して、コマンドの真正性をチェックする(ステップS91)。このチェックに失敗したときには、コンテンツ伝送終了処理を中止(Abort)する。但し、Sourceは自身のソケット情報が途中で変化したことが原因でSinkがCMD1の送信先を誤った可能性がある場合は、処理を中止せずにCMD1を待ち続けても良い。
また、Sourceは、真正性のチェックに成功したときには、鍵IDであるKxM_labelとMAC6B、MOVEしたコンテンツのIDを不揮発的に格納する(ステップS92)。これらのデータを不揮発的に格納しておくことにより、電源遮断などによりコンテンツ伝送終了処理が途切れても、再開処理が可能となり、SinkとSourceの双方でコンテンツが無効になることを避けることができる(同上)。
そして、Sourceは、有効状態であった元のコンテンツを、中間的な無効状態に遷移させてから(ステップS93)、CMD1を受理したこと(Accepted)を示すMOVE終了処理用レスポンスRSP1を返信する。
Sinkは、SourceからMOVE終了処理用レスポンスRSP1を受信すると、CMD1が拒絶(Rejected)されていないかどうかをチェックする(ステップS84)。RSP1がAcceptedを示している場合には、さらにRSP1に含まれるMAC6Bが自ら保持しているMAC6Aと一致するかどうかをチェックする(ステップS85)。そして、これらのチェックに成功すると、SourceからMOVEしたコンテンツを無効状態から有効状態に遷移させる(ステップS86)。
続いて、Sinkは、鍵IDであるKxM_labelを含んだMOVE終了用コマンドCMD2(若しくは、MV_COMPLETEコマンド)をSourceに送信する。Sinkは、Sourceからレスポンスを受け取るまでは、受信タイムアウトが発生する度にCMD2を送信し続ける(ステップS87)。
Sourceは、MOVE終了処理用コマンドCMD2を受信すると、これに含まれるKxM_labelに対応するデータを削除する(ステップS94)。ここで言うデータとは、ステップS92で不揮発的に格納しておいたKxM_labelとMAC6B、MOVEしたコンテンツのIDのことである。そして、Sourceは、MOVE終了処理用レスポンスRSP2を返信する。
Sinkは、MOVE終了処理用レスポンスRSP2を受信すると、これに含まれるKxM_labelに対応するデータを削除する(ステップS88)。ここで言うデータとは、ステップS82で不揮発的に格納しておいたKxM_labelと乱数R、MAC5A、MAC6A、コンテンツのID、SourceのIDのことである。
ダウンロードMOVE伝送が終了した後にSink側でコンテンツを有効化する方法は特に限定されない。有効化すると、Sink内のコンテンツ記録ブロックでNo More Copiesとして符号化して記録されたコンテンツの利用が可能となる(例えば、記録時に適用した暗号の解除が可能となる)。この結果、コンテンツ再生ブロック31に符号化コンテンツを供給して、ビデオ及びオーディオ信号に変換(rendering)して、ディスプレイなどのAV出力部から映像並びに音響出力することができる。また、Sinkは、今度はSourceとしてさらに別のSinkに対して、No more Copiesコンテンツを上述と同様にダウンロード形式でMOVEしたり、あるいは後述するアップロード形式でMOVEしたりすることもできる。
また、ダウンロードMOVE伝送が終了した後にSource側で元のコンテンツを削除する方法も特に限定されない。コンテンツを格納したハード・ディスクなどの記録媒体からコンテンツ・データのエンティティ自体を削除する以外に、符号化(暗号化)して記録されているコンテンツのエンティティは残すが復号鍵を再び使用できないようにするのであってもよい。
ここで、SourceからSinkへコンテンツのエンティティが成功裏にダウンロードMOVE伝送されたにも拘らず、一方の機器の電源遮断などにより図11に示したダウンロードMOVE伝送の終了処理シーケンスが途切れてしまう可能性がある。このような場合、ダウンロードMOVE伝送の終了処理の中断(interrupted)によって、Source及びSinkの双方において移動したコンテンツを利用できなくなるおそれがある。そこで、本実施形態に係るコンテンツ伝送システムでは、このような事態に備えて、コンテンツ伝送終了処理を再開するための処理手続きを設けて、Comminmentを無事に終了させるようにしている。この再開手続きによって、コンテンツ伝送手続きが無駄にならずに済むとともに、SinkとSourceの双方でコンテンツが無効になることを避けることができる。
ダウンロードMOVE伝送の終了処理の再開を可能にするために、Sink及びSourceの各々では、ダウンロードMOVE伝送の終了処理を開始する際に、NVRAMなどの不揮発性メモリを用いて、再開処理に必要となるデータを保存するようにしている。Sink側では、CMD1すなわちMV_FINALIZEコマンドを発行する際に、そのコマンドで送信するKXM_lable、乱数R、MAC5A、さらにMAC6A、ダウンロードMOVEしたコンテンツのID(CDSのオブジェクトIDに相当)、SourceのID(UPnP(登録商標)のUUIDに相当)を不揮発的に格納する(図18中のステップS82を参照)。一方、Source側では、鍵IDであるKxM_labelとMAC5B、MAC6Bを不揮発的に格納する(図18中のステップS92を参照)。再開処理は、基本的にはSink側が起動する。
Sinkは、UPnP Device Architectureで規定されているUUIDを記憶しておくことにより、CDS処理のクエスト先であるSourceを発見することが可能であり、また、UPnP AV CDS2で規定されているObject IDを記憶しておくことにより、MOVE対象コンテンツを指定することが可能である。そして、中断したMOVE処理を再開する際、Sinkは、最初にコンテンツを選択するときと同様にUPnP(登録商標)のCDSの処理をすることで、MOVE対象となるコンテンツに対するソケット情報を得ることができる。例えばSourceが電源遮断して、再開時にそのIPアドレスが変更してしまっても問題はない。
Sinkは、MOVE対象コンテンツのソケット情報を得ると、続いて、該当するSourceとのTCPコネクションを確立する。図29には、MOVE伝送終了処理を再開する際に、Sink及びSource間でTCPコネクションを確立するための処理手順をフローチャートの形式で示している。
Sinkは、不揮発に記憶しているSourceID(UUID)を1つ選択すると(ステップS131)、UPnPのデバイス発見のプロトコル(SSDP)により、同じUUIDを持つ機器が存在するかどうかをチェックする(ステップS132)。ここで、同じUUIDを持つ機器が存在しなければ、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
一方、同じUUIDを持つ機器が存在する場合には(ステップS132のYes)、その機器に対してCDS::BrowseリクエストをObject ID指定付きで送信する(ステップS133)。
Sourceは、SinkからCDS::Browseリクエストを受信すると(ステップS141)、該当するコンテンツについてコンテンツ伝送終了処理が完了していない旨の情報を含んだCDS::Browseレスポンスを返信する(ステップS142)。
なお、コンテンツ伝送終了処理が完了していないということは、例えばコンテンツがMovableであることを示す属性情報を含めない、あるいはHTTP GETリクエストを送るべきURLを含めない、MOVE処理を実行中という属性情報を含める、といった方法で示すことができる。
そして、Sinkは、CDS::Browseレスポンスを受信すると(ステップS134)、当該メッセージに含まれるソケット情報を参照して、CMD1、CMD2などのAKEコマンド用のTCPコネクションを確立する(ステップS135)。
Sinkは、このようにしてAKEコマンド用のTCPコネクションを確立すると、不揮発的に格納しておいた鍵IDであるKxM_labelと乱数R、MAC5Aを参照して、CMD1(MV_FINALIZEコマンド)又はCMD2(MV_COMPLETEコマンド)をSourceに送信する。これに対し、Sourceは、同様に不揮発的に格納しておいたKxM_labelとMAC6Bを用いてCMD1に対するレスポンスRSP1又はCMD2に対するレスポンスRSP2を返す。これによって、SinkとSource間のダウンロードMOVE伝送の終了処理を完結することができる。
図19には、図11並びに図18に示したダウンロードMOVE伝送の終了処理シーケンスが何らかの原因により中断(interrupted)した後、SourceがSinkからMOVE終了処理用コマンドCMD1を受け取ったときの処理手順をフローチャートの形式で示している。
Sourceは、MOVE終了処理用コマンドCMD1に含まれるKxM_labelを自分が不揮発的に格納しているかどうかをチェックする(ステップS101)。
ここで、KxM_labelを保持していないときには、Sourceは既に該当するコンテンツ伝送終了処理を完了しているか、又はCMD1が自分とは無関係であることが想定されるので、当該コマンドを拒絶すること(Rejected)を示すMOVE終了処理用レスポンスRSP1を返す(ステップS104)。
一方、KxM_labelを保持しているときには、該当するコンテンツ伝送終了処理が中断していたことになるので、Sourceは、CMD1内のコンテンツIDで示される元のコンテンツを中間的な無効状態に遷移させてから(ステップS102)、CMD1を受理したこと(Accepted)を示すMOVE終了処理用レスポンスRSP1を返信する(ステップS103)。このようにして、中断したMOVE終了処理をHTTPサーバとして動作するSourceにおいて再開することができる。
また、図20には、図11並びに図18に示したダウンロードMOVE伝送の終了処理シーケンスが何らかの原因により中断(interrupted)した後、SourceがSinkからMOVE終了処理用コマンドCMD2を受け取ったときの処理手順をフローチャートの形式で示している。
Sourceは、MOVE終了処理用コマンドCMD2に含まれる鍵IDであるKxM_labelを自分が不揮発的に格納しているかどうかをチェックする(ステップS111)。
ここで、KxM_labelを保持しているときには、該当するコンテンツ伝送終了処理が中断していたことになるので、Sourceは、KxM_labelに対応付けて格納されているデータ(すなわち、MAC6B、MOVEしたコンテンツのID)を削除し(ステップS112)、CMD2を受理したこと(Accepted)を示すMOVE終了処理用レスポンスRSP2を返信する(ステップS113)。
一方、KxM_labelを保持していないときには、Sourceは既に該当するコンテンツ伝送終了処理を完了しているか、又はCMD2が自分とは無関係であることが想定されるので、ステップS112をスキップし、CMD2を受理したこと(Accepted)を示すMOVE終了処理用レスポンスRSP2を返信する(ステップS113)。このようにして、中断したMOVE終了処理をHTTPサーバとして動作するSourceにおいて再開することができる。
また、図21には、図11並びに図18に示したダウンロードMOVE伝送の終了処理シーケンスが何らかの原因により中断(interrupted)した後、SinkがMOVE終了処理を再開させるための処理手順をフローチャートの形式で示している。
Sinkは、ステップS82において不揮発的に格納したデータ、すなわち鍵IDであるKxM_labelと乱数R、MAC5A、MAC6A、コンテンツID、SourceIDが存在していることを検出すると(ステップS121)、これはコンテンツ伝送終了処理が中断して、SourceとのCommitmentが完了せずに、これらのデータが消去されずに残っていることが分かる。
この場合、コンテンツ伝送終了処理を再開するために、該当するSourceとのTCPコネクションを確立する(ステップS122)。
そして、コンテンツIDで示されるコンテンツが無効状態かどうかをチェックする(ステップS123)。
コンテンツが無効状態のままであれば(ステップS123のYes)、SourceからMOVE終了処理用レスポンスRSP1を受け取る前にコンテンツ伝送終了処理が中断したことになるので、図18に示したフローチャートの#1にジャンプして(ステップS124)、SourceとのCommitmentを開始する。
コンテンツが既に有効状態となっていれば(ステップS123のNo)、SourceからCommitmentを得た後でMOVE終了処理用レスポンスRSP2を受け取る前にコンテンツ伝送終了処理が中断したことになるので、図18に示したフローチャートの#2にジャンプして(ステップS125)、Sourceに対するMOVE終了処理用コマンドCMD2の送信を行なう。このようにして、中断したMOVE終了処理をHTTPクライアントとして動作するSinkにおいて再開することができる。
図19〜図21に示したようなMOVE伝送シーケンスの再開処理によって、コンテンツ伝送手続きが無駄にならずに済むとともに、SinkとSourceの双方でコンテンツが無効になることを避けることができる。
Sourceは、MOVE終了処理用レスポンスRSP2を返信するか、又は無効化すべきというユーザの指示入力に応答して、元のコンテンツを中間的な無効状態から完全な無効状態に遷移させる。
C−2.アップロード形式のBLOCK MOVE
図12には、アップロード形式でSourceとSink間のBLOCK MOVE伝送を行なう場合の動作シーケンスを示している。この場合のMOVE伝送もダウンロードと同様に、Sink及びコンテンツ選択、MOVE用AKE手続き、コンテンツ移動(MOVE)手続き、MOVE終了処理手続きという4段階のフェーズで構成される。このうち、MOVE用AKE手続き、コンテンツ移動(MOVE)手続き、MOVE終了処理手続きは、DTCP上で規定される手順に従って実行される。
Sink及びコンテンツ選択のフェーズでは、ユーザは、Source側で、MOVEしたいコンテンツの選択(Select Content)と、コンテンツの伝送先となるSinkの選択(Select Sink & Destination)を行なってから、該当するSinkに対して、DTCP MOVEとして伝送するコンテンツに関する認証及び鍵交換用のソケット情報を通知する。そして、これに引き続いて、選択したコンテンツのMOVE処理が開始する。
SourceからSinkに対する通知は、UPnP(登録商標)ベースでCDSを用いて行なうことができる。図13には、この場合のSourceとSink間の動作シーケンスを示している。
まず、Sourceは、Sinkに対してアップロードMOVE伝送を要求するときには、伝送しようとするコンテンツの保管場所を作成するよう、CDS::CreateObjectリクエストを発行する。Sourceは、このCDS::CreateObjectリクエスト内で、MOVEしようとするコンテンツ毎に、コンテンツのタイトル、コンテンツのUPnP(登録商標)クラス、認証及び鍵交換用のソケット情報並びにDTCP−IPのMOVE手続きによってコンテンツ伝送を行なうことを記載する。なお、コンテンツ特定用のitem ID、parentID、コンテンツのURIはリクエストで不定となり、HTTPサーバであるSinkが決定し、CDS::CreateObjectレスポンスによってHTTPクライアントであるSourceに通知する。図13に示す例では、Sourceは、resのprotocolInfoアトリビュートの第3フィールドにソケット情報としての文字列“DTCP1HOST=(host);DTCP1PORT=(port)”を記載するとともに、当該コンテンツをDTCP−IPのMOVE伝送シーケンスによって伝送することを示す文字列“DTCPOP=MOVE”を記載している。
なお、res@protocolInfoの中にDTCPOPなど、アップロード時に一時的に使用する属性情報を含めると、Sinkは自身がHTTPサーバとしてCDS::Browseリクエストへの応答でres@protocolInfoを送る際にはその属性情報を取り除く必要があり、処理が煩雑になる。そこで、属性情報をprotocolInfoとは独立して新たなアトリビュートで送る方法も考えられる。具体的には、res@dtcp:uploadInfoアトリビュートというものを設けて、コンテンツのMOVE伝送の可否を示すことが考えられる。res@dtcp:uploadInfoアトリビュートは32ビット長のフィールドであり、ビット定義は以下の通りとなっている。ビット30に1が記載されているときには、ビット31にも1が記載される。Sinkは予備のビット・フィールドを無視する。
ビット31:DTCPに基づき、MOVEとして伝送する。
ビット30:DTCP仕様書に規定されている条件を満足するBLOCK MOVEプロトコルを使用する。
ビット29〜0:予備
res@dtcp:uploadInfoアトリビュートの32ビットは16進数表記される。CDS::CreateObjectリクエスト中のres@dtcp:uploadInfoアトリビュートの記述例は以下の通りとなる。
Sinkは、CDS::CreateObjectリクエストを受け取ると、コンテンツの伝送元となるSource側の認証及び鍵交換用のソケット情報と、コンテンツがMOVEとして伝送されるのかどうかを識別することができる。そして、Sinkは、SourceからのアップロードMOVE伝送要求を受け容れるときには、コンテンツの保管場所(すなわちインポート先)をローカルの記憶領域に作成するとともに、この保管場所の情報を含んだCDS::CreateObjectレスポンスを要求元のSourceに返す。図13に示す例では、Sinkはres@protocolInfoアトリビュート内のimportUriアトリビュートにMOVE対象となるコンテンツのインポート先を示す文字列“http://1.2.3.4:50000/import?id=6”を記載している。あるいは、res@dtcp:uploadInfoアトリビュートを用いてMOVE伝送の可否を示す場合には、CDS::CreateObjectレスポンスの記述例は以下の通りとなる。
このようにして、Sourceは、SinkからエラーでないCDS::CreateObjectレスポンスを受け取って、Sink宛てにコンテンツのMOVEが可能であると確認し、コンテンツの保管場所を確保すると、これに引き続いて、選択したコンテンツのアップロードMOVE伝送処理が開始される。
MOVE伝送に先駆けて、まずSourceとSink間の相互認証及びMOVE用の鍵共有を行なうために、MOVE用AKE手続きを実施する。MOVE用AKE手続きの動作シーケンスは、図10、並びに図16〜17を参照しながら既に説明した通りなので、ここでは説明を省略する。但し、MV−CHALLENGEコマンドでは、通常のAKE手続の場合とは異なるスクランブル方法が適用され、MOVE伝送をコピー伝送と偽られるのを防止する(同上)。
あるいは、MOVE用AKE手続きには、図27に示したような動作シーケンスを使用することができる。この場合、Sinkは、MV−INITIATEコマンドを送信するというMOVEプロトコルを用いて、ダウンロードMOVE伝送を初期化して、MOVE RTT−AKEプロセスを起動する。RTT−AKEプロセスでは、通常のAKEと同じ手順を追って、チャレンジ−レスポンス手続きによる相互認証が行なわれる。そして、MV_EXCHANGE_KEYコマンドによって共有鍵の交換が行なわれる(同上)。
そして、MOVE伝送用のAKE手続きが無事に完了すると、続いてコンテンツ移動(MOVE)手続きが開始される。Source側のユーザ操作によりSinkへコンテンツをMOVE伝送する場合、SourceがHTTPクライアントとして動作するとともにSinkがHTTPサーバとして動作し、HTTPプロトコルを用いてアップロードMOVE伝送を行なうようにすれば良い。すなわち、HTTPクライアントとしてのSourceはHTTP POSTリクエストを送信し、これに対し、HTTPサーバとしてのSinkはHTTP POSTレスポンスを返信することにより、コンテンツ選択フェーズで選択されたコンテンツをSourceからSinkへアップロードMOVE伝送する。POSTは、特定のURIに対して情報を送信するための、リクエストとして送信するHTTPメソッドである(周知)。
HTTPプロトコルを用いてコンテンツをアップロードMOVE伝送するとき、Sourceは、E−EMIのモードをC1(すなわちMOVEモード(表1を参照のこと))に設定する。Sinkは、C1以外のE−EMIモードを受け取ったときには、受信したコンテンツをMOVE対象として扱わない(同上)。
Sourceは、HTTPのPOSTリクエストのヘッダに“MOVE.dtcp.com:<KxM_label>”(若しくは、“MOVE.dtcp.com”ではなく“BLKMOVE.dtcp.com”)というヘッダ情報を設定したHTTP POSTリクエストを送信して、アップロードMOVE伝送を開始する。そして、Sourceは、リクエストしたコンテンツをKxM_labelに対応するMOVE用の鍵KXMから得た暗号鍵Kcで暗号化し、E−EMIをC1に設定して後続のPOSTリクエストとして伝送する。
図15A及び図15Bには、HTTPクライアントとしてのSourceからHTTPサーバとしてのSinkへコンテンツをアップロードMOVE伝送する場合のSource及びSinkがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
Sourceは、コンテンツのアップロード先のサーバとして動作するSinkを発見すると(ステップS41)、Sinkに対してコンテンツの保管場所の作成を要求するべく、CDS::CreateObject requestを送信して(ステップS42)、そのレスポンスの受信を待機する(ステップS43)。
Sinkは、SourceからCDS::CreateObject requestを受信すると(ステップS61)、これに対するレスポンスを返信する(ステップS62)。
Sourceは、SinkからCDS::CreateObject responseを受信すると、続いてMOVEするコンテンツを決定し(ステップS44)、MOVE用のAKE要求を受信するまで待機する(ステップS45)。
Sinkは、CDS::CreateObject responseを送信した後、Sourceに対してMOVE用のAKE処理を要求する(ステップS63)。
そして、SinkとSource間では、MOVE用のAKE手続きが開始され、互いにMOVE用のAKE処理を実行する(ステップS46、S64)。MOVE用のAKEの認証に成功すると(ステップS47、S65)、SourceはMOVE用の鍵と鍵IDを生成してSinkに送信し(ステップS48)、SinkはSourceからMOVE用の鍵と鍵IDを受信する(ステップS66)。但し、SourceとSink間でMOVE用のAKEの認証に失敗すると、SourceとSinkはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
続いて、Sourceは、Sinkに対してMOVEによりアップロードしようとするコンテンツに対して「MOVE伝送中」フラグをセットしてから(ステップS49)、当該コンテンツをMOVE用の鍵を用いて暗号化し、“MOVE.dtcp.com:<KxM_label>”というヘッダ情報を伴ったHTTP POSTリクエストにより、暗号化コンテンツを送信する(ステップS50)。「MOVE伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、SinkからのHTTP POSTレスポンスの受信を待機する(ステップS51)。
Sink側では、MOVE用のAKE手続きを終えると、SourceからのHTTP POSTリクエストを受信待機している(ステップS67)。そして、当該リクエストを受信して、暗号化コンテンツをすべて受け取ると、HTTP POSTレスポンスを返信する(ステップS68)。
このようにして、SourceからSinkへ暗号化コンテンツを成功裏にアップロードすることができたならば、SourceはMOVE終了処理の受信を待機する(ステップS52)。また、Sinkは、Sourceに対してMOVE終了処理の要求を送信する(ステップS69)。そして、SourceとSinkは、それぞれMOVE終了処理手続きを実行して(ステップS53、S70)、Sink側でコンテンツを有効化するとともに、Source側の元のコンテンツを削除する。Source及びSink間におけるMOVE終了処理手続きの動作シーケンスは図11並びに図18を参照して既に説明した通りなので、ここでは説明を省略する。
そして、SourceとSinkは、MOVE終了処理手続きを完了すると(ステップS54、S71)、いずれもMOVE用の鍵と鍵IDを破棄して(ステップS55、S72)、本処理ルーチン全体を終了する。
図15A及び図15Bに示したアップロードMOVE処理手続の期間中、MOVE対象となるコンテンツを他のSinkからMOVE要求できないようにロックして、多重MOVEの発生を防止する。アップロード形式でコンテンツのMOVEを行なう場合、Sinkは、サーバに相当するが、保持する個々のコンテンツについてMOVE伝送中であるかどうかを、例えば表2(前述)に示したようなテーブルを使って管理することができる(同上)。
また、Sinkは、BLOCK MOVEモードでアップロードMOVE伝送処理が行なわれている期間中は、コンテンツはまだ有効化されていないので、リアルタイムでレンダリングする以外の目的で受信したコンテンツを利用することはできない。リアルタイム・レンダリングの仕組みについては、図7を参照しながら既に説明したので、ここでは説明を省略する。
なお、MOVE用AKE手続き並びにコンテンツ移動(MOVE)手続きの期間中には、MOVE伝送をユーザ操作で取り止める取り消し(Cancel)や中止(Abort)といった中断処理が起動することがあるが、この点の詳細については後述に譲る。
そして、SourceがHTTPプロトコルのPOSTリクエストにより、HTTPサーバとして動作する所定のSinkに対して所望のコンテンツを成功裏にアップロードすることができたならば、アップロードMOVE伝送の終了処理手続きを実施して、Sink側ではこのアップロードしたコンテンツを有効化すると同時に、Source側では元のコンテンツの削除を行なう。MOVE終了処理手続きは、図11並びに図18に示したものと同様の動作シーケンスに従って実行される(同上)。
アップロードMOVE伝送が終了した後にSink側でコンテンツを有効化する方法は特に限定されない。有効化すると、Sink内のコンテンツ記録ブロックでNo More Copiesとして符号化して記録されたコンテンツの利用が可能となる(例えば、記録時に適用した暗号の解除が可能となり)。この結果、コンテンツ再生ブロックに符号化コンテンツを供給して、ビデオ及びオーディオ信号に変換(rendering)して、ディスプレイなどのAV出力部から映像並びに音響出力することができる。あるいは、今度はSourceとして、さらに別のSinkに対して、上述と同様にダウンロード又はアップロード形式でMOVEすることもできる。
また、アップロードMOVE伝送が終了した後にSource側で元のコンテンツを削除する方法も特に限定されない。コンテンツを格納したハード・ディスクなどの記録媒体からコンテンツ・データのエンティティ自体を削除する以外に、符号化(暗号化)して記録されているコンテンツのエンティティは残すが復号鍵を再び使用できないようにするのであってもよい。
なお、Sinkは、コンテンツをSourceからアップロードMOVE伝送した後に、今度は自らSourceとしてコンテンツを提供しようとする場合は、resタグ内のDTCPOP=MOVEを削除する(若しくはres@dtcp:uploadInfoアトリビュートを削除する)とともに、ソケット情報のホスト名とポートを自らのものに変更する必要がある。また、他のSinkにコンテンツを持ち出す(MOVE out)ことを許容する場合には、resタグ内にMOVE可能であることを示す文字列“MOVE:1”を記載したallowedUseアトリビュートを追加する(若しくは、上記のDTCP.COM_FLAGS paramをres@protocolInfoアトリビュートの第4フィールドに追加する)。
図13に示した動作シーケンスでは、Sink側でMOVE用AKE手続きのためのTCPコネクションを確立するために必要となるソケット情報(DTCP socket Info)を、SourceはCDS::CreateObjectリクエストによって通知している。ところが、この通知方法では、中断したMOVE伝送終了手続きを再開する際には、ソケット情報の通知のために、同じコンテンツのアップロードMOVE伝送を要求するCDS::CreateObjectリクエストを再び発行しなければならず、1回のみMOVE伝送を許可するというDTCP規格に抵触するおそれがある。
そこで、本発明者らは、図13に示した動作シーケンスによる通知方法以外に、CDS::CreateObjectの処理後に、MOVE用AKE手続きを行なうのに先立ち、HTTP POSTリクエストのヘッダにソケット情報(DTCP socket Info)を記載して、SourceからSinkへソケット情報を通知する方法について提案する。例えば、Content−Typeヘッダを使って、以下のように記載する。
SinkはAKE手続きが完了するまでコンテンツの暗号を解けないので、SourceはこのPOSTリクエストではまだコンテンツを伝送せず、AKE手続きの完了後に伝送するという手順が考えられる。すなわち、ソケット情報を通知するHTTP POSTリクエストは、コンテンツを伴わなくても良く、また、図13とは相違し、CDS::CreateObjectではソケット情報を送る必要はない。
図30には、SourceがPOSTリクエストを用いてソケット情報を通知する方法を用いる場合において、SourceとSink間でアップロードMOVE伝送を行なうための動作シーケンスを示している。
まず、Sourceは、CDS::CreateObjectリクエストを用いて、Sinkに対して、コンテンツの移動先となるオブジェクトの作成を要求する。このとき、Sourceは、res@uploadInfoアトリビュートにおいてMOVE伝送をベースにしたトランザクションを要求する。これに対し、Sinkは、CDS::CreateObjectレスポンスのres@importUriアトリビュートにおいて、HTTP POST用のURIを返す。
続いて、Sourceは、CDS::CreateObjectレスポンスの記載内容から取得したURIに対するHTTP POSTリクエストを送信して、Sinkに対して認証及び鍵交換用のソケット情報を通知する。ソケット情報は、上述したように、ContentTypeとして送られてくる。但し、ソケット情報の通知に使用されるHTTP POSTリクエストは、コンテンツを含まない。
Sinkは、ソケット情報を取得すると、認証及び鍵交換用のTCPコネクションを確立する。そして、Sinkは、MV−INITIATEコマンドを送信してMOVE RTT−AKEプロセスを起動することによって、アップロードMOVE伝送を初期化する。
MOVE RTT−AKEプロセスが終了すると、BLKMOVE.dtcp.comヘッダ情報を含んだHTTP POSTリクエストを送信することで、Sourceは、暗号化コンテンツの伝送を行なう。
Sinkは、MOVE対象コンテンツをすべて受け取った後、MV_FINALIZEコマンドを送信することによって、MOVE伝送終了処理を起動する。MOVE終了処理手続きは、図11に示した動作シーケンスに従って実施される。
なお、図31に示すように、Sourceから、コンテンツを伴わないPOSTリクエストのヘッダでソケット情報を送り、Sinkが認証および鍵交換用のTCPコネクションを確立して、AKE手続を終了した後に、POSTレスポンスを返すようにしても良い。このような動作シーケンスの場合、AKE手続きで共有したKXM_labelをMOVE.dtcp.com(若しくは、BLKMOVE.dtcp.com)ヘッダを使い、“MOVE.dtcp.com:<KXM_label>”のようにしてSinkからのPOSTレスポンスで送ることで、Sourceは同時に複数のMOVE伝送処理を行なう場合でも、コンテンツの暗号化に適用すべき交換鍵KXMを確実に把握することができる。
また、図31に示した動作シーケンスと同じ効果を得る別の方法として、複数のMOVE処理を行なう場合にSinkに通知するソケット情報をユニークにすることで、SinkとKXMの関係付けを確実に行なうことができる。この場合、SinkはAKE手続きの完了前にMOVE.dtcp.com(若しくは、BLKMOVE.com)ヘッダを伴わないPOSTレスポンスを送ることもできる。なお、この後のコンテンツ伝送は新たなPOSTリクエストとしてではなく、AKE手続き前のPOSTリクエストの手続きとして送る方法も考えられる。
また、ここで説明したソケット情報の通知方法は、アップロードMOVE伝送だけでなく、アップロード形式のCOPY伝送においても同様に適用することができる。
図32A及び図32Bには、図31に示した動作シーケンスによってHTTPクライアントとしてのSourceからHTTPサーバとしてのSinkへコンテンツをアップロードMOVE伝送する場合のSource及びSinkがそれぞれ実行する処理動作をフローチャートの形式でまとめている。
Sourceは、コンテンツのアップロード先のサーバとして動作するSinkを発見すると(ステップS151)、Sinkに対してコンテンツの保管場所の作成を要求するべく、CDS::CreateObject requestを送信して(ステップS152)、そのレスポンスの受信を待機する(ステップS153)。
Sinkは、SourceからCDS::CreateObject requestを受信すると(ステップS171)、これに対するレスポンスを返信する(ステップS172)。
Sourceは、SinkからCDS::CreateObject responseを受信すると、続いてMOVE対象となるコンテンツを決定する(ステップS154)。そして、Content−Typeヘッダを伴うHTTP POSTリクエストでSinkにソケット情報を送信した後(ステップS155)、MOVE用のAKE要求を受信するまで待機する(ステップS156)。
Sinkは、ソケット情報を伴うHTTP POSTリクエストをSourceから受信すると(ステップS173)、当該リクエストから得たソケットに対するTCPコネクションを確立して(ステップA174)、Sourceに対してMOVE用のAKE処理を要求する(ステップS175)。
そして、SinkとSource間では、MOVE用のAKE手続きが開始され、互いにMOVE用のAKE処理を実行する(ステップS157、S176)。ここで、MOVE用のAKEの認証に成功すると(ステップS158、S177)、Sourceは、MOVE用の鍵と鍵IDを生成してSinkに送信する(ステップS159)。但し、SourceとSink間でMOVE用のAKEの認証に失敗すると、SourceとSinkはともに、後続の処理をすべてスキップして、本処理ルーチン全体を終了する。
Sinkは、SourceからMOVE用の鍵と鍵IDを受信すると(ステップS178のYes)、BLKMOVE.dtcp.comヘッダを伴うHTTP POSTレスポンスで鍵IDを送信する(ステップS179)。
そして、Sourceは、Sinkから鍵IDを伴うHTTP POSTレスポンスを受信すると(ステップS160のYes)、この鍵IDに対応するMOVE伝送用の鍵を以後の処理用に選択する(ステップS161)。
続いて、Sourceは、Sinkに対してアップロードMOVE伝送しようとするコンテンツに対して「MOVE伝送中」フラグをセットしてから(ステップS162)、当該コンテンツをMOVE伝送用の鍵を用いて暗号化し、ソケット情報を伴うHTTP POSTリクエストのメッセージ・ボディとして送信する(ステップS163)。「MOVE伝送中」フラグをセットすると、当該コンテンツはロック状態となる。そして、SinkからのHTTP POSTレスポンスの受信を待機する(ステップS164)。
Sink側では、MOVE用のAKE手続きを終えると、SourceからのHTTP POSTリクエストのメッセージ・ボディとしての暗号化コンテンツを受信待機している(ステップS181)。そして、当該リクエストを受信して、暗号化コンテンツを受け取ると、HTTP POSTレスポンスを返信する(ステップS182)。
このようにして、SourceからSinkへ暗号化コンテンツを成功裏にアップロードすることができたならば、SourceはMOVE終了処理の受信を待機する(ステップS165)。また、Sinkは、Sourceに対してMOVE終了処理の要求を送信する(ステップS183)。そして、SourceとSinkは、それぞれMOVE終了処理手続きを実行して(ステップS166、S184)、Sink側でコンテンツを有効化するとともに、Source側の元のコンテンツを削除又は無効化する。Source及びSink間におけるMOVE終了処理手続きの動作シーケンスは図11並びに図18を参照して既に説明した通りなので、ここでは説明を省略する。
そして、SourceとSinkは、MOVE終了処理手続きを完了すると(ステップS167、S185)、いずれもMOVE伝送用の鍵と鍵IDを破棄して(ステップS168、S186)、本処理ルーチン全体を終了する。
ここで、SourceからSinkへコンテンツのエンティティが成功裏にアップロードMOVE伝送されたにも拘らず、一方の機器の電源遮断などによりMOVE伝送の終了処理シーケンスが途切れてしまう可能性がある。MOVE伝送の終了処理の中断(interrupted)によって、Source及びSinkの双方において移動したコンテンツを利用できなくなるおそれがある。このようにMOVE終了処理手続きが中断したときには、図19〜21に示した処理手順に従って再開して、SinkとSourceの双方でコンテンツが無効になることを避けることができる。
アップロードMOVE伝送の終了処理の再開を可能にするために、Sink及びSourceの各々では、アップロードMOVE伝送の終了処理を開始する際に、NVRAMなどの不揮発性メモリを用いて、再開処理に必要となるデータを保存するようにしている。Sink側では、CMD1すなわちMV_FINALIZEコマンドで用いるパラメータ(KxM_label)と、MAC6Aを不揮発的に格納する。
また、Sourceは中断したCommitment情報を持つ場合、対応するSinkに対してソケット情報を通知し、処理の再開を促す必要がある。このためには、Sourceは、Commitment処理の過程において、Sink発見に必要となるUUID、及びPOSTの宛て先URIを発見するのに必要となるObject ID、さらには鍵IDであるKxM_labelとMAC5B、MAC6Bを不揮発的に格納する。再開処理は、基本的にはSink側が起動する。
HTTP POSTリクエストのヘッダにソケット情報(DTCP socket Info)を記載して、SourceからSinkへソケット情報を通知するという上記の方法によれば、CDS::CreateObjectを使ってソケット情報を通知する方法とは異なり、中断したMOVE処理を再開する際であっても、Sinkは問題なくMOVE対象となるコンテンツに関するソケット情報を得ることができる。
図33には、MOVE伝送終了処理を再開する際に、Sink及びSource間でTCPコネクションを確立するための処理手順をフローチャートの形式で示している。
Sourceは、不揮発的に記憶しておいたUUIDを1つ選択し(ステップS191)、UPnPのデバイス発見のプロトコルにより、不揮発的に記憶しておいたUUIDと一致する機器(Sink)が発見されたかどうかをチェックする(ステップS192)。そして、Sourceは、不揮発的に記憶しておいたものと同じUUIDを持つSinkを発見すると、その機器に対してCDS::BrowseリクエストをObjectID指定付きで送信する(ステップS193)。
一方、Sinkは、SourceからCDS::Browseリクエストを受信すると(ステップS201)、CDS::Browseレスポンスを返信する(ステップS202)。
Sourceは、SinkからCDS::Browseレスポンスを受け取ると(ステップS194のYes)、当該レスポンスの記述内容からソケット情報の送信先となるres@importUriを取得する(ステップS195)。そして、ソケット情報をContent−Typeヘッダに含むHTTP POSTリクエストをSinkに送信する(ステップS196)。
Sinkは、Sourceからソケット情報を伴うHTTP POSTリクエストを受信すると(ステップS203)、当該リクエストに含まれるソケット情報を参照して、Sourceとの間でAKEコマンドの通信用のTCPコネクションを確立する(ステップS204)。そして、このTCPコネクションを利用して、図19〜21に示した処理手順に従って、中断されたMOVE伝送終了処理を再開することができる。
C−3.BLOCK MOVEのCANCEL並びにAbort
上述したようなダウンロード及びアップロードのうちいずれの形式でコンテンツをMOVEする場合であっても、Sinkは、Sourceに対しMOVE終了処理用コマンドCMD1を送信する前であれば、MOVE処理を取り消し(cancel)又は中止(abort)することができる。
Source並びにSinkはともに、相手に対してMV−CANCELサブファンクションを送信することによって、MOVE処理手続を取り消す(CANCELする)ことができる。
本実施形態では、MOVE処理手続きのCANCELは、AKE手続きの一部として実装する。AKE手続きのためのTCPコネクションは、通常、Sinkからのトリガによって確立される。コンテンツのストリーミングやコピーを行なう通常のコンテンツ伝送手続きでは、AKEにより鍵を共有するとAKE用のTCPコネクションを切断する。しかしながら、ここでは、MOVE処理手続き中にSource側からもMV−CANCELサブファンクションを送信できるようにするために、AKE用のTCPコネクションを保持しておく必要がある。
Sourceは、MOVE終了処理手続きを開始する前にMV−CANCELサブファンクションを送信し又は受信すると、MOVE処理手続きを終了させるとともに、MOVE対象となっていたコンテンツのロック状態を解除し(具体的には、表2中で該当コンテンツの状態をMOVE可能に戻す)、当該コンテンツに対する他のMOVE要求のために解放する。また、MOVE処理手続の終了に併せて、Sourceは交換鍵KXMを消滅させる。これ以降は、Sinkからの当該終了したMOVE処理手続きに関するリクエストを拒絶するようになる。
また、Sinkは、MOVE終了処理手続きを開始する前にMV−CANCELサブファンクションを送信し又は受信すると、MOVE処理手続きを終了させるとともに、自分にMOVEされたコンテンツを削除する。このMOVE処理手続の終了に併せて、Sinkは交換鍵KXMを消滅させる。
また、SourceとSinkはともに、MOVE終了処理が開始する前にSourceとSink間の通信が途切れると、MOVE処理手続きを中止(abort)することができる。この場合のSourceとSinkは、MV−CANCELを送信又は受信したときと同様の振る舞いを行なう。
D.MOVEモード詐称攻撃の対策
DTCP−IPでは、SourceとSink間の伝送路上にパーソナル・コンピュータなどで構成される不正なプロキシを設置することで、通信内容の改ざんが容易に行なわれてしまう。とりわけ、SourceとSink間でケイパビリティの確認手続き(図16〜17を参照のこと)を経てBLOCK MOVEを開始するようなシステムにおいては、その確認手続きの実装が必須でない場合、SourceがBLOCK MOVEに対応しているにも拘らず、プロキシはSourceがBLOCK MOVEに非対応であるとSinkに偽り、SinkにINCREMENTAL MOVEを行なわせることができる。図22に示す動作シーケンス例では、プロキシは、SinkからのBLOCK MOVE対応であることを記載したCAPABILITY_EXCHANGEメッセージをSourceにそのまま伝達するが、SourceからのBLOCK MOVE対応であることを記載したCAPABILITY_EXCHANGEメッセージを改竄して、BLOCK MOVEの要求を拒否し(Rejected)、SourceがBLOCK MOVE非対応であると偽る。この場合、Source側はSinkからの要求に従ってBLOCK MOVEモードでコンテンツ送信処理を行なうが、SinkはINCREMENTAL MOVEモードに切り替わってコンテンツ受信処理を行なうことになる。
このようなMOVEモード詐称攻撃が仕掛けられると、Sink側では、Sourceからデータを受け取る度に逐次的に有効化していくとともに、コンテンツ伝送処理が終了した時点でプロキシがSourceに対してコンテンツ伝送処理の取り消しを行なうことで、SourceとSinkの双方で有効なコンテンツが存在するというDTCP−IPの規定に抵触する事態が生じる。
そこで、本実施形態に係るコンテンツ伝送システムは、SourceとSink間で確認されたケイパビリティを詐称してSink側のMOVEモードが偽装されることや、何らかの手段によりMOVE伝送であることを装ってコンテンツのコピー伝送を行なうことを防止するための幾つかの方法を適用するようにしている。
例えば、プロキシがSource機器からのCAPABILITY_EXCHANGEメッセージを改ざんしてBLOCK MOVEの要求を拒否し(Rejected)、SourceがBLOCK MOVE非対応であると偽った場合であっても、その後AKE手続きにおいて、SinkがSourceに対して設定したMOVEモードを通知し、Sourceはケイパビリティの確認手続きを経て決定した自分のMOVEモードと照合することによって、詐称が行なわれているかどうかをチェックすることができる。あるいは図8中のSource及びコンテンツの選択手続きや図12中のSink及びコンテンツの選択手続きにおいて、sinkに対してMOVEによるコンテンツ伝送を行なうことを正しく理解させ、過ってCOPY伝送を行なわせないようにする。
図23に示す動作シーケンス例では、Sinkは、AKE認証手続き内で行なわれるチャレンジ・レスポンスを利用して、Sourceに送るレスポンスの中に自分の動作モードに関する情報を含める。この際、署名で保護される情報にMOVEモードの情報を含めることが望ましい。このレスポンスを受信したSourceは、自分が設定しているBLOCK MOVEモードとは相違することから、MOVEモードの詐称が行なわれ、SourceとSink間の伝送路が危険に晒されていることを気づくことができる。そして、Sourceは、交換鍵KxをSinkに送らず、このような危険な伝送路でコンテンツ伝送を開始することなく、MOVE処理を終了する。
また、図24には、図23に示した動作シーケンスの変形例を示している。図示のシーケンス例では、Sinkは、AKE認証手続き内でSourceに送るレスポンス中で、署名で保護される情報にMOVEモードの情報を含める。このレスポンスを受信したSourceは、自分が設定しているBLOCK MOVEモードとは相違することから、MOVEモードの詐称が行なわれていることを気づくと、BLOCK MOVEモードからINCREMENTAL MOVEモードに切り替わり、交換鍵KxをSinkに送る。そして、SourceとSinkはそれぞれ、交換鍵Kxに所定の演算を施してコンテンツ暗号鍵Kcを作成し、MOVE対象となるコンテンツの暗号化伝送を開始する。
MOVEモードの詐称を防止する他の方法として、交換鍵Kxをスクランブルする方法をMOVEモード毎に切り替える方法が挙げられる。図25には、この場合の動作シーケンス例を示している。Source側では、BLOCK MOVEを行なう際には、交換鍵Kxでスクランブルに使うワンタイム鍵をハッシュ関数で処理して使う。すると、INCREMENTAL MOVEモード下にあるSinkは、交換鍵Kx用のデスクランブル方法ではBLOCK MOVE用の交換鍵KxMを共用することができなくなる。すなわち、Sinkは、BLOCK MOVEモード以外では交換鍵Kx用のデスクランブルが禁止され、正しいコンテンツ暗号鍵Kcを作成できないので、MOVEされたコンテンツを復号できない。
また、MOVEモードの詐称を防止するさらに他の方法として、交換鍵Kxからコンテンツ暗号鍵Kcを生成する計算式をMOVEモード毎に切り替える方法が挙げられる。図26には、この場合の動作シーケンス例を示している。Source側では、BLOCK MOVEを行なう際には、交換鍵KxMからコンテンツ暗号鍵Kcを生成するための計算式に含まれる定数を特別な値に変更する。すると、INCREMENTAL MOVEモード下にあるSink側では、通常の計算式に従って交換鍵Kxから計算しても、正しいコンテンツ暗号鍵Kcを作成できないので(言い換えれば、交換鍵KxMからコンテンツ暗号鍵Kcを計算することが禁止されているので)、MOVEされたコンテンツを復号できない。
よって、上述したいずれかの対策を講じることで、不正なプロキシが伝送路に介在する場合であっても、SourceとSinkの双方で有効なコンテンツが存在するというDTCP−IPの規定に抵触する事態を回避することができる。
図16には、MOVE伝送モード詐称攻撃の対策としてCAPABILITY_EXCHANGEシーケンスについて説明したが、図23〜図26に示したような対策によってMOVE伝送モード詐称攻撃を十分に防ぐことができ、これらの場合はCAPABILITY_EXCHANGEシーケンスを通じたセキュアな情報交換手続は不要となる。