JP4736603B2 - 情報通信装置及び情報通信方法、並びにコンピュータ・プログラム - Google Patents

Description

本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを受信処理する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。

さらに詳しくは、本発明は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続き、ＨＴＴＰプロトコルを利用した暗号化コンテンツ伝送、並びに伝送コンテンツの復号化や再生その他のコンテンツ処理を実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを介して共有されるコンテンツ鍵を使用して暗号化コンテンツの復号処理を実施する際にコンテンツ鍵の確認手続きを行なう情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。

最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。また、デジタル・コンテンツはコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。

例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。

コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。

ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。

ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれ、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。また、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。

ここで、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。

図６には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。同図に示す例では、コンテンツ伝送にはＨＴＴＰプロトコルが利用される。

ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや認証鍵Ｋ_authが埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している認証鍵Ｋ_authをＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。

ＡＫＥ手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、それぞれ内部で同様の処理を行なってＫ_authからコンテンツ鍵の種となる種鍵Ｋ_xを生成する。種鍵Ｋ_xは、コンテンツ伝送時にコンテンツ鍵Ｋ_cを生成するために使用される（後述）。

そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（Ｃｏｎｔｅｎｔｓ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＤＴＣＰ＿Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用することができる。あるいは、ＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。

図６に示すようにＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。ちなみに、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。

ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される（すなわち、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器はそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット（ＩＰアドレスとポート番号の組み合わせ）を持つ）。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。

ここで、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。

具体的には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、乱数を用いてノンスＮ_cを生成して、Ｋ_xとＮ_cを基にコンテンツ鍵Ｋ_cを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋ_cを用いて暗号化し、暗号化コンテンツとノンスＮ_cからなるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せてＤＴＣＰ＿Ｓｉｎｋ機器に送信する。そして、ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける（例えば、非特許文献３を参照のこと）。

ＤＴＣＰ＿Ｓｉｎｋ機器側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、ストリームからノンスＮ_cを取り出すと、これと認証鍵Ｋ_authから求めた鍵Ｋ_xを用いて同様にコンテンツ鍵Ｋ_cを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。

そして、ＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、使用したＴＣＰコネクションを適宜切断することができる。

ここで、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮ_cすなわちコンテンツ鍵Ｋ_cを更新するよう取り決められている。バイト・ストリーム中で、同じノンスＮ_cから生成されたコンテンツ鍵Ｋ_cを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。

また、このようにバイト・ストリームの途中で復号鍵が動的に変更されることから、コンテンツ鍵の確認手続きが必要となる。そこで、ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器に対しコンテンツ鍵確認のための手続きを行なう。ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ鍵の確認が必要になると、適宜このＴＣＰコネクションを確立する。

例えば、ＤＴＣＰ−ＩＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ ＳｅｃｔｉｏｎＶ１ＳＥ．８．６には、Ｃｏｎｔｅｎｔ Ｋｅｙ Ｃｏｎｆｉｒｍａｔｉｏｎについて規定している。これによれば、Ｓｉｎｋ機器は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ ｓｕｂｆｕｎｃｔｉｏｎを用いて、現在のノンスＮ_cに関連付けられたコンテンツ鍵の確認を行なう。

ＤＴＣＰ−ＩＰでは、暗号化コンテンツとノンスＮ_cを含んだＰＣＰというパケット形式でコンテンツ伝送が行なわれる。１つのＰＣＰが同じ復号鍵で復号することができる復号化単位に相当する。Ｓｉｎｋ機器は、コンテンツ・ストリーム毎に、最も新しく受信したＰＣＰのノンスＮ_cの値を確認し、さらに動的に変更される後続のノンスについても２分間隔で再確認しなければならない。但し、Ｓｉｎｋ機器がノンスを初期確認した後に後続のノンスＮ_cの値が単調に増大する連続的な数値であることを監視し確認する場合には、周期的なコンテンツ鍵確認の手続きを省略することができる。

Ｓｉｎｋ機器は、未確認の初期ノンスを取得すると、当該コンテンツ・ストリームに関して暗号化コンテンツの復号を終了しなければならなくなる前に、１分間だけコンテンツ鍵の確認を再試行する猶予期間が与えられる。そして、Ｓｉｎｋ機器は、この猶予期間中にノンスＮ_cの確認に成功すると、暗号化コンテンツの復号動作を回復することができる。

図７には、コンテンツ鍵確認のためのＳｉｎｋ機器とＳｏｕｒｃｅ機器間の手続きを示している。但し、Ｒは６４ビット値で、初期は乱数であるが、後続の試行では１ ｍｏｄ ２⁶⁴でインクリメントするとともに、以下の通りとする。

ＭＸ＝ＳＨＡ−１（Ｋ_x||Ｋ_y）
ＭＡＣ３Ａ＝ＭＡＣ３Ｂ＝［ＳＨＡ−１（ＭＸ＋Ｎ_cＴ＋Ｒ）］ｍｓｂ８０
ＭＡＣ４Ａ＝ＭＡＣ４Ｂ＝［ＳＨＡ−１（ＭＸ＋Ｎ_cＴ＋Ｒ）］ｌｓｂ８０
（上式で、“＋”はｍｏｄ２⁶⁴の加算を意味するために使用される。）

