特許 5744231 ＰＴＰプロトコル用の鍵を配布するための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5744231

(24)【登録日】2015年5月15日

(45)【発行日】2015年7月8日

(54)【発明の名称】ＰＴＰプロトコル用の鍵を配布するための方法および装置

(51)【国際特許分類】

   H04L 9/08 20060101AFI20150618BHJP

   H04L 9/32 20060101ALI20150618BHJP

   H04W 12/04 20090101ALI20150618BHJP

   H04W 12/06 20090101ALI20150618BHJP

【ＦＩ】

   H04L9/00 601C

   H04L9/00 675A

   H04W12/04

   H04W12/06

【請求項の数】14

【全頁数】20

(21)【出願番号】特願2013-548902(P2013-548902)

(86)(22)【出願日】2012年1月3日

(65)【公表番号】特表2014-504826(P2014-504826A)

(43)【公表日】2014年2月24日

(86)【国際出願番号】IB2012000061

(87)【国際公開番号】WO2012095741

(87)【国際公開日】20120719

【審査請求日】2013年9月11日

(31)【優先権主張番号】201110005208.9

(32)【優先日】2011年1月12日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】110001173

【氏名又は名称】特許業務法人川口國際特許事務所

(72)【発明者】

【氏名】ヤオ，イーフオン

【審査官】 脇岡 剛

(56)【参考文献】

【文献】 国際公開第２０１０／０２２３３８（ＷＯ，Ａ１）

【文献】 特開２００１−３４４２１４（ＪＰ，Ａ）

【文献】 特表２０１１−５２５３０８（ＪＰ，Ａ）

【文献】 特開２００８−１９３６９８（ＪＰ，Ａ）

【文献】 国際公開第２００４／１０７６７１（ＷＯ，Ａ１）

【文献】 特開２０１０−１０３９７０（ＪＰ，Ａ）

【文献】 特開２００９−０４８５０８（ＪＰ，Ａ）

【文献】 特開２００４−３１２２５７（ＪＰ，Ａ）

【文献】 特表２０１２−５０１１０８（ＪＰ，Ａ）

【文献】 馬場 達也，マスタリングＩＰｓｅｃ 第２版，株式会社オライリー・ジャパン，２００６年 ８月１８日，２１１〜２１４頁

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／０８

Ｈ０４Ｌ ９／３２

Ｈ０４Ｗ １２／０４

Ｈ０４Ｗ １２／０６

(57)【特許請求の範囲】

【請求項1】

ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための方法あって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであるかどうかを認証サーバと検証するステップと、
ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップであって、鍵がドメイン内のネットワークノードと別のネットワークノードの間での使用のためである、ステップと
を含む、方法。

【請求項2】

検証するステップが、
身元を照会するための要求メッセージを、ネットワークノードに送信するステップと、
ネットワークノードから、身元を照会するための応答メッセージを受信するステップであって、応答メッセージがネットワークノードの身元の情報を含む、受信するステップと、
ネットワークノードの身元が適格であるかどうかを検証するステップと、
認証情報を照会するための要求メッセージを、ネットワークノードに送信するステップと、
ネットワークノードから、認証情報を照会するための応答メッセージを受信するステップと、
認証情報が適格であるかどうかを検証するステップと、
認証情報が適格である場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップと
を含む、請求項１に記載の方法。

【請求項3】

ネットワークノードの身元および認証情報が、ＲＡＤＩＵＳ認証またはＤＩＡＭＥＴＥＲ認証に基づいて検証される、請求項２に記載の方法。

【請求項4】

ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップが、
ＥＡＰ認証で定義されたメッセージにおける「Ｔｙｐｅ−Ｄａｔａ」の定義を拡張することによって、ＰＴＰプロトコル用の鍵の送信を実装するステップ
を含む、請求項１に記載の方法。

【請求項5】

ＰＴＰプロトコル用の鍵の送信が、新しいＥＡＰ認証方式を定義するための、ＥＡＰメッセージにおける「Ｅｘｐａｎｄｅｄ Ｔｙｐｅ」を定義することによって実装される、請求項１に記載の方法。

【請求項6】

ＰＴＰプロトコル鍵が、暗号化されたテキストの形式で送信される、請求項１に記載の方法。

【請求項7】

ＰＴＰプロトコル用の鍵が、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む、請求項１に記載の方法。

【請求項8】

ＰＴＰプロトコル用の鍵が、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび秘密鍵を含む、請求項１に記載の方法。

【請求項9】

ＰＴＰプロトコルデータパケットを暗号化するために、通信ネットワークのネットワークノードで使用するための方法であって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであることがドメイン制御デバイスによって検証された後、ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するステップＡと、
ＰＴＰプロトコルに従って、鍵を用いて、ドメイン内の別のネットワークノードとの暗号化通信を実施するステップＢと
を含む、方法。

【請求項10】

ＰＴＰプロトコル用の鍵が、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび第１の秘密鍵を含み、第１の秘密鍵が、ネットワークノードの身元情報に基づいて、ドメイン制御デバイスによって生成され、
ステップＢが、
ユニキャストＰＴＰデータパケットを送信するときに、第１の秘密鍵および受信ノードの身元情報に基づいて、ユニキャストＰＴＰデータパケットのためのデジタル署名を生成するステップ、およびユニキャストＰＴＰデータパケットのテキスト本文を暗号化するステップと、
第１の秘密鍵および送信ノードの身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための復号化およびデジタル署名検証を実施するステップと
を含む、請求項９に記載の方法。

【請求項11】

ネットワークノードが、マルチキャストまたはブロードキャストＰＴＰデータパケットをさらに送信および受信し、ＰＴＰプロトコル用の鍵が、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたマルチキャストグループまたはブロードキャストグループのための身元情報、および身元情報に基づいて生成された第２の秘密鍵をさらに含み、
ステップＢが、
マルチキャストまたはブロードキャストＰＴＰデータパケットを送信するときに、第１の秘密鍵、およびマルチキャストグループまたはブロードキャストグループの身元情報に基づいて、マルチキャストまたはブロードキャストＰＴＰデータパケットのためのデジタル署名を生成するステップ、およびマルチキャストまたはブロードキャストＰＴＰデータパケットのテキスト本文を暗号化するステップと、
第２の秘密鍵および送信ノードの身元情報に基づいて、受信されたマルチキャストまたはブロードキャストＰＴＰデータパケットのための復号化およびデジタル署名検証を実施するステップと
をさらに含む、請求項１０に記載の方法。

