会議システムにおけるセキュリティで保護された鍵管理
本発明の原理は、会議システムなどの通信環境において使用するための１つまたは複数のセキュリティで保護された鍵管理プロトコルを提供する。例えば、通信システムにおいて２名以上の関係者の間で会議を管理するための方法が、以下のステップを備える。ＩＤベースの認証された鍵交換動作が、通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間で実行され、その会議管理要素とその２名以上の関係者の間で交換されるメッセージは、それらのメッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素は、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する。会議管理要素が、それらの関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信する。会議管理要素が、各関係者から、ランダムなグループ鍵構成要素を受信し、このランダムなグループ鍵構成要素は、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される。会議管理要素が、各関係者に、それらの関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信して、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにする。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照により開示が本明細書に組み込まれている、整理番号８０５７１４で識別され、「Ｓｅｃｕｒｅ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ ｉｎ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ」という名称の、本出願の譲受人に譲渡され、同時に出願された米国特許出願に関連する。
【０００２】
本発明は、一般に、通信セキュリティに関し、より詳細には、マルチメディア通信システムおよび電話会議システムのメディアプレーンなどの通信環境において使用するためのセキュリティで保護された鍵管理プロトコルに関する。
【背景技術】
【０００３】
マルチメディア通信システムにおいて提供される既存のマルチメディアアプリケーションは、メディアプレーンにおけるセキュリティをサポートしない。メディアプレーンセキュリティに関する懸念は、比較的新しい問題である。
【０００４】
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）などのマルチメディア通信システムにおける既存の提案は、鍵を作成して、配信する可能性がある鍵管理サーバを使用して管理される、何らかの種類のトークンベースの対称鍵方法に基づく。参照により開示が本明細書に組み込まれている３ＧＰＰ（第３世代パートナーシッププロジェクト）ＴＲ（技術レポート）３３．８２８が、ＩＭＳメディアプレーン暗号化に関する既存の提案を説明する。しかし、これらの既存のソリューションは、スケーラブルではなく（サーバが、高度に応対可能であるとともに、常時、オンラインでなければならないので）、エンティティの認証を提供せず、加えて、サーバにおける鍵供託も提供しない。
【０００５】
逆に、ＳＫＹＰＥ（ルクセンブルクのスカイプテクノロジーズ社の商標）や、その他のクライアントツークライアントマルチメディアアプリケーションなどの非ＩＭＳアプリケーションは、認証を用い、鍵供託は用いない終端間プライバシーを提供する。しかし、このソリューションは、管理するのに極めて高い費用がかかる、利用可能性が非常に高い公開鍵インフラストラクチャ（ＰＫＩ）を要求する証明書の使用に依拠する。さらに、このソリューションは、グループ会議アプリケーションに合わせて十分にスケーリングされず、ＰＫＩが存在しない状況下で通信の合法な傍受を可能にすることもない。
【０００６】
さらに、同様な鍵管理セキュリティ問題が、関係者が会議サーバ経由で呼セッションに参加する会議システムに存在する。
【０００７】
このため、マルチメディア通信システムおよび電話会議システムのメディアプレーンなどの通信環境において使用するためのセキュリティで保護された鍵管理ソリューションの必要性が存在する。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】ＢｏｎｅｈおよびＦｒａｎｋｌｉｎ、ｓｃｃ Ｄａｎ Ｂｏｎｅｈ、Ｍａｔｔｈｅｗ Ｋ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ｅｎｃｒｙｐｔｉｏｎ ｆｒｏｍ ｔｈｅ Ｗｅｉｌ Ｐａｉｒｉｎｇ」、Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｇｒａｐｈｙ − Ｐｒｏｃｅｅｄｉｎｇ ｏｆ ＣＲＹＰＴＯ ２００１（２００１年）
【非特許文献２】Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｉｏｎ（ＩＴＵ−Ｔ）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．３２３
【非特許文献３】Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＩＥＴＦ ＲＦＣ３２６１
【非特許文献４】３ＧＰＰ技術仕様、ＴＳ２３．２１８
【非特許文献５】３ＧＰＰ技術仕様、ＴＳ２３．２２８
【非特許文献６】３ＧＰＰ技術仕様、ＴＳ２４．２２８
【非特許文献７】３ＧＰＰ技術仕様、ＴＳ２４．２２９
【非特許文献８】３ＧＰＰ技術仕様、ＴＳ２４．２３０
【非特許文献９】ＩＥＴＦ ＲＦＣ２２４６
【非特許文献１０】ＩＥＴＦ ＲＦＣ３７１１
【非特許文献１１】ＩＥＴＦ ＲＦＣ２６３３
【非特許文献１２】ＩＥＴＦ ＲＦＣ２４０６
【非特許文献１３】ＩＥＴＦ ＲＦＣ２４０９
【非特許文献１４】ＩＥＴＦ ＲＦＣ４３０６
【非特許文献１５】ＩＥＴＦ ＲＦＣ４３０８
【非特許文献１６】ＩＥＴＦ ＲＦＣ２２４６
【非特許文献１７】３ＧＰＰ技術仕様、ＴＳ３３．２２０
【非特許文献１８】Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ １、Ｔｈｅ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３３４６−９
【非特許文献１９】Ｗ．Ｒｉｃｈａｒｄ ＳｔｅｖｅｎｓおよびＧａｒｙ Ｒ．Ｗｒｉｇｈｔ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ２、Ｔｈｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ、ＩＳＢＮ ０−２０１−６３３５４−Ｘ
【非特許文献２０】Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ３、ＴＣＰ ｆｏｒ Ｔｒａｎｓａｃｔｉｏｎｓ，ＨＴＴＰ，ＮＮＴＰ，ａｎｄ ＵＮＩＸ Ｄｏｍａｉｎ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３４９５−３
【非特許文献２１】ＩＥＴＦ ＲＦＣ５０９１
【非特許文献２２】ＩＥＴＦ ＲＦＣ５４０８
【非特許文献２３】ＩＥＴＦ ＲＦＣ５４０９
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の原理は、会議システムなどの通信環境において使用するための１つまたは複数のセキュリティで保護された鍵管理プロトコルを提供する。
【課題を解決するための手段】
【００１０】
例えば、一態様において、通信システムにおいて２名以上の関係者の間で会議を管理するための方法が、以下のステップを備える。ＩＤベースの認証された鍵交換動作が、通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間で実行され、その会議管理要素とその２名以上の関係者の間で交換されるメッセージは、それらのメッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素は、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する。
【００１１】
会議管理要素が、それらの関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信する。会議管理要素が、各関係者からランダムなグループ鍵構成要素を受信し、このランダムなグループ鍵構成要素は、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される。
【００１２】
会議管理要素が、各関係者に、それらの関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信して、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにする。
【００１３】
一実施形態において、会議管理要素は、会議における参加する関係者ではなく、その結果、グループ鍵を計算することができない。別の実施形態において、会議管理要素は、会議呼における参加する関係者であり、その結果、グループ鍵を計算することができる。
【００１４】
一実施形態において、各関係者によって計算されるグループ鍵は、Ｎａｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋．．．＋Ｘｉ−２として表現され、ただし、Ｎは、会議に参加することを求めている関係者の総数を表し、ａｉは、所与の関係者によって選択された乱数を表し、Ｚｉは、所与の関係者によって計算されるランダムな鍵構成要素を表し、Ｘｉは、所与の関係者によって計算されるランダムなグループ鍵構成要素を表し、さらにｉは、Ｎ名の関係者の会議における所与の関係者に関する会議順序付けの番号を表し、ｉ＝１の場合、ｉ−１＝Ｎであり、ｉ＝Ｎである場合、ｉ＋１＝１である。
【００１５】
一実施形態において、所与の関係者に関するランダムな鍵構成要素は、ａｉＰとして表現される計算によって計算され、ただし、ａｉは、所与の関係者によって選択された乱数であり、さらにＰは、ＩＤ暗号化ベースの鍵認証動作に関連するグループから選択された点である。
【００１６】
一実施形態において、所与の関係者に関するランダムなグループ鍵構成要素は、ａｉ（ａｉ＋１Ｐ−ａｉ−１Ｐ）として表現される計算によって計算され、ただし、ａｉは、その所与の関係者によって選択された乱数であり、ａｉ＋１Ｐは、会議順序付けにおいてその所与の関係者の直後に続く関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、ａｉ−１Ｐは、会議順序付けにおけるその所与の関係者の直前の関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、さらにＰは、暗号鍵交換プロトコルに関連するグループから選択された点である。
【００１７】
本発明の原理は、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）環境に特に適しているが、本発明は、そのように限定されることは意図していないことを認識されたい。つまり、本発明の原理は、セキュリティで保護された鍵管理フィーチャを提供することが望ましい任意の適切な通信システムに一般に適用可能である。
【００１８】
本発明のこれら、およびその他の目的、特徴、および利点は、添付の図面と併せて読まれるべき、本発明の例示的な実施形態の以下の詳細な説明から明白となろう。
【図面の簡単な説明】
【００１９】
【図１Ａ】本発明の或る実施形態による秘密鍵獲得方法を示す図である。
【図１Ｂ】本発明の或る実施形態によるＩＤベースの認証された鍵交換方法を示す図である。
【図２】本発明の或る実施形態による鍵分岐方法を示す図である。
【図３】本発明の或る実施形態による呼リダイレクト方法を示す図である。
【図４Ａ】本発明の或る実施形態による遅延配信方法を示す図である。
【図４Ｂ】本発明の別の実施形態による遅延配信方法を示す図である。
【図５】本発明の或る実施形態による合法な傍受方法を示す図である。
【図６Ａ】本発明の或る実施形態による会議管理方法を示す図である。
【図６Ｂ】本発明の或る実施形態による会議管理方法における参加者の追加を示す図である。
【図６Ｃ】本発明の或る実施形態による会議管理方法における参加者の削除を示す図である。
【図７】本発明のＩＭＳベースの実施形態によるセキュリティで保護された鍵管理プロトコルに関するネットワークアーキテクチャを示す図である。
【図８】本発明のＩＭＳベースの実施形態による鍵分岐方法を示す図である。
【図９】本発明のＩＭＳベースの実施形態によるリダイレクト方法を示す図である。
【図１０】本発明のＩＭＳベースの実施形態による３名の参加者を有する会議方法を示す図である。
【図１１】本発明の実施形態によるプロトコルの１つまたは複数を実施するのに適したデータネットワークおよび通信（コンピューティング）デバイスの一般化されたハードウェアアーキテクチャを示す図である。
【発明を実施するための形態】
【００２０】
本明細書で使用される「マルチメディア通信システム」という句は、一般に、テキストベースのデータ、グラフィックスベースのデータ、音声ベースのデータ、およびビデオベースのデータを含むが、以上には限定されない２つ以上のタイプのメディアをトランスポートすることができる任意の通信システムとして定義される。
【００２１】
本明細書で使用される「メディアプレーン」という句は、一般に、呼セッションにおける２つ以上の関係者の間で１つまたは複数のタイプのメディアが交換されるのに準拠するマルチメディア通信システムの機能部分として定義される。このことは、呼セッションを確立するために呼ネゴシエーション／スケジューリングが実行されるのに準拠するマルチメディア通信システムの機能部分である「制御プレーン」と対比される。本発明の技術が使用され得るメディアプレーンアプリケーションの例には、ボイスオーバーＩＰ（ＶｏＩＰ）、インスタントメッセージング（ＩＭ）、ボイス／オーディオＩＭ、およびボイスシェアが含まれるが、以上には限定されない。メディアプレーンは、アプリケーション層トラフィックを含むものと理解される。
【００２２】
本明細書で使用される「鍵」という用語は、一般に、エンティティ認証、プライバシー、メッセージ完全性などを目的とするが、以上の目的には限定されない、暗号プロトコルへの入力として定義される。
【００２３】
参照を容易にするため、詳細な説明は、以下のとおり分けられる。段落Ｉが、ＩＤベースの暗号化動作およびＩＤベースの認証された鍵交換動作の一般的な原理を説明する。段落ＩＩが、一般的な通信環境コンテキストにおける本発明の例示的な原理によるセキュリティで保護された鍵管理ソリューションを説明する。段落ＩＩＩが、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）環境コンテキストにおける本発明の例示的な原理によるセキュリティで保護された鍵管理ソリューションを説明する。段落ＩＶが、本発明による１つまたは複数のセキュリティで保護された鍵管理プロトコルを実施するための例示的なコンピューティングシステムを説明する。
【００２４】
Ｉ．ＩＤベースの暗号化（ＩＢＥ）およびＩＤベースの認証された鍵交換（ＩＢＡＫＥ）
本発明のセキュリティで保護された鍵管理技術の例示的な実施形態の説明に先立って、ＩＢＥおよびＩＢＡＫＥの一般的な原理が与えられる。
【００２５】
Ａ．ＩＤベースの暗号化
ＩＤベースの暗号化（ＩＢＥ）プロトコルは、参照により開示が本明細書に組み込まれている、ＢｏｎｅｈおよびＦｒａｎｋｌｉｎによって提示された（Ｄａｎ Ｂｏｎｅｈ、Ｍａｔｔｈｅｗ Ｋ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ｅｎｃｒｙｐｔｉｏｎ ｆｒｏｍ ｔｈｅ Ｗｅｉｌ Ｐａｉｒｉｎｇ」、Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｇｒａｐｈｙ − Ｐｒｏｃｅｅｄｉｎｇ ｏｆ ＣＲＹＰＴＯ ２００１（２００１年）を参照）。この非対称暗号法の暗号化プロトコルは、参加者が、「ＩＤ」（例えば、電子メールＩＤ、またはドメイン名）を公開鍵として使用することを許し、ＲＳＡ（リベスト、シャミール、およびアドルマン）などの公開鍵暗号化方法にしばしば関連する大規模な公開鍵インフラストラクチャの必要性を解消する。この問題に対するＢｏｎｅｈおよびＦｒａｎｋｌｉｎのアプローチは、有限体上の楕円曲線上の双線形写像を使用し、さらに双線形決定ディフィ−ヘルマン問題に依拠する。
【００２６】
ＩＢＥには、以下の数学ツールおよびパラメータがかかわる：
Ｅを有限体Ｆ上の楕円曲線とし、Ｐを大きい素数位数の点とする。
【００２７】
ｅ：ＥｘＥ−→ＧをＥ上の双線形写像とする。典型的な例が、ヴェイユペアリングであり、したがって、Ｇは、ｎがＦ上のＥ上の点の数の関数である１のｎ乗根の群である。
【００２８】
ｓを０でない正の整数とし、鍵生成関数（ＫＧＦ）の中に格納された秘密とする。これは、システム全体の秘密であり、ＫＧＦの外部には明かされない。
【００２９】
Ｐｐｕｂ＝ｓＰを、すべての参加者に知られているシステムの公開鍵とする。ｓＰは、Ｅが群であるので、Ｅの中の点を表すことを想い起こされたい。
【００３０】
Ｈ１を、或る文字列をとり、その文字列を、楕円曲線上の或る点に割り当てる、知られているハッシュ関数とし、すなわち、Ｅ上のＨ１（Ａ）＝ＱＡであり、ただし、Ａは、通常、ＩＤであり、さらにＡの公開鍵でもある。
【００３１】
ｄＡ＝ｓＱＡを、ＫＧＦによって計算され、Ａだけに配信される秘密鍵であるものとする。
【００３２】
Ｈ２を、Ｇの要素をとり、その要素を或る文字列に割り当てる、知られているハッシュ関数とする。
【００３３】
ｍを、暗号化されて、Ａに送信される必要があるメッセージとする。ＢｏｎｅｈおよびＦｒａｎｋｌｉｎによって説明される暗号化関数は、以下のとおりである。
【００３４】
ｇＡ＝ｅ（ＱＡ，Ｐｐｕｂ）とし、さらにｒを乱数とする。
【００３５】
暗号化Ａ（ｍ）＝（ｒＰ，ｍ ｘｏｒ Ｈ２（ｇＡＩ））であり、つまり、ｍの暗号化出力は、２つの座標ｕおよびｖを有し、ただし、ｕ＝ｒＰであり、ｖ＝ｍ ｘｏｒ Ｈ２（ｇＡＩ）である。「ｘｏｒ」とは、排他的論理和関数を指すことに留意されたい。
（ｕ，ｖ）を解読するために、Ａは、以下の式を使用してｍを回復する：
ｍ＝ｖ ｘｏｒ Ｈ２（ｃ（ｄＡ，ｕ））
この式の証明は、双線形写像において単純明快な作業であり、事実Ａは、秘密ｄＡ（Ａだけには知られているが、その他の参加者には知られていない秘密鍵）を有する。また、そもそもｄＡを計算したＫＧＦは、そのメッセージを解読することもできて、ＫＧＦが、事実上、鍵供託サーバであることになることにも注目されたい。
【００３６】
Ｂ．ＩＤベースの認証された鍵交換
ＩＢＡＫＥ（ＩＤベースの認証された鍵交換）は、参照により開示が本明細書に組み込まれている、２００９年２月１７日に出願したシリアル番号１２／３７２，２４２によって識別される米国特許出願において説明される。ＩＢＡＫＥプロトコルは、デバイスが互いを相互に認証し、さらに完全な順方向の秘密および逆方向の秘密をもたらす鍵を導き出すことを可能とする。
【００３７】
本明細書で説明されるＩＢＡＫＥ実施形態において、このプロトコルに関する基本的なセットアップには、サブ段落Ａで前述した数学的構造およびパラメータがかかわる。このプロトコルは、非対称的であるが、ＰＫＩサポートを全く必要とせず、代わりに、このプロトコルは、鍵生成関数の役割をするオフラインサーバを使用することを思い起こされたい。このプロトコルの詳細を以下に概略で述べる。
【００３８】
Ａ、Ｂが、鍵を認証し、鍵について合意しようと試みている２つのエンティティ（または、Ａが第１の関係者のコンピュータシステムを表し、Ｂが第２の関係者のコンピュータシステムを表す、関係者）であるものと想定されたい。
【００３９】
ＡおよびＢを使用して、定義により、ＡおよびＢの公開鍵も表す、ＡおよびＢに対応するＩＤを表す。
【００４０】
Ｈ１（Ａ）＝ＱＡおよびＨ１（Ｂ）＝ＱＢを、公開鍵に対応する楕円曲線上のそれぞれの点とする。実際、ＩＤと、Ｈ１を適用することによって獲得される曲線上の点の間に１対１対応が存在するので、ＱＡおよびＱＢを公開鍵と呼ぶことも可能である。
【００４１】
ｘを、Ａによって選択された乱数とし、さらにｙをＢによって選択された乱数とする。
【００４２】
ＡとＢの間のプロトコル交換は、以下のステップから成る：
第１のステップで、Ａが、ｘＰ（すなわち、Ｅ上で加算則を使用して、Ｅ上の点としてｘ回、自らに加算されたＰ）を計算し、ｘＰを、Ｂの公開鍵を使用して暗号化し、さらに暗号化されたｘＰをＢに送信する。このステップにおいて、暗号化とは、前出のサブ段落Ａで説明されるＩＤベースの暗号化を指す。
この暗号化されたメッセージを受信すると、Ｂは、このメッセージを解読し、ｘＰを獲得する。その後、第２のステップで、Ｂは、ｙＰを計算し、Ａの公開鍵を使用してペア｛ｘＰ，ｙＰ｝を暗号化し、その後、暗号化されたペア｛ｘＰ，ｙＰ｝をＡに送信する。
このメッセージを受信すると、Ａは、このメッセージを解読し、ｙＰを獲得する。その後、第３のステップで、Ａは、Ｂの公開鍵を使用してｙＰを暗号化し、暗号化されたｙＰをＢに送り返す。
以上の後に続いて、ＡとＢがともに、ｘｙＰをセッション鍵として計算する。
Ａはｘをランダムに選択しており、さらにプロトコル交換の第２のステップでｙＰを受信していることに注目されたい。このことは、Ａが、ｙＰを自らにｘ回、加算することによってｘｙＰを計算することを可能とする。逆に、Ｂは、ｙをランダムに選択しており、さらにプロトコル交換の第１のステップでｘＰを受信している。このことは、Ｂが、ｘＰを自らにｙ回、加算することによってｘｙＰを計算することを可能とする。このプロトコルのいずれの適用も、ＩＤと一緒にヘッダデータを利用して、このプロトコルが適切に機能することを確実にすることが可能であることに留意されたい。このことは、比較的標準的であり、鍵合意のためのほとんどすべてのプロトコル交換に適用可能である。
また、ｘは、ランダムであるが、ｘＰは、ｘについての情報を全く与えないことに留意されたい。したがって、ｘＰは、Ａによって選択されたランダムな秘密に基づく鍵の構成要素である。同様に、ｙは、ランダムであるが、ｙＰは、ｙについての情報を全く供給しない。したがって、ｙＰは、Ｂだけに知られているランダムな秘密に基づく鍵の構成要素である。
ｘｙＰは、セッション鍵の役割をすることが可能であることにさらに留意されたい。また、セッション鍵は、ｘｙＰの任意の知られている関数であることが可能である。つまり、セッション鍵は、ｆ（ｘｙＰ）と等しいことが可能であり、ただし、ｆは、両方の関係者に知られており、秘密であることを要求されない（すなわち、世界に知られている）。ｆに関する１つの実際的な要件は、ｆが、ｘまたはｙの知識なしに計算するのが困難であることであり、さらに出力は、暗号法の見地から満足の行く長さ、例えば、約１２８ビット以上である。
【００４３】
ＩＢＡＫＥプロトコルの特性のいくつかには、以下が含まれる：
− 鍵供託を免れていること。プロトコル交換におけるすべてのステップは、ＩＢＥを使用して暗号化されることに注目されたい。したがって、明らかに、ＫＧＦは、すべての交換を解読することができる。しかし、ＫＧＦは、セッション鍵を計算することができない。このことは、楕円曲線ディフィ−ヘルマン問題の難しさのためである。つまり、ｘＰおよびｙＰを与えられて、ｘｙＰを計算することは計算的に困難である。
− 相互に認証された鍵合意。プロトコル交換におけるすべてのステップは、ＩＢＥを使用して暗号化されることに注目されたい。特に、Ｂだけが、第１のステップ、および第３のステップでＡによって送信されたメッセージの内容を解読することができ、同様にＡだけが、第２のステップでＢによって送信されたメッセージの内容を解読することができる。さらに、第２のステップの終わりで、Ａは、第１のステップでＢによって内容が解読された後だけ、ｘＰが第２のステップで送信されている可能性があるので、Ｂの真正性を検証することができる。同様に、第３のステップの終わりで、Ｂは、第２のステップの内容を正しく解読した後だけ、第ｙＰが３のステップで送り返されている可能性があり、正しく解読することは、Ａによってしか可能でないので、Ａの真正性を検証することができる。最後に、ＡとＢがともに、同一のセッション鍵について合意することが可能である。つまり、このプロトコルは、ＩＢＥに基づく、相互に認証された鍵合意プロトコルである。以上の説明は、プロトコルのセキュリティに関する動機を与えるが、セキュリティの暗号法上の証明が容易に与えられることが可能である。プロトコルの堅牢性は、楕円曲線の選択によって影響される、楕円曲線ディフィ−ヘルマン問題の難しさに依拠する。
− 完全な順方向の秘密および逆方向の秘密。ｘおよびｙは、ランダムなので、ｘｙＰは、常に新規であり、ＡとＢの間のいずれの過去のセッション、または将来のセッションとも無関係である。
− パスワードが存在しない。ＩＢＡＫＥプロトコルは、ＡとＢの間でパスワードまたは秘密鍵のオフライン交換を全く要求しない。事実、この方法は、任意の通信ネットワークを介して初めて通信している任意の２名の関係者に明らかに適用可能である。唯一の要件は、ＡとＢの両方が、例えば、ディレクトリサービスを介して、互いの公開鍵を認識していることを確実にすることだけである。
【００４４】
ＩＩ．セキュリティで保護された鍵管理、および例示的な拡張
インターネットが、ベストエフォートデータネットワークから、マルチメディアを含む様々なクラスのトラフィックに関するサポートを備えたマルチサービスＩＰ（インターネットプロトコル）ネットワークに急速に進化したことが認識されている。このことが、モバイルワイヤレスネットワークの急速な成長と相俟って、技術的な課題を生じさせている。技術的見地から、それなりにうまく対処されてきた中心的な課題が、「メディアプレーン」としばしば呼ばれるアプリケーション層トラフィックからの、呼をセットアップするシグナリングから成る呼制御機能の分離である。Ｈ３２３（例えば、参照により開示が本明細書に組み込まれている、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｉｏｎ（ＩＴＵ−Ｔ）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．３２３を参照）、セッション開始プロトコルまたはＳＩＰ（例えば、参照により開示が本明細書に組み込まれている、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＩＥＴＦ ＲＦＣ３２６１を参照）、およびＩＭＳ（例えば、参照により開示が本明細書に組み込まれている、３ＧＰＰ技術仕様、ＴＳ２３．２１８、ＴＳ２３．２２８、ＴＳ２４．２２８、ＴＳ２４．２２９、およびＴＳ２４．２３０を参照）などの呼制御プロトコルが、ＩＥＴＦや３ＧＰＰなどの様々な組織によって標準化されており、固定ネットワークおよびモバイルネットワークにわたって様々な採用段階にある。
【００４５】
同時に、様々なレベルでシグナリングをセキュリティで保護する入念な機構が組み込まれてきた。しかし、メディアプレーンにおいて、トランスポート層セキュリティまたはＴＬＳ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２２４６を参照）、セキュアリアルタイムトランスポートプロトコルまたはＳＲＴＰ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ３７１１を参照）などのプロトコル、およびセキュア多目的インターネットメール拡張またはＳＭＩＭＥ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２６３３を参照）が、様々なアプリケーションに関するコンテナフォーマットを提供するが、メディアプレーンにおけるセキュリティソリューションは、アプリケーション層において終端間のセキュリティで保護された鍵管理をサポートする一貫性のある、標準化された方法を欠いている。
【００４６】
本発明の原理は、主に、この問題に対処する。特に、本発明の原理は、メディアプレーンに関してスケーラブルなアプリケーション、およびプロトコルにとらわれないセキュリティで保護された鍵管理の枠組みを提供する。例示的な枠組みにおいて、本発明のソリューションは、段落Ｉ．Ｂで前述した非対称（したがって、公開鍵）ＩＢＡＫＥ（ＩＤベースの認証された鍵交換）プロトコルを利用する。例示的な実施形態は、例えば、セキュリティで保護された２名の関係者のメディアプレーン通信アプリケーション、セキュリティで保護された複数関係者会議アプリケーション、セキュリティで保護された呼分岐アプリケーション、セキュリティで保護された呼リダイレクトアプリケーション、およびセキュリティで保護された遅延配信アプリケーションなどの、様々なフィーチャをサポートする鍵交換機構を説明する。セキュリティで保護された鍵管理のためのスケーラブルな枠組みを提供することに加えて、この設計および枠組みのいくつかの例示的な態様には、以下が含まれる：
− 要求されるネットワークサポートの複雑度を劇的に低減するオフラインＫＭＳ（鍵管理サーバ）の使用。公開鍵環境における非対称プロトコルは、取消しを含む証明書管理の入念な常時オンのＰＫＩ（公開鍵インフラストラクチャ）サポートを要求することを思い起こされたい。対称鍵ベースの鍵管理サーバは、定義により、絶え間なく同期し、更新している「常時オン」のサーバである。この「常時オン」の要件をなくすことにより、我々の枠組みは、費用を劇的に低減し、スケーラビリティを促進する。
− ＩＤベースのプロトコルに特有の受動的な鍵供託の解消。鍵管理サーバを使用する対称鍵プロトコルは、この問題を解消することができないことを思い起こされたい。また、既存のＩＤベースの暗号化（段落Ｉ．Ａで前述した）プロトコルは、ＩＢＡＫＥ（段落Ｉ．Ｂで前述した）を使用して解決される問題である、鍵供託問題に悩まされることも思い起こされたい。
− このプロトコルの枠組みは、鍵交換に関与するエンティティの相互認証を、完全な秘密とともに本来的にサポートする。
− 本発明の例示的な実施形態は、既存のネットワーク要素アーキテクチャを再使用し、さらに、可能な限り、既存のプロトコルコンテナフォーマットを再使用する。例として、会議アプリケーションにおいて、例示的な実施形態は、会議サーバを再使用して、会議を可能にするが、会議サーバが、通信のために使用されるグループ鍵を知ることがない（後段で説明されるとおり、会議サーバも会議の関係者であるのではない限り）ことを確実にする。
− 本発明の原理は、受動的な鍵供託をなくすが、本発明のプロトコルは、呼を傍受する法の執行のための法的要件が存在する場合に、鍵を見出すことのシームレスなサポートも提供する。
【００４７】
ＩＤベースの非対称暗号法の枠組みに基づく例示的な実施形態において、各参加者は、公開鍵と、秘密鍵とを有する。その公開鍵は、ＩＤに基づく。その秘密鍵は、その公開鍵に対応し、鍵管理サーバまたは鍵管理サービス（ＫＭＳ）によって発行される。参加者は、ＫＭＳから秘密鍵をオフラインで獲得することができる。単に例として、参加者は、１カ月に（より一般的には、契約の全期間にわたって）一度、参加者のＫＭＳと連絡をとり、秘密鍵を獲得する。また、秘密鍵は、使用の頻度に応じて獲得されることも可能である。ＫＭＳと参加者の間にセキュリティ関連付けが存在するものと想定される。鍵交換中のメッセージの暗号化および解読は、ＩＢＥに基づく。ＫＭＳの公開のパラメータは、公衆に入手可能である（例えば、ウェブサイト上でオンラインで）と想定されることに留意されたい。
【００４８】
一般に、本発明の例示的な実施形態によるセキュリティで保護された鍵管理方法は、２つの主な段階を備える。第１の段階で、参加者（関係者）が、ＫＭＳなどの鍵サービスから秘密鍵を獲得する。第２の段階で、マルチメディアベースの呼セッションにおいて通信することを求める２名以上の関係者の間でＩＤベースの認証された鍵交換が、実行される。その２名以上の関係者の間で交換されるメッセージは、メッセージの受信者のそれぞれのＩＤに基づいて暗号化される。また、それらの関係者の間で交換される暗号化されたメッセージは、関係者に関連付けられたＩＤを含む。
【００４９】
図１Ａは、セキュリティで保護された鍵管理方法の第１の段階、すなわち、秘密鍵獲得を示す。図示されるとおり、２名の関係者の通信デバイス（より一般的には、コンピューティングデバイス）１０２がそれぞれ、それぞれのＫＭＳ１０４から秘密（またはシークレット）鍵を要求し、獲得する。秘密鍵交換１０６はセキュリティで保護された通信プロトコルによって行われる。セキュリティで保護された通信プロトコルの例には、インターネットプロトコルセキュリティまたはＩＰＳｅｃ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２４０６、ＩＥＴＦ ＲＦＣ２４０９、ＩＥＴＦ ＲＦＣ４３０６、およびＩＥＴＦ ＲＦＣ４３０８を参照）、およびトランスポート層セキュリティまたはＴＬＳ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２２４６を参照）が含まれるが、以上には限定されない。汎用ブートストラップアーキテクチャまたはＧＢＡ（例えば、参照により開示が本明細書に組み込まれている、３ＧＰＰ技術仕様（ＴＳ）３３．２２０を参照）が、各関係者とＫＭＳの間のセキュリティで保護された通信プロトコルにおいて使用すべき鍵を決定するのに使用されることが可能である。一例において、ＫＭＳサーバに接続され、さらに事前共有される鍵としてＧＢＡ鍵、またはＧＢＡ鍵と一緒にネットワーク層におけるＩＰＳｅｃを使用する（トランスポート制御プロトコルまたはＴＣＰより上位の）アプリケーション層（例えば、参照により開示が本明細書に組み込まれている、Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ １、Ｔｈｅ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３３４６−９、Ｗ．Ｒｉｃｈａｒｄ ＳｔｅｖｅｎｓおよびＧａｒｙ Ｒ．Ｗｒｉｇｈｔ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ２、Ｔｈｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ、ＩＳＢＮ ０−２０１−６３３５４−Ｘ、Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ３、ＴＣＰ ｆｏｒ Ｔｒａｎｓａｃｔｉｏｎｓ，ＨＴＴＰ，ＮＮＴＰ，ａｎｄ ＵＮＩＸ Ｄｏｍａｉｎ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３４９５−３を参照）においてＴＬＳを使用するクライアントデバイスにおいて実行されるアプリケーションが存在することが可能である。
【００５０】
左側のデバイスが開始側（Ｉ）と考えられ、右側のデバイスが応答側（Ｒ）と考えられることに留意されたい。この名称は、左側のデバイスが、右側のデバイスを相手にマルチメディア呼セッションを開始することを求めることに由来する。
【００５１】
図示されるとおり、各デバイスは、そのデバイスの要求と一緒に識別子をＫＭＳに供給し、このことに対して、ＫＭＳは、秘密（シークレット）鍵で応答する。開始側デバイス１０２−Ｉの場合、１つの識別子がＫＭＳ１０４−Ｉに供給され、これに応答して、１つの秘密鍵Ｉ−ＳＫがこのデバイスに供給される。応答側デバイス１０２−Ｒの場合、２つの別々の識別子、すなわち、ＲおよびＲ１が、ＫＭＳ１０４−Ｒに供給される。これに応答して、ＫＭＳは、応答する関係者に、２つの秘密鍵、Ｒ＿ＳＫおよびＲ１＿ＳＫを供給する。もちろん、各関係者は、いくつかの秘密鍵獲得スケジュールに基づいて、より多くの、またはより少ない秘密鍵を要求して、獲得してもよい。このスケジュールは、時間ベースのスケジュール（例えば、１カ月周期）、呼セッション頻度ベースのスケジュール（例えば、呼を行う必要がある場合）、および契約ベースのスケジュール（例えば、関係者は、いくらかの長さの期間にわたって、または契約終了条件が生じたことに基づいて、ＫＭＳの鍵サービスに契約をする）であることが可能である。
【００５２】
また、所与の関係者が複数の公開ＩＤを有する可能性もあることも認識されたい。例えば、関係者Ｂ（「ボブ」）が、以下の２つのＩＤ、すなわち、ｂｏｂ＠ｗｏｒｋ．ｃｏｍおよびｂｏｂ＠ｈｏｍｅ．ｃｏｍを有することが可能である。これら２つのＩＤに関して、異なる２つの公開鍵が存在することが可能であり、このため、異なる２つの秘密鍵が存在することが可能である。
【００５３】
図１Ｂは、セキュリティで保護された鍵管理方法の第２の段階、すなわち、認証された鍵交換を示す。この実施形態において、認証された鍵交換は、ＩＢＡＫＥ（段落Ｉ．Ｂで前述した）に基づく。第１の関係者と第２の関係者の間のメッセージ交換の好ましいフォーマットは、ＭＩＫＥＹ（マルチメディアインターネットキーイング）に基づくので、したがって、図１Ａおよび図１Ｂの全体的なセキュリティで保護された鍵交換プロトコルは、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルと本明細書では呼ばれる。
【００５４】
この場合も、左側のデバイスが、開始する関係者、つまり、開始側１０２−Ｉであり、右側のデバイスが、応答する関係者、つまり、応答側１０２−Ｒであるものと想定される。認証された鍵交換のステップは、ＩＢＡＫＥプロトコルと同様のステップをたどる。
【００５５】
開始側の公開鍵、Ｉ＿ＰＫは、段落Ｉで前述したハッシュ関数を使用することによって計算されるものと想定される。同様に、応答側の公開鍵、Ｒ＿ＰＫも同様に計算される。開始側および応答側の秘密鍵は、それぞれ、Ｉ＿ＳＫおよびＲ＿ＳＫであることを思い起こされたい。つまり、Ｈ１（Ｉｎｉｔｉａｔｏｒ＿ＩＤ）＝Ｉ＿ＰＫ、およびＨ１（Ｒｅｓｐｏｎｄｅｒ＿ＩＤ）＝Ｒ＿ＰＫを、それらの公開鍵に対応する楕円曲線上のそれぞれの点であるものとする。
【００５６】
ａを、開始側１０２−Ｉによって選択された乱数とし、ｂを、応答側１０２−Ｒによって選択された乱数とする。
【００５７】
１０２−Ｉと１０２−Ｒの間のプロトコル交換は、以下のステップを備える：
ステップ１１０で、開始側１０２−Ｉが、第１のランダムな鍵構成要素ａＰ（すなわち、Ｅ上で加算則を使用して、Ｅ上の点としてａ回、自らに加算されたＰ）を計算し、第１のランダムな鍵構成要素を、応答側の公開鍵（Ｒ＿ＰＫ）を使用して暗号化し、さらに暗号化された第１のランダムな鍵構成要素を応答側１０２−Ｒに送信する。このステップで、暗号化とは、前段のサブ段落Ｉ．Ａにおいて説明されるＩＤベースの暗号化を指す。ステップ１１０の暗号化されたメッセージにやはり含められるのが、開始側のＩＤ、および応答側のＩＤ（それぞれ、Ｉ＿ＩＤおよびＲ＿ＩＤ）であることに留意されたい。
【００５８】
この暗号化されたメッセージを受信すると、応答側は、応答側の秘密鍵（図１Ａで獲得された）を使用して、このメッセージを解読し、ａＰを獲得する。その後、ステップ１１２で、応答側は、第２のランダムな鍵構成要素ｂＰを計算し、開始側の公開鍵を使用してペア｛ａＰ，ｂＰ｝を暗号化し、その後、暗号化されたペア｛ａＰ，ｂＰ｝を開始側に送信する。この場合も、ステップ１１２の暗号化されたメッセージは、開始側のＩＤ、および応答側のＩＤ（それぞれ、Ｉ＿ＩＤおよびＲ＿ＩＤ）を含む。
【００５９】
ステップ１１２からのメッセージを受信すると、開始側は、このメッセージを、開始側の秘密鍵（図１Ａで獲得された）を使用して解読し、ｂＰを獲得する。その後、ステップ１１４で、開始側は、応答側の公開鍵を使用してｂＰを暗号化し、暗号化されたｂＰを応答側に送り返す。この場合も、ステップ１１４の暗号化されたメッセージは、開始側のＩＤ、および応答側のＩＤ（それぞれ、Ｉ＿ＩＤおよびＲ＿ＩＤ）を含む。
【００６０】
ステップ１１６で、応答側が、開始側の公開鍵を使用して暗号化された検証メッセージを開始側に送信する。
【００６１】
これを行った後、開始側と応答側の両方が、マルチメディア通信システムのメディアプレーン（アプリケーション層）を介して呼セッション中に互いにセキュリティで保護された通信を行うために使用されるべきセキュリティで保護された呼セッション鍵としてａｂＰを計算する。
【００６２】
開始側１０２−Ｉは、ａをランダムに選択しており、プロトコル交換の第２のステップでｂＰを受信していることに注目されたい。このことは、開始側が、ｂＰを自らにａ回、加算することによってａｂＰを計算することを可能とする。逆に、応答側１０２−Ｒは、ｂをランダムに選択しており、プロトコル交換の第１のステップでａＰを受信している。このことは、応答側が、ａＰを自らにｂ回、加算することによってａｂＰを計算することを可能とする。また、ａは、ランダムであるが、ａＰは、ａについての情報を全く与えないことにも留意されたい。したがって、ａＰは、開始側によって選択されたランダムな秘密に基づく鍵の構成要素であると考えられる。同様に、ｂは、ランダムであるが、ｂＰは、ｂについての情報を全く与えない。このため、ｂＰは、応答側だけに知られているランダムな秘密に基づく鍵の構成要素であると考えられる。
【００６３】
次に図２を参照すると、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張が示されている。この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。この特定の実施形態において、図２は、分岐を示す。分岐は、複数のロケーションへの要求の配信である。分岐は、例えば、応答側が、複数の通信（コンピューティング）デバイスを有して、それらのデバイス上で応答側がマルチメディア呼セッションに参加することができる場合に、行われる可能性がある。分岐の一例は、関係者が卓上電話機、パーソナルコンピュータ（ＰＣ)クライアント、移動ハンドセットを有し、全てがＭＩＫＥＹ−ＩＢＡＫＥプロトコルに参加している場合である。一般に、分岐は、着信する呼が、いくつかの内線を同時に鳴らして呼ぶことを可能にするマルチメディアセッション開始プロトコルのフィーチャである。最初に応答する電話機が、その呼を支配する。
【００６４】
したがって、図２に示されるとおり、応答側には、２つのデバイス１０２−Ｒ１および１０２−Ｒ２が関連付けられている。したがって、図示されるとおり、デバイス１０２−Ｒ１は、公開鍵Ｒ１＿ＰＫと、秘密鍵Ｒ１＿ＳＫとを有する。また、デバイス１０２−Ｒ１は、応答側の公開鍵Ｒ＿ＰＫ、および応答側の秘密鍵Ｒ＿ＳＫを知っている。同様に、デバイス１０２−Ｒ２は、公開鍵Ｒ２＿ＰＫと、秘密鍵Ｒ２＿ＳＫとを有する。また、デバイス１０２−Ｒ２は、応答側の公開鍵Ｒ＿ＰＫ、および応答側の秘密鍵Ｒ＿ＳＫを知っている。
【００６５】
分岐シナリオにおけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ２１０、２１２、２１４、および２１６は、以下を例外として、図１Ｂの一般的な関連におけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ１１０、１１２、１１４、および１１６と基本的に同一である。ステップ２１０でデバイス１０２−Ｉによって送信されるメッセージは、Ｒ＿ＰＫを使用して暗号化されるため、デバイスＲ１とＲ２はともに、このメッセージを解読することができる（デバイスＲ１とＲ２はともに、Ｒ＿ＳＫを有するので）ことに留意されたい。しかし、応答する関係者が、現在、デバイスＲ１ではなく、Ｒ２に関連しているものと想定すると、ステップ２１２における返信メッセージは、ＩＢＡＫＥによりＲ２によって計算されたランダムな鍵構成要素ｂ２Ｐ（ただし、ｂ２は、Ｒ２によって選択された乱数）を含む。また、ステップ２１２における暗号化されたメッセージは、開始側のＩＤ、応答側のＩＤ、およびデバイスＲ２のＩＤ（それぞれ、Ｉ＿ＩＤ、Ｒ＿ＩＤ、およびＲ２＿ＩＤ）を含む。
【００６６】
デバイス１０２−Ｉは、Ｒ２から受信されたメッセージを、デバイス１０２−Ｉの秘密鍵を使用して解読して、このメッセージに含まれるｂ２ＰおよびＩＤを獲得する。このため、開始側は、ステップ２１２におけるメッセージがＲ２から来たことを識別する。ＭＩＫＥＹ−ＩＢＡＫＥプロトコルにより、次に、開始側は、ステップ２１４で、ｂ２Ｐ、Ｉ＿ＩＤ、およびＲ２＿ＩＤを含むメッセージを送信する。このメッセージは、Ｒ２の公開鍵を使用して暗号化される。このメッセージは、Ｒ１がＲ＿ＳＫおよびＲ１＿ＳＫだけを有し、Ｒ２＿ＳＫは有さないので、Ｒ１によって解読され得ないことに留意されたい。ステップ２１６は、図１Ｂのステップ１１６と同様の検証メッセージである。次に、呼セッション鍵が、ａｂ２Ｐとしてデバイス１０２−Ｉおよび１０２−Ｒ２において計算されることが可能である。
【００６７】
図３は、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの、ターゲット変更フィーチャへの拡張を示す。この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。ターゲット変更またはリダイレクトは、通信システムにおける１つまたは複数の機能要素が、異なる宛先に呼をリダイレクトすることを決定するシナリオである。セッションをリダイレクトする、この決定は、いくつかの異なる機能要素によって、セッションの確立における様々な時点で、様々な理由で行われることが可能である。また、ターゲット変更は、着信転送としても知られている。
【００６８】
図３の例は、リダイレクト決定を行うアプリケーションサーバ３０２を示す。分岐シナリオにおけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ３１０、３１２、３１４、および３１６は、以下を例外として、図１Ｂの一般的な関連におけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ１１０、１１２、１１４、および１１６と基本的に同一である。
【００６９】
デバイス１０２−Ｉが、ステップ３１０で、プロトコルにおける最初のメッセージを、このメッセージがデバイス１０２−Ｒ１に向かうことを意図して、送信する（Ｒ１の公開鍵で暗号化されたメッセージ）。しかし、機能要素３０２が、３１０で、このメッセージがデバイスＲ２にリダイレクトされるべきであるという決定を行っている（ステップ３１０’参照）。このことに先立って、またはこのことに関連して、Ｒ２が、この機能要素を経由してステップ３０８で送信されたメッセージの中でＲ１の秘密鍵を受信しているものと想定される。Ｒ１からＲ２に送信されたメッセージは、Ｒ２の公開鍵を使用して暗号化されている。このため、機能要素３０２は、３０８で、このメッセージを解読することができないが、Ｒ２は、３１０’で、このメッセージを解読し、ステップ３１２で開始側に応答することができる。この時点から、ステップ３１２、３１４、および３１６は、図２の分岐シナリオにおけるステップ２１２、２１４、および２１６と同一である。
【００７０】
図４Ａは、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの遅延配信拡張を示す。この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。遅延配信は、セッション内容が、送信されている時点で宛先に配信され得ない（例えば、宛先ユーザが、現在、オンラインではない）ようになっているタイプのサービスである。それでも、送信側は、受信側が応対可能になるとすぐに、ネットワークがそのメッセージを配信するものと予期する。遅延配信の一例が、ボイスメールである。
【００７１】
図４Ａで、Ａが、デバイス１０２−Ｉであり、Ｂが、１０２−Ｒであり、デバイス４０２が、アプリケーションサーバなどの機能要素であり、さらにＭＢが、Ｂに関連するメールボックス１０２−ＭＢ（より一般的には、一時的な宛先）であるものと想定されたい。
【００７２】
ステップ４０１で、Ａが、暗号化された第１のランダムな鍵構成要素（ｘＰ）を備える第１のメッセージをＢに送信する。第１のランダムな鍵構成要素は、Ａにおいて計算されており、さらに第１のメッセージは、Ｂの公開鍵を使用して暗号化されている。ステップ４０２で、機能要素４０２が、Ｂが応対不能であると決定し、第１のメッセージをＭＢに転送する。
【００７３】
ステップ４０３で、ＭＢが、ＭＢによって計算された、暗号化された第２のランダムな鍵構成要素（ｙＰ）を備える第２のメッセージをＡに送信する。ステップ４０３のメッセージは、Ａの公開鍵を使用してＭＢにおいて暗号化されている。ステップ４０４で、機能要素４０２が、このメッセージをＡに転送する。
【００７４】
Ａが、ＭＢからの、このメッセージを、Ａによって鍵サービスから獲得された秘密鍵を使用して解読して、第２のランダムな鍵構成要素を獲得する。Ａが、ステップ４０４で受信されたメッセージがＭＢから来たことを識別する（ＭＢのＩＤが、このメッセージの中に含められていることにより）。
【００７５】
ステップ４０５で、Ａが、暗号化されたランダムな鍵構成要素ペアを含む第３のメッセージを（ステップ４０６で機能要素を介して）ＭＢに送信し、このランダムな鍵構成要素ペアは、第１のランダムな鍵構成要素（ｘＰ）と、第２のランダムな鍵構成要素（ｙＰ）とから形成され、さらにＭＢの公開鍵を使用してＡにおいて暗号化されている。また、この第３のメッセージは、Ａにおいて計算され、Ｂの公開鍵を使用してＡにおいて暗号化された、暗号化されたランダムな秘密鍵（ｓＫ）も含む。ＭＢが、ステップ４０７および４０８を介してＡに受信の確認応答を行う。ＭＢは、メッセージの後半部分を解読することができず（その部分は、Ｂの公開鍵を使用して暗号化されており、ＭＢは、Ｂの秘密鍵を有さないので）、このため、ｓＫを知ることができない。
【００７６】
ＭＢは、ＢとＭＢの間の相互認証動作の後、Ｂによって要求されると、暗号化されたランダムな秘密鍵（ｓＫ）をＢに供給する。このことが、ステップ４０９およびステップ４１０に示される。次に、この秘密鍵が、ＡによってＢのメールボックスの中に残された内容（例えば、音声メッセージ）を獲得するようにＢによって使用される。
【００７７】
図４Ｂに示される、図４Ａの遅延配信の変種において、認証された鍵合意プロトコルが実行されるのではなく、第１のメッセージの中で、Ａが、Ａにおいて計算され、さらにＢの公開鍵を使用してＡにおいて暗号化された、暗号化されたランダムな秘密鍵（ｓＫ）を送信するものと想定されたい（ステップ４１１）。機能要素４０２は、Ｂが応対不能であると決定しており、第１のメッセージをＭＢに転送し（ステップ４１２）、ＭＢが、第１のメッセージを確認する（ステップ４１３および４１４）。後に、Ｂは、前述したのと同一の仕方で、ＭＢから秘密鍵を取り出すことができる（ステップ４１５および４１６）。
【００７８】
図５は、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのさらに別の拡張を示す。この場合も、この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。図５の拡張は、マルチメディア通信システムにおいて交換されるメッセージの合法的な傍受の概念と関係する。合法的な傍受の概念は、法執行機関が、１名または複数名の関係者の通信を「盗聴する」ことができる必要がある状況に基づく。
【００７９】
１つのアプローチにおいて、法執行機関は、単に、捜査令状を介して１０２−Ｉおよび１０２−Ｒの秘密鍵を獲得し、鍵合意プロトコル中に能動的な「中間者」の役割をして、トラフィックを盗聴することができる。
【００８０】
図５に示される別のアプローチにおいて、法執行サーバ（ＬＩサーバ）５０２が、開始側のＫＭＳ（ＫＭＳＩ）および応答側のＫＭＳ（ＫＭＳＲ）と一緒に機能して、デバイス１０２−Ｉとデバイス１０２−Ｒの間で送信するメッセージを合法的に傍受する。図５は、ＬＩサーバ、ＫＭＳＩ、およびＫＭＳＲに関して別々のサーバを示すが、マルチメディア通信システムにおける１つの機能要素（例えば、傍受サーバ）が、ＫＭＳ機能および傍受機能を実行するのに使用されてもよいことを認識されたい。
【００８１】
したがって、図１Ａおよび図１Ｂの関連で前述したＭＩＫＥＹ＿ＩＢＡＫＥプロトコルが、実行される。しかし、ＬＩサーバは、応答側に送信されるメッセージに関して開始側を模倣し、開始側に送信されるメッセージに関して応答側を模倣する。
【００８２】
例えば、ＬＩサーバが応答側を模倣する場合のメッセージフローを考慮されたい。１０２−Ｉが、１０２−Ｒによる受信が意図される、暗号化された第１のランダムな鍵構成要素を含む第１のメッセージを送信するものと想定されたい。第１のメッセージが、ＬＩサーバによって傍受される。次に、ＬＩサーバが、第２のランダムな鍵構成要素を計算し、暗号化されたランダムな鍵構成要素ペアを含む第２のメッセージを１０２−Ｉに送信する。ランダムな鍵構成要素ペアは、第１のランダムな鍵構成要素と、ＬＩサーバにおいて計算された第２のランダムな鍵構成要素とから形成される。第２のメッセージは、１０２−Ｉの公開鍵を使用してＬＩサーバにおいて暗号化される。
【００８３】
第２のメッセージは、１０２−Ｉによって鍵サービスから獲得された秘密鍵を使用して解読されて、第２のランダムな鍵構成要素が獲得される。次に、デバイス１０２−Ｉが、１０２−Ｒによる受信が意図されるが、ＬＩサーバによって傍受される、第２のランダムな鍵構成要素を含む第３のメッセージを送信する。このため、ＬＩサーバは、デバイス１０２−Ｉが計算するのと同一のセキュリティで保護された鍵を計算することができる。
【００８４】
ＬＩサーバは、応答側（１０２−Ｒ）が、ＬＩサーバを相手に、開始側によって合意されていると応答側が信じるセキュリティで保護された鍵（しかし、実際には、ＬＩサーバを相手に合意されている）を確立するように、認証された鍵合意動作中にメッセージを送受信する際に、やはり開始側（１０２−Ｉ）を模倣することを理解されたい。
【００８５】
前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルフィーチャの１つまたは複数は、会議システムシナリオに拡張され得ることを認識されたい。そのような拡張が、図６Ａから図６Ｃに示される。
【００８６】
一般的な想定は、複数関係者の通信を中継する会議サーバ（より一般的には、会議管理要素）（例えば、会議ブリッジ）が、グループ鍵を知らない一方で、すべてのユーザは、同一のグループ鍵にアクセスを有することである。この想定には例外、すなわち、ピアツーピア会議において、会議ブリッジの役割をしているコンピューティングデバイスが、会議に実質的に参加している関係者でもある場合が存在する。
【００８７】
図６Ａに示されるとおり、複数関係者会議６００が、会議サーバと、ユーザ（関係者）１からＮとを含むものと想定され、ただし、このユーザ番号は、ユーザが会議に参加することを求める順序で、すなわち、１、２、３、．．．Ｎの順番に割り当てられる。
【００８８】
ステップ６０２で、各ユーザが個々に、会議サーバを相手にＩＢＡＫＥプロトコルを実行する。Ｚｉ＝ａｉＰを、会議サーバを相手にした認証中にユーザ「Ｉ」によってサーバに送信される値とする。ａｉＰは、ＩＢＡＫＥにより関係者によって計算されたランダムな鍵構成要素であることを思い起こされたい。
【００８９】
認証の成功の後、ステップ６０４で、会議サーバが、集合｛ａｉＰ｝をすべてのユーザに送信する（ブロードキャスト、または個別のユニキャスト）。このため、集合｛ａｉＰ｝は、それらの関係者のそれぞれによって計算されたランダムな鍵構成要素を含む集合である。
【００９０】
ステップ６０６で、すべてのユーザが個々に、会議サーバにＸｉ＝ａｉ｛ａｉ＋１Ｐ−ａｉ−１Ｐ｝を送り返す。ａｉ｛ａｉ＋１Ｐ−ａｉ−１Ｐ｝は、ランダムなグループ鍵構成要素であり、このランダムなグループ鍵構成要素は、鍵認証動作中に関係者によって使用される乱数、および会議に参加することを求めている２名以上の関係者の他のサブセットによって計算されたランダムな鍵構成要素に基づく計算を介して、各関係者によって計算される。この実施形態において、所与の関係者に関するランダムなグループ鍵構成要素ａｉ｛ａｉ＋１Ｐ−ａｉ−１Ｐ｝は、ａｉが、所与の関係者によって選択された乱数であり、ａｉ＋１Ｐが、会議順序付けにおいてその所与の関係者の直後に続く関係者によってサーバに送信されたランダムな鍵構成要素であり、ａｉ−１Ｐが、会議順序付けにおけるその所与の関係者の直前の関係者によってサーバに送信されたランダムな鍵構成要素であり、さらにＰが、ＩＤ暗号化ベースの鍵認証動作に関連するグループから選択された点（例えば、前述した楕円曲線から選択された点）であるように計算される。
【００９１】
ステップ６０８で、会議サーバが、次に、集合｛Ｘｉ｝を全員と共有する（ブロードキャスト、または個別のユニキャスト）。つまり、集合｛Ｘｉ｝は、それらの関係者によって計算されたランダムなグループ鍵構成要素を含む集合である。
【００９２】
ステップ６１０で、各関係者は、会議サーバを介して関係者が互いに通信する際に使用するための同一のグループ鍵を計算することができる。このグループ鍵は、以下のとおり計算される。Ｎａｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋．．．Ｘｉ−２、ただし、Ｎは、会議に参加することを求める関係者の総数を表し、ａｉは、所与の関係者によって選択された乱数を表し、Ｚｉは、所与の関係者によって計算されるランダムな鍵構成要素を表し、Ｘｉは、所与の関係者によって計算されるランダムなグループ鍵構成要素を表し、さらにｉは、Ｎ名の関係者の会議における所与の関係者に関する会議順序付けの番号であり、ｉ＝１の場合、ｉ−１＝Ｎであり、ｉ＝Ｎである場合、ｉ＋１＝１である。
【００９３】
前述したとおり、会議サーバは、会議における参加する関係者ではなく、そのため、グループ鍵を計算することができない。しかし、ピアツーピアシナリオにおいて、会議サーバは、会議呼における参加する関係者であり、そのため、グループ鍵を計算することができる必要がある。
【００９４】
会議サーバは、会議に参加することを求める各関係者を相手に相互認証動作を実行するものと理解される。また、会議サーバは、以下の少なくとも２つの条件：（ｉ）所与の関係者が、会議管理要素によって認証される、および（ｉｉ）所与の関係者が、会議許可リストに属することが確認されるという条件が満たされた場合に限って、所与の関係者を会議に受け入れる。また、前述のＭＩＫＥＹ−ＩＢＡＫＥプロトコルによれば、会議に参加することを求める関係者、および会議サーバは、１つまたは複数のＫＭＳ（鍵管理サービス）からそれぞれの秘密鍵を獲得する。
【００９５】
図６Ｂは、新たな会議参加者（ユーザＮ＋１）がどのように、進行中の会議に追加されて、変更された会議６００’をもたらすかを示す。
【００９６】
ステップ６１２で、ユーザＮ＋１が、会議サーバを相手にＩＢＡＫＥを実行する。ＺＮ＋１＝ａＮ＋１Ｐを、サーバを相手にした認証中にユーザ「Ｎ＋１」によってサーバに送信される値とする。ユーザＮ＋１の認証成功の後、ステップ６１４で、会議サーバが、新たなユーザＮ＋１の受入れを告知し、ＺＮ＋１を含む集合｛ａｉＰ｝を、全員に送信する（ブロードキャスト、または個別のユニキャスト）。
【００９７】
ステップ６１６で、ユーザ１、Ｎ、Ｎ＋１が、サーバにＸｉ＝ａｉ（ａＮ＋１Ｐ−ａＮ−１Ｐ｝を送り返し、代替として、ユーザのすべてが、このステップを実行することも可能である。次に、ステップ６１８で、会議サーバが、ＸＮ＋１を含む集合｛Ｘｉ｝を、全員と共有する（ブロードキャスト、または個別のユニキャスト）。次に、ステップ６２０で、グループ鍵（Ｎ＋１）ａｉ（Ｚｉ−１）＋（Ｎ）Ｘｉ＋（Ｎ−１）Ｘｉ＋１＋．．．Ｘｉ−２が再計算される。グループ鍵は、その新たなユーザが受け入れられた後に変化することに注目されたい。
【００９８】
図６Ｃは、会議参加者がどのように、進行中の会議を抜けて、変更された会議６００”をもたらすかを示す。
【００９９】
ユーザ３が、その呼を抜けるものと想定されたい（ユーザ３の選択は、単に例に過ぎないことを理解されたい）。ステップ６２２で、会議サーバが、いずれのユーザが呼を抜けたかを告知する（ブロードキャスト、または個別のユニキャスト）。ステップ６２４で、ユーザ順序付けが変化する。ユーザ１および２は、そのままである。ユーザｉは、４以上のすべてのｉに関して、ユーザｉ−１になる。ステップ６２６で、ユーザ４（現時点で、ユーザ３である）が、Ｘｉを再計算し、この寄与を会議サーバと共有する。ステップ６２８で、会議が、集合｛Ｘｉ｝をすべての参加者と共有する。ステップ６３０で、それらの参加者が、グループ鍵（Ｎ−１）ａｉ（Ｚｉ−１）＋（Ｎ−２）Ｘｉ＋（Ｎ−３）Ｘｉ＋１＋．．．Ｘｉ−２を再計算する。この場合も、グループ鍵は、参加者が呼を抜けた後に変化することに注目されたい。
【０１００】
本発明の原理は、前述した会議管理技術の拡張も提供する。この拡張には、会議メッセージの合法的な傍受がかかわる。
【０１０１】
会議システムにＮ名の参加者が存在するものと想定されたい。参加者Ｎが、「嫌疑がかけられ」ており、法執行機間が、参加者Ｎへの呼、および参加者Ｎからの呼を盗聴する令状を獲得している。参加者Ｎを嫌疑がかけられていると宣言することの選択は、例示に過ぎず、説明を追うことをより容易にし、このソリューションは、第Ｎ番のユーザを嫌疑がかけられたユーザと宣言することに全く限定するものではない。
【０１０２】
会議呼に先立って、ＬＩサーバ（図５で思い起こされたい）が、参加者Ｎに対応するＫＭＳにアプローチし、参加者Ｎの秘密鍵を獲得する。このことは、ＬＩサーバが、グループ鍵交換プロセス中に参加者Ｎのふりをして、図６Ａのすべてのステップを実行するが、ただし、参加者Ｎの寄与は、ＬＩサーバからの寄与で置き換えられていることを可能とする。詳細には、ＬＩサーバは、ＺＮおよびＸＮの代わりにＺＬＩおよびＸＬＩを代用する。残りの参加者は、この違いを知らず、グループ鍵を計算して、その鍵をＧＫ’と呼ぶ。
【０１０３】
次に、ＬＩサーバが、会議サーバと協働し、参加者Ｎとのすべての通信においてＺ１およびＸ１をＺＬＩおよびＸＬＩで置き換える。このことは、参加者Ｎが、ＧＫ’とは異なるグループ鍵を計算することを暗示する。この新たな鍵をＧＫ”と呼ぶ。
【０１０４】
前述のステップで、ＬＩサーバは、任意の参加者に関してＺｉおよびＸｉをＺＬＩおよびＸＬＩで置き換えることが可能であったこと、およびｉ＝１の選択は例示に過ぎないことに留意されたい。
【０１０５】
呼がセットアップされた後、参加者１ないしＮ−１からのいずれの通信も、ＧＫ’を使用して暗号化される。ＬＩサーバは、ＧＫ’を知っているので、ＬＩサーバは、次に、その通信を傍受し、その通信を解読し、その後、その通信を、ＧＫ”を使用して再暗号化して、参加者Ｎに送信することができる。逆に、ＬＩサーバによって傍受される、参加者Ｎからのいずれの通信も、ＧＫ”を使用して暗号化され、その後、ＧＫ”を使用して解読され、ＧＫ’を使用して再暗号化され、さらに参加者１ないしＮ−１に送信する。
【０１０６】
ＩＩＩ．ＩＭＳ実施形態
以下の段落において、ＭＩＫＥＹ＿ＩＢＡＫＥの前述した一般的な原理、およびそれらの原理の拡張が、ＩＭＳ（ＩＰマルチメディアサブシステム）環境に適用される。つまり、この段落におけるマルチメディア通信システムは、ＩＭＳネットワークであると考えられる。ＩＭＳ標準は、参照により開示が本明細書に組み込まれている、３ＧＰＰ技術仕様、ＴＳ２３．２１８、ＴＳ２３．２２８、ＴＳ２４．２２８、ＴＳ２４．２２９、およびＴＳ２４．９３０において説明されている。
【０１０７】
ＩＭＳメディアプレーンセキュリティに関する、特に、鍵管理に関するアーキテクチャの枠組みをまず説明することとし、この枠組みに基づいて、様々なフィーチャおよび使用事例が導き出されることが可能である。
【０１０８】
このソリューションの中核にあるのは、参照により開示が本明細書に組み込まれている、ＲＦＣ５０９１、ＲＦＣ５４０８、およびＲＦＣ５４０９と同様の、ＩＢＥ（ＩＤベースの暗号化）概念である。
【０１０９】
しかし、これらのＲＦＣは、認証を提供せず、特有の鍵供託問題に悩まされている。我々は、相互認証を提供し、受動的な鍵供託を解消し、鍵の完全な秘密をもたらす（ＩＤベースの認証された鍵交換（ＩＢＡＫＥ）プロトコルを含むように基本的なＩＢＥを拡張することによって、これらの問題に対処する。ＩＢＡＫＥが基本的なプロトコル構造であるが、我々は、鍵配信のためのプロトコルコンテナとしてＭＩＫＥＹを使用する。
【０１１０】
本発明のＩＭＳソリューションの枠組みについての１つの基本的な考え方は、我々は、ＫＭＳを含む、提案されるアーキテクチャを再使用するが、とりわけ、我々は、これらのＫＭＳサーバが常にオンラインであることを必要としないことである。つまり、提案される枠組みにおいて、ＫＭＳは、定期的に（例えば、１カ月に１回）エンドユーザクライアントと通信して、セキュリティで保護されたＩＤベースの暗号化の枠組みを作成するオフラインサーバである一方で、エンドユーザクライアント間のオンライントランザクションは（メディアプレーンセキュリティのために）、参加するクライアントが、非対称ＩＤベースの暗号化の枠組みにおいて鍵構成要素を交換することを可能とするＩＢＡＫＥの枠組みに基づく。この枠組みは、受動的な供託を解消することに加えて、エンドユーザクライアントが、（ＩＭＳメディアプレーン層において）互いを相互に認証することを可能とし、完全な順方向の秘密および逆方向の秘密をもたらす。
【０１１１】
ＫＭＳ−クライアント間の交換は、控えめに（例えば、１カ月に１回）使用され、このため、ＫＭＳはもはや、高度に応対可能であるサーバであることを要求されず、特に、異なるＫＭＳが（事業者境界をまたいで）互いに通信しなくてもよい。さらに、非対称ＩＤベースの暗号化の枠組みが使用されることから、高価な公開鍵インフラストラクチャ（ＰＫＩ）、ならびに証明書管理および取消しのすべての運用上の費用が解消される。さらに、様々なＩＭＳメディアプレーンフィーチャが、セキュリティで保護されてサポートされ、このことには、セキュリティで保護された分岐、ターゲット変更、遅延配信、事前符号化された内容、メディアクリッピング、および匿名性が含まれる。
【０１１２】
このソリューションの拡張は、ＩＭＳ会議アプリケーションサーバがユーザを認証して、呼に受け入れるが、その呼のすべての参加者が、グループ鍵を決定する（全員からの寄与を使用して）一方で、会議サーバ自体は、そのグループ鍵を知ることがない、セキュリティで保護された会議アプリケーションを可能にする。さらに、そのグループ鍵は、新たな参加者、および呼を抜ける参加者を考慮に入れるように変更され得る。ＩＭＳベースの鍵管理の枠組みのさらなるフィーチャは、受動的な鍵供託の解消にもかかわらず、この枠組みが、能動的な供託の概念を使用して、法執行とセキュリティ資格証明を合法的に共有することをサポートする。
【０１１３】
図７は、このアーキテクチャの概略を、ＩＭＳメディアプレーンにおける例示的な終端間鍵交換プロトコルに関与するエンティティと一緒に提示する。ＩＭＳアーキテクチャは、よく知られているので、図７に示される機能上の構成要素は、詳細には説明されないものと理解される。それらの構成要素の機能の詳細な説明については、ＩＭＳ標準を参照することが可能である。知られているとおり、ＣＳＣＦとは、呼セッション制御機能であり、ただし、Ｐ−ＣＳＣＦは、プロキシＣＳＣＦであり、Ｓ−ＣＳＣＦは、サービングＣＳＣＦであることに留意されたい。ＮＡＦとは、ネットワークアプリケーション機能を指す。
【０１１４】
例示されるシナリオにおいて、２つのＩＭＳ対応のエンドユーザ電話機が、アプリケーション層において通信をセキュリティで保護するようにｅ２ｅ（終端間）鍵交換を行っている。この例示は、ＵＥ（ユーザ機器）とＫＭＳの間のオフライントランザクション、ならびにＩＭＳを介するＵＥ間のオンライントランザクションを含むことに留意されたい。
【０１１５】
ＵＥとＫＭＳは、ユーザが、鍵管理サーバを相手にセキュリティで保護された接続を確立することができ、さらに相互認証が提供される、事前構成されたセキュリティ関連付けを共有することに注目されたい。３ＧＰＰシステムにおける１つの自然な例が、汎用化されたブートストラップアーキテクチャの使用である（例えば、参照により開示が本明細書に組み込まれている、３ＧＰＰ ＴＳ３３．２２０を参照）。図７で、ＫＭＳとＵＥの間のトランザクションは、ＢＳＦ（ブートストラップサーバ機能）を介して可能にされ、さらに、このトランザクションは、控えめに（例えば、１カ月に１回）実行されることを思い起こされたい。ＧＢＡが応対不能である場合、事前共有される鍵または証明書を有するＩＫＥｖ２（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ４３０６を参照）などの他のタイプの資格証明が、ユーザとＫＭＳの間で、この相互認証を確立するために使用されることが可能であることに留意されたい。
【０１１６】
このトランザクション中、ＵＥは、ＵＥの契約資格証明を提示し、この後に、ＫＭＳが、秘密鍵のセットを生成する（ＩＢＡＫＥにおいて使用される）。このトランザクションは、１カ月に１回、実行され、次に、ＫＭＳが、１日毎に１つの鍵を生成することを選択することが可能である。鍵の数、およびこの交換の頻度は、ポリシーの問題であり、契約に結び付けられることが可能である。この柔軟性は、前払いの顧客に関して特に有用である。
【０１１７】
単一のＫＭＳではなく、ユーザＡに関して１つ、すなわち、ＫＭＳ＿Ａ、およびユーザＢに関して１つ、すなわち、ＫＭＳ＿Ｂという異なる２つのＫＭＳが関与することも可能である。しかし、ＫＭＳ＿ＡとＫＭＳ＿Ｂは、互いに通信しなくてもよい。このシナリオは、事業者間のシナリオにおいて特に適用可能である。
【０１１８】
次に、ＩＭＳのコンテキストにおいてＭＩＫＥＹ−ＩＢＡＫＥにかかわる交換の簡単な要約を与える。
【０１１９】
Ａ、Ｂが、鍵を認証し、鍵について合意しようと試みている２名のユーザであるものと想定されたい。同時に、ＡおよびＢは、Ａに対応するＩＤ、およびＢに対応するＩＤも表し、これらのＩＤは、定義により、Ａの公開鍵、およびＢの公開鍵も表す。Ｈ１（Ａ）＝ＱＡおよびＨ１（Ｂ）＝ＱＢを、それらの公開鍵に対応する楕円曲線上のそれぞれの点であるものとする。実際、それらのＩＤと、Ｈ１を適用することによって獲得される曲線上の点との間に１対１対応が存在するので、ＱＡおよびＱＢを公開鍵と呼ぶことも可能である。ｘを、Ａによって選択された乱数とし、ｙを、Ｂによって選択された乱数とする。以降、暗号化とは、段落Ｉで前述したとおり、ＩＤベースの暗号化を指す。
【０１２０】
ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥプロトコル交換は、以下のステップを含む（図７に示される構成要素に関連する）：
１．ユーザＡに属するＩＭＳ ＵＥが、ＮＡＦの役割をするＫＭＳを相手にセキュリティで保護された接続を確立することができるようにＢＳＦを使用してブートストラップを行う。このことは、ＢＳＦがユーザを認証することを可能とし、さらにユーザがＫＭＳを間接的に認証することを可能とする。ＧＢＡが使用され得ない場合、ＩＭＳ ＵＥは、ＫＭＳに接続して、認証を行い、さらに事前確立されたセキュリティ関連付けに基づいて、共有される鍵を確立する。
【０１２１】
２．ＩＭＳ ＵＥが、ＫＭＳを相手にＭＩＫＥＹ交換に従事し、秘密鍵（または、例えば、１日につき１つの、複数の秘密鍵）を要求する。
【０１２２】
３．ＫＭＳが、ユーザＡのＩＭＳ ＵＥに関するメディア秘密鍵を生成し、このメディア秘密鍵をユーザＡに送信する。
【０１２３】
４．ユーザＡのＩＭＳ ＵＥが、ｘＰ（すなわち、Ｅ上で加算則を使用して、Ｅ上の点としてｘ回、自らに加算されたＰ）を計算し、Ｂの公開鍵を使用してｘＰを暗号化し、暗号化されたｘＰをユーザＢのＩＭＳ ＵＥに送信する。
【０１２４】
５．ＩＭＳコアが、ＩＮＶＩＴＥを検出し、ネットワーク機能が、許可される場合、セッション鍵にアクセスを得ることができるようにＩＮＶＩＴＥを扱う。このステップは、合法的な傍受要件を満たすのに必要とされる能動的な供託フィーチャをサポートするようにだけ適用可能である。
【０１２５】
６．ユーザＢのＩＭＳ ＵＥが、暗号化されたｘＰを含むＩＮＶＩＴＥを受信する。ユーザＢのＩＭＳ ＵＥが、そのメッセージを解読し、ｘＰを獲得する。その後、Ｂが、ｙＰを計算し、ユーザＡのＩＭＳ ＵＥの公開鍵を使用してペア｛ｘＰ，ｙＰ｝を暗号化し、次に、暗号化されたペア｛ｘＰ，ｙＰ｝を応答メッセージの中でＡに送信する。
【０１２６】
７．このメッセージを受信すると、ユーザＡのＩＭＳ ＵＥが、このメッセージを解読し、ｙＰを獲得する。その後、ユーザＡのＩＭＳ ＵＥが、Ｂの公開鍵を使用してｙＰを暗号化し、暗号化されたｙＰを、応答確認メッセージの中でＢに送り返す。以上の後に、ＡとＢがともに、セッション鍵としてｘｙＰを計算する。
【０１２７】
８．この時点で、ユーザＢのＩＭＳ ＵＥが、メディアセキュリティの招待および使用を受け入れる。
【０１２８】
Ａは、ｘをランダムに選択しており、プロトコル交換の第２のステップでｙＰを受信していることに注目されたい。このことは、Ａが、ｙＰ自らをｘ回、加算することによってｘｙＰを計算することを可能とする。逆に、Ｂは、ｙをランダムに選択しており、プロトコル交換の第１のステップでｘＰを受信している。このことは、Ｂが、ｘＰ自らをｙ回、加算することによってｘｙＰを計算することを可能とする。
【０１２９】
ＭＩＫＥＹ−ＩＢＡＫＥプロトコルから生じるいくつかの有利な特性は、以下のとおりである。
【０１３０】
相互認証。ステップ４および７のペイロードの内容は、Ｂの公開鍵を使用して暗号化されていることに注目されたい。このため、Ｂだけが、これらのメッセージを解読することができる。同様に、ステップ６のメッセージの内容は、Ａによってしか解読され得ない。また、ステップ６および７は、ＢとＡが互いを認証する（メッセージが正しく解読されたことを証明することによって）ことを可能とすることにも注目されたい。この新奇な特徴は、ＡおよびＢが、オンラインサーバまたは証明機関の助けを借りることなしに、互いを相互に認証することを可能にする。
【０１３１】
完全な秘密。ｘおよびｙは、ランダムであることに注目されたい。このため、セッション鍵ｘｙＰは、新規であり、過去または将来のトランザクションと全く関係を有さない。
【０１３２】
受動的な供託の解消。ＫＭＳ（またはＫＭＳのペア）は、交換におけるメッセージを解読することができるが、ｘＰおよびｙＰを所与として、ｘｙＰを算出するのは困難であることに注目されたい。困難さの想定は、楕円曲線上のディフィ−ヘルマン問題に依拠する。また、ＩＢＥのために使用される曲線は、ＫＭＳ特有であり、さらに、セッション鍵を生成するのに使用される曲線と同一でなくてもよいことに留意されたい。この柔軟性は、多数の選択肢を提供し、さらにＫＭＳの間で必要とされる調整も解消する。
【０１３３】
ＩＤ管理。前述したとおり、メッセージを暗号化するのに、送信者は、受信者のＩＤ（または複数のＩＤのうち１つ）を使用して生成された、受信者の公開鍵を使用する。受信者のＩＤは、特定のユーザ、グループのユーザ、または任意のユーザを特定するフォーマットになっていることが可能である。ユーザおよびユーザグループの命名は、通常のＩＭＳ慣行に従うことが可能であり、ワイルドカードを使用して拡張されることが可能である。グループアプリケーションがかかわるいくつかのシナリオにおいて、グループ内のすべての受信者が、その特定のユーザグループのＩＤに対応する秘密鍵を使用することを可能とするポリシーを有することが自然であり得る。例えば、企業ユーザに関して、デフォルトとして、企業のＩＤに対応する秘密鍵がすべての企業ユーザに配信されることが自然であり得る。ＩＤベースの暗号化のこれらの特性のため、或るグループに属するすべてのユーザが、場合により、そのグループの秘密鍵を有するものの、それでも、すべてのユーザは、送信者と、その同一のグループに属する他の何らかのユーザの間で確立されたセッション鍵を獲得することができないことに留意されたい。また、ポリシーが執行されることを確実にするのに、公開ユーザＩＤが、ＩＭＳ ＵＥにセキュリティで保護されて結び付けられることが可能であることも必要である。つまり、ＫＭＳに対して認証するのにユーザによって使用されるＩＤが、公開ＩＤ（のセット）であることが重要である。
【０１３４】
次に、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの、様々なＩＭＳベースの使用事例シナリオへの拡張を説明する。これらの拡張は、概ね、段落ＩＩで説明されていることに留意されたい。以下の説明は、ＩＭＳ環境の関連において行われる。
【０１３５】
Ａ．能動的な供託を介する合法的な傍受（ＬＩ）
傍受された通信の明瞭なコピーを供給することができるのに、以下の条件が満たされなければならない：
１．トラフィック（シグナリングとメディアの両方）を傍受することが可能でなければならない。
２．実際のトラフィック保護のために使用されるセッション鍵が、利用可能でなければならない。セッション鍵を利用可能にするのに、ＫＭＳ機能／サービスが要求される。
【０１３６】
前述したとおり、トラフィック保護のためにしようされる実際のセッション鍵は、送信者と受信者の間で生成され、このため、ＫＭＳによって知られていない。したがって、能動的な供託ソリューションが必要とされる。このシナリオにおいて、ＫＭＳが、ユーザＡとユーザＢの間のセッション鍵を獲得するのに、ＫＭＳは、ＫＭＳとユーザＡの間でアクティブセッション鍵を確立する必要があり、さらにＫＭＳとユーザＢの間で別の同時の、アクティブセッションを確立する必要がある。ＫＭＳは、Ａに向けてＢのふりをし、Ｂに向けてＡのふりをする。ＫＭＳによって果たされる、この「中間者」の役割は、能動的な供託と呼ばれ、証明機関が「偽の証明書」を生成し、交換の中間に座るＰＫＩ環境において使用される方法に類似する。従来のＣＡにおいて使用される技術と、能動的な供託の我々のアプローチの違いは、ＫＭＳが、偽の鍵を生成しなくてもよいことである。
【０１３７】
シグナリングトラフィックは、ホームネットワーク経由でルーティングされており、ホームネットワークにおけるシグナリングトラフィックの傍受は、ＳＩＰ（セッション開始プロトコル）サーバにおいて行われることが可能である。次に、このシグナリングトラフィックが、適切なＫＭＳに向けて、このＫＭＳが、対応するユーザを相手に必要とされるセッション鍵を確立するようにルーティングされる必要がある。ローミング状況において、ＳＩＰシグナリングトラフィックは、通常、ＩＭＳ ＵＥとＰ−ＣＳＣＦの間で機密性が保護されているので、さらに現行の展開において、Ｐ−ＣＳＣＦがホームネットワーク内に配置されることを考慮すると、ＳＩＰシグナリングは、移動先ネットワークにおけるベアラレベルで、暗号化されたフォーマットでしか利用可能でない。
【０１３８】
ローミングシナリオの場合、暗号化されたＳＩＰシグナリングおよび内容は、常に利用可能であるが、ＳＩＰシグナリングを傍受し、通信の内容を解読するために、移動先ネットワークと、ＫＭＳを扱うエンティティとの間で相互運用性合意が存在しなければならない。通常、ＫＭＳは、ホームネットワーク内に存在し、したがって、移動先ネットワークによって実行されるＬＩのために、ホームネットワークとの協力が必要とされる。
【０１３９】
ＬＩ標準に沿って、ＶＰＬＭＮ（移動先公衆陸上モバイルネットワーク）が暗号化に関与していない場合、暗号化された内容だけしか、ＶＰＬＭＮにおけるＬＩのために利用可能でない。
【０１４０】
Ｂ．異なるＫＭＳドメインにおけるユーザ
異なるＫＭＳドメインにおけるユーザは、異なるＫＭＳによって生成されたユーザの秘密鍵を有する。その結果、異なるセットの公開パラメータ（例えば、暗号法上の材料）が、異なるＫＭＳドメインにおけるユーザに関する公開鍵および秘密鍵を生成するのに使用され得る。適切な暗号化／解読を確実にするのに、送信者と受信者は、それぞれの側によって使用される正確な公開パラメータを知る必要がある。それでも、１つのＫＭＳドメインにおけるユーザが、別のＫＭＳドメインにおけるユーザに対してセキュリティで保護された呼を確立する必要がある場合、関与するＫＭＳは、協力しなくてもよい。いずれのＩＤベースの暗号プロトコルの場合とも同様に、さらに言えば、いずれの公開鍵プロトコルの場合とも同様に、我々は、交換のために必要とされる公開パラメータが、公開で利用可能である、または交換されるものと想定して支障ない。
【０１４１】
Ｃ．終端−中間間シナリオ
終端−中間間シナリオにおいて、メディア保護は、ＩＭＳ ＵＥとネットワークエンティティの間で行われる。ＩＭＳ ＵＥから呼が開始されるシナリオにおいて、呼のセットアップは、終端間保護された呼の場合と同一の原理に従う。開始するＩＭＳ ＵＥは、ネットワークエンティティ（例えば、ＭＧＷＣ、つまり、メディアゲートウェイコントロール）のＩＤを使用して、前述したとおりｘＰを暗号化し、暗号化されたｘＰをＩＮＶＩＴＥと一緒に送信する。ＭＧＷＣが、メッセージを傍受し、受信するＩＭＳ ＵＥが行うのと同じ仕方でｙＰを生成する。次に、ＭＧＷＣは、ＩＭＳ ＵＥに向けてメディアセキュリティを有するようにＭＧＷをセットアップする。メディアトラフィックは、ＰＳＴＮ（公衆交換電話網）において平文で転送される。
【０１４２】
ＩＭＳ ＵＥに対する着信する呼の場合、ＭＧＷＣは、意図される受信者のために登録された少なくとも１つの端末装置が、メディアセキュリティ能力および選好を登録していることを確認する。メディア保護対応の端末装置が存在しない場合、その呼は、平文で転送される。存在する場合、ＭＧＷＣは、ｙを選択し、ｙＰを生成する。次に、ＭＧＷＣは、（ＩＭＳ ＵＥのＩＤを使用して）暗号化されたｙＰをＩＮＶＩＴＥの中に挿入し、ＭＧＷにおけるメディアセキュリティの使用を、ＭＧＷとＩＭＳ端末装置の間のメディアトラフィック上で開始する。
【０１４３】
Ｄ．鍵分岐
この段落では、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関して分岐が説明される。分岐は、概ね、図２の関連において前段で説明されていることを思い起こされたい。分岐は、複数のロケーションへの要求（例えば、ＩＮＶＩＴＥメッセージ）の配信である。このことは、単一のＩＭＳユーザが複数回、登録されている場合に生じる。分岐の例が、ユーザが、ディスク電話機、ＰＣクライアント、およびモバイルハンドセットをすべて、同一の公開ＩＤで登録している場合である。
【０１４４】
後段で説明され、図８のステップ１から８の関連において示される例において、ユーザＢのＩＭＳ ＵＥが、単一の公開ユーザＩＤ Ｂで複数の連絡先アドレスを登録しているものと想定されたい。つまり、Ｂ１とＢ２がともに、公開ＩＤ Ｂに対応する秘密鍵を獲得する。この事例において、ユーザＡのＩＭＳ ＵＥが、ユーザＢのＩＭＳ ＵＥと連絡をとることを所望する場合、要求は、Ｂ１とＢ２の両方に配信される。Ｂ２が呼に応答するものと想定すると、Ｂ２はまず、ＩＤ Ｂに関連する秘密鍵を使用して受信されたメッセージを解読する。次に、Ｂ２は、ｙをランダムに選択し、Ａの公開ＩＤを使用して暗号化された、ｙＰと、Ｂ２のＩＤ Ｂ２とを含むメッセージをＡに送信する。このメッセージを受信すると、ユーザＡは、このメッセージを解読し、ユーザＢ２を相手に通信していることを認識し、さらにＢ２の公開ＩＤを使用して暗号化された、受信されたｙＰを含む応答確認メッセージを送信する。
【０１４５】
Ｂ１は、Ｂの公開ＩＤを使用して暗号化された、ユーザＡから受信されたメッセージを解読することができ、したがって、ｘＰを獲得することができることに注目されたい。しかし、Ｂ１は、Ｂ２から送信されたメッセージを解読することは、そのメッセージが、ＡのＩＤを使用して暗号化されているので、できない。このため、ユーザＢ１は、ｙＰを獲得することができない。また、Ｂ１がｙＰを獲得することができる場合でさえ、Ｂ１は、それでも、ｘｙＰを計算することができないことにも留意されたい。図７で、（Ｍ）＿Ｘは、メッセージＭが、ＸのＩＤを使用して暗号化されていることを表すことに留意されたい。
【０１４６】
Ｅ．リダイレクト
この段落では、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関してセッションリダイレクト（ターゲット変更）が説明される。リダイレクトは、概ね、図３の関連において前段で説明されていることを思い起こされたい。セッションリダイレクトは、機能要素が、呼を異なる宛先にリダイレクトすることを決定するシナリオである。セッションリダイレクトは、「無条件セッション転送」、「話中セッション転送」、「可変セッション転送」、「選択的セッション転送」、および「応答なしセッション転送」という通常のサービスを可能にする。
【０１４７】
セッションリダイレクトの２つの基本的なシナリオが存在する。シナリオ１では、基本要素（例えば、Ｓ−ＣＳＣＦ）が、ＳＩＰ ＲＥＤＩＲＥＣＴ方法を使用してセッションをリダイレクトすることを決定する。つまり、機能要素は、新たな宛先情報を発信元に送信する。その結果、発信元は、機能要素によって与えられた、リダイレクトされる宛先に対して新たなセッションを開始する。ＭＩＫＥＹ−ＩＢＡＫＥの事例の場合、このことは、発信元が、リダイレクトされる宛先のＩＤを使用して新たなセッションを開始することを意味する。
【０１４８】
第２のシナリオでは、機能要素は、発信元に知らせることなしに、セッションをリダイレクトすることを決定する。一般的なシナリオは、宛先ユーザのＳ−ＣＳＣＦが、セッションがリダイレクトされるべきことを決定するシナリオである。登録中に「Ｃｘプル」によってＨＳＳ（ホーム契約者サーバ）から獲得されるユーザプロファイル情報は、セッションリダイレクトをもたらす複雑なロジックおよびトリガを含むことが可能である。
【０１４９】
図９のステップ１から８に示される例において、一般性を失うことなしに、ユーザＢは、ユーザＣに対するセッション転送をセットアップするものと想定される。この事例において、ユーザＢは、ユーザＢのユーザプロファイルの中に、ＣのＩＤを使用して暗号化されたユーザＢの秘密鍵ＳＫ＿Ｂを含める。したがって、Ｓ−ＣＳＣＦが、ユーザＡからメッセージを受信し、そのメッセージがリダイレクトされる必要があると決定すると、Ｓ−ＣＳＣＦは、ユーザＣにリダイレクトされるメッセージの中にＢの暗号化された鍵を含める。このメッセージを受信すると、ユーザＣは、その秘密鍵を暗号化し、次に、Ａからのメッセージを暗号化する。次に、ユーザＣは、ランダムなｙを選択し、Ａの公開ＩＤを使用して暗号化された、ｙＰと、ＣのＩＤ Ｃとを含むメッセージをＡに送信する。このメッセージを受信すると、ユーザＡは、このメッセージを解読し、ユーザＣを相手に通信していることを認識し、さらにＣの公開ＩＤを使用して暗号化された、受信されたｙＰを含む応答確認メッセージを送信する。図９で、（Ｍ）＿Ｘは、メッセージＭが、ＸのＩＤを使用して暗号化されていることを表す。
【０１５０】
Ｆ．遅延配信
この段落では、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関して遅延配信が説明される。段落ＩＩから、遅延配信は、セッション内容が、送信された時点で宛先に配信され得ない（例えば、宛先ユーザが、現在、オンラインでない、またはその呼に応答しないことを決定する）ようなタイプのサービスであることを思い起こされたい。それでも、送信者は、受信者が応対可能になるとすぐに、ネットワークがそのメッセージを配信するものと予期する。遅延配信の典型的な例が、ボイスメールである。
【０１５１】
以下に、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関する遅延配信の２つの基本的なシナリオが提示される。第１のシナリオに関して図４Ａが参照されることが可能であり、第２のシナリオに関して図４Ｂが参照されることが可能である。
【０１５２】
第１のシナリオでは、ユーザＡのメールボックスとＢのメールボックスが、遅延配信が意図されるメッセージの内容を解読するために使用されるべき鍵について合意するのに先立って、相互認証を実行するのに対して、第２のシナリオでは、相互認証は、実行されない。
【０１５３】
第１のシナリオ（やはり、機能要素４０２がＩＭＳサーバである図４Ａを再び参照することが可能である）では、ユーザＡが、現在、応対可能でないユーザＢと連絡をとろうと試みており、したがって、その呼は、Ｂの「ボイスメール」（より一般的には、遅延配信サーバ）に転送されるものと想定される。ＭＩＫＥＹ−ＩＢＡＫＥプロトコルに従って、Ｂのメールボックスによって受信されたメッセージは、ＢのＩＤを使用して暗号化されており、したがって、Ｂのメールボックスは、そのメッセージを解読することができない。Ｂのメールボックスは、ランダムなｙを選択し、ｙＰを計算し、さらに、ＩＢＥ暗号化された、ＢのメールボックスのＩＤおよびｙＰをユーザＡに送信する。ユーザＡは、Ｂがそのメッセージを受信しなかったこと、および実際の受信者が、その受信者のＩＤ、およびｘＰを欠いているために、第１のステップで送信されたメッセージを解読することができなかったことを認識する。したがって、ユーザは、ＢのメールボックスＩＤを使用してすべてＩＢＥ暗号化された、ＡのＩＤ、ＢのメールボックスのＩＤ、ｘＰ、およびｙＰを含む新たなメッセージを送信する。このメッセージを受信すると、Ｂのメールボックスは、Ｂに向けられたメッセージのためのセッション鍵として「ｓＫ」を受け入れ、ＡのＩＤ、およびｘＰをユーザＡに戻して認証を完了させる。
【０１５４】
ｓＫは、Ｂの公開鍵を使用して暗号化され、このため、メールボックスＢは、このメッセージを解読し、「ｓＫ」を獲得することができないことに注目されたい。その後、Ｂが、オンラインになり、「ボイスメール」を確認する（遅延配信サーバに対して確認を行う）と、Ｂは、メールボックスサーバからｓＫの暗号化された値を獲得することができる。Ｂは、その鍵を獲得するのにメールボックスを相手に認証を行わなければならない可能性があり、このことは、既に設定されている既存の認証機構に基づくことが可能であることに留意されたい。
【０１５５】
第２のシナリオ（やはり、機能要素４０２がＩＭＳサーバである図４Ｂを再び参照することが可能である）では、同一の想定が成立し、すなわち、ユーザＡが、現在、応対可能でないユーザＢと連絡をとろうと試みており、したがって、その呼は、Ｂのボイスメールに転送される。しかし、この事例において、ＢのメールボックスとユーザＡは、認証を実行しない。代わりに、Ｂのメールボックスは、単にｓＫをセッション鍵として受け入れ、ユーザＡにＯＫメッセージを戻してｓＫを確認する。
【０１５６】
Ｇ．グループ呼および会議呼
この段落では、ＭＩＫＥＹ−ＩＢＡＫＥの鍵管理プロトコルが、グループ呼および会議呼に拡張される。したがって、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルから生じる有利な特性は、会議環境において実現されることに留意されたい。会議は、概ね、図６Ａから図６Ｃの関連において説明されていることを思い起こされたい。図１０のＩＭＳ例は、Ｎ＝３の場合であることに留意されたい。
【０１５７】
図１０のステップ１から１８に示されるＩＭＳベースのシナリオにおいて、ユーザを会議呼に招待する会議サーバ（ＡＳ／ＭＲＦＣ、つまり、アプリケーションサーバ／マルチメディアリソース機能コントローラ）が存在するものと想定される。このことは、例えば、別のユーザから以前に受信されたＲＥＦＥＲ要求の結果であることも可能である。代替のアプローチは、この機能をユーザの１名（例えば、会議長）に委託することである。この代替は、図１０に示されないものの、このアプローチは、同様であり、グループ鍵の計算は、同一である。
【０１５８】
以下の説明において、すべてのメッセージは、適切なＩＤを使用してＩＢＥ暗号化される（例えば、ユーザＹが、ユーザＸにメッセージＭを送信している場合、メッセージＭは、ＸのＩＤを使用して暗号化される）ものと想定される。図１０で、このことは、（Ｍ）＿Ｘとして表され、つまり、メッセージＭは、ＸのＩＤを使用してＩＢＥ暗号化されることを意味する。
【０１５９】
会議サーバを相手にした交換の第１のセットにおいて、ユーザＡ１、Ａ２、およびＡ３が、それぞれ、ランダムなａ１、ａ２、およびａ３を選択し、さらに各ユーザＡｉが、ｗｉ＝ａｉＰを会議サーバに送信する。交換の第２のセットにおいて、会議サーバは、すべてのａｉＰをすべてのユーザに送信する一方で、各ユーザは、ｚｉ＝ａｉ（ａｉ＋１Ｐ−ａｉ−１Ｐを）を送信する。最後の交換において、会議サーバは、すべてのｚｉを各ユーザに送信する。以上が行われた後、すべての会議参加者は、以下のとおりグループ鍵を計算することができる。すなわち、Ｋｉ＝３ａｉｗｉ−１＋２ｚｉ＋ｚｉ＋１
Ｋ１＝Ｋ２＝Ｋ３であることに留意されたい。また、Ａ１、Ａ２、およびＡ３は、グループ鍵を生成することができるが、会議サーバは、ｚｉおよびｗｉを知っているが、個々のユーザだけしか、ユーザによってランダムに選択されたａｉを知らないので、グループ鍵を生成することができないことにも留意されたい。
【０１６０】
簡明のため、前述の説明は、３名の会議呼参加者に絞る。しかし、前述の手順は、ｎ名の参加者に一般化され得る。ｎ名の参加者の場合、グループ鍵は、Ｋｉ＝ｎａｉｗｉ−１＋（ｎ−１）ｚｉ＋（ｎ−２）ｚｉ＋１．．．ｚｉ−１として生成され、ただし、ｗｉおよびｚｉは、前段で定義されるとおりである。
【０１６１】
このプロトコルの重要な特徴の１つは、新たなユーザが受け入れられるたびに、または既存のユーザが呼を抜けるたびに、グループ鍵が変わることである。このことは、新たなユーザが、呼に追加されるまで、グループ鍵を知ることがないことを確実にし、さらに呼を尚早に離れるユーザは、呼の後、会話へのアクセスを得ることがない。
【０１６２】
新たなユーザが追加され、さらにシステムにＮ名のユーザが既に存在する場合、合計でＮ＋１名のユーザがシステムに存在することに注目されたい。これらのユーザが輪にされると、第Ｎ番のユーザの次のユーザは、現時点で、第（Ｎ＋１）番のユーザである（第Ｎ＋１番のユーザを受け入れる前にそうであったように、第１番のユーザではなく）。新たなユーザを受け入れるプロトコルは、以下のとおり機能する：
新規のユーザは、すべてのユーザと同様に、ＩＢＡＫＥを使用して会議サーバに対して認証を行う。このことは、そのユーザが受け入れられる（さらに呼を許可される）ことを可能とし、さらにその新規のユーザは、正しい会議に参加することを保証される（会議サーバの認証を介して）。
【０１６３】
ｚＮ＋１＝ａＮ＋１Ｐを、認証中に新たなユーザによって選択された値とする。
【０１６４】
次に、会議サーバが、ｉ＝１からｉ＝Ｎ＋１までのすべてに関する集合｛ｚｉ｝を、ブロードキャストであれ、ユニキャストであれ、すべてのユーザに送信する。このことは、すべてのユーザが、その新規のユーザについて知るとともに、ユーザの隣人を特定することを可能とする。隣人リストは、ユーザ１、Ｎ、およびＮ＋１に関してだけ変化することに注目されたい。
【０１６５】
次に、ユーザ１、Ｎ、およびＮ＋１が、ｗのユーザ１、Ｎ、およびＮ＋１に対応する値を計算し、その値を会議サーバに送り返す（個々に）。
【０１６６】
次に、サーバが、｛ｗｉ｝の更新されたリストをすべてのユーザに送信する。
【０１６７】
次に、すべての参加者が、前述したのと同一の式を使用してグループ鍵を再計算し、ただし、Ｎは、Ｎ＋１で置き換えられ、ｚｉおよびｗｉの新たな値が使用される。
【０１６８】
ユーザが会議呼を抜けると、新たな認証手順は、全く実行される必要はないが、グループ鍵が変化する。この手順は、以下のとおり機能する：
会議サーバが、ユーザが会議呼を抜けることについて知る。
【０１６９】
その後、会議サーバが、このイベント、ならびにいずれのユーザが呼を抜けたかに関係する情報（単にＩＤだけでなく、順序も含む）を全員に知らせる。事情を簡単にするため、会議サーバは、新規のリスト｛ｚｉ｝を再送信してもよい。
【０１７０】
このことは、すべてのユーザが、ユーザの隣人を再発見し、さらに必要な場合、ｗｉを再計算することを可能とする。
【０１７１】
ｗｉが変化した、呼に留まっているすべての参加者は、これらの参加者の新たな値を会議サーバに知らせる。
【０１７２】
次に、会議サーバが、更新されたリスト｛ｗｉ｝を送信する。
【０１７３】
次に、すべての参加者が、前述したのと同一の式を使用してグループ鍵を再計算し、ただし、Ｎは、Ｎ−１で置き換えられ、ｗｉの新たな値が使用される。
【０１７４】
ＩＶ．例示的なコンピューティングシステム
図１１は、ネットワーク環境、ならびに本発明の実施形態による２つのエンティティ間でセキュリティで保護された鍵管理プロトコルを実施するのに適したコンピューティングデバイスの形態の通信デバイスの一般化されたハードウェアアーキテクチャ１１００を示す。図１１は、２つだけのエンティティしか示さないが、他のエンティティも同一の構成を有することが可能であることを理解されたい。このため、前述した、セキュリティで保護された鍵管理プロトコルに関連して、この２つのエンティティは、開始側１０２−Ｉ（第１の関係者、またはＡ）および応答側１０２−Ｒ（第２の関係者、またはＢ）であることが可能である。しかし、ＫＭＳ、会議サーバ、ＬＩサーバ、機能要素、さらなるクライアントデバイス（関係者）、およびさらなるサーバが、図１１のコンピューティングデバイスに示されるのと同一のアーキテクチャを使用して実施されることが可能である。したがって、簡明のため、本発明のプロトコルに参加する可能性があるすべてのコンピューティングデバイス（通信デバイス）を図１１に示すことはしない。
【０１７５】
図示されるとおり、１１０２として示されるＡのコンピューティングデバイスと、１１０４として示されるＢのコンピューティングデバイスが、ネットワーク１１０６を介して結合される。このネットワークは、例えば、前述した実施形態の場合と同様に、デバイスが通信することができる任意のネットワークであることが可能であり、ネットワーク１１０６は、ネットワーク事業者（例えば、ベライゾン社、ＡＴ＆Ｔ社、スプリント社）によって運営されるセルラ通信ネットワークなどの公衆アクセス可能な広域通信ネットワークを含むことが可能である。しかし、本発明は、特定のタイプのネットワークに限定されない。通常、これらのデバイスは、クライアントマシンであることが可能である。本明細書で説明されるプロトコルに参加するのに関係者によって使用されることが可能なクライアントデバイスの例には、セルラ電話機、スマートフォン、デスクトップ電話機、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどが含まれることが可能であるが、以上には限定されない。しかし、デバイスの１つまたは複数は、サーバであることも可能である。このため、本発明の通信プロトコルは、コンピューティングシステムが、それぞれ、クライアントとサーバである事例に限定されず、２つのネットワーク要素を備える任意のコンピューティングデバイスに適用可能であることを理解されたい。
【０１７６】
当業者には直ちに明白であるとおり、これらのサーバおよびクライアントは、コンピュータプログラムコードの制御下で動作する、プログラミングされたコンピュータとして実施されることが可能である。コンピュータプログラムコードは、コンピュータ可読記憶媒体（例えば、メモリ）の中に格納され、さらにこのコードは、コンピュータのプロセッサによって実行される。本発明の本開示を与えられて、当業者は、本明細書で説明されるプロトコルを実施するために適切なコンピュータプログラムコードを容易に作ることができる。
【０１７７】
それでも、図１１は、ネットワークを介して通信する各コンピュータシステムに関する例示的なアーキテクチャを一般的に示す。図示されるとおり、デバイス１１０２は、入出力デバイス１１０８−Ａと、プロセッサ１１１０−Ａと、メモリ１１１２−Ａとを備える。デバイス１１０４は、入出力デバイス１１０８−Ｂと、プロセッサ１１１０−Ｂと、メモリ１１１２−Ｂとを備える。本明細書で使用される「プロセッサ」という用語は、中央処理装置（ＣＰＵ）、あるいは１つまたは複数のシグナルプロセッサ、１つまたは複数の集積回路などを含むが、以上には限定されない他の処理回路を含め、１つまたは複数の処理デバイスを含むことを意図していることを理解されたい。また、本明細書で使用される「メモリ」という用語は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えば、ハードドライブ）、またはリムーバブルメモリデバイス（例えば、ディスケットもしくはＣＤ−ＲＯＭ）などの、プロセッサまたはＣＰＵに関連するメモリを含むことを意図している。さらに、本明細書で使用される「入出力デバイス」という用語は、処理装置にデータを入力するための１つまたは複数の入力デバイス（例えば、キーボード、マウス）、ならびに処理装置に関連する結果をもたらすための１つまたは複数の出力デバイス（例えば、ＣＲＴディスプレイ）を含むことを意図している。
【０１７８】
したがって、本明細書で説明される、本発明の方法を実行するためのソフトウェア命令またはソフトウェアコードは、関連するメモリデバイス、例えば、ＲＯＭ、固定メモリ、またはリムーバブルメモリの１つまたは複数の中に格納されることが可能であり、さらに、利用される用意ができると、ＲＡＭにロードされ、ＣＰＵによって実行される。
【０１７９】
本発明の例示的な実施形態は、添付の図面を参照して本明細書で説明されてきたが、本発明は、それらの実施形態そのものに限定されないこと、および本発明の範囲または趣旨を逸脱することなく、他の様々な変更および変形が当業者によって行われ得ることを理解されたい。
【技術分野】
【０００１】
本出願は、参照により開示が本明細書に組み込まれている、整理番号８０５７１４で識別され、「Ｓｅｃｕｒｅ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ ｉｎ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ」という名称の、本出願の譲受人に譲渡され、同時に出願された米国特許出願に関連する。
【０００２】
本発明は、一般に、通信セキュリティに関し、より詳細には、マルチメディア通信システムおよび電話会議システムのメディアプレーンなどの通信環境において使用するためのセキュリティで保護された鍵管理プロトコルに関する。
【背景技術】
【０００３】
マルチメディア通信システムにおいて提供される既存のマルチメディアアプリケーションは、メディアプレーンにおけるセキュリティをサポートしない。メディアプレーンセキュリティに関する懸念は、比較的新しい問題である。
【０００４】
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）などのマルチメディア通信システムにおける既存の提案は、鍵を作成して、配信する可能性がある鍵管理サーバを使用して管理される、何らかの種類のトークンベースの対称鍵方法に基づく。参照により開示が本明細書に組み込まれている３ＧＰＰ（第３世代パートナーシッププロジェクト）ＴＲ（技術レポート）３３．８２８が、ＩＭＳメディアプレーン暗号化に関する既存の提案を説明する。しかし、これらの既存のソリューションは、スケーラブルではなく（サーバが、高度に応対可能であるとともに、常時、オンラインでなければならないので）、エンティティの認証を提供せず、加えて、サーバにおける鍵供託も提供しない。
【０００５】
逆に、ＳＫＹＰＥ（ルクセンブルクのスカイプテクノロジーズ社の商標）や、その他のクライアントツークライアントマルチメディアアプリケーションなどの非ＩＭＳアプリケーションは、認証を用い、鍵供託は用いない終端間プライバシーを提供する。しかし、このソリューションは、管理するのに極めて高い費用がかかる、利用可能性が非常に高い公開鍵インフラストラクチャ（ＰＫＩ）を要求する証明書の使用に依拠する。さらに、このソリューションは、グループ会議アプリケーションに合わせて十分にスケーリングされず、ＰＫＩが存在しない状況下で通信の合法な傍受を可能にすることもない。
【０００６】
さらに、同様な鍵管理セキュリティ問題が、関係者が会議サーバ経由で呼セッションに参加する会議システムに存在する。
【０００７】
このため、マルチメディア通信システムおよび電話会議システムのメディアプレーンなどの通信環境において使用するためのセキュリティで保護された鍵管理ソリューションの必要性が存在する。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】ＢｏｎｅｈおよびＦｒａｎｋｌｉｎ、ｓｃｃ Ｄａｎ Ｂｏｎｅｈ、Ｍａｔｔｈｅｗ Ｋ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ｅｎｃｒｙｐｔｉｏｎ ｆｒｏｍ ｔｈｅ Ｗｅｉｌ Ｐａｉｒｉｎｇ」、Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｇｒａｐｈｙ − Ｐｒｏｃｅｅｄｉｎｇ ｏｆ ＣＲＹＰＴＯ ２００１（２００１年）
【非特許文献２】Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｉｏｎ（ＩＴＵ−Ｔ）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．３２３
【非特許文献３】Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＩＥＴＦ ＲＦＣ３２６１
【非特許文献４】３ＧＰＰ技術仕様、ＴＳ２３．２１８
【非特許文献５】３ＧＰＰ技術仕様、ＴＳ２３．２２８
【非特許文献６】３ＧＰＰ技術仕様、ＴＳ２４．２２８
【非特許文献７】３ＧＰＰ技術仕様、ＴＳ２４．２２９
【非特許文献８】３ＧＰＰ技術仕様、ＴＳ２４．２３０
【非特許文献９】ＩＥＴＦ ＲＦＣ２２４６
【非特許文献１０】ＩＥＴＦ ＲＦＣ３７１１
【非特許文献１１】ＩＥＴＦ ＲＦＣ２６３３
【非特許文献１２】ＩＥＴＦ ＲＦＣ２４０６
【非特許文献１３】ＩＥＴＦ ＲＦＣ２４０９
【非特許文献１４】ＩＥＴＦ ＲＦＣ４３０６
【非特許文献１５】ＩＥＴＦ ＲＦＣ４３０８
【非特許文献１６】ＩＥＴＦ ＲＦＣ２２４６
【非特許文献１７】３ＧＰＰ技術仕様、ＴＳ３３．２２０
【非特許文献１８】Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ １、Ｔｈｅ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３３４６−９
【非特許文献１９】Ｗ．Ｒｉｃｈａｒｄ ＳｔｅｖｅｎｓおよびＧａｒｙ Ｒ．Ｗｒｉｇｈｔ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ２、Ｔｈｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ、ＩＳＢＮ ０−２０１−６３３５４−Ｘ
【非特許文献２０】Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ３、ＴＣＰ ｆｏｒ Ｔｒａｎｓａｃｔｉｏｎｓ，ＨＴＴＰ，ＮＮＴＰ，ａｎｄ ＵＮＩＸ Ｄｏｍａｉｎ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３４９５−３
【非特許文献２１】ＩＥＴＦ ＲＦＣ５０９１
【非特許文献２２】ＩＥＴＦ ＲＦＣ５４０８
【非特許文献２３】ＩＥＴＦ ＲＦＣ５４０９
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の原理は、会議システムなどの通信環境において使用するための１つまたは複数のセキュリティで保護された鍵管理プロトコルを提供する。
【課題を解決するための手段】
【００１０】
例えば、一態様において、通信システムにおいて２名以上の関係者の間で会議を管理するための方法が、以下のステップを備える。ＩＤベースの認証された鍵交換動作が、通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間で実行され、その会議管理要素とその２名以上の関係者の間で交換されるメッセージは、それらのメッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素は、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する。
【００１１】
会議管理要素が、それらの関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信する。会議管理要素が、各関係者からランダムなグループ鍵構成要素を受信し、このランダムなグループ鍵構成要素は、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される。
【００１２】
会議管理要素が、各関係者に、それらの関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信して、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにする。
【００１３】
一実施形態において、会議管理要素は、会議における参加する関係者ではなく、その結果、グループ鍵を計算することができない。別の実施形態において、会議管理要素は、会議呼における参加する関係者であり、その結果、グループ鍵を計算することができる。
【００１４】
一実施形態において、各関係者によって計算されるグループ鍵は、Ｎａｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋．．．＋Ｘｉ−２として表現され、ただし、Ｎは、会議に参加することを求めている関係者の総数を表し、ａｉは、所与の関係者によって選択された乱数を表し、Ｚｉは、所与の関係者によって計算されるランダムな鍵構成要素を表し、Ｘｉは、所与の関係者によって計算されるランダムなグループ鍵構成要素を表し、さらにｉは、Ｎ名の関係者の会議における所与の関係者に関する会議順序付けの番号を表し、ｉ＝１の場合、ｉ−１＝Ｎであり、ｉ＝Ｎである場合、ｉ＋１＝１である。
【００１５】
一実施形態において、所与の関係者に関するランダムな鍵構成要素は、ａｉＰとして表現される計算によって計算され、ただし、ａｉは、所与の関係者によって選択された乱数であり、さらにＰは、ＩＤ暗号化ベースの鍵認証動作に関連するグループから選択された点である。
【００１６】
一実施形態において、所与の関係者に関するランダムなグループ鍵構成要素は、ａｉ（ａｉ＋１Ｐ−ａｉ−１Ｐ）として表現される計算によって計算され、ただし、ａｉは、その所与の関係者によって選択された乱数であり、ａｉ＋１Ｐは、会議順序付けにおいてその所与の関係者の直後に続く関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、ａｉ−１Ｐは、会議順序付けにおけるその所与の関係者の直前の関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、さらにＰは、暗号鍵交換プロトコルに関連するグループから選択された点である。
【００１７】
本発明の原理は、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）環境に特に適しているが、本発明は、そのように限定されることは意図していないことを認識されたい。つまり、本発明の原理は、セキュリティで保護された鍵管理フィーチャを提供することが望ましい任意の適切な通信システムに一般に適用可能である。
【００１８】
本発明のこれら、およびその他の目的、特徴、および利点は、添付の図面と併せて読まれるべき、本発明の例示的な実施形態の以下の詳細な説明から明白となろう。
【図面の簡単な説明】
【００１９】
【図１Ａ】本発明の或る実施形態による秘密鍵獲得方法を示す図である。
【図１Ｂ】本発明の或る実施形態によるＩＤベースの認証された鍵交換方法を示す図である。
【図２】本発明の或る実施形態による鍵分岐方法を示す図である。
【図３】本発明の或る実施形態による呼リダイレクト方法を示す図である。
【図４Ａ】本発明の或る実施形態による遅延配信方法を示す図である。
【図４Ｂ】本発明の別の実施形態による遅延配信方法を示す図である。
【図５】本発明の或る実施形態による合法な傍受方法を示す図である。
【図６Ａ】本発明の或る実施形態による会議管理方法を示す図である。
【図６Ｂ】本発明の或る実施形態による会議管理方法における参加者の追加を示す図である。
【図６Ｃ】本発明の或る実施形態による会議管理方法における参加者の削除を示す図である。
【図７】本発明のＩＭＳベースの実施形態によるセキュリティで保護された鍵管理プロトコルに関するネットワークアーキテクチャを示す図である。
【図８】本発明のＩＭＳベースの実施形態による鍵分岐方法を示す図である。
【図９】本発明のＩＭＳベースの実施形態によるリダイレクト方法を示す図である。
【図１０】本発明のＩＭＳベースの実施形態による３名の参加者を有する会議方法を示す図である。
【図１１】本発明の実施形態によるプロトコルの１つまたは複数を実施するのに適したデータネットワークおよび通信（コンピューティング）デバイスの一般化されたハードウェアアーキテクチャを示す図である。
【発明を実施するための形態】
【００２０】
本明細書で使用される「マルチメディア通信システム」という句は、一般に、テキストベースのデータ、グラフィックスベースのデータ、音声ベースのデータ、およびビデオベースのデータを含むが、以上には限定されない２つ以上のタイプのメディアをトランスポートすることができる任意の通信システムとして定義される。
【００２１】
本明細書で使用される「メディアプレーン」という句は、一般に、呼セッションにおける２つ以上の関係者の間で１つまたは複数のタイプのメディアが交換されるのに準拠するマルチメディア通信システムの機能部分として定義される。このことは、呼セッションを確立するために呼ネゴシエーション／スケジューリングが実行されるのに準拠するマルチメディア通信システムの機能部分である「制御プレーン」と対比される。本発明の技術が使用され得るメディアプレーンアプリケーションの例には、ボイスオーバーＩＰ（ＶｏＩＰ）、インスタントメッセージング（ＩＭ）、ボイス／オーディオＩＭ、およびボイスシェアが含まれるが、以上には限定されない。メディアプレーンは、アプリケーション層トラフィックを含むものと理解される。
【００２２】
本明細書で使用される「鍵」という用語は、一般に、エンティティ認証、プライバシー、メッセージ完全性などを目的とするが、以上の目的には限定されない、暗号プロトコルへの入力として定義される。
【００２３】
参照を容易にするため、詳細な説明は、以下のとおり分けられる。段落Ｉが、ＩＤベースの暗号化動作およびＩＤベースの認証された鍵交換動作の一般的な原理を説明する。段落ＩＩが、一般的な通信環境コンテキストにおける本発明の例示的な原理によるセキュリティで保護された鍵管理ソリューションを説明する。段落ＩＩＩが、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）環境コンテキストにおける本発明の例示的な原理によるセキュリティで保護された鍵管理ソリューションを説明する。段落ＩＶが、本発明による１つまたは複数のセキュリティで保護された鍵管理プロトコルを実施するための例示的なコンピューティングシステムを説明する。
【００２４】
Ｉ．ＩＤベースの暗号化（ＩＢＥ）およびＩＤベースの認証された鍵交換（ＩＢＡＫＥ）
本発明のセキュリティで保護された鍵管理技術の例示的な実施形態の説明に先立って、ＩＢＥおよびＩＢＡＫＥの一般的な原理が与えられる。
【００２５】
Ａ．ＩＤベースの暗号化
ＩＤベースの暗号化（ＩＢＥ）プロトコルは、参照により開示が本明細書に組み込まれている、ＢｏｎｅｈおよびＦｒａｎｋｌｉｎによって提示された（Ｄａｎ Ｂｏｎｅｈ、Ｍａｔｔｈｅｗ Ｋ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ｅｎｃｒｙｐｔｉｏｎ ｆｒｏｍ ｔｈｅ Ｗｅｉｌ Ｐａｉｒｉｎｇ」、Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｇｒａｐｈｙ − Ｐｒｏｃｅｅｄｉｎｇ ｏｆ ＣＲＹＰＴＯ ２００１（２００１年）を参照）。この非対称暗号法の暗号化プロトコルは、参加者が、「ＩＤ」（例えば、電子メールＩＤ、またはドメイン名）を公開鍵として使用することを許し、ＲＳＡ（リベスト、シャミール、およびアドルマン）などの公開鍵暗号化方法にしばしば関連する大規模な公開鍵インフラストラクチャの必要性を解消する。この問題に対するＢｏｎｅｈおよびＦｒａｎｋｌｉｎのアプローチは、有限体上の楕円曲線上の双線形写像を使用し、さらに双線形決定ディフィ−ヘルマン問題に依拠する。
【００２６】
ＩＢＥには、以下の数学ツールおよびパラメータがかかわる：
Ｅを有限体Ｆ上の楕円曲線とし、Ｐを大きい素数位数の点とする。
【００２７】
ｅ：ＥｘＥ−→ＧをＥ上の双線形写像とする。典型的な例が、ヴェイユペアリングであり、したがって、Ｇは、ｎがＦ上のＥ上の点の数の関数である１のｎ乗根の群である。
【００２８】
ｓを０でない正の整数とし、鍵生成関数（ＫＧＦ）の中に格納された秘密とする。これは、システム全体の秘密であり、ＫＧＦの外部には明かされない。
【００２９】
Ｐｐｕｂ＝ｓＰを、すべての参加者に知られているシステムの公開鍵とする。ｓＰは、Ｅが群であるので、Ｅの中の点を表すことを想い起こされたい。
【００３０】
Ｈ１を、或る文字列をとり、その文字列を、楕円曲線上の或る点に割り当てる、知られているハッシュ関数とし、すなわち、Ｅ上のＨ１（Ａ）＝ＱＡであり、ただし、Ａは、通常、ＩＤであり、さらにＡの公開鍵でもある。
【００３１】
ｄＡ＝ｓＱＡを、ＫＧＦによって計算され、Ａだけに配信される秘密鍵であるものとする。
【００３２】
Ｈ２を、Ｇの要素をとり、その要素を或る文字列に割り当てる、知られているハッシュ関数とする。
【００３３】
ｍを、暗号化されて、Ａに送信される必要があるメッセージとする。ＢｏｎｅｈおよびＦｒａｎｋｌｉｎによって説明される暗号化関数は、以下のとおりである。
【００３４】
ｇＡ＝ｅ（ＱＡ，Ｐｐｕｂ）とし、さらにｒを乱数とする。
【００３５】
暗号化Ａ（ｍ）＝（ｒＰ，ｍ ｘｏｒ Ｈ２（ｇＡＩ））であり、つまり、ｍの暗号化出力は、２つの座標ｕおよびｖを有し、ただし、ｕ＝ｒＰであり、ｖ＝ｍ ｘｏｒ Ｈ２（ｇＡＩ）である。「ｘｏｒ」とは、排他的論理和関数を指すことに留意されたい。
（ｕ，ｖ）を解読するために、Ａは、以下の式を使用してｍを回復する：
ｍ＝ｖ ｘｏｒ Ｈ２（ｃ（ｄＡ，ｕ））
この式の証明は、双線形写像において単純明快な作業であり、事実Ａは、秘密ｄＡ（Ａだけには知られているが、その他の参加者には知られていない秘密鍵）を有する。また、そもそもｄＡを計算したＫＧＦは、そのメッセージを解読することもできて、ＫＧＦが、事実上、鍵供託サーバであることになることにも注目されたい。
【００３６】
Ｂ．ＩＤベースの認証された鍵交換
ＩＢＡＫＥ（ＩＤベースの認証された鍵交換）は、参照により開示が本明細書に組み込まれている、２００９年２月１７日に出願したシリアル番号１２／３７２，２４２によって識別される米国特許出願において説明される。ＩＢＡＫＥプロトコルは、デバイスが互いを相互に認証し、さらに完全な順方向の秘密および逆方向の秘密をもたらす鍵を導き出すことを可能とする。
【００３７】
本明細書で説明されるＩＢＡＫＥ実施形態において、このプロトコルに関する基本的なセットアップには、サブ段落Ａで前述した数学的構造およびパラメータがかかわる。このプロトコルは、非対称的であるが、ＰＫＩサポートを全く必要とせず、代わりに、このプロトコルは、鍵生成関数の役割をするオフラインサーバを使用することを思い起こされたい。このプロトコルの詳細を以下に概略で述べる。
【００３８】
Ａ、Ｂが、鍵を認証し、鍵について合意しようと試みている２つのエンティティ（または、Ａが第１の関係者のコンピュータシステムを表し、Ｂが第２の関係者のコンピュータシステムを表す、関係者）であるものと想定されたい。
【００３９】
ＡおよびＢを使用して、定義により、ＡおよびＢの公開鍵も表す、ＡおよびＢに対応するＩＤを表す。
【００４０】
Ｈ１（Ａ）＝ＱＡおよびＨ１（Ｂ）＝ＱＢを、公開鍵に対応する楕円曲線上のそれぞれの点とする。実際、ＩＤと、Ｈ１を適用することによって獲得される曲線上の点の間に１対１対応が存在するので、ＱＡおよびＱＢを公開鍵と呼ぶことも可能である。
【００４１】
ｘを、Ａによって選択された乱数とし、さらにｙをＢによって選択された乱数とする。
【００４２】
ＡとＢの間のプロトコル交換は、以下のステップから成る：
第１のステップで、Ａが、ｘＰ（すなわち、Ｅ上で加算則を使用して、Ｅ上の点としてｘ回、自らに加算されたＰ）を計算し、ｘＰを、Ｂの公開鍵を使用して暗号化し、さらに暗号化されたｘＰをＢに送信する。このステップにおいて、暗号化とは、前出のサブ段落Ａで説明されるＩＤベースの暗号化を指す。
この暗号化されたメッセージを受信すると、Ｂは、このメッセージを解読し、ｘＰを獲得する。その後、第２のステップで、Ｂは、ｙＰを計算し、Ａの公開鍵を使用してペア｛ｘＰ，ｙＰ｝を暗号化し、その後、暗号化されたペア｛ｘＰ，ｙＰ｝をＡに送信する。
このメッセージを受信すると、Ａは、このメッセージを解読し、ｙＰを獲得する。その後、第３のステップで、Ａは、Ｂの公開鍵を使用してｙＰを暗号化し、暗号化されたｙＰをＢに送り返す。
以上の後に続いて、ＡとＢがともに、ｘｙＰをセッション鍵として計算する。
Ａはｘをランダムに選択しており、さらにプロトコル交換の第２のステップでｙＰを受信していることに注目されたい。このことは、Ａが、ｙＰを自らにｘ回、加算することによってｘｙＰを計算することを可能とする。逆に、Ｂは、ｙをランダムに選択しており、さらにプロトコル交換の第１のステップでｘＰを受信している。このことは、Ｂが、ｘＰを自らにｙ回、加算することによってｘｙＰを計算することを可能とする。このプロトコルのいずれの適用も、ＩＤと一緒にヘッダデータを利用して、このプロトコルが適切に機能することを確実にすることが可能であることに留意されたい。このことは、比較的標準的であり、鍵合意のためのほとんどすべてのプロトコル交換に適用可能である。
また、ｘは、ランダムであるが、ｘＰは、ｘについての情報を全く与えないことに留意されたい。したがって、ｘＰは、Ａによって選択されたランダムな秘密に基づく鍵の構成要素である。同様に、ｙは、ランダムであるが、ｙＰは、ｙについての情報を全く供給しない。したがって、ｙＰは、Ｂだけに知られているランダムな秘密に基づく鍵の構成要素である。
ｘｙＰは、セッション鍵の役割をすることが可能であることにさらに留意されたい。また、セッション鍵は、ｘｙＰの任意の知られている関数であることが可能である。つまり、セッション鍵は、ｆ（ｘｙＰ）と等しいことが可能であり、ただし、ｆは、両方の関係者に知られており、秘密であることを要求されない（すなわち、世界に知られている）。ｆに関する１つの実際的な要件は、ｆが、ｘまたはｙの知識なしに計算するのが困難であることであり、さらに出力は、暗号法の見地から満足の行く長さ、例えば、約１２８ビット以上である。
【００４３】
ＩＢＡＫＥプロトコルの特性のいくつかには、以下が含まれる：
− 鍵供託を免れていること。プロトコル交換におけるすべてのステップは、ＩＢＥを使用して暗号化されることに注目されたい。したがって、明らかに、ＫＧＦは、すべての交換を解読することができる。しかし、ＫＧＦは、セッション鍵を計算することができない。このことは、楕円曲線ディフィ−ヘルマン問題の難しさのためである。つまり、ｘＰおよびｙＰを与えられて、ｘｙＰを計算することは計算的に困難である。
− 相互に認証された鍵合意。プロトコル交換におけるすべてのステップは、ＩＢＥを使用して暗号化されることに注目されたい。特に、Ｂだけが、第１のステップ、および第３のステップでＡによって送信されたメッセージの内容を解読することができ、同様にＡだけが、第２のステップでＢによって送信されたメッセージの内容を解読することができる。さらに、第２のステップの終わりで、Ａは、第１のステップでＢによって内容が解読された後だけ、ｘＰが第２のステップで送信されている可能性があるので、Ｂの真正性を検証することができる。同様に、第３のステップの終わりで、Ｂは、第２のステップの内容を正しく解読した後だけ、第ｙＰが３のステップで送り返されている可能性があり、正しく解読することは、Ａによってしか可能でないので、Ａの真正性を検証することができる。最後に、ＡとＢがともに、同一のセッション鍵について合意することが可能である。つまり、このプロトコルは、ＩＢＥに基づく、相互に認証された鍵合意プロトコルである。以上の説明は、プロトコルのセキュリティに関する動機を与えるが、セキュリティの暗号法上の証明が容易に与えられることが可能である。プロトコルの堅牢性は、楕円曲線の選択によって影響される、楕円曲線ディフィ−ヘルマン問題の難しさに依拠する。
− 完全な順方向の秘密および逆方向の秘密。ｘおよびｙは、ランダムなので、ｘｙＰは、常に新規であり、ＡとＢの間のいずれの過去のセッション、または将来のセッションとも無関係である。
− パスワードが存在しない。ＩＢＡＫＥプロトコルは、ＡとＢの間でパスワードまたは秘密鍵のオフライン交換を全く要求しない。事実、この方法は、任意の通信ネットワークを介して初めて通信している任意の２名の関係者に明らかに適用可能である。唯一の要件は、ＡとＢの両方が、例えば、ディレクトリサービスを介して、互いの公開鍵を認識していることを確実にすることだけである。
【００４４】
ＩＩ．セキュリティで保護された鍵管理、および例示的な拡張
インターネットが、ベストエフォートデータネットワークから、マルチメディアを含む様々なクラスのトラフィックに関するサポートを備えたマルチサービスＩＰ（インターネットプロトコル）ネットワークに急速に進化したことが認識されている。このことが、モバイルワイヤレスネットワークの急速な成長と相俟って、技術的な課題を生じさせている。技術的見地から、それなりにうまく対処されてきた中心的な課題が、「メディアプレーン」としばしば呼ばれるアプリケーション層トラフィックからの、呼をセットアップするシグナリングから成る呼制御機能の分離である。Ｈ３２３（例えば、参照により開示が本明細書に組み込まれている、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｉｏｎ（ＩＴＵ−Ｔ）Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．３２３を参照）、セッション開始プロトコルまたはＳＩＰ（例えば、参照により開示が本明細書に組み込まれている、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ ＩＥＴＦ ＲＦＣ３２６１を参照）、およびＩＭＳ（例えば、参照により開示が本明細書に組み込まれている、３ＧＰＰ技術仕様、ＴＳ２３．２１８、ＴＳ２３．２２８、ＴＳ２４．２２８、ＴＳ２４．２２９、およびＴＳ２４．２３０を参照）などの呼制御プロトコルが、ＩＥＴＦや３ＧＰＰなどの様々な組織によって標準化されており、固定ネットワークおよびモバイルネットワークにわたって様々な採用段階にある。
【００４５】
同時に、様々なレベルでシグナリングをセキュリティで保護する入念な機構が組み込まれてきた。しかし、メディアプレーンにおいて、トランスポート層セキュリティまたはＴＬＳ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２２４６を参照）、セキュアリアルタイムトランスポートプロトコルまたはＳＲＴＰ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ３７１１を参照）などのプロトコル、およびセキュア多目的インターネットメール拡張またはＳＭＩＭＥ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２６３３を参照）が、様々なアプリケーションに関するコンテナフォーマットを提供するが、メディアプレーンにおけるセキュリティソリューションは、アプリケーション層において終端間のセキュリティで保護された鍵管理をサポートする一貫性のある、標準化された方法を欠いている。
【００４６】
本発明の原理は、主に、この問題に対処する。特に、本発明の原理は、メディアプレーンに関してスケーラブルなアプリケーション、およびプロトコルにとらわれないセキュリティで保護された鍵管理の枠組みを提供する。例示的な枠組みにおいて、本発明のソリューションは、段落Ｉ．Ｂで前述した非対称（したがって、公開鍵）ＩＢＡＫＥ（ＩＤベースの認証された鍵交換）プロトコルを利用する。例示的な実施形態は、例えば、セキュリティで保護された２名の関係者のメディアプレーン通信アプリケーション、セキュリティで保護された複数関係者会議アプリケーション、セキュリティで保護された呼分岐アプリケーション、セキュリティで保護された呼リダイレクトアプリケーション、およびセキュリティで保護された遅延配信アプリケーションなどの、様々なフィーチャをサポートする鍵交換機構を説明する。セキュリティで保護された鍵管理のためのスケーラブルな枠組みを提供することに加えて、この設計および枠組みのいくつかの例示的な態様には、以下が含まれる：
− 要求されるネットワークサポートの複雑度を劇的に低減するオフラインＫＭＳ（鍵管理サーバ）の使用。公開鍵環境における非対称プロトコルは、取消しを含む証明書管理の入念な常時オンのＰＫＩ（公開鍵インフラストラクチャ）サポートを要求することを思い起こされたい。対称鍵ベースの鍵管理サーバは、定義により、絶え間なく同期し、更新している「常時オン」のサーバである。この「常時オン」の要件をなくすことにより、我々の枠組みは、費用を劇的に低減し、スケーラビリティを促進する。
− ＩＤベースのプロトコルに特有の受動的な鍵供託の解消。鍵管理サーバを使用する対称鍵プロトコルは、この問題を解消することができないことを思い起こされたい。また、既存のＩＤベースの暗号化（段落Ｉ．Ａで前述した）プロトコルは、ＩＢＡＫＥ（段落Ｉ．Ｂで前述した）を使用して解決される問題である、鍵供託問題に悩まされることも思い起こされたい。
− このプロトコルの枠組みは、鍵交換に関与するエンティティの相互認証を、完全な秘密とともに本来的にサポートする。
− 本発明の例示的な実施形態は、既存のネットワーク要素アーキテクチャを再使用し、さらに、可能な限り、既存のプロトコルコンテナフォーマットを再使用する。例として、会議アプリケーションにおいて、例示的な実施形態は、会議サーバを再使用して、会議を可能にするが、会議サーバが、通信のために使用されるグループ鍵を知ることがない（後段で説明されるとおり、会議サーバも会議の関係者であるのではない限り）ことを確実にする。
− 本発明の原理は、受動的な鍵供託をなくすが、本発明のプロトコルは、呼を傍受する法の執行のための法的要件が存在する場合に、鍵を見出すことのシームレスなサポートも提供する。
【００４７】
ＩＤベースの非対称暗号法の枠組みに基づく例示的な実施形態において、各参加者は、公開鍵と、秘密鍵とを有する。その公開鍵は、ＩＤに基づく。その秘密鍵は、その公開鍵に対応し、鍵管理サーバまたは鍵管理サービス（ＫＭＳ）によって発行される。参加者は、ＫＭＳから秘密鍵をオフラインで獲得することができる。単に例として、参加者は、１カ月に（より一般的には、契約の全期間にわたって）一度、参加者のＫＭＳと連絡をとり、秘密鍵を獲得する。また、秘密鍵は、使用の頻度に応じて獲得されることも可能である。ＫＭＳと参加者の間にセキュリティ関連付けが存在するものと想定される。鍵交換中のメッセージの暗号化および解読は、ＩＢＥに基づく。ＫＭＳの公開のパラメータは、公衆に入手可能である（例えば、ウェブサイト上でオンラインで）と想定されることに留意されたい。
【００４８】
一般に、本発明の例示的な実施形態によるセキュリティで保護された鍵管理方法は、２つの主な段階を備える。第１の段階で、参加者（関係者）が、ＫＭＳなどの鍵サービスから秘密鍵を獲得する。第２の段階で、マルチメディアベースの呼セッションにおいて通信することを求める２名以上の関係者の間でＩＤベースの認証された鍵交換が、実行される。その２名以上の関係者の間で交換されるメッセージは、メッセージの受信者のそれぞれのＩＤに基づいて暗号化される。また、それらの関係者の間で交換される暗号化されたメッセージは、関係者に関連付けられたＩＤを含む。
【００４９】
図１Ａは、セキュリティで保護された鍵管理方法の第１の段階、すなわち、秘密鍵獲得を示す。図示されるとおり、２名の関係者の通信デバイス（より一般的には、コンピューティングデバイス）１０２がそれぞれ、それぞれのＫＭＳ１０４から秘密（またはシークレット）鍵を要求し、獲得する。秘密鍵交換１０６はセキュリティで保護された通信プロトコルによって行われる。セキュリティで保護された通信プロトコルの例には、インターネットプロトコルセキュリティまたはＩＰＳｅｃ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２４０６、ＩＥＴＦ ＲＦＣ２４０９、ＩＥＴＦ ＲＦＣ４３０６、およびＩＥＴＦ ＲＦＣ４３０８を参照）、およびトランスポート層セキュリティまたはＴＬＳ（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ２２４６を参照）が含まれるが、以上には限定されない。汎用ブートストラップアーキテクチャまたはＧＢＡ（例えば、参照により開示が本明細書に組み込まれている、３ＧＰＰ技術仕様（ＴＳ）３３．２２０を参照）が、各関係者とＫＭＳの間のセキュリティで保護された通信プロトコルにおいて使用すべき鍵を決定するのに使用されることが可能である。一例において、ＫＭＳサーバに接続され、さらに事前共有される鍵としてＧＢＡ鍵、またはＧＢＡ鍵と一緒にネットワーク層におけるＩＰＳｅｃを使用する（トランスポート制御プロトコルまたはＴＣＰより上位の）アプリケーション層（例えば、参照により開示が本明細書に組み込まれている、Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ １、Ｔｈｅ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３３４６−９、Ｗ．Ｒｉｃｈａｒｄ ＳｔｅｖｅｎｓおよびＧａｒｙ Ｒ．Ｗｒｉｇｈｔ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ２、Ｔｈｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ、ＩＳＢＮ ０−２０１−６３３５４−Ｘ、Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ、Ｖｏｌｕｍｅ ３、ＴＣＰ ｆｏｒ Ｔｒａｎｓａｃｔｉｏｎｓ，ＨＴＴＰ，ＮＮＴＰ，ａｎｄ ＵＮＩＸ Ｄｏｍａｉｎ Ｐｒｏｔｏｃｏｌｓ、ＩＳＢＮ ０−２０１−６３４９５−３を参照）においてＴＬＳを使用するクライアントデバイスにおいて実行されるアプリケーションが存在することが可能である。
【００５０】
左側のデバイスが開始側（Ｉ）と考えられ、右側のデバイスが応答側（Ｒ）と考えられることに留意されたい。この名称は、左側のデバイスが、右側のデバイスを相手にマルチメディア呼セッションを開始することを求めることに由来する。
【００５１】
図示されるとおり、各デバイスは、そのデバイスの要求と一緒に識別子をＫＭＳに供給し、このことに対して、ＫＭＳは、秘密（シークレット）鍵で応答する。開始側デバイス１０２−Ｉの場合、１つの識別子がＫＭＳ１０４−Ｉに供給され、これに応答して、１つの秘密鍵Ｉ−ＳＫがこのデバイスに供給される。応答側デバイス１０２−Ｒの場合、２つの別々の識別子、すなわち、ＲおよびＲ１が、ＫＭＳ１０４−Ｒに供給される。これに応答して、ＫＭＳは、応答する関係者に、２つの秘密鍵、Ｒ＿ＳＫおよびＲ１＿ＳＫを供給する。もちろん、各関係者は、いくつかの秘密鍵獲得スケジュールに基づいて、より多くの、またはより少ない秘密鍵を要求して、獲得してもよい。このスケジュールは、時間ベースのスケジュール（例えば、１カ月周期）、呼セッション頻度ベースのスケジュール（例えば、呼を行う必要がある場合）、および契約ベースのスケジュール（例えば、関係者は、いくらかの長さの期間にわたって、または契約終了条件が生じたことに基づいて、ＫＭＳの鍵サービスに契約をする）であることが可能である。
【００５２】
また、所与の関係者が複数の公開ＩＤを有する可能性もあることも認識されたい。例えば、関係者Ｂ（「ボブ」）が、以下の２つのＩＤ、すなわち、ｂｏｂ＠ｗｏｒｋ．ｃｏｍおよびｂｏｂ＠ｈｏｍｅ．ｃｏｍを有することが可能である。これら２つのＩＤに関して、異なる２つの公開鍵が存在することが可能であり、このため、異なる２つの秘密鍵が存在することが可能である。
【００５３】
図１Ｂは、セキュリティで保護された鍵管理方法の第２の段階、すなわち、認証された鍵交換を示す。この実施形態において、認証された鍵交換は、ＩＢＡＫＥ（段落Ｉ．Ｂで前述した）に基づく。第１の関係者と第２の関係者の間のメッセージ交換の好ましいフォーマットは、ＭＩＫＥＹ（マルチメディアインターネットキーイング）に基づくので、したがって、図１Ａおよび図１Ｂの全体的なセキュリティで保護された鍵交換プロトコルは、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルと本明細書では呼ばれる。
【００５４】
この場合も、左側のデバイスが、開始する関係者、つまり、開始側１０２−Ｉであり、右側のデバイスが、応答する関係者、つまり、応答側１０２−Ｒであるものと想定される。認証された鍵交換のステップは、ＩＢＡＫＥプロトコルと同様のステップをたどる。
【００５５】
開始側の公開鍵、Ｉ＿ＰＫは、段落Ｉで前述したハッシュ関数を使用することによって計算されるものと想定される。同様に、応答側の公開鍵、Ｒ＿ＰＫも同様に計算される。開始側および応答側の秘密鍵は、それぞれ、Ｉ＿ＳＫおよびＲ＿ＳＫであることを思い起こされたい。つまり、Ｈ１（Ｉｎｉｔｉａｔｏｒ＿ＩＤ）＝Ｉ＿ＰＫ、およびＨ１（Ｒｅｓｐｏｎｄｅｒ＿ＩＤ）＝Ｒ＿ＰＫを、それらの公開鍵に対応する楕円曲線上のそれぞれの点であるものとする。
【００５６】
ａを、開始側１０２−Ｉによって選択された乱数とし、ｂを、応答側１０２−Ｒによって選択された乱数とする。
【００５７】
１０２−Ｉと１０２−Ｒの間のプロトコル交換は、以下のステップを備える：
ステップ１１０で、開始側１０２−Ｉが、第１のランダムな鍵構成要素ａＰ（すなわち、Ｅ上で加算則を使用して、Ｅ上の点としてａ回、自らに加算されたＰ）を計算し、第１のランダムな鍵構成要素を、応答側の公開鍵（Ｒ＿ＰＫ）を使用して暗号化し、さらに暗号化された第１のランダムな鍵構成要素を応答側１０２−Ｒに送信する。このステップで、暗号化とは、前段のサブ段落Ｉ．Ａにおいて説明されるＩＤベースの暗号化を指す。ステップ１１０の暗号化されたメッセージにやはり含められるのが、開始側のＩＤ、および応答側のＩＤ（それぞれ、Ｉ＿ＩＤおよびＲ＿ＩＤ）であることに留意されたい。
【００５８】
この暗号化されたメッセージを受信すると、応答側は、応答側の秘密鍵（図１Ａで獲得された）を使用して、このメッセージを解読し、ａＰを獲得する。その後、ステップ１１２で、応答側は、第２のランダムな鍵構成要素ｂＰを計算し、開始側の公開鍵を使用してペア｛ａＰ，ｂＰ｝を暗号化し、その後、暗号化されたペア｛ａＰ，ｂＰ｝を開始側に送信する。この場合も、ステップ１１２の暗号化されたメッセージは、開始側のＩＤ、および応答側のＩＤ（それぞれ、Ｉ＿ＩＤおよびＲ＿ＩＤ）を含む。
【００５９】
ステップ１１２からのメッセージを受信すると、開始側は、このメッセージを、開始側の秘密鍵（図１Ａで獲得された）を使用して解読し、ｂＰを獲得する。その後、ステップ１１４で、開始側は、応答側の公開鍵を使用してｂＰを暗号化し、暗号化されたｂＰを応答側に送り返す。この場合も、ステップ１１４の暗号化されたメッセージは、開始側のＩＤ、および応答側のＩＤ（それぞれ、Ｉ＿ＩＤおよびＲ＿ＩＤ）を含む。
【００６０】
ステップ１１６で、応答側が、開始側の公開鍵を使用して暗号化された検証メッセージを開始側に送信する。
【００６１】
これを行った後、開始側と応答側の両方が、マルチメディア通信システムのメディアプレーン（アプリケーション層）を介して呼セッション中に互いにセキュリティで保護された通信を行うために使用されるべきセキュリティで保護された呼セッション鍵としてａｂＰを計算する。
【００６２】
開始側１０２−Ｉは、ａをランダムに選択しており、プロトコル交換の第２のステップでｂＰを受信していることに注目されたい。このことは、開始側が、ｂＰを自らにａ回、加算することによってａｂＰを計算することを可能とする。逆に、応答側１０２−Ｒは、ｂをランダムに選択しており、プロトコル交換の第１のステップでａＰを受信している。このことは、応答側が、ａＰを自らにｂ回、加算することによってａｂＰを計算することを可能とする。また、ａは、ランダムであるが、ａＰは、ａについての情報を全く与えないことにも留意されたい。したがって、ａＰは、開始側によって選択されたランダムな秘密に基づく鍵の構成要素であると考えられる。同様に、ｂは、ランダムであるが、ｂＰは、ｂについての情報を全く与えない。このため、ｂＰは、応答側だけに知られているランダムな秘密に基づく鍵の構成要素であると考えられる。
【００６３】
次に図２を参照すると、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張が示されている。この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。この特定の実施形態において、図２は、分岐を示す。分岐は、複数のロケーションへの要求の配信である。分岐は、例えば、応答側が、複数の通信（コンピューティング）デバイスを有して、それらのデバイス上で応答側がマルチメディア呼セッションに参加することができる場合に、行われる可能性がある。分岐の一例は、関係者が卓上電話機、パーソナルコンピュータ（ＰＣ)クライアント、移動ハンドセットを有し、全てがＭＩＫＥＹ−ＩＢＡＫＥプロトコルに参加している場合である。一般に、分岐は、着信する呼が、いくつかの内線を同時に鳴らして呼ぶことを可能にするマルチメディアセッション開始プロトコルのフィーチャである。最初に応答する電話機が、その呼を支配する。
【００６４】
したがって、図２に示されるとおり、応答側には、２つのデバイス１０２−Ｒ１および１０２−Ｒ２が関連付けられている。したがって、図示されるとおり、デバイス１０２−Ｒ１は、公開鍵Ｒ１＿ＰＫと、秘密鍵Ｒ１＿ＳＫとを有する。また、デバイス１０２−Ｒ１は、応答側の公開鍵Ｒ＿ＰＫ、および応答側の秘密鍵Ｒ＿ＳＫを知っている。同様に、デバイス１０２−Ｒ２は、公開鍵Ｒ２＿ＰＫと、秘密鍵Ｒ２＿ＳＫとを有する。また、デバイス１０２−Ｒ２は、応答側の公開鍵Ｒ＿ＰＫ、および応答側の秘密鍵Ｒ＿ＳＫを知っている。
【００６５】
分岐シナリオにおけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ２１０、２１２、２１４、および２１６は、以下を例外として、図１Ｂの一般的な関連におけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ１１０、１１２、１１４、および１１６と基本的に同一である。ステップ２１０でデバイス１０２−Ｉによって送信されるメッセージは、Ｒ＿ＰＫを使用して暗号化されるため、デバイスＲ１とＲ２はともに、このメッセージを解読することができる（デバイスＲ１とＲ２はともに、Ｒ＿ＳＫを有するので）ことに留意されたい。しかし、応答する関係者が、現在、デバイスＲ１ではなく、Ｒ２に関連しているものと想定すると、ステップ２１２における返信メッセージは、ＩＢＡＫＥによりＲ２によって計算されたランダムな鍵構成要素ｂ２Ｐ（ただし、ｂ２は、Ｒ２によって選択された乱数）を含む。また、ステップ２１２における暗号化されたメッセージは、開始側のＩＤ、応答側のＩＤ、およびデバイスＲ２のＩＤ（それぞれ、Ｉ＿ＩＤ、Ｒ＿ＩＤ、およびＲ２＿ＩＤ）を含む。
【００６６】
デバイス１０２−Ｉは、Ｒ２から受信されたメッセージを、デバイス１０２−Ｉの秘密鍵を使用して解読して、このメッセージに含まれるｂ２ＰおよびＩＤを獲得する。このため、開始側は、ステップ２１２におけるメッセージがＲ２から来たことを識別する。ＭＩＫＥＹ−ＩＢＡＫＥプロトコルにより、次に、開始側は、ステップ２１４で、ｂ２Ｐ、Ｉ＿ＩＤ、およびＲ２＿ＩＤを含むメッセージを送信する。このメッセージは、Ｒ２の公開鍵を使用して暗号化される。このメッセージは、Ｒ１がＲ＿ＳＫおよびＲ１＿ＳＫだけを有し、Ｒ２＿ＳＫは有さないので、Ｒ１によって解読され得ないことに留意されたい。ステップ２１６は、図１Ｂのステップ１１６と同様の検証メッセージである。次に、呼セッション鍵が、ａｂ２Ｐとしてデバイス１０２−Ｉおよび１０２−Ｒ２において計算されることが可能である。
【００６７】
図３は、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの、ターゲット変更フィーチャへの拡張を示す。この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。ターゲット変更またはリダイレクトは、通信システムにおける１つまたは複数の機能要素が、異なる宛先に呼をリダイレクトすることを決定するシナリオである。セッションをリダイレクトする、この決定は、いくつかの異なる機能要素によって、セッションの確立における様々な時点で、様々な理由で行われることが可能である。また、ターゲット変更は、着信転送としても知られている。
【００６８】
図３の例は、リダイレクト決定を行うアプリケーションサーバ３０２を示す。分岐シナリオにおけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ３１０、３１２、３１４、および３１６は、以下を例外として、図１Ｂの一般的な関連におけるＭＩＫＥＹ−ＩＢＡＫＥプロトコルステップ１１０、１１２、１１４、および１１６と基本的に同一である。
【００６９】
デバイス１０２−Ｉが、ステップ３１０で、プロトコルにおける最初のメッセージを、このメッセージがデバイス１０２−Ｒ１に向かうことを意図して、送信する（Ｒ１の公開鍵で暗号化されたメッセージ）。しかし、機能要素３０２が、３１０で、このメッセージがデバイスＲ２にリダイレクトされるべきであるという決定を行っている（ステップ３１０’参照）。このことに先立って、またはこのことに関連して、Ｒ２が、この機能要素を経由してステップ３０８で送信されたメッセージの中でＲ１の秘密鍵を受信しているものと想定される。Ｒ１からＲ２に送信されたメッセージは、Ｒ２の公開鍵を使用して暗号化されている。このため、機能要素３０２は、３０８で、このメッセージを解読することができないが、Ｒ２は、３１０’で、このメッセージを解読し、ステップ３１２で開始側に応答することができる。この時点から、ステップ３１２、３１４、および３１６は、図２の分岐シナリオにおけるステップ２１２、２１４、および２１６と同一である。
【００７０】
図４Ａは、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの遅延配信拡張を示す。この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。遅延配信は、セッション内容が、送信されている時点で宛先に配信され得ない（例えば、宛先ユーザが、現在、オンラインではない）ようになっているタイプのサービスである。それでも、送信側は、受信側が応対可能になるとすぐに、ネットワークがそのメッセージを配信するものと予期する。遅延配信の一例が、ボイスメールである。
【００７１】
図４Ａで、Ａが、デバイス１０２−Ｉであり、Ｂが、１０２−Ｒであり、デバイス４０２が、アプリケーションサーバなどの機能要素であり、さらにＭＢが、Ｂに関連するメールボックス１０２−ＭＢ（より一般的には、一時的な宛先）であるものと想定されたい。
【００７２】
ステップ４０１で、Ａが、暗号化された第１のランダムな鍵構成要素（ｘＰ）を備える第１のメッセージをＢに送信する。第１のランダムな鍵構成要素は、Ａにおいて計算されており、さらに第１のメッセージは、Ｂの公開鍵を使用して暗号化されている。ステップ４０２で、機能要素４０２が、Ｂが応対不能であると決定し、第１のメッセージをＭＢに転送する。
【００７３】
ステップ４０３で、ＭＢが、ＭＢによって計算された、暗号化された第２のランダムな鍵構成要素（ｙＰ）を備える第２のメッセージをＡに送信する。ステップ４０３のメッセージは、Ａの公開鍵を使用してＭＢにおいて暗号化されている。ステップ４０４で、機能要素４０２が、このメッセージをＡに転送する。
【００７４】
Ａが、ＭＢからの、このメッセージを、Ａによって鍵サービスから獲得された秘密鍵を使用して解読して、第２のランダムな鍵構成要素を獲得する。Ａが、ステップ４０４で受信されたメッセージがＭＢから来たことを識別する（ＭＢのＩＤが、このメッセージの中に含められていることにより）。
【００７５】
ステップ４０５で、Ａが、暗号化されたランダムな鍵構成要素ペアを含む第３のメッセージを（ステップ４０６で機能要素を介して）ＭＢに送信し、このランダムな鍵構成要素ペアは、第１のランダムな鍵構成要素（ｘＰ）と、第２のランダムな鍵構成要素（ｙＰ）とから形成され、さらにＭＢの公開鍵を使用してＡにおいて暗号化されている。また、この第３のメッセージは、Ａにおいて計算され、Ｂの公開鍵を使用してＡにおいて暗号化された、暗号化されたランダムな秘密鍵（ｓＫ）も含む。ＭＢが、ステップ４０７および４０８を介してＡに受信の確認応答を行う。ＭＢは、メッセージの後半部分を解読することができず（その部分は、Ｂの公開鍵を使用して暗号化されており、ＭＢは、Ｂの秘密鍵を有さないので）、このため、ｓＫを知ることができない。
【００７６】
ＭＢは、ＢとＭＢの間の相互認証動作の後、Ｂによって要求されると、暗号化されたランダムな秘密鍵（ｓＫ）をＢに供給する。このことが、ステップ４０９およびステップ４１０に示される。次に、この秘密鍵が、ＡによってＢのメールボックスの中に残された内容（例えば、音声メッセージ）を獲得するようにＢによって使用される。
【００７７】
図４Ｂに示される、図４Ａの遅延配信の変種において、認証された鍵合意プロトコルが実行されるのではなく、第１のメッセージの中で、Ａが、Ａにおいて計算され、さらにＢの公開鍵を使用してＡにおいて暗号化された、暗号化されたランダムな秘密鍵（ｓＫ）を送信するものと想定されたい（ステップ４１１）。機能要素４０２は、Ｂが応対不能であると決定しており、第１のメッセージをＭＢに転送し（ステップ４１２）、ＭＢが、第１のメッセージを確認する（ステップ４１３および４１４）。後に、Ｂは、前述したのと同一の仕方で、ＭＢから秘密鍵を取り出すことができる（ステップ４１５および４１６）。
【００７８】
図５は、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのさらに別の拡張を示す。この場合も、この拡張は、前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルの拡張であるので、簡明のため、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルのすべてのフィーチャを繰り返すことはしないことを理解されたい。図５の拡張は、マルチメディア通信システムにおいて交換されるメッセージの合法的な傍受の概念と関係する。合法的な傍受の概念は、法執行機関が、１名または複数名の関係者の通信を「盗聴する」ことができる必要がある状況に基づく。
【００７９】
１つのアプローチにおいて、法執行機関は、単に、捜査令状を介して１０２−Ｉおよび１０２−Ｒの秘密鍵を獲得し、鍵合意プロトコル中に能動的な「中間者」の役割をして、トラフィックを盗聴することができる。
【００８０】
図５に示される別のアプローチにおいて、法執行サーバ（ＬＩサーバ）５０２が、開始側のＫＭＳ（ＫＭＳＩ）および応答側のＫＭＳ（ＫＭＳＲ）と一緒に機能して、デバイス１０２−Ｉとデバイス１０２−Ｒの間で送信するメッセージを合法的に傍受する。図５は、ＬＩサーバ、ＫＭＳＩ、およびＫＭＳＲに関して別々のサーバを示すが、マルチメディア通信システムにおける１つの機能要素（例えば、傍受サーバ）が、ＫＭＳ機能および傍受機能を実行するのに使用されてもよいことを認識されたい。
【００８１】
したがって、図１Ａおよび図１Ｂの関連で前述したＭＩＫＥＹ＿ＩＢＡＫＥプロトコルが、実行される。しかし、ＬＩサーバは、応答側に送信されるメッセージに関して開始側を模倣し、開始側に送信されるメッセージに関して応答側を模倣する。
【００８２】
例えば、ＬＩサーバが応答側を模倣する場合のメッセージフローを考慮されたい。１０２−Ｉが、１０２−Ｒによる受信が意図される、暗号化された第１のランダムな鍵構成要素を含む第１のメッセージを送信するものと想定されたい。第１のメッセージが、ＬＩサーバによって傍受される。次に、ＬＩサーバが、第２のランダムな鍵構成要素を計算し、暗号化されたランダムな鍵構成要素ペアを含む第２のメッセージを１０２−Ｉに送信する。ランダムな鍵構成要素ペアは、第１のランダムな鍵構成要素と、ＬＩサーバにおいて計算された第２のランダムな鍵構成要素とから形成される。第２のメッセージは、１０２−Ｉの公開鍵を使用してＬＩサーバにおいて暗号化される。
【００８３】
第２のメッセージは、１０２−Ｉによって鍵サービスから獲得された秘密鍵を使用して解読されて、第２のランダムな鍵構成要素が獲得される。次に、デバイス１０２−Ｉが、１０２−Ｒによる受信が意図されるが、ＬＩサーバによって傍受される、第２のランダムな鍵構成要素を含む第３のメッセージを送信する。このため、ＬＩサーバは、デバイス１０２−Ｉが計算するのと同一のセキュリティで保護された鍵を計算することができる。
【００８４】
ＬＩサーバは、応答側（１０２−Ｒ）が、ＬＩサーバを相手に、開始側によって合意されていると応答側が信じるセキュリティで保護された鍵（しかし、実際には、ＬＩサーバを相手に合意されている）を確立するように、認証された鍵合意動作中にメッセージを送受信する際に、やはり開始側（１０２−Ｉ）を模倣することを理解されたい。
【００８５】
前述したＭＩＫＥＹ−ＩＢＡＫＥプロトコルフィーチャの１つまたは複数は、会議システムシナリオに拡張され得ることを認識されたい。そのような拡張が、図６Ａから図６Ｃに示される。
【００８６】
一般的な想定は、複数関係者の通信を中継する会議サーバ（より一般的には、会議管理要素）（例えば、会議ブリッジ）が、グループ鍵を知らない一方で、すべてのユーザは、同一のグループ鍵にアクセスを有することである。この想定には例外、すなわち、ピアツーピア会議において、会議ブリッジの役割をしているコンピューティングデバイスが、会議に実質的に参加している関係者でもある場合が存在する。
【００８７】
図６Ａに示されるとおり、複数関係者会議６００が、会議サーバと、ユーザ（関係者）１からＮとを含むものと想定され、ただし、このユーザ番号は、ユーザが会議に参加することを求める順序で、すなわち、１、２、３、．．．Ｎの順番に割り当てられる。
【００８８】
ステップ６０２で、各ユーザが個々に、会議サーバを相手にＩＢＡＫＥプロトコルを実行する。Ｚｉ＝ａｉＰを、会議サーバを相手にした認証中にユーザ「Ｉ」によってサーバに送信される値とする。ａｉＰは、ＩＢＡＫＥにより関係者によって計算されたランダムな鍵構成要素であることを思い起こされたい。
【００８９】
認証の成功の後、ステップ６０４で、会議サーバが、集合｛ａｉＰ｝をすべてのユーザに送信する（ブロードキャスト、または個別のユニキャスト）。このため、集合｛ａｉＰ｝は、それらの関係者のそれぞれによって計算されたランダムな鍵構成要素を含む集合である。
【００９０】
ステップ６０６で、すべてのユーザが個々に、会議サーバにＸｉ＝ａｉ｛ａｉ＋１Ｐ−ａｉ−１Ｐ｝を送り返す。ａｉ｛ａｉ＋１Ｐ−ａｉ−１Ｐ｝は、ランダムなグループ鍵構成要素であり、このランダムなグループ鍵構成要素は、鍵認証動作中に関係者によって使用される乱数、および会議に参加することを求めている２名以上の関係者の他のサブセットによって計算されたランダムな鍵構成要素に基づく計算を介して、各関係者によって計算される。この実施形態において、所与の関係者に関するランダムなグループ鍵構成要素ａｉ｛ａｉ＋１Ｐ−ａｉ−１Ｐ｝は、ａｉが、所与の関係者によって選択された乱数であり、ａｉ＋１Ｐが、会議順序付けにおいてその所与の関係者の直後に続く関係者によってサーバに送信されたランダムな鍵構成要素であり、ａｉ−１Ｐが、会議順序付けにおけるその所与の関係者の直前の関係者によってサーバに送信されたランダムな鍵構成要素であり、さらにＰが、ＩＤ暗号化ベースの鍵認証動作に関連するグループから選択された点（例えば、前述した楕円曲線から選択された点）であるように計算される。
【００９１】
ステップ６０８で、会議サーバが、次に、集合｛Ｘｉ｝を全員と共有する（ブロードキャスト、または個別のユニキャスト）。つまり、集合｛Ｘｉ｝は、それらの関係者によって計算されたランダムなグループ鍵構成要素を含む集合である。
【００９２】
ステップ６１０で、各関係者は、会議サーバを介して関係者が互いに通信する際に使用するための同一のグループ鍵を計算することができる。このグループ鍵は、以下のとおり計算される。Ｎａｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋．．．Ｘｉ−２、ただし、Ｎは、会議に参加することを求める関係者の総数を表し、ａｉは、所与の関係者によって選択された乱数を表し、Ｚｉは、所与の関係者によって計算されるランダムな鍵構成要素を表し、Ｘｉは、所与の関係者によって計算されるランダムなグループ鍵構成要素を表し、さらにｉは、Ｎ名の関係者の会議における所与の関係者に関する会議順序付けの番号であり、ｉ＝１の場合、ｉ−１＝Ｎであり、ｉ＝Ｎである場合、ｉ＋１＝１である。
【００９３】
前述したとおり、会議サーバは、会議における参加する関係者ではなく、そのため、グループ鍵を計算することができない。しかし、ピアツーピアシナリオにおいて、会議サーバは、会議呼における参加する関係者であり、そのため、グループ鍵を計算することができる必要がある。
【００９４】
会議サーバは、会議に参加することを求める各関係者を相手に相互認証動作を実行するものと理解される。また、会議サーバは、以下の少なくとも２つの条件：（ｉ）所与の関係者が、会議管理要素によって認証される、および（ｉｉ）所与の関係者が、会議許可リストに属することが確認されるという条件が満たされた場合に限って、所与の関係者を会議に受け入れる。また、前述のＭＩＫＥＹ−ＩＢＡＫＥプロトコルによれば、会議に参加することを求める関係者、および会議サーバは、１つまたは複数のＫＭＳ（鍵管理サービス）からそれぞれの秘密鍵を獲得する。
【００９５】
図６Ｂは、新たな会議参加者（ユーザＮ＋１）がどのように、進行中の会議に追加されて、変更された会議６００’をもたらすかを示す。
【００９６】
ステップ６１２で、ユーザＮ＋１が、会議サーバを相手にＩＢＡＫＥを実行する。ＺＮ＋１＝ａＮ＋１Ｐを、サーバを相手にした認証中にユーザ「Ｎ＋１」によってサーバに送信される値とする。ユーザＮ＋１の認証成功の後、ステップ６１４で、会議サーバが、新たなユーザＮ＋１の受入れを告知し、ＺＮ＋１を含む集合｛ａｉＰ｝を、全員に送信する（ブロードキャスト、または個別のユニキャスト）。
【００９７】
ステップ６１６で、ユーザ１、Ｎ、Ｎ＋１が、サーバにＸｉ＝ａｉ（ａＮ＋１Ｐ−ａＮ−１Ｐ｝を送り返し、代替として、ユーザのすべてが、このステップを実行することも可能である。次に、ステップ６１８で、会議サーバが、ＸＮ＋１を含む集合｛Ｘｉ｝を、全員と共有する（ブロードキャスト、または個別のユニキャスト）。次に、ステップ６２０で、グループ鍵（Ｎ＋１）ａｉ（Ｚｉ−１）＋（Ｎ）Ｘｉ＋（Ｎ−１）Ｘｉ＋１＋．．．Ｘｉ−２が再計算される。グループ鍵は、その新たなユーザが受け入れられた後に変化することに注目されたい。
【００９８】
図６Ｃは、会議参加者がどのように、進行中の会議を抜けて、変更された会議６００”をもたらすかを示す。
【００９９】
ユーザ３が、その呼を抜けるものと想定されたい（ユーザ３の選択は、単に例に過ぎないことを理解されたい）。ステップ６２２で、会議サーバが、いずれのユーザが呼を抜けたかを告知する（ブロードキャスト、または個別のユニキャスト）。ステップ６２４で、ユーザ順序付けが変化する。ユーザ１および２は、そのままである。ユーザｉは、４以上のすべてのｉに関して、ユーザｉ−１になる。ステップ６２６で、ユーザ４（現時点で、ユーザ３である）が、Ｘｉを再計算し、この寄与を会議サーバと共有する。ステップ６２８で、会議が、集合｛Ｘｉ｝をすべての参加者と共有する。ステップ６３０で、それらの参加者が、グループ鍵（Ｎ−１）ａｉ（Ｚｉ−１）＋（Ｎ−２）Ｘｉ＋（Ｎ−３）Ｘｉ＋１＋．．．Ｘｉ−２を再計算する。この場合も、グループ鍵は、参加者が呼を抜けた後に変化することに注目されたい。
【０１００】
本発明の原理は、前述した会議管理技術の拡張も提供する。この拡張には、会議メッセージの合法的な傍受がかかわる。
【０１０１】
会議システムにＮ名の参加者が存在するものと想定されたい。参加者Ｎが、「嫌疑がかけられ」ており、法執行機間が、参加者Ｎへの呼、および参加者Ｎからの呼を盗聴する令状を獲得している。参加者Ｎを嫌疑がかけられていると宣言することの選択は、例示に過ぎず、説明を追うことをより容易にし、このソリューションは、第Ｎ番のユーザを嫌疑がかけられたユーザと宣言することに全く限定するものではない。
【０１０２】
会議呼に先立って、ＬＩサーバ（図５で思い起こされたい）が、参加者Ｎに対応するＫＭＳにアプローチし、参加者Ｎの秘密鍵を獲得する。このことは、ＬＩサーバが、グループ鍵交換プロセス中に参加者Ｎのふりをして、図６Ａのすべてのステップを実行するが、ただし、参加者Ｎの寄与は、ＬＩサーバからの寄与で置き換えられていることを可能とする。詳細には、ＬＩサーバは、ＺＮおよびＸＮの代わりにＺＬＩおよびＸＬＩを代用する。残りの参加者は、この違いを知らず、グループ鍵を計算して、その鍵をＧＫ’と呼ぶ。
【０１０３】
次に、ＬＩサーバが、会議サーバと協働し、参加者Ｎとのすべての通信においてＺ１およびＸ１をＺＬＩおよびＸＬＩで置き換える。このことは、参加者Ｎが、ＧＫ’とは異なるグループ鍵を計算することを暗示する。この新たな鍵をＧＫ”と呼ぶ。
【０１０４】
前述のステップで、ＬＩサーバは、任意の参加者に関してＺｉおよびＸｉをＺＬＩおよびＸＬＩで置き換えることが可能であったこと、およびｉ＝１の選択は例示に過ぎないことに留意されたい。
【０１０５】
呼がセットアップされた後、参加者１ないしＮ−１からのいずれの通信も、ＧＫ’を使用して暗号化される。ＬＩサーバは、ＧＫ’を知っているので、ＬＩサーバは、次に、その通信を傍受し、その通信を解読し、その後、その通信を、ＧＫ”を使用して再暗号化して、参加者Ｎに送信することができる。逆に、ＬＩサーバによって傍受される、参加者Ｎからのいずれの通信も、ＧＫ”を使用して暗号化され、その後、ＧＫ”を使用して解読され、ＧＫ’を使用して再暗号化され、さらに参加者１ないしＮ−１に送信する。
【０１０６】
ＩＩＩ．ＩＭＳ実施形態
以下の段落において、ＭＩＫＥＹ＿ＩＢＡＫＥの前述した一般的な原理、およびそれらの原理の拡張が、ＩＭＳ（ＩＰマルチメディアサブシステム）環境に適用される。つまり、この段落におけるマルチメディア通信システムは、ＩＭＳネットワークであると考えられる。ＩＭＳ標準は、参照により開示が本明細書に組み込まれている、３ＧＰＰ技術仕様、ＴＳ２３．２１８、ＴＳ２３．２２８、ＴＳ２４．２２８、ＴＳ２４．２２９、およびＴＳ２４．９３０において説明されている。
【０１０７】
ＩＭＳメディアプレーンセキュリティに関する、特に、鍵管理に関するアーキテクチャの枠組みをまず説明することとし、この枠組みに基づいて、様々なフィーチャおよび使用事例が導き出されることが可能である。
【０１０８】
このソリューションの中核にあるのは、参照により開示が本明細書に組み込まれている、ＲＦＣ５０９１、ＲＦＣ５４０８、およびＲＦＣ５４０９と同様の、ＩＢＥ（ＩＤベースの暗号化）概念である。
【０１０９】
しかし、これらのＲＦＣは、認証を提供せず、特有の鍵供託問題に悩まされている。我々は、相互認証を提供し、受動的な鍵供託を解消し、鍵の完全な秘密をもたらす（ＩＤベースの認証された鍵交換（ＩＢＡＫＥ）プロトコルを含むように基本的なＩＢＥを拡張することによって、これらの問題に対処する。ＩＢＡＫＥが基本的なプロトコル構造であるが、我々は、鍵配信のためのプロトコルコンテナとしてＭＩＫＥＹを使用する。
【０１１０】
本発明のＩＭＳソリューションの枠組みについての１つの基本的な考え方は、我々は、ＫＭＳを含む、提案されるアーキテクチャを再使用するが、とりわけ、我々は、これらのＫＭＳサーバが常にオンラインであることを必要としないことである。つまり、提案される枠組みにおいて、ＫＭＳは、定期的に（例えば、１カ月に１回）エンドユーザクライアントと通信して、セキュリティで保護されたＩＤベースの暗号化の枠組みを作成するオフラインサーバである一方で、エンドユーザクライアント間のオンライントランザクションは（メディアプレーンセキュリティのために）、参加するクライアントが、非対称ＩＤベースの暗号化の枠組みにおいて鍵構成要素を交換することを可能とするＩＢＡＫＥの枠組みに基づく。この枠組みは、受動的な供託を解消することに加えて、エンドユーザクライアントが、（ＩＭＳメディアプレーン層において）互いを相互に認証することを可能とし、完全な順方向の秘密および逆方向の秘密をもたらす。
【０１１１】
ＫＭＳ−クライアント間の交換は、控えめに（例えば、１カ月に１回）使用され、このため、ＫＭＳはもはや、高度に応対可能であるサーバであることを要求されず、特に、異なるＫＭＳが（事業者境界をまたいで）互いに通信しなくてもよい。さらに、非対称ＩＤベースの暗号化の枠組みが使用されることから、高価な公開鍵インフラストラクチャ（ＰＫＩ）、ならびに証明書管理および取消しのすべての運用上の費用が解消される。さらに、様々なＩＭＳメディアプレーンフィーチャが、セキュリティで保護されてサポートされ、このことには、セキュリティで保護された分岐、ターゲット変更、遅延配信、事前符号化された内容、メディアクリッピング、および匿名性が含まれる。
【０１１２】
このソリューションの拡張は、ＩＭＳ会議アプリケーションサーバがユーザを認証して、呼に受け入れるが、その呼のすべての参加者が、グループ鍵を決定する（全員からの寄与を使用して）一方で、会議サーバ自体は、そのグループ鍵を知ることがない、セキュリティで保護された会議アプリケーションを可能にする。さらに、そのグループ鍵は、新たな参加者、および呼を抜ける参加者を考慮に入れるように変更され得る。ＩＭＳベースの鍵管理の枠組みのさらなるフィーチャは、受動的な鍵供託の解消にもかかわらず、この枠組みが、能動的な供託の概念を使用して、法執行とセキュリティ資格証明を合法的に共有することをサポートする。
【０１１３】
図７は、このアーキテクチャの概略を、ＩＭＳメディアプレーンにおける例示的な終端間鍵交換プロトコルに関与するエンティティと一緒に提示する。ＩＭＳアーキテクチャは、よく知られているので、図７に示される機能上の構成要素は、詳細には説明されないものと理解される。それらの構成要素の機能の詳細な説明については、ＩＭＳ標準を参照することが可能である。知られているとおり、ＣＳＣＦとは、呼セッション制御機能であり、ただし、Ｐ−ＣＳＣＦは、プロキシＣＳＣＦであり、Ｓ−ＣＳＣＦは、サービングＣＳＣＦであることに留意されたい。ＮＡＦとは、ネットワークアプリケーション機能を指す。
【０１１４】
例示されるシナリオにおいて、２つのＩＭＳ対応のエンドユーザ電話機が、アプリケーション層において通信をセキュリティで保護するようにｅ２ｅ（終端間）鍵交換を行っている。この例示は、ＵＥ（ユーザ機器）とＫＭＳの間のオフライントランザクション、ならびにＩＭＳを介するＵＥ間のオンライントランザクションを含むことに留意されたい。
【０１１５】
ＵＥとＫＭＳは、ユーザが、鍵管理サーバを相手にセキュリティで保護された接続を確立することができ、さらに相互認証が提供される、事前構成されたセキュリティ関連付けを共有することに注目されたい。３ＧＰＰシステムにおける１つの自然な例が、汎用化されたブートストラップアーキテクチャの使用である（例えば、参照により開示が本明細書に組み込まれている、３ＧＰＰ ＴＳ３３．２２０を参照）。図７で、ＫＭＳとＵＥの間のトランザクションは、ＢＳＦ（ブートストラップサーバ機能）を介して可能にされ、さらに、このトランザクションは、控えめに（例えば、１カ月に１回）実行されることを思い起こされたい。ＧＢＡが応対不能である場合、事前共有される鍵または証明書を有するＩＫＥｖ２（例えば、参照により開示が本明細書に組み込まれている、ＩＥＴＦ ＲＦＣ４３０６を参照）などの他のタイプの資格証明が、ユーザとＫＭＳの間で、この相互認証を確立するために使用されることが可能であることに留意されたい。
【０１１６】
このトランザクション中、ＵＥは、ＵＥの契約資格証明を提示し、この後に、ＫＭＳが、秘密鍵のセットを生成する（ＩＢＡＫＥにおいて使用される）。このトランザクションは、１カ月に１回、実行され、次に、ＫＭＳが、１日毎に１つの鍵を生成することを選択することが可能である。鍵の数、およびこの交換の頻度は、ポリシーの問題であり、契約に結び付けられることが可能である。この柔軟性は、前払いの顧客に関して特に有用である。
【０１１７】
単一のＫＭＳではなく、ユーザＡに関して１つ、すなわち、ＫＭＳ＿Ａ、およびユーザＢに関して１つ、すなわち、ＫＭＳ＿Ｂという異なる２つのＫＭＳが関与することも可能である。しかし、ＫＭＳ＿ＡとＫＭＳ＿Ｂは、互いに通信しなくてもよい。このシナリオは、事業者間のシナリオにおいて特に適用可能である。
【０１１８】
次に、ＩＭＳのコンテキストにおいてＭＩＫＥＹ−ＩＢＡＫＥにかかわる交換の簡単な要約を与える。
【０１１９】
Ａ、Ｂが、鍵を認証し、鍵について合意しようと試みている２名のユーザであるものと想定されたい。同時に、ＡおよびＢは、Ａに対応するＩＤ、およびＢに対応するＩＤも表し、これらのＩＤは、定義により、Ａの公開鍵、およびＢの公開鍵も表す。Ｈ１（Ａ）＝ＱＡおよびＨ１（Ｂ）＝ＱＢを、それらの公開鍵に対応する楕円曲線上のそれぞれの点であるものとする。実際、それらのＩＤと、Ｈ１を適用することによって獲得される曲線上の点との間に１対１対応が存在するので、ＱＡおよびＱＢを公開鍵と呼ぶことも可能である。ｘを、Ａによって選択された乱数とし、ｙを、Ｂによって選択された乱数とする。以降、暗号化とは、段落Ｉで前述したとおり、ＩＤベースの暗号化を指す。
【０１２０】
ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥプロトコル交換は、以下のステップを含む（図７に示される構成要素に関連する）：
１．ユーザＡに属するＩＭＳ ＵＥが、ＮＡＦの役割をするＫＭＳを相手にセキュリティで保護された接続を確立することができるようにＢＳＦを使用してブートストラップを行う。このことは、ＢＳＦがユーザを認証することを可能とし、さらにユーザがＫＭＳを間接的に認証することを可能とする。ＧＢＡが使用され得ない場合、ＩＭＳ ＵＥは、ＫＭＳに接続して、認証を行い、さらに事前確立されたセキュリティ関連付けに基づいて、共有される鍵を確立する。
【０１２１】
２．ＩＭＳ ＵＥが、ＫＭＳを相手にＭＩＫＥＹ交換に従事し、秘密鍵（または、例えば、１日につき１つの、複数の秘密鍵）を要求する。
【０１２２】
３．ＫＭＳが、ユーザＡのＩＭＳ ＵＥに関するメディア秘密鍵を生成し、このメディア秘密鍵をユーザＡに送信する。
【０１２３】
４．ユーザＡのＩＭＳ ＵＥが、ｘＰ（すなわち、Ｅ上で加算則を使用して、Ｅ上の点としてｘ回、自らに加算されたＰ）を計算し、Ｂの公開鍵を使用してｘＰを暗号化し、暗号化されたｘＰをユーザＢのＩＭＳ ＵＥに送信する。
【０１２４】
５．ＩＭＳコアが、ＩＮＶＩＴＥを検出し、ネットワーク機能が、許可される場合、セッション鍵にアクセスを得ることができるようにＩＮＶＩＴＥを扱う。このステップは、合法的な傍受要件を満たすのに必要とされる能動的な供託フィーチャをサポートするようにだけ適用可能である。
【０１２５】
６．ユーザＢのＩＭＳ ＵＥが、暗号化されたｘＰを含むＩＮＶＩＴＥを受信する。ユーザＢのＩＭＳ ＵＥが、そのメッセージを解読し、ｘＰを獲得する。その後、Ｂが、ｙＰを計算し、ユーザＡのＩＭＳ ＵＥの公開鍵を使用してペア｛ｘＰ，ｙＰ｝を暗号化し、次に、暗号化されたペア｛ｘＰ，ｙＰ｝を応答メッセージの中でＡに送信する。
【０１２６】
７．このメッセージを受信すると、ユーザＡのＩＭＳ ＵＥが、このメッセージを解読し、ｙＰを獲得する。その後、ユーザＡのＩＭＳ ＵＥが、Ｂの公開鍵を使用してｙＰを暗号化し、暗号化されたｙＰを、応答確認メッセージの中でＢに送り返す。以上の後に、ＡとＢがともに、セッション鍵としてｘｙＰを計算する。
【０１２７】
８．この時点で、ユーザＢのＩＭＳ ＵＥが、メディアセキュリティの招待および使用を受け入れる。
【０１２８】
Ａは、ｘをランダムに選択しており、プロトコル交換の第２のステップでｙＰを受信していることに注目されたい。このことは、Ａが、ｙＰ自らをｘ回、加算することによってｘｙＰを計算することを可能とする。逆に、Ｂは、ｙをランダムに選択しており、プロトコル交換の第１のステップでｘＰを受信している。このことは、Ｂが、ｘＰ自らをｙ回、加算することによってｘｙＰを計算することを可能とする。
【０１２９】
ＭＩＫＥＹ−ＩＢＡＫＥプロトコルから生じるいくつかの有利な特性は、以下のとおりである。
【０１３０】
相互認証。ステップ４および７のペイロードの内容は、Ｂの公開鍵を使用して暗号化されていることに注目されたい。このため、Ｂだけが、これらのメッセージを解読することができる。同様に、ステップ６のメッセージの内容は、Ａによってしか解読され得ない。また、ステップ６および７は、ＢとＡが互いを認証する（メッセージが正しく解読されたことを証明することによって）ことを可能とすることにも注目されたい。この新奇な特徴は、ＡおよびＢが、オンラインサーバまたは証明機関の助けを借りることなしに、互いを相互に認証することを可能にする。
【０１３１】
完全な秘密。ｘおよびｙは、ランダムであることに注目されたい。このため、セッション鍵ｘｙＰは、新規であり、過去または将来のトランザクションと全く関係を有さない。
【０１３２】
受動的な供託の解消。ＫＭＳ（またはＫＭＳのペア）は、交換におけるメッセージを解読することができるが、ｘＰおよびｙＰを所与として、ｘｙＰを算出するのは困難であることに注目されたい。困難さの想定は、楕円曲線上のディフィ−ヘルマン問題に依拠する。また、ＩＢＥのために使用される曲線は、ＫＭＳ特有であり、さらに、セッション鍵を生成するのに使用される曲線と同一でなくてもよいことに留意されたい。この柔軟性は、多数の選択肢を提供し、さらにＫＭＳの間で必要とされる調整も解消する。
【０１３３】
ＩＤ管理。前述したとおり、メッセージを暗号化するのに、送信者は、受信者のＩＤ（または複数のＩＤのうち１つ）を使用して生成された、受信者の公開鍵を使用する。受信者のＩＤは、特定のユーザ、グループのユーザ、または任意のユーザを特定するフォーマットになっていることが可能である。ユーザおよびユーザグループの命名は、通常のＩＭＳ慣行に従うことが可能であり、ワイルドカードを使用して拡張されることが可能である。グループアプリケーションがかかわるいくつかのシナリオにおいて、グループ内のすべての受信者が、その特定のユーザグループのＩＤに対応する秘密鍵を使用することを可能とするポリシーを有することが自然であり得る。例えば、企業ユーザに関して、デフォルトとして、企業のＩＤに対応する秘密鍵がすべての企業ユーザに配信されることが自然であり得る。ＩＤベースの暗号化のこれらの特性のため、或るグループに属するすべてのユーザが、場合により、そのグループの秘密鍵を有するものの、それでも、すべてのユーザは、送信者と、その同一のグループに属する他の何らかのユーザの間で確立されたセッション鍵を獲得することができないことに留意されたい。また、ポリシーが執行されることを確実にするのに、公開ユーザＩＤが、ＩＭＳ ＵＥにセキュリティで保護されて結び付けられることが可能であることも必要である。つまり、ＫＭＳに対して認証するのにユーザによって使用されるＩＤが、公開ＩＤ（のセット）であることが重要である。
【０１３４】
次に、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルの、様々なＩＭＳベースの使用事例シナリオへの拡張を説明する。これらの拡張は、概ね、段落ＩＩで説明されていることに留意されたい。以下の説明は、ＩＭＳ環境の関連において行われる。
【０１３５】
Ａ．能動的な供託を介する合法的な傍受（ＬＩ）
傍受された通信の明瞭なコピーを供給することができるのに、以下の条件が満たされなければならない：
１．トラフィック（シグナリングとメディアの両方）を傍受することが可能でなければならない。
２．実際のトラフィック保護のために使用されるセッション鍵が、利用可能でなければならない。セッション鍵を利用可能にするのに、ＫＭＳ機能／サービスが要求される。
【０１３６】
前述したとおり、トラフィック保護のためにしようされる実際のセッション鍵は、送信者と受信者の間で生成され、このため、ＫＭＳによって知られていない。したがって、能動的な供託ソリューションが必要とされる。このシナリオにおいて、ＫＭＳが、ユーザＡとユーザＢの間のセッション鍵を獲得するのに、ＫＭＳは、ＫＭＳとユーザＡの間でアクティブセッション鍵を確立する必要があり、さらにＫＭＳとユーザＢの間で別の同時の、アクティブセッションを確立する必要がある。ＫＭＳは、Ａに向けてＢのふりをし、Ｂに向けてＡのふりをする。ＫＭＳによって果たされる、この「中間者」の役割は、能動的な供託と呼ばれ、証明機関が「偽の証明書」を生成し、交換の中間に座るＰＫＩ環境において使用される方法に類似する。従来のＣＡにおいて使用される技術と、能動的な供託の我々のアプローチの違いは、ＫＭＳが、偽の鍵を生成しなくてもよいことである。
【０１３７】
シグナリングトラフィックは、ホームネットワーク経由でルーティングされており、ホームネットワークにおけるシグナリングトラフィックの傍受は、ＳＩＰ（セッション開始プロトコル）サーバにおいて行われることが可能である。次に、このシグナリングトラフィックが、適切なＫＭＳに向けて、このＫＭＳが、対応するユーザを相手に必要とされるセッション鍵を確立するようにルーティングされる必要がある。ローミング状況において、ＳＩＰシグナリングトラフィックは、通常、ＩＭＳ ＵＥとＰ−ＣＳＣＦの間で機密性が保護されているので、さらに現行の展開において、Ｐ−ＣＳＣＦがホームネットワーク内に配置されることを考慮すると、ＳＩＰシグナリングは、移動先ネットワークにおけるベアラレベルで、暗号化されたフォーマットでしか利用可能でない。
【０１３８】
ローミングシナリオの場合、暗号化されたＳＩＰシグナリングおよび内容は、常に利用可能であるが、ＳＩＰシグナリングを傍受し、通信の内容を解読するために、移動先ネットワークと、ＫＭＳを扱うエンティティとの間で相互運用性合意が存在しなければならない。通常、ＫＭＳは、ホームネットワーク内に存在し、したがって、移動先ネットワークによって実行されるＬＩのために、ホームネットワークとの協力が必要とされる。
【０１３９】
ＬＩ標準に沿って、ＶＰＬＭＮ（移動先公衆陸上モバイルネットワーク）が暗号化に関与していない場合、暗号化された内容だけしか、ＶＰＬＭＮにおけるＬＩのために利用可能でない。
【０１４０】
Ｂ．異なるＫＭＳドメインにおけるユーザ
異なるＫＭＳドメインにおけるユーザは、異なるＫＭＳによって生成されたユーザの秘密鍵を有する。その結果、異なるセットの公開パラメータ（例えば、暗号法上の材料）が、異なるＫＭＳドメインにおけるユーザに関する公開鍵および秘密鍵を生成するのに使用され得る。適切な暗号化／解読を確実にするのに、送信者と受信者は、それぞれの側によって使用される正確な公開パラメータを知る必要がある。それでも、１つのＫＭＳドメインにおけるユーザが、別のＫＭＳドメインにおけるユーザに対してセキュリティで保護された呼を確立する必要がある場合、関与するＫＭＳは、協力しなくてもよい。いずれのＩＤベースの暗号プロトコルの場合とも同様に、さらに言えば、いずれの公開鍵プロトコルの場合とも同様に、我々は、交換のために必要とされる公開パラメータが、公開で利用可能である、または交換されるものと想定して支障ない。
【０１４１】
Ｃ．終端−中間間シナリオ
終端−中間間シナリオにおいて、メディア保護は、ＩＭＳ ＵＥとネットワークエンティティの間で行われる。ＩＭＳ ＵＥから呼が開始されるシナリオにおいて、呼のセットアップは、終端間保護された呼の場合と同一の原理に従う。開始するＩＭＳ ＵＥは、ネットワークエンティティ（例えば、ＭＧＷＣ、つまり、メディアゲートウェイコントロール）のＩＤを使用して、前述したとおりｘＰを暗号化し、暗号化されたｘＰをＩＮＶＩＴＥと一緒に送信する。ＭＧＷＣが、メッセージを傍受し、受信するＩＭＳ ＵＥが行うのと同じ仕方でｙＰを生成する。次に、ＭＧＷＣは、ＩＭＳ ＵＥに向けてメディアセキュリティを有するようにＭＧＷをセットアップする。メディアトラフィックは、ＰＳＴＮ（公衆交換電話網）において平文で転送される。
【０１４２】
ＩＭＳ ＵＥに対する着信する呼の場合、ＭＧＷＣは、意図される受信者のために登録された少なくとも１つの端末装置が、メディアセキュリティ能力および選好を登録していることを確認する。メディア保護対応の端末装置が存在しない場合、その呼は、平文で転送される。存在する場合、ＭＧＷＣは、ｙを選択し、ｙＰを生成する。次に、ＭＧＷＣは、（ＩＭＳ ＵＥのＩＤを使用して）暗号化されたｙＰをＩＮＶＩＴＥの中に挿入し、ＭＧＷにおけるメディアセキュリティの使用を、ＭＧＷとＩＭＳ端末装置の間のメディアトラフィック上で開始する。
【０１４３】
Ｄ．鍵分岐
この段落では、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関して分岐が説明される。分岐は、概ね、図２の関連において前段で説明されていることを思い起こされたい。分岐は、複数のロケーションへの要求（例えば、ＩＮＶＩＴＥメッセージ）の配信である。このことは、単一のＩＭＳユーザが複数回、登録されている場合に生じる。分岐の例が、ユーザが、ディスク電話機、ＰＣクライアント、およびモバイルハンドセットをすべて、同一の公開ＩＤで登録している場合である。
【０１４４】
後段で説明され、図８のステップ１から８の関連において示される例において、ユーザＢのＩＭＳ ＵＥが、単一の公開ユーザＩＤ Ｂで複数の連絡先アドレスを登録しているものと想定されたい。つまり、Ｂ１とＢ２がともに、公開ＩＤ Ｂに対応する秘密鍵を獲得する。この事例において、ユーザＡのＩＭＳ ＵＥが、ユーザＢのＩＭＳ ＵＥと連絡をとることを所望する場合、要求は、Ｂ１とＢ２の両方に配信される。Ｂ２が呼に応答するものと想定すると、Ｂ２はまず、ＩＤ Ｂに関連する秘密鍵を使用して受信されたメッセージを解読する。次に、Ｂ２は、ｙをランダムに選択し、Ａの公開ＩＤを使用して暗号化された、ｙＰと、Ｂ２のＩＤ Ｂ２とを含むメッセージをＡに送信する。このメッセージを受信すると、ユーザＡは、このメッセージを解読し、ユーザＢ２を相手に通信していることを認識し、さらにＢ２の公開ＩＤを使用して暗号化された、受信されたｙＰを含む応答確認メッセージを送信する。
【０１４５】
Ｂ１は、Ｂの公開ＩＤを使用して暗号化された、ユーザＡから受信されたメッセージを解読することができ、したがって、ｘＰを獲得することができることに注目されたい。しかし、Ｂ１は、Ｂ２から送信されたメッセージを解読することは、そのメッセージが、ＡのＩＤを使用して暗号化されているので、できない。このため、ユーザＢ１は、ｙＰを獲得することができない。また、Ｂ１がｙＰを獲得することができる場合でさえ、Ｂ１は、それでも、ｘｙＰを計算することができないことにも留意されたい。図７で、（Ｍ）＿Ｘは、メッセージＭが、ＸのＩＤを使用して暗号化されていることを表すことに留意されたい。
【０１４６】
Ｅ．リダイレクト
この段落では、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関してセッションリダイレクト（ターゲット変更）が説明される。リダイレクトは、概ね、図３の関連において前段で説明されていることを思い起こされたい。セッションリダイレクトは、機能要素が、呼を異なる宛先にリダイレクトすることを決定するシナリオである。セッションリダイレクトは、「無条件セッション転送」、「話中セッション転送」、「可変セッション転送」、「選択的セッション転送」、および「応答なしセッション転送」という通常のサービスを可能にする。
【０１４７】
セッションリダイレクトの２つの基本的なシナリオが存在する。シナリオ１では、基本要素（例えば、Ｓ−ＣＳＣＦ）が、ＳＩＰ ＲＥＤＩＲＥＣＴ方法を使用してセッションをリダイレクトすることを決定する。つまり、機能要素は、新たな宛先情報を発信元に送信する。その結果、発信元は、機能要素によって与えられた、リダイレクトされる宛先に対して新たなセッションを開始する。ＭＩＫＥＹ−ＩＢＡＫＥの事例の場合、このことは、発信元が、リダイレクトされる宛先のＩＤを使用して新たなセッションを開始することを意味する。
【０１４８】
第２のシナリオでは、機能要素は、発信元に知らせることなしに、セッションをリダイレクトすることを決定する。一般的なシナリオは、宛先ユーザのＳ−ＣＳＣＦが、セッションがリダイレクトされるべきことを決定するシナリオである。登録中に「Ｃｘプル」によってＨＳＳ（ホーム契約者サーバ）から獲得されるユーザプロファイル情報は、セッションリダイレクトをもたらす複雑なロジックおよびトリガを含むことが可能である。
【０１４９】
図９のステップ１から８に示される例において、一般性を失うことなしに、ユーザＢは、ユーザＣに対するセッション転送をセットアップするものと想定される。この事例において、ユーザＢは、ユーザＢのユーザプロファイルの中に、ＣのＩＤを使用して暗号化されたユーザＢの秘密鍵ＳＫ＿Ｂを含める。したがって、Ｓ−ＣＳＣＦが、ユーザＡからメッセージを受信し、そのメッセージがリダイレクトされる必要があると決定すると、Ｓ−ＣＳＣＦは、ユーザＣにリダイレクトされるメッセージの中にＢの暗号化された鍵を含める。このメッセージを受信すると、ユーザＣは、その秘密鍵を暗号化し、次に、Ａからのメッセージを暗号化する。次に、ユーザＣは、ランダムなｙを選択し、Ａの公開ＩＤを使用して暗号化された、ｙＰと、ＣのＩＤ Ｃとを含むメッセージをＡに送信する。このメッセージを受信すると、ユーザＡは、このメッセージを解読し、ユーザＣを相手に通信していることを認識し、さらにＣの公開ＩＤを使用して暗号化された、受信されたｙＰを含む応答確認メッセージを送信する。図９で、（Ｍ）＿Ｘは、メッセージＭが、ＸのＩＤを使用して暗号化されていることを表す。
【０１５０】
Ｆ．遅延配信
この段落では、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関して遅延配信が説明される。段落ＩＩから、遅延配信は、セッション内容が、送信された時点で宛先に配信され得ない（例えば、宛先ユーザが、現在、オンラインでない、またはその呼に応答しないことを決定する）ようなタイプのサービスであることを思い起こされたい。それでも、送信者は、受信者が応対可能になるとすぐに、ネットワークがそのメッセージを配信するものと予期する。遅延配信の典型的な例が、ボイスメールである。
【０１５１】
以下に、ＩＭＳベースのＭＩＫＥＹ−ＩＢＡＫＥの事例に関する遅延配信の２つの基本的なシナリオが提示される。第１のシナリオに関して図４Ａが参照されることが可能であり、第２のシナリオに関して図４Ｂが参照されることが可能である。
【０１５２】
第１のシナリオでは、ユーザＡのメールボックスとＢのメールボックスが、遅延配信が意図されるメッセージの内容を解読するために使用されるべき鍵について合意するのに先立って、相互認証を実行するのに対して、第２のシナリオでは、相互認証は、実行されない。
【０１５３】
第１のシナリオ（やはり、機能要素４０２がＩＭＳサーバである図４Ａを再び参照することが可能である）では、ユーザＡが、現在、応対可能でないユーザＢと連絡をとろうと試みており、したがって、その呼は、Ｂの「ボイスメール」（より一般的には、遅延配信サーバ）に転送されるものと想定される。ＭＩＫＥＹ−ＩＢＡＫＥプロトコルに従って、Ｂのメールボックスによって受信されたメッセージは、ＢのＩＤを使用して暗号化されており、したがって、Ｂのメールボックスは、そのメッセージを解読することができない。Ｂのメールボックスは、ランダムなｙを選択し、ｙＰを計算し、さらに、ＩＢＥ暗号化された、ＢのメールボックスのＩＤおよびｙＰをユーザＡに送信する。ユーザＡは、Ｂがそのメッセージを受信しなかったこと、および実際の受信者が、その受信者のＩＤ、およびｘＰを欠いているために、第１のステップで送信されたメッセージを解読することができなかったことを認識する。したがって、ユーザは、ＢのメールボックスＩＤを使用してすべてＩＢＥ暗号化された、ＡのＩＤ、ＢのメールボックスのＩＤ、ｘＰ、およびｙＰを含む新たなメッセージを送信する。このメッセージを受信すると、Ｂのメールボックスは、Ｂに向けられたメッセージのためのセッション鍵として「ｓＫ」を受け入れ、ＡのＩＤ、およびｘＰをユーザＡに戻して認証を完了させる。
【０１５４】
ｓＫは、Ｂの公開鍵を使用して暗号化され、このため、メールボックスＢは、このメッセージを解読し、「ｓＫ」を獲得することができないことに注目されたい。その後、Ｂが、オンラインになり、「ボイスメール」を確認する（遅延配信サーバに対して確認を行う）と、Ｂは、メールボックスサーバからｓＫの暗号化された値を獲得することができる。Ｂは、その鍵を獲得するのにメールボックスを相手に認証を行わなければならない可能性があり、このことは、既に設定されている既存の認証機構に基づくことが可能であることに留意されたい。
【０１５５】
第２のシナリオ（やはり、機能要素４０２がＩＭＳサーバである図４Ｂを再び参照することが可能である）では、同一の想定が成立し、すなわち、ユーザＡが、現在、応対可能でないユーザＢと連絡をとろうと試みており、したがって、その呼は、Ｂのボイスメールに転送される。しかし、この事例において、ＢのメールボックスとユーザＡは、認証を実行しない。代わりに、Ｂのメールボックスは、単にｓＫをセッション鍵として受け入れ、ユーザＡにＯＫメッセージを戻してｓＫを確認する。
【０１５６】
Ｇ．グループ呼および会議呼
この段落では、ＭＩＫＥＹ−ＩＢＡＫＥの鍵管理プロトコルが、グループ呼および会議呼に拡張される。したがって、ＭＩＫＥＹ−ＩＢＡＫＥプロトコルから生じる有利な特性は、会議環境において実現されることに留意されたい。会議は、概ね、図６Ａから図６Ｃの関連において説明されていることを思い起こされたい。図１０のＩＭＳ例は、Ｎ＝３の場合であることに留意されたい。
【０１５７】
図１０のステップ１から１８に示されるＩＭＳベースのシナリオにおいて、ユーザを会議呼に招待する会議サーバ（ＡＳ／ＭＲＦＣ、つまり、アプリケーションサーバ／マルチメディアリソース機能コントローラ）が存在するものと想定される。このことは、例えば、別のユーザから以前に受信されたＲＥＦＥＲ要求の結果であることも可能である。代替のアプローチは、この機能をユーザの１名（例えば、会議長）に委託することである。この代替は、図１０に示されないものの、このアプローチは、同様であり、グループ鍵の計算は、同一である。
【０１５８】
以下の説明において、すべてのメッセージは、適切なＩＤを使用してＩＢＥ暗号化される（例えば、ユーザＹが、ユーザＸにメッセージＭを送信している場合、メッセージＭは、ＸのＩＤを使用して暗号化される）ものと想定される。図１０で、このことは、（Ｍ）＿Ｘとして表され、つまり、メッセージＭは、ＸのＩＤを使用してＩＢＥ暗号化されることを意味する。
【０１５９】
会議サーバを相手にした交換の第１のセットにおいて、ユーザＡ１、Ａ２、およびＡ３が、それぞれ、ランダムなａ１、ａ２、およびａ３を選択し、さらに各ユーザＡｉが、ｗｉ＝ａｉＰを会議サーバに送信する。交換の第２のセットにおいて、会議サーバは、すべてのａｉＰをすべてのユーザに送信する一方で、各ユーザは、ｚｉ＝ａｉ（ａｉ＋１Ｐ−ａｉ−１Ｐを）を送信する。最後の交換において、会議サーバは、すべてのｚｉを各ユーザに送信する。以上が行われた後、すべての会議参加者は、以下のとおりグループ鍵を計算することができる。すなわち、Ｋｉ＝３ａｉｗｉ−１＋２ｚｉ＋ｚｉ＋１
Ｋ１＝Ｋ２＝Ｋ３であることに留意されたい。また、Ａ１、Ａ２、およびＡ３は、グループ鍵を生成することができるが、会議サーバは、ｚｉおよびｗｉを知っているが、個々のユーザだけしか、ユーザによってランダムに選択されたａｉを知らないので、グループ鍵を生成することができないことにも留意されたい。
【０１６０】
簡明のため、前述の説明は、３名の会議呼参加者に絞る。しかし、前述の手順は、ｎ名の参加者に一般化され得る。ｎ名の参加者の場合、グループ鍵は、Ｋｉ＝ｎａｉｗｉ−１＋（ｎ−１）ｚｉ＋（ｎ−２）ｚｉ＋１．．．ｚｉ−１として生成され、ただし、ｗｉおよびｚｉは、前段で定義されるとおりである。
【０１６１】
このプロトコルの重要な特徴の１つは、新たなユーザが受け入れられるたびに、または既存のユーザが呼を抜けるたびに、グループ鍵が変わることである。このことは、新たなユーザが、呼に追加されるまで、グループ鍵を知ることがないことを確実にし、さらに呼を尚早に離れるユーザは、呼の後、会話へのアクセスを得ることがない。
【０１６２】
新たなユーザが追加され、さらにシステムにＮ名のユーザが既に存在する場合、合計でＮ＋１名のユーザがシステムに存在することに注目されたい。これらのユーザが輪にされると、第Ｎ番のユーザの次のユーザは、現時点で、第（Ｎ＋１）番のユーザである（第Ｎ＋１番のユーザを受け入れる前にそうであったように、第１番のユーザではなく）。新たなユーザを受け入れるプロトコルは、以下のとおり機能する：
新規のユーザは、すべてのユーザと同様に、ＩＢＡＫＥを使用して会議サーバに対して認証を行う。このことは、そのユーザが受け入れられる（さらに呼を許可される）ことを可能とし、さらにその新規のユーザは、正しい会議に参加することを保証される（会議サーバの認証を介して）。
【０１６３】
ｚＮ＋１＝ａＮ＋１Ｐを、認証中に新たなユーザによって選択された値とする。
【０１６４】
次に、会議サーバが、ｉ＝１からｉ＝Ｎ＋１までのすべてに関する集合｛ｚｉ｝を、ブロードキャストであれ、ユニキャストであれ、すべてのユーザに送信する。このことは、すべてのユーザが、その新規のユーザについて知るとともに、ユーザの隣人を特定することを可能とする。隣人リストは、ユーザ１、Ｎ、およびＮ＋１に関してだけ変化することに注目されたい。
【０１６５】
次に、ユーザ１、Ｎ、およびＮ＋１が、ｗのユーザ１、Ｎ、およびＮ＋１に対応する値を計算し、その値を会議サーバに送り返す（個々に）。
【０１６６】
次に、サーバが、｛ｗｉ｝の更新されたリストをすべてのユーザに送信する。
【０１６７】
次に、すべての参加者が、前述したのと同一の式を使用してグループ鍵を再計算し、ただし、Ｎは、Ｎ＋１で置き換えられ、ｚｉおよびｗｉの新たな値が使用される。
【０１６８】
ユーザが会議呼を抜けると、新たな認証手順は、全く実行される必要はないが、グループ鍵が変化する。この手順は、以下のとおり機能する：
会議サーバが、ユーザが会議呼を抜けることについて知る。
【０１６９】
その後、会議サーバが、このイベント、ならびにいずれのユーザが呼を抜けたかに関係する情報（単にＩＤだけでなく、順序も含む）を全員に知らせる。事情を簡単にするため、会議サーバは、新規のリスト｛ｚｉ｝を再送信してもよい。
【０１７０】
このことは、すべてのユーザが、ユーザの隣人を再発見し、さらに必要な場合、ｗｉを再計算することを可能とする。
【０１７１】
ｗｉが変化した、呼に留まっているすべての参加者は、これらの参加者の新たな値を会議サーバに知らせる。
【０１７２】
次に、会議サーバが、更新されたリスト｛ｗｉ｝を送信する。
【０１７３】
次に、すべての参加者が、前述したのと同一の式を使用してグループ鍵を再計算し、ただし、Ｎは、Ｎ−１で置き換えられ、ｗｉの新たな値が使用される。
【０１７４】
ＩＶ．例示的なコンピューティングシステム
図１１は、ネットワーク環境、ならびに本発明の実施形態による２つのエンティティ間でセキュリティで保護された鍵管理プロトコルを実施するのに適したコンピューティングデバイスの形態の通信デバイスの一般化されたハードウェアアーキテクチャ１１００を示す。図１１は、２つだけのエンティティしか示さないが、他のエンティティも同一の構成を有することが可能であることを理解されたい。このため、前述した、セキュリティで保護された鍵管理プロトコルに関連して、この２つのエンティティは、開始側１０２−Ｉ（第１の関係者、またはＡ）および応答側１０２−Ｒ（第２の関係者、またはＢ）であることが可能である。しかし、ＫＭＳ、会議サーバ、ＬＩサーバ、機能要素、さらなるクライアントデバイス（関係者）、およびさらなるサーバが、図１１のコンピューティングデバイスに示されるのと同一のアーキテクチャを使用して実施されることが可能である。したがって、簡明のため、本発明のプロトコルに参加する可能性があるすべてのコンピューティングデバイス（通信デバイス）を図１１に示すことはしない。
【０１７５】
図示されるとおり、１１０２として示されるＡのコンピューティングデバイスと、１１０４として示されるＢのコンピューティングデバイスが、ネットワーク１１０６を介して結合される。このネットワークは、例えば、前述した実施形態の場合と同様に、デバイスが通信することができる任意のネットワークであることが可能であり、ネットワーク１１０６は、ネットワーク事業者（例えば、ベライゾン社、ＡＴ＆Ｔ社、スプリント社）によって運営されるセルラ通信ネットワークなどの公衆アクセス可能な広域通信ネットワークを含むことが可能である。しかし、本発明は、特定のタイプのネットワークに限定されない。通常、これらのデバイスは、クライアントマシンであることが可能である。本明細書で説明されるプロトコルに参加するのに関係者によって使用されることが可能なクライアントデバイスの例には、セルラ電話機、スマートフォン、デスクトップ電話機、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどが含まれることが可能であるが、以上には限定されない。しかし、デバイスの１つまたは複数は、サーバであることも可能である。このため、本発明の通信プロトコルは、コンピューティングシステムが、それぞれ、クライアントとサーバである事例に限定されず、２つのネットワーク要素を備える任意のコンピューティングデバイスに適用可能であることを理解されたい。
【０１７６】
当業者には直ちに明白であるとおり、これらのサーバおよびクライアントは、コンピュータプログラムコードの制御下で動作する、プログラミングされたコンピュータとして実施されることが可能である。コンピュータプログラムコードは、コンピュータ可読記憶媒体（例えば、メモリ）の中に格納され、さらにこのコードは、コンピュータのプロセッサによって実行される。本発明の本開示を与えられて、当業者は、本明細書で説明されるプロトコルを実施するために適切なコンピュータプログラムコードを容易に作ることができる。
【０１７７】
それでも、図１１は、ネットワークを介して通信する各コンピュータシステムに関する例示的なアーキテクチャを一般的に示す。図示されるとおり、デバイス１１０２は、入出力デバイス１１０８−Ａと、プロセッサ１１１０−Ａと、メモリ１１１２−Ａとを備える。デバイス１１０４は、入出力デバイス１１０８−Ｂと、プロセッサ１１１０−Ｂと、メモリ１１１２−Ｂとを備える。本明細書で使用される「プロセッサ」という用語は、中央処理装置（ＣＰＵ）、あるいは１つまたは複数のシグナルプロセッサ、１つまたは複数の集積回路などを含むが、以上には限定されない他の処理回路を含め、１つまたは複数の処理デバイスを含むことを意図していることを理解されたい。また、本明細書で使用される「メモリ」という用語は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えば、ハードドライブ）、またはリムーバブルメモリデバイス（例えば、ディスケットもしくはＣＤ−ＲＯＭ）などの、プロセッサまたはＣＰＵに関連するメモリを含むことを意図している。さらに、本明細書で使用される「入出力デバイス」という用語は、処理装置にデータを入力するための１つまたは複数の入力デバイス（例えば、キーボード、マウス）、ならびに処理装置に関連する結果をもたらすための１つまたは複数の出力デバイス（例えば、ＣＲＴディスプレイ）を含むことを意図している。
【０１７８】
したがって、本明細書で説明される、本発明の方法を実行するためのソフトウェア命令またはソフトウェアコードは、関連するメモリデバイス、例えば、ＲＯＭ、固定メモリ、またはリムーバブルメモリの１つまたは複数の中に格納されることが可能であり、さらに、利用される用意ができると、ＲＡＭにロードされ、ＣＰＵによって実行される。
【０１７９】
本発明の例示的な実施形態は、添付の図面を参照して本明細書で説明されてきたが、本発明は、それらの実施形態そのものに限定されないこと、および本発明の範囲または趣旨を逸脱することなく、他の様々な変更および変形が当業者によって行われ得ることを理解されたい。
【特許請求の範囲】
【請求項１】
通信システムにおいて２名以上の関係者の間で会議を管理するための方法であって、
通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間でＩＤベースの認証された鍵交換動作を実行するステップであり、会議管理要素と２名以上の関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する、ステップと、
会議管理要素が、関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信するステップと、
会議管理要素において、各関係者からランダムなグループ鍵構成要素を受信するステップであり、ランダムなグループ鍵構成要素が、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される、ステップと、
会議管理要素から各関係者に、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信して、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにするステップとを備える、方法。
【請求項２】
各関係者によって計算されるグループ鍵が、Ｎａｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋．．．＋Ｘｉ−２として表現され、ただし、Ｎが、会議に参加することを求めている関係者の総数を表し、ａｉが、所与の関係者によって選択された乱数を表し、Ｚｉが、所与の関係者によって計算されるランダムな鍵構成要素を表し、Ｘｉが、所与の関係者によって計算されるランダムなグループ鍵構成要素を表し、さらにｉが、Ｎ名の関係者の会議における所与の関係者に関する会議順序付けの番号を表し、ｉ＝１の場合、ｉ−１＝Ｎであり、ｉ＝Ｎである場合、ｉ＋１＝１である、請求項１に記載の方法。
【請求項３】
所与の関係者に関するランダムな鍵構成要素が、ａｉＰとして表現される計算によって計算され、ただし、ａｉが、所与の関係者によって選択された乱数であり、さらにＰが、ＩＤ暗号化ベースの鍵認証動作に関連するグループから選択された点である、請求項２に記載の方法。
【請求項４】
所与の関係者に関するランダムなグループ鍵構成要素が、ａｉ（ａｉ＋１Ｐ−ａｉ−１Ｐ）として表現される計算によって計算され、ただし、ａｉが、所与の関係者によって選択された乱数であり、ａｉ＋１Ｐが、会議順序付けにおいて所与の関係者の直後に続く関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、ａｉ−１Ｐが、会議順序付けにおけるその所与の関係者の直前の関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、さらにＰが、暗号鍵交換プロトコルに関連するグループから選択された点である、請求項２に記載の方法。
【請求項５】
会議に参加することを求めている２名以上の関係者が、１つまたは複数の鍵管理サービスからそれぞれの秘密鍵を獲得する、請求項１に記載の方法。
【請求項６】
新規の関係者が会議に追加された場合、および参加している関係者が会議を離れた場合にはいつでも、グループ鍵が変わる、請求項１に記載の方法。
【請求項７】
機能要素が、会議に参加することを求めている嫌疑がかけられた関係者を模倣して、機能要素が嫌疑がかけられた関係者への会議メッセージ、および嫌疑がかけられた関係者からの会議メッセージを傍受することができるようにする、請求項１に記載の方法。
【請求項８】
通信システムにおいて２名以上の関係者の間で会議を管理するための装置であって、
メモリと、
メモリに結合された少なくとも１つのプロセッサとを備え、少なくとも１つのプロセッサが、
通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間でＩＤベースの認証された鍵交換動作を実行するように構成され、会議管理要素と２名以上の関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信し、
会議管理要素から、関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信するように構成され、
会議管理要素において、各関係者からランダムなグループ鍵構成要素を受信するように構成され、ランダムなグループ鍵構成要素が、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算され、さらに
会議管理要素から各関係者に、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信するように構成され、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにするが、会議管理要素が、グループ鍵を計算することができない、装置。
【請求項９】
通信システムにおいて関係者の間の会議に参加する際に使用するための方法であって、
所与の関係者において、
通信システムの会議管理要素と、所与の関係者との間でＩＤベースの認証された鍵交換動作を実行するステップであり、会議管理要素がまた、会議に参加することを求めているその他の参加者を相手にＩＤベースの認証された鍵交換動作を実行し、会議管理要素と関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する、ステップと、
所与の関係者において会議管理要素から、関係者によって計算されたランダムな鍵構成要素を備えるセットを受信するステップと、
所与の関係者から会議管理要素にランダムなグループ鍵構成要素を送信するステップであり、会議管理要素がまた、その他の関係者の各関係者からランダムなグループ鍵構成要素を受信し、ランダムなグループ鍵構成要素が、鍵認証動作中に関係者によって使用された乱数と、会議に参加することを求めている関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される、ステップと、
所与の関係者において会議管理要素から、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを受信するステップと、
所与の関係者において、会議管理要素を介して関係者相互で通信する際に使用するためにその他の関係者によって計算されたのと同一のグループ鍵であるグループ鍵を計算するステップとを備える、方法。
【請求項１０】
通信システムにおいて関係者の間の会議に参加する際に使用するための装置であって、
所与の関係者において、
メモリと、
メモリに結合された少なくとも１つのプロセッサとを備え、少なくとも１つのプロセッサが、
通信システムの会議管理要素と、所与の関係者との間でＩＤベースの認証された鍵交換動作を実行するように構成され、会議管理要素がまた、会議に参加することを求めているその他の参加者を相手にＩＤベースの認証された鍵交換動作を実行し、会議管理要素と関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信し、
所与の関係者において会議管理要素から、関係者によって計算されたランダムな鍵構成要素を備えるセットを受信するように構成され、
所与の関係者から会議管理要素にランダムなグループ鍵構成要素を送信するように構成され、会議管理要素がまた、その他の関係者の各関係者からランダムなグループ鍵構成要素を受信し、ランダムなグループ鍵構成要素が、鍵認証動作中に関係者によって使用された乱数と、会議に参加することを求めている関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算され、
所与の関係者において会議管理要素から、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを受信するように構成され、
所与の関係者において、会議管理要素を介して関係者相互で通信する際に使用するためにその他の関係者によって計算されたのと同一のグループ鍵であるグループ鍵を計算するように構成されている、装置。
【請求項１】
通信システムにおいて２名以上の関係者の間で会議を管理するための方法であって、
通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間でＩＤベースの認証された鍵交換動作を実行するステップであり、会議管理要素と２名以上の関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する、ステップと、
会議管理要素が、関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信するステップと、
会議管理要素において、各関係者からランダムなグループ鍵構成要素を受信するステップであり、ランダムなグループ鍵構成要素が、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される、ステップと、
会議管理要素から各関係者に、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信して、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにするステップとを備える、方法。
【請求項２】
各関係者によって計算されるグループ鍵が、Ｎａｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋．．．＋Ｘｉ−２として表現され、ただし、Ｎが、会議に参加することを求めている関係者の総数を表し、ａｉが、所与の関係者によって選択された乱数を表し、Ｚｉが、所与の関係者によって計算されるランダムな鍵構成要素を表し、Ｘｉが、所与の関係者によって計算されるランダムなグループ鍵構成要素を表し、さらにｉが、Ｎ名の関係者の会議における所与の関係者に関する会議順序付けの番号を表し、ｉ＝１の場合、ｉ−１＝Ｎであり、ｉ＝Ｎである場合、ｉ＋１＝１である、請求項１に記載の方法。
【請求項３】
所与の関係者に関するランダムな鍵構成要素が、ａｉＰとして表現される計算によって計算され、ただし、ａｉが、所与の関係者によって選択された乱数であり、さらにＰが、ＩＤ暗号化ベースの鍵認証動作に関連するグループから選択された点である、請求項２に記載の方法。
【請求項４】
所与の関係者に関するランダムなグループ鍵構成要素が、ａｉ（ａｉ＋１Ｐ−ａｉ−１Ｐ）として表現される計算によって計算され、ただし、ａｉが、所与の関係者によって選択された乱数であり、ａｉ＋１Ｐが、会議順序付けにおいて所与の関係者の直後に続く関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、ａｉ−１Ｐが、会議順序付けにおけるその所与の関係者の直前の関係者によって会議管理要素に送信されたランダムな鍵構成要素であり、さらにＰが、暗号鍵交換プロトコルに関連するグループから選択された点である、請求項２に記載の方法。
【請求項５】
会議に参加することを求めている２名以上の関係者が、１つまたは複数の鍵管理サービスからそれぞれの秘密鍵を獲得する、請求項１に記載の方法。
【請求項６】
新規の関係者が会議に追加された場合、および参加している関係者が会議を離れた場合にはいつでも、グループ鍵が変わる、請求項１に記載の方法。
【請求項７】
機能要素が、会議に参加することを求めている嫌疑がかけられた関係者を模倣して、機能要素が嫌疑がかけられた関係者への会議メッセージ、および嫌疑がかけられた関係者からの会議メッセージを傍受することができるようにする、請求項１に記載の方法。
【請求項８】
通信システムにおいて２名以上の関係者の間で会議を管理するための装置であって、
メモリと、
メモリに結合された少なくとも１つのプロセッサとを備え、少なくとも１つのプロセッサが、
通信システムの会議管理要素と、会議に参加することを求めている２名以上の関係者の各関係者との間でＩＤベースの認証された鍵交換動作を実行するように構成され、会議管理要素と２名以上の関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信し、
会議管理要素から、関係者によって計算されたランダムな鍵構成要素を備えるセットを各関係者に送信するように構成され、
会議管理要素において、各関係者からランダムなグループ鍵構成要素を受信するように構成され、ランダムなグループ鍵構成要素が、鍵認証動作中にその関係者によって使用された乱数と、会議に参加することを求めている２名以上の関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算され、さらに
会議管理要素から各関係者に、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを送信するように構成され、各関係者が、会議管理要素を介して関係者相互に通信する際に使用するための同一のグループ鍵を計算することができるようにするが、会議管理要素が、グループ鍵を計算することができない、装置。
【請求項９】
通信システムにおいて関係者の間の会議に参加する際に使用するための方法であって、
所与の関係者において、
通信システムの会議管理要素と、所与の関係者との間でＩＤベースの認証された鍵交換動作を実行するステップであり、会議管理要素がまた、会議に参加することを求めているその他の参加者を相手にＩＤベースの認証された鍵交換動作を実行し、会議管理要素と関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信する、ステップと、
所与の関係者において会議管理要素から、関係者によって計算されたランダムな鍵構成要素を備えるセットを受信するステップと、
所与の関係者から会議管理要素にランダムなグループ鍵構成要素を送信するステップであり、会議管理要素がまた、その他の関係者の各関係者からランダムなグループ鍵構成要素を受信し、ランダムなグループ鍵構成要素が、鍵認証動作中に関係者によって使用された乱数と、会議に参加することを求めている関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算される、ステップと、
所与の関係者において会議管理要素から、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを受信するステップと、
所与の関係者において、会議管理要素を介して関係者相互で通信する際に使用するためにその他の関係者によって計算されたのと同一のグループ鍵であるグループ鍵を計算するステップとを備える、方法。
【請求項１０】
通信システムにおいて関係者の間の会議に参加する際に使用するための装置であって、
所与の関係者において、
メモリと、
メモリに結合された少なくとも１つのプロセッサとを備え、少なくとも１つのプロセッサが、
通信システムの会議管理要素と、所与の関係者との間でＩＤベースの認証された鍵交換動作を実行するように構成され、会議管理要素がまた、会議に参加することを求めているその他の参加者を相手にＩＤベースの認証された鍵交換動作を実行し、会議管理要素と関係者の間で交換されるメッセージが、メッセージの受信者のそれぞれのＩＤに基づいて暗号化され、さらに会議管理要素が、鍵認証動作中に各関係者から、その関係者によって選択された乱数に基づいて計算されたランダムな鍵構成要素を受信し、
所与の関係者において会議管理要素から、関係者によって計算されたランダムな鍵構成要素を備えるセットを受信するように構成され、
所与の関係者から会議管理要素にランダムなグループ鍵構成要素を送信するように構成され、会議管理要素がまた、その他の関係者の各関係者からランダムなグループ鍵構成要素を受信し、ランダムなグループ鍵構成要素が、鍵認証動作中に関係者によって使用された乱数と、会議に参加することを求めている関係者のうちその他の関係者のサブセットによって計算されたランダムな鍵構成要素とに基づく計算を介して、各関係者によって計算され、
所与の関係者において会議管理要素から、関係者によって計算されたランダムなグループ鍵構成要素を備えるセットを受信するように構成され、
所与の関係者において、会議管理要素を介して関係者相互で通信する際に使用するためにその他の関係者によって計算されたのと同一のグループ鍵であるグループ鍵を計算するように構成されている、装置。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１Ｂ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１３−５０３５６４（Ｐ２０１３−５０３５６４Ａ）
【公表日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願番号】特願２０１２−５２６８７４（Ｐ２０１２−５２６８７４）
【出願日】平成２２年８月２３日（２０１０．８．２３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０４６３１９
【国際公開番号】ＷＯ２０１１／０３１４３６
【国際公開日】平成２３年３月１７日（２０１１．３．１７）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願日】平成２２年８月２３日（２０１０．８．２３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０４６３１９
【国際公開番号】ＷＯ２０１１／０３１４３６
【国際公開日】平成２３年３月１７日（２０１１．３．１７）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]