図示のコンテンツ確認手続きでは、Ｓｉｎｋ機器は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドにおいて、検査用のノンスＮ_cＴをＳｏｕｒｃｅ機器に送る。

Ｓｏｕｒｃｅ機器側では、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると、検査用のノンスＮ_cＴを取り出して、現在のノンスＮ_cと比較する。そして、現在のノンスＮ_cがＮ_cＴとＮ_cＴ＋５の範囲にあるときには検査用のノンスＮ_cＴが有効であることを確認する。検査用のノンスＮ_cＴが有効であることを確認できたときには、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、コンテンツ鍵が正しかったことを示すＡＣＣＥＰＴＥＤレスポンス、又は正しくなかったことを示すＲＥＪＥＣＴＥＤレスポンスのいずれかをＳｉｎｋ機器に返す。

Ｓｉｎｋ機器側では、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたときには、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、Ｓｉｎｋ機器自身でコンテンツ鍵が正しいことを確認できた場合にはＳｉｎｋ機器はｃｏｎｆｉｒｍｅｄ状態になる。

一方、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたがＳｉｎｋ機器自身でのコンテンツ鍵確認に失敗した場合や、Ｓｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスが返されたときには、Ｓｉｎｋ機器はｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になる。

ここで、ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が正しいことが確認された状態、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が不正であることが確認された状態であり、いずれもＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている。

ｃｏｎｆｉｒｍｅｄ状態では、Ｓｉｎｋ機器は受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態では、Ｓｉｎｋ機器は復号処理を継続できない。

図８には、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。

Ｓｏｕｒｃｅ機器は、コンテンツ伝送先となるＳｉｎｋ機器からコンテンツ確認を要求するＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると（ステップＳ１）、コンテンツ鍵の確認を行なう（ステップＳ２）。具体的には、当該コマンドから検査用のノンスＮ_cＴを取り出して、現在のノンスＮ_cと比較する。そして、現在のノンスＮ_cがＮ_cＴとＮ_cＴ＋５の範囲にあるときには検査用のノンスＮ_cＴが有効であることを確認する。

そして、Ｓｏｕｒｃｅ機器は、コンテンツ鍵が正しいことを確認した場合には その旨を示すＡＣＣＥＰＴＥＤレスポンスをＳｉｎｋ機器に返信するが（ステップＳ３）、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する（ステップＳ４）。

なお、ＡＣＣＥＰＴＥＤ並びにＲＥＪＥＣＴＥＤはともにＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている、コマンドに対するレスポンスである。

また、図９には、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。

Ｓｉｎｋ機器は、コンテンツ要求先となるＳｏｕｒｃｅ機器に対しＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信した後（ステップＳ１１）、当該Ｓｏｕｒｃｅ機器からのレスポンス受信を待機する（ステップＳ１２）。

ここで、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したときには（ステップＳ１３）、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいて、自らコンテンツ鍵を確認する（ステップＳ１４）。このとき、コンテンツ鍵が正しい場合にはｃｏｎｆｉｒｍｅｄ（ステップＳ１５）、コンテンツ鍵が不正である場合には ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ１７）。また、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときには（ステップＳ１６）、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ１７）。

ｃｏｎｆｉｒｍｅｄでは、Ｓｉｎｋ機器は受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎでは、Ｓｉｎｋ機器は復号処理を継続できない（前述）。但し、Ｓｉｎｋ機器は、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間はコンテンツ鍵確認手続きを繰り返すことができるので（ステップＳ１８）、ステップＳ１１に戻り（ステップＳ１９）、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを再発行する。

コンテンツ鍵確認手続きを再試行して、１分以内にｃｏｎｆｉｒｍｅｄとなれば（ステップＳ１５）、受信コンテンツの復号処理を継続することができる。しかし、１分間ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎが継続した場合には（ステップＳ１８）、受信コンテンツの復号処理を直ちに停止しなければならない（ステップＳ２０）。

上述したように、ＤＴＣＰ−ＩＰの規格では、コンテンツ鍵確認の手続きにおいて、Ｓｉｎｋ機器がＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信して、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤ又はＲＥＪＥＣＴＥＤといった正常なレスポンスを受信してコンテンツ鍵の確認に失敗した結果としてｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎの状態に陥ること、並びに、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態となったときにＳｉｎｋ機器にはコンテンツの復号処理を停止するまでに１分間の猶予が与えられることが明記されている。したがって、Ｓｉｎｋ機器はｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎの状態になってから１分間はＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを繰り返し送信し、この猶予期間にコマンド鍵の確認に成功すると、Ｓｉｎｋ機器はコンテンツの復号処理を停止せずに済む。

