JP2013517688A5 - - Google Patents

Description

マルチメディア通信システムにおけるセキュリティ保護された通信のための階層鍵管理

本発明は、概して通信セキュリティに関し、より詳細には、マルチメディア通信システムのメディアプレーンなどの環境における通信をセキュリティ保護する際に使用するための鍵管理プロトコルに関する。

従来のマルチメディア通信システムにおいて提供される既存のマルチメディアアプリケーションは、メディアプレーンにおけるセキュリティを十分にサポートしない。ＩＭＳ（ＩＰ（インターネットプロトコル）マルチメディアサブシステム）などの従来のマルチメディア通信システムにおける既存のセキュリティ提案は、トークンベースの対称鍵方法に基づき、鍵を作成して、配布する可能性がある鍵管理サービスを使用して管理される。引用により開示が本明細書に組み込まれている３ＧＰＰ（第３世代パートナーシッププロジェクト）ＴＳ（技術仕様） ３３．３２８および３ＧＰＰ ＴＳ ３３．８２８が、ＩＭＳメディアプレーン暗号化に関する既存の提案について論じている。

引用により開示が本明細書に組み込まれているＲＦＣ３８３０において開示されるＭＩＫＥＹ（マルチメディアインターネットキーイング）が、事前共有鍵に基づくメディアセキュリティプロトコルの例である。

ＭＩＫＥＹプロトコルの或る試みられた改良形態は、ＭＩＫＥＹ−ＴＩＣＫＥＴと呼ばれ、引用により開示が本明細書に組み込まれている、国際特許公開第ＷＯ２００９／０７００７５号において開示される。ＭＩＫＥＹ−ＴＩＣＫＥＴは、ＴＳ ３３．３２８およびＴＳ ３３．８２８において開示されるＲｅｌ−９ ＩＭＳメディアプレーンセキュリティの一部である。ＭＩＫＥＹ−ＴＩＣＫＥＴアプローチは、ユーザデバイスに、別のユーザデバイスを相手にセッション鍵を確立する際に使用するための証明書（チケット）および鍵生成情報を発行する１つまたは複数のＫＭＳ（鍵管理サービス）を使用する。次に、そのセッション鍵が、それらのユーザデバイスによって互いに通信するのに使用される。２つのＫＭＳ（各ユーザデバイスにつき１つのＫＭＳ）が使用される場合、その２つのＫＭＳは、その２つのＫＭＳが利用に供されているユーザデバイスとのセキュリティアソシエーションを確立しなければならないだけでなく、その２つのＫＭＳは、ＭＩＫＥＹ−ＴＩＣＫＥＴプロトコルが機能するのに、その２つのＫＭＳの間であらかじめ存在する１対１のセキュリティアソシエーションを有してもいなければならない。このことは、特に各ＫＭＳが異なる管理ドメインに属する場合、必ずしも好ましい、または可能であるとは限らない。

このため、マルチメディア通信システムのメディアプレーンなどの環境における通信をセキュリティ保護する際に使用するための改良された鍵管理ソリューションの必要性が存在する。

国際公開第２００９／０７００７５号

３ＧＰＰ ＴＳ ３３．３２８ ３ＧＰＰ ＴＳ ３３．８２８ ＲＦＣ３８３０

本発明の原理は、例として、マルチメディア通信システムのメディアプレーンなどの環境における通信をセキュリティ保護する際に使用するための１つまたは複数の階層鍵管理方法を提供する。

本発明の１つの例示的な態様として、第１のコンピューティングデバイスが、第１のユーザ機器に関する鍵管理機能を実行するように構成され、さらに第２のコンピューティングデバイスが、第２のユーザ機器に関する鍵管理機能を実行するように構成され、第１のユーザ機器が、第２のユーザ機器を相手に通信を開始することを求め、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスが、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間であらかじめ存在するセキュリティアソシエーションを有さず、さらに第３のコンピューティングデバイスが、鍵管理機能を実行するように構成されるとともに、第１のコンピューティングデバイスとのあらかじめ存在するセキュリティアソシエーションと、第２のコンピューティングデバイスとのあらかじめ存在するセキュリティアソシエーションとを有する通信システムにおいて、第３のコンピューティングデバイスが、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスのいずれかから要求を受信するステップと、この要求に応答して、その後、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスが、第１のユーザ機器と第２のユーザ機器の間のセキュリティアソシエーションの確立を円滑にすることができるように、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間のセキュリティアソシエーションの確立を円滑にするステップとを備える方法を実行する。

第１のコンピューティングデバイス、第２のコンピューティングデバイス、および第３のコンピューティングデバイスは、鍵管理階層の少なくとも一部分を備え、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスは、この階層のより低いレベルにあり、さらに第３のコンピューティングデバイスは、この階層のより高いレベルにある。