【請求項12】

ＰＴＰプロトコル用の鍵が、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含み、
ステップＢが、
ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を用いて、ＰＴＰデータパケットのためのセキュリティ保護を実施するステップと、
ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を用いて、ＰＴＰデータパケットのためのセキュリティ検証を実施するステップと
を含む、請求項９に記載の方法。

【請求項13】

ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための装置であって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであるかどうかを認証サーバと検証するように構成された第１の検証手段と、
ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するように構成された第１の送信手段であって、鍵がドメイン内のネットワークノードと別のネットワークノードの間での使用のためである、第１の送信手段と
を含む、装置。

【請求項14】

通信ネットワークのネットワークノードにおいて、ＰＴＰプロトコルデータパケットを暗号化するための装置であって、
ＥＡＰ認証方式でネットワークノードがドメインにおける適格なノードであることがドメイン制御デバイスによって検証された後、ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するように構成された第１の受信手段と、
ＰＴＰプロトコルに従って、鍵を用いて、ドメイン内の別のネットワークノードとの暗号化通信を実施するように構成された暗号化通信手段と
を含む、装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＰＴＰプロトコルに関し、詳細には、ＰＴＰプロトコルにおける暗号化に関する。

【背景技術】

【0002】

分散システムにおいて、クロック同期は、多くの用途のために必須の技術である。最も代表的なクロック同期プロトコルの１つが、ＩＥＥＥ１５８８プロトコルであり、ＰＴＰプロトコル（Ｐｒｅｃｉｓｉｏｎ Ｔｉｍｉｎｇ Ｐｒｏｔｏｃｏｌ：高精度時間プロトコル）とも呼ばれる。ＰＴＰプロトコルの主な原理は、分散システムが正確な同期に到達することができるように、同期信号を通して、ネットワークにおけるすべてのノードのクロックに対して周期的に補正同期を実施することである。マスタースレーブクロックのモデルベースのＰＴＰプロトコルは、実装するのに簡単でわかりやすいという利点を有するものの、より一層の研究により、ＰＴＰプロトコルは、悪意のある攻撃または障害に脆弱であることがわかっている。典型的な例として、ＰＴＰプロトコルは、悪意のあるマスタークロック、たとえば、時間を改ざんするＢｙｚａｎｔｉｎｅまたはＢａｂｂｌｉｎｇ ｉｄｉｏｔに対処することができない。

【0003】

ＰＴＰプロトコルは、ＡｎｎｅｘＫにおいて実験的なセキュリティ拡張を提供し、すなわち、攻撃者が直接アクセスを得ることができるオープンな環境において、クロック同期のための「ネイティブな」セキュリティサポートを提示する。ＰＴＰプロトコルは、対称なメッセージ認証符号化関数を使用して、グループソース認証、メッセージ完全性、および再生保護を提供する。プロトコルにおける参加者は、ドメイン全体内またはドメインのサブセット内で共有されてよい対称鍵を共有する。現在、対称鍵の配布は手動で構成されており、したがって、柔軟性にかなり乏しい。各ネットワークノードで構成されるために必要な鍵の数は、ドメインにおけるノードの数、およびこれらのノード間での送受信関係に直接比例する。ネットワーク管理者にとって、そのような莫大な数の鍵を構成する／リフレッシュすることは、そう容易なことではない。現在のソリューションでは、静的鍵が各ネットワークノードに記憶されており、このことは機密性に乏しいという欠点を有する。セキュリティの観点からは、静的鍵よりも、動的鍵がより望ましい。

【0004】

ＰＴＰプロトコルのＡｎｎｅｘＫにおけるセキュリティ拡張は、追跡をサポートしない。ＡｎｎｅｘＫは、対称なメッセージ認証符号化関数を使用し、すなわち、あらゆる任意のノードがその通信ピアの暗号化鍵を知っており、その結果、悪意のあるノードは、追跡されることなく、ピアノードの名前でＰＴＰメッセージを送出することができる。悪意のあるノードが、マルチキャストまたはブロードキャストＰＴＰメッセージを送信した場合は、さらに悪いことになる。

【0005】

鍵の配布は、手動で構成されても、または自動鍵管理プロトコルを通して行われてもよい。ＰＴＰプロトコルにおけるＡｎｎｅｘＫは、鍵の手動構成、およびＡｎｎｅｘＫの仕様に従った構成パスワードに基づく鍵の自動生成をサポートする。ネイティブなセキュリティサポートは、他の将来のメッセージ認証のための可能性を提供する。

【0006】

加えて、ＰＴＰプロトコルにおけるＡｎｎｅｘＫは、既定のチャレンジレスポンス認証方法をサポートするのみであり、他の認証方法はサポートしていない。したがって、その柔軟性はかなり乏しい。

【先行技術文献】

【非特許文献】

【0007】

【非特許文献1】Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ｓｉｇｎｃｒｙｐｔｉｏｎ、Ｊｏｈｎ Ｍａｌｏｎｅ−Ｌｅｅ、Ｃｒｙｐｔｏｌｏｇｙ ｅＰｒｉｎｔ Ａｒｃｈｉｖｅ、Ｒｅｐｏｒｔ２００２／０９８、２００２．ｈｔｔｐ：／／ｅｐｒｉｎｔ．ｉａｃｒ．ｏｒｇ／

【発明の概要】

【発明が解決しようとする課題】

【0008】

ＰＴＰプロトコルにおいて、鍵の配布は、手動で構成されても、または自動鍵管理プロトコルを通して行われてもよい。ＰＴＰプロトコルにおけるＡｎｎｅｘＫは、鍵の手動構成、および構成パスワードに基づく鍵の自動生成をサポートする。本発明は、自動的にＰＴＰ鍵を配布する技術的なソリューションを提供し、それを基にして、新しい暗号化方法を提供する。

【課題を解決するための手段】

【0009】

本発明の実施形態によれば、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための方法が提供され、方法は、以下のステップを含む：ネットワークノードがドメインにおける適格なノードであるかどうかを検証するステップ、ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するステップ。

【0010】