しかしながら、ＤＴＣＰ−ＩＰの規格では、コンテンツ鍵確認の手続きにおいて、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤやＲＥＪＥＣＴＥＤなどＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドに対する正常なレスポンスを受け取ることができなかったためにコンテンツ鍵確認が成功しなかったときの処理については特に明記していない。具体的には、Ｓｉｎｋ機器がＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信したのに対して、Ｓｏｕｒｃｅ機器からはＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤ（非実装）レスポンスが返された場合や、レスポンス受信待機に対してタイムアウトした場合に、Ｓｉｎｋ機器がｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になることは明記されていない。

ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態にならないことは、言い換えれば、コンテンツ鍵確認に失敗したときにＳｉｎｋ機器に猶予期間が与えられないことになる。すなわち、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器からＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを受信したときやレスポンス受信待機期間がタイムアウトすると、即座にコンテンツの復号処理を停止しなければならない。そして、復号処理が停止されたコンテンツを利用したいときには、コンテンツ伝送手続きを改めて最初から実施しなければならず、１分間の猶予期間を利用してコンテンツ復号処理を再開する場合に比べると、処理が非効率的となる。

Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ_ＣＯＮＦのレスポンスが遅れることがある。しかしながら、Ｓｉｎｋ機器が通常ありえないＮＯＴ_ＩＭＰＬＥＭＥＮＴＥＤを受信したときや、レスポンスに対するタイムアウトが発生したときに受信コンテンツの復号処理を直ちに停止してしまうと、Ｓｉｎｋ機器の動作として問題がある。何故ならば、Ｓｉｎｋ機器は、正しいコンテンツ鍵を持っているにも関わらず、受信コンテンツの復号処理を行うことができなくなるからである。

ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．３ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．０ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／ ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ） ７９１ ＩＮＴＥＲＮＥＴ ＰＲＯＴＯＣＯＬ

本発明の目的は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続き、ＨＴＴＰプロトコルを利用した暗号化コンテンツ伝送、並びに伝送コンテンツの復号化や再生その他のコンテンツ処理を好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを介して共有されるコンテンツ鍵を使用して暗号化コンテンツの復号処理を実施する際にコンテンツ鍵の確認手続きを好適に行なうことができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、ＤＴＣＰ−ＩＰに準拠してコンテンツ伝送を行なう際に、Ｓｉｎｋ機器としてＳｏｕｒｃｅ機器に対してコンテンツ鍵確認を要求し、これに対し正常なレスポンスを得ることができずにコンテンツ鍵確認に失敗した場合であっても、円滑に動作状態を回復することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明は、上記課題を参酌してなされたものであり、その第１の側面は、Ｓｏｕｒｃｅ機器から伝送される暗号化コンテンツを受信処理する情報通信装置であって、
暗号化コンテンツを受信するコンテンツ受信手段と、
コンテンツ鍵を用いて暗号化コンテンツを復号処理するコンテンツ復号手段と、
Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認を要求するコンテンツ鍵確認要求手段と、
コンテンツ鍵確認要求に対するＳｏｕｒｃｅ機器からのレスポンスに応じて、コンテンツ鍵確認手段と、
前記コンテンツ鍵確認手段による確認結果に応じて前記コンテンツ復号手段による暗号化コンテンツの復号処理動作の継続又は停止を制御するコンテンツ復号処理制御手段を備え、
前記コンテンツ復号処理制御手段は、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、前記コンテンツ鍵確認要求手段によるコンテンツ鍵の確認要求の再試行を所定期間だけ許容する、
ことを特徴とする情報通信装置である。

本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。

この種の情報通信システムでは、ＴＣＰストリームのような長大なバイト・ストリームを途中でコンテンツ鍵を変更しながら暗号化通信が行なわれ、且つ、暗号化コンテンツの復号処理その他のコンテンツ処理を実施する際にコンテンツ鍵の確認手続きが行なわれる。

本発明に係る情報通信装置は、ＤＴＣＰ−ＩＰにおけるＳｉｎｋ機器として動作する。そして、ＨＴＴＰプロトコルを用いてＳｏｕｒｃｅ機器との間でコンテンツ伝送を行なう際に、前記コンテンツ復号手段は、Ｓｏｕｒｃｅ機器との相互認証手続きを経て共有する認証鍵と暗号化コンテンツに付加されるノンスからコンテンツ鍵を生成して、暗号化コンテンツを復号処理する。また、コンテンツ鍵確認要求手段は、検査用ノンスを含んだコンテンツ鍵確認要求コマンドをＳｏｕｒｃｅ機器に送信する。また、前記コンテンツ鍵確認手段は、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信し且つ自らコンテンツ鍵の確認を行なって正しい鍵と判定するとｃｏｎｆｉｒｍｅｄ状態を出力し、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したが自らコンテンツ鍵の確認を行なって正しい鍵と判定できない場合又はＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときにｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態を出力するようになっている。

ここで、ＤＴＣＰ−ＩＰの規格では、コンテンツ鍵確認の手続きにおいて、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤ又はＲＥＪＥＣＴＥＤといった正常なレスポンスを受信してコンテンツ鍵の確認に失敗した結果としてｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎの状態に陥ること、並びに、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態となったときにＳｉｎｋ機器にはコンテンツの復号処理を停止するまでに１分間の猶予が与えられることが明記されている。したがって、Ｓｉｎｋ機器はｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎの状態になってから猶予期間にコマンド鍵の確認に成功すると、Ｓｉｎｋ機器はコンテンツの復号処理を停止せずに済む。