１つの例示的な実施形態において、第３のコンピューティングデバイスによって実行される、円滑にするステップは、データ項目および暗号情報を第１のコンピューティングデバイスに送信することをさらに備える。

次に、第１のコンピューティングデバイスが、そのデータ項目を第２のコンピューティングデバイスに送信する。また、第１のコンピューティングデバイスは、第３のコンピューティングデバイスから受信された暗号情報に基づいて、鍵を計算することもし、さらにその計算された鍵を使用して、第２のコンピューティングデバイスへの１つまたは複数のメッセージの転送をセキュリティ保護する。代替として、第３のコンピューティングデバイスから第１のコンピューティングデバイスによって受信された暗号情報が、事前計算された鍵である場合、第１のコンピューティングデバイスは、その事前計算された鍵を使用して、第２のコンピューティングデバイスへの１つまたは複数のメッセージの転送をセキュリティ保護する。

次に、第２のコンピューティングデバイスが、そのデータ項目を第３のコンピューティングシステムに送信する。

次に、第３のコンピューティングシステムが、第２のコンピューティングシステムからそのデータ項目を受信したことに応答して、第１のコンピューティングシステムに送信されたのと同一の暗号情報を第２のコンピューティングシステムに送信する。

一例において、第２のコンピューティングデバイスが、第３のコンピューティングデバイスから受信された暗号情報に基づく鍵を計算し、さらにその計算された鍵を使用して、第１のコンピューティングデバイスへの１つまたは複数のメッセージの転送をセキュリティ保護することが可能である。別の実施例において、第２のコンピューティングデバイスによって第３のコンピューティングデバイスから受信される暗号情報が、事前計算された鍵である場合、第２のコンピューティングデバイスは、その事前計算された鍵を使用して、第１のコンピューティングデバイスへの１つまたは複数のメッセージの転送をセキュリティ保護する。

一実施形態において、第１のコンピューティングデバイス、第２のコンピューティングデバイス、および第３のコンピューティングデバイスはそれぞれ、鍵管理サービスであり、さらにデータ項目は、チケットまたは証明書を備える。

さらに、例示的な方法によれば、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間でセキュリティアソシエーションが確立されると、第１のユーザ機器と第２のユーザ機器の間でセッション鍵およびセッションアソシエーションが確立される。

また、第１のコンピューティングデバイスは、第２のコンピューティングデバイスを管理する管理ドメインとは異なる管理ドメインによって管理され得る。

本発明の原理は、インターネットプロトコルマルチメディアサブシステム環境に特に適しているが、本発明が、そのように限定されることは意図されてないことを認識されたい。つまり、本発明の原理は、鍵管理の特徴を提供することが望ましい任意の適切な通信システムに一般に適用可能である。

本発明のこれら、およびその他の目的、特徴、および利点は、添付の図面に関連して読まれるべき、本発明の例示的な実施形態の以降の詳細な説明から明白となろう。

単一の鍵管理サービスを使用する鍵管理アーキテクチャおよび鍵管理方法を示す図である。 ２つの鍵管理サービスを使用する鍵管理アーキテクチャおよび鍵管理方法を示す図である。 本発明の或る実施形態による階層鍵管理アーキテクチャおよび階層鍵管理方法を示す図である。 本発明の或る実施形態による階層鍵管理メッセージングプロトコルを示す図である。 本発明の実施形態による方法およびプロトコルの１つまたは複数を実施するのに適した通信システムおよびコンピューティングデバイスの一部分の一般化されたハードウェアアーキテクチャを示す図である。

本明細書で使用される「マルチメディア通信システム」という句は、テキストベースのデータ、グラフィックスベースのデータ、音声ベースのデータ、およびビデオベースのデータを含むが、以上には限定されない２つ以上のタイプのメディアを送信することができる任意の通信システムとして一般的に定義される。

本明細書で使用される「メディアプレーン」という句は、その１つまたは複数のタイプのメディアが呼セッションにおける２名以上の関係者の間で交換されるマルチメディア通信システムの機能部分として一般的に定義される。このことは、その呼セッションを確立するために呼ネゴシエーション／スケジューリングが実行されるマルチメディア通信システムの機能部分である「制御プレーン」と対比される。本発明の技術が使用され得るメディアプレーンアプリケーションの例には、ＶｏＩＰ（ボイスオーバーＩＰ）、ＩＭ（インスタントメッセージング）、ビデオ／オーディオＩＭ、およびビデオ共有が含まれるが、以上には限定されない。メディアプレーンは、アプリケーション層のトラフィックを含むことを理解されたい。

本明細書で使用される「鍵」という用語は、エンティティ認証、プライバシー、メッセージ完全性などの、ただし、以上には限定されない目的の、暗号プロトコルまたは暗号方法に対する入力として一般的に定義される。

