情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
【課題】 コンテンツ鍵を生成するコンテンツ伝送手続きが終了した後もコンテンツ鍵の確認を適正に実施する。
【解決手段】 Ｓｏｕｒｃｅ機器は、コンテンツ伝送用のＴＣＰコネクションが終了した後もノンスＮcを即座に削除しない。コンテンツ伝送用のＴＣＰコネクションが終了した後に、Ｓｉｎｋ機器側からコンテンツ鍵の確認要求を受けても、コンテンツ鍵の判定を適正に行なうことができる。Ｓｉｎｋ機器は、受信した暗号化コンテンツの復号処理を行なう際、コンテンツ鍵確認要求に対して正しい判定結果を得ることができるので、受信コンテンツの復号処理を停止しなくて済む。
【解決手段】 Ｓｏｕｒｃｅ機器は、コンテンツ伝送用のＴＣＰコネクションが終了した後もノンスＮcを即座に削除しない。コンテンツ伝送用のＴＣＰコネクションが終了した後に、Ｓｉｎｋ機器側からコンテンツ鍵の確認要求を受けても、コンテンツ鍵の判定を適正に行なうことができる。Ｓｉｎｋ機器は、受信した暗号化コンテンツの復号処理を行なう際、コンテンツ鍵確認要求に対して正しい判定結果を得ることができるので、受信コンテンツの復号処理を停止しなくて済む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを受信処理する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続き、並びにＨＴＴＰプロトコルを利用した暗号化コンテンツ伝送、並びに伝送コンテンツの復号処理を実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを介して共有されるコンテンツ鍵を使用して暗号化コンテンツの復号処理を実施する際にコンテンツ鍵の確認手続きを行なう情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。
【０００４】
しかしながら、この種のコンテンツはデジタル・データであることからコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。
【０００５】
デジタル・コンテンツの利用が盛んな今日においては、その著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。
【０００６】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００７】
コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。
【０００８】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。
【０００９】
ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれ、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。また、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。
【００１０】
ここで、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。
【００１１】
図６には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。同図に示す例では、コンテンツ伝送にはＨＴＴＰプロトコルが利用される。
【００１２】
ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや認証鍵Ｋ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の確認に成功すると、暗号化コンテンツの復号動作を回復することができる。
【００２６】
図７には、コンテンツ鍵確認のためのＳｉｎｋ機器とＳｏｕｒｃｅ機器間の手続きを示している。但し、Ｒは６４ビット値で、初期は乱数であるが、後続の試行では１ ｍｏｄ ２64でインクリメントするとともに、以下の通りとする。
【００２７】
ＭＸ＝ＳＨＡ−１（Ｋx||Ｋx）
ＭＡＣ３Ａ＝ＭＡＣ３Ｂ＝［ＳＨＡ−１（ＭＸ＋ＮcＴ＋Ｒ）］ｍｓｂ８０
ＭＡＣ４Ａ＝ＭＡＣ４Ｂ＝［ＳＨＡ−１（ＭＸ＋ＮcＴ＋Ｒ）］ｌｓｂ８０
（上式で、“＋”はｍｏｄ２64の加算を意味するために使用される。）
【００２８】
図示のコンテンツ確認手続きでは、Ｓｉｎｋ機器は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドにおいて、検査用のノンスＮcＴをＳｏｕｒｃｅ機器に送る。
【００２９】
Ｓｏｕｒｃｅ機器側では、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると、検査用のノンスＮcＴを取り出して、現在のノンスＮcと比較する。そして、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。検査用のノンスＮcＴが有効であることを確認できたときには、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、コンテンツ鍵が正しかったことを示すＡＣＣＥＰＴＥＤレスポンス、又は正しくなかったことを示すＲＥＪＥＣＴＥＤレスポンスのいずれかをＳｉｎｋ機器に返す。
【００３０】
Ｓｉｎｋ機器側では、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたときには、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、Ｓｉｎｋ機器自身でコンテンツ鍵が正しいことを確認できた場合にはＳｉｎｋ機器はｃｏｎｆｉｒｍｅｄ状態になる。
【００３１】
一方、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたがＳｉｎｋ機器自身でのコンテンツ鍵確認に失敗した場合や、Ｓｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスが返されたときには、Ｓｉｎｋ機器はｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になる。
【００３２】
ここで、ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が正しいことが確認された状態、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が不正であることが確認された状態であり、いずれもＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている。
【００３３】
ｃｏｎｆｉｒｍｅｄ状態では、Ｓｉｎｋ機器は受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態では、Ｓｉｎｋ機器は復号処理を継続できない。
【００３４】
図８には、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【００３５】
Ｓｏｕｒｃｅ機器は、コンテンツ伝送先となるＳｉｎｋ機器からコンテンツ確認を要求するＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると（ステップＳ１）、コンテンツ鍵の確認を行なう（ステップＳ２）。具体的には、当該コマンドから検査用のノンスＮcＴを取り出して、現在のノンスＮcと比較する。そして、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。
【００３６】
そして、Ｓｏｕｒｃｅ機器は、コンテンツ鍵が正しいことを確認した場合には その旨を示すＡＣＣＥＰＴＥＤレスポンスをＳｉｎｋ機器に返信するが（ステップＳ３）、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する（ステップＳ４）。
【００３７】
なお、ＡＣＣＥＰＴＥＤ並びにＲＥＪＥＣＴＥＤはともにＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている、コマンドに対するレスポンスである。
【００３８】
また、図９には、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【００３９】
Ｓｉｎｋ機器は、コンテンツ要求先となるＳｏｕｒｃｅ機器に対しＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信した後（ステップＳ１１）、当該Ｓｏｕｒｃｅ機器からのレスポンス受信を待機する（ステップＳ１２）。
【００４０】
ここで、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したときには（ステップＳ１３）、コンテンツ鍵を確認する（ステップＳ１４）。このとき、コンテンツ鍵が正しい場合にはｃｏｎｆｉｒｍｅｄ（ステップＳ１５）、コンテンツ鍵が不正である場合には ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ１７）。また、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときには（ステップＳ１６）、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ１７）。
【００４１】
ここで、ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が正しいことが確認された状態、ｎｏｎ−ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が不正であることが確認された状態であり、いずれもＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている。
【００４２】
ｃｏｎｆｉｒｍｅｄでは、Ｓｉｎｋ機器は受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍｅｄでは、Ｓｉｎｋ機器は復号処理を継続できない。
【００４３】
但し、Ｓｉｎｋ機器は、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間はコンテンツ鍵確認手続きを繰り返すことができるので（ステップＳ１８）、ステップＳ１１に戻り（ステップＳ２０）、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを再発行する。
【００４４】
コンテンツ鍵確認手続きを再試行して、１分以内にｃｏｎｆｉｒｍｅｄとなれば（ステップＳ１５）、受信コンテンツの復号処理を継続することができる。しかし、１分間ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎが継続した場合には（ステップＳ１８）、受信コンテンツの復号処理を直ちに停止しなければならない（ステップＳ１９）。
【００４５】
ＤＴＣＰ−ＩＰによりＳｏｕｒｃｅ機器からＳｉｎｋ機器へＨＴＴＰプロトコルを利用してコンテンツ伝送を行なう場合、以下の事柄を理解されたい。
【００４６】
（１）Ｓｏｕｒｃｅ機器とＳｉｎｋ機器間では、認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、コンテンツ鍵確認の手続き毎に、別々のＴＣＰコネクションを確立する。
（２）認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、コンテンツ鍵確認それぞれの手続きが終了すると、他の手続きが係属しているかどうかに拘らず、該当するＴＣＰコネクションを切断することができる。
（３）ＨＴＴＰプロトコルを利用したコンテンツ伝送用のＴＣＰコネクションを初期化する際に、Ｓｏｕｒｃｅ機器はノンスＮcを生成する。また、Ｓｏｕｒｃｅ機器は、ノンスＮcを動的に変更する。
【００４７】
ここで、ＤＴＣＰ−ＩＰの規格では、ノンスＮcの起点について最初のＴＣＰコネクションが確立される時と明記されているが、Ｎcの終点についての記述はない。したがって、Ｓｏｕｒｃｅ機器は、コンテンツ伝送用のＴＣＰコネクションが終了したときにＮ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の起点について最初のＴＣＰコネクションが確立される時と明記されているが、Ｎcの終点についての記述はないため、Ｓｏｕｒｃｅ機器側でＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドに対して適正なコンテンツ鍵確認処理を行なえなくなるという問題がある。
【０１１８】
例えば、コンテンツ受信後にもＳｉｎｋ機器側ではコンテンツ再生処理をしばらく継続している場合など、コンテンツ伝送用のＴＣＰコネクションを終了した後にもコンテンツ鍵確認手続きを行なわなければならないことがある。Ｓｉｎｋ機器がコンテンツ鍵の確認を行なうには、Ｓｏｕｒｃｅ機器側で生成又は更新したノンスＮcが必要である。しかしながら、コンテンツ伝送用のＴＣＰコネクションが終了した際にＳｏｕｒｃｅ機器がノンスＮcを既に削除してしまっていると、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦに対してコンテンツ鍵の判定を正しく行なうことができない。
【０１１９】
そこで、本実施形態では、Ｓｏｕｒｃｅ機器となる情報通信装置は、コンテンツ伝送用のＴＣＰコネクションが終了した後もノンスＮcを即座に削除せず、ＴＣＰコネクションが終了してから所定期間が経過した後に、ノンスＮcを削除するようにしている。ここでいう所定期間とは、例えばＳｉｎｋ機器側でコンテンツを受信完了してから暗号コンテンツの復号処理を終えるまでに要する数分程度の時間である。具体的には、コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するようにすることで、コンテンツ伝送用のＴＣＰコネクションが既に終了している状態でＳｉｎｋ機器側からコンテンツ鍵の確認要求を受けても、Ｓｏｕｒｃｅ機器はコンテンツ鍵の判定を適正に行なうことができる。
【０１２０】
図４には、Ｓｏｕｒｃｅ機器において、コンテンツ伝送手続き適応してコンテンツ鍵の生成と削除、並びにコンテンツ鍵確認手続きを行なうための機能的構成を模式的に示している。
【０１２１】
ＴＣＰコネクション確立部１１は、Ｓｉｎｋ機器からのＨＴＴＰリクエストなどのコンテンツ伝送要求などに応じて、Ｓｉｎｋ機器との間でコンテンツ伝送用のＴＣＰコネクションを確立する。
【０１２２】
ＴＣＰコネクション終了部１２は、Ｓｉｎｋ機器へのコンテンツ伝送が終了したときや、何らかの理由によりコンテンツ伝送を停止するときに、ＴＣＰコネクション確立部１１により確立されたＴＣＰコネクションを終了する。
【０１２３】
ノンス生成部１３は、ＴＣＰコネクション確立部１１によりコンテンツ伝送用のＴＣＰコネクションを初期化する際に、ノンスＮcを生成する。ノンスＮcから伝送コンテンツを暗号化／復号するためのコンテンツ鍵Ｋcを作成することができるが、その仕組みは図６を参照しながら説明した通りである。また、ノンス生成部１３は、１２８ＭＢのバイト・データ毎にノンスＮcを動的に変更する。
【０１２４】
ノンス削除部１４は、ＴＣＰコネクション終了部１２によりコンテンツ伝送用のＴＣＰコネクションが終了し、伝送コンテンツ暗号用のノンスＮcが不要となったときに、ノンス生成部１３により生成され当該システム内に保持されているノンスをシステムから削除する。本実施形態では、ノンス削除部１４は内部にタイマ機能（図示しない）を備え、ＴＣＰコネクション終了部１２によりＴＣＰコネクションが終了してからの経過時間を計時し、コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するようになっている。
【０１２５】
コマンド受信部１５は、コンテンツ伝送先となるＳｉｎｋ機器からのコンテンツ確認要求を受信する。Ｓｉｎｋ機器は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ ｓｕｂｆｕｎｃｔｉｏｎを用いて、現在のノンスＮcに関連付けられたコンテンツ鍵の確認を行なう。ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドには検査用のノンスＮcＴが含まれており、コマンド受信部１５は受信したＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドから検査用のノンスＮcＴを取り出して、コンテンツ鍵確認判定部１６に渡す。
【０１２６】
コンテンツ鍵確認判定部１６は、検査用のノンスＮcＴと現在のノンスＮcと比較して、その確認判定を行なう。具体的には、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。
【０１２７】
レスポンス返信部１７は、コンテンツ鍵確認判定部１６におけるコンテンツ鍵の確認判定結果のレスポンスを要求元のＳｉｎｋ機器に送信する。コンテンツ鍵が正しいことを確認した場合にはＡＣＣＥＰＴＥＤレスポンスを、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する。
【０１２８】
図５には、図４に示した機能的構成を備えたＳｏｕｒｃｅ機器において、コンテンツ伝送手続きに伴うノンスＮcの生成及び削除とコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【０１２９】
ノンス生成部１３は、ＴＣＰコネクション確立部１１においてコンテンツ伝送用のＴＣＰコネクションを初期化する際にノンスＮcを生成する（ステップＳ４１）。そして、当該ＴＣＰコネクションを確立してから（ステップＳ４２）、ＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう。
【０１３０】
その後、コンテンツ伝送を終了すると、ＴＣＰコネクション終了部１２はＴＣＰコネクションを終了する（ステップＳ４３）。そして、ノンス削除部１４は、ＴＣＰコネクション終了に応答して、ノンスＮcを削除するタイミングを決定するためにタイマを起動する（ステップＳ４４）。
【０１３１】
一方、Ｓｉｎｋ機器側では、受信した暗号コンテンツを復号処理する際、必要に応じてコンテンツ鍵の確認を要求するＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信する。
【０１３２】
コマンド受信部１５は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると（ステップＳ４５）、当該コマンドから検査用のノンスＮcＴを取り出して、コンテンツ鍵確認判定部１６に渡す。
【０１３３】
コンテンツ鍵確認判定部１６は、検査用のノンスＮcＴと現在のノンスＮcと比較して、その確認判定を行なう（ステップＳ４６）。すなわち、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。コンテンツ鍵を確認処理するには、Ｓｏｕｒｃｅ機器がノンスＮcを保持している必要がある。ここでは、ノンスＮc削除用のタイマがタイムアウトしていないので、Ｓｏｕｒｃｅ機器は適正にコンテンツ鍵の確認処理を実施することができる。
【０１３４】
レスポンス返信部１７は、コンテンツ鍵確認判定部１６におけるコンテンツ鍵の確認判定結果のレスポンスを要求元のＳｉｎｋ機器に送信する。コンテンツ鍵が正しいことを確認した場合にはＡＣＣＥＰＴＥＤレスポンスを返信し（ステップＳ４７）、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する（ステップＳ４８）。
【０１３５】
そして、ノンス削除部１４は、ＴＣＰコネクション終了に応答して起動したタイマがタイムアウトすると（ステップＳ４９）、ノンス生成部１３により生成され当該システム内に保持されているノンスＮcをシステムから削除する。これは、コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除することに相当する。
【０１３６】
一方、Ｓｉｎｋ機器は図９に示した処理手順に従ってコンテンツ鍵確認手続きを実施すればよい。上述したように、Ｓｏｕｒｃｅ機器は、コンテンツ伝送用のＴＣＰコネクションが終了した後もノンスＮcを即座に削除しない。したがって、Ｓｉｎｋ機器は、コンテンツ伝送用のＴＣＰコネクションが既に終了している状態であっても、受信した暗号化コンテンツの復号処理を行なう際などにおいてコンテンツ鍵を確認する必要が生じたときには、Ｓｏｕｒｃｅ機器に対してコンテンツ鍵確認要求を発行し、正しい判定結果を得ることができるので、受信コンテンツの復号処理を停止しなくて済む。
【産業上の利用可能性】
【０１３７】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１３８】
本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立されるという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。ＩＰプロトコルを利用したコンテンツ伝送手続きにおいて、暗号化コンテンツ伝送と、暗号化コンテンツの復号鍵の確認手続き用にそれぞれ別のＴＣＰコネクションを確立するような他のタイプの情報通信システムに対しても、同様に本発明を適用することができる。
【０１３９】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【０１４０】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図３】図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図４】図４は、Ｓｏｕｒｃｅ機器において、コンテンツ伝送手続きに適応してコンテンツ鍵の生成と削除、並びにコンテンツ鍵確認手続きを行なうための機能的構成を模式的に示した図である。
【図５】図５は、図４に示した機能的構成を備えたＳｏｕｒｃｅ機器において、コンテンツ伝送手続きに伴うノンスＮcの生成及び削除とコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図６】図６は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図７】図７は、コンテンツ鍵確認のためのＳｉｎｋ機器とＳｏｕｒｃｅ機器間の手続きを示した図である。
【図８】図８は、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図９】図９は、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図１０】図１０は、Ｓｏｕｒｃｅ機器がコンテンツ伝送手続きに伴うノンスＮcの生成及び削除とコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【符号の説明】
【０１４１】
１１…ＴＣＰコネクション確立部
１２…ＴＣＰコネクション終了部
１３…ノンス生成部
１４…ノンス削除部
１５…コマンド受信部
１６…コンテンツ鍵確認判定部
１７…レスポンス返信部
【技術分野】
【０００１】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを受信処理する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続き、並びにＨＴＴＰプロトコルを利用した暗号化コンテンツ伝送、並びに伝送コンテンツの復号処理を実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを介して共有されるコンテンツ鍵を使用して暗号化コンテンツの復号処理を実施する際にコンテンツ鍵の確認手続きを行なう情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。
【０００４】
しかしながら、この種のコンテンツはデジタル・データであることからコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。
【０００５】
デジタル・コンテンツの利用が盛んな今日においては、その著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。
【０００６】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００７】
コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。
【０００８】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。
【０００９】
ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれ、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。また、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。
【００１０】
ここで、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。
【００１１】
図６には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。同図に示す例では、コンテンツ伝送にはＨＴＴＰプロトコルが利用される。
【００１２】
ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや認証鍵Ｋ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の確認に成功すると、暗号化コンテンツの復号動作を回復することができる。
【００２６】
図７には、コンテンツ鍵確認のためのＳｉｎｋ機器とＳｏｕｒｃｅ機器間の手続きを示している。但し、Ｒは６４ビット値で、初期は乱数であるが、後続の試行では１ ｍｏｄ ２64でインクリメントするとともに、以下の通りとする。
【００２７】
ＭＸ＝ＳＨＡ−１（Ｋx||Ｋx）
ＭＡＣ３Ａ＝ＭＡＣ３Ｂ＝［ＳＨＡ−１（ＭＸ＋ＮcＴ＋Ｒ）］ｍｓｂ８０
ＭＡＣ４Ａ＝ＭＡＣ４Ｂ＝［ＳＨＡ−１（ＭＸ＋ＮcＴ＋Ｒ）］ｌｓｂ８０
（上式で、“＋”はｍｏｄ２64の加算を意味するために使用される。）
【００２８】
図示のコンテンツ確認手続きでは、Ｓｉｎｋ機器は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドにおいて、検査用のノンスＮcＴをＳｏｕｒｃｅ機器に送る。
【００２９】
Ｓｏｕｒｃｅ機器側では、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると、検査用のノンスＮcＴを取り出して、現在のノンスＮcと比較する。そして、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。検査用のノンスＮcＴが有効であることを確認できたときには、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、コンテンツ鍵が正しかったことを示すＡＣＣＥＰＴＥＤレスポンス、又は正しくなかったことを示すＲＥＪＥＣＴＥＤレスポンスのいずれかをＳｉｎｋ機器に返す。
【００３０】
Ｓｉｎｋ機器側では、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたときには、さらにＭＡＣ４ＡとＭＡＣ４Ｂが等しいかどうかに基づいてコンテンツ鍵の確認を行なう。そして、Ｓｉｎｋ機器自身でコンテンツ鍵が正しいことを確認できた場合にはＳｉｎｋ機器はｃｏｎｆｉｒｍｅｄ状態になる。
【００３１】
一方、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスが返されたがＳｉｎｋ機器自身でのコンテンツ鍵確認に失敗した場合や、Ｓｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスが返されたときには、Ｓｉｎｋ機器はｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態になる。
【００３２】
ここで、ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が正しいことが確認された状態、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が不正であることが確認された状態であり、いずれもＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている。
【００３３】
ｃｏｎｆｉｒｍｅｄ状態では、Ｓｉｎｋ機器は受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎ状態では、Ｓｉｎｋ機器は復号処理を継続できない。
【００３４】
図８には、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【００３５】
Ｓｏｕｒｃｅ機器は、コンテンツ伝送先となるＳｉｎｋ機器からコンテンツ確認を要求するＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると（ステップＳ１）、コンテンツ鍵の確認を行なう（ステップＳ２）。具体的には、当該コマンドから検査用のノンスＮcＴを取り出して、現在のノンスＮcと比較する。そして、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。
【００３６】
そして、Ｓｏｕｒｃｅ機器は、コンテンツ鍵が正しいことを確認した場合には その旨を示すＡＣＣＥＰＴＥＤレスポンスをＳｉｎｋ機器に返信するが（ステップＳ３）、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する（ステップＳ４）。
【００３７】
なお、ＡＣＣＥＰＴＥＤ並びにＲＥＪＥＣＴＥＤはともにＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている、コマンドに対するレスポンスである。
【００３８】
また、図９には、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器との間でコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【００３９】
Ｓｉｎｋ機器は、コンテンツ要求先となるＳｏｕｒｃｅ機器に対しＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信した後（ステップＳ１１）、当該Ｓｏｕｒｃｅ機器からのレスポンス受信を待機する（ステップＳ１２）。
【００４０】
ここで、Ｓｏｕｒｃｅ機器からＡＣＣＥＰＴＥＤレスポンスを受信したときには（ステップＳ１３）、コンテンツ鍵を確認する（ステップＳ１４）。このとき、コンテンツ鍵が正しい場合にはｃｏｎｆｉｒｍｅｄ（ステップＳ１５）、コンテンツ鍵が不正である場合には ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ１７）。また、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器からＲＥＪＥＣＴＥＤレスポンスを受信したときには（ステップＳ１６）、ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎである（ステップＳ１７）。
【００４１】
ここで、ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が正しいことが確認された状態、ｎｏｎ−ｃｏｎｆｉｒｍｅｄはＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦによりコンテンツ鍵が不正であることが確認された状態であり、いずれもＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ ＳｅｃｔｉｏｎＶ１ＳＥ８．６に規定されている。
【００４２】
ｃｏｎｆｉｒｍｅｄでは、Ｓｉｎｋ機器は受信コンテンツの復号処理を継続して行なうことができる。他方、ｎｏｎ−ｃｏｎｆｉｒｍｅｄでは、Ｓｉｎｋ機器は復号処理を継続できない。
【００４３】
但し、Ｓｉｎｋ機器は、最初のｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎとなってから１分間はコンテンツ鍵確認手続きを繰り返すことができるので（ステップＳ１８）、ステップＳ１１に戻り（ステップＳ２０）、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを再発行する。
【００４４】
コンテンツ鍵確認手続きを再試行して、１分以内にｃｏｎｆｉｒｍｅｄとなれば（ステップＳ１５）、受信コンテンツの復号処理を継続することができる。しかし、１分間ｎｏｎ−ｃｏｎｆｉｒｍａｔｉｏｎが継続した場合には（ステップＳ１８）、受信コンテンツの復号処理を直ちに停止しなければならない（ステップＳ１９）。
【００４５】
ＤＴＣＰ−ＩＰによりＳｏｕｒｃｅ機器からＳｉｎｋ機器へＨＴＴＰプロトコルを利用してコンテンツ伝送を行なう場合、以下の事柄を理解されたい。
【００４６】
（１）Ｓｏｕｒｃｅ機器とＳｉｎｋ機器間では、認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、コンテンツ鍵確認の手続き毎に、別々のＴＣＰコネクションを確立する。
（２）認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、コンテンツ鍵確認それぞれの手続きが終了すると、他の手続きが係属しているかどうかに拘らず、該当するＴＣＰコネクションを切断することができる。
（３）ＨＴＴＰプロトコルを利用したコンテンツ伝送用のＴＣＰコネクションを初期化する際に、Ｓｏｕｒｃｅ機器はノンスＮcを生成する。また、Ｓｏｕｒｃｅ機器は、ノンスＮcを動的に変更する。
【００４７】
ここで、ＤＴＣＰ−ＩＰの規格では、ノンスＮcの起点について最初のＴＣＰコネクションが確立される時と明記されているが、Ｎcの終点についての記述はない。したがって、Ｓｏｕｒｃｅ機器は、コンテンツ伝送用のＴＣＰコネクションが終了したときにＮ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の起点について最初のＴＣＰコネクションが確立される時と明記されているが、Ｎcの終点についての記述はないため、Ｓｏｕｒｃｅ機器側でＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドに対して適正なコンテンツ鍵確認処理を行なえなくなるという問題がある。
【０１１８】
例えば、コンテンツ受信後にもＳｉｎｋ機器側ではコンテンツ再生処理をしばらく継続している場合など、コンテンツ伝送用のＴＣＰコネクションを終了した後にもコンテンツ鍵確認手続きを行なわなければならないことがある。Ｓｉｎｋ機器がコンテンツ鍵の確認を行なうには、Ｓｏｕｒｃｅ機器側で生成又は更新したノンスＮcが必要である。しかしながら、コンテンツ伝送用のＴＣＰコネクションが終了した際にＳｏｕｒｃｅ機器がノンスＮcを既に削除してしまっていると、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦに対してコンテンツ鍵の判定を正しく行なうことができない。
【０１１９】
そこで、本実施形態では、Ｓｏｕｒｃｅ機器となる情報通信装置は、コンテンツ伝送用のＴＣＰコネクションが終了した後もノンスＮcを即座に削除せず、ＴＣＰコネクションが終了してから所定期間が経過した後に、ノンスＮcを削除するようにしている。ここでいう所定期間とは、例えばＳｉｎｋ機器側でコンテンツを受信完了してから暗号コンテンツの復号処理を終えるまでに要する数分程度の時間である。具体的には、コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するようにすることで、コンテンツ伝送用のＴＣＰコネクションが既に終了している状態でＳｉｎｋ機器側からコンテンツ鍵の確認要求を受けても、Ｓｏｕｒｃｅ機器はコンテンツ鍵の判定を適正に行なうことができる。
【０１２０】
図４には、Ｓｏｕｒｃｅ機器において、コンテンツ伝送手続き適応してコンテンツ鍵の生成と削除、並びにコンテンツ鍵確認手続きを行なうための機能的構成を模式的に示している。
【０１２１】
ＴＣＰコネクション確立部１１は、Ｓｉｎｋ機器からのＨＴＴＰリクエストなどのコンテンツ伝送要求などに応じて、Ｓｉｎｋ機器との間でコンテンツ伝送用のＴＣＰコネクションを確立する。
【０１２２】
ＴＣＰコネクション終了部１２は、Ｓｉｎｋ機器へのコンテンツ伝送が終了したときや、何らかの理由によりコンテンツ伝送を停止するときに、ＴＣＰコネクション確立部１１により確立されたＴＣＰコネクションを終了する。
【０１２３】
ノンス生成部１３は、ＴＣＰコネクション確立部１１によりコンテンツ伝送用のＴＣＰコネクションを初期化する際に、ノンスＮcを生成する。ノンスＮcから伝送コンテンツを暗号化／復号するためのコンテンツ鍵Ｋcを作成することができるが、その仕組みは図６を参照しながら説明した通りである。また、ノンス生成部１３は、１２８ＭＢのバイト・データ毎にノンスＮcを動的に変更する。
【０１２４】
ノンス削除部１４は、ＴＣＰコネクション終了部１２によりコンテンツ伝送用のＴＣＰコネクションが終了し、伝送コンテンツ暗号用のノンスＮcが不要となったときに、ノンス生成部１３により生成され当該システム内に保持されているノンスをシステムから削除する。本実施形態では、ノンス削除部１４は内部にタイマ機能（図示しない）を備え、ＴＣＰコネクション終了部１２によりＴＣＰコネクションが終了してからの経過時間を計時し、コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するようになっている。
【０１２５】
コマンド受信部１５は、コンテンツ伝送先となるＳｉｎｋ機器からのコンテンツ確認要求を受信する。Ｓｉｎｋ機器は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ ｓｕｂｆｕｎｃｔｉｏｎを用いて、現在のノンスＮcに関連付けられたコンテンツ鍵の確認を行なう。ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドには検査用のノンスＮcＴが含まれており、コマンド受信部１５は受信したＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドから検査用のノンスＮcＴを取り出して、コンテンツ鍵確認判定部１６に渡す。
【０１２６】
コンテンツ鍵確認判定部１６は、検査用のノンスＮcＴと現在のノンスＮcと比較して、その確認判定を行なう。具体的には、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。
【０１２７】
レスポンス返信部１７は、コンテンツ鍵確認判定部１６におけるコンテンツ鍵の確認判定結果のレスポンスを要求元のＳｉｎｋ機器に送信する。コンテンツ鍵が正しいことを確認した場合にはＡＣＣＥＰＴＥＤレスポンスを、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する。
【０１２８】
図５には、図４に示した機能的構成を備えたＳｏｕｒｃｅ機器において、コンテンツ伝送手続きに伴うノンスＮcの生成及び削除とコンテンツ鍵確認手続きを行なうための処理手順をフローチャートの形式で示している。
【０１２９】
ノンス生成部１３は、ＴＣＰコネクション確立部１１においてコンテンツ伝送用のＴＣＰコネクションを初期化する際にノンスＮcを生成する（ステップＳ４１）。そして、当該ＴＣＰコネクションを確立してから（ステップＳ４２）、ＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう。
【０１３０】
その後、コンテンツ伝送を終了すると、ＴＣＰコネクション終了部１２はＴＣＰコネクションを終了する（ステップＳ４３）。そして、ノンス削除部１４は、ＴＣＰコネクション終了に応答して、ノンスＮcを削除するタイミングを決定するためにタイマを起動する（ステップＳ４４）。
【０１３１】
一方、Ｓｉｎｋ機器側では、受信した暗号コンテンツを復号処理する際、必要に応じてコンテンツ鍵の確認を要求するＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを送信する。
【０１３２】
コマンド受信部１５は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦコマンドを受信すると（ステップＳ４５）、当該コマンドから検査用のノンスＮcＴを取り出して、コンテンツ鍵確認判定部１６に渡す。
【０１３３】
コンテンツ鍵確認判定部１６は、検査用のノンスＮcＴと現在のノンスＮcと比較して、その確認判定を行なう（ステップＳ４６）。すなわち、現在のノンスＮcがＮcＴとＮcＴ＋５の範囲にあるときには検査用のノンスＮcＴが有効であることを確認する。コンテンツ鍵を確認処理するには、Ｓｏｕｒｃｅ機器がノンスＮcを保持している必要がある。ここでは、ノンスＮc削除用のタイマがタイムアウトしていないので、Ｓｏｕｒｃｅ機器は適正にコンテンツ鍵の確認処理を実施することができる。
【０１３４】
レスポンス返信部１７は、コンテンツ鍵確認判定部１６におけるコンテンツ鍵の確認判定結果のレスポンスを要求元のＳｉｎｋ機器に送信する。コンテンツ鍵が正しいことを確認した場合にはＡＣＣＥＰＴＥＤレスポンスを返信し（ステップＳ４７）、コンテンツ鍵が不正であることを確認した場合にはその旨を示すＲＥＪＥＣＴＥＤレスポンスを返信する（ステップＳ４８）。
【０１３５】
そして、ノンス削除部１４は、ＴＣＰコネクション終了に応答して起動したタイマがタイムアウトすると（ステップＳ４９）、ノンス生成部１３により生成され当該システム内に保持されているノンスＮcをシステムから削除する。これは、コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除することに相当する。
【０１３６】
一方、Ｓｉｎｋ機器は図９に示した処理手順に従ってコンテンツ鍵確認手続きを実施すればよい。上述したように、Ｓｏｕｒｃｅ機器は、コンテンツ伝送用のＴＣＰコネクションが終了した後もノンスＮcを即座に削除しない。したがって、Ｓｉｎｋ機器は、コンテンツ伝送用のＴＣＰコネクションが既に終了している状態であっても、受信した暗号化コンテンツの復号処理を行なう際などにおいてコンテンツ鍵を確認する必要が生じたときには、Ｓｏｕｒｃｅ機器に対してコンテンツ鍵確認要求を発行し、正しい判定結果を得ることができるので、受信コンテンツの復号処理を停止しなくて済む。
【産業上の利用可能性】
【０１３７】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１３８】
本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立されるという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。ＩＰプロトコルを利用したコンテンツ伝送手続きにおいて、暗号化コンテンツ伝送と、暗号化コンテンツの復号鍵の確認手続き用にそれぞれ別のＴＣＰコネクションを確立するような他のタイプの情報通信システムに対しても、同様に本発明を適用することができる。
【０１３９】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【０１４０】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図３】図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図４】図４は、Ｓｏｕｒｃｅ機器において、コンテンツ伝送手続きに適応してコンテンツ鍵の生成と削除、並びにコンテンツ鍵確認手続きを行なうための機能的構成を模式的に示した図である。
【図５】図５は、図４に示した機能的構成を備えたＳｏｕｒｃｅ機器において、コンテンツ伝送手続きに伴うノンスＮcの生成及び削除とコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図６】図６は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図７】図７は、コンテンツ鍵確認のためのＳｉｎｋ機器とＳｏｕｒｃｅ機器間の手続きを示した図である。
【図８】図８は、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図９】図９は、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器との間でコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【図１０】図１０は、Ｓｏｕｒｃｅ機器がコンテンツ伝送手続きに伴うノンスＮcの生成及び削除とコンテンツ鍵確認手続きを行なうための処理手順を示したフローチャートである。
【符号の説明】
【０１４１】
１１…ＴＣＰコネクション確立部
１２…ＴＣＰコネクション終了部
１３…ノンス生成部
１４…ノンス削除部
１５…コマンド受信部
１６…コンテンツ鍵確認判定部
１７…レスポンス返信部
【特許請求の範囲】
【請求項１】
コンテンツを暗号化伝送する情報通信装置であって、
コンテンツ鍵を生成するコンテンツ鍵生成手段と、
コンテンツ鍵を用いてコンテンツを暗号化するコンテンツ暗号化手段と、
暗号化コンテンツを伝送するコンテンツ伝送手段と、
コンテンツ伝送先となる機器からのコンテンツ鍵確認要求に応じて、前記コンテンツ鍵生成手段により生成したコンテンツ鍵を正誤判定するコンテンツ鍵確認手段と、
コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するコンテンツ鍵削除手段と、
を具備することを特徴とする情報通信装置。
【請求項２】
ＤＴＣＰ−ＩＰにおけるＳｏｕｒｃｅ機器として動作し、ＨＴＴＰプロトコルを用いてＳｉｎｋ機器にコンテンツ伝送を行ない、
Ｓｉｎｋ機器との間で、相互認証、コンテンツ伝送、及びコンテンツ鍵確認の各手続きを行なうためのＴＣＰコネクションの確立及び終了を行なうＴＣＰコネクション管理手段をさらに備える、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項３】
Ｓｉｎｋ機器との相互認証手続きの際に認証鍵を共有し、
前記コンテンツ鍵生成手段はノンスを生成し、
前記コンテンツ暗号化手段は、認証鍵及びノンスを用いて得られる暗号鍵を用いてコンテンツを暗号化し、
前記コンテンツ伝送手段は、暗号化コンテンツにノンスを付加してコンテンツ伝送を行ない、
前記コンテンツ鍵確認手段は、検査用ノンスを含んだコンテンツ鍵確認要求コマンドを受信して、該検査用ノンスと前記コンテンツ鍵生成手段により生成したノンスと正誤判定し、結果をＳｉｎｋ機器に通知する、
ことを特徴とする請求項２に記載の情報通信装置。
【請求項４】
前記コンテンツ鍵生成手段は、前記コンテンツ伝送手段がコンテンツ伝送を行なう期間において、ノンスを動的に変更する、
ことを特徴とする請求項３に記載の情報通信装置。
【請求項５】
前記コンテンツ鍵生成手段は、Ｓｉｎｋ機器との間でコンテンツ伝送用のＴＣＰコネクションを初期化する際にノンスを生成し、
前記コンテンツ鍵削除手段は、Ｓｉｎｋ機器とのコンテンツ伝送用のＴＣＰコネクションを終了してから所定期間が経過した後にコンテンツ鍵を削除する、
ことを特徴とする請求項３に記載の情報通信装置。
【請求項６】
コンテンツを暗号化伝送する情報通信方法であって、
コンテンツ鍵を生成するコンテンツ鍵生成ステップと、
コンテンツ鍵を用いてコンテンツを暗号化するコンテンツ暗号化ステップと、
暗号化コンテンツを伝送するコンテンツ伝送ステップと、
コンテンツ伝送先となる機器からのコンテンツ鍵確認要求に応じて、前記コンテンツ鍵生成手段により生成したコンテンツ鍵を正誤判定するコンテンツ鍵確認ステップと、
コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するコンテンツ鍵削除ステップと、
を具備することを特徴とする情報通信方法。
【請求項７】
ＤＴＣＰ−ＩＰにおけるＳｏｕｒｃｅ機器として動作し、ＨＴＴＰプロトコルを用いてＳｉｎｋ機器にコンテンツ伝送を行なう際に、
Ｓｉｎｋ機器との間で、相互認証、コンテンツ伝送、及びコンテンツ鍵確認の各手続きを行なうためのＴＣＰコネクションの確立及び終了を行なうＴＣＰコネクション管理ステップをさらに備える、
ことを特徴とする請求項６に記載の情報通信方法。
【請求項８】
Ｓｉｎｋ機器との相互認証手続きの際に認証鍵を共有し、
前記コンテンツ鍵生成ステップではノンスを生成し、
前記コンテンツ暗号化ステップでは、認証鍵及びノンスを用いて得られる暗号鍵を用いてコンテンツを暗号化し、
前記コンテンツ伝送ステップでは、暗号化コンテンツにノンスを付加してコンテンツ伝送を行ない、
前記コンテンツ鍵確認ステップでは、検査用ノンスを含んだコンテンツ鍵確認要求コマンドを受信して、該検査用ノンスと前記コンテンツ鍵生成手段により生成したノンスと正誤判定し、結果をＳｉｎｋ機器に通知する、
ことを特徴とする請求項７に記載の情報通信方法。
【請求項９】
前記コンテンツ鍵生成ステップでは、前記コンテンツ伝送手段がコンテンツ伝送を行なう期間において、ノンスを動的に変更する、
ことを特徴とする請求項８に記載の情報通信方法。
【請求項１０】
前記コンテンツ鍵生成ステップでは、Ｓｉｎｋ機器との間でコンテンツ伝送用のＴＣＰコネクションを初期化する際にコンテンツ鍵を生成し、
前記コンテンツ鍵削除ステップでは、Ｓｉｎｋ機器とのコンテンツ伝送用のＴＣＰコネクションを終了してから所定期間が経過した後にコンテンツ鍵を削除する、
ことを特徴とする請求項８に記載の情報通信方法。
【請求項１１】
１
コンテンツを暗号化伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
コンテンツ鍵を生成するコンテンツ鍵生成手順と、
コンテンツ鍵を用いてコンテンツを暗号化するコンテンツ暗号化手順と、
暗号化コンテンツを伝送するコンテンツ伝送手順と、
コンテンツ伝送先となる機器からのコンテンツ鍵確認要求に応じて、前記コンテンツ鍵生成手段により生成したコンテンツ鍵を正誤判定するコンテンツ鍵確認手順と、
コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するコンテンツ鍵削除手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【請求項１】
コンテンツを暗号化伝送する情報通信装置であって、
コンテンツ鍵を生成するコンテンツ鍵生成手段と、
コンテンツ鍵を用いてコンテンツを暗号化するコンテンツ暗号化手段と、
暗号化コンテンツを伝送するコンテンツ伝送手段と、
コンテンツ伝送先となる機器からのコンテンツ鍵確認要求に応じて、前記コンテンツ鍵生成手段により生成したコンテンツ鍵を正誤判定するコンテンツ鍵確認手段と、
コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するコンテンツ鍵削除手段と、
を具備することを特徴とする情報通信装置。
【請求項２】
ＤＴＣＰ−ＩＰにおけるＳｏｕｒｃｅ機器として動作し、ＨＴＴＰプロトコルを用いてＳｉｎｋ機器にコンテンツ伝送を行ない、
Ｓｉｎｋ機器との間で、相互認証、コンテンツ伝送、及びコンテンツ鍵確認の各手続きを行なうためのＴＣＰコネクションの確立及び終了を行なうＴＣＰコネクション管理手段をさらに備える、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項３】
Ｓｉｎｋ機器との相互認証手続きの際に認証鍵を共有し、
前記コンテンツ鍵生成手段はノンスを生成し、
前記コンテンツ暗号化手段は、認証鍵及びノンスを用いて得られる暗号鍵を用いてコンテンツを暗号化し、
前記コンテンツ伝送手段は、暗号化コンテンツにノンスを付加してコンテンツ伝送を行ない、
前記コンテンツ鍵確認手段は、検査用ノンスを含んだコンテンツ鍵確認要求コマンドを受信して、該検査用ノンスと前記コンテンツ鍵生成手段により生成したノンスと正誤判定し、結果をＳｉｎｋ機器に通知する、
ことを特徴とする請求項２に記載の情報通信装置。
【請求項４】
前記コンテンツ鍵生成手段は、前記コンテンツ伝送手段がコンテンツ伝送を行なう期間において、ノンスを動的に変更する、
ことを特徴とする請求項３に記載の情報通信装置。
【請求項５】
前記コンテンツ鍵生成手段は、Ｓｉｎｋ機器との間でコンテンツ伝送用のＴＣＰコネクションを初期化する際にノンスを生成し、
前記コンテンツ鍵削除手段は、Ｓｉｎｋ機器とのコンテンツ伝送用のＴＣＰコネクションを終了してから所定期間が経過した後にコンテンツ鍵を削除する、
ことを特徴とする請求項３に記載の情報通信装置。
【請求項６】
コンテンツを暗号化伝送する情報通信方法であって、
コンテンツ鍵を生成するコンテンツ鍵生成ステップと、
コンテンツ鍵を用いてコンテンツを暗号化するコンテンツ暗号化ステップと、
暗号化コンテンツを伝送するコンテンツ伝送ステップと、
コンテンツ伝送先となる機器からのコンテンツ鍵確認要求に応じて、前記コンテンツ鍵生成手段により生成したコンテンツ鍵を正誤判定するコンテンツ鍵確認ステップと、
コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するコンテンツ鍵削除ステップと、
を具備することを特徴とする情報通信方法。
【請求項７】
ＤＴＣＰ−ＩＰにおけるＳｏｕｒｃｅ機器として動作し、ＨＴＴＰプロトコルを用いてＳｉｎｋ機器にコンテンツ伝送を行なう際に、
Ｓｉｎｋ機器との間で、相互認証、コンテンツ伝送、及びコンテンツ鍵確認の各手続きを行なうためのＴＣＰコネクションの確立及び終了を行なうＴＣＰコネクション管理ステップをさらに備える、
ことを特徴とする請求項６に記載の情報通信方法。
【請求項８】
Ｓｉｎｋ機器との相互認証手続きの際に認証鍵を共有し、
前記コンテンツ鍵生成ステップではノンスを生成し、
前記コンテンツ暗号化ステップでは、認証鍵及びノンスを用いて得られる暗号鍵を用いてコンテンツを暗号化し、
前記コンテンツ伝送ステップでは、暗号化コンテンツにノンスを付加してコンテンツ伝送を行ない、
前記コンテンツ鍵確認ステップでは、検査用ノンスを含んだコンテンツ鍵確認要求コマンドを受信して、該検査用ノンスと前記コンテンツ鍵生成手段により生成したノンスと正誤判定し、結果をＳｉｎｋ機器に通知する、
ことを特徴とする請求項７に記載の情報通信方法。
【請求項９】
前記コンテンツ鍵生成ステップでは、前記コンテンツ伝送手段がコンテンツ伝送を行なう期間において、ノンスを動的に変更する、
ことを特徴とする請求項８に記載の情報通信方法。
【請求項１０】
前記コンテンツ鍵生成ステップでは、Ｓｉｎｋ機器との間でコンテンツ伝送用のＴＣＰコネクションを初期化する際にコンテンツ鍵を生成し、
前記コンテンツ鍵削除ステップでは、Ｓｉｎｋ機器とのコンテンツ伝送用のＴＣＰコネクションを終了してから所定期間が経過した後にコンテンツ鍵を削除する、
ことを特徴とする請求項８に記載の情報通信方法。
【請求項１１】
１
コンテンツを暗号化伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
コンテンツ鍵を生成するコンテンツ鍵生成手順と、
コンテンツ鍵を用いてコンテンツを暗号化するコンテンツ暗号化手順と、
暗号化コンテンツを伝送するコンテンツ伝送手順と、
コンテンツ伝送先となる機器からのコンテンツ鍵確認要求に応じて、前記コンテンツ鍵生成手段により生成したコンテンツ鍵を正誤判定するコンテンツ鍵確認手順と、
コンテンツ鍵の正誤判定が不要となるタイミングでコンテンツ鍵を削除するコンテンツ鍵削除手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００７−３６９５２（Ｐ２００７−３６９５２Ａ）
【公開日】平成１９年２月８日（２００７．２．８）
【国際特許分類】
【出願番号】特願２００５−２２０４７３（Ｐ２００５−２２０４７３）
【出願日】平成１７年７月２９日（２００５．７．２９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成１９年２月８日（２００７．２．８）
【国際特許分類】
【出願日】平成１７年７月２９日（２００５．７．２９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]