他方、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ_ＣＯＮＦのレスポンスが遅れることがある。ところが、このような場合に、Ｓｉｎｋ機器がｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になることは明記されていない。ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態でないと、コンテンツ鍵確認に失敗したときに猶予期間が与えられないので、Ｓｉｎｋ機器は即座にコンテンツの復号処理を停止しなければならない。

Ｓｉｎｋ機器は、正しいコンテンツ鍵を持っているにも関わらず受信コンテンツの復号処理を行なうことができなくなるから、ＮＯＴ_ＩＭＰＬＥＭＥＮＴＥＤを受信したときや、レスポンスに対するタイムアウトが発生したときに受信コンテンツの復号処理を直ちに停止してしまうと、Ｓｉｎｋ機器の動作として問題がある。また、復号処理が停止されたコンテンツを利用したいときには、コンテンツ伝送手続きを改めて最初から実施しなければならず、猶予期間を利用してコンテンツ復号処理を再開する場合に比べると、処理が非効率的となる。

これに対し、本発明に係る情報通信装置によれば、前記コンテンツ復号処理制御手段は、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、前記コンテンツ鍵確認要求手段によるコンテンツ鍵の確認要求の再試行を所定期間だけ許容するようにしている。したがって、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦのレスポンスの受信に遅れが生じる状況下であっても、その後にコンテンツ鍵が正しいことを確認できたときには、受信コンテンツの復号処理を継続して行なうことができる。

ここで、前記コンテンツ鍵確認手段は、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態を出力するようにしてもよい。

このような場合、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってコンテンツ鍵確認要求に対するレスポンスの受信に遅れが生じた際におけるＳｉｎｋ機器の動作を、ＤＴＣＰ−ＩＰで規定されているｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態における処理として扱うことができるので、低コストで実現することができる。

また、本発明の第２の側面は、Ｓｏｕｒｃｅ機器から伝送される暗号化コンテンツの受信処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
暗号化コンテンツを受信するコンテンツ受信手順と、
コンテンツ鍵を用いて暗号化コンテンツを復号処理するコンテンツ復号手順と、
Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認を要求するコンテンツ鍵確認要求手順と、
コンテンツ鍵確認要求に対するＳｏｕｒｃｅ機器からのレスポンスに応じて、コンテンツ鍵確認手順と、
前記コンテンツ鍵確認手順における確認結果に応じて前記コンテンツ復号手順による暗号化コンテンツの復号処理動作の継続又は停止を制御するコンテンツ復号処理制御手順を実行させ、
前記コンテンツ復号処理制御手順では、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、前記コンテンツ鍵確認要求手順によるコンテンツ鍵の確認要求の再試行を所定期間だけ許容する、
ことを特徴とするコンピュータ・プログラムである。

本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る情報通信装置と同様の作用効果を得ることができる。

本発明によれば、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続き、ＨＴＴＰプロトコルを利用した暗号化コンテンツ伝送、並びに伝送コンテンツの処理を好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを介して共有されるコンテンツ鍵を使用して暗号化コンテンツの復号処理を実施する際にコンテンツ鍵の確認手続きを好適に行なうことができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、ＤＴＣＰ−ＩＰに準拠してコンテンツ伝送を行なう際に、Ｓｉｎｋ機器としてＳｏｕｒｃｅ機器に対してコンテンツ鍵確認を要求し、これに対し正常なレスポンスを得ることができずにコンテンツ鍵確認に失敗した場合であっても、円滑に動作状態を回復することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。

ＤＴＣＰ−ＩＰに準拠したコンテンツ伝送において、Ｓｉｎｋ機器がＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送った際に、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦのレスポンスが遅れることがあるが、これ自体はコンテンツ鍵確認判定に影響を及ぼすべきでない。本発明によれば、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器からＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤを受信したときや、レスポンスに対するタイムアウトが発生したときに、即時に受信コンテンツの復号処理を停止するのではなく、（擬似的に）ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎと判定することにより、Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認手続きを繰り返し行なうことができる。したがって、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ_ＣＯＮＦのレスポンスの受信に遅れが生じる状況下であっても、その後にコンテンツ鍵が正しいことを確認できたときには、受信コンテンツの復号処理を継続して行なうことができる。

また、本発明によれば、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ_ＣＯＮＦのレスポンスの受信に遅れが生じた際におけるＳｉｎｋ機器の動作を、ＤＴＣＰ−ＩＰで規定されているｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態における処理として扱うことができるので、低コストにより実現することができる。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

以下、図面を参照しながら本発明の実施形態について詳解する。

本発明は、ＴＣＰ／ＩＰなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号する情報通信システムに関する。本発明に係る情報通信システムでは、Ｓｏｕｒｃｅ機器とＳｉｎｋ機器間でＴＣＰストリームのような長大なバイト・ストリームでコンテンツ伝送する途中でコンテンツ鍵を動的に変更し、且つ、Ｓｉｎｋ機器はＳｏｕｒｃｅ機器に対してコンテンツ鍵の確認手続きを適宜行なう。また、この情報通信システムでは、相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立される。かかるシステムの具体例は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送である。

Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅ機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋ機器で構成される。図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。