「セキュリティアソシエーション」という句は、関係している複数のエンティティのうちの１つまたは複数のエンティティの認証のため、および／または暗号化、解読、認定などのために生成された何らかの暗号データまたはセキュアデータ（例えば、１つまたは複数の鍵）に基づく、２つ以上のエンティティの間の関係として一般的に定義される。

「管理ドメイン」という句は、ホストやルータなどのネットワーク要素の集合体、および所与の管理機関によって管理される相互接続ネットワーク（複数可）として一般的に定義される。

「ユーザデバイス」という句は、関係者（ユーザ）によって、本明細書で説明される方法に参加するのに使用されることが可能である通信デバイスまたはクライアントデバイスとして一般的に定義され、さらに「ユーザデバイス」には、セルラ電話機、スマートフォン、デスクトップ電話機、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどが含まれ得るが、以上には限定されない。

「鍵管理サービス」という句は、暗号鍵の生成、交換、格納、保全、使用、審査、および置き換えと関係する機能をもたらす暗号システム内の論理要素として一般的に定義される。例えば、鍵管理サービスは、１つまたは複数のサーバを介して実施され得る。

「チケット」または「証明書」という用語は、ＫＭＳを発行することによって完全性が保護された１つの情報として一般的に定義され、さらに「チケット」または「証明書」には、メタデータ、参加する関係者のＩＤ、作成の時刻、有効性の時間、シーケンス番号、許される通信使用のタイプなどの１つまたは複数が含まれ得る。チケットは、また、プライバシーが保護される必要のある他の情報あるいは１つまたは複数の鍵を含んでもよい。

前述したとおり、ＩＭＳメディアセキュリティのための鍵配布のためのＭＩＫＥＹ−ＴＩＣＫＥＴ法は、１つまたは複数のＫＭＳ（鍵管理サービス）が、通信ネットワークにおける１つまたは複数のユーザデバイス、すなわち、ＵＥ（ユーザ機器）とのセキュリティアソシエーションを有することを要求する。鍵を確立している複数のＵＥが、異なる管理ドメイン、および異なるＫＭＳに属する事例において、これらのＫＭＳは、互いにあらかじめ存在する１対１のセキュリティアソシエーションを有することを要求される。

一部の実施形態において、そのような要求は、満たすことが可能でない可能性がある。そのようなネットワークアーキテクチャに関する例が、２つ以上の管理ドメインに属するとともに、互いの間であらかじめ存在するセキュリティアソシエーションを有さない、またはそのようなセキュリティアソシエーションを有することを明白に禁止されている２つ以上のＫＭＳである。このため、既存のソリューションは、ＫＭＳの間のあらかじめ存在する１対１のセキュリティアソシエーションを要求して、もたらされる鍵管理ソリューションをかなり柔軟性がなく、リソースを大量に消費するものにしている。また、さらなるＫＭＳ（すなわち、ローミングのための）の追加は、既存のＫＭＳに対するあらかじめ存在するセキュリティアソシエーションの追加を要求する。

図１Ａは、単一のＫＭＳ（鍵管理サービス）を使用する鍵管理アーキテクチャおよび鍵管理方法を示す。詳細には、このアーキテクチャおよび方法は、ＭＩＫＥＹ−ＴＩＣＫＥＴアプローチの一形態である。方法１００に示されるとおり、ユーザデバイス１０２−Ｉ（開始側）が、ユーザデバイス１０２−Ｒ（応答側）を相手に通信セッションを開始することを求める。

ＭＩＫＥＹ−ＴＩＣＫＥＴアプローチによれば、ＫＭＳ１０４は、ユーザデバイス１０２−Ｉを相手に共有鍵（セキュリティ保護された通信）を確立する能力を有するものと想定され、さらに鍵要求に応答して（ステップ１）、その鍵要求に応答して鍵生成情報１０５およびチケット１０６をユーザに供給する（ステップ２）。次に、ユーザデバイス１０２−Ｉが、通信を求める要求の中でチケット１０６をユーザデバイス１０２−Ｒに送信する（ステップ３）。

ＫＭＳ１０４（ユーザデバイス１０２−Ｉにサービスを提供するのと同一のＫＭＳ）を相手にあらかじめ確立されたセキュリティ保護された通信を有するユーザデバイス１０２−Ｒは、チケット１０６をＫＭＳ１０４に供給する（ステップ４）。チケット１０６を供給されたことに応答して、ＫＭＳ１０４は、鍵生成情報１０５（ステップ２でＫＭＳ１０４がユーザデバイス１０２−Ｉに送ったのと同一の鍵生成情報）をユーザデバイス１０２−Ｒに戻す（ステップ５）。鍵生成情報１０５に基づいて、ユーザデバイス１０２−Ｉとユーザデバイス１０２−Ｒの両方が、マルチメディア通信において使用するための共通のセッション鍵を生成する。ユーザデバイス１０２−Ｒが、セッション鍵確立プロセスを完了させる応答を送信する（ステップ６）。ＫＭＳは、鍵生成情報ではなく、既に計算済みの共通のセッション鍵をユーザデバイスに送信することも可能であることに留意されたい。