本発明の別の実施形態によれば、ＰＴＰプロトコルデータパケットを暗号化するために、通信ネットワークのネットワークノードで使用するための方法が提供され、方法は、以下のステップを含む：ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するステップ、ＰＴＰプロトコルに従って、鍵を用いて、ドメイン内の別のネットワークノードとの暗号化通信を実施するステップ。

【0011】

本発明のさらなる実施形態によれば、ＰＴＰプロトコル鍵をドメイン内のネットワークノードに配布するために、通信ネットワークのドメイン制御デバイスで使用するための装置が提供され、装置は、以下を含む：ネットワークノードがドメインにおける適格なノードであるかどうかを検証するように構成された第１の検証手段、ネットワークノードがドメインにおける適格なノードである場合に、ＰＴＰプロトコル用の鍵をネットワークノードに送信するように構成された第１の送信手段。

【0012】

本発明のさらに別の実施形態によれば、ＰＴＰプロトコルデータパケットを暗号化するために、通信ネットワークのネットワークノードで使用するための装置が提供され、装置は、以下を含む：ネットワークノードが属するドメイン内のドメイン制御デバイスから、ＰＴＰプロトコル用の鍵を受信するように構成された第１の受信手段、ＰＴＰプロトコルに従って、鍵を利用して、ドメイン内の他のネットワークノードとの暗号化通信を実施するように構成された暗号化通信手段。

【0013】

本発明による方法および装置は、さまざまな形態のＰＴＰネットワークノードのアクセス認証、ならびにＰＴＰ鍵の自動構成および動的送信を可能にし、その結果、鍵のセキュリティが大幅に強化される。加えて、ＳｉｇｎＣｒｙｐｔｉｏｎ暗号化アルゴリズムを採用することによって、ＰＴＰメッセージごとに、メッセージソースの認証、メッセージ完全性の認証、メッセージの機密性、および再生保護が提供され得るだけでなく、その送信ネットワークノードもまた追跡され得ることが可能にされる。したがって、セキュリティは著しく強化される。

【0014】

添付の図面を参照し、以下の非限定的な実施形態についての詳細な説明を通して、本発明の他の特徴、目的、および効果が、さらに明らかになるであろう。

【図面の簡単な説明】

【0015】

【図1】本発明の実施形態による適用シナリオの図である。

【図2】本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布する方法の流れ図である。

【図3】本発明の実施形態による、図２におけるステップＳ２０１のサブステップの流れ図である。

【図4】ＲＡＤＩＵＳ認証に基づいた方法の流れ図である。

【図5】ＰＴＰ上で動作するＥＡＰのプロトコルアーキテクチャの図である。

【図6】ＥＡＰ認証方法を利用することによって、ネットワークノード２１を認証するためのＥＡＰメッセージのフォーマットの図である。

【図7】新しいＥＡＰ認証方法を利用することによって、ネットワークノード２１を認証するためのＥＡＰメッセージのフォーマットの図である。

【図8】本発明の実施形態による、通信ネットワークのネットワークノード内でＰＴＰプロトコルデータパケットを暗号化する方法の流れ図である。

【図9】本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するための装置９００の構造図である。

【図10】本発明の実施形態による、通信ネットワークのネットワークノード内でＰＴＰプロトコルデータパケットを暗号化する装置１００の構造図である。

【発明を実施するための形態】

【0016】

図面全体を通して、同じもしくは類似した参照番号は、同じもしくは対応するステップの特徴または手段（モジュール）を示す。

【0017】

以下では、添付の図面を参照して、本発明の実施形態が詳細に説明される。

【0018】

図１は、本発明の実施形態による適用シナリオの図である。図１は、ドメイン１０、およびそのドメイン内の複数のネットワークノード２１、２２、２３などを示す。ＰＴＰプロトコル鍵のための自動配布デバイスとして働くドメイン制御デバイスが存在する。ドメインは、一般に、ネットワークにおける適用範囲である。この範囲内のエンティティは、許可されたアクセス権限を有し、一方で、この範囲を超えたエンティティは、ドメイン権限の制御を受け、アクセスできないことになる。ドメインは、比較的厳格な管理モードである。通常、ドメインおよびドメイン制御デバイスは、ネットワークセキュリティにとって極めて重要である、中央管理およびセキュリティ制御を実施するために利用される。

【0019】

図２は、本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布する方法の流れ図である。図３は、本発明の実施形態による、図２におけるステップＳ２０１のサブステップの流れ図である。

【0020】

以下では、図１のドメイン制御デバイスについて、ＰＴＰプロトコル鍵を配布するプロセスが詳細に説明される。

【0021】

図２を参照すると、最初にステップＳ２０１で、ドメイン制御デバイス１１が、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証する。

【0022】

ネットワークノード２１がドメインにおける適格なノードである場合、ステップＳ２０２で、ＰＴＰプロトコル用の鍵がネットワークノード２１に送信される。

【0023】

具体的には、ドメイン制御デバイスが、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証するためのいくつかの方式がある。一実施形態が、図３に示される。

【0024】

最初に、ステップＳ３０１で、ドメイン制御デバイス１１は、身元（ｉｄｅｎｔｉｔｙ）を照会するための要求メッセージを、ネットワークノード２１に送信する。

【0025】

次に、ステップＳ３０２で、ドメイン制御デバイス１１は、ネットワークノード２１から、身元を照会するための応答メッセージを受信し、応答メッセージは、ネットワークノード２１の身元情報を含む。

【0026】

ステップＳ３０３で、ドメイン制御デバイス１１は、ネットワークノード２１の身元が適格であるかどうかを検証する。

【0027】

ステップ３０４で、ネットワークノード２１の身元が適格である場合、認証情報を照会するための要求メッセージがネットワークノード２１に送信される。

【0028】

ステップＳ３０５で、ドメイン制御デバイス１１は、ネットワークノード２１から、認証情報を照会するための応答メッセージを受信する。

【0029】

ステップＳ３０６で、ドメイン制御デバイス１１は、ネットワークノード２１の認証情報が適格であるかどうかを検証する。

【0030】

ネットワークノード２１の認証情報が適格である場合、ステップＳ３０７で、ドメイン制御デバイス１１は、ＰＴＰプロトコル用の鍵をネットワークノード２１に送信する。

【0031】