図示の例では、Ｓｏｕｒｃｅ機器Ａ〜Ｂ、Ｓｉｎｋ機器Ａ〜Ｂ及び中継機器Ａ〜Ｃの各エンティティにより、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。

ＤＴＣＰ−ＩＰ に準拠した認証サーバであるＳｏｕｒｃｅ機器ＡとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器Ａが中継機器Ａと中継機器Ｂを経由してネットワークで接続されている。

また、中継機器Ａ、中継機器Ｂ、中継機器Ｃ を経由して、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＢやＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器ＢがＩＰネットワークで接続されている。

図２及び図３には、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）及びサーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成をそれぞれ模式的に示している。Ｓｉｎｋ機器とＳｏｕｒｃｅ機器は、インターネットなどの図示しないＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。

図２に示すＳｉｎｋ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｉｎｋとして動作する。図示のクライアント機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。

ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。

ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。

メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。

メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。

コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵を用いてコンテンツの復号鍵を算出し、暗号コンテンツを復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。

コンテンツ再生／記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。

ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、ＡＫＥを実施した後にコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロックはＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。

ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックへ分かれる。

ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりサーバへ送信される。

ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＤＴＣＰ認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。

ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。

また、図３に示すＳｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｏｕｒｃｅとして動作する。サーバ機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。

ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。

ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＤＴＣＰ＿Ｓｉｎｋ機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。

メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。

メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。

コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じて、コンテンツ管理ブロックより読み出したコンテンツ・データをＡＫＥで交換した鍵から生成したコンテンツ鍵を用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。

コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。

ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、ＨＴＴＰサーバ・ブロックを持ち、ＨＴＴＰサーバとしてクライアントからのリクエストを受理し要求に応じた処理を実行する。

ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。

ＨＴＴＰリクエスト受信ブロックは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。

ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。

ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。

ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。

ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、Ｓｉｎｋ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。

なお、ＤＴＣＰ−Ｓｉｎｋ機器及びＤＴＣＰ−Ｓｏｕｒｃｅ機器がそれぞれＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。例えば、本出願人に既に譲渡されている特願２００４−１１３４５９号公報には、この種のメッセージ・ダイジェスト生成ブロックについて記述されている。

Ｂ．ＨＴＴＰを利用したコンテンツ伝送
ＤＴＣＰ−ＩＰに準拠したコンテンツ伝送については既に説明したが、図６を参照しながらおさらいをしておく。

ＤＴＣＰ−ＩＰに準拠したＳｏｕｒｃｅ機器及びＳｉｎｋ機器間でＨＴＴＰプロトコルを利用したコンテンツ伝送を実施する場合、ＴＣＰストリームのような長大なバイト・ストリームを途中でコンテンツ鍵を変更しながら暗号化通信が行なわれ、且つ、暗号化コンテンツの復号処理その他のコンテンツ処理を実施する際にコンテンツ鍵の確認手続きが行なわれる。また、相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立される。

具体的には、ＡＫＥ手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、認証鍵Ｋ_authを共有することができ、それぞれ内部で同様の処理を行なってＫ_authからコンテンツ鍵の種となる種鍵Ｋ_xを生成する。Ｓｏｕｒｃｅ機器は、乱数を用いてノンスＮ_cを生成して、Ｋ_xとＮ_cを基にコンテンツ鍵Ｋ_cを生成し、Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋ_cを用いて暗号化し、暗号化コンテンツとノンスＮ_cからなるＰＣＰをＴＣＰストリーム上に乗せてＳｉｎｋ機器に送信する。一方、Ｓｉｎｋ機器側では、ＴＣＰストリームからノンスＮ_cを取り出すと、これと認証鍵Ｋ_authから求めた鍵Ｋ_xを用いて同様にコンテンツ鍵Ｋ_cを算出し、暗号化コンテンツを復号することができる。

このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。

また、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮ_cすなわちコンテンツ鍵Ｋ_cを更新する。そして、バイト・ストリームの途中で復号鍵が動的に変更されることから、コンテンツ鍵の確認手続きが必要となり、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器に対しコンテンツ鍵確認のための手続きを行なう。

Ｃ．コンテンツ鍵確認手続き
コンテンツ鍵確認手続きでは、Ｓｉｎｋ機器は、検査用のノンスＮ_cＴを付加したＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドをＳｏｕｒｃｅ機器に送る。Ｓｏｕｒｃｅ機器側では、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると、検査用のノンスＮ_cＴを取り出して、現在のノンスＮ_cと比較する。そして、現在のノンスＮ_cがＮ_cＴとＮ_cＴ＋５の範囲にあるときには検査用のノンスＮ_cＴが有効であることを確認する。

そして、Ｓｏｕｒｃｅ機器は、コンテンツ鍵が正しいことを確認した場合には その旨を示すＡＣＣＥＰＴＥＤレスポンスをＳｉｎｋ機器に返信するが、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する（図８を参照のこと）。