図１Ｂは、このシナリオにおいて、複数の、例えば、２つの鍵管理サービスを使用する鍵管理アーキテクチャおよび鍵管理方法を示す。このアーキテクチャおよび方法は、ＭＩＫＥＹ−ＴＩＣＫＥＴアプローチの別の形態である。方法１１０に示されるとおり、この場合も、ユーザデバイス１０２−Ｉが、ユーザデバイス１０２−Ｒを相手に通信セッションを開始することを求める。図１Ｂにおけるステップ１から６は、図１Ａに関して前述したのと基本的に同一である。この場合の唯一の違いは、図１Ｂでは、２つのＫＭＳ、すなわち、ユーザデバイス１０２−Ｉにサービスを提供するＫＭＳ１０４−Ｉ、およびユーザデバイス１０２−Ｒにサービスを提供するＫＭＳ１０４−Ｒが存在することである。図１Ｂに示されるさらなるステップ２ａは、既存のＭＩＫＥＹ−ＴＩＣＫＥＴアプローチによれば、このプロトコルが機能するのに、その２つのＫＭＳの間であらかじめ存在する１対１のセキュリティアソシエーションが存在しなければならないという要件を表す。つまり、ＫＭＳ−Ｒは、開始側がステップ１でプロトコルを開始するのに先立って、ＫＭＳ１０４−Ｉに対してそのような１対１のセキュリティアソシエーションが存在しなかったとすると、ステップ４および５で１０２−Ｒからの要求を解決することができないことになる。しかし、前述したとおり、そのような１対１のセキュリティアソシエーションが存在することは、特に、ＫＭＳ１０４−Ｉが、ＫＭＳ１０４−Ｒとは異なる管理ドメインに属する場合、好ましくない可能性があり、実際、禁止されている可能性がある。

既存のアプローチに関連するこれら、およびその他の欠点に対処するのに、本発明の例示的な原理は、ＫＭＳに関するセキュリティアソシエーションのプロビジョニングを簡略化するとともに、ＭＩＫＥＹ−ＴＩＣＫＥＴ鍵配布方法、または他の何らかの鍵配布方法を用いてＫＭＳを展開する際の事業者の柔軟性をもたらす階層セキュリティアソシエーション−信頼モデルを実施することを備える階層鍵管理ソリューションを提供する。このため、異なる２つ以上の管理ドメインに属する、２つ以上のより低い階層のＫＭＳが、より上の階層のＫＭＳに対して、あらかじめ存在するセキュリティアソシエーションを有することが可能である。このため、本発明のソリューションは、ＭＩＫＥＹ−ＴＩＣＫＥＴ方法などが、複数レベルのＫＭＳ階層を導入することによって改良されることを可能にして、マルチメディア通信システムの別々のネットワーク（および、したがって、複数の管理ドメイン）、すなわち、通信システムのネットワーク事業者部分、および通信システムの企業部分における鍵配布の特徴のより柔軟性のある展開を可能にする。

図２Ａは、本発明の或る実施形態による階層鍵管理アーキテクチャおよび階層鍵管理方法を示す。図２Ａにおけるユーザデバイス２０２−Ｉ（開始側）および２０２−Ｒ（応答側）は、図１Ａおよび図１Ｂにおけるユーザデバイス１０２−Ｉおよびユーザデバイス１０２−Ｒとそれぞれ同一または同様であり、さらに特に明記しない限り、同一または同様の仕方で機能するものと理解されたい。同様に、ＫＭＳ２０４−ＩおよびＫＭＳ２０４−Ｒは、ユーザデバイスに関して、ＫＭＳ１０４−ＩおよびＫＭＳ１０４−Ｒとそれぞれ同一または同様であり、さらに特に明記しない限り、同一または同様の仕方で機能する。しかし、ＫＭＳ２０４−Ｉ／ＫＭＳ２０４−ＲとＫＭＳ１０４−Ｉ／ＫＭＳ１０４−Ｒの重要な違いは、図２Ａにおける開始要求（ステップ１）の開始時に、ＫＭＳ２０４−ＩおよびＫＭＳ２０４−Ｒは、ＫＭＳ２０４−ＩとＫＭＳ２０４−Ｒの間で既存のセキュリティアソシエーション（信頼）を有さないことである。しかし、本発明の或る実施形態によれば、ＫＭＳ２０４−ＩとＫＭＳ２０４−０の間、ならびにＫＭＳ２０４−ＲとＫＭＳ２０４−０の間で階層セキュリティアソシエーションが存在する。つまり、本発明の或る実施形態によれば、階層のレベルＢにおけるＫＭＳは、レベルＢ（より低い階層レベル）における個別の各ＫＭＳが、レベルＡ（より高い、つまり、上の階層レベル）におけるＫＭＳを相手にセキュリティアソシエーションを有する、または確立するので、互いにあらかじめ存在する１対１のセキュリティアソシエーションを有することを要求されない。しかし、開始側ＵＥ（２０２−Ｉ）は、そのＵＥ（２０２−Ｉ）のＫＭＳ Ｉ（２０４−Ｉ）を相手にセキュリティアソシエーションを有し、または確立し、さらに応答側ＵＥ（２０２−Ｒ）は、ＫＭＳ Ｒ（２０４−Ｒ）を相手に同様のセキュリティアソシエーションを有する、または確立するものと想定される。