ドメイン制御デバイス１１が、ネットワークノード２１の身元が適格であるかどうかを検証するための、およびネットワークノード２１の認証情報が適格であるかどうかを検証するための、いくつかの方式がある。たとえば、ＲＡＤＩＵＳベースの認証（ＲＦＣ２８６９）、またはＤＩＡＭＥＴＥＲベースの認証（ＲＦＣ３５８８）が使用されてよい。図４は、ＲＡＤＩＵＳベースの認証の方法の流れ図であり、ここで、ステップＳ３０１、Ｓ３０２、Ｓ３０４、Ｓ３０５、およびＳ３０７は、上で言及されたものと同じであり、ここでは詳述されない。ステップＳ３０２の後、ドメイン制御デバイス１１は、ステップＳ４０１を実施して、第１のアクセス照会要求メッセージをリモートサーバ３１に送信し、ここで、第１のアクセス照会要求メッセージは、ネットワークノード２１の身元情報を含む。第１のアクセス照会要求メッセージを受信した後で、リモートサーバ３１は、ネットワークノードの記憶されている身元情報を照会して、ネットワークノードの身元情報が存在するかどうかを判定し、存在する場合は、ネットワークノード２１の身元が適格であるとみなされる。次いでステップＳ４０２で、アクセスチャレンジ要求メッセージがドメイン制御デバイス２１に送信され、アクセスチャレンジ要求メッセージは、ネットワークノード２１の認証情報について要求するために使用される。

【0032】

アクセスチャレンジ要求メッセージを受信した後で、ドメイン制御デバイス１１は、ステップＳ３０４およびＳ３０５、次いでＳ４０３を実施し、第２のアクセス照会要求メッセージがリモートサーバ３１に送信され、第２のアクセス照会要求メッセージは、ネットワークノード２１の認証情報を含む。リモートサーバ３１は、ネットワークノード２１からの認証情報が適格であるかどうかを検証し、適格である場合、ステップＳ４０４で、アクセス受信応答メッセージがドメイン制御デバイス１１に送信される。これ以後、ドメイン制御デバイス１１は、ステップＳ３０７を実施する。

【0033】

アクセスチャレンジ要求および認証情報の例が、Ｃｈａｌｌｅｎｇｅ（ＲＮ）であり、ここで、ＲＮは乱数であり、

【0034】

【数1】

ここで、Ｋｅｙは、ネットワークノード２１のためのあらかじめ構成された鍵を示し、Ｈは、認証プロトコルによって、たとえば、ＭＤ５によって指定されたハッシュ関数であってよい。リモートサーバ３１は、認証情報応答を受信し、それを、リモートサーバ３１自身によって計算された

【0035】

【数2】

の値と比較する。一致した場合、認証情報は適格である。アクセスチャレンジ要求および認証情報はこれに限定されないこと、および、いかなる任意の他の形式の認証メカニズム、たとえば、ワンタイムパスワード（ＯＴＰ）、トランスポートレイヤセキュリティ（ＴＬＳ）なども許可されることに留意されたい。

【0036】

当然ながら、ドメイン制御デバイス１が、ネットワークノード２１の身元情報および認証情報を事前記憶している場合は、図４に示されるようなＲＡＤＩＵＳ認証、または他の認証を実施する必要はない。

【0037】

ネットワークノード２１を認証し、ＰＴＰプロトコル用の鍵を送信するためのドメイン制御デバイス１１のプロセスが、機能の観点から詳細に説明されてきた。具体的には、一実施形態において、ドメイン制御デバイス１１は、ＥＡＰ認証を用いて、ネットワークノード２１がドメイン１０における適格なノードであるかどうかを検証することができる。以下では、それが詳細に説明される。

【0038】

ＥＡＰは、よく知られ、一般的に使用される、ＲＦＣ３７４８で定義されたセキュリティ認証プロトコルである。ＥＡＰは、さまざまな種類の下位のトランスポートプロトコル上で動作することができる。本発明は、ＰＴＰプロトコルを対象としているため、ＰＴＰ上で動作するＥＡＰを使用することが好ましい。当然ながら、本発明はこれに限定されない。別のプロトコル上で動作するＥＡＰを使用することもまた、ネットワークノード２１がドメイン１０における適格なノードであるかどうかの認証を実現することができる。たとえば、ＵＤＰ上で動作するＥＡＰ、またはイーサネット（登録商標）上で動作するＥＡＰが使用されてもよい。

【0039】

図５は、ＰＴＰ上で動作するＥＡＰのプロトコルアーキテクチャの図である。図６は、ＥＡＰ認証処理を用いて、ネットワークノード２１を認証するためのＥＡＰメッセージのフォーマットの図である。図６では、使用されることになる既存のＥＡＰ認証処理が示されている。ＲＦＣ３７４８の定義に従って、「Ｃｏｄｅ」が１であるとき、それはＥＡＰ要求メッセージであり、「Ｃｏｄｅ」が２であるとき、それはＥＡＰ応答メッセージである。「Ｉｄｅｎｔｉｆｉｅｒ」は、ＥＡＰ要求メッセージとＥＡＰ応答メッセージとを適合させるための１ビット長の整数である。新しいＥＡＰ要求メッセージは、このフィールドの値を変更しなければならない。「Ｌｅｎｇｔｈ」は、ＥＡＰメッセージ全体の長さを示す。「Ｔｙｐｅ」は、ＥＡＰ要求またはＥＡＰ応答のタイプである。Ｔｙｐｅ−ｄａｔａの内容は、タイプによって決定される。たとえば、「Ｔｙｐｅ」値＝１のとき、それは、ネットワークノード２１の身元を照会するための「Ｉｄｅｎｔｉｔｙ」を表す。「Ｔｙｐｅ」値＝４のとき、それは、「ＭＤ５−Ｃｈａｌｌｅｎｇｅ」を表し、これは、ＰＰＰ ＣＨＡＰプロトコルに類似し、ネットワークノード２１の認証情報を照会するための問い合わせメッセージを含む。すなわち、図３を参照すると、ステップＳ３０１で、「Ｃｏｄｅ」値は１であり、「Ｔｙｐｅ」値は１である。ステップＳ３０２で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は１であり、「Ｔｙｐｅ−Ｄａｔａ」は、ネットワークノード２１の身元情報である。ステップＳ３０４およびＳ３０５は、例としてのＥＡＰ ＭＤ５ Ｃｈａｌｌｅｇｅ認証方式を用いて説明されるので、「Ｔｙｐｅ」値は４である。ステップＳ３０４で、「Ｃｏｄｅ」値は１であり、ステップＳ３０５で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ−Ｄａｔａ」は、ネットワークノード２１の認証情報である。ステップＳ３０７におけるＰＴＰプロトコル用の鍵の配信は、新しい「Ｃｏｄｅ」および／または新しい「Ｔｙｐｅ」を定義するように、かつ「Ｔｙｐｅ−Ｄａｔａ」における新しいフィールドを定義するようにＥＡＰプロトコルを拡張することによって、あるいは、新しい「Ｔｙｐｅ」を定義し、かつ「Ｔｙｐｅ−Ｄａｔａ」における新しいフィールドを定義するようにＥＡＰプロトコルの既存のメッセージを拡張することによって、実施されてよい。ＳＵＣＣＥＳＳメッセージを拡張するために、引き続きＥＡＰ ＭＤ５−Ｃｈａｌｌｅｇｅ認証方式を例に取ると、新たに定義された「Ｔｙｐｅ−Ｄａｔａ」がＳＵＣＣＥＳＳメッセージの中に追加されて、ＰＴＰプロトコル用の鍵を送信する。このケースで、「Ｃｏｄｅ」値は３であり、「Ｔｙｐｅ」のタイプは、拡張された定義の新しいタイプであってよい。このタイプは、ＰＴＰプロトコル用の鍵を送信するために、「Ｔｙｐｅ−Ｄａｔａ」においてＰＴＰプロトコルの鍵フィールドを示す。