一方、Ｓｉｎｋ機器は、コンテンツ要求先となるＳｏｕｒｃｅ機器に対しＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信した後、当該Ｓｏｕｒｃｅ機器からのレスポンス受信を待機する。そして、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したときには、さらにＳｉｎｋ機器自身でコンテンツ鍵を確認し、コンテンツ鍵が正しい場合にはｃｏｎｆｉｒｍｅｄ状態となるが、コンテンツ鍵が不正である場合には ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態となる。また、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときにもｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態となる（図９を参照のこと）。

Ｓｉｎｋ機器は、ｎｏｎ−ｃｏｎｆｉｒｍｅｄでは、Ｓｉｎｋ機器は復号処理を継続できないが、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間はコンテンツ鍵確認手続きを繰り返すことができる。そして、１分以内にｃｏｎｆｉｒｍｅｄとなれば、受信コンテンツの復号処理を継続することができる。

Ｓｉｎｋ機器からのコンテンツ鍵確認要求に対するＳｏｕｒｃｅ機器側の動作として、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドのレスポンスが遅れることや、ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスが返されることも想定される。ところが、ＤＴＣＰ−ＩＰでは、ＡＣＣＥＰＴＥＤ／ＲＥＪＥＣＴＥＤレスポンス以外の場合におけるＳｉｎｋ機器の対処方法については明記されていない。

Ｓｉｎｋ機器が正しいコンテンツ鍵を持っている場合、レスポンスの遅延やＳｏｕｒｃｅ機器からの通常あり得ないレスポンスによって、Ｓｉｎｋ機器側でのコンテンツ鍵確認判定が影響を受け、受信コンテンツの復号処理を行なうことができなくなると、Ｓｉｎｋ機器の動作として問題がある。

そこで、本実施形態では、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器からＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤを受信したときや、レスポンスに対するタイムアウトが発生したときに、即時に受信コンテンツの復号処理を停止するのではなく、（擬似的に）ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎと判定することにより、Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認手続きを繰り返し行なうようにしている。したがって、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦのレスポンスの受信に遅れが生じる状況下であっても、その後にコンテンツ鍵が正しいことを確認できたときには、受信コンテンツの復号処理を継続して行なうことができる。

図４には、Ｓｉｎｋ機器において、コンテンツ鍵確認手続きを行なうための機能的構成を模式的に示している。

コマンド送信部１１は、Ｓｏｕｒｃｅ機器に対するコマンド送信を行なう。Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認を要求するときには、コンテンツ鍵確認用のＴＣＰコネクションを確立して、検査用のノンスＮ_cＴを含んだＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信する。

また、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間はコンテンツ鍵確認手続きを繰り返すことが許容されているので、コマンド送信部１１は、この猶予期間内にＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドをＳｏｕｒｃｅ機器宛てに再度送信する。

レスポンス待機部１２は、Ｓｏｕｒｃｅ機器に対してコマンドを送信した後、ＴＣＰコネクション上で受信動作を行ない、Ｓｏｕｒｃｅ機器からのレスポンスが届くのを待機する。

レスポンス受信部１３は、送信したコマンドに対するＳｏｕｒｃｅ機器からのレスポンスを受信処理する。送信コマンドがＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドであった場合には、Ｓｏｕｒｃｅ機器からのレスポンスとして、コンテンツ鍵が正しかったことを示すＡＣＣＥＰＴＥＤレスポンスと、正しくなかったことを示すＲＥＪＥＣＴＥＤレスポンスと、通常はあり得ないＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスが想定される。レスポンス受信部１３は、受信したレスポンスがいずれであるかを解釈し、ＡＣＣＥＰＴＥＤレスポンスであればコンテンツ鍵確認判定部１５に通知する。また、Ｓｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスが返されたときにはｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になる。

また、ＤＴＣＰ−ＩＰではＡＣＣＥＰＴＥＤ／ＲＥＪＥＣＴＥＤレスポンス以外の場合におけるＳｉｎｋ機器の対処方法については明記されていないが、本実施形態では、レスポンス受信部１３は、Ｓｏｕｒｃｅ機器からＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを受信したときにはｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態となるようにしている。

レスポンスに対するタイムアウト検出部１４は、コマンド送信部からＳｏｕｒｃｅ機器宛てにコマンドを送信してからＳｏｕｒｃｅ機器からレスポンスが返されるまでのタイムアウトを検出する。例えば、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってレスポンスが遅れると、タイムアウトが検出される。

ＤＴＣＰ−ＩＰでは、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドのレスポンスが遅れたときのＳｉｎｋ機器側での対処方法について特に明記していない。これに対し、本実施形態では、レスポンスに対するタイムアウト検出部１４は、ＣＯＮＴ＿ＫＥＹ_ＣＯＮＦコマンドのレスポンスが遅れたときにはｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態となるようにしている。

コンテンツ鍵確認判定部１５は、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたことをレスポンス受信部１３から通知されると、ＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、Ｓｉｎｋ機器自身でコンテンツ鍵が正しいことを確認できた場合にはＳｉｎｋ機器はｃｏｎｆｉｒｍｅｄ状態になるが、Ｓｉｎｋ機器自身でのコンテンツ鍵確認に失敗した場合には、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になる。

復号処理停止部１６は、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間にｃｏｎｆｉｒｍｅｄ状態とならなかった場合に、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ復号ブロック（図２を参照のこと）における受信コンテンツの復号処理を停止する。