図２Ａは、より低いレベルに２つのＫＭＳを有し、より高いレベルに１つのＫＭＳを有する２レベル階層を示すが、本発明の原理は、各レベルで図２Ａに示される所与の数より多くのＫＭＳを有する、２つより多くのレベルを有する階層を企図することを理解されたい。このため、所与のレベルでＫＭＳを追加することは、追加されたＫＭＳが、同一のレベルでその他のＫＭＳのそれぞれを相手にセキュリティアソシエーションを確立することを要求するのではなく、追加されたＫＭＳが、より上の階層のＫＭＳを相手にセキュリティアソシエーションを確立することだけしか要求しない。

したがって、図２Ａに示される実施形態において、以下のステップが行われる。以下のことに留意されたい：ユーザデバイス２０２−Ｉは、「開始側ＵＥ」または「開始側」または「Ｉ」と呼ばれ、ユーザデバイス２０２−Ｒは、「応答側ＵＥ」または「応答側」または「Ｒ」と呼ばれ、ＫＭＳ２０４−Ｉは、「ＫＭＳ Ｉ」と呼ばれ、ＫＭＳ２０４−Ｒは、「ＫＭＳ Ｒ」と呼ばれ、さらにＫＭＳ ２０４−０は、「ＫＭＳ０」と呼ばれる。また、本明細書で開示される拡張によって別様に指定されない限り、または修正されない限り、標準のＭＩＫＥＹ＿ＴＩＣＫＥＴ技術が、メッセージ転送において適用され得ることにも留意されたい。

ステップ１．開始側ＵＥが、応答側のＩＤを含むＲＥＱＵＥＳＴ＿ＩＮＩＴメッセージをＫＭＳ Ｉに送信する。

ステップ２．ＫＭＳ Ｉが、セッション鍵２０５（または、前述したとおり、このセッション鍵を生成するための鍵生成情報）と、チケット２０６とを含むＲＥＱＵＥＳＴ＿ＲＥＳＰメッセージで開始側に応答する。

ステップ３．開始側が、ＫＭＳ Ｉから受信されたチケット２０６を含むＴＲＡＮＳＦＥＲ＿ＩＮＩＴメッセージを応答側に送信する。

ステップ４．応答側が、開始側から受信されたチケット２０６をＲＥＳＯＬＶＥ＿ＩＮＩＴメッセージの中でＫＭＳ Ｒに転送する。

ステップ５．ＫＭＳ Ｉが、ＲＥＱＵＥＳＴ＿ＩＮＩＴ＿ＫＭＳメッセージをＫＭＳ０に送信する。

ステップ６．ＫＭＳ０が、ＲＥＱＵＥＳＴ＿ＲＥＳＰ＿ＫＭＳメッセージの中のＫＭＳ間チケット２０８およびＫＭＳ間鍵２０９（またはこのＫＭＳ間鍵を生成するための鍵生成情報）でＫＭＳ Ｉに応答する。

ステップ７．ＫＭＳ Ｉが、ＫＭＳ０から受信されたＫＭＳ間チケット２０８をＴＲＡＮＳＦＥＲ＿ＩＮＩＴ＿ＫＭＳメッセージの中でＫＭＳ Ｒに転送する。このメッセージの中で、ＫＭＳ Ｉは、セッション鍵２０５（または鍵生成情報）もＫＭＳ Ｒに転送する。

ステップ８．ＫＭＳ Ｒが、ＫＭＳ Ｉから受信されたＫＭＳ間チケット２０８をＲＥＳＯＬＶＥ＿ＩＮＩＴ＿ＫＭＳメッセージの中でＫＭＳ０に転送する。