【0040】

図６は、既存のＥＡＰ認証処理を用いて、ネットワークノード２１を認証するシナリオを示す。図７は、本発明の実施形態による、新しいＥＡＰ認証を定義するメッセージフォーマットを示す。ステップＳ３０１、Ｓ３０２、Ｓ３０４、およびＳ３０５における認証メッセージの送信、ならびにステップＳ３０７におけるＰＴＰプロトコル用の鍵の送信は、２５４である「Ｔｙｐｅ」による拡張されたＥＡＰメッセージを利用して実施され、ここで、メッセージフォーマットが図７に示されている。メッセージの内容は、「Ｖｅｎｄｏｒ Ｄａｔａ」フィールドにおいて送信され、ＰＴＰプロトコル用の鍵は、「Ｖｅｎｄｏｒ Ｄａｔａ」において１つまたは複数のフィールドを追加することによって送信されてよい。

【0041】

ステップＳ３０１で、「Ｃｏｄｅ」値は１であり、「Ｔｙｐｅ」値は２５４であり、「Ｖｅｎｄｏｒ−ＩＤ」は、定義を拡張して、たとえば、ＩＥＥＥ１５８８ ＰＩＰのための特定のタイプ値を確保し、サポートされた認証プロトコルごとに特定の「Ｖｅｎｄｏｒ−ＩＤ」を配布することができる。ステップＳ３０２で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は２５４であり、「Ｖｅｎｄｏｒ−Ｄａｔａ」は、ネットワークノード２１の身元情報である。ステップＳ３０４で、「Ｃｏｄｅ」値は１であり、「Ｔｙｐｅ」値は２５４である。ステップＳ３０５で、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は２５４４であり、「Ｖｅｎｄｏｒ−Ｄａｔａ」は、ネットワークノード２１の認証情報である。ステップＳ３０７におけるＰＴＰプロトコル用の鍵の送信は、「Ｖｅｎｄｏｒ−Ｄａｔａ」において新しいフィールドを定義することによって実施されてよい。このケースで、「Ｃｏｄｅ」値は２であり、「Ｔｙｐｅ」値は２５４であり、図６に示されるようなオリジナル認証プロトコルによって定義されたフィールドに加えて、「Ｖｅｎｄｏｒ−Ｄａｔａ」においてＰＴＰプロトコルの鍵フィールドが追加される。

【0042】

ステップＳ２０２におけるＰＴＰプロトコル用の鍵の送信は、平文テキストで、または暗号化で実施されてよいことに留意されたい。暗号化は、ステップＳ２０１での認証段階中に合意された鍵によって行われてよい。たとえば、図６または図７で、ネットワークノード２１は、ドメイン制御デバイス１１においてＴＬＳプロトコルを通して認証される。ＴＬＳ用のデータ暗号化鍵は、認証が完了する間に合意されてよい。したがって、ＰＴＰプロトコル用の鍵への暗号化送信を実施するために、データ暗号化鍵が利用されてよい。

【0043】

利用される異なる暗号化方式に基づいて、たとえば、ＰＴＰプロトコルのＡｎｎｅｘＫで定義されたハッシュ関数暗号化方式（ＩＥＥＥ １５８８−２００８）などの、ＰＴＰプロトコル用の鍵の複数の形式があってよく、この場合、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む。たとえば、暗号化およびデジタル署名は、身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズム（Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ Ｓｉｇｎｃｒｙｐｔｉｏｎ、Ｊｏｈｎ Ｍａｌｏｎｅ−Ｌｅｅ、Ｃｒｙｐｔｏｌｏｇｙ ｅＰｒｉｎｔ Ａｒｃｈｉｖｅ、Ｒｅｐｏｒｔ２００２／０９８、２００２．ｈｔｔｐ：／／ｅｐｒｉｎｔ．ｉａｃｒ．ｏｒｇ／）を採用することによって実施されてよく、この場合、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび秘密鍵を含む。以下では、２つのアルゴリズムが詳細に説明される。

【0044】

図８は、本発明の実施形態による、通信ネットワークのネットワークノード内でＰＴＰプロトコルデータパケットを暗号化する方法の流れ図である。以下では、図１に示されたような適用シナリオを参照して、ネットワークノード２１においてＰＴＰプロトコルデータパケットを暗号化する方法が詳細に説明される。

【0045】

最初に、ステップＳ８０１で、ネットワークノード２１が、本ネットワークノードが属するドメイン内のドメイン制御デバイス１１から、ＰＴＰプロトコル用の鍵を受信する。

【0046】

