(57)【要約】【課題】  ＡＫＥを経て共有される鍵をアプリケーションからアクセス不可能な通信プロトコル・レイヤで管理して秘匿性を保つ。【解決手段】  Ｓｏｕｒｃｅ機器とＳｉｎｋ機器の間でＡＫＥを実行する際に、秘匿性のあるデータ値を直接操作できる秘匿データ操作可能レイヤと、直接操作できない秘匿データ操作不可レイヤを設け、Ｋxを秘匿データ操作可能レイヤで管理し、秘匿データ操作不可レイヤにはＫxと結び付いているＫx識別情報を格納する。ＤＴＣＰ−ＩＰアプリケーション、秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスする。【選択図】  図５
2007043475.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワーク上で、情報通信機器間で相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）を実施する情報通信システムであって、
各情報通信機器において、秘匿性のあるデータ値に対し直接的な操作を行なうことができる秘匿データ操作可能レイヤと、かかるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設け、
情報通信機器間でＡＫＥを実施して生成又は取得した交換鍵データＫxを秘匿データ操作可能レイヤで管理するとともに、秘匿データ操作不可レイヤにはＫxと結び付いているＫx識別情報を格納し、
情報通信機器上で起動するアプリケーション毎に１つの秘匿データ操作不可レイヤが起動し、各アプリケーションは秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスする、
ことを特徴とする情報通信システム。
【請求項２】
２つの情報通信機器のアプリケーション同士でＡＫＥを実施する際に、各情報通信機器において、
秘匿データ操作不可レイヤは、アプリケーションから取得した相手機器の識別情報を秘匿データ操作可能レイヤに渡し、
秘匿データ操作可能レイヤは、相手機器との認証を識別する機器認証セッション情報を秘匿データ操作不可レイヤに返す、
ことを特徴とする請求項１に記載の情報通信システム。
【請求項３】
２つの情報通信機器のアプリケーション同士で実施したＡＫＥが成功した際に、各情報通信機器において、
秘匿データ操作可能レイヤは相手機器と共有する交換鍵データＫxを生成又は取得し、Ｋxを相手機器の識別情報と結び付けて登録し、
秘匿データ操作不可レイヤは、Ｋxと結び付いているＫx識別情報を秘匿データ操作可能レイヤから取得して格納する、
ことを特徴とする請求項２に記載の情報通信システム。
【請求項４】
各情報通信機器は、ＡＫＥの相手となる情報通信機器の識別情報としてＩＰアドレスを用いる、
ことを特徴とする請求項３に記載の情報通信システム。
【請求項５】
ＤＴＣＰ−ＩＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｏｉｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ  ｏｖｅｒ  ＩＰ）に準拠したＳｏｕｒｃｅ機器及びＳｉｎｋ機器として動作する情報通信機器間でＡＫＥが実施される、
ことを特徴とする請求項３に記載の情報通信システム。
【請求項６】
Ｓｉｎｋ機器側で起動するＳｉｎｋアプリケーションがＳｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対しＤＴＣＰ−ＩＰ暗号化されたコンテンツを要求し、ＳｏｕｒｃｅアプリケーションからＳｉｎｋアプリケーションへ該コンテンツが伝送された際に、
Ｓｉｎｋアプリケーションは、Ｓｏｕｒｃｅ機器の識別情報とＫxの識別情報とともに秘匿データ操作可能レイヤに渡して受信したコンテンツの処理を依頼し、
秘匿データ操作可能レイヤは、そのときのＫxを利用して該コンテンツの処理を行なう、
ことを特徴とする請求項５に記載の情報通信システム。
【請求項７】
Ｓｉｎｋ機器側で起動するＳｉｎｋアプリケーションがＳｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対してＡＫＥを実施する際に、
秘匿データ操作可能レイヤは、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションから渡されるＳｏｕｒｃｅ機器の識別情報をチェックする、
ことを特徴とする請求項５に記載の情報通信システム。
【請求項８】
秘匿データ操作可能レイヤは、Ｓｏｕｒｃｅ機器の識別情報をチェックした結果、同じＳｏｕｒｃｅ機器に対する認証セッションが継続中であることが判ったときには、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知し、
Ｓｉｎｋアプリケーションは、該通知に応答して、実施中のＡＫＥを失敗させる、
ことを特徴とする請求項７に記載の情報通信システム。
【請求項９】
秘匿データ操作可能レイヤは、Ｓｏｕｒｃｅ機器の識別情報をチェックした結果、同じＳｏｕｒｃｅ機器と共有する交換鍵データＫxを既に生成又は取得済みであることが判ったときには、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知し、
秘匿データ操作不可レイヤは、該当するＫx識別情報を秘匿データ操作可能レイヤから取得し、
Ｓｉｎｋアプリケーションは、該通知に応答して、ＡＫＥを実施しない、
ことを特徴とする請求項７に記載の情報通信システム。
【請求項１０】
ＩＰネットワーク上で他の情報通信装置と相互認証及び鍵交換（ＡＫＥ）を実施する情報通信装置であって、
秘匿性のあるデータ値に対し参照や変更といった直接的な操作を行なうことができる秘匿データ操作可能レイヤと、
ＡＫＥを実施するアプリケーション毎に１つずつ起動して、秘匿性のあるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを備え、
他の情報通信装置とＡＫＥを実施して生成又は取得した交換鍵データＫxを秘匿データ操作可能レイヤで管理するとともに、秘匿データ操作不可レイヤにはＫxと結び付いているＫx識別情報を格納し、
各アプリケーションは秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスする、
ことを特徴とする情報通信装置。
【請求項１１】
他の情報通信装置とアプリケーション同士でＡＫＥを実施する際に、
秘匿データ操作不可レイヤは、アプリケーションから取得した相手機器の識別情報を秘匿データ操作可能レイヤに渡し、
秘匿データ操作可能レイヤは、相手機器との認証を識別する機器認証セッション情報を秘匿データ操作不可レイヤに返す、
ことを特徴とする請求項１０に記載の情報通信装置。
【請求項１２】
２つの情報通信機器のアプリケーション同士で実施したＡＫＥが成功した際に、
秘匿データ操作可能レイヤは相手機器と共有する交換鍵データＫxを生成又は取得し、Ｋxを相手機器の識別情報と結び付けて登録し、
秘匿データ操作不可レイヤは、Ｋxと結び付いているＫx識別情報を秘匿データ操作可能レイヤから取得して格納する、
ことを特徴とする請求項１１に記載の情報通信装置。
【請求項１３】
ＡＫＥを実施する相手となる情報通信装置の識別情報としてＩＰアドレスを用いる、
ことを特徴とする請求項１２に記載の情報通信装置。
【請求項１４】
ＤＴＣＰ−ＩＰに準拠して、Ｓｏｕｒｃｅ機器として動作してＳｉｎｋ機器なる情報通信機器とＡＫＥを実施し、又は、Ｓｉｎｋ機器として動作してＳｏｕｒｃｅ機器なる情報通信機器とＡＫＥを実施する、
ことを特徴とする請求項１２に記載の情報通信装置。
【請求項１５】
Ｓｉｎｋアプリケーションを起動してＳｉｎｋ機器として動作して、Ｓｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対してＤＴＣＰ−ＩＰ暗号化されたコンテンツを要求し、ＳｏｕｒｃｅアプリケーションからＳｉｎｋアプリケーションへ該コンテンツが伝送された際に、
Ｓｉｎｋアプリケーションは、Ｓｏｕｒｃｅ機器の識別情報とＫxの識別情報とともに秘匿データ操作可能レイヤに渡して受信したコンテンツの処理を依頼し、
秘匿データ操作可能レイヤは、そのときのＫxを利用して該コンテンツの処理を行なう、
ことを特徴とする請求項１４に記載の情報通信装置。
【請求項１６】
Ｓｉｎｋアプリケーションを起動してＳｉｎｋ機器として動作して、Ｓｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対してＡＫＥを実施する際に、
秘匿データ操作可能レイヤは、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションから渡されるＳｏｕｒｃｅ機器の識別情報をチェックする、
ことを特徴とする請求項１４に記載の情報通信装置。
【請求項１７】
秘匿データ操作可能レイヤは、Ｓｏｕｒｃｅ機器の識別情報をチェックした結果、同じＳｏｕｒｃｅ機器に対する認証セッションが継続中であることが判ったときには、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知し、
Ｓｉｎｋアプリケーションは、該通知に応答して、実施中のＡＫＥを失敗させる、
ことを特徴とする請求項１６に記載の情報通信装置。
【請求項１８】
秘匿データ操作可能レイヤは、Ｓｏｕｒｃｅ機器の識別情報をチェックした結果、同じＳｏｕｒｃｅ機器と共有する交換鍵データＫxを既に生成又は取得済みであることが判ったときには、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知し、
秘匿データ操作不可レイヤは、該当するＫx識別情報を秘匿データ操作可能レイヤから取得し、
Ｓｉｎｋアプリケーションは、該通知に応答して、ＡＫＥを実施しない、
ことを特徴とする請求項１６に記載の情報通信装置。
【請求項１９】
秘匿性のあるデータ値に対して直接的な操作を行なうことができる秘匿データ操作可能レイヤと、ＡＫＥを実施するアプリケーション毎に１つ起動して、秘匿性のあるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設けて、ＩＰネットワーク上で他の情報通信装置と相互認証及び鍵交換（ＡＫＥ）を実施する情報通信方法であって、
他の情報通信装置とＡＫＥを実施して生成又は取得した交換鍵データＫxを秘匿データ操作可能レイヤで管理するステップと、
秘匿データ操作不可レイヤにＫxと結び付いているＫx識別情報を格納するステップと、
アプリケーションから秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスするステップと、
を具備することを特徴とする情報通信方法。
【請求項２０】
他の情報通信装置とアプリケーション同士でＡＫＥを実施する際に、
秘匿データ操作不可レイヤがアプリケーションから取得した相手機器の識別情報を秘匿データ操作可能レイヤに渡すステップと、
秘匿データ操作可能レイヤが相手機器との認証を識別する機器認証セッション情報を秘匿データ操作不可レイヤに返すステップと、
をさらに備えることを特徴とする請求項１９に記載の情報通信方法。
【請求項２１】
２つの情報通信機器のアプリケーション同士で実施したＡＫＥが成功した際に、
秘匿データ操作可能レイヤが相手機器と共有する交換鍵データＫxを生成又は取得し、Ｋxを相手機器の識別情報と結び付けて登録するステップと、
秘匿データ操作不可レイヤがＫxと結び付いているＫx識別情報を秘匿データ操作可能レイヤから取得して格納するステップと、
をさらに備えることを特徴とする請求項２０に記載の情報通信方法。
【請求項２２】
ＡＫＥを実施する相手となる情報通信装置の識別情報としてＩＰアドレスを用いる、
ことを特徴とする請求項２１に記載の情報通信方法。
【請求項２３】
ＤＴＣＰ−ＩＰに準拠して、Ｓｏｕｒｃｅ機器として動作してＳｉｎｋ機器なる情報通信機器とＡＫＥを実施し、又は、Ｓｉｎｋ機器として動作してＳｏｕｒｃｅ機器なる情報通信機器とＡＫＥを実施する、
ことを特徴とする請求項２１に記載の情報通信方法。
【請求項２４】
Ｓｉｎｋアプリケーションを起動してＳｉｎｋ機器として動作して、Ｓｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対してＤＴＣＰ−ＩＰ暗号化されたコンテンツを要求し、ＳｏｕｒｃｅアプリケーションからＳｉｎｋアプリケーションへ該コンテンツが伝送された際に、
ＳｉｎｋアプリケーションがＳｏｕｒｃｅ機器の識別情報とＫxの識別情報とともに秘匿データ操作可能レイヤに渡して受信したコンテンツの処理を依頼するステップと、
秘匿データ操作可能レイヤがそのときのＫxを利用して該コンテンツの処理を行なうステップと、
をさらに備えることを特徴とする請求項２３に記載の情報通信方法。
【請求項２５】
Ｓｉｎｋアプリケーションを起動してＳｉｎｋ機器として動作して、Ｓｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対してＡＫＥを実施する際に、
秘匿データ操作可能レイヤが秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションから渡されるＳｏｕｒｃｅ機器の識別情報をチェックする機器識別情報チェック・ステップをさらに備える、
ことを特徴とする請求項２３に記載の情報通信方法。
【請求項２６】
前記機器識別情報チェック・ステップにおいて同じＳｏｕｒｃｅ機器に対する認証セッションが継続中であることが判ったことに応答して、
秘匿データ操作可能レイヤが秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知するステップと、
Ｓｉｎｋアプリケーションが実施中のＡＫＥを失敗させるステップと、
をさらに備えることを特徴とする請求項２５に記載の情報通信方法。
【請求項２７】
前記機器識別情報チェック・ステップにおいて同じＳｏｕｒｃｅ機器と共有する交換鍵データＫxを既に生成又は取得済みであることが判ったことに応答して、
秘匿データ操作可能レイヤが秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知するステップと、
秘匿データ操作不可レイヤが該当するＫx識別情報を秘匿データ操作可能レイヤから取得するステップをさらに備え、
ＳｉｎｋアプリケーションはＡＫＥを実施しない、
ことを特徴とする請求項２５に記載の情報通信方法。
【請求項２８】
秘匿性のあるデータ値に対し直接的な操作を行なうことができる秘匿データ操作可能レイヤと、ＡＫＥを実施するアプリケーション毎に１つ起動して、秘匿性のあるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設けて、ＩＰネットワーク上で他の情報通信装置と相互認証及び鍵交換（ＡＫＥ）を実施するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
他の情報通信装置とＡＫＥを実施して生成又は取得した交換鍵データＫxを秘匿データ操作可能レイヤで管理する手順と、
秘匿データ操作不可レイヤにＫxと結び付いているＫx識別情報を格納する手順と、
アプリケーションから秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスする手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを送受信処理する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ機器間で共有される鍵を秘匿性を保ちながら管理する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、複数のＤＴＣＰ−ＩＰアプリケーションを起動するＤＴＣＰ＿Ｓｉｎｋ機器において、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ＿Ｓｏｕｒｃｅ機器と共有される鍵の秘匿性を保ちながら、同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器と認証するＤＴＣＰ−ＩＰアプリケーション間で共有鍵に関する情報を共有する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。また、デジタル・コンテンツはコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。
【０００４】
例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコル、すなわち暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうことなどを取り決めている。
【０００５】
コンテンツ提供元であるサーバ（ＤＴＣＰ  Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ  Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。
【０００６】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ＤＴＣＰ−ＩＰでは、伝送路にＩＰネットワークを使用し、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用する。また、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。
【０００７】
図１４には、ＤＴＣＰ＿ＩＰに準拠するＳｏｕｒｃｅ機器とＳｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを図解している。同図に示す例では、コンテンツ伝送にはＨＴＴＰプロトコルが利用される。
【０００８】
ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや認証鍵Ｋauthが埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している認証鍵ＫauthをＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。
【０００９】
ＡＫＥ手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、それぞれ内部で同様の処理を行なってＫauthからコンテンツ鍵の種となる鍵Ｋxを生成する。この鍵Ｋxは、コンテンツ伝送時にコンテンツ鍵Ｋcを生成するために使用される（後述）。
【００１０】
そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（Ｃｏｎｔｅｎｔｓ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。また、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。あるいは、ＲＳＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。
【００１１】
ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。
【００１２】
ここで、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。
【００１３】
具体的には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、乱数を用いてノンスＮcを生成して、ＫxとＮcを基にコンテンツ鍵Ｋcを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツとノンスＮcからなるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ  Ｃｏｎｔｅｎｔ  Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せてＤＴＣＰ＿Ｓｉｎｋ機器に送信する。そして、ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
【００１４】
ＤＴＣＰ＿Ｓｉｎｋ機器側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、ストリームからノンスＮcを取り出すと、これと認証鍵Ｋauthから求めた鍵Ｋxを用いて同様にコンテンツ鍵Ｋcを算出し、暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生若しくは記録などの処理を実施することができる。
【００１５】
そして、ＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、使用したＴＣＰコネクションを適宜切断することができる。
【００１６】
ここで、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新するよう取り決められている。バイト・ストリーム中で、同じノンスＮcから生成されたコンテンツ鍵Ｋcを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。
【００１７】
また、このようにバイト・ストリームの途中で復号鍵が動的に変更されることから、コンテンツ鍵の確認手続きが必要となる。そこで、ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器に対しコンテンツ鍵確認のための手続きを行なう。ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ鍵の確認が必要になると、適宜このＴＣＰコネクションを確立する。
【００１８】
このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴や改竄を防いで、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００１９】
【非特許文献１】ＤＴＣＰ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｖｏｌｕｍｅ  １  Ｖｅｒｓｉｏｎ  １．３  （Ｉｎｆｏｒｍａｔｉｏｎａｌ  Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ
【非特許文献２】ＤＴＣＰ  Ｖｏｌｕｍｅ  １  Ｓｕｐｐｌｅｍｅｎｔ  Ｅ  Ｍａｐｐｉｎｇ  ＤＴＣＰ  ｔｏ  ＩＰ，  Ｖｅｒｓｉｏｎ  １．０  （Ｉｎｆｏｒｍａｔｉｏｎａｌ  Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／
【発明の開示】
【発明が解決しようとする課題】
【００２０】
上述したようにＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを実施することによって、コンテンツの交換に使用される鍵Ｋxを共有することができる。そして、共有した鍵を利用してコンテンツを伝送する際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴や改竄を防いで、ＩＰネットワーク上においても安全なコンテンツ伝送を実現することができる。
【００２１】
このようなコンテンツ伝送システムでは、ＤＴＣＰ＿Ｓｉｎｋ機器側において、１以上のＤＴＣＰ＿Ｓｏｕｒｃｅ機器を通信相手にし、複数のＤＴＣＰ−ＩＰ用Ｓｉｎｋアプリケーションが同時に起動している、というユース・ケースが考えられる。ＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ手続きでＤＴＣＰ＿Ｓｉｎｋ機器と交換する鍵ＫauthはＤＴＬＡと呼ばれる認可組織により機器に内蔵されている。言い換えれば、ＤＴＣＰ＿Ｓｉｎｋ機器で起動している複数のＤＴＣＰ−ＩＰ用Ｓｉｎｋアプリケーションのうち同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器を通信相手にしているものは、同じ交換鍵Ｋxを使用することになる。
【００２２】
ここで、それぞれのアプリケーションはプロセスという単位で分かれることになるため、プロセス間通信などの特殊な仕組みを実現しない限り、お互いが保有するデータを共有することはできない。ところが、プロセス間通信などはコスト・パフォーマンスの点において有益とは言い難い。
【００２３】
このため、Ｓｉｎｋ機器内に複数のＤＴＣＰ−ＩＰアプリケーションが起動している場合に、それぞれ同じＳｏｕｒｃｅ機器に対する認証かどうかを判断できず、その帰結として、無駄な認証手続きが起動される可能性が高くなる。
【００２４】
勿論、（Ｋauthから求まる）Ｋxのような情報をユーザ・アプリケーションからアクセス可能な通信プロトコルにおいて管理すれば、ＤＴＣＰ−ＩＰアプリケーション同士でそれぞれ同じＳｏｕｒｃｅ機器に対する認証かどうかを容易に判断することができる。しかしながら、Ｋxのような情報は、ＤＴＣＰ−ＩＰにおいてコンテンツを復号するための重要情報であり、秘匿性を考慮した場合、ユーザ・アプリケーションでかかる情報を管理することは安全性の面で不十分な情報管理方法と言わざるを得ない。
【００２５】
本発明は上述したような技術的課題を勘案したものであり、その主な目的は、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２６】
本発明のさらなる目的は、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ機器間で共有される鍵を、秘匿性を保ちながら好適に管理することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２７】
本発明のさらなる目的は、ＤＴＣＰ＿Ｓｉｎｋ機器において、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ＿Ｓｏｕｒｃｅ機器と共有される鍵の秘匿性を保ちながら、同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器と認証する複数のＤＴＣＰ−ＩＰアプリケーションにおいて無駄な認証手続きの起動を回避することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２８】
本発明のさらなる目的は、ＤＴＣＰ＿Ｓｉｎｋ機器において、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ＿Ｓｏｕｒｃｅ機器と共有される鍵をアプリケーションからアクセス不可能な通信プロトコル・レイヤで管理してその秘匿性を保ちながら、同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器と認証するＤＴＣＰ−ＩＰアプリケーション間で共有鍵に関する情報を共有することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００２９】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した情報通信機器間で相互認証及び鍵交換（ＡＫＥ）を実施する情報通信システムであって、
各情報通信機器において、秘匿性のあるデータ値に対し参照や変更といった直接的な操作を行なうことができる秘匿データ操作可能レイヤと、かかるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設け、ＡＫＥを実施して生成又は取得した交換鍵データＫxを秘匿データ操作可能レイヤで管理するとともに、秘匿データ操作不可レイヤにはＫxと結び付いているＫx識別情報を格納し、
情報通信機器上で起動するアプリケーション毎に１つの秘匿データ操作不可レイヤが起動し、各アプリケーションは秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスする、
ことを特徴とする情報通信システムである。
【００３０】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない（以下、同様）。
【００３１】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵Ｋxを用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。ＤＴＣＰ−ＩＰによれば、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴や改竄を防ぎ、ＩＰネットワーク上においても安全なコンテンツ伝送を実現することができる。
【００３２】
ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、複数のＤＴＣＰ＿Ｓｉｎｋ機器を通信相手にして複数のＳｏｕｒｃｅアプリケーションを同時に起動させることができる。また、ＤＴＣＰ＿Ｓｉｎｋ機器側では、１以上のＤＴＣＰ＿Ｓｏｕｒｃｅ機器を通信相手にした複数のＳｉｎｋアプリケーションを同時に起動させることができる。ここで、ＤＴＣＰ−ＩＰ  ＡＫＥ手続きで交換する鍵Ｋauthは各ＤＴＣＰ＿Ｓｏｕｒｃｅ機器においてユニークであるから、ＤＴＣＰ＿Ｓｉｎｋ機器で起動している複数のＳｉｎｋアプリケーションのうち同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器を通信相手にしているものは、同じ交換鍵Ｋxを使用することになる。
【００３３】
本発明者らは、（Ｋauthから求まる）Ｋxのような情報は、ユーザ・アプリケーションからアクセス可能な通信プロトコル・レイヤにおいて管理するのではなく、通常はユーザ・アプリケーションからアクセス不可能な通信プロトコル・レイヤで管理することが妥当であると思料する。このような情報管理手法を採用する場合には、Ｋxへのアクセス方法を考え出さねばならない。
【００３４】
アプリケーションはプロセスという単位で分かれるので、同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器とコンテンツ伝送を行なう各ＤＴＣＰ−ＩＰアプリケーションは例えばプロセス間通信によって互いにＫxを共有することが考えられる。しかしながら、プロセス間通信などは、コスト・パフォーマンスの点において有効でない。
【００３５】
このため、Ｓｉｎｋ機器内に複数のＤＴＣＰ−ＩＰアプリケーションが起動している場合に、それぞれ同じＳｏｕｒｃｅ機器に対する認証かどうかを判断できず、その帰結として、無駄な認証手続きが起動される可能性が高くなる。
【００３６】
そこで、本発明では、認証サーバとなるＳｏｕｒｃｅ機器と認証クライアントとなるＳｉｎｋ機器の間でＡＫＥ認証手続きを実行する際に、秘匿性のあるデータ値に対し参照や変更といった直接的な操作を行なうことができる秘匿データ操作可能レイヤと、かかるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設け、ＡＫＥ認証を経て機器同士で交換した鍵Ｋxを秘匿データ操作可能レイヤで管理するとともに、秘匿データ操作不可レイヤにはＫxと結び付いているＫx識別情報を格納するようにした。そして、ＤＴＣＰ−ＩＰアプリケーションからは、秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスできるようにした。
【００３７】
具体的には、２つの情報通信機器のアプリケーション同士でＡＫＥを実施する際に、秘匿データ操作不可レイヤは、アプリケーションから取得した相手機器の識別情報を秘匿データ操作可能レイヤに渡し、秘匿データ操作可能レイヤは、相手機器との認証を識別する機器認証セッション情報を秘匿データ操作不可レイヤに返すようにする。そして、２つの情報通信機器のアプリケーション同士で実施したＡＫＥが成功した際には、秘匿データ操作可能レイヤは相手機器と共有する交換鍵データＫxを生成又は取得し、Ｋxを相手機器の識別情報と結び付けて登録し、秘匿データ操作不可レイヤは、Ｋxと結び付いているＫx識別情報を秘匿データ操作可能レイヤから取得して格納する。ここで、相手機器の識別情報としてＩＰアドレスを用いることができる。
【００３８】
本発明をＤＴＣＰ−ＩＰに準拠したＳｏｕｒｃｅ機器及びＳｉｎｋ機器として動作する情報通信機器間で実施するＡＫＥに適用した場合、Ｓｉｎｋ機器側で起動するＳｉｎｋアプリケーションがＳｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対しＤＴＣＰ−ＩＰ暗号化されたコンテンツを要求し、ＳｏｕｒｃｅアプリケーションからＳｉｎｋアプリケーションへ該コンテンツが伝送された際に、Ｓｉｎｋアプリケーションは、Ｓｏｕｒｃｅ機器の識別情報とＫx識別情報とともに秘匿データ操作可能レイヤに渡して受信したコンテンツの処理を依頼し、秘匿データ操作可能レイヤは、そのときのＫxを利用して該コンテンツの処理を行なうことになる。
【００３９】
また、Ｓｉｎｋ機器側で起動するＳｉｎｋアプリケーションがＳｏｕｒｃｅ機器側で起動するＳｏｕｒｃｅアプリケーションに対してＡＫＥを実施する際に、秘匿データ操作可能レイヤは、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションから渡されるＳｏｕｒｃｅ機器の識別情報をチェックするようにする。Ｓｉｎｋ機器は、秘匿データ操作可能レイヤにおいて、Ｓｏｕｒｃｅ機器の識別情報と結び付けてＫx識別情報を登録することにより、Ｓｏｕｒｃｅ機器固有のＫx識別情報を取得する際、当該Ｓｏｕｒｃｅ機器を識別する情報に対する認証が既に終了しているかどうかを判断することができる。
【００４０】
ここで、秘匿データ操作可能レイヤは、Ｓｏｕｒｃｅ機器の識別情報をチェックした結果、同じＳｏｕｒｃｅ機器に対する認証セッションが継続中であることが判ったときには、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知し、Ｓｉｎｋアプリケーションは、該通知に応答して、実施中のＡＫＥを失敗させる。すなわち、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器とＡＫＥ認証手続きを実行する際に、１つ目の認証が終了する前に、２つ目以降の認証が実行された場合には、２つ目以降の認証を失敗させることにより、無駄な認証トラフィックを避けることができる。
【００４１】
また、秘匿データ操作可能レイヤは、Ｓｏｕｒｃｅ機器の識別情報をチェックした結果、同じＳｏｕｒｃｅ機器と共有する交換鍵データＫxを既に生成又は取得済みであることが判ったときには、秘匿データ操作不可レイヤを通じてＳｉｎｋアプリケーションに通知し、Ｓｉｎｋアプリケーションは、該通知に応答して、ＡＫＥを実施しない。そして、秘匿データ操作不可レイヤは、該当するＫx識別情報を秘匿データ操作可能レイヤから取得する。すなわち、当該Ｓｏｕｒｃｅ機器とは認証終了済みであれば、Ｓｉｎｋ機器は認証手続きを実際に行なわなくても、その時点でＳｏｕｒｃｅ機器と結び付いているＫx識別情報を得ることかできる。
【００４２】
このように、本発明によれば、ＤＴＣＰ機器上で動作するＤＴＣＰ−ＩＰアプリケーションはＫxのような秘匿性が求められている重要な情報に対し、かかる情報を直接操作できない秘匿データ操作不可レイヤを通じてのみ操作するので、交換鍵に対する十分な秘匿性が確保されることになる。また、ＤＴＣＰ−ＩＰアプリケーションには、操作不可レイヤに格納されているＫx識別情報を通じてＫxを操作するというアクセス方法が与えられているので、各ＤＴＣＰ−ＩＰアプリケーションは、それぞれ同じＳｏｕｒｃｅ機器に対する認証かどうかを判断して、無駄な認証手続きを起動しなくて済む。
【００４３】
Ｓｉｎｋ機器は、同じＳｏｕｒｃｅ機器を通信相手にして複数のＳｉｎｋアプリケーションを同時に起動することがある。このような場合、Ｓｉｎｋ機器は、Ｓｏｕｒｃｅ機器に結び付けられたＫx識別情報を利用することによって、Ｓｏｕｒｃｅ機器から取得した暗号化コンテンツを復号することができる。
【００４４】
また、本発明に係る情報通信装置は、Ｓｏｕｒｃｅ機器及びＳｉｎｋ機器双方の機能をともに備えることができる。
【００４５】
また、本発明の第２の側面は、秘匿性のあるデータ値に対し参照や変更といった直接的な操作を行なうことができる秘匿データ操作可能レイヤと、ＡＫＥを実施するアプリケーション毎に１つずつ起動して、秘匿性のあるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設けて、ＩＰネットワーク上で他の情報通信装置と相互認証及び鍵交換（ＡＫＥ）を実施するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
他の情報通信装置とＡＫＥを実施して生成又は取得した交換鍵データＫxを秘匿データ操作可能レイヤで管理する手順と、
秘匿データ操作不可レイヤにＫxと結び付いているＫx識別情報を格納する手順と、
アプリケーションから秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスする手順と、
を実行させることを特徴とするコンピュータ・プログラムである。
【００４６】
本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによってコンピュータ・システム上では協働的作用が発揮され、情報通信装置として動作する。このような情報通信装置をＳｏｕｒｃｅ機器並びにＳｉｎｋ機器として起動してＤＴＣＰ−ＩＰ  ＡＫＥを実施することによって、本発明の第１の側面に係る情報通信システムと同様の作用効果を得ることができる。
【発明の効果】
【００４７】
本発明によれば、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ機器間で共有される鍵を、秘匿性を保ちながら好適に管理することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４８】
また、本発明によれば、ＤＴＣＰ＿Ｓｉｎｋ機器において、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ＿Ｓｏｕｒｃｅ機器と共有される鍵Ｋxの秘匿性を保ちながら、同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器と認証する複数のＤＴＣＰ−ＩＰアプリケーションにおいて無駄な認証手続きの起動を回避することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４９】
また、本発明によれば、ＤＴＣＰ＿Ｓｉｎｋ機器において、相互認証及び鍵交換（ＡＫＥ）の手続きを経てＤＴＣＰ＿Ｓｏｕｒｃｅ機器と共有される鍵Ｋxをアプリケーションからアクセス不可能な通信プロトコル・レイヤで管理してその秘匿性を保ちながら、同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器と認証するＤＴＣＰ−ＩＰアプリケーション間で共有する鍵Ｋxに関する情報を共有することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００５０】
本発明によれば、ＤＴＣＰ−ＩＰ のようなセキュリティ（耐タンパ性やロバストネス性など）を高く保たねばならないようなシステムにおいて、通常では操作・参照することができないようなエリアに所属する情報を操作するための方法を実現することができる。
【００５１】
また、本発明によれば、通常では操作や参照することができないようなエリアに所属させる情報やそれに付随する情報を好適に使用することで、（情報交換が互いに難しいような）複数のプロセスが起動している場合であっても、いずれか１つのプロセスが既に認証を完了しているときには、その他のプロセスが同じターゲットと認証するときには、無駄な認証を省いて（すなわち、以降は認証せずに）認証を実施したものと同等の状態となることができる。
【００５２】
また、本発明によれば、通常では操作や参照することができないようなエリアに所属させる情報やそれに付随する情報を好適に使用することで、（情報交換が互いに難しい）複数のプロセスが起動している場合であっても、いずれかのプロセスが認証中に、その他のプロセスが同じターゲットと認証するときは、（無駄な認証を省いて）後者の認証を中止させることができる。
【００５３】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【００５４】
以下、図面を参照しながら本発明の実施形態について詳解する。
【００５５】
本発明は、ＴＣＰ／ＩＰなどのネットワーク上やファイル・システムからバイト・ストリームとして暗号データを受理して復号する情報通信システムに関するものであり、具体的には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間で行なわれるＨＴＴＰプロトコルを利用したコンテンツ伝送を行なうシステムであり、コンテンツ伝送する途中でコンテンツ鍵を動的に変更し、且つ、Ｓｉｎｋ機器はＳｏｕｒｃｅ機器に対してコンテンツ鍵の確認手続きを適宜行なう。
【００５６】
Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅ機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋ機器で構成される。図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。
【００５７】
図示の例では、Ｓｏｕｒｃｅ機器Ａ〜Ｂ、Ｓｉｎｋ機器Ａ〜Ｂ及び中継機器Ａ〜Ｃの各エンティティにより、ＤＴＣＰ−ＩＰ  ＡＫＥシステムが構築されている。
【００５８】
ＤＴＣＰ−ＩＰ に準拠した認証サーバであるＳｏｕｒｃｅ機器ＡとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器Ａが中継機器Ａと中継機器Ｂを経由してネットワークで接続されている。
【００５９】
また、中継機器Ａ、中継機器Ｂ、中継機器Ｃ を経由して、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＢやＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器ＢがＩＰネットワークで接続されている。
【００６０】
但し、本発明の要旨は図示のネットワーク・トポロジに限定されるものではない。ここでは、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器側では、複数のＤＴＣＰ＿Ｓｉｎｋ機器を通信相手にした複数のＤＴＣＰ−ＩＰアプリケーションを同時に起動させることができ、また、ＤＴＣＰ＿Ｓｉｎｋ機器側では、１以上のＤＴＣＰ＿Ｓｏｕｒｃｅ機器を通信相手にした複数のＤＴＣＰ−ＩＰアプリケーションを同時に起動させることができる、という点を理解されたい。
【００６１】
認証クライアントとしてのＳｉｎｋ機器と認証サーバとしてのＳｏｕｒｃｅ機器は、ＴＣＰ／ＩＰネットワーク上で確立したコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【００６２】
ＤＴＣＰ−ＩＰ規格に準拠してＤＴＣＰ＿Ｓｉｎｋとして動作するＳｉｎｋ機器は、ＤＴＣＰ−ＩＰ認証機能と、ＤＴＣＰ−ＩＰコンテンツ受信機能と、コンテンツ再生／記録機能を備えている。
【００６３】
ＤＴＣＰ−ＩＰ認証機能は、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するＡＫＥ機能と、コンテンツ復号機能からなる。
【００６４】
コンテンツ復号機能により、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵Ｋxを用いてコンテンツの復号鍵を算出し、暗号コンテンツを復号することができる。そして、コンテンツ再生／記録機能により、再生モードの場合はコンテンツ再生を行ない、記録モードの場合は復号したコンテンツを保存する。
【００６５】
ＤＴＣＰ−ＩＰコンテンツ受信機能は、ＡＫＥを実施した後にコンテンツ伝送手続きを実行することができる。例えば、ＨＴＴＰクライアントとして構成され、ＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。
【００６６】
ＨＴＴＰクライアントは、ＨＴＴＰリクエスト管理とＨＴＴＰレスポンス管理を行なう。さらに、ＨＴＴＰリクエスト管理は、ＨＴＴＰリクエスト送信とＨＴＴＰリクエスト生成へ分かれる。すなわち、コンテンツ伝送要求としてのＨＴＴＰリクエストを生成して、ＨＴＴＰサーバへ送信する。そして、ＨＴＴＰサーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツを受信すると、そのＨＴＴＰレスポンス解釈によりチェックする。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＡＫＥで交換した鍵Ｋxから算出される復号鍵を用いて復号するが、このチェックがＮＧの場合はエラー・レスポンスとしての処理を行なう。
【００６７】
Ｓｉｎｋ機器は、ＤＴＣＰ−ＩＰ認証とＤＴＣＰ−ＩＰコンテンツ受信において、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００６８】
また、ＤＴＣＰ−ＩＰ規格に準拠してＤＴＣＰ＿Ｓｏｕｒｃｅとして動作するＳｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ認証機能と、ＤＴＣＰ−ＩＰコンテンツ送信機能と、コンテンツ管理機能を備えている。
【００６９】
ＤＴＣＰ−ＩＰ認証機能は、ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するＡＫＥ機能と、コンテンツ暗号化機能からなる。
【００７０】
コンテンツ管理機能により、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツが管理されており、ＤＴＣＰ−ＩＰコンテンツ送信要求に応じてコンテンツのデータが読み出される。
【００７１】
そして、コンテンツ暗号化機能により、ＤＴＣＰ−ＩＰコンテンツ送信要求に応じて読み出されたコンテンツ・データをＡＫＥで交換した鍵Ｋxから生成したコンテンツ鍵を用いて暗号化する。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。
【００７２】
ＤＴＣＰ−ＩＰコンテンツ送信機能は、ＨＴＴＰサーバに相当し、ＨＴＴＰリクエスト管理とＨＴＴＰレスポンス管理を行ない、ＨＴＴＰクライアントからのリクエストを受理し要求に応じた処理を実行する。
【００７３】
ＨＴＴＰサーバは、クライアントから受信したＨＴＴＰリクエストを解釈してチェックする。ここでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成し、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。
【００７４】
Ｓｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ認証とＤＴＣＰ−ＩＰコンテンツ送信において、Ｓｉｎｋ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００７５】
Ｂ．秘匿データの情報管理手法
既に述べたように、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器側では、複数のＤＴＣＰ＿Ｓｉｎｋ機器を通信相手にした複数のＤＴＣＰ−ＩＰアプリケーションを同時に起動させることができる。また、ＤＴＣＰ＿Ｓｉｎｋ機器側では、複数のＤＴＣＰ−ＩＰアプリケーションを同時に起動させることができ、１つのＤＴＣＰ＿Ｓｏｕｒｃｅ機器に対して複数のＤＴＣＰ−ＩＰアプリケーションを同時に起動することもある。
【００７６】
ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、ＤＴＣＰ−ＩＰに準拠したＡＫＥ手続きを実施することによって、コンテンツの交換に使用される鍵Ｋxを共有する。ＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ手続きでＤＴＣＰ＿Ｓｉｎｋ機器と交換する鍵ＫauthはＤＴＬＡと呼ばれる認可組織により機器に内蔵されたユニークなものであるから、ＤＴＣＰ＿Ｓｉｎｋ機器で起動している複数のＤＴＣＰ−ＩＰアプリケーションのうち同じＤＴＣＰ＿Ｓｏｕｒｃｅ機器を通信相手にしているものは、同じ交換鍵Ｋxを使用することになる。
【００７７】
Ｋxのような情報は、ユーザ・アプリケーションからアクセス可能な通信プロトコル・レイヤにおいて管理するのではなく、通常はユーザ・アプリケーションからアクセス不可能な通信プロトコル・レイヤで管理することが妥当である、と本発明者らは思料する。このような情報管理手法を採用する場合には、Ｋxへのアクセス方法を考え出さねばならない。
【００７８】
そこで、本実施形態では、認証サーバとなるＳｏｕｒｃｅ機器と認証クライアントとなるＳｉｎｋ機器の間でＡＫＥ認証手続きを実行する際に、秘匿性のあるデータ値に対し参照や変更といった直接的な操作を行なうことができる秘匿データ操作可能レイヤと、かかるデータ値に対する直接的な操作を行なうことができない秘匿データ操作不可レイヤを設け、ＡＫＥ認証を経て機器同士で交換した鍵Ｋxを秘匿データ操作可能レイヤで管理するとともに、秘匿データ操作不可レイヤにはＫxと結び付いているＫx識別情報を格納するようにした。そして、ＤＴＣＰ−ＩＰアプリケーションからは、秘匿データ操作不可レイヤ内のＫx識別情報を通じて秘匿データ操作可能レイヤ内のＫxにアクセスできるようにした。
【００７９】
このような場合、ＤＴＣＰ機器上で動作するＤＴＣＰ−ＩＰアプリケーションはＫxのような秘匿性が求められている重要な情報に対し、かかる情報を直接操作できない秘匿データ操作不可レイヤを通じてのみ操作するので、交換鍵に対する十分な秘匿性が確保されることになる。また、ＤＴＣＰ−ＩＰアプリケーションには、操作不可レイヤに格納されているＫx識別情報を通じてＫxを操作するというアクセス方法が与えられているので、各ＤＴＣＰ−ＩＰアプリケーションは、それぞれ同じＳｏｕｒｃｅ機器に対する認証かどうかを判断して、無駄な認証手続きを起動しなくて済む。
【００８０】
図２には、Ｓｏｕｒｃｅ機器における通信ソフトウェアのスタック構造を模式的に示している。同図に示すように、Ｓｏｕｒｃｅ機器では、ＤＴＣＰ−ＩＰを Ｓｏｕｒｃｅとして実現するためのアプリケーション（以下、「ＤＴＣＰ−ＩＰ用Ｓｏｕｒｃｅアプリケーション」とも呼ぶ）を複数起動させることが可能であり、それぞれのＳｏｕｒｃｅアプリケーションに対応して秘匿データ操作不可レイヤが起動される。
【００８１】
秘匿データ操作可能レイヤは、複数のＳｏｕｒｃｅアプリケーションに対して１つだけ起動され、Ｓｏｕｒｃｅアプリケーション毎に起動した各秘匿データ操作不可レイヤとそれぞれ交信することができる。
【００８２】
Ｓｏｕｒｃｅアプリケーションは、Ｓｉｎｋ機器と共有するための交換鍵Ｋxを複数個生成することもできるが、以下の説明では１つだけ生成するものとする。秘匿データ操作可能レイヤでＫxを生成した際、それに対応するＫx識別情報が秘匿データ操作不可レイヤで保持され、秘匿データ操作不可レイヤ側ではこのＫx識別情報を利用することでＫxに対する操作を実現することができる。ここでは、複数の秘匿データ操作不可レイヤが単一のＫxに対するＫx識別情報を取得できるものとする。図２に示した例では、秘匿データ操作可能レイヤにおいてＫx _1を生成し、それに対応するＫx識別情報_1が各ＳｏｕｒｃｅアプリケーションＡ〜Ｂに対応する秘匿データ操作不可レイヤにおいて保持され、Ｋx識別情報_1を利用することでＫx _1に対する操作が行なわれる。
【００８３】
また、図３には、Ｓｉｎｋ機器における通信ソフトウェアのスタック構造を模式的に示している。同図に示すように、Ｓｉｎｋ機器では、ＤＴＣＰ−ＩＰをＳｉｎｋとして実現するためのアプリケーション（以下、「ＤＴＣＰ−ＩＰ用Ｓｉｎｋアプリケーション」とも呼ぶ）を複数起動させることが可能であり、それぞれのＳｉｎｋアプリケーションに対応して秘匿データ操作不可レイヤが起動される。
【００８４】
秘匿データ操作可能レイヤは、複数のＳｉｎｋアプリケーションに対して１つだけ起動され、Ｓｉｎｋアプリケーション毎に起動した各秘匿データ操作不可レイヤとそれぞれ交信することができる。
【００８５】
Ｓｉｎｋ機器は複数のＳｉｎｋアプリケーションを同時に起動することができ、また、１つのＳｏｕｒｃｅ機器を相手に複数のＳｉｎｋアプリケーションを同時に起動することができる。各Ｓｉｎｋアプリケーションは、Ｓｏｕｒｃｅ機器と共有するＫxを確保することができる。但し、同じＳｏｕｒｃｅ機器を相手とするＳｉｎｋアプリケーションにおいてＫxを１つだけ確保して共有することができる。
【００８６】
秘匿データ操作可能レイヤでＫxを保持した際、それに対応するＫx識別情報が秘匿データ操作不可レイヤで保持され、秘匿データ操作不可レイヤ側ではこのＫx識別情報を利用することでＫxに対する操作を実現することができる。このとき、どのＳｏｕｒｃｅ機器と共有したＫxであるかを判断するために、秘匿データ操作可能レイヤでは、ＫxとともにＳｏｕｒｃｅ機器識別情報を保持する。
【００８７】
また、異なるＳｉｎｋアプリケーションにもかかわらず、認証で共有したいＫxを保有するＳｏｕｒｃｅ機器が同じである場合、各Ｓｉｎｋアプリケーションに対応して起動した複数の秘匿データ操作不可レイヤが単一のＫxに対するＫx識別情報を取得できるものとする。
【００８８】
図３に示した例では、秘匿データ操作可能レイヤでは、Ｓｏｕｒｃｅ機器２〜４のそれぞれと共有するＫx _2、Ｋx _3、Ｋx _4を保持した際、これらとともに各Ｓｏｕｒｃｅ機器識別情報を保持している。そして、Ｓｏｕｒｃｅ機器２並びに３をそれぞれ通信相手とするＳｉｎｋアプリケーションＤ並びにＥに対応して起動した各秘匿データ操作不可レイヤは、秘匿データ操作可能レイヤでＫx _2、Ｋx _3を保持した際に、それぞれ対応するＫx識別情報２並びに３を保持する。
【００８９】
また、ＳｉｎｋアプリケーションＦ及びＧはともにＳｏｕｒｃｅ機器４と認証によりＫxを共有したいので、それぞれに対応する秘匿データ操作不可レイヤＦ及びＧは、ともに秘匿データ操作可能レイヤでただ１つ保持されるＫx_4に対するＫx識別情報_4を取得し、いずれもこのＫx識別情報_4を利用することでＫx_4に対する操作を実現することができる。
【００９０】
Ｃ．Ｓｏｕｒｃｅ機器とＳｉｎｋ機器間でのＤＴＣＰ−ＩＰ  ＡＫＥの実施
この項では、Ｓｏｕｒｃｅ機器とＳｉｎｋ機器でＤＴＣＰ−ＩＰ ＡＫＥを実施する手順について考察する。
【００９１】
なお、ＤＴＣＰ−ＩＰでは、ＴＣＰ／ＩＰスタックを利用したネットワーク伝送により相互認証及び鍵交換（ＡＫＥ）並びにコンテンツ伝送を行なうが、以下では、説明の便宜上、ＤＴＣＰ−ＩＰ用のＳｏｕｒｃｅアプリケーション及びＳｉｎｋアプリケーションによりこれらのネットワーク処理を実現するものとして扱う。
【００９２】
また、ＤＴＣＰ−ＩＰでは、ＡＫＥのトリガ方法そのものについては定義していないが、ＡＫＥをトリガするための情報（以下では、「ＡＫＥトリガ情報」とも呼ぶ）については規定している。ＡＫＥトリガ情報は、Ｓｏｕｒｃｅ機器においてＡＫＥを受け付けるためのＩＰアドレスとポート番号の組み合わせを含んだ形で定義されている。したがって、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へＡＫＥトリガ情報が渡された後、その情報を基にＳｉｎｋ機器からＳｏｕｒｃｅ機器に対してＴＣＰコネクションを確立することで、ＡＫＥはトリガされる。ＡＫＥトリガ情報の性質から自明であるが、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器に対しＴＣＰ コネクションを確立しにいくということは考える必要がない。以下の説明では、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へネットワーク経由でＡＫＥトリガ情報が渡され（実際にはＵＰｎＰのＣＤＳを利用して渡される）、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へＡＫＥトリガ情報が渡されるより前に、Ｓｏｕｒｃｅ機器はＳｉｎｋ機器からのＡＫＥを受け付けられる状態になっているものとする。
【００９３】
以下、Ｓｏｕｒｃｅ 機器ＡとＳｉｎｋ機器、並びにＳｏｕｒｃｅ機器ＢとＳｉｎｋ機器でＤＴＣＰ−ＩＰ ＡＫＥを実施するという具体例に則って、Ｓｉｎｋ機器が複数のＳｏｕｒｃｅ機器とＤＴＣＰ−ＩＰ  ＡＫＥを実施する仕組みについて説明する。
【００９４】
ここで、Ｓｏｕｒｃｅ 機器Ａ並びにＳｏｕｒｃｅ機器ＢにおいてそれぞれＳｏｕｒｃｅアプリケーションＡ並びにＳｏｕｒｃｅアプリケーションＢが起動され、また、Ｓｉｎｋ機器ではＳｉｎｋアプリケーションＣ〜Ｅが起動されている状況を設定する。
【００９５】
Ｓｏｕｒｃｅ機器Ａでは、ＳｏｕｒｃｅアプリケーションＡが起動しており、秘匿データ操作可能レイヤ１でＫx_1が生成され、秘匿データ操作不可レイヤＡ ではそれに対応したＫx識別情報_1が取得される。
【００９６】
また、Ｓｏｕｒｃｅ機器Ｂでは、ＳｏｕｒｃｅアプリケーションＢが起動しており、秘匿データ操作可能レイヤ２でＫx_2が生成され、秘匿データ操作不可レイヤＢではそれに対応したＫx識別情報_2が取得される。
【００９７】
一方、Ｓｉｎｋ機器では、ＳｉｎｋアプリケーションＣ、ＳｉｎｋアプリケーションＤ、並びにＳｉｎｋアプリケーションＥが起動しており、それぞれに対応した秘匿データ操作不可レイヤＣ、秘匿データ操作不可レイヤＤ、並びに秘匿データ操作不可レイヤＥも起動している。また、各Ｓｉｎｋアプリケーションに共通となる秘匿データ操作可能レイヤが存在する。
【００９８】
Ｃ−１．通常の認証処理の流れ
Ｓｏｕｒｃｅ機器Ａ中のＳｏｕｒｃｅアプリケーションＡとＳｉｎｋ機器中のＳｉｎｋアプリケーションＣによりＤＴＣＰ−ＩＰ ＡＫＥを実施するための処理手順について説明する。
【００９９】
まず、ＳｏｕｒｃｅアプリケーションＡは、ＡＫＥトリガ情報でＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。
【０１００】
続いて、ＳｏｕｒｃｅアプリケーションＡは、ＡＫＥトリガ情報をＳｉｎｋアプリケーションＣへ、ネットワーク経由で渡す。ＡＫＥトリガ情報は、例えば、Ｓｏｕｒｃｅ機器においてＡＫＥを受け付けるためのＩＰアドレスとポート番号の組み合わせであり（前述）、図６に示すような構成となる。
【０１０１】
続いて、ＳｉｎｋアプリケーションＣは、ＡＫＥトリガ情報を基に、ＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。
【０１０２】
そして、ＳｏｕｒｃｅアプリケーションＡとＳｉｎｋアプリケーションＣで ＤＴＣＰ−ＩＰ ＡＫＥを開始する。図４には、Ｓｏｕｒｃｅ 機器ＡとＳｉｎｋ機器、並びにＳｏｕｒｃｅ機器ＢとＳｉｎｋ機器でＤＴＣＰ−ＩＰ ＡＫＥを実施する前の様子を模式的に示している。
【０１０３】
ＳｏｕｒｃｅアプリケーションＡにおいては、Ｋx識別情報_1を通じて、ＤＴＣＰ−ＩＰ ＡＫＥに必要なＫxに関連する情報を取得して認証を実施する。この認証中に、秘匿データ操作可能レイヤ１へそのＳｉｎｋ機器の情報を渡すことで、そのＳｉｎｋ機器との認証を識別できるＳｏｕｒｃｅ認証セッション情報を、秘匿データ操作不可レイヤＡにて取得することができる。
【０１０４】
ＳｉｎｋアプリケーションＣでは、認証中において、秘匿データ操作可能レイヤへそのＳｏｕｒｃｅ機器の情報を渡すことで、そのＳｏｕｒｃｅ機器との認証を識別できるＳｉｎｋ認証セッション情報を、秘匿データ操作不可レイヤＣにて取得することができる。
【０１０５】
また、ＳｉｎｋアプリケーションＣにおいては、認証が成功するとともにＫxを生成し、秘匿データ操作不可レイヤＣにて先のＫxに対応したＫx識別情報_3を取得する。そのとき、ＡＫＥトリガ情報より、Ｋxを共有したＳｏｕｒｃｅ機器Ａの情報を取得して、（Ｋx識別情報_3を通じて）秘匿データ操作可能レイヤ_3_4へＳｏｕｒｃｅ機器識別情報_3として登録させる。図５には、ＤＴＣＰ−ＩＰ ＡＫＥが終了して、Ｓｏｕｒｃｅ機器識別情報_3の登録が済んだときの状態を示している。このとき、Ｓｏｕｒｃｅ機器識別情報とＫxとを結び付けて登録させる。また、図７には、Ｓｏｕｒｃｅ機器識別情報としてのＩＰアドレスと認証により共有するＫxの組み合わせを例示している。
【０１０６】
上述したＤＴＣＰ−ＩＰ  ＡＫＥを実施して成功した後は、ＳｉｎｋアプリケーションＣは、ＳｏｕｒｃｅアプリケーションＡに対してＤＴＣＰ−ＩＰ暗号化されたコンテンツを要求することができる。そして、ＳｏｕｒｃｅアプリケーションＡは、この要求に応答して、ＳｉｎｋアプリケーションＣへコンテンツを伝送する。この場合、ＳｉｎｋアプリケーションＣは、Ｓｏｕｒｃｅ機器Ａの情報をＫx識別情報_3とともに秘匿データ操作可能レイヤ_3_4へ渡すのと同時に、そのコンテンツ・データ処理を依頼すると、秘匿データ操作可能レイヤ_3_4ではそのときのＫxを利用してコンテンツ・データ処理が行なわれる。
【０１０７】
続いて、Ｓｏｕｒｃｅ機器Ｂ上で起動しているＳｏｕｒｃｅアプリケーションＢとＳｉｎｋ機器上で起動しているＳｉｎｋアプリケーションＤによるＤＴＣＰ−ＩＰ ＡＫＥを実施するための処理手順について説明する。
【０１０８】
まず、ＳｏｕｒｃｅアプリケーションＢは、ＡＫＥトリガ情報でＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。そして、ＳｏｕｒｃｅアプリケーションＢは、ＡＫＥトリガ情報をＳｉｎｋアプリケーションＤへ、ネットワーク経由で渡す。
【０１０９】
これに対し、ＳｉｎｋアプリケーションＤは、ＡＫＥトリガ情報を基に、ＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。そして、ＳｉｎｋアプリケーションＤは、秘匿データ操作不可レイヤＤを通じて秘匿データ操作可能レイヤ_3_4にＳｏｕｒｃｅ機器の情報を渡し、有効なＫxをまだ共有していないＳｏｕｒｃｅ機器であることを確認して、ＳｏｕｒｃｅアプリケーションＢとＳｉｎｋアプリケーションＤで ＤＴＣＰ−ＩＰ ＡＫＥを開始する。また、秘匿データ操作不可レイヤＤは秘匿データ操作可能レイヤ_3_4にＳｏｕｒｃｅ機器の情報を渡して、Ｓｉｎｋ認証セッション情報を取得する。
【０１１０】
ＳｏｕｒｃｅアプリケーションＢにおいては、Ｋx識別情報_2を通じて、ＤＴＣＰ−ＩＰ ＡＫＥに必要なＫxに関連する情報を取得して認証を実施する。この認証中に、ＳｏｕｒｃｅアプリケーションＢが秘匿データ操作不可レイヤＢにＳｉｎｋ機器の情報を渡し、さらに秘匿データ操作不可レイヤＢは秘匿データ操作可能レイヤ２にＳｉｎｋ機器の情報を渡して、秘匿データ操作不可レイヤＢにてＳｏｕｒｃｅ認証セッション情報を取得する。また、ＳｏｕｒｃｅアプリケーションＢは、状況に応じて、秘匿データ操作不可レイヤＢを通じて、秘匿データ操作可能レイヤ２から、Ｋxに関連する情報を取得する。
【０１１１】
ＳｉｎｋアプリケーションＤでは、認証中において、秘匿データ操作不可レイヤＤを通じて秘匿データ操作可能レイヤ_3_4へそのＳｏｕｒｃｅ機器の情報を渡すことで、そのＳｏｕｒｃｅ機器との認証を識別できるＳｉｎｋ認証セッション情報を、秘匿データ操作不可レイヤＤにて取得することができる。
【０１１２】
また、ＳｉｎｋアプリケーションＤにおいては、認証が成功するとともにＫxを生成し、秘匿データ操作不可レイヤＤにて先のＫxに対応したＫx識別情報_4を取得する。そのとき、ＡＫＥトリガ情報より、Ｋxを共有したＳｏｕｒｃｅ機器Ｂの情報を取得して、（Ｋx識別情報_4を通じて）秘匿データ操作可能レイヤ_3_4へＳｏｕｒｃｅ機器識別情報_4として登録させる。図８には、ＤＴＣＰ−ＩＰ ＡＫＥが終了して、Ｓｏｕｒｃｅ機器識別情報_4の登録が済んだときの状態を示している。このとき、Ｓｏｕｒｃｅ機器識別情報とＫxとを結び付けて登録させる。
【０１１３】
その後、ＳｉｎｋアプリケーションＤがＳｏｕｒｃｅアプリケーションＢに対してＤＴＣＰ−ＩＰ暗号化されたコンテンツを要求し、これにＳｏｕｒｃｅアプリケーションＢからＳｉｎｋアプリケーションＤへコンテンツが伝送される。この場合、ＳｉｎｋアプリケーションＤは、Ｓｏｕｒｃｅ機器Ｂの情報をＫx識別情報_4とともに秘匿データ操作可能レイヤ_3_4へ渡すのと同時に、そのコンテンツ・データ処理を依頼すると、秘匿データ操作可能レイヤ_3_4ではそのときのＫxを利用してコンテンツ・データ処理が行なわれる。
【０１１４】
Ｃ−２．同じＳｏｕｒｃｅ機器に対する認証処理の流れ
Ｓｏｕｒｃｅ機器Ｂ上で起動しているＳｏｕｒｃｅアプリケーションＢとＳｉｎｋ機器上で起動しているＳｉｎｋアプリケーションＤによるＤＴＣＰ−ＩＰ ＡＫＥを開始した時点で、さらにＳｏｕｒｃｅ機器Ｂ上で起動しているＳｏｕｒｃｅアプリケーションＢとＳｉｎｋ機器上で起動している別のＳｉｎｋアプリケーションＥによるＤＴＣＰ−ＩＰ ＡＫＥを実施するための処理手順について、図１０を参照しながら説明する。
【０１１５】
Ｓｉｎｋ機器では、ＳｉｎｋアプリケーションＤが、ＳｏｕｒｃｅアプリケーションＢから受理したＡＫＥトリガ情報によりデータ送受信の準備を行なう。そして、ＳｉｎｋアプリケーションＤは、秘匿データ操作不可レイヤＤを通じて秘匿データ操作可能レイヤ_3_4にＳｏｕｒｃｅ機器の情報を渡し、有効なＫxをまだ共有していないＳｏｕｒｃｅ機器であることを確認して、ＳｏｕｒｃｅアプリケーションＢとのＤＴＣＰ−ＩＰ  ＡＫＥを開始する（同上）。
【０１１６】
ＳｉｎｋアプリケーションＤとのＤＴＣＰ−ＩＰ ＡＫＥが開始すると、ＳｏｕｒｃｅアプリケーションＢは、Ｋx識別情報_2を通じて、ＤＴＣＰ−ＩＰ ＡＫＥに必要なＫxに関連する情報を取得できる状態にある。この認証中に、秘匿データ操作可能レイヤ２へそのＳｉｎｋ機器の情報を渡すことで、そのＳｉｎｋ機器との認証を識別できるＳｏｕｒｃｅ認証セッション情報を、秘匿データ操作不可レイヤＢにて取得することができる。
【０１１７】
ここで、ＳｏｕｒｃｅアプリケーションＢはさらに、ＡＫＥトリガ情報をＳｉｎｋアプリケーションＥへ、ネットワーク経由で渡す。これに対し、ＳｉｎｋアプリケーションＥは、ＡＫＥトリガ情報を基に、ＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。続いて、ＳｏｕｒｃｅアプリケーションＢとＳｉｎｋアプリケーションＥでＤＴＣＰ−ＩＰ ＡＫＥの開始を試みる。
【０１１８】
ＳｉｎｋアプリケーションＥでは、秘匿データ操作不可レイヤＥを通じて秘匿データ操作可能レイヤ_3_4へそのＳｏｕｒｃｅ機器の情報を渡す。そして、秘匿データ操作可能レイヤ_3_4では、Ｓｏｕｒｃｅ機器の情報がＳｏｕｒｃｅ機器識別情報_4と一致していることから、そのＳｏｕｒｃｅ機器との認証を示すＳｉｎｋ認証セッション情報が既に取得されていると判断し、さらにそのＳｏｕｒｃｅ機器とは認証セッションが継続中であることを判断する。この結果が秘匿データ操作不可レイヤＥを通じてＳｉｎｋアプリケーションＥに通知される。ＳｉｎｋアプリケーションＥでは、同じＳｏｕｒｃｅ機器に対する認証が継続中であることを認識すると、当該ＤＴＣＰ−ＩＰ  ＡＫＥの手続きを失敗としてハンドリングする。
【０１１９】
このように、Ｓｉｎｋ機器は、同じＳｏｕｒｃｅ機器に対して連続して認証を実行する際に、１つ目の認証が終了する前に２つ目以降の認証が実行された場合、２つ目以降の認証手続きを失敗させることにより、無駄な認証トラフィックを避けるようにしている。
【０１２０】
続いて、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器と一旦認証を完了している状態で、Ｓｉｎｋ機器上で起動している別のＳｉｎｋアプリケーションがさらに同じＳｏｕｒｃｅアプリケーションに対してＤＴＣＰ−ＩＰ ＡＫＥを実施する際の処理手順について、図１１を参照しながら説明する。
【０１２１】
まず、ＳｏｕｒｃｅアプリケーションＢは、ＡＫＥトリガ情報でＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。そして、ＳｏｕｒｃｅアプリケーションＢは、ＡＫＥトリガ情報をＳｉｎｋアプリケーションＥへ、ネットワーク経由で渡す。
【０１２２】
なお、ＳｏｕｒｃｅアプリケーションＢにおいては、Ｋx識別情報_2を通じて、ＤＴＣＰ−ＩＰ ＡＫＥに必要なＫxに関連する情報を取得できる状態にある。この認証中に、秘匿データ操作可能レイヤ２へそのＳｉｎｋ機器の情報を渡すことで、そのＳｉｎｋ機器との認証を識別できるＳｏｕｒｃｅ認証セッション情報を、秘匿データ操作不可レイヤＢにて取得することができる（同上）。
【０１２３】
これに対し、ＳｉｎｋアプリケーションＥは、ＡＫＥトリガ情報を基に、ＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。そして、続いて、ＳｏｕｒｃｅアプリケーションＢとＳｉｎｋアプリケーションＥでＤＴＣＰ−ＩＰ ＡＫＥの開始を試みる。
【０１２４】
ここで、ＳｉｎｋアプリケーションＥは、秘匿データ操作不可レイヤＤを通じて秘匿データ操作可能レイヤ_3_4にＳｏｕｒｃｅ機器の情報を渡す。そして、秘匿データ操作可能レイヤ_3_4では、Ｓｏｕｒｃｅ機器の情報がＳｏｕｒｃｅ機器識別情報_4と一致していることから、そのＳｏｕｒｃｅ機器とは既に共有したＫxを生成若しくは取得済みであると判断する。
【０１２５】
Ｓｉｎｋ機器は、秘匿データ操作不可レイヤ_3_4において、Ｓｏｕｒｃｅ機器の識別情報と結び付けてＫx識別情報を登録しているので、Ｓｏｕｒｃｅ機器固有のＫx識別情報を取得する際に、ＩＰアドレスなどそのＳｏｕｒｃｅ機器を識別する情報に対する認証が既に終了しているかどうかを判断することができる。
【０１２６】
そして、さらにそのＳｏｕｒｃｅ機器とは認証が完了したことを判断すると、そのときのＳｏｕｒｃｅ機器識別情報に結び付けられているＫx_4に対応したＫx識別情報_4を、秘匿データ操作不可レイヤＥにて取得する。図９には、そのときの様子を示している。また、ＳｉｎｋアプリケーションＥでは認証が既に成功していたと判断すると、当該ＤＴＣＰ−ＩＰ  ＡＫＥの手続きを実行しない。この場合、ＳｉｎｋアプリケーションＥは、既に取得しているＫx識別情報を利用することで、ＳｏｕｒｃｅアプリケーションＢとのコンテンツ送受信を実施することができる。
【０１２７】
このように、Ｓｉｎｋ機器は、認証終了済みと判断されるＳｏｕｒｃｅ機器とは、認証手続きを行なうことなく、そのときＳｏｕｒｃｅ機器と結び付いているＫx識別情報を取得するようにして、無駄な認証トラフィックを回避することができる。
【０１２８】
Ｃ−３．Ｓｏｕｒｃｅ機器における処理動作
図１２には、Ｃ−１及びＣ−２項で説明したＳｏｕｒｃｅ機器における動作を実現するための処理手順をフローチャートの形式で示している。
【０１２９】
まず、秘匿データ操作可能レイヤにおいてＫxを生成し（ステップＳ１）、秘匿データ操作不可レイヤにおいてそのＫx識別情報を取得する（ステップＳ２）。
【０１３０】
そして、全体処理終了の指示があるまでの間に、ＡＫＥ待機処理の指示が発生する度に（ステップＳ３）、ステップＳ４に進み、以降の処理を実施する。
【０１３１】
ステップＳ４では、ＴＣＰ／ＩＰネットワークによるデータ送受信が出来るような準備を行なう。そして、ステップＳ３において指示されたＡＫＥ待機処理の終了が指示されるまで、ステップＳ５〜Ｓ９の処理手順を繰り返し行なう。
【０１３２】
ステップＳ５では、Ｓｉｎｋ危機へＡＫＥトリガ情報を渡す指示があるかどうかをチェックし、当該支持があればＡＫＥトリガ情報をＳｉｎｋ機器へ渡す（ステップＳ６）。
【０１３３】
次いで、Ｓｉｎｋ機器からＡＫＥを受け付けたかどうかをチェックし（ステップＳ７）、ＡＫＥを受け付けた場合には、Ｓｉｎｋ機器の情報を渡すことによってＳｏｕｒｃｅ認証セッション情報を取得する（ステップＳ８）。そして、ＡＫＥが終了する、又はＡＫＥ処理停止命令があるまで、ＤＴＣＰ−ＩＰ  ＡＫＥ処理を実施する（ステップＳ９）。この間、Ｓｏｕｒｃｅアプリケーションは、必要に応じて、Ｋx識別情報を通じて、ＤＴＣＰ−ＩＰ ＡＫＥに必要なＫxに関連する情報を取得できる状態にある。
【０１３４】
Ｓｏｕｒｃｅ機器に対して全体処理終了の指示があると、起動されたＡＫＥ処理を停止し、その停止を確認して（ステップＳ１０）、本処理ルーチン全体を終了する。
【０１３５】
Ｃ−４．Ｓｉｎｋ機器における処理動作
図１３には、Ｃ−１及びＣ−２項で説明したＳｉｎｋ機器における動作を実現するための処理手順をフローチャートの形式で示している。
【０１３６】
Ｓｉｎｋ機器は、全体処理終了の指示があるまでの間に、ＡＫＥ待機処理の指示が発生する度に（ステップＳ２１）、ステップＳ２２に進み、以降の処理を実施する。
【０１３７】
ステップＳ２２では、ＴＣＰ／ＩＰネットワークによるデータ送受信ができるような準備を行なう。
【０１３８】
次いで、同じＳｏｕｒｃｅ機器からのＫxを生成若しくは取得していないかどうかをチェックする（ステップＳ２３）。この判断は、受信したＡＫＥトリガ情報から抜き出したＳｏｕｒｃｅ機器情報に基づいて行なうことができる。
【０１３９】
ここで、同じＳｏｕｒｃｅ機器からのＫxを生成若しくは取得している場合には、既に取得してあったＫxを利用して当該Ｓｏｕｒｃｅ機器からコンテンツ受信処理を行なうことができるので（ステップＳ２７）、ＤＴＣＰ−ＩＰ  ＡＫＥを実施せずに、本処理ルーチン全体を終了する。
【０１４０】
一方、同じＳｏｕｒｃｅ機器からのＫxを生成若しくは取得していない場合には、続いて、新規にＳｉｎｋ認証セッション情報を取得できるかどうかをチェックする（ステップＳ２４）。この判断も、受信したＡＫＥトリガ情報から抜き出したＳｏｕｒｃｅ機器情報に基づいて行なうことができる。
【０１４１】
ここで、新規にＳｉｎｋ認証セッション情報を取得できないときには、認証処理に失敗したとして取り扱い（ステップＳ２８）、本処理ルーチン全体を終了する。
【０１４２】
また、新規にＳｉｎｋ認証セッション情報を取得できるときには、Ｓｉｎｋ認証セッション情報を取得し（ステップＳ２５）、ＡＫＥが終了する、又はＡＫＥ処理停止命令があるまで、ＤＴＣＰ−ＩＰ  ＡＫＥ処理を実施する（ステップＳ２６）。この間、Ｓｉｎｋアプリケーションは、必要に応じて、Ｋx識別情報を通じて、ＤＴＣＰ−ＩＰ ＡＫＥに必要なＫxに関連する情報を取得できる状態にある。
【０１４３】
Ｓｉｎｋ機器に対して全体処理終了の指示があると、起動されたＡＫＥ処理を停止し、その停止を確認して（ステップＳ２９）、本処理ルーチン全体を終了する。
【産業上の利用可能性】
【０１４４】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１４５】
本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）、コンテンツ伝送、並びにコンテンツ鍵確認の手続き毎にＴＣＰコネクションが確立されるという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。所定の認証手続きを経て機器間で共有される鍵を秘匿性を保ちながら管理し且つコンテンツ復号時などに随時使用する必要のある他のタイプの情報通信システムに対しても、同様に本発明を適用することができる。
【０１４６】
本明細書では、本発明をＤＴＣＰ−ＩＰに適用した実施形態を中心に説明してきたが、ＩＥＥＥ１３９４を伝送路とするＤＴＣＰ技術、あるいはＵＳＢやＭＯＳＴ（Ｍｅｄｉａ  Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ（例えば、ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｍｏｓｔｃｏｏｒｅｐａｔｉｏｎ．ｃｏｍ／を参照のこと））、あるいはＢｌｕｅｔｏｏｔｈ通信などを伝送路とするネットワーク・システムにも同様に本発明を適用することができる。
【０１４７】
図２に示した例では、Ｓｏｕｒｃｅ機器側では秘匿データ操作不可レイヤはＤＴＣＰ−ＩＰ用Ｓｏｕｒｃｅアプリケーション毎に１つ起動するようになっているが、Ｓｏｕｒｃｅ機器毎に１つだけ起動するようにしてもよい。また、図２に示した例では、Ｓｏｕｒｃｅ機器側では秘匿データ操作可能レイヤはＳｏｕｒｃｅ機器毎に１つだけ起動するようになっているが、ＤＴＣＰ−ＩＰ用Ｓｏｕｒｃｅアプリケーション毎に１つ起動するようにしてもよい。
【０１４８】
図３に示した例では、Ｓｉｎｋ機器側では秘匿データ操作不可レイヤはＤＴＣＰ−ＩＰ用Ｓｉｎｋアプリケーション毎に１つ起動するようになっているが、Ｓｏｕｒｃｅ機器毎に１つだけ起動するようにしてもよい。また、図３に示した例では、Ｓｉｎｋ機器側では秘匿データ操作可能レイヤはＳｉｎｋ機器毎に１つだけ起動するようになっているが、ＤＴＣＰ−ＩＰ用Ｓｉｎｋアプリケーション毎に１つ起動するようにしてもよい。
【０１４９】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【０１５０】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、Ｓｏｕｒｃｅ機器における通信ソフトウェアのスタック構造を模式的に示した図である。
【図３】図３は、Ｓｉｎｋ機器における通信ソフトウェアのスタック構造を模式的に示した図である。
【図４】図４は、Ｓｏｕｒｃｅ 機器ＡとＳｉｎｋ機器、並びにＳｏｕｒｃｅ機器とＳｉｎｋ機器でＤＴＣＰ−ＩＰ ＡＫＥを実施する前の様子を模式的に示した図である。
【図５】図５は、Ｓｏｕｒｃｅ 機器ＡとＳｉｎｋ機器、並びにＳｏｕｒｃｅ機器とＳｉｎｋ機器でＤＴＣＰ−ＩＰ ＡＫＥを実施した後の様子を模式的に示した図である。
【図６】図６は、ＡＫＥトリガ情報の構成例を示した図である。
【図７】図７は、Ｓｏｕｒｃｅ機器識別情報としてのＩＰアドレスと認証により共有するＫxの組み合わせを例示した図である。
【図８】図８は、ＤＴＣＰ−ＩＰ ＡＫＥが終了して、Ｓｏｕｒｃｅ機器識別情報_4の登録が済んだときの状態を示した図である。
【図９】図９は、Ｓｉｎｋアプリケーションが、Ｓｏｕｒｃｅ機器と共有しているＫxを既に生成済みであると判断し、且つ、そのＳｏｕｒｃｅ機器とは認証が完了したということを判断して、そのときのＳｏｕｒｃｅ機器識別情報に結び付けられているＫx_4に対応したＫx識別情報_4を秘匿データ操作不可レイヤＥにて取得する様子を示した図である。
【図１０】図１０は、Ｓｉｎｋ機器が同じＳｏｕｒｃｅ機器に対して連続して認証を実行する際に、１つ目の認証が終了する前に２つ目以降の認証が実行されたときの動作シーケンスを示した図である。
【図１１】図１１は、Ｓｉｎｋ機器がＳｏｕｒｃｅ機器と一旦認証を完了している状態で、Ｓｉｎｋ機器上で起動している別のＳｉｎｋアプリケーションがさらに同じＳｏｕｒｃｅアプリケーションに対してＤＴＣＰ−ＩＰ ＡＫＥを実施する際の動作シーケンスを示した図である。
【図１２】図１２は、Ｓｏｕｒｃｅ機器において実行する処理手順を示したフローチャートである。
【図１３】図１３は、Ｓｉｎｋ機器において実行する処理手順を示したフローチャートである。
【図１４】図１４は、ＤＴＣＰ＿ＩＰに準拠するＳｏｕｒｃｅ機器とＳｉｎｋ機器の間でＡＫＥに基づく鍵交換手続き、及び鍵交換により共有した鍵を利用した暗号化コンテンツ伝送を行なう仕組みを示した図である。
【図１】
2007043475.tif 000003
【図２】
2007043475.tif 000004
【図３】
2007043475.tif 000005
【図４】
2007043475.tif 000006
【図５】
2007043475.tif 000007
【図６】
2007043475.tif 000008
【図７】
2007043475.tif 000009
【図８】
2007043475.tif 000010
【図９】
2007043475.tif 000011
【図１０】
2007043475.tif 000012
【図１１】
2007043475.tif 000013
【図１２】
2007043475.tif 000014
【図１３】
2007043475.tif 000015
【図１４】
2007043475.tif 000016