ステップ９．ＫＭＳ０が、ＲＥＳＯＬＶＥ＿ＲＥＳＰ＿ＫＭＳメッセージの中のＫＭＳ間鍵２０９でＫＭＳ Ｒに応答する。

ステップ１０．ＫＭＳ Ｒが、ＴＲＡＮＳＦＥＲ＿ＲＥＳＰ＿ＫＭＳメッセージをＫＭＳ Ｉに送信して、鍵交換を完了させることによって、ＫＭＳ ＲがＫＭＳ間鍵２０９を受信したことを確認する。この時点で、ＫＭＳ ＩとＫＭＳ Ｒの間のセキュリティアソシエーションは、確立される。

ステップ１１．ＫＭＳ Ｒが、セッション鍵２０５を有するＲＥＳＯＬＶＥ＿ＲＥＳＰメッセージを応答側に送信する。

ステップ１２．応答側が、ＴＲＡＮＳＦＥＲ＿ＲＥＳＰメッセージを開始側に送信することによって鍵交換を完了させる。

鍵２０５は、ＩとＲの間の実際のメディアセッションに必要とされるセッション鍵であり、ＫＭＳ Ｉは、鍵２０５をＫＭＳ Ｒに送信し、さらにＫＭＳ Ｒは、鍵２０５をＲに送信することに留意されたい。鍵２０９は、ＫＭＳ Ｉが、Ｉによる通信セッションの開始の後にＫＭＳ Ｒを相手にセキュリティアソシエーションを確立することを可能にして、ＫＭＳ ＩおよびＫＭＳ Ｒが、あらかじめ存在する１対１のセキュリティアソシエーションを有さなければならないという要件を緩和する鍵である。このＫＭＳ間鍵によって保護されているメディアは存在せず、ＫＭＳ ＩとＫＭＳ Ｒの間のシグナリングだけしか保護されていないことに留意されたい。

図２Ｂは、図２Ａとの絡みで前述したのと同一のステップを示すが、階層鍵管理メッセージングプロトコル２２０における実際のメッセージ順序を示す。このため、要するに、ＫＭＳ ＩおよびＫＭＳ Ｒは、互いにＳＡ（セキュリティアソシエーション）を有さないが、ＫＭＳ ＩおよびＫＭＳ Ｒは、ＫＭＳ０に対するＳＡは有する。鍵交換は、ＵＥ Ｉによって開始され、ＵＥ Ｉが、ＫＭＳ Ｒに関連付けられているＵＥ Ｒにセキュリティ保護された接続をするようＫＭＳ Ｉに要求を送信する。ＫＭＳ ＩおよびＫＭＳ Ｒは、互いにＳＡを確立しなければならない。これを行うのに、ＫＭＳ ＩおよびＫＭＳ Ｒは、ＫＭＳ ＩおよびＫＭＳ Ｒがともに事前構成されたＳＡを有するＫＭＳ０を使用する。ＫＭＳ ＩとＫＭＳ Ｒの間のＳＡは、ステップ１０でＫＭＳ ＲがＫＭＳ Ｉに確認メッセージを送信すると、確立されたものと見なされることに留意されたい。また、ＫＭＳ Ｉは、ＵＥ Ｉに前に与えられた（ステップ＃２）セッション鍵をＫＭＳ Ｒに転送する（ステップ＃７において）ことにも留意されたい。その後、ステップ＃１１で、ＫＭＳ Ｒが、そのセッション鍵をＵＥ Ｒに転送することが可能である。この時点で、ＵＥ ＩおよびＵＥ Ｒはともに、セッション鍵およびセキュリティアソシエーションを有し、さらにその鍵によって保護されたメディアを交換することができる。

図２Ａおよび図２Ｂとの絡みで前述した実施形態の代替の実施形態が、ＫＭＳ Ｒが、ＲＥＱＵＥＳＴ＿ＩＮＩＴ＿ＫＭＳメッセージをＫＭＳ０に送信し、さらにＲＥＱＵＥＳＴ＿ＲＥＳＰ＿ＫＭＳメッセージの中でＫＭＳ間チケット２０８およびＫＭＳ間鍵２０９（またはＫＭＳ間鍵を生成するための鍵生成情報）を受信するアプローチである。ＲＥＱＵＥＳＴ＿ＩＮＩＴ＿ＫＭＳメッセージおよびＲＥＱＵＥＳＴ＿ＲＥＳＰ＿ＫＭＳメッセージの後には、ＴＲＡＮＳＦＥＲメッセージおよびＲＥＳＯＬＶＥメッセージが続く（すなわち、ＫＭＳ Ｒが、ＴＲＡＮＳＦＥＲ＿ＩＮＩＴ＿ＫＭＳメッセージをＫＭＳ Ｉに送信し、ＫＭＳ Ｉが、ＲＥＳＯＬＶＥ＿ＩＮＩＴ＿ＫＭＳ／ＲＥＳＯＬＶＥ＿ＲＥＳＰ＿ＫＭＳメッセージをＫＭＳ０と交換してから、ＴＲＡＮＳＦＥＲ＿ＲＥＳＰ＿ＫＭＳメッセージをＫＭＳ Ｒに戻す）。

