(57)【要約】  本発明は、複数の通信エンティティを含む通信ネットワークにおいてソースエンティティと目標エンティティとの間でセッション鍵を設定する方法および装置に関する。本方法は、対称形の暗号プリミティブの使用に依存し、４または５個のメッセージ交換でセッションを設定することにより当該セッション内の各エンティティをサービス妨害攻撃から保護する。
2016514913.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信エンティティを含む通信ネットワークにおいて、ソースエンティティ（Ｉ）と目標エンティティ（Ｒ）との間でセッション鍵を設定する方法であって、前記ソースエンティティが、データを暗号化するための第１のソース鍵ＫＩｅおよび前記ソースエンティティ用のメッセージ認証コードを計算するための第２のソース鍵ＫＩａを信頼できる第三者エンティティ（ＴＣ）と共有し、前記目標エンティティが、データを暗号化するための第１の目標鍵ＫＲｅおよび前記目標エンティティ用のメッセージ認証コードを計算するための第２の目標鍵ＫＲａを前記信頼できる第三者エンティティと共有していて、前記方法が、
−前記信頼できる第三者エンティティにおいて、前記目標エンティティとのセッションを設定するメッセージであって、少なくとも前記ソースエンティティ、前記目標エンティティ、および前記信頼できる第三者エンティティの各々からの識別子、並びに前記第２のソース鍵ＫＩａに基づく認証コードを含む前記メッセージを前記ソースエンティティから受信するステップ（６０２）と、
−前記ソースエンティティおよび前記目標エンティティ用の鍵のペアＫＩＲ（ＫＩＲａ、ＫＩＲｅ）を生成するステップ（６０４）と、
−前記第１のソース鍵ＫＩｅおよび前記第１の目標鍵ＫＲｅにより前記鍵のペアＫＩＲ（ＫＩＲａ、ＫＩＲｅ）を暗号化するステップ（６０４）と、
−少なくとも前記暗号化された鍵ＫＩＲおよび前記第２の目標鍵ＫＲａに基づく認証コードを含むメッセージを前記目標エンティティに送信するステップ（６０６）と、
−少なくとも前記ソースエンティティ、前記目標エンティティ、および前記信頼できる第三者エンティティの各々からの識別子、並びに前記第２の目標鍵ＫＲａに基づく認証コードを含むメッセージを前記目標エンティティから受信するステップ（６０８）と、
−少なくとも前記暗号化された鍵ＫＩＲおよび前記第２のソース鍵ＫＩａに基づく認証コードを含むメッセージを前記ソースエンティティに送信するステップ（６０１）とを含む方法。
【請求項２】
前記データ暗号化用の前記ソース鍵ＫＩｅおよび前記認証コード用の前記ソース鍵ＫＩａが、前記信頼できる第三者エンティティに対する前記目標エンティティの認証ステップの後で取得された初期鍵から導出される、請求項１に記載の方法。
【請求項３】
前記ソースエンティティから受信される前記メッセージが、前記ソースエンティティからの前記メッセージの鮮度証明用のソースノンス（ＮＩ）を更に含んでいる、請求項１または２に記載の方法。
【請求項４】
前記ソースエンティティ用の前記鍵ＫＩＲａを生成するステップが、前記鍵ＫＩＲａを、前記目標エンティティ、前記信頼できる第三者エンティティ、および前記ノンスＮＩの各々からの識別子と連結するステップ、並びに前記連結されたアセンブリを前記第１の目標鍵ＫＲｅを用いて暗号化するステップを含んでいる、請求項３に記載の方法。
【請求項５】
前記目標エンティティに送信される前記メッセージが前記ノンス（ＮＩ）を更に含み、前記第２の目標鍵ＫＲａに基づく前記認証コードが前記ノンスに対し計算される、請求項４に記載の方法。
【請求項６】
前記目標エンティティから受信される前記メッセージが、前記目標メッセージの鮮度証明用のソースノンス（ＮＩ）および目標ノンス（ＮＲ）を更に含んでいる、請求項５に記載の方法。
【請求項７】
前記第２の目標鍵ＫＲａ、前記識別子、前記ソースおよび目標ノンス（ＮＩ、ＮＲ）、並びに前記受信した認証コードを用いて、前記第２の目標鍵ＫＲａに基づいて認証コードを計算するステップと、前記計算された認証コードが前記受信した認証コードに等しいか否か確認するステップを含んでいる、請求項６に記載の方法。
【請求項８】
前記ソースエンティティに送信される前記メッセージが、前記ソースおよび目標ノンス（ＮＩ、ＮＲ）を更に含んでいる、請求項７に記載の方法。
【請求項９】
前記ソースおよび目標エンティティの各々からの識別子が、ＩＰｖ６アドレス、ＭＡＣアドレス、またはＵＲＬのいずれかである、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記ノンスが、１個のタイムスタンプ情報、１個の乱数、または１個のカウンタである、請求項３〜９のいずれか１項に記載の方法。
【請求項１１】
前記目標エンティティに送信される（７０６）前記メッセージが更に、前記鍵ＫＩｅおよびＫＩａにより暗号化された鍵を含み、前記目標エンティティから受信される前記メッセージおよび前記ソースエンティティに送信される前記メッセージが前記目標エンティティから前記ソースエンティティに送信される単一のメッセージ（７０８）である、請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記ソースエンティティおよび前記目標エンティティの各々からの識別子、前記ソースおよび目標ノンス（ＮＩ、ＮＲ）、並びに前記ソースエンティティおよび前記目標エンティティ用の鍵のペアを用いて計算された認証コードを含むメッセージを前記ソースエンティティから前記目標エンティティに送信するステップ（６１２）を更に含んでいる、請求項６〜１１のいずれか１項に記載の方法。
【請求項１３】
ソースエンティティと目標エンティティとの間でセッション鍵を設定するシステムであって、前記ソースエンティティが、データを暗号化するための第１のソース鍵ＫＩｅおよび前記ソースエンティティ用のメッセージ認証コードを計算するための第２のソース鍵ＫＩａを信頼できる第三者エンティティと共有し、前記目標エンティティが、データを暗号化するための第１の目標鍵ＫＲｅおよび前記目標エンティティ用のメッセージ認証コードを計算するための第２の目標鍵ＫＲａを前記信頼できる第三者エンティティと共有していて、請求項１〜１２のいずれか１項に記載の方法のステップを実行する手段を含むシステム。
【請求項１４】
前記ソースエンティティが一群のソースノードであり、および／または前記目標エンティティが個々の鍵および／または一群の鍵を用いる一群の目標ノードである、請求項１３に記載のシステム。
【請求項１５】
コンピュータプログラム製品であって、前記プログラムがコンピュータ上で実行された場合に、請求項１〜１２のいずれか１項に記載の方法のステップを実行可能にするコード命令を含んでいるコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク通信の分野、特にネットワークのエンティティ間での暗号化された通信に関する。
【背景技術】
【０００２】
通信ネットワークの２個のエンティティ間におけるセッション鍵の設定は、当該エンティティ間でのやり取りのセキュリティ保証を意図した大多数の暗号サービスを実装するための基本的要件である。従って、交換されるデータの改ざんまたは単に内容を知ることを目的とする攻撃からの前記データの保護は一般に対称な暗号プリミティブに依存しており、その際に相互に通信するエンティティがメッセージの送信（暗号化、完全性の保護）および受信（復号化、完全性の確認）に同一の鍵を用いる。
【０００３】
セッション鍵の設定は、通信エンティティの存続期間にわたり多くの回数発生することが意図された。全ての新規のコレスポンデントとの全てのやり取りのセキュリティを保証するために新規の対称鍵を使用しなければならない。これらのコレスポンデントは、当該エンティティが、メンバー間の対話を促進するシナリオにおける参加主体、例えばセンサネットワーク（無線センサネットワーク、ＷＳＮ）、機械間（Ｍ２Ｍ）または「物のインターネット」（ＩｏＴ）型である場合に更に多数になる。更に、セッション鍵は、存続期間に限りがあるため定期的に更新されなければならないことを特徴とする。従って、セッション鍵を設定するために実装される手順は特に重要であって慎重な設計を要する。
【０００４】
セッション鍵設定プロトコルの品質を判断するために複数のパラメータを考慮する必要がある。第１に、プロトコルのセキュリティが保証されなければならない。従って、設定する鍵の機密性および２個のコレスポンデントの相互認証が保証されなければならない。これらに加えて、サービス妨害攻撃からの保護等、電力リソースおよび／またはシステムリソースの消耗を意図する攻撃に対するプロトコルの実行に関与するエンティティを保護する他のセキュリティパラメータがある。第２に、セッション鍵設定プロトコルは、必要な通過帯域および電力消費に関して、特に実行される暗号計算の観点から効率的でなければならない。この第２の基準が特に重要なのは、セッション鍵設定プロトコルが、電池等の小規模な電力リソース、または計算および／またはメモリ容量が小さいエンティティにより実装されなければならない場合である。最後に、プロトコルは、追加的な機能、例えば認証機構を実装する２個のノード間における認証機構の相互運用性、または鍵の交換に対する集中化された制御の可能性、および／または設定された鍵に伴うセキュリティポリシーの集中化された定義の可能性を提供することができる。
【０００５】
原理的に、２個のノード間でセッション鍵を設定する３通りのアプローチが開発されてきた。
【０００６】
第１の系統は鍵転送であり、１個以上の秘密値をセッションの２個の参加主体のうちの一方から他方へ、暗号化によりセキュリティを保証した上で転送するものである。このような秘密値の転送は「１パス鍵転送プロトコル」として知られるモードで一方向に行われても、または「２パス鍵転送プロトコル」として知られるモードで双方向に行われてもよい。次いでセッション鍵は当該秘密値から導出される。
【０００７】
セッション鍵を設定する解決策の第２の系統は鍵合致である。このアプローチは、２個のノード間で公開値を交換し、そこから、交換に関与する２個のエンティティにより、交換された公開値を復号化する必要無しに共通セッション鍵が復元される。「鍵合致」の公知の主要プロトコルがＤｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコルである。「鍵合致」は、消費されるリソースの観点から、主として暗号動作に消費される電力に関して高コストのアプローチである。
【０００８】
セッション鍵を設定する解決策の第３の系統は鍵配信である。このアプローチでは、「信頼できる第三者機関」と呼ばれることが多い第３のエンティティが介在して他の２個の参加主体にセッション鍵を計算可能にする秘密値またはセッション鍵自体を提供する。しかし、鍵配信もまた、２個の参加主体間で直接のやり取りを必要とする。これは、当該２個の参加主体が、プロトコルに関与している証拠を提供し、自身が送るメッセージの鮮度を確立して、確立された秘密を知っていることを証明しなければならないためである。鍵配信は、実装が簡単、且つ必要な暗号演算および消費電力の観点から手軽であるにもかかわらず、既存の解決策では未だ解決されていない短所がある。
【０００９】
公知の「鍵配信」解決策は、ＮｅｅｄｈａｍおよびＳｃｈｒｏｅｄｅｒによるものであり、あるいはＫｅｒｂｅｒｏｓプロトコルまたはＭＩＫＥＹ−Ｔｉｃｋｅｔアプローチであってもよい。
【００１０】
Ｎｅｅｄｈａｍ−Ｓｃｈｒｏｅｄｅｒ鍵転送プロトコルは、文献「Ｕｓｉｎｇ  ｅｎｃｒｙｐｔｉｏｎ  ｆｏｒ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｉｎ  ｌａｒｇｅ  ｎｅｔｗｏｒｋｓ  ｏｆ  ｃｏｍｐｕｔｅｒｓ」、Ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｏｆ  ｔｈｅ  ＡＣＭ、ｖｏｌｕｍｅ  ２１、ｎｕｍｂｅｒ  １２、１９７８に提示されており、各々が信頼できる第三者機関（ＴＣ）と暗号化鍵を共有する２個のエンティティすなわちイニシエータ（Ｉ）とレスポンダ（Ｒ）の間における５個のメッセージ交換を含んでいる。５個のメッセージ交換を図１に示す。Ｎｅｅｄｈａｍ−Ｓｃｈｒｏｅｄｅｒプロトコルの主要な問題の一つは、イニシエータのふりをしてイニシエータとレスポンダの間で第３のメッセージ（メッセージ３）をリプレイする攻撃者による成りすまし攻撃である。攻撃者は、信頼できる第三者機関が生成した鍵を知っている可能性があり、次いで第４のメッセージを復号化して、最後のメッセージを送ることによりセッションを乗っ取る恐れがある。
【００１１】
ＫｏｈｌおよびＮｅｕｍａｎ著の文献「Ｔｈｅ  Ｋｅｒｂｅｒｏｓ  ｎｅｔｗｏｒｋ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｓｅｒｖｉｃｅ」、Ｓｅｐｔｅｍｂｅｒ  １９９３に記述されている正規化Ｋｅｒｂｅｒｏｓプロトコルは図２に示され、４個のメッセージ交換に基づいている。最初の２個のメッセージは、イニシエータと信頼できる第三者機関との間で交換される。最後の２個のメッセージは、イニシエータとレスポンダとの間で交換される。Ｋｅｒｂｅｒｏｓプロトコルの短所は、イニシエータとレシーバとが対称でない点である。信頼できる第三者機関は、レシーバが実際に連絡を受けたか、または安全なトランザクションへの参加に実際に同意したかについて一切保証しない。実際、Ｋｅｒｂｅｒｏｓプロトコルは、用途が限定的であって、むしろイニシエータであるクライアントから、悪意のある行動に晒されないものと仮定されるリソース、例えばプリンタまたはファイルサーバ等へのアクセスを許可することを意図している。
【００１２】
ＮｅｅｄｈａｍおよびＳｃｈｒｏｅｄｅｒプロトコルに対する公知の改良は、図３に示すと共に、ＯｔｗａｙおよびＲｅｅｓ著の文献「Ｅｆｆｉｃｉｅｎｔ  ａｎｄ  ｔｉｍｅｌｙ  ｍｕｔｕａｌ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、１９８７に記述されているＯｔｗａｙおよびＲｅｅｓプロトコルである。しかし、このプロトコルにも依然として、信頼できる第三者機関が２個の参加主体の一方、この場合はレスポンダとしか直接対話しない点が短所である。
【００１３】
Ｂｌｏｍ他による国際公開第２００９／０７００７５Ａ１号パンフレット「Ｋｅｙ  ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  ｓｅｃｕｒｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ」に２個のエンティティ間における安全な通信のためのセッション鍵を設定する方法が示されている。本方法は、ＭａｔｔｓｓｏｎおよびＴｉａｎ著「ＭＩＫＥＹ−Ｔｉｃｋｅｔ：Ｔｉｃｋｅｔ−ｂａｓｅｄ  ｍｏｄｅｓ  ｏｆ  ｋｅｙ  ｄｉｓｔｒｉｂｕｔｉｏｎ  ｉｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｎｅｔ  ＫＥＹｉｎｇ（ＭＩＫＥＹ）」のＲＦＣ６０４３に指定されたＭＩＫＥＹ−Ｔｉｃｋｅｔ鍵配信プロトコルに依存している。鍵管理は、イニシエータおよびレスポンダが各々信頼できる第三者機関と共通鍵を共有する集中化鍵管理信用サービスに基づいている。
【００１４】
実際、当該プロトコルは、その設計に起因してサービス妨害攻撃の目標になり得る。当業者は各種形式のサービス妨害攻撃を承知している。攻撃者は、例えば使用するプロトコルが、ノードが未知のデータを受信した際に当該ノードをブロックすべく実装されている場のように、通信プロトコルにおける実装エラーを悪用することによりサービスの妨害を行うことができる。攻撃者は次いで、レスポンダすなわち目標に誤ったフィールドを含むメッセージを送ることにより、サービス妨害攻撃を行うことが可能である。サービスの妨害を実施する別の方法は、目標と通信を開始し、次いでメッセージの送信を停止することで目標を承認待ちの状態に陥れて受信スタックを飽和させるものである。最後に、サービスの妨害は、なるべく早く目標を飽和させて攻撃者の追跡を困難にすべく、複数の攻撃者を同時に用いて配信することができる。
【００１５】
従って、公知のアプローチは、セッション鍵を設定する代替的な解決策を提供するものの、その短所に起因してセッション鍵設定プロトコルに期待される全てのセキュリティニーズに応えるものではない。
【００１６】
提案する本発明はこれらのニーズに応えることができる。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】国際公開第２００９／０７００７５号
【非特許文献】
【００１８】
【非特許文献１】ＮｅｅｄｈａｍおよびＳｃｈｒｏｅｄｅｒ著「Ｕｓｉｎｇ  ｅｎｃｒｙｐｔｉｏｎ  ｆｏｒ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｉｎ  ｌａｒｇｅ  ｎｅｔｗｏｒｋｓ  ｏｆ  ｃｏｍｐｕｔｅｒｓ」，Ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｏｆ  ｔｈｅ  ＡＣＭ、ｖｏｌｕｍｅ  ２１，ｎｕｍｂｅｒ  １２、１９７８
【非特許文献２】ＫｏｈｌおよびＮｅｕｍａｎ著「Ｔｈｅ  Ｋｅｒｂｅｒｏｓ  ｎｅｔｗｏｒｋ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｓｅｒｖｉｃｅ」，，Ｓｅｐｔｅｍｂｅｒ  １９９３
【非特許文献３】ＯｔｗａｙおよびＲｅｅｓ著「Ｅｆｆｉｃｉｅｎｔ  ａｎｄ  ｔｉｍｅｌｙ  ｍｕｔｕａｌ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ」，１９８７
【非特許文献４】ＭａｔｔｓｓｏｎおよびＴｉａｎ著「ＭＩＫＥＹ−Ｔｉｃｋｅｔ：Ｔｉｃｋｅｔ−ｂａｓｅｄ  ｍｏｄｅｓ  ｏｆ  ｋｅｙ  ｄｉｓｔｒｉｂｕｔｉｏｎ  ｉｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｎｅｔ  ＫＥＹｉｎｇ（ＭＩＫＥＹ）」
【発明の概要】
【発明が解決しようとする課題】
【００１９】
本発明の目的は、安全且つサービス妨害攻撃から保護されたセッション鍵を設定する方法を提案することである。
【課題を解決するための手段】
【００２０】
有利な特徴として、本発明は、イニシエータノードおよびレスポンダノードの両方をサービス妨害攻撃から保護する。
【００２１】
本発明の別の目的は、リソース消費の観点から効率的なセッション鍵を設定する方法を提案することである。従って、本発明の方法は、４または５個のメッセージ交換でセッションの設定を可能にすることができ、対称な暗号プリミティブの使用に依存する。
【００２２】
有利な特徴として、本発明は、機械間（Ｍ２Ｍ）通信のセキュリティの分野で、またはリソースが制約されたノード、例えばリソースの制約が最大で且つセッション鍵の動的設定の必要性を督促可能なノードに属するセンサおよび／またはアクチュエータノードのネットワークに関連して実装される。
【００２３】
所望の結果を得るための方法、装置およびコンピュータプログラム製品を提案する。
【００２４】
特に、複数の通信エンティティを含む通信ネットワークにおいて、ソースエンティティ（Ｉ）と目標エンティティ（Ｒ）との間でセッション鍵を設定する方法であって、当該ソースエンティティが、データを暗号化するための第１のソース鍵ＫＩｅおよび当該ソースエンティティ用のメッセージ認証コードを計算するための第２のソース鍵ＫＩａを信頼できる第三者エンティティ（ＴＣ）と共有し、目標エンティティが、データを暗号化するための第１の目標鍵ＫＲｅおよび当該目標エンティティ用のメッセージ認証コードを計算するための第２の目標鍵ＫＲａを前記信頼できる第三者エンティティと共有していて、当該方法が、
信頼できる第三者エンティティにおいて、目標エンティティとのセッションを設定するメッセージであって、少なくともソースエンティティ、目標エンティティ、および前記信頼できる第三者エンティティの各々からの識別子、並びに第２のソース鍵ＫＩａに基づく認証コードを含む前記メッセージをソースエンティティから受信するステップと、
ソースエンティティおよび目標エンティティ用の鍵のペアＫＩＲ（ＫＩＲａ、ＫＩＲｅ）を生成するステップと、
第１のソース鍵ＫＩｅおよび第１の目標鍵ＫＲｅにより鍵のペアＫＩＲ（ＫＩＲａ、ＫＩＲｅ）を暗号化するステップと、
少なくとも当該暗号化された鍵ＫＩＲおよび第２の目標鍵ＫＲａに基づく認証コードを含むメッセージを目標エンティティに送信するステップと、
少なくともソースエンティティ、目標エンティティ、および前記信頼できる第三者エンティティの各々からの識別子、並びに第２の目標鍵ＫＲａに基づく認証コードを含むメッセージを目標エンティティから受信するステップと、
少なくとも当該暗号化された鍵ＫＩＲおよび第２のソース鍵ＫＩａに基づく認証コードを含むメッセージをソースエンティティに送信するステップとを含んでいる。
【００２５】
有利な特徴として、データ暗号化用のソース鍵ＫＩｅおよび認証コード用のソース鍵ＫＩａは、信頼できる第三者エンティティに対する目標エンティティの認証ステップの後で取得された初期鍵から導出される。
【００２６】
一変型例において、ソースエンティティから受信されるメッセージは更に、ソースエンティティからのメッセージの鮮度証明用のソースノンス（ＮＩ）を含んでいる。
【００２７】
別の変型例において、ソースエンティティ用の鍵ＫＩＲａを生成するステップは、鍵ＫＩＲａを、目標エンティティ、信頼できる第三者エンティティ、およびノンスＮＩの各々からの識別子と連結するステップ、並びに連結されたアセンブリを第１の目標鍵ＫＲｅを用いて暗号化するステップを含んでいる。
【００２８】
有利な特徴として、目標エンティティに送信されるメッセージは更にノンス（ＮＩ）を含み、第２の目標鍵ＫＲａに基づく認証コードがノンスに対し計算される。
【００２９】
有利な特徴として、目標エンティティから受信されるメッセージは更に、目標メッセージの鮮度証明用のソースノンス（ＮＩ）および目標ノンス（ＮＲ）を含んでいる。
【００３０】
一実装変型例において、第２の目標鍵ＫＲａ、識別子、ソースおよび目標ノンス（ＮＩ、ＮＲ）、並びに受信した認証コードを用いて、第２の目標鍵ＫＲａに基づいて認証コードを計算するステップと、計算された認証コードが受信した認証コードに等しいか否かを確認するステップ。
【００３１】
有利な特徴として、ソースエンティティに送信されるメッセージは更に、ソースおよび目標ノンス（ＮＩ、ＮＲ）を含んでいる。
【００３２】
有利な特徴として、ソースおよび目標エンティティの各々からの識別子は、ＩＰｖ６アドレス、ＭＡＣアドレス、またはＵＲＬのいずれかである。
【００３３】
上記変型例によれば、ノンスは、１個のタイムスタンプ情報、１個の乱数、または１個のカウンタである。
【００３４】
別の変型例において、信用できる第三者エンティティにより目標エンティティに送信されたメッセージは、鍵ＫＩｅおよびＫＩａにより暗号化された鍵を更に含み、目標エンティティから受信されるメッセージおよびソースエンティティに送信されるメッセージは、目標エンティティからソースエンティティに送信された単一のメッセージである。
【００３５】
別の変型例において、本方法は、ソースエンティティおよび目標エンティティの各々からの識別子、ソースおよび目標ノンス（ＮＩ、ＮＲ）、並びにソースエンティティおよび目標エンティティとで共有される鍵ＫＩＲａを用いて計算された認証コードを含むメッセージをソースエンティティから目標エンティティに送信するステップを更に含む。
【００３６】
本発明は更に、ソースエンティティと目標エンティティとの間でセッション鍵を設定するシステムに関し、当該ソースエンティティが、データを暗号化するための第１のソース鍵ＫＩｅおよび当該ソースエンティティ用のメッセージ認証コードを計算するための第２のソース鍵ＫＩａを信頼できる第三者エンティティと共有し、当該目標エンティティが、データを暗号化するための第１の目標鍵ＫＲｅおよび当該目標エンティティ用のメッセージ認証コードを計算するための第２の目標鍵ＫＲａを前記信頼できる第三者エンティティと共有していて、当該システムは権利請求された本方法の全てのステップを実装する手段を含んでいる。
【００３７】
本発明は、コンピュータプログラム製品の形式で実装することができ、当該プログラムがコンピュータ上で実行された場合に、権利請求された本方法のステップを実行可能にするコード命令を含んでいる。
【００３８】
本発明の各種態様および利点は、以下の図面を参照しながら、本発明の好適であるが非限定的な実装モードの説明から明らかになろう。
【図面の簡単な説明】
【００３９】
【図１】ＮｅｅｄｈａｍおよびＳｃｈｒｏｅｄｅｒの方法に基づくメッセージ交換を示す。
【図２】Ｋｅｒｂｅｒｏｓの方法に基づくメッセージ交換を示す。
【図３】ＯｔｗａｙおよびＲｅｅｓの方法に基づくメッセージ交換を示す。
【図４】本発明を有利に実装可能なネットワークインフラのトポロジカルな表現である。
【図５】ＭＩＫＥＹ−Ｔｉｃｋｅｔ法に基づく、図４のネットワークの開始エンティティ、応答エンティティ、および信頼できる第三者エンティティとの間で実行される手順を示す。
【図６】本発明の有利な実装例において、図４のネットワークの開始エンティティ、応答エンティティ、および信頼できる第三者エンティティとの間で実行される手順を示す。
【図７】本発明の変型例において、図１のネットワークの開始エンティティ、応答エンティティ、および信頼できる第三者エンティティとの間で実行される手順を示す。
【発明を実施するための形態】
【００４０】
図４に、本発明を有利に実装可能な通信インフラ１００の一例を示す。本発明を限定するのではなく、説明を簡潔にするために、図４の例は有限個数のエンティティ（またはノード）および接続だけを示しているが、当業者には以下に述べる原理が複数且つ各種のエンティティおよび接続種別（無線、移動、高速度）に拡張できよう。
【００４１】
通信ネットワーク（１００）は、オブジェクトのネットワーク（１０２）を形成可能な固定または移動エンティティを含んでいる。これらのエンティティは、強いリソース制約（１０２−１、１０２−ｎ）または弱いリソース制約（１１２−１、１１２−ｍ）を有していてよい。
【００４２】
強いリソース制約を有するエンティティは、計算および／または記憶容量が制約された無線センサまたはアクチュエータであってもよい。これらはまた能動タグであってもよい。しかし、リソースが本質的に制約されていないエンティティであっても、自身のプロセッサリソースの大部分を別のタスクに用いた場合、または自身のバッテリレベルが臨界閾値に達した時点で一時的に制約を受ける場合がある。更に、当該エンティティは、本発明のように電力の観点からより低コストのプロトコルを実装するよう督促され得る。
【００４３】
リソース制約が余り厳しくないエンティティとして、インターネット接続およびカメラを備えた携帯電話がある。これらはまた、制約のあるエンティティを有するネットワークとインターネットとの相互接続のゲートウェイであってもよい。これらのエンティティはより高い計算力および記憶容量を提供し、より大きい電源（電池、主電源）を有し、且つ図示するようにインターネット網（１０４）上で直接、またはゲートウェイおよび中間サーバ（図示せず）を介して、ネットワート上で通信することができる。
【００４４】
ノード（１０２）のネットワークは、当該ネットワークを構成するエンティティ間のレベル２通信（例：８０２．１５．４または８０２．１１）および／またはレベル３通信（例：ＩＰ）に基づいていてよい。使用するプロトコルに応じて、マルチキャストまたはブロードキャスト通信スキームを当該ネットワーク内で用いてよい。
【００４５】
本発明は、ネットワークの２個のノードすなわち「イニシエータ」と呼ばれるソースエンティティおよび「レスポンダ」と呼ばれる目標エンティティとの間で、図４の環境で有利に実装することができる。２個のエンティティは、相互にセキュリティ関連付けを設定する必要がある。信頼できる第三者機関と呼ばれる中央鍵配信サーバ（１０６）は、ノードの認証を担う。当該サーバは、遠隔地にあってセルラネットワークまたはインターネット網である第三者通信ネットワーク（１０４）を介してアクセス可能であってよい。信頼できる第三者機関は、各々のノードの認証に必要な暗号データを保存する。
【００４６】
各イニシエータおよびレスポンダノードが動作する間、自身の一意な証明書、属性モデル、および自身の特定性および制約の各々と最も高い相関を有する独立した認証方法を用いて中央サーバに対して自身を認証する。従って、例えば、２個のノードは、各々の属性の一方をチップカード、他方を生態認証により検証しながら、セッション鍵を設定して、当該セッション鍵を各々の属性に関連付けることができる。トラストサーバは、相互の間でのセキュリティ関連付けの設定を望む２個のノードに同一のセッション鍵を配信することで、各ノードに対して無相関の認証を許すと共に、鍵の設定および／または当該鍵に付随するポリシーに対する集中制御を可能にする。
【００４７】
図５に、図４のネットワークのイニシエータノード（Ｉ）、レスポンダノード（Ｒ）、および信頼できる第三者機関（ＴＣ）の間で公知のＭＩＫＥＹ−Ｔｉｃｋｅｔプロトコルに従い実行されるプロシージャを示す。
【００４８】
本発明の理解を容易にすべく、以下の図５〜７の説明に同一の表記を用いる。従って、
−Ｄａｔａ１、Ｄａｔａ２、等は各々メッセージ１、２、等に含まれるデータの連結を表す。当業者には、本発明が、連結データを含むメッセージの例示的に示す順序に限定されないことが理解されよう。従って、同一のメッセージについて、（Ｄａｔａ１、Ｄａｔａ２）および（Ｄａｔａ２、Ｄａｔａ１）の形式での同一データの送信は等価である。
−Ｅ｛Ｋ、（Ｄａｔａ１、Ｄａｔａ２、等）｝は、鍵Ｋを用いる暗号化アルゴリズムによる連結データ（Ｄａｔａ１、Ｄａｔａ２等）の暗号化を表す。
−ＭＡＣ｛Ｋ、（Ｄａｔａ１、Ｄａｔａ２等）｝は、鍵Ｋを用いる連結データ（Ｄａｔａ１、Ｄａｔａ２等）に対するメッセージ認証コード（ＭＡＣ）表す。
【００４９】
先に説明したように、ＭＩＫＥＹ−Ｔｉｃｋｅｔプロトコルは、信頼できる第三者機関の利用を通じたＭＩＫＥＹプロトコルの拡張と定義されていて、３個のエンティティ、すなわちイニシエータ（Ｉ）、レスポンダ（Ｒ）、および信頼できる第三者機関（ＴＣ）の間における６個のメッセージの交換に基づいている。
【００５０】
イニシエータノードは、第１のメッセージを初期化要求「Ｒｅｑｕｅｓｔ＿ｉｎｉｔ」の形式で信頼できる第三者機関に送信する。要求は、自身の鍵「ＫＩａ」を使用して計算されたる認証コードＭＡＣを含んでいる。ＴＣは、第１のメッセージを受信したならば、イニシエータから送られたＭＡＣおよびデータ（Ｄａｔａ１）の真正性の妥当性を確認する。これらのデータは主としてイニシエータノードがセッションを設定したいレスポンダノードからの識別子、ノンスおよび暗号化に関する情報、並びにイニシエータがサポートするＭＡＣ計算アルゴリズムを含んでいる。
【００５１】
信頼できる第三者機関は、鍵「ＫＩＲ」を生成し、応答メッセージ「Ｒｅｑｕｅｓｔ＿ｒｅｓｐ」に含めてイニシエータに発信する。鍵ＫＩＲは、イニシエータの暗号化鍵「ＫＩｅ」により暗号化される。第２のメッセージは更にイニシエータ用のチケット「ＴｉｃｋｅｔＩ」および鍵ＫＩａを用いて計算されたＭＡＣを含んでいる。
【００５２】
イニシエータは、メッセージを受信したならば、ＭＡＣの妥当性を確認し、レスポンダに付随する２個の鍵「ＫＩＲａ」および「ＫＩｒｅ」を導出可能にする自身の鍵ＫＩＲを復元する。鍵ＫＩＲａはＭＡＣの計算に使用される一方、鍵ＫＩＲｅによりデータの暗号化が可能になる。
【００５３】
イニシエータは次いで、自身のチケット「ＴｉｃｋｅｔＩ」を含むメッセージ「Ｔｒａｎｓｆｅｒｔ＿ｉｎｉｔ」をレスポンダに送信する。この第３のメッセージは、鍵ＫＩＲａを用いて計算されたＭＡＣを含んでいる。
【００５４】
プロトコルの実行の上記レベルでは、レスポンダノード（Ｒ）は未だ鍵ＫＩＲを受信しておらず、従って、鍵ＫＩＲａおよびＫＩＲｅを受信していない点に注意されたい。従って、（Ｒ）は当該ＭＡＣがたった今イニシエータノードから受信した旨の妥当性を確認することができないため、鍵ＫＩＲを渡すよう要請すべくメッセージ「Ｒｅｓｏｌｖｅ＿ｉｎｉｔ」を信頼できる第三者機関（ＴＣ）に送らなければならない。
【００５５】
信頼できる第三者機関は、第４のメッセージを受信したならば、鍵ＫＲａを用いてレスポンダからのＭＡＣの妥当性を確認する。ＭＡＣが妥当な場合、鍵ＫＲｅにより暗号化された鍵ＫＩＲを第５のメッセージ「Ｒｅｓｏｌｖｅ＿ｒｅｓｐ」に含めてレスポンダに送信する。
【００５６】
レスポンダは、第５のメッセージを受信したならば、信頼できる第三者機関により計算されたＭＡＣを確認して鍵ＫＩＲを復元する。レスポンダは、鍵ＫＩＲを受信したならば、鍵ＫＩＲａを計算し、イニシエータにより計算された第３のメッセージ「Ｔｒａｎｓｆｅｒｔ＿ｉｎｉｔ」内のＭＡＣの値を確認する。ＭＡＣの値が妥当な場合、レスポンダは鍵ＫＩＲを受信した旨を肯定応答すべく第６のメッセージ「Ｔｒａｎｓｆｅｒｔ＿ｒｅｓｐ」をイニシエータに送信する。
【００５７】
従って、既に上で議論したように、第３のメッセージに入れられてイニシエータから送信されたＭＡＣをレスポンダノードが取得するのは、信頼できる第三者機関と第４および第５のメッセージを交換した後でしかなく、従ってレスポンダノードはサービス妨害攻撃の目標となり得る。攻撃側ノードは、無数の「Ｔｒａｎｓｆｅｒ＿ｉｎｉｔ」型メッセージ（第３のメッセージ）をレスポンダノードに送りつけることにより、レスポンダノードが多数の「Ｒｅｓｏｌｖｅ＿ｉｎｉｔ」メッセージ（第４のメッセージ）を計算せざるを得ないようにして、レスポンダノードの全ての電力と計算リソースを消耗させることができる。
【００５８】
図６に、本発明の有利な実装例における図４のネットワークのイニシエータ（Ｉ）、レスポンダ（Ｒ）、および信頼できる第三者機関（ＴＣ）エンティティとの間で実行されるプロシージャを示す。
【００５９】
本発明の顕著な利点は、交換されるメッセージの個数が減ることにより得られる、実装された方法の電力効率にある。提案する方法は、図６の実装例による５個のメッセージ交換または図７の実装例による４個のメッセージ交換でイニシエータノードとレスポンダノードとの間における安全な通信の設定を可能にする。２個の例に示す最後のメッセージが、イニシエータとレスポンダとの間で交換され、イニシエータによる暗黙的な鍵の確認に対応する点に注意されたい。イニシエータとレスポンダとの間におけるデータの安全な交換は、各々図６および７における第４および第３のメッセージの後で開始可能である。
【００６０】
当業者には、メッセージ交換がイニシエータノード（Ｉ）およびレシーバノード（Ｒ）に、信頼できる第三者機関（ＴＣ）に対する等価な役割を与えることが理解されよう。その理由は、対話が、
【数１】
2016514913.tif 000003
の形式であるため、信頼できる第三者機関がセッション鍵の設定をより良好に制御できるからである。
【００６１】
図６に示す実装例が有利に適用できるのは、一切の秘密を直接共有しないが、各々が１個以上の秘密を信頼できる第三者機関（ＴＣ）と共有する２個のノード間で安全な通信が設定される場合である。信頼できる第三者機関およびイニシエータは最初に２個の鍵（ＫＩｅ、ＫＩａ）を共有する。ここでＫＩｅはデータ暗号化に用いる鍵であり、ＫＩａはメッセージ認証コード（ＭＡＣ）の計算に用いる鍵である。ＫＩｅおよびＫＩａは、信頼できる第三者機関によるイニシエータの認証に続いてマスター鍵から導出することができる。一方、レスポンダ（Ｒ）も同様に、信頼できる第三者機関と鍵のペア（ＫＲｅ、ＫＲａ）を共有する。
【００６２】
当業者には、図６の変型例の説明を簡素化すべく、イニシエータおよびレスポンダを各々単一のエンティティとして表しているが、より一般的なケースでは個別の鍵および／または一群の鍵を用いる一群のイニシエータノードおよび／または一群のレスポンダノードがあり得ることが理解されよう。
【００６３】
レスポンダ（Ｒ）との安全な通信路を設定すべく、イニシエータ（Ｉ）は信頼できる第三者機関（ＴＣ）にイニシエータ（Ｉ）およびレスポンダ（Ｒ）用に１個以上の鍵を作成させる旨を伝える。プロトコルの記述を簡素化すべく、図６の変型例では、信頼できる第三者機関は２個のノード（Ｉ）および（Ｒ）用に１個の鍵ＫＩＲを生成する。次いで、信頼できる第三者機関は、鍵ＫＩｅにより暗号化された鍵ＫＩＲをイニシエータに送信し、レスポンダに鍵ＫＲｅにより暗号化された鍵ＫＩＲを送信する。交換されるメッセージの完全性は鍵ＫＩａおよびＫＲａにより各々計算されたＭＡＣの追加により保証される。
【００６４】
図６を参照しながらより詳細に述べるに、イニシエータは、第１のメッセージ「メッセージ１」を信頼できる第三者機関に送信することで本方法を開始する。当該メッセージは、イニシエータ（ＩＤＩ）、信頼できる第三者機関（ＩＤＴＣ）、およびレスポンダ（ＩＤＲ）の各々からの識別子を含んでいる。当該メッセージはまた、セッションの鮮度を証明してリプレイ攻撃を避けるために用いるノンス（ＮＩ）を含んでいる。更に、イニシエータは、鍵ＫＩａを用いて（ＩＤＩ、ＩＤＴＣ、ＩＤＲ、ＮＩ）に対して計算されたＭＡＣ（ＭＡＣＩ１）をメッセージ１に追加する。当該ＭＡＣにより、信頼できる第三者機関に対し、第１のメッセージに含めて受信されたデータの真正性を証明することができる。
【００６５】
識別子（ＩＤＩ、ＩＤＴＣ、ＩＤＲ）は使用する技術および設置されているネットワークの種類に依存し得る。これらの識別子は、例えばＩＰｖ６アドレス、ＭＡＣアドレス、またはＵＲＬであってよい。ＩＰネットワークの特別なケースにおいて、識別子ＩＤＩおよびＩＤＴＣは、各々ＩＰパケットのソースアドレスおよび宛先アドレスに対応していてよい。
【００６６】
ノンスは、１個のタイムスタンプ情報、１個の乱数、または１個のカウンタ（シーケンス番号）であってよい。当該情報は、時間に伴い変化するが一意であって、且つ文献「Ｈａｎｄｂｏｏｋ  ｏｆ  ａｐｐｌｉｅｄ  ｃｒｙｐｔｏｇｒａｐｈｙ」の第１０章）に記述されている公知のＭｅｎｅｚｅｓ、Ｖａｎ  Ｏｏｒｓｃｈｏｔ、およびＶａｎｓｔｏｎｅプロトコルの各種の実行を区別可能にする情報でなければならない。ノンスはまた、先に述べた技術を組み合せて形成することができる。例えば、ノンスは１個のタイムスタンプ情報および１個の乱数により形成することができる。
【００６７】
信頼できる第三者機関は、第１のメッセージを受信したならば、ノンス（ＮＩ）の鮮度を確認し、鍵ＫＩａを用いて（ＩＤＩ、ＩＤＴＣ、ＩＤＲおよびＮＩ）に対してＭＡＣ（ＭＡＣＴＣ１）を計算する。次いで、信頼できる第三者機関は、イニシエータから受信したＭＡＣＩ１と自身のＭＡＣ（ＭＡＣＴＣ１）の同等性を確認することにより、受信したメッセージの完全性を確認する。２個の値が等しい場合、信頼できる第三者機関は、レシーバに送信すべく第２のメッセージ「メッセージ２」を生成する。信頼できる第三者機関は、イニシエータおよびレスポンダ用の鍵ＫＩＲを生成することから始める。信頼できる第三者機関は次いで、暗号化鍵ＫＲｅにより引用された当該鍵ＫＩＲをレスポンダに送信する。レスポンダに送信されたメッセージは更に、受信したデータの完全性をレスポンダが確認できるようにするＭＡＣ（ＭＡＣＴＣ２）を含んでいる。
【００６８】
好適な実装例において、信頼できる第三者機関は、暗号Ｅ｛ＫＲｅ、ＫＩＲ，ＩＤＴＣ，ＩＤＩ，ＮＩ）｝を取得すべく鍵ＫＲｅを用いて全体を暗号化する前に、鍵ＫＩＲを識別子ＩＤＩおよびＩＤＴＣ並びにノンスＮＩと連結する。この第２のメッセージはまた、識別子（ＩＤＩ、ＩＤＴＣ、ＩＤＲ）、ノンスＮＩ、およびＭＡＣ（ＭＡＣＴＣ２）を含んでいる。ＭＡＣ（ＭＡＣＴＣ２）は、以下のフィールド、すなわちＩＤＴＣ、ＩＤＲ、ＩＤＩ、ＮＩおよびＥ｛ＫＲｅ、（ＫＩＲ，ＩＤＴＣ，ＩＤＩ，ＮＩ）｝に対して鍵ＫＲａを用いて計算される。
【００６９】
レスポンダは、第２のメッセージを受信したならば、受信したＭＡＣＴ２と、鍵ＫＲａを用いて計算する自身のＭＡＣ値（ＭＡＣＲ２）の同等性を確認する。ＭＡＣＴＣ２の値が正しい場合、レスポンダは鍵ＫＩＲを復元すべく、Ｅ｛ＫＲｅ、ＫＩＲ，ＩＤＴＣ，ＩＤＩ，ＮＩ）｝の内容を復号化する。
【００７０】
レスポンダは、識別子（ＩＤＲ、ＩＤＴＣ、ＩＤＩ）およびノンス（ＮＩ、ＮＲ）データに対して鍵ＫＩＲを用いてノンス（ＮＲ）を生成してＭＡＣ（ＭＡＣＲＩ）を計算する。ＭＡＣ（ＭＡＣＲＩ）は、レスポンダが実際に鍵ＫＩＲを受信したことをイニシエータが確認できるように信頼できる第三者機関からイニシエータに送信される。
【００７１】
第１の変型例において、レスポンダは、２個の鍵「ＫＩＲａ」および「ＫＩＲｅ」を生成する疑似乱数関数の入力として、ノンス（ＮＩ、ＮＲ）および鍵ＫＩＲを用いる。鍵ＫＩＲａはＭＡＣの計算に用いられ、鍵ＫＩＲｅはイニシエータとレスポンダとの間におけるデータ暗号化に用いられる。
【００７２】
第２の変型例において、信頼できる第三者機関は、イニシエータおよびレスポンダ用に２個の鍵「ＫＩＲａ」および「ＫＩＲｅ」を生成する。これらの鍵は信頼できる第三者機関からイニシエータおよびレスポンダに送信され、各々ＭＡＣの計算およびデータの暗号化に用いられる。
【００７３】
表記を簡素化すべく、以下で表記ＫＩＲは、鍵ＫＩＲａおよびＫＩＲｅを生成可能にした方法とは独立に、ＭＡＣの計算および暗号化に用いる鍵の両方を表すために用いる。
【００７４】
レスポンダは、信頼できる第三者機関に向けて第３のメッセージ「メッセージ３」を生成する。当該メッセージは、全ての先行データに対して鍵ＫＲａを用いて計算された識別子（ＩＤＲ）および（ＩＤＴＣ）、ノンス（ＮＲ）および（ＮＩ）、ＭＡＣＲＩおよび新規のＭＡＣ（ＭＡＣＲ３）を含んでいる。
【００７５】
信頼できる第三者機関は、第３のメッセージを受信したならば、ノンスＮＲの鮮度を確認し、鍵ＫＲａおよび識別子（ＩＤＲ、ＩＤＴＣ）を用いてＭＡＣＴＣ３、ノンス（ＮＲ、ＮＩ）、およびＭＡＣ（ＭＡＣＲＩ）データを計算する。
【００７６】
信頼できる第三者機関は次いで、計算されたＭＡＣＴＣ３がレシーバから受信したＭＡＣＲ３に実際に等しいことを確認する。受信したＭＡＣＴＣ３の値が妥当な場合、信頼できる第三者機関はイニシエータに向けてメッセージ「メッセージ４」を生成する。第４のメッセージは、ノンスＮＲおよびＮＩ、ＭＡＣＩＲおよび鍵ＫＩｅにより暗号化された鍵ＫＩＲを含んでいる。
【００７７】
好適な実装例において、鍵ＫＩＲは、レスポンダＩＤＲおよび信頼できる第三者機関ＩＤＴＣの各々からの識別子と、鍵ＫＩｅにより暗号化される前のノンスＮＩおよびＮＲとに連結されて暗号Ｅ｛ＫＩｅ、（ＫＩＲ，ＩＤＲ，ＩＤＴＣ，ＮＩ，ＮＲ）｝を生成する。
【００７８】
信頼できる第三者機関からイニシエータに送信されたメッセージは更に、受信したデータの完全性をイニシエータが確認できるようにする鍵ＫＩａを用いて計算されたＭＡＣ（ＭＡＣＴＣ４）を含んでいる。
【００７９】
イニシエータは、第４のメッセージを受信したならば、自身の鍵ＫＩＡを用いて自身のＭＡＣ（ＭＡＣＩ４）を計算し、次いで信頼できる第三者機関から送信されたＭＡＣ（ＭＡＣＴＣ４）と比較する。
【００８０】
２個のＭＡＣが等しい場合、イニシエータは、鍵ＫＩＲを復元すべく、自身の鍵ＫＩｅを用いてＥ｛ＫＩｅ、（ＫＩＲ，ＩＤＲ，ＩＤＴＣ，ＮＩ，ＮＲ）｝の内容を復号化する。
【００８１】
次に、イニシエータは、レシーバにより計算されて送信された第３のメッセージ内のＭＡＣ（ＭＡＣＲＩ）の値を、鍵ＫＩＲを用いて確認する。この目的のため、イニシエータは、レシーバが（ＭＡＣＲＩ）の計算に用いたものと同一のフィールド、すなわち識別子（ＩＤＲ、ＩＤＴＣ、ＩＤＩ）およびノンス（ＮＩ、ＮＲ）に対してＭＡＣ（ＭＡＣＩＲ）を局所的に計算する。次いで、イニシエータは、自身のＭＡＣＩＲとＭＡＣＲＩの同等性を比較する。２個のＭＡＣが等しい場合、これはレスポンダが信頼できる第三者機関から実際に鍵ＫＩＲを受信したことを意味する。第４のメッセージを正しく受信した旨を肯定応答すべく、イニシエータは、レスポンダに向けてメッセージ「メッセージ５」を生成する。
【００８２】
イニシエータは。イニシエータおよびレスポンダ（ＩＤＩおよびＩＤＲ）の各々からの識別子、識別子のノンス（ＮＩ、ＮＲ）および鍵ＫＩＲにより計算したＭＡＣ（ＭＡＣＩ５）を含む第５のメッセージ５を直接レスポンダに送信する。
【００８３】
レスポンダは、第５のメッセージを受信したならば、自身のＭＡＣ（ＭＡＣＲ５）を計算することにより、受信したＭＡＣ（ＭＡＣＩ５）の値を確認する。２個のＭＡＣが等しい場合、レスポンダＲは、イニシエータが信頼できる第三者機関から実際に鍵ＫＩＲを受信したものと結論付ける。
【００８４】
図７に、４個のメッセージ交換を含む本発明の変型実装例における図４のネットワークのイニシエータ、レスポンダおよび信頼できる第三者エンティティとの間で実行されるプロシージャを示す。
【００８５】
イニシエータは、第１のメッセージ「メッセージ１」を信頼できる第三者機関に送信することで本方法を開始する。第１のメッセージの内容は、図６に関して記述したものと同一である。
【００８６】
信頼できる第三者機関ＴＣは、メッセージ１を受信した後で、ノンス（ＮＴＣ）、およびイニシエータとレスポンダ用に鍵ＫＩＲを生成する。ノンスＮＴＣは、レスポンダがメッセージの鮮度に、イニシエータおよび信頼できる第三者機関からの新規のノンスの受信を関連付けた場合に第２のメッセージへの鮮度の追加を可能にするオプションのパラメータである。
【００８７】
ノンス（ＮＴＣ）の追加は、ネットワークの管理人によりセキュリティポリシーが設定された場合に決定することができる。
【００８８】
信頼できる第三者機関は鍵ＫＲｅを用いてノンスを暗号化するが、鍵ＫＩＲおよび当該同一の鍵ＫＩＲは、イニシエータと共有される鍵ＫＩｅよびＫＩａにより完全性の観点から暗号化されて保護されている。暗号は、第２のメッセージ「メッセージ２ｂｉｓ」に含めてレスポンダに送信される。当該メッセージは更に、受信したデータの完全性をレスポンダが確認できるように、鍵ＫＲａを用いて計算されたＭＡＣを含んでいる。
【００８９】
レスポンダは、第２のメッセージを受信した後で、受信したメッセージの完全性および真正性を自身の鍵ＫＲａを用いて確認する。確認した結果が肯定的である場合、レスポンダは共有鍵ＫＩＲを復元すべくメッセージを復号化する。
【００９０】
次に、レスポンダはノンス（ＮＲ）を生成し、次いで信頼できる第三者機関ＴＣから第２のメッセージに含めて受信された、信頼できる第三者機関とイニシエータにより共有される鍵ＫＩｅおよびＫＩａを用いて暗号化されて認証された鍵ＫＩＲを含むデータを、第３のメッセージ「メッセージ３ｂｉｓ」に含めて送信する。レスポンダが実際に共有鍵ＫＩＲを受信したことをイニシエータが確認できるように、レスポンダはまた、当該鍵ＫＩＲを用いて計算されたＭＡＣも送信する。
【００９１】
イニシエータは、第３のメッセージを受信したならば、信頼できる第三者機関が鍵ＫＩａを用いて生成したメッセージの第１部分の完全性を確認する。確認が成功であった場合、イニシエータは自身の鍵ＫＩｅを用いて共有鍵ＫＩＲを復元する。次いで、イニシエータは鍵ＫＩＲを用いて、レスポンダから送信されたＭＡＣを確認する。
【００９２】
イニシエータは次いで、イニシエータおよびレスポンダ（ＩＤＩ、ＩＤＲ）の各々からの識別子、それらのノンス（ＮＩ、ＮＲ）、および鍵ＫＩＲを用いて計算されたＭＡＣ（ＭＡＣＩ５）を含む第４のメッセージを直接レスポンダに送信する。
【００９３】
レスポンダは、第４のメッセージを受信したならば、受信したＭＡＣＩ５の値を、自身のＭＡＣＲ５を計算することにより確認する。２個のＭＡＣが等しい場合、レスポンダは、イニシエータが信頼できる第三者機関から鍵ＫＩＲを実際に受信したものと結論付ける。
【００９４】
当業者には、本発明の原理を保持しながら、好適に説明した本方法を変更できることが理解されよう。従って、上述の例は好適なプロトコルに基づいているが、他の認証プロトコルを用いることも可能である。
【００９５】
本発明は、ハードウェアおよび／またはソフトウェア構成要素に基づいて実装できる。コンピュータ可読媒体上のコンピュータプログラム製品としても入手可能である。当該媒体は、電子、磁気、光、電磁気または赤外線型のブロードキャスト媒体であってよい。そのような媒体の例として、半導体メモリ（ランダムアクセスメモリＲＡＭ、読取専用メモリＲＯＭ）、テープ、フロッピー（登録商標）ディスク、あるいは磁気または光ディスク（コンパクトディスク−読取専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−読取／書込（ＣＤ−Ｒ／Ｗ）およびＤＶＤ）がある。
【図１】
2016514913.tif 000004
【図２】
2016514913.tif 000005
【図３】
2016514913.tif 000006
【図４】
2016514913.tif 000007
【図５】
2016514913.tif 000008
【図６】
2016514913.tif 000009
【図７】
2016514913.tif 000010
【国際調査報告】
2016514913.tif 000011
2016514913.tif 000012
2016514913.tif 000013
2016514913.tif 000014
2016514913.tif 000015
2016514913.tif 000016