次に、ステップＳ８０２で、ネットワークノード２１は、ＰＴＰプロトコルに従って、ステップＳ８０１で受信された鍵を用いて、ドメイン１０内の別のネットワークノードとの暗号化通信を実施する。

【0047】

上で述べたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび第１の鍵を含み、ここで、第１の鍵は、ネットワークノード２１の身元情報に基づいて、ドメイン制御デバイスによって生成される。具体的には、ステップＳ８０２が、以下のサブステップを含む：ユニキャストＰＴＰデータパケットを送信するときに、第１の鍵および受信ノードの身元情報に基づいて、ユニキャストＰＴＰデータパケットのためのデジタル署名を生成するステップ、およびユニキャストＰＴＰデータパケットのテキスト本文を暗号化するステップ、ならびに第１の鍵および送信ノードの身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための暗号化およびデジタル署名認証を実施するステップ。

【0048】

以下では、Ｊｏｈｎによる身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎを参照して、ユニキャストシナリオにおける、デジタル署名の生成、暗号化、復号化、およびデジタル署名認証のやり方が簡単に説明される。一般性を損なうことなく、詳細な説明は、ネットワークノード２１とネットワークノード２２との通信の例を用いて行われる。ネットワークノード２１の身元情報をＩＤ_ａ、およびネットワークノード２２の身元情報をＩＤ_ｂとすることにする。

【0049】

Ｐ、

【0050】

【数3】

Ｈ_１、Ｈ_２、Ｈ_３、およびＱ_ＴＡは、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムのために定義されたシステム論破パラメータである。それらは、具体的には以下のように定義される：（Ｇ，＋）および（Ｖ，・）は、ｑの素数次数を有する巡回群である。Ｐは、巡回群Ｇの生成元である。プロトコル実装パフォーマンス要件およびプロトコルデータグラムオーバーヘッドを考慮して、楕円曲線によって生成された巡回群を使用することが推奨される。

【0051】

【数4】

は、身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムの要件を満たす双一次変換である。Ｈ_１、Ｈ_２、およびＨ_３は、あらかじめ定義されたハッシュ関数であって、ここで、

【0052】

【数5】

【0053】

【数6】

【0054】

【数7】

であり、ここで、ｎは、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムによって処理されるメッセージの長さを表し、Ｇ^＊＝Ｇ＼｛０｝である。

【0055】

以下の記述において、シンボル

【0056】

【数8】

は、ビット文字列の接続を表し、

【0057】

【数9】

は、ビット文字列がビットごとのＸＯＲであることを表し、＋は、選択された巡回群で定義された加法演算を表し、

【0058】

【数10】

は、

【0059】

【数11】

から無作為に値を選択し、その値をｔに与えることを表す。

【0060】

システムの初期化時に、ドメイン制御デバイスは、最初に、身元ベースのＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムのシステムパラメータのＰ、

【0061】

【数12】

Ｈ_１、Ｈ_２、およびＨ_３を選択する。次いで、ドメイン全体のＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムのシステム構成パラメータが完全に決定されるまで、

【0062】

【数13】

が無作為に選択され、Ｑ_ＴＡがｔＰとして計算される。ドメイン制御デバイスは、Ｐ、

【0063】

【数14】

Ｈ_１、Ｈ_２、Ｈ_３、およびＱ_ＴＡを開示することができ、すなわち、これらのパラメータを、ドメイン１０内のそれぞれのネットワークノードを通知することができる。ドメイン制御デバイス１１によってのみ知られる乱数として、ｔは、ドメイン全体のマスター鍵である。

【0064】

ネットワークノード２１については、それがドメイン１０の中に追加されるとき、ドメイン制御デバイス１１に登録される必要がある。ドメイン制御デバイス１１は、ネットワークノード２１を検証する。ネットワークノード２１が認証に成功した場合にのみ、ドメイン制御デバイス１１は、ネットワークノード２１がドメイン１０の中に追加されることを許可する。ドメイン制御デバイス１１は、認証処理の間に、ネットワークノード２１の身元ＩＤを取得する。ネットワークノード２１が認証に成功した後で、そのＩＤに基づいて、ネットワークノード２１のための秘密鍵Ｓ_ＩＤ＝ｔＱ_ＩＤが計算され、ここで、Ｑ_ＩＤ＝Ｈ_１（ＩＤ）である。秘密鍵は、システム構成パラメータＰ、

【0065】

【数15】

Ｈ_１、Ｈ_２、Ｈ_３、およびＱ_ＴＡと共に、ネットワークノード２１に配布される。セキュリティを保証するために、これらのパラメータは、配布プロセスの間に、必要に応じて、暗号化され、保護されてよい。ネットワークノード２１が登録を完了し、ＳｉｇｎＣｒｙｐｔｉｏｎのシステム構成パラメータ、ならびにその秘密鍵を取得した後で、ネットワークノード２１は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムを利用することによって、ドメイン内の他のノードとセキュアに通信することができる。

【0066】

メッセージを送信するとき、ネットワークノード２１は、以下の規定に従ってメッセージを処理する：

【0067】

【数16】

ここで、ｍは、ネットワークノード２１によって、ネットワークノード２２に送信されることになるＰＴＰプロトコルメッセージであり、ｃは、暗号化されたメッセージであり、ＵおよびＶは、ｍに基づいて生成されたデジタル署名であり、σは、暗号化され、デジタル署名が添付されたＰＴＰプロトコルメッセージである。

【0068】

暗号化された署名付きのメッセージを受信した後で、ネットワークノード２２は、その秘密鍵および送信ノード（すなわち、ネットワークノード２１）の身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための復号化およびデジタル署名認証を、以下のプロセスで実施する：
Ｕｎｓｉｇｎｃｒｙｐｔ（ＩＤａ，Ｓ_ＩＤｂ，σ）
Ｑ_ＩＤａ＝Ｈ_１（ＩＤ_ａ）
σを（ｃ，Ｕ，Ｖ）として構文解析する

【0069】

【数17】

ｋ＝ｙ
ｍ＝ｋ□ｃ

【0070】

【数18】

【0071】

【数19】

の場合、
⊥を返す（メッセージが無効であり、破棄されるべきであることを示す）
ｍを返す

【0072】

【数20】

が、

【0073】

【数21】