前述した実施形態は、ＭＩＫＥＹ−ＴＩＣＫＥＴ鍵配布方法との絡みで本発明の階層鍵管理ソリューションを例示的に説明するが、そのような本発明のソリューションは、ＭＩＫＥＹ−ＴＩＣＫＥＴプロトコルにおける使用に限定されないことを理解されたい。つまり、本発明のそのような階層鍵管理サービスアーキテクチャおよび階層鍵管理サービス方法は、通信システムにおける他の任意の適切な鍵管理シナリオにおいて実施され得る。

また、本明細書で説明される本発明の階層ＫＭＳアーキテクチャは、有利には、基本プロトコルを変更することなしに、水平にスケール変更すること（すなわち、同一のレベルでさらなるＫＭＳを追加すること）、および垂直にスケール変更すること（すなわち、階層のレベルを追加すること）も可能であることにも留意されたい。

したがって、本発明の１つの例示的な態様として、第１のコンピューティングデバイス（例えば、ＫＭＳ Ｉ）が、第１のユーザ機器（例えば、ＵＥ Ｉ）に関する鍵管理機能（例えば、サービス）を実行するように構成され、さらに第２のコンピューティングデバイス（例えば、ＫＭＳ Ｒ）が、第２のユーザ機器（例えば、ＵＥ Ｒ）に関する鍵管理機能を実行するように構成され、第１のユーザ機器が、第２のユーザ機器を相手に通信を開始することを求め、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスが、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間であらかじめ存在するセキュリティアソシエーションを有さず、さらに第３のコンピューティングデバイス（例えば、ＫＳＭ０）が、鍵管理機能を実行するように構成されるとともに、第１のコンピューティングデバイスとのあらかじめ存在するセキュリティアソシエーションと、第２のコンピューティングデバイスとのあらかじめ存在するセキュリティアソシエーションとを有する通信システムにおいて、第３のコンピューティングデバイスが、第１のコンピューティングデバイスから要求を受信するステップ（例えば、ステップ５）と、この要求に応答して、その後、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスが、第１のユーザ機器と第２のユーザ機器の間のセキュリティアソシエーションの確立を円滑にすることができるように、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間のセキュリティアソシエーションの確立を円滑にする（ステップ６から１０）ステップとを備える方法を実行する。代替の実施形態において、第３のコンピューティングデバイスは、第２のコンピューティングデバイスからその要求を受信してもよく、このため、第２のコンピューティングデバイス（第１のコンピューティングデバイスではなく）が、ＫＭＳ間セキュリティアソシエーションの確立を開始することに留意されたい。

第１のコンピューティングデバイス、第２のコンピューティングデバイス、および第３のコンピューティングデバイスは、鍵管理階層の少なくとも一部分を備え、第１のコンピューティングデバイスおよび第２のコンピューティングデバイスは、この階層のより低いレベル（例えば、レベルＢ）にあり、さらに第３のコンピューティングデバイスは、この階層のより高いレベル（例えば、レベルＡ）にある。

１つの例示的な実施形態において、第３のコンピューティングデバイス（例えば、ＫＭＳ０）によって実行される、円滑にするステップは、データ項目（例えば、チケット２０８）および暗号情報（鍵または鍵生成情報２０９）を第１のコンピューティングデバイス（例えば、ＫＭＳ Ｉ）に送信することをさらに備える。次に、第１のコンピューティングデバイスが、そのデータ項目を第２のコンピューティングデバイス（例えば、ＫＭＳ Ｒ）に送信する。次に、第２のコンピューティングデバイスが、そのデータ項目を第３のコンピューティングシステムに送信する。次に、第３のコンピューティングシステムが、第２のコンピューティングシステムからそのデータ項目を受信したことに応答して、第１のコンピューティングシステムに送信されたのと同一の暗号情報を第２のコンピューティングシステムに送信する。次に、第２のコンピューティングデバイスが、第１のコンピューティングデバイスに応答を送信する。さらに、第１のコンピューティングデバイスと第２のコンピューティングデバイスの間でセキュリティアソシエーションが一度確立されると、第１のユーザ機器（例えば、ＵＥ Ｉ）と第２のユーザ機器（例えば、ＵＥ Ｒ）の間でセッション鍵およびセキュリティアソシエーションが確立される。