図５には、図４に示した機能的構成を備えたＳｉｎｋ機器においてコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。

コマンド送信部１１がコンテンツ要求先となるＳｏｕｒｃｅ機器に対しＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信した後（ステップＳ３１）、レスポンス待機部１２は当該Ｓｏｕｒｃｅ機器からのレスポンス受信を待機する（ステップＳ３２）。そして、レスポンスに対するタイムアウト検出部１４がタイムアウトを検出するまでは（ステップＳ４３）、レスポンス待機部１２はレスポンスの待機動作を継続する。

ここで、Ｓｏｕｒｃｅ機器からレスポンスを受信したときには、レスポンス受信部１３がレスポンスの種別を判定する（ステップＳ３３）。そして、ＡＣＣＥＰＴＥＤレスポンスを受信したときには（ステップＳ３４）、コンテンツ鍵確認判定部１５に通知して、コンテンツ鍵確認判定処理を起動する（ステップＳ３５）。コンテンツ鍵確認判定部１５は、ＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、コンテンツ鍵が正しい場合にはｃｏｎｆｉｒｍｅｄ（ステップＳ３６）、コンテンツ鍵が不正である場合には ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ３８）。

また、レスポンス受信部１３がＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときには（ステップＳ３７）、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなる（ステップＳ３８）。本実施形態では、レスポンス受信部１３がＳｏｕｒｃｅ機器からＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを受信したときにも（ステップＳ３７）、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなる（ステップＳ３８）。

また、本実施形態では、Ｓｏｕｒｃｅ機器に対しＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信した後、レスポンスに対するタイムアウト検出部１４がタイムアウトを検出した場合にも（ステップＳ４３）、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなる（ステップＳ３８）。

ｃｏｎｆｉｒｍｅｄ状態では（ステップＳ３６）、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ復号ブロックは受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態では（ステップＳ３８）、Ｓｉｎｋ機器は復号処理を継続できない（前述）。但し、Ｓｉｎｋ機器は、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間はコンテンツ鍵確認手続きを繰り返すことができるので（ステップＳ３９）、ステップＳ３１に戻り（ステップＳ４０）、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを再発行する。

コンテンツ鍵確認手続きを再試行して、１分以内にｃｏｎｆｉｒｍｅｄとなれば（ステップＳ３６）、受信コンテンツの復号処理を継続することができる。しかし、１分間ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎが継続した場合には（ステップＳ３９）、受信コンテンツの復号処理を直ちに停止しなければならない（ステップＳ４１）。

このように、図５に示した処理手順によれば、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときだけでなく、ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤを受信したときや、レスポンスに対するタイムアウトが発生したときに、即時に受信コンテンツの復号処理を停止するのではなく、（擬似的に）ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎと判定することにより、Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認手続きを繰り返し行なうことができる。したがって、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器のビジー状態やネットワークの輻輳によってＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦのレスポンスの受信に遅れが生じる状況下であっても、その後にコンテンツ鍵が正しいことを確認できたときには、受信コンテンツの復号処理を継続して行なうことができる。

以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立されるという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。ＩＰプロトコルを利用したコンテンツ伝送手続きにおいて、暗号化コンテンツ伝送と、暗号化コンテンツの復号鍵の確認手続き用にそれぞれ別のＴＣＰコネクションを確立するような他のタイプの情報通信システムに対しても、同様に本発明を適用することができる。

要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。

図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。 図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。 図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。 図４は、Ｓｉｎｋ機器においてコンテンツ鍵確認手続きを行なうための機能的構成を模式的に示した図である。 図５は、図４に示した機能的構成を備えたＳｉｎｋ機器においてコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。 図６は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である。 図７は、コンテンツ鍵確認のためのＳｉｎｋ機器とＳｏｕｒｃｅ機器間の手続きを示した図である。 図８は、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。 図９は、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。

符号の説明

１１…コマンド送信部
１２…レスポンス待機部
１３…レスポンス受信部
１４…レスポンスに対するタイムアウト検出部
１５…コンテンツ鍵確認部
１６…復号処理停止部

Claims (7)

1. Ｓｏｕｒｃｅ機器から伝送される暗号化コンテンツを受信処理する情報通信装置であって、
   暗号化コンテンツを受信するコンテンツ受信手段と、
   コンテンツ鍵を用いて暗号化コンテンツを復号処理するコンテンツ復号手段と、
   Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認を要求するコンテンツ鍵確認要求手段と、
   コンテンツ鍵確認要求に対するＳｏｕｒｃｅ機器からのレスポンスに応じて、コンテンツ鍵確認手段と、
   前記コンテンツ鍵確認手段による確認結果に応じて前記コンテンツ復号手段による暗号化コンテンツの復号処理動作の継続又は停止を制御するコンテンツ復号処理制御手段を備え、
   前記コンテンツ復号処理制御手段は、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、前記コンテンツ鍵確認要求手段によるコンテンツ鍵の確認要求の再試行を所定期間だけ許容する、
   ことを特徴とする情報通信装置。