に等しくない場合、ネットワークノード２２は、この署名は正しくないものと判定し、メッセージｍを破棄する、または無視する。

【0074】

当然ながら、ネットワークノード２１が、受信されたユニキャストメッセージに、どのように復号化およびデジタル署名検証を実施するかのプロセスも、上で言及されたものと同様である。

【0075】

マルチキャストまたはブロードキャストデータパケットの送信および受信のために、ドメイン制御デバイス１１は、マルチキャスト（またはブロードキャスト）ごとに身元情報を定義し、身元に基づいて第２の秘密鍵を生成し、第２の秘密鍵を、マルチキャスト（またはブロードキャスト）データパケットの受信を要求するネットワークノード、たとえば、ネットワークノード２１に送信する。マルチキャストまたはブロードキャストＰＴＰデータパケットを送信するとき、ネットワークノード２１は、それ自身の第１の秘密鍵、そのマルチキャストグループまたはブロードキャストグループの身元情報に基づいて、マルチキャストまたはブロードキャストＰＴＰデータパケットへのデジタル署名を生成し、マルチキャストまたはブロードキャストＰＴＰデータパケットのテキスト本文を暗号化し、マルチキャスト（またはブロードキャスト）グループの第２の秘密鍵および送信ノードの身元情報に基づいて、受信されたマルチキャストまたはブロードキャストＰＴＰデータパケットのための復号化およびデジタル署名認証を実施する。

【0076】

上で言及されたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫによって定義された共有対称鍵を含む。具体的には、共有対称鍵の数は、ネットワークノード２１が通信する必要のあるネットワークノードの数によって決まる。具体的には、ステップＳ８０２が、以下のサブステップを含む：ネットワークノード２１は、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ保護を実施し、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ検証を実施する。

【0077】

以下では、ＰＴＰプロトコルのＡｎｎｅｘＫを参照して、ネットワークノード２１がどのように、共有対称鍵を用いて、送受信されるデータパケットのためのセキュリティ保護およびセキュリティ検証を実施するかが詳細に説明される。

【0078】

ＰＴＰプロトコルがＡｎｎｅｘＫをサポートするとき、すべてのＰＴＰメッセージは、フィールドＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶを保持しなければならず、フラグフィールドのためのセキュリティフラグ（ｆｌａｇＦｉｅｌｄ．Ｓｅｃｕｒｅ）を設定する。ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおける「Ｉｎｔｅｇｒｉｔｙ Ｃｈｅｃｋ Ｖａｌｕｅ」フィールドは、メッセージ全体の完全性を保証するためのものである。ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおけるアルゴリズムＩＤによって識別されるメッセージ認証符号化関数（たとえば、ＰＴＰプロトコルのＡｎｎｅｘＫにおいて定義されるＨＭＡＣ−ＳＨＡ１−９６またはＨＭＡＣ−ＳＨＡ２５６−１２８関数）、および鍵ＩＤによって識別される鍵を、ＰＴＰメッセージ全体に適用することによって、ＩＣＶが取得される。

【0079】

一般性を損なうことなく、ネットワークノード２１とネットワークノード２２との通信を例に取ると、それらの共有対称鍵が、Ｋであり、ｍは、ネットワークノード２１によって、ネットワークノード２２に送信されることになるＰＴＰプロトコルデータパケットである。ネットワークノード２１は、必要に応じて、ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおける該当フィールドに、たとえば、アルゴリズムＩＤ、鍵ＩＤなど書き込み、ここで、ＩＣＶ値はゼロであり、初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶが、メッセージｍに添付される。ネットワークノード２１は、ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおけるアルゴリズムＩＤ、鍵ＩＤ、および初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶが添付されたＰＴＰメッセージに基づいて、完全性チェック値フィールド＝Ｈ（初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶのＰＴＰメッセージ、Ｋが添付されている）を計算し、ここで、Ｈは、ＰＴＰプロトコルのＡｎｎｅｘＫにおいて定義されるＨＭＡＣ−ＳＨＡ１−９６またはＨＭＡＣ−ＳＨＡ２５６−１２８関数である。ネットワークノード２１は、この結果を使用して、初期のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおけるＩＣＶフィールドを変更し、ＩＣＶが変更されたＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶフィールドを有するメッセージを、ネットワークノード２２に送信する。ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶを保持するメッセージｍを受信した後で、ネットワークノード２２は、上で言及されたのと同じ方法を使用して、ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおけるアルゴリズムＩＤ、鍵ＩＤ、および受信されたｍを計算し、それを、受信されたメッセージ内のＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＴＬＶにおいて保持されたＩＣＶ値と比較する。それらが一致しない場合、メッセージｍを破棄する、または無視する。ネットワークノード２１はまた、ネットワークノード２２から受信されたＰＴＰプロトコルメッセージに対してそのようなチェックを実施する。

【0080】

図９は、本発明の実施形態による、通信ネットワークのドメイン制御デバイスにおいて、ＰＴＰプロトコル用の鍵をドメイン内のネットワークノードに配布するための装置９００の構造図であり、装置９００は、第１の検証手段９０１と、第１の送信手段９０２とを含む。一実施形態において、第１の検証手段９０１は、第２の送信手段９０１１と、第２の受信手段９０１２と、第２の検証手段９０１３と、第３の送信手段９０１４と、第３の受信手段９０１５と、第３の検証手段９０１６とを含む。

【0081】

以下では、ドメイン制御デバイス１１における装置９００の作業手順に関して詳細な説明がなされる。

【0082】

最初に、第１の検証手段９０１が、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証する。

【0083】

ネットワークノードがドメインにおける適格なノードである場合、第１の送信手段９０２が、ＰＴＰプロトコル用の鍵をネットワークノードに送信する。

【0084】

具体的には、第１の検証手段９０１が、ネットワークノード２１がドメインにおける適格なノードであるかどうかを検証するためのいくつかの方式がある。一実施形態が、以下に示される。

【0085】

最初に、第２の送信手段９０１１が、身元を照会するための要求メッセージを、ネットワークノード２１に送信する。

【0086】

次に、第２の受信手段９０１２が、ネットワークノード２１から、身元を照会するための応答メッセージを受信し、応答メッセージは、ネットワークノード２１の身元情報を含む。

【0087】

第２の検証手段９０１３が、ネットワークノード２１の身元が適格であるかどうかを検証する。