次に、最後に図３を参照すると、例示されているのは、本発明による２つのエンティティの間で鍵管理プロトコルを実施するのに適した通信システム環境およびコンピューティングデバイスの一般化されたハードウェアアーキテクチャ３００である。図３は、２つのエンティティＡおよびＢに関するコンピューティングデバイスだけを示すが、他のエンティティも同一の構成を有し得るものと理解されたい。このため、前述した鍵管理プロトコルに関して、２つのエンティティＡおよびＢは、図２Ａおよび図２Ｂに示される任意の２つのエンティティ、すなわち、開始側２０２−Ｉと応答側２０２−Ｒ、ＫＭＳと、開始側および応答側のいずれか、ＫＭＳ階層の任意の２つのＫＭＳなどであることが可能である。このため、簡明のため、本発明のプロトコルに参加し得るすべてのコンピューティングデバイス（通信デバイスおよびサーバ）が図３に示されているわけではない。

図示されるとおり、３０２で表されるＡのコンピューティングデバイスと３０４で表されるＢのコンピューティングデバイスが、ネットワーク３０６を介して結合される。このネットワークは、これらのデバイスが通信することができる任意のネットワークであることが可能であり、例えば、前述した実施形態の場合のように、ネットワーク３０６は、ネットワーク事業者（例えば、ベライゾン、ＡＴ＆Ｔ、スプリント）によって運用されるセルラ通信ネットワークなどの公衆アクセス可能なワイドエリア通信ネットワークであることも可能である。また、ネットワーク３０６は、プライベート企業ネットワークを含むことも可能である。しかし、本発明は、特定のタイプのネットワークに限定されない。通常、これらのデバイスは、クライアントマシンであり得る。本明細書で説明されるプロトコルに参加するのに関係者によって使用され得るクライアントデバイスの例には、セルラ電話機、スマートフォン、デスクトップ電話機、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータなどが含まれ得るが、これらには限定されない。しかし、これらのデバイスの１つまたは複数が、サーバであることも可能である。このため、本発明の通信プロトコルは、コンピューティングシステムがそれぞれ、クライアントとサーバである事例に限定されるのではなく、代わりに任意の形態のコンピューティングデバイスに適用可能であることを理解されたい。

当業者には直ちに明白なとおり、これらのサーバおよびクライアントは、コンピュータプログラムコードの制御下で動作するプログラミングされたコンピュータとして実施され得る。そのコンピュータプログラムコードは、コンピュータ可読記憶媒体（例えば、メモリ）の中に格納され、さらにそのコードは、コンピュータのプロセッサによって実行される。本発明の開示に鑑みて、当業者は、本明細書で説明されるプロトコルを実施するために適切なコンピュータプログラムコードを作成することもできる。

それでも、図３は、ネットワークを介して通信する各コンピュータシステムに関する例示的なアーキテクチャを一般的に示す。図示されるとおり、デバイス３０２は、入出力デバイス３０８−Ａと、プロセッサ３１０−Ａと、メモリ３１２−Ａとを備える。デバイス３０４は、入出力デバイス３０８−Ｂと、プロセッサ３１０−Ｂと、メモリ３１２−Ｂとを備える。本明細書で使用される「プロセッサ」という用語は、ＣＰＵ（中央処理装置）、または１つまたは複数のシグナルプロセッサ、１つまたは複数の集積回路などを含むが、これらには限定されない他の処理回路を含め、１つまたは複数の処理デバイスを含むことを意図しているものと理解されたい。また、本明細書で使用される「メモリ」という用語は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えば、ハードドライブ）、またはリムーバブルメモリデバイス（例えば、ディスケットまたはＣＤＲＯＭ）などの、プロセッサまたはＣＰＵに関連するメモリを含むことを意図している。さらに、本明細書で使用される「入出力デバイス」という用語は、処理装置にデータを入力するための１つまたは複数の入力デバイス（例えば、キーボード、マウス）、ならびに処理装置に関連する結果をもたらすための１つまたは複数の出力デバイス（例えば、ＣＲＴディスプレイ）を含むことを意図している。

したがって、本明細書で説明される本発明の方法を実行するためのソフトウェア命令またはソフトウェアコードは、関連するメモリデバイス、例えば、ＲＯＭ、固定メモリもしくはリムーバブルメモリの１つまたは複数の中に格納されることが可能であり、さらに利用される準備ができると、ＲＡＭにロードされ、ＣＰＵによって実行されることが可能である。

本発明の例示的な実施形態が、添付の図面を参照して本明細書で説明されてきたが、本発明は、それらの実施形態そのものに限定されないこと、および本発明の範囲または趣旨を逸脱することなく、他の様々な変更および修正が当業者によって行われ得ることを理解されたい。