2. ＤＴＣＰ−ＩＰにおけるＳｉｎｋ機器として動作し、ＨＴＴＰプロトコルを用いてＳｏｕｒｃｅ機器との間でコンテンツ伝送を行なう際に、
   前記コンテンツ復号手段は、Ｓｏｕｒｃｅ機器との相互認証手続きを経て共有する認証鍵と暗号化コンテンツに付加されるノンスからコンテンツ鍵を生成して、暗号化コンテンツを復号処理し、
   コンテンツ鍵確認要求手段は、検査用ノンスを含んだコンテンツ鍵確認要求コマンドをＳｏｕｒｃｅ機器に送信し、
   前記コンテンツ鍵確認手段は、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信し且つ自らコンテンツ鍵の確認を行なって正しい鍵と判定するとｃｏｎｆｉｒｍｅｄ状態を出力し、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したが自らコンテンツ鍵の確認を行なって正しい鍵と判定できない場合又はＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときにｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態を出力する、
   ことを特徴とする請求項１に記載の情報通信装置。
3. ＤＴＣＰ−ＩＰにおいてｃｏｎｆｉｒｍｅｄ状態では前記コンテンツ復号手段による暗号化コンテンツの復号処理動作の継続が許容され、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態では所定期間だけ前記コンテンツ鍵確認要求手段によるコンテンツ鍵の確認要求の再試行が許容され、
   前記コンテンツ鍵確認手段は、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態を出力する、
   ことを特徴とする請求項２に記載の情報通信装置。
4. Ｓｏｕｒｃｅ機器から伝送される暗号化コンテンツを受信処理する情報通信方法であって、
   暗号化コンテンツを受信するコンテンツ受信ステップと、
   コンテンツ鍵を用いて暗号化コンテンツを復号処理するコンテンツ復号ステップと、
   Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認を要求するコンテンツ鍵確認要求ステップと、
   コンテンツ鍵確認要求に対するＳｏｕｒｃｅ機器からのレスポンスに応じて、コンテンツ鍵確認ステップと、
   前記コンテンツ鍵確認ステップにおける確認結果に応じて前記コンテンツ復号手段による暗号化コンテンツの復号処理動作の継続又は停止を制御するコンテンツ復号処理制御ステップを備え、
   前記コンテンツ復号処理制御ステップでは、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、前記コンテンツ鍵確認要求手段によるコンテンツ鍵の確認要求の再試行を所定期間だけ許容する、
   ことを特徴とする情報通信方法。
5. ＤＴＣＰ−ＩＰにおけるＳｉｎｋ機器として動作し、ＨＴＴＰプロトコルを用いてＳｏｕｒｃｅ機器との間でコンテンツ伝送を行なう際に、
   前記コンテンツ復号ステップでは、Ｓｏｕｒｃｅ機器との相互認証手続きを経て共有する認証鍵と暗号化コンテンツに付加されるノンスからコンテンツ鍵を生成して、暗号化コンテンツを復号処理し、
   コンテンツ鍵確認要求ステップでは、検査用ノンスを含んだコンテンツ鍵確認要求コマンドをＳｏｕｒｃｅ機器に送信し、
   前記コンテンツ鍵確認ステップでは、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信し且つ自らコンテンツ鍵の確認を行なって正しい鍵と判定するとｃｏｎｆｉｒｍｅｄ状態を出力し、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したが自らコンテンツ鍵の確認を行なって正しい鍵と判定できない場合又はＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときにｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態を出力する、
   ことを特徴とする請求項４に記載の情報通信方法。
6. ６
   ＤＴＣＰ−ＩＰにおいてｃｏｎｆｉｒｍｅｄ状態では前記コンテンツ復号ステップによる暗号化コンテンツの復号処理動作の継続が許容され、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態では所定期間だけ前記コンテンツ鍵確認要求ステップによるコンテンツ鍵の確認要求の再試行が許容され、
   前記コンテンツ鍵確認ステップでは、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態を出力する、
   ことを特徴とする請求項５に記載の情報通信方法。
7. Ｓｏｕｒｃｅ機器から伝送される暗号化コンテンツの受信処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
   暗号化コンテンツを受信するコンテンツ受信手順と、
   コンテンツ鍵を用いて暗号化コンテンツを復号処理するコンテンツ復号手順と、
   Ｓｏｕｒｃｅ機器に対してコンテンツ鍵の確認を要求するコンテンツ鍵確認要求手順と、
   コンテンツ鍵確認要求に対するＳｏｕｒｃｅ機器からのレスポンスに応じて、コンテンツ鍵確認手順と、
   前記コンテンツ鍵確認手順における確認結果に応じて前記コンテンツ復号手順による暗号化コンテンツの復号処理動作の継続又は停止を制御するコンテンツ復号処理制御手順を実行させ、
   前記コンテンツ復号処理制御手順では、コンテンツ鍵確認要求に対してＳｏｕｒｃｅ機器から所望のレスポンスが得られなかったとき、又はレスポンス受信待機期間がタイムアウトしたときに、前記コンテンツ鍵確認要求手順によるコンテンツ鍵の確認要求の再試行を所定期間だけ許容する、
   ことを特徴とするコンピュータ・プログラム。

Images