(57)【特許請求の範囲】
【請求項１】
ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための方法あって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであるかどうかを認証サーバと検証するステップと、
ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップであって、鍵がドメイン内のネットワークノードと別のネットワークノードの間での使用のためである、ステップと
を含む、方法。
【請求項２】
検証するステップが、
身元を照会するための要求メッセージを、ネットワークノードに送信するステップと、
ネットワークノードから、身元を照会するための応答メッセージを受信するステップであって、応答メッセージがネットワークノードの身元の情報を含む、受信するステップと、
ネットワークノードの身元が適格であるかどうかを検証するステップと、
認証情報を照会するための要求メッセージを、ネットワークノードに送信するステップと、
ネットワークノードから、認証情報を照会するための応答メッセージを受信するステップと、
認証情報が適格であるかどうかを検証するステップと、
認証情報が適格である場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップと
を含む、請求項１に記載の方法。
【請求項３】
ネットワークノードの身元および認証情報が、ＲＡＤＩＵＳ認証またはＤＩＡＭＥＴＥＲ認証に基づいて検証される、請求項２に記載の方法。
【請求項４】
ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップが、
ＥＡＰ認証で定義されたメッセージにおける「Ｔｙｐｅ−Ｄａｔａ」の定義を拡張することによって、ＰＴＰプロトコル用の鍵の送信を実装するステップ
を含む、請求項１に記載の方法。
【請求項５】
ＰＴＰプロトコル用の鍵の送信が、新しいＥＡＰ認証方式を定義するための、ＥＡＰメッセージにおける「Ｅｘｐａｎｄｅｄ  Ｔｙｐｅ」を定義することによって実装される、請求項１に記載の方法。
【請求項６】
ＰＴＰプロトコル鍵が、暗号化されたテキストの形式で送信される、請求項１に記載の方法。
【請求項７】
ＰＴＰプロトコル用の鍵が、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む、請求項１に記載の方法。
【請求項８】
ＰＴＰプロトコル用の鍵が、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび秘密鍵を含む、請求項１に記載の方法。
【請求項９】
ＰＴＰプロトコルデータパケットを暗号化するために、通信ネットワークのネットワークノードで使用するための方法であって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであることがドメイン制御デバイスによって検証された後、ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するステップＡと、
ＰＴＰプロトコルに従って、鍵を用いて、ドメイン内の別のネットワークノードとの暗号化通信を実施するステップＢと
を含む、方法。
【請求項１０】
ＰＴＰプロトコル用の鍵が、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび第１の秘密鍵を含み、第１の秘密鍵が、ネットワークノードの身元情報に基づいて、ドメイン制御デバイスによって生成され、
ステップＢが、
ユニキャストＰＴＰデータパケットを送信するときに、第１の秘密鍵および受信ノードの身元情報に基づいて、ユニキャストＰＴＰデータパケットのためのデジタル署名を生成するステップ、およびユニキャストＰＴＰデータパケットのテキスト本文を暗号化するステップと、
第１の秘密鍵および送信ノードの身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための復号化およびデジタル署名検証を実施するステップと
を含む、請求項９に記載の方法。
【請求項１１】
ネットワークノードが、マルチキャストまたはブロードキャストＰＴＰデータパケットをさらに送信および受信し、ＰＴＰプロトコル用の鍵が、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたマルチキャストグループまたはブロードキャストグループのための身元情報、および身元情報に基づいて生成された第２の秘密鍵をさらに含み、
ステップＢが、
マルチキャストまたはブロードキャストＰＴＰデータパケットを送信するときに、第１の秘密鍵、およびマルチキャストグループまたはブロードキャストグループの身元情報に基づいて、マルチキャストまたはブロードキャストＰＴＰデータパケットのためのデジタル署名を生成するステップ、およびマルチキャストまたはブロードキャストＰＴＰデータパケットのテキスト本文を暗号化するステップと、
第２の秘密鍵および送信ノードの身元情報に基づいて、受信されたマルチキャストまたはブロードキャストＰＴＰデータパケットのための復号化およびデジタル署名検証を実施するステップと
をさらに含む、請求項１０に記載の方法。
【請求項１２】
ＰＴＰプロトコル用の鍵が、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含み、
ステップＢが、
ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を用いて、ＰＴＰデータパケットのためのセキュリティ保護を実施するステップと、
ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を用いて、ＰＴＰデータパケットのためのセキュリティ検証を実施するステップと
を含む、請求項９に記載の方法。
【請求項１３】
ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための装置であって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであるかどうかを認証サーバと検証するように構成された第１の検証手段と、
ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するように構成された第１の送信手段であって、鍵がドメイン内のネットワークノードと別のネットワークノードの間での使用のためである、第１の送信手段と
を含む、装置。
【請求項１４】
通信ネットワークのネットワークノードにおいて、ＰＴＰプロトコルデータパケットを暗号化するための装置であって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであることがドメイン制御デバイスによって検証された後、ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するように構成された第１の受信手段と、
ＰＴＰプロトコルに従って、鍵を用いて、ドメイン内の別のネットワークノードとの暗号化通信を実施するように構成された暗号化通信手段と
を含む、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＰＴＰプロトコルに関し、詳細には、ＰＴＰプロトコルにおける暗号化に関する。
【背景技術】
【０００２】
分散システムにおいて、クロック同期は、多くの用途のために必須の技術である。最も代表的なクロック同期プロトコルの１つが、ＩＥＥＥ１５８８プロトコルであり、ＰＴＰプロトコル（Ｐｒｅｃｉｓｉｏｎ  Ｔｉｍｉｎｇ  Ｐｒｏｔｏｃｏｌ：高精度時間プロトコル）とも呼ばれる。ＰＴＰプロトコルの主な原理は、分散システムが正確な同期に到達することができるように、同期信号を通して、ネットワークにおけるすべてのノードのクロックに対して周期的に補正同期を実施することである。マスタースレーブクロックのモデルベースのＰＴＰプロトコルは、実装するのに簡単でわかりやすいという利点を有するものの、より一層の研究により、ＰＴＰプロトコルは、悪意のある攻撃または障害に脆弱であることがわかっている。典型的な例として、ＰＴＰプロトコルは、悪意のあるマスタークロック、たとえば、時間を改ざんするＢｙｚａｎｔｉｎｅまたはＢａｂｂｌｉｎｇ  ｉｄｉｏｔに対処することができない。
【０００３】
ＰＴＰプロトコルは、ＡｎｎｅｘＫにおいて実験的なセキュリティ拡張を提供し、すなわち、攻撃者が直接アクセスを得ることができるオープンな環境において、クロック同期のための「ネイティブな」セキュリティサポートを提示する。ＰＴＰプロトコルは、対称なメッセージ認証符号化関数を使用して、グループソース認証、メッセージ完全性、および再生保護を提供する。プロトコルにおける参加者は、ドメイン全体内またはドメインのサブセット内で共有されてよい対称鍵を共有する。現在、対称鍵の配布は手動で構成されており、したがって、柔軟性にかなり乏しい。各ネットワークノードで構成されるために必要な鍵の数は、ドメインにおけるノードの数、およびこれらのノード間での送受信関係に直接比例する。ネットワーク管理者にとって、そのような莫大な数の鍵を構成する／リフレッシュすることは、そう容易なことではない。現在のソリューションでは、静的鍵が各ネットワークノードに記憶されており、このことは機密性に乏しいという欠点を有する。セキュリティの観点からは、静的鍵よりも、動的鍵がより望ましい。
【０００４】
ＰＴＰプロトコルのＡｎｎｅｘＫにおけるセキュリティ拡張は、追跡をサポートしない。ＡｎｎｅｘＫは、対称なメッセージ認証符号化関数を使用し、すなわち、あらゆる任意のノードがその通信ピアの暗号化鍵を知っており、その結果、悪意のあるノードは、追跡されることなく、ピアノードの名前でＰＴＰメッセージを送出することができる。悪意のあるノードが、マルチキャストまたはブロードキャストＰＴＰメッセージを送信した場合は、さらに悪いことになる。
【０００５】
鍵の配布は、手動で構成されても、または自動鍵管理プロトコルを通して行われてもよい。ＰＴＰプロトコルにおけるＡｎｎｅｘＫは、鍵の手動構成、およびＡｎｎｅｘＫの仕様に従った構成パスワードに基づく鍵の自動生成をサポートする。ネイティブなセキュリティサポートは、他の将来のメッセージ認証のための可能性を提供する。
【０００６】
加えて、ＰＴＰプロトコルにおけるＡｎｎｅｘＫは、既定のチャレンジレスポンス認証方法をサポートするのみであり、他の認証方法はサポートしていない。したがって、その柔軟性はかなり乏しい。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｓｉｇｎｃｒｙｐｔｉｏｎ、Ｊｏｈｎ  Ｍａｌｏｎｅ−Ｌｅｅ、Ｃｒｙｐｔｏｌｏｇｙ  ｅＰｒｉｎｔ  Ａｒｃｈｉｖｅ、Ｒｅｐｏｒｔ２００２／０９８、２００２．ｈｔｔｐ：／／ｅｐｒｉｎｔ．ｉａｃｒ．ｏｒｇ／
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＰＴＰプロトコルにおいて、鍵の配布は、手動で構成されても、または自動鍵管理プロトコルを通して行われてもよい。ＰＴＰプロトコルにおけるＡｎｎｅｘＫは、鍵の手動構成、および構成パスワードに基づく鍵の自動生成をサポートする。本発明は、自動的にＰＴＰ鍵を配布する技術的なソリューションを提供し、それを基にして、新しい暗号化方法を提供する。
【課題を解決するための手段】
【０００９】
本発明の実施形態によれば、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための方法が提供され、方法は、以下のステップを含む：ネットワークノードがドメインにおける適格なノードであるかどうかを検証するステップ、ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップ。
【００１０】
本発明の別の実施形態によれば、ＰＴＰプロトコルデータパケットを暗号化するために、通信ネットワークのネットワークノードで使用するための方法が提供され、方法は、以下のステップを含む：ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するステップ、ＰＴＰプロトコルに従って、鍵を用いて、ドメイン内の別のネットワークノードとの暗号化通信を実施するステップ。
【００１１】
本発明のさらなる実施形態によれば、ＰＴＰプロトコル鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための装置が提供され、装置は、以下を含む：ネットワークノードがドメインにおける適格なノードであるかどうかを検証するように構成された第１の検証手段、ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するように構成された第１の送信手段。
【００１２】
本発明のさらに別の実施形態によれば、ＰＴＰプロトコルデータパケットを暗号化するために、通信ネットワークのネットワークノードで使用するための装置が提供され、装置は、以下を含む：ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するように構成された第１の受信手段、ＰＴＰプロトコルに従って、鍵を利用して、ドメイン内の他のネットワークノードとの暗号化通信を実施するように構成された暗号化通信手段。
【００１３】
本発明による方法および装置は、さまざまな形態のＰＴＰネットワークノードのアクセス認証、ならびにＰＴＰ鍵の自動構成および動的送信を可能にし、その結果、鍵のセキュリティが大幅に強化される。加えて、ＳｉｇｎＣｒｙｐｔｉｏｎ暗号化アルゴリズムを採用することによって、ＰＴＰメッセージごとに、メッセージソースの認証、メッセージ完全性の認証、メッセージの機密性、および再生保護が提供され得るだけでなく、その送信ネットワークノードもまた追跡され得ることが可能にされる。したがって、セキュリティは著しく強化される。
【００１４】
添付の図面を参照し、以下の非限定的な実施形態についての詳細な説明を通して、本発明の他の特徴、目的、および効果が、さらに明らかになるであろう。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態による適用シナリオの図である。
【図２】本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布する方法の流れ図である。
【図３】本発明の実施形態による、図２におけるステップＳ２０１のサブステップの流れ図である。
【図４】ＲＡＤＩＵＳ認証に基づいた方法の流れ図である。
【図５】ＰＴＰ上で動作するＥＡＰのプロトコルアーキテクチャの図である。
【図６】ＥＡＰ認証方法を利用することによって、ネットワークノード２１を認証するためのＥＡＰメッセージのフォーマットの図である。
【図７】新しいＥＡＰ認証方法を利用することによって、ネットワークノード２１を認証するためのＥＡＰメッセージのフォーマットの図である。
【図８】本発明の実施形態による、通信ネットワークのネットワークノード内でＰＴＰプロトコルデータパケットを暗号化する方法の流れ図である。
【図９】本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するための装置９００の構造図である。
【図１０】本発明の実施形態による、通信ネットワークのネットワークノード内でＰＴＰプロトコルデータパケットを暗号化する装置１００の構造図である。
【発明を実施するための形態】
【００１６】
図面全体を通して、同じもしくは類似した参照番号は、同じもしくは対応するステップの特徴または手段（モジュール）を示す。
【００１７】
以下では、添付の図面を参照して、本発明の実施形態が詳細に説明される。
【００１８】
図１は、本発明の実施形態による適用シナリオの図である。図１は、ドメイン１０、およびそのドメイン内の複数のネットワークノード２１、２２、２３などを示す。ＰＴＰプロトコル鍵のための自動配布デバイスとして働くドメイン制御デバイスが存在する。ドメインは、一般に、ネットワークにおける適用範囲である。この範囲内のエンティティは、許可されたアクセス権限を有し、一方で、この範囲を超えたエンティティは、ドメイン権限の制御を受け、アクセスできないことになる。ドメインは、比較的厳格な管理モードである。通常、ドメインおよびドメイン制御デバイスは、ネットワークセキュリティにとって極めて重要である、中央管理およびセキュリティ制御を実施するために利用される。
【００１９】
図２は、本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布する方法の流れ図である。図３は、本発明の実施形態による、図２におけるステップＳ２０１のサブステップの流れ図である。
【００２０】
以下では、図１のドメイン制御デバイスについて、ＰＴＰプロトコル鍵を配布するプロセスが詳細に説明される。
【００２１】
図２を参照すると、最初にステップＳ２０１で、ドメイン制御デバイス１１が、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証する。
【００２２】
ネットワークノード２１がドメインにおける適格なノードである場合、ステップＳ２０２で、ＰＴＰプロトコル用の鍵がネットワークノード２１に送信される。
【００２３】
具体的には、ドメイン制御デバイスが、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証するためのいくつかの方式がある。一実施形態が、図３に示される。
【００２４】
最初に、ステップＳ３０１で、ドメイン制御デバイス１１は、身元（ｉｄｅｎｔｉｔｙ）を照会するための要求メッセージを、ネットワークノード２１に送信する。
【００２５】
次に、ステップＳ３０２で、ドメイン制御デバイス１１は、ネットワークノード２１から、身元を照会するための応答メッセージを受信し、応答メッセージは、ネットワークノード２１の身元情報を含む。
【００２６】
ステップＳ３０３で、ドメイン制御デバイス１１は、ネットワークノード２１の身元が適格であるかどうかを検証する。
【００２７】
ステップ３０４で、ネットワークノード２１の身元が適格である場合、認証情報を照会するための要求メッセージがネットワークノード２１に送信される。
【００２８】
ステップＳ３０５で、ドメイン制御デバイス１１は、ネットワークノード２１から、認証情報を照会するための応答メッセージを受信する。
【００２９】
ステップＳ３０６で、ドメイン制御デバイス１１は、ネットワークノード２１の認証情報が適格であるかどうかを検証する。
【００３０】
ネットワークノード２１の認証情報が適格である場合、ステップＳ３０７で、ドメイン制御デバイス１１は、ＰＴＰプロトコル用の鍵をネットワークノード２１に送信する。
【００３１】
ドメイン制御デバイス１１が、ネットワークノード２１の身元が適格であるかどうかを検証するための、およびネットワークノード２１の認証情報が適格であるかどうかを検証するための、いくつかの方式がある。たとえば、ＲＡＤＩＵＳベースの認証（ＲＦＣ２８６９）、またはＤＩＡＭＥＴＥＲベースの認証（ＲＦＣ３５８８）が使用されてよい。図４は、ＲＡＤＩＵＳベースの認証の方法の流れ図であり、ここで、ステップＳ３０１、Ｓ３０２、Ｓ３０４、Ｓ３０５、およびＳ３０７は、上で言及されたものと同じであり、ここでは詳述されない。ステップＳ３０２の後、ドメイン制御デバイス１１は、ステップＳ４０１を実施して、第１のアクセス照会要求メッセージをリモートサーバ３１に送信し、ここで、第１のアクセス照会要求メッセージは、ネットワークノード２１の身元情報を含む。第１のアクセス照会要求メッセージを受信した後で、リモートサーバ３１は、ネットワークノードの記憶されている身元情報を照会して、ネットワークノードの身元情報が存在するかどうかを判定し、存在する場合は、ネットワークノード２１の身元が適格であるとみなされる。次いでステップＳ４０２で、アクセスチャレンジ要求メッセージがドメイン制御デバイス２１に送信され、アクセスチャレンジ要求メッセージは、ネットワークノード２１の認証情報について要求するために使用される。
【００３２】
アクセスチャレンジ要求メッセージを受信した後で、ドメイン制御デバイス１１は、ステップＳ３０４およびＳ３０５、次いでＳ４０３を実施し、第２のアクセス照会要求メッセージがリモートサーバ３１に送信され、第２のアクセス照会要求メッセージは、ネットワークノード２１の認証情報を含む。リモートサーバ３１は、ネットワークノード２１からの認証情報が適格であるかどうかを検証し、適格である場合、ステップＳ４０４で、アクセス受信応答メッセージがドメイン制御デバイス１１に送信される。これ以後、ドメイン制御デバイス１１は、ステップＳ３０７を実施する。
【００３３】
アクセスチャレンジ要求および認証情報の例が、Ｃｈａｌｌｅｎｇｅ（ＲＮ）であり、ここで、ＲＮは乱数であり、
【００３４】
【数１】
0005744231.tif 000002
ここで、Ｋｅｙは、ネットワークノード２１のためのあらかじめ構成された鍵を示し、Ｈは、認証プロトコルによって、たとえば、ＭＤ５によって指定されたハッシュ関数であってよい。リモートサーバ３１は、認証情報応答を受信し、それを、リモートサーバ３１自身によって計算された
【００３５】
【数２】
0005744231.tif 000003
の値と比較する。一致した場合、認証情報は適格である。アクセスチャレンジ要求および認証情報はこれに限定されないこと、および、いかなる任意の他の形式の認証メカニズム、たとえば、ワンタイムパスワード（ＯＴＰ）、トランスポートレイヤセキュリティ（ＴＬＳ）なども許可されることに留意されたい。
【００３６】
当然ながら、ドメイン制御デバイス１が、ネットワークノード２１の身元情報および認証情報を事前記憶している場合は、図４に示されるようなＲＡＤＩＵＳ認証、または他の認証を実施する必要はない。
【００３７】
ネットワークノード２１を認証し、ＰＴＰプロトコル用の鍵を送信するためのドメイン制御デバイス１１のプロセスが、機能の観点から詳細に説明されてきた。具体的には、一実施形態において、ドメイン制御デバイス１１は、ＥＡＰ認証を用いて、ネットワークノード２１がドメイン１０における適格なノードであるかどうかを検証することができる。以下では、それが詳細に説明される。
【００３８】
ＥＡＰは、よく知られ、一般的に使用される、ＲＦＣ３７４８で定義されたセキュリティ認証プロトコルである。ＥＡＰは、さまざまな種類の下位のトランスポートプロトコル上で動作することができる。本発明は、ＰＴＰプロトコルを対象としているため、ＰＴＰ上で動作するＥＡＰを使用することが好ましい。当然ながら、本発明はこれに限定されない。別のプロトコル上で動作するＥＡＰを使用することもまた、ネットワークノード２１がドメイン１０における適格なノードであるかどうかの認証を実現することができる。たとえば、ＵＤＰ上で動作するＥＡＰ、またはイーサネット（登録商標）上で動作するＥＡＰが使用されてもよい。
【００３９】
図５は、ＰＴＰ上で動作するＥＡＰのプロトコルアーキテクチャの図である。図６は、ＥＡＰ認証処理を用いて、ネットワークノード２１を認証するためのＥＡＰメッセージのフォーマットの図である。図６では、使用されることになる既存のＥＡＰ認証処理が示されている。ＲＦＣ３７４８の定義に従って、「Ｃｏｄｅ」が１であるとき、それはＥＡＰ要求メッセージであり、「Ｃｏｄｅ」が２であるとき、それはＥＡＰ応答メッセージである。「Ｉｄｅｎｔｉｆｉｅｒ」は、ＥＡＰ要求メッセージとＥＡＰ応答メッセージとを適合させるための１ビット長の整数である。新しいＥＡＰ要求メッセージは、このフィールドの値を変更しなければならない。「Ｌｅｎｇｔｈ」は、ＥＡＰメッセージ全体の長さを示す。「Ｔｙｐｅ」は、ＥＡＰ要求またはＥＡＰ応答のタイプである。Ｔｙｐｅ−ｄａｔａの内容は、タイプによって決定される。たとえば、「Ｔｙｐｅ」値＝１のとき、それは、ネットワークノード２１の身元を照会するための「Ｉｄｅｎｔｉｔｙ」を表す。「Ｔｙｐｅ」値＝４のとき、それは、「ＭＤ５−Ｃｈａｌｌｅｎｇｅ」を表し、これは、ＰＰＰ  ＣＨＡＰプロトコルに類似し、ネットワークノード２１の認証情報を照会するための問い合わせメッセージを含む。すなわち、図３を参照すると、ステップＳ３０１で、「Ｃｏｄｅ」値は１であり、「Ｔｙｐｅ」値は１である。ステップＳ３０２で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は１であり、「Ｔｙｐｅ−Ｄａｔａ」は、ネットワークノード２１の身元情報である。ステップＳ３０４およびＳ３０５は、例としてのＥＡＰ  ＭＤ５  Ｃｈａｌｌｅｇｅ認証方式を用いて説明されるので、「Ｔｙｐｅ」値は４である。ステップＳ３０４で、「Ｃｏｄｅ」値は１であり、ステップＳ３０５で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ−Ｄａｔａ」は、ネットワークノード２１の認証情報である。ステップＳ３０７におけるＰＴＰプロトコル用の鍵の配信は、新しい「Ｃｏｄｅ」および／または新しい「Ｔｙｐｅ」を定義するように、かつ「Ｔｙｐｅ−Ｄａｔａ」における新しいフィールドを定義するようにＥＡＰプロトコルを拡張することによって、あるいは、新しい「Ｔｙｐｅ」を定義し、かつ「Ｔｙｐｅ−Ｄａｔａ」における新しいフィールドを定義するようにＥＡＰプロトコルの既存のメッセージを拡張することによって、実施されてよい。ＳＵＣＣＥＳＳメッセージを拡張するために、引き続きＥＡＰ  ＭＤ５−Ｃｈａｌｌｅｇｅ認証方式を例に取ると、新たに定義された「Ｔｙｐｅ−Ｄａｔａ」がＳＵＣＣＥＳＳメッセージの中に追加されて、ＰＴＰプロトコル用の鍵を送信する。このケースで、「Ｃｏｄｅ」値は３であり、「Ｔｙｐｅ」のタイプは、拡張された定義の新しいタイプであってよい。このタイプは、ＰＴＰプロトコル用の鍵を送信するために、「Ｔｙｐｅ−Ｄａｔａ」においてＰＴＰプロトコルの鍵フィールドを示す。
【００４０】
図６は、既存のＥＡＰ認証処理を用いて、ネットワークノード２１を認証するシナリオを示す。図７は、本発明の実施形態による、新しいＥＡＰ認証を定義するメッセージフォーマットを示す。ステップＳ３０１、Ｓ３０２、Ｓ３０４、およびＳ３０５における認証メッセージの送信、ならびにステップＳ３０７におけるＰＴＰプロトコル用の鍵の送信は、２５４である「Ｔｙｐｅ」による拡張されたＥＡＰメッセージを利用して実施され、ここで、メッセージフォーマットが図７に示されている。メッセージの内容は、「Ｖｅｎｄｏｒ  Ｄａｔａ」フィールドにおいて送信され、ＰＴＰプロトコル用の鍵は、「Ｖｅｎｄｏｒ  Ｄａｔａ」において１つまたは複数のフィールドを追加することによって送信されてよい。
【００４１】
ステップＳ３０１で、「Ｃｏｄｅ」値は１であり、「Ｔｙｐｅ」値は２５４であり、「Ｖｅｎｄｏｒ−ＩＤ」は、定義を拡張して、たとえば、ＩＥＥＥ１５８８  ＰＩＰのための特定のタイプ値を確保し、サポートされた認証プロトコルごとに特定の「Ｖｅｎｄｏｒ−ＩＤ」を配布することができる。ステップＳ３０２で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は２５４であり、「Ｖｅｎｄｏｒ−Ｄａｔａ」は、ネットワークノード２１の身元情報である。ステップＳ３０４で、「Ｃｏｄｅ」値は１であり、「Ｔｙｐｅ」値は２５４である。ステップＳ３０５で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は２５４４であり、「Ｖｅｎｄｏｒ−Ｄａｔａ」は、ネットワークノード２１の認証情報である。ステップＳ３０７におけるＰＴＰプロトコル用の鍵の送信は、「Ｖｅｎｄｏｒ−Ｄａｔａ」において新しいフィールドを定義することによって実施されてよい。このケースで、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は２５４であり、図６に示されるようなオリジナル認証プロトコルによって定義されたフィールドに加えて、「Ｖｅｎｄｏｒ−Ｄａｔａ」においてＰＴＰプロトコルの鍵フィールドが追加される。
【００４２】
ステップＳ２０２におけるＰＴＰプロトコル用の鍵の送信は、平文テキストで、または暗号化で実施されてよいことに留意されたい。暗号化は、ステップＳ２０１での認証段階中に合意された鍵によって行われてよい。たとえば、図６または図７で、ネットワークノード２１は、ドメイン制御デバイス１１においてＴＬＳプロトコルを通して認証される。ＴＬＳ用のデータ暗号化鍵は、認証が完了する間に合意されてよい。したがって、ＰＴＰプロトコル用の鍵への暗号化送信を実施するために、データ暗号化鍵が利用されてよい。
【００４３】
利用される異なる暗号化方式に基づいて、たとえば、ＰＴＰプロトコルのＡｎｎｅｘＫで定義されたハッシュ関数暗号化方式（ＩＥＥＥ  １５８８−２００８）などの、ＰＴＰプロトコル用の鍵の複数の形式があってよく、この場合、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む。たとえば、暗号化およびデジタル署名は、身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズム（Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｓｉｇｎｃｒｙｐｔｉｏｎ、Ｊｏｈｎ  Ｍａｌｏｎｅ−Ｌｅｅ、Ｃｒｙｐｔｏｌｏｇｙ  ｅＰｒｉｎｔ  Ａｒｃｈｉｖｅ、Ｒｅｐｏｒｔ２００２／０９８、２００２．ｈｔｔｐ：／／ｅｐｒｉｎｔ．ｉａｃｒ．ｏｒｇ／）を採用することによって実施されてよく、この場合、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび秘密鍵を含む。以下では、２つのアルゴリズムが詳細に説明される。
【００４４】
図８は、本発明の実施形態による、通信ネットワークのネットワークノード内でＰＴＰプロトコルデータパケットを暗号化する方法の流れ図である。以下では、図１に示されたような適用シナリオを参照して、ネットワークノード２１においてＰＴＰプロトコルデータパケットを暗号化する方法が詳細に説明される。
【００４５】
最初に、ステップＳ８０１で、ネットワークノード２１が、本ネットワークノードが属するドメイン内のドメイン制御デバイス１１から、ＰＴＰプロトコル用の鍵を受信する。
【００４６】
次に、ステップＳ８０２で、ネットワークノード２１は、ＰＴＰプロトコルに従って、ステップＳ８０１で受信された鍵を用いて、ドメイン１０内の別のネットワークノードとの暗号化通信を実施する。
【００４７】
上で述べたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび第１の鍵を含み、ここで、第１の鍵は、ネットワークノード２１の身元情報に基づいて、ドメイン制御デバイスによって生成される。具体的には、ステップＳ８０２が、以下のサブステップを含む：ユニキャストＰＴＰデータパケットを送信するときに、第１の鍵および受信ノードの身元情報に基づいて、ユニキャストＰＴＰデータパケットのためのデジタル署名を生成するステップ、およびユニキャストＰＴＰデータパケットのテキスト本文を暗号化するステップ、ならびに第１の鍵および送信ノードの身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための暗号化およびデジタル署名認証を実施するステップ。
【００４８】
以下では、Ｊｏｈｎによる身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎを参照して、ユニキャストシナリオにおける、デジタル署名の生成、暗号化、復号化、およびデジタル署名認証のやり方が簡単に説明される。一般性を損なうことなく、詳細な説明は、ネットワークノード２１とネットワークノード２２との通信の例を用いて行われる。ネットワークノード２１の身元情報をＩＤａ、およびネットワークノード２２の身元情報をＩＤｂとすることにする。
【００４９】
Ｐ、
【００５０】
【数３】
0005744231.tif 000004
Ｈ１、Ｈ２、Ｈ３、およびＱＴＡは、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムのために定義されたシステム論破パラメータである。それらは、具体的には以下のように定義される：（Ｇ，＋）および（Ｖ，・）は、ｑの素数次数を有する巡回群である。Ｐは、巡回群Ｇの生成元である。プロトコル実装パフォーマンス要件およびプロトコルデータグラムオーバーヘッドを考慮して、楕円曲線によって生成された巡回群を使用することが推奨される。
【００５１】
【数４】
0005744231.tif 000005
は、身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムの要件を満たす双一次変換である。Ｈ１、Ｈ２、およびＨ３は、あらかじめ定義されたハッシュ関数であって、ここで、
【００５２】
【数５】
0005744231.tif 000006
【００５３】
【数６】
0005744231.tif 000007
【００５４】
【数７】
0005744231.tif 000008
であり、ここで、ｎは、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムによって処理されるメッセージの長さを表し、Ｇ＊＝Ｇ＼｛０｝である。
【００５５】
以下の記述において、シンボル
【００５６】
【数８】
0005744231.tif 000009
は、ビット文字列の接続を表し、
【００５７】
【数９】
0005744231.tif 000010
は、ビット文字列がビットごとのＸＯＲであることを表し、＋は、選択された巡回群で定義された加法演算を表し、
【００５８】
【数１０】
0005744231.tif 000011
は、
【００５９】
【数１１】
0005744231.tif 000012
から無作為に値を選択し、その値をｔに与えることを表す。
【００６０】
システムの初期化時に、ドメイン制御デバイスは、最初に、身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムのシステムパラメータのＰ、
【００６１】
【数１２】
0005744231.tif 000013
Ｈ１、Ｈ２、およびＨ３を選択する。次いで、ドメイン全体のＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムのシステム構成パラメータが完全に決定されるまで、
【００６２】
【数１３】
0005744231.tif 000014
が無作為に選択され、ＱＴＡがｔＰとして計算される。ドメイン制御デバイスは、Ｐ、
【００６３】
【数１４】
0005744231.tif 000015
Ｈ１、Ｈ２、Ｈ３、およびＱＴＡを開示することができ、すなわち、これらのパラメータを、ドメイン１０内のそれぞれのネットワークノードを通知することができる。ドメイン制御デバイス１１によってのみ知られる乱数として、ｔは、ドメイン全体のマスター鍵である。
【００６４】
ネットワークノード２１については、それがドメイン１０の中に追加されるとき、ドメイン制御デバイス１１に登録される必要がある。ドメイン制御デバイス１１は、ネットワークノード２１を検証する。ネットワークノード２１が認証に成功した場合にのみ、ドメイン制御デバイス１１は、ネットワークノード２１がドメイン１０の中に追加されることを許可する。ドメイン制御デバイス１１は、認証処理の間に、ネットワークノード２１の身元ＩＤを取得する。ネットワークノード２１が認証に成功した後で、そのＩＤに基づいて、ネットワークノード２１のための秘密鍵ＳＩＤ＝ｔＱＩＤが計算され、ここで、ＱＩＤ＝Ｈ１（ＩＤ）である。秘密鍵は、システム構成パラメータＰ、
【００６５】
【数１５】
0005744231.tif 000016
Ｈ１、Ｈ２、Ｈ３、およびＱＴＡと共に、ネットワークノード２１に配布される。セキュリティを保証するために、これらのパラメータは、配布プロセスの間に、必要に応じて、暗号化され、保護されてよい。ネットワークノード２１が登録を完了し、ＳｉｇｎＣｒｙｐｔｉｏｎのシステム構成パラメータ、ならびにその秘密鍵を取得した後で、ネットワークノード２１は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムを利用することによって、ドメイン内の他のノードとセキュアに通信することができる。
【００６６】
メッセージを送信するとき、ネットワークノード２１は、以下の規定に従ってメッセージを処理する：
【００６７】
【数１６】
0005744231.tif 000017
ここで、ｍは、ネットワークノード２１によって、ネットワークノード２２に送信されることになるＰＴＰプロトコルメッセージであり、ｃは、暗号化されたメッセージであり、ＵおよびＶは、ｍに基づいて生成されたデジタル署名であり、σは、暗号化され、デジタル署名が添付されたＰＴＰプロトコルメッセージである。
【００６８】
暗号化された署名付きのメッセージを受信した後で、ネットワークノード２２は、その秘密鍵および送信ノード（すなわち、ネットワークノード２１）の身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための復号化およびデジタル署名認証を、以下のプロセスで実施する：
Ｕｎｓｉｇｎｃｒｙｐｔ（ＩＤａ，ＳＩＤｂ，σ）
ＱＩＤａ＝Ｈ１（ＩＤａ）
σを（ｃ，Ｕ，Ｖ）として構文解析する
【００６９】
【数１７】
0005744231.tif 000018
ｋ＝ｙ
ｍ＝ｋ□ｃ
【００７０】
【数１８】
0005744231.tif 000019
【００７１】
【数１９】
0005744231.tif 000020
の場合、
⊥を返す（メッセージが無効であり、破棄されるべきであることを示す）
ｍを返す
【００７２】
【数２０】
0005744231.tif 000021
が、
【００７３】
【数２１】
0005744231.tif 000022
に等しくない場合、ネットワークノード２２は、この署名は正しくないものと判定し、メッセージｍを破棄する、または無視する。
【００７４】
当然ながら、ネットワークノード２１が、受信されたユニキャストメッセージに、どのように復号化およびデジタル署名検証を実施するかのプロセスも、上で言及されたものと同様である。
【００７５】
マルチキャストまたはブロードキャストデータパケットの送信および受信のために、ドメイン制御デバイス１１は、マルチキャスト（またはブロードキャスト）ごとに身元情報を定義し、身元に基づいて第２の秘密鍵を生成し、第２の秘密鍵を、マルチキャスト（またはブロードキャスト）データパケットの受信を要求するネットワークノード、たとえば、ネットワークノード２１に送信する。マルチキャストまたはブロードキャストＰＴＰデータパケットを送信するとき、ネットワークノード２１は、それ自身の第１の秘密鍵、そのマルチキャストグループまたはブロードキャストグループの身元情報に基づいて、マルチキャストまたはブロードキャストＰＴＰデータパケットへのデジタル署名を生成し、マルチキャストまたはブロードキャストＰＴＰデータパケットのテキスト本文を暗号化し、マルチキャスト（またはブロードキャスト）グループの第２の秘密鍵および送信ノードの身元情報に基づいて、受信されたマルチキャストまたはブロードキャストＰＴＰデータパケットのための復号化およびデジタル署名認証を実施する。
【００７６】
上で言及されたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫによって定義された共有対称鍵を含む。具体的には、共有対称鍵の数は、ネットワークノード２１が通信する必要のあるネットワークノードの数によって決まる。具体的には、ステップＳ８０２が、以下のサブステップを含む：ネットワークノード２１は、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ保護を実施し、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ検証を実施する。
【００７７】
以下では、ＰＴＰプロトコルのＡｎｎｅｘＫを参照して、ネットワークノード２１がどのように、共有対称鍵を用いて、送受信されるデータパケットのためのセキュリティ保護およびセキュリティ検証を実施するかが詳細に説明される。
【００７８】
ＰＴＰプロトコルがＡｎｎｅｘＫをサポートするとき、すべてのＰＴＰメッセージは、フィールドＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶを保持しなければならず、フラグフィールドのためのセキュリティフラグ（ｆｌａｇＦｉｅｌｄ．Ｓｅｃｕｒｅ）を設定する。ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおける「Ｉｎｔｅｇｒｉｔｙ  Ｃｈｅｃｋ  Ｖａｌｕｅ」フィールドは、メッセージ全体の完全性を保証するためのものである。ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおけるアルゴリズムＩＤによって識別されるメッセージ認証符号化関数（たとえば、ＰＴＰプロトコルのＡｎｎｅｘＫにおいて定義されるＨＭＡＣ−ＳＨＡ１−９６またはＨＭＡＣ−ＳＨＡ２５６−１２８関数）、および鍵ＩＤによって識別される鍵を、ＰＴＰメッセージ全体に適用することによって、ＩＣＶが取得される。
【００７９】
一般性を損なうことなく、ネットワークノード２１とネットワークノード２２との通信を例に取ると、それらの共有対称鍵が、Ｋであり、ｍは、ネットワークノード２１によって、ネットワークノード２２に送信されることになるＰＴＰプロトコルデータパケットである。ネットワークノード２１は、必要に応じて、ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおける該当フィールドに、たとえば、アルゴリズムＩＤ、鍵ＩＤなど書き込み、ここで、ＩＣＶ値はゼロであり、初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶが、メッセージｍに添付される。ネットワークノード２１は、ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおけるアルゴリズムＩＤ、鍵ＩＤ、および初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶが添付されたＰＴＰメッセージに基づいて、完全性チェック値フィールド＝Ｈ（初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶのＰＴＰメッセージ、Ｋが添付されている）を計算し、ここで、Ｈは、ＰＴＰプロトコルのＡｎｎｅｘＫにおいて定義されるＨＭＡＣ−ＳＨＡ１−９６またはＨＭＡＣ−ＳＨＡ２５６−１２８関数である。ネットワークノード２１は、この結果を使用して、初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおけるＩＣＶフィールドを変更し、ＩＣＶが変更されたＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶフィールドを有するメッセージを、ネットワークノード２２に送信する。ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶを保持するメッセージｍを受信した後で、ネットワークノード２２は、上で言及されたのと同じ方法を使用して、ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおけるアルゴリズムＩＤ、鍵ＩＤ、および受信されたｍを計算し、それを、受信されたメッセージ内のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＴＬＶにおいて保持されたＩＣＶ値と比較する。それらが一致しない場合、メッセージｍを破棄する、または無視する。ネットワークノード２１はまた、ネットワークノード２２から受信されたＰＴＰプロトコルメッセージに対してそのようなチェックを実施する。
【００８０】
図９は、本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するための装置９００の構造図であり、装置９００は、第１の検証手段９０１と、第１の送信手段９０２とを含む。一実施形態において、第１の検証手段９０１は、第２の送信手段９０１１と、第２の受信手段９０１２と、第２の検証手段９０１３と、第３の送信手段９０１４と、第３の受信手段９０１５と、第３の検証手段９０１６とを含む。
【００８１】
以下では、ドメイン制御デバイス１１における装置９００の作業手順に関して詳細な説明がなされる。
【００８２】
最初に、第１の検証手段９０１が、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証する。
【００８３】
ネットワークノードがドメインにおける適格なノードである場合、第１の送信手段９０２が、ＰＴＰプロトコル用の鍵をネットワークノードに送信する。
【００８４】
具体的には、第１の検証手段９０１が、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証するためのいくつかの方式がある。一実施形態が、以下に示される。
【００８５】
最初に、第２の送信手段９０１１が、身元を照会するための要求メッセージを、ネットワークノード２１に送信する。
【００８６】
次に、第２の受信手段９０１２が、ネットワークノード２１から、身元を照会するための応答メッセージを受信し、応答メッセージは、ネットワークノード２１の身元情報を含む。
【００８７】
第２の検証手段９０１３が、ネットワークノード２１の身元が適格であるかどうかを検証する。
【００８８】
ネットワークノード２１の身元が適格である場合、第３の送信手段９０１４が、認証情報を照会するための要求メッセージを、ネットワークノード２１に送信する。
【００８９】
第３の受信手段９０１５が、ネットワークノード２１から、認証情報を照会するための応答メッセージを受信する。
【００９０】
第３の検証手段９０１６が、ネットワークノード２１の認証情報が適格であるかどうかを検証する。
【００９１】
ネットワークノード２１の認証情報が適格である場合、第１の送信手段９０２は、ＰＴＰプロトコル用の鍵をネットワークノード２１に送信する。
【００９２】
第２の検証手段９０１３が、ネットワークノード２１の身元が適格であるかどうかを検証するための、および第３の検証手段９０１６が、ネットワークノード２１の認証情報が適格であるかどうかを検証するための複数の方式、たとえば、ＲＡＤＩＵＳベースの認証（ＲＦＣ２８６９）、またはＤＩＡＭＥＴＥＲベースの認証（ＲＦＣ３５８８）がある。
【００９３】
一実施形態において、第１の検証手段９０１は、ＥＡＰ認証を用いて、ネットワークノード２１がドメイン１０における適格なノードであるかどうかを検証することができる。第１の送信手段９０２は、ＥＡＰ認証処理で定義されたメッセージにおける定義「Ｔｙｐｅ−Ｄａｔａ」を拡張することによって、ＰＴＰプロトコル用の鍵の送信を実装する。別の実施形態において、第１の送信手段９０２は、ＥＡＰメッセージにおける「Ｅｘｐａｎｄｅｄ  Ｔｙｐｅ」を定義することによって、ＰＴＰプロトコル用の鍵の送信を実装し、それにより、新しいＥＡＰ認証方式を定義する。ＰＴＰプロトコル用の鍵は、暗号化されたテキストの形式、または平文テキストの形式で送信されてよい。一実施形態において、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む。別の実施形態において、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび秘密鍵を含む。
【００９４】
図１０は、本発明の一実施形態による、通信ネットワークのネットワークノードにおいて、ＰＴＰプロトコルデータパケットを暗号化するための装置１００の構造ブロック図である。以下では、ネットワークノード２１において、装置１００についてＰＴＰプロトコルデータパケットを暗号化するプロセスが詳細に説明される。
【００９５】
最初に、第１の受信手段１０１が、本ネットワークノードが属するドメイン内のドメイン制御デバイス１１から、ＰＴＰプロトコル用の鍵を受信する。
【００９６】
次に、暗号化通信手段１０２が、ＰＴＰプロトコルに従って、鍵を利用して、ドメイン内の別のネットワークノードとの暗号化通信を実施する。
【００９７】
上で述べたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび第１の鍵を含み、ここで、第１の鍵は、ネットワークノード２１の身元情報に基づいて、ドメイン制御デバイス１０によって生成される。具体的には、暗号化通信手段１０２は、以下の機能を実施する：ユニキャストＰＴＰデータパケットを送信するときに、第１の鍵および受信ノードの身元情報に基づいて、ユニキャストＰＴＰデータパケットへのデジタル署名を生成すること、およびユニキャストＰＴＰデータパケットのテキスト本文を暗号化すること、ならびに、第１の鍵および受信ノードの身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための暗号化およびデジタル署名認証を実施すること。
【００９８】
マルチキャストまたはブロードキャストデータパケットの送信および受信のために、ドメイン制御デバイス１１は、マルチキャスト（またはブロードキャスト）ごとに身元情報を定義し、身元に基づいて第２の秘密鍵を生成し、第２の秘密鍵を、マルチキャスト（またはブロードキャスト）データパケットの受信を要求するネットワークノード、たとえば、ネットワークノード２１に送信する。ネットワークノード２１がマルチキャストまたはブロードキャストＰＴＰデータパケットを送信するとき、暗号化通信手段１０２は、それ自身の第１の秘密鍵、そのマルチキャストグループまたはブロードキャストグループの身元情報に基づいて、マルチキャストまたはブロードキャストＰＴＰデータパケットへのデジタル署名を生成し、マルチキャストまたはブロードキャストＰＴＰデータパケットのテキスト本文を暗号化し、マルチキャスト（またはブロードキャスト）グループの第２の秘密鍵および送信ノードの身元情報に基づいて、受信されたマルチキャストまたはブロードキャストＰＴＰデータパケットのための復号化およびデジタル署名認証を実施する。
【００９９】
上で述べたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む。具体的には、共有対称鍵の数は、ネットワークノード２１が通信する必要のあるネットワークノードの数によって決まる。具体的には、暗号化通信手段１０２は、以下の機能を実施する：ネットワークノード２１は、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ保護を実施し、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ検証を実施する。
【０１００】
本発明の趣旨から逸脱しない、いずれの任意の技術的なソリューションも、本発明の保護範囲の中に含まれるべきである。加えて、特許請求の範囲におけるいずれの参照番号も、特許請求の範囲を限定するものとしてみなされるべきでない。用語「含む（ｃｏｍｐｒｉｓｅ）」は、特許請求の範囲または明細書において規定されていない他の手段またはステップを排除しない。手段の前の「ａ」は、より多くの同様の手段の存在を排除しない。複数の手段を含む装置において、複数の手段のうちの１つまたは複数の機能は、同じハードウェアモジュールまたはソフトウェアモジュールによって実装されてもよい。「第１の」、「第２の」、および「第３の」などの語句は、いずれの特定の順序を示すことなく、単なる呼び名を表す。
【０１０１】
本発明の具体的な実施形態が上で説明されてきた。本発明は、上の特定の実施形態に限定されないことに留意されたい。当業者は、添付の特許請求の範囲内でのさまざまな変更形態または修正形態を行うことができる。
【図１】
0005744231.tif 000023
【図２】
0005744231.tif 000024
【図３】
0005744231.tif 000025
【図４】
0005744231.tif 000026
【図５】
0005744231.tif 000027
【図６】
0005744231.tif 000028
【図７】
0005744231.tif 000029
【図８】
0005744231.tif 000030
【図９】
0005744231.tif 000031
【図１０】
0005744231.tif 000032