【0088】

ネットワークノード２１の身元が適格である場合、第３の送信手段９０１４が、認証情報を照会するための要求メッセージを、ネットワークノード２１に送信する。

【0089】

第３の受信手段９０１５が、ネットワークノード２１から、認証情報を照会するための応答メッセージを受信する。

【0090】

第３の検証手段９０１６が、ネットワークノード２１の認証情報が適格であるかどうかを検証する。

【0091】

ネットワークノード２１の認証情報が適格である場合、第１の送信手段９０２は、ＰＴＰプロトコル用の鍵をネットワークノード２１に送信する。

【0092】

第２の検証手段９０１３が、ネットワークノード２１の身元が適格であるかどうかを検証するための、および第３の検証手段９０１６が、ネットワークノード２１の認証情報が適格であるかどうかを検証するための複数の方式、たとえば、ＲＡＤＩＵＳベースの認証（ＲＦＣ２８６９）、またはＤＩＡＭＥＴＥＲベースの認証（ＲＦＣ３５８８）がある。

【0093】

一実施形態において、第１の検証手段９０１は、ＥＡＰ認証を用いて、ネットワークノード２１がドメイン１０における適格なノードであるかどうかを検証することができる。第１の送信手段９０２は、ＥＡＰ認証処理で定義されたメッセージにおける定義「Ｔｙｐｅ−Ｄａｔａ」を拡張することによって、ＰＴＰプロトコル用の鍵の送信を実装する。別の実施形態において、第１の送信手段９０２は、ＥＡＰメッセージにおける「Ｅｘｐａｎｄｅｄ Ｔｙｐｅ」を定義することによって、ＰＴＰプロトコル用の鍵の送信を実装し、それにより、新しいＥＡＰ認証方式を定義する。ＰＴＰプロトコル用の鍵は、暗号化されたテキストの形式、または平文テキストの形式で送信されてよい。一実施形態において、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む。別の実施形態において、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび秘密鍵を含む。

【0094】

図１０は、本発明の一実施形態による、通信ネットワークのネットワークノードにおいて、ＰＴＰプロトコルデータパケットを暗号化するための装置１００の構造ブロック図である。以下では、ネットワークノード２１において、装置１００についてＰＴＰプロトコルデータパケットを暗号化するプロセスが詳細に説明される。

【0095】

最初に、第１の受信手段１０１が、本ネットワークノードが属するドメイン内のドメイン制御デバイス１１から、ＰＴＰプロトコル用の鍵を受信する。

【0096】

次に、暗号化通信手段１０２が、ＰＴＰプロトコルに従って、鍵を利用して、ドメイン内の別のネットワークノードとの暗号化通信を実施する。

【0097】

上で述べたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＳｉｇｎＣｒｙｐｔｉｏｎアルゴリズムで定義されたパラメータおよび第１の鍵を含み、ここで、第１の鍵は、ネットワークノード２１の身元情報に基づいて、ドメイン制御デバイス１０によって生成される。具体的には、暗号化通信手段１０２は、以下の機能を実施する：ユニキャストＰＴＰデータパケットを送信するときに、第１の鍵および受信ノードの身元情報に基づいて、ユニキャストＰＴＰデータパケットへのデジタル署名を生成すること、およびユニキャストＰＴＰデータパケットのテキスト本文を暗号化すること、ならびに、第１の鍵および受信ノードの身元情報に基づいて、受信されたユニキャストＰＴＰデータパケットのための暗号化およびデジタル署名認証を実施すること。

【0098】

マルチキャストまたはブロードキャストデータパケットの送信および受信のために、ドメイン制御デバイス１１は、マルチキャスト（またはブロードキャスト）ごとに身元情報を定義し、身元に基づいて第２の秘密鍵を生成し、第２の秘密鍵を、マルチキャスト（またはブロードキャスト）データパケットの受信を要求するネットワークノード、たとえば、ネットワークノード２１に送信する。ネットワークノード２１がマルチキャストまたはブロードキャストＰＴＰデータパケットを送信するとき、暗号化通信手段１０２は、それ自身の第１の秘密鍵、そのマルチキャストグループまたはブロードキャストグループの身元情報に基づいて、マルチキャストまたはブロードキャストＰＴＰデータパケットへのデジタル署名を生成し、マルチキャストまたはブロードキャストＰＴＰデータパケットのテキスト本文を暗号化し、マルチキャスト（またはブロードキャスト）グループの第２の秘密鍵および送信ノードの身元情報に基づいて、受信されたマルチキャストまたはブロードキャストＰＴＰデータパケットのための復号化およびデジタル署名認証を実施する。

【0099】

上で述べたように、一実施形態において、ＰＴＰプロトコル用の鍵は、ＰＴＰプロトコルのＡｎｎｅｘＫで定義された共有対称鍵を含む。具体的には、共有対称鍵の数は、ネットワークノード２１が通信する必要のあるネットワークノードの数によって決まる。具体的には、暗号化通信手段１０２は、以下の機能を実施する：ネットワークノード２１は、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ保護を実施し、ＰＴＰプロトコルのＡｎｎｅｘＫに従った暗号化鍵を利用して、ＰＴＰデータパケットのためのセキュリティ検証を実施する。

【0100】

本発明の趣旨から逸脱しない、いずれの任意の技術的なソリューションも、本発明の保護範囲の中に含まれるべきである。加えて、特許請求の範囲におけるいずれの参照番号も、特許請求の範囲を限定するものとしてみなされるべきでない。用語「含む（ｃｏｍｐｒｉｓｅ）」は、特許請求の範囲または明細書において規定されていない他の手段またはステップを排除しない。手段の前の「ａ」は、より多くの同様の手段の存在を排除しない。複数の手段を含む装置において、複数の手段のうちの１つまたは複数の機能は、同じハードウェアモジュールまたはソフトウェアモジュールによって実装されてもよい。「第１の」、「第２の」、および「第３の」などの語句は、いずれの特定の順序を示すことなく、単なる呼び名を表す。

【0101】

本発明の具体的な実施形態が上で説明されてきた。本発明は、上の特定の実施形態に限定されないことに留意されたい。当業者は、添付の特許請求の範囲内でのさまざまな変更形態または修正形態を行うことができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】