"キーサーバが有するIDである第1のIDに基づき、自装置の名前とセッション鍵とを少なくとも含む第1の情報を暗号化して第1の暗号情報を生成する手段と、前記第1の暗号情報を前記キーサーバに送出する手段と、前記第1の暗号情報を前記キーサーバが復号して得た前記名前に対応して前記キーサーバが前記自装置向けに生成したIDである第2のIDと、該第2のIDに対応して前記キーサーバが生成した秘密鍵とを少なくとも含む第2の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第2の暗号情報とされてかつ前記キーサーバの署名である第1のサーバ署名が付されて前記キーサーバから送られてきたときに、該第2の暗号情報および該第1のサーバ署名を受け取る手段と、前記第1のサーバ署名の正当性を検証する手段と、前記第2の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、ホストに関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに対して、前記自装置の登録を要求する旨の情報を前記第2のIDを付して送出する手段と、前記登録サーバのIDである第3のIDを少なくとも含む第3の情報が、前記登録サーバの署名である第2のサーバ署名が付されて前記登録サーバから送られてきたときに、該第3の情報および該第2のサーバ署名を受け取る手段と、前記第2のサーバ署名の正当性を検証する手段と、前記第3のIDに基づき、前記自装置の前記名前を少なくとも含む第4の情報を暗号化して第3の暗号情報を生成し、かつ前記秘密鍵に基づき、自装置署名を生成する手段と、前記第3の暗号情報および前記自装置署名を前記登録サーバに送出する手段とを具備することを特徴とするホスト装置。前記第1の暗号情報が、前記第1の情報にランダム数およびタイムスタンプをさらに含ませるようにして得た情報を暗号化して得られた暗号情報であり、前記第3の暗号情報が、前記第4の情報に、前記ランダム数とは異なる第2のランダム数をさらに含ませるようにして得た情報を暗号化して得られた暗号情報であることを特徴とする請求項1記載のホスト装置。通信をしようとする発信先装置が有する名前の解決を要求する旨の情報を少なくとも含む第1の情報に自装置署名を付して、該第1の情報および該自装置署名を、前記発信先装置に関する情報である第2の情報を登録するための登録サーバを含んで構造化されたシステムに対して、該システムが前記登録サーバを見つけられるように送出する手段と、前記第2の情報が、自装置のIDに基づく暗号化で暗号情報とされてかつ前記登録サーバの署名であるサーバ署名が付されて前記登録サーバから送られてきたときに、該暗号情報および該サーバ署名を受け取る手段と、前記サーバ署名の正当性を検証する手段と、前記暗号情報から、前記第2の情報を復号して得る手段とを具備することを特徴とするホスト装置。通信をしようとする発信先装置が有する名前の解決を要求する旨の情報を少なくとも含む第1の情報に自装置署名を付して、前記発信先装置に関する情報である第2の情報を登録するための登録サーバを含んで階層化されたシステムに送出する手段と、前記システムにおいて前記登録サーバの階層上位に位置するサーバたる第1の上位サーバに関する情報である第3の情報が、自装置のIDである第1のIDに基づく暗号化で第1の暗号情報とされてかつ前記第1の上位サーバのさらに階層上位に位置する第2の上位サーバの署名である第1のサーバ署名が付されて該第2の上位サーバから送られてきたときに、該第1の暗号情報および該第1のサーバ署名を受け取る手段と、前記第1のサーバ署名の正当性を検証する手段と、前記第1の暗号情報から、前記第3の情報を復号して得る手段と、前記第1の情報に自装置署名を付して、前記第1の上位サーバに送出する手段と、前記登録サーバに関する情報である第4の情報が、前記第1のIDに基づく暗号化で第2の暗号情報とされてかつ前記第1の上位サーバの署名である第2のサーバ署名が付されて該第1の上位サーバから送られてきたときに、該第2の暗号情報および該第2のサーバ署名を受け取る手段と、前記第2のサーバ署名の正当性を検証する手段と、前記第2の暗号情報から、前記第4の情報を復号して得る手段と、前記第1の情報に自装置署名を付して、前記登録サーバに送出する手段と、前記第2の情報が、前記第1のIDに基づく暗号化で第3の暗号情報とされてかつ前記登録サーバの署名である第3のサーバ署名が付されて前記登録サーバから送られてきたときに、該第3の暗号情報および該第3のサーバ署名を受け取る手段と、前記第3のサーバ署名の正当性を検証する手段と、前記第3の暗号情報から、前記第2の情報を復号して得る手段とを具備することを特徴とするホスト装置。自装置の名前である第1の名前の情報が含まれたIDと、通信しようとする発信先装置の名前である第2の名前とを少なくとも含む第1の情報に自装置署名を付して、前記発信先装置に送出する手段と、前記発信先装置が生成したセッション鍵およびランダム数を少なくとも含む第2の情報が、前記発信先装置が名前解決システムに前記第1の名前を適用して前記自装置の公開鍵および公開パラメータが前記発信先装置によって獲得されたあとに、前記IDに基づく暗号化で第1の暗号情報とされてかつ前記発信先装置の署名である装置署名が付されて前記発信先装置から送られてきたときに、該第1の暗号情報および該装置署名を受け取る手段と、前記装置署名の正当性を検証する手段と、前記第1の暗号情報から、前記セッション鍵および前記ランダム数を復号して得る手段と、前記セッション鍵に基づき、前記ランダム数を暗号化して第2の暗号情報を生成する手段と、前記第2の暗号情報を前記発信先装置に送出する手段とを具備することを特徴とするホスト装置。自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置に関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに送出する手段とを具備することを特徴とするホスト装置。本発明は、例えばIPアドレスおよびローケータのような関連必要情報を持ち得るホスト装置において、自己保護性を向上することができるホスト装置を提供することを目的とする。上記の課題を解決するため、本発明の一態様であるホスト装置は、キーサーバが有するIDである第1のIDに基づき、自装置の名前とセッション鍵とを少なくとも含む第1の情報を暗号化して第1の暗号情報を生成する手段と、前記第1の暗号情報を前記キーサーバに送出する手段と、前記第1の暗号情報を前記キーサーバが復号して得た前記名前に対応して前記キーサーバが前記自装置向けに生成したIDである第2のIDと、該第2のIDに対応して前記キーサーバが生成した秘密鍵とを少なくとも含む第2の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第2の暗号情報とされてかつ前記キーサーバの署名である第1のサーバ署名が付されて前記キーサーバから送られてきたときに、該第2の暗号情報および該第1のサーバ署名を受け取る手段と、前記第1のサーバ署名の正当性を検証する手段と、前記第2の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、ホストに関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに対して、前記自装置の登録を要求する旨の情報を前記第2のIDを付して送出する手段と、前記登録サーバのIDである第3のIDを少なくとも含む第3の情報が、前記登録サーバの署名である第2のサーバ署名が付されて前記登録サーバから送られてきたときに、該第3の情報および該第2のサーバ署名を受け取る手段と、前記第2のサーバ署名の正当性を検証する手段と、前記第3のIDに基づき、前記自装置の前記名前を少なくとも含む第4の情報を暗号化して第3の暗号情報を生成し、かつ前記秘密鍵に基づき、自装置署名を生成する手段と、前記第3の暗号情報および前記自装置署名を前記登録サーバに送出する手段とを具備する。また、本発明の別の態様であるホスト装置は、通信をしようとする発信先装置が有する名前の解決を要求する旨の情報を少なくとも含む第1の情報に自装置署名を付して、該第1の情報および該自装置署名を、前記発信先装置に関する情報である第2の情報を登録するための登録サーバを含んで構造化されたシステムに対して、該システムが前記登録サーバを見つけられるように送出する手段と、前記第2の情報が、自装置のIDに基づく暗号化で暗号情報とされてかつ前記登録サーバの署名であるサーバ署名が付されて前記登録サーバから送られてきたときに、該暗号情報および該サーバ署名を受け取る手段と、前記サーバ署名の正当性を検証する手段と、前記暗号情報から、前記第2の情報を復号して得る手段とを具備する。また、本発明のさらに別の態様であるホスト装置は、通信をしようとする発信先装置が有する名前の解決を要求する旨の情報を少なくとも含む第1の情報に自装置署名を付して、前記発信先装置に関する情報である第2の情報を登録するための登録サーバを含んで階層化されたシステムに送出する手段と、前記システムにおいて前記登録サーバの階層上位に位置するサーバたる第1の上位サーバに関する情報である第3の情報が、自装置のIDである第1のIDに基づく暗号化で第1の暗号情報とされてかつ前記第1の上位サーバのさらに階層上位に位置する第2の上位サーバの署名である第1のサーバ署名が付されて該第2の上位サーバから送られてきたときに、該第1の暗号情報および該第1のサーバ署名を受け取る手段と、前記第1のサーバ署名の正当性を検証する手段と、前記第1の暗号情報から、前記第3の情報を復号して得る手段と、前記第1の情報に自装置署名を付して、前記第1の上位サーバに送出する手段と、前記登録サーバに関する情報である第4の情報が、前記第1のIDに基づく暗号化で第2の暗号情報とされてかつ前記第1の上位サーバの署名である第2のサーバ署名が付されて該第1の上位サーバから送られてきたときに、該第2の暗号情報および該第2のサーバ署名を受け取る手段と、前記第2のサーバ署名の正当性を検証する手段と、前記第2の暗号情報から、前記第4の情報を復号して得る手段と、前記第1の情報に自装置署名を付して、前記登録サーバに送出する手段と、前記第2の情報が、前記第1のIDに基づく暗号化で第3の暗号情報とされてかつ前記登録サーバの署名である第3のサーバ署名が付されて前記登録サーバから送られてきたときに、該第3の暗号情報および該第3のサーバ署名を受け取る手段と、前記第3のサーバ署名の正当性を検証する手段と、前記第3の暗号情報から、前記第2の情報を復号して得る手段とを具備する。また、本発明のさらに別の態様であるホスト装置は、自装置の名前である第1の名前の情報が含まれたIDと、通信しようとする発信先装置の名前である第2の名前とを少なくとも含む第1の情報に自装置署名を付して、前記発信先装置に送出する手段と、前記発信先装置が生成したセッション鍵およびランダム数を少なくとも含む第2の情報が、前記発信先装置が名前解決システムに前記第1の名前を適用して前記自装置の公開鍵および公開パラメータが前記発信先装置によって獲得されたあとに、前記IDに基づく暗号化で第1の暗号情報とされてかつ前記発信先装置の署名である装置署名が付されて前記発信先装置から送られてきたときに、該第1の暗号情報および該装置署名を受け取る手段と、前記装置署名の正当性を検証する手段と、前記第1の暗号情報から、前記セッション鍵および前記ランダム数を復号して得る手段と、前記セッション鍵に基づき、前記ランダム数を暗号化して第2の暗号情報を生成する手段と、前記第2の暗号情報を前記発信先装置に送出する手段とを具備する。また、本発明のさらに別の態様であるホスト装置は、自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置に関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに送出する手段とを具備する。本発明によれば、例えばIPアドレスおよびローケータのような関連必要情報を持ち得るホスト装置において、自己保護性を向上することができる。以上を踏まえ、以下では本発明の実施形態を適宜、図面を参照しながら説明する。説明の準備事項、NMS専用のNMSを備えた一般的なネットワーク構造が図1に示される。図1に示すように、ネットワーク構造は、通常、データプレーンと制御プレーンとからなる。データ転送に用いられるデータプレーンは、エッジドメインED1N1、1N2、...、1N3とグローバルな情報転送ネットワークGTN200とからなる。エッジドメイン1N1、1N2、...、1N3は、エンドホストであるホスト11、12に、ネットワークアクセスおよびドメイン内情報転送の便宜を提供する。エッジドメイン1N1等には、基地局81やルータ91が含まれる場合がある。一方、情報転送ネットワーク200は、サービスプロバイダの基幹ネットワークの集合であり、ドメイン間情報転送のため用いられる。情報転送ネットワーク200には、通常、ゲートウエイ41~49が設けられる。制御プレーンであるNMS100は、図1のネットワークでのホスト名をホストローケータおよびその他のRNIRelatedNecessaryInformationにマッピングするように設計されている。ホスト名は、ホストに割り当てられたユニークな名称であり、ホストローケータは、ホストがネットワークに接続するための接続アタッチポイントである。名前付けの方法は、階層構造の名前付けと平坦構造の名前付けという2つのカテゴリに分類することができる。この両者は、状況により利点および弱点を有する。インターネットや、LISPのような考え得る将来の構造では、階層構造の名前付けが採用される。一方、重層技術オーバーレイテクノロジーに関連するほかの構造は、平坦構造の名前付けが採用される。NMS100は、一般にNMSサブシステムを複数有し、例えば図1に示すように、ひとつのNMSサブシステム100AたるNMSSS1と、別のNMSサブシステム100BたるNMSSSkからなる。異なるNMSサブシステムは、NMS全体において異なる役割を有しており、それらは名前解決のためチェーンとなってはたらく。通常、最初のサブシステムが、ホスト名を入力としてそのRNIを提供し、中間のサブシステムが、前のサブシステムが提供したRNIを入力としてそのさらなるRNIを提供し、最後のサブシステムが、ホストローケータおよび別のさらなるRNIを提供する。これらのサブシステムの相互は、場合により接続されまたは切り離される。ひとつのNMSサブシステムは、名前登録、解決に供されるひとつ以上のNMS装置NMSEを有し、それらは、階層構造かあるいは平坦構造で構成されている。図1では、NMSSS1のNMS装置31h~36hは、階層構造であり、NMSSSkのNMS装置31f~35fは、平坦構造である。NMSEは、ホスト名とこのホストのRNIとの対応マッピングを記憶している。RNIには、例として、ID、ローケータ、公開鍵、公開パラメータ、IPアドレス、終点識別子EndpointIdentifierなどが挙げられる。ホスト名、公開鍵、および公開パラメータは、以下説明する実施形態において、NMSEに蓄えられる基本的な情報として位置づけられる。ローケータおよびRNIを得るため、ホスト名は、ひとつのサブシステムあるいは複数のサブシステムで1回以上の解決手順に付される。NMSサブシステムの根本的な機能は、名前解決の問合せに返答することである。共通事項として、ひとつのサブシステムにおいて名前をRNIとして解決することに関し、再帰モードと反復モードというふたつの名前解決モードが存在する。一方、異なるサブシステム間での関係は、必ず反復モードである。ひとつのサブシステムにおいて、再帰モードでは、NMSEは、このサブシステム内で直接的に、再帰的手法でたどり着いた対応のNMSEに対して名前解決要求を出す。これに対して、対応のNMSEは、要求者または代理の要求者に対して目的のホストのRNIを返答する。以下では、簡単のため、要求者という場合には、最初の要求者および代理の要求者の両者を含むものとする。ひとつのサブシステムにおいて、反復モードでは、NMSEが次に対応のNMSEのローケータを要求者に返答することを複数回反復し、最後に対応のNMSEが目的のホストのRNIを要求者に返答する。NMSにひとつしかサブシステムがない場合は、得られたRNIが、DNSでのIPアドレスのごとき最終的に要求されたRNIになる。NMSが複数のサブシステムを含む場合には、さらに続けて名前解決の手順がなされる必要がある。このような連続する名前解決は、異なるサブシステム間における反復モードとして実行される。すなわち、前のサブシステムから得られた名前解決結果が要求者に返答され、これに基づいて要求者は新たな要求を新たなサブシステムに対して開始する。そして最後に、目的のホストのRNIが、最後のサブシステムによる解決結果として得られる。ここで、上記説明のNMSを一般的なネットワーク構造で説明するため、DNS、および、LISPALTについてそれぞれ説明する。これらは典型的なNMSである。DNSDNSは、インターネットの核となる機能であり、ホスト名をIPアドレスに対応づけるものである。DNSではDNSサーバDNSSが用いられ、これは、DNSにおける名前サーバを意味するNMSE相当のものである。DNSはシステムとしてひとつなので、このNMSにほかのサブシステムは存在しない。DNSは、例えばtokyouacjpのように階層構造の名前付けを採用している。DNSにおけるDNSSは、ツリー構造として階層的に構成される。そのデータベースは、ゾーンと呼ばれるセクションに分割されており、DNSS間で分配される。DNSSのそれぞれは、DNSの名前空間内の隣接する領域であるゾーンについて責任を有している。すなわち、DNSSは、そのサブツリーの一部について機能する。DNSSは、そのゾーン内のホストについての問合せに対して返答する。DNSは、再帰モードと反復モードとを両者ともサポートする。再帰モードでは、DNSSが再帰動作して、たどり着いた対応のDNSSに対して直接に名前解決要求を出す。これに対して、対応のDNSSは、目的のホストのIPアドレスを要求者に返答する。反復モードでは、DNSSが次に対応のDNSSのIPアドレスを要求者に返答することを複数回反復し、最後に、その対応のDNSSが目的のホストのIPアドレスを要求者に返答する。IPアドレスはほかでもなくホストから要求された情報であり、よってさらなる名前解決以下では、名前解決を単に解決と言う場合があるのための別のサブシステムは必要ない。DNSの再帰モードにおけるホスト名の登録解決のステップが、一例として、図2に示される。図2において、図1中に示したものと同一または同一相当のものには同一符号を付してある。図2では、NMSE31h~37hに相当して、DNSサーバ31~37が設けられる。登録ステップであるステップ1では、ホスト名とそのIPアドレスとをDNS110に登録する。対応のDNSサーバDNSS37であるDNSSZAXは、図2中に示したホスト11Pの名前であるHost2.Z.A.XをそのIPアドレス情報と対応づけて記憶する。名前解決の手順では、まず、解決の問合せがローカルDNSサーバLDNSS30Lに送られる。次に、ローカルDNSサーバ30Lが問合せを基底ルートサーバDNSS0DNSサーバ31に送る。サーバが回答を示せないならば、その問合せを最も近い既知の信頼すべきDNSSに送る。最後に、その対応のDNSSDNSサーバ37がホスト名に対応するホストのIPアドレスをローカルDNSサーバ30Lに返答し、ローカルDNSサーバ30Lはその解決結果を要求ホストに転送する。図2に示すように、名前解決の手順は、ステップ2.1から2.7である。一方、DNSでの反復モードによる名前解決が、一例として、図3に示される。図3において、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。名前解決の手順は、ステップ2.1から2.10である。まず、Host1.K.C.Yのホスト12が解決の問合せを、DNS120内のローカルDNSサーバ30Lに送り、ローカルDNSサーバ30Lはその問合せを基底サーバDNSサーバ31に送る。反復の問合せでは、DNSSは毎回、DNSSが複数記載されたリストをローカルDNSサーバ30Lに返答する可能性がある。その場合には、ローカルDNSサーバ30Lは、次のDNSSとしてその中からひとつ選択し次の問合せを送る。簡単のため、図示では、次のDNSSとして単一のIPアドレスが特定されていることとしている。この反復モードの手順では、中間のDNSSは、次のDNSSのIPアドレスを返答し、ローカルDNSサーバ30Lは、それに応じて問合せを反復する。最後に、ローカルDNSサーバ30Lは、目的のホストのIPアドレスを得、この結果を要求者ホスト12に提供する。なお、ホストは、その名前を維持する一方で接続を変更するときに、そのIPアドレスの更新を要する場合がある。このような場合は、対応ホストCHへの更新とDNSへの更新というふたつの手順が必要である。CH更新のためには、更新要求がCHに送られ、CHはそのアドレスを更新しこの要求を了知する。DNS更新のためには、更新要求が対応のDNSSに送られ、DNSSはアドレスを更新しこの要求を了知する。LISPALTLISPALTは、もうひとつの典型的なNMSの例である。LISPALTでは、ホストIDとして終点識別子EndpointIdentifier:EIDを用いる一方、ローケータとしてルーティングローケータRLOCを用いる。EIDおよびRLOCは、階層構造の名前付けをその方法として使用する。このNMSは、インターネットのような機能を有するDNSとオルタナティブトポロジーALTというふたつのサブシステムを有する。DNSサブシステムがホスト名をホストEIDとして解決し、一方ALTサブシステムがホストEIDをホストRLOCとして解決する。DNSサブシステムにおけるNMSEは階層構造を有し、一方ALTサブシステムにおけるNMSEは平坦構造を有する。DNSサブシステムは、再帰モードと反復モードの両者をサポートする。一方、ALTサブシステムにおいては、LISPがBGPボーダーゲートウエイプロトコルを使用してEIDプリフィックスの更新情報を送り、そのEIDプリフィックスのEIDからRLOCへの対応を保持しているETRエグレストンネルルータに要求が転送されるように動作が生じる。つまり、ALTサブシステムは、再帰モードだけをサポートする。DNSのシステムによる解決のあと、目的のホストEIDを含む中間のRNIが要求者によって取得される。そして、代理の要求者であるITRイングレストンネルルータは、このEIDを用い、名前解決の要求をALTサブシステムに送る。中間のNMSEであるALTサーバは、ETRに達するまで再帰的にこの要求を転送する。ETRは、ホストにとって最終的な要求RNIである、対応するRLOCを要求元のITRに返答する。ふたつのサブシステムが異なる要求者を有する点は、注目すべきである。DNSサブシステムでは要求者はホスト自体であり、一方ALTサブシステムでは代理の要求者ITRが存在する。LISPALTにおけるふたつのサブシステムでの反復解決手順が、一例として、図4に示される。図4において、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。DNSサブシステム130での対応解決手順はステップ1.1から1.5を含む。Host1.K.C.Yのホスト12が解決要求をローカルDNSサーバ30Lを介してDNSサブシステム130に送り、DNSサブシステム130は再帰のまたは反復の手順を遂行しローカルDNSサーバ30Lを介してHost1.K.C.YにEIDHost2を返答する。それから、反復的にITR21がALTサブシステム140での対応解決手順ステップ2.1から2.3を実行する。ITR21はALTサブシステム140に、最初の対応解決手順で得ているEIDを伴う要求を行い、これにより、ALTサブシステム140は再帰的解決を行って、ITR21に対してホスト11PのRLOCであるRLOCHost2を返答する。符号22は、既述したETRである。脅威上記記載の各NMSは、種々の攻撃下で脆弱性を有する。このような脅威は、以下のような5つの手順において生じる可能性がある。すなわち、1ひとつのホストがその名前とRNIとを登録するとき、2NMSEが登録情報を交換するとき、3ひとつのホストがほかのホストの名前解決を要求するとき、4ひとつのホストがほかのホストと通信を行うとき、5ひとつのホストがその情報を更新するとき、である。これらの5つの手順において攻撃者は、成りすまし攻撃、中間介入攻撃MIMA、または繰り返し攻撃を仕掛ける可能性がある。成りすまし攻撃は、上記の各手順において異なる形式を持ち得る。登録の手順では、攻撃者は、正規のホストを騙り、成りすましでホスト名やRNIを登録する可能性があり、あるいは、正規のNMSEに対して、真の身分を隠してホストのための登録を行う可能性がある。情報交換の手順では、攻撃者は、真の身分を隠して正規のNMSEに対して偽の情報をほかのNMSEに提供するよう仕向け、NMSを誤動作させる可能性がある。名前解決の手順では、攻撃者は、正規のNMSEを騙り、ホストに偽の情報を提供して、DoS攻撃やサイトの乗っ取りを行う可能性がある。また、攻撃者は、正規のホストを騙り、NMSから情報を不正に得、あるいは、NMSの動作を途切れさすように偽のメッセージを浴びせる可能性もある。また、通信の手順では、攻撃者は、正規のホストに成りすましてほかの個人使用のホストをだます可能性がある。同様に、攻撃者は、CHやNMSEに偽のRNIを通知して特定のホストとの正規の相互通信を切断する可能性もある。MIMAは、中間介入の攻撃者による送信メッセージの改ざんで行われ得る。例えば、ホストとNMSEとの中間に介入した攻撃者は、ホストの登録情報を変更する可能性があり、また、送信された解決結果におけるマッピング情報を変更する可能性がある。繰り返し攻撃は、攻撃者が個人的目的を達するため、過去のパケットを繰り返し送りつけなされる。本発明の実施形態は、一般的な世界規模のNMSの構造にセキュリティ上の特徴的造作を組み込み、埋め込むものである。これにより、上記の攻撃からその構造自体で自己保護を可能とする。IBE、IBSこの実施形態において、IDベース暗号IBEとIDベース署名IBSとを含むIDベース暗号技術が利用される。この技術は、自己証明できるIDに大きな利点を有するためである。ここで、その基本的な機能を説明する。IBEの基本的な仕組みが図5に示される。IBEによって、送信者アリスは、受信者ボブのIDを利用しメッセージMを暗号化することができる符号1A。受信者ボブは、キーサーバKS3から得た秘密鍵PKBobを利用し、暗号文を復号解読することができる符号2A。IBEにおける基本的機能は次である。1準備:KS3は、ハッシュ関数の情報を含む、双線形群と公開パラメータPPsとを選択し、マスター鍵MKおよび対応する公開鍵PubKKSを生成する。図5において、PubKKSとPPsとはアリスおよびボブ両者に通知される。2鍵生成:KS3は、ユーザボブのIDに基づいて関数KeyGenMK,IDを用いてユーザのため秘密鍵を生成する。図5において、ボブは、その秘密鍵PKBobを獲得する。PKBobは、ボブのIDとPubKKSとPPsとに対応づけられている。3暗号化:通信者アリスは、ボブのIDを使ってメッセージを暗号化する。図5において、アリスは、メッセージMを暗号化し、ボブのIDを使い暗号文Cを得る。4復号:通信者ボブは、その秘密鍵を用いて暗号文を復号する。図5において、ボブは、その秘密鍵PKBobを用いてアリスからの暗号文を復号し、平文のメッセージを得る。IBSの基本的な仕組みが図6に示される。IBSによって、送信者アリスは、その秘密鍵を用いてメッセージMに署名をし、署名のあるメッセージSigAliceを受信者ボブに送る符号1B。受信者ボブは、アリスのIDを利用して署名の正当性を検証できる符号2B。IBSにおける基本機能は以下である。1準備:KS3は、双線形群とPPsとを選択し、マスター鍵MKおよび対応する公開鍵PubKKSを生成する。2鍵生成:KS3は、ユーザアリスのIDに基づいて関数KeyGenMK,IDを用い、ユーザのため秘密鍵を生成する。この関数は、IBEでのものと同一でもよくまたは違っていてもよい。図6において、アリスは、そのIDに対応して秘密鍵PKAliceを獲得する。3署名:通信者アリスは、その秘密鍵を用いメッセージに署名を行う。図6において、アリスは、メッセージMに署名を行い、PKAliceを使い、そして署名SigAliceを得る。4認証:通信者ボブは、アリスのIDを使い署名を検証できる。図6において、ボブは、アリスのIDAliceを使いアリスからの署名を検証する。IBEとIBSとで、マスター鍵、公開鍵、公開パラメータ、および鍵生成関数は同一でも異なってもよい。以下の説明では、その簡単化のため、それらは、IBEとIBSとで同一であるとして説明する。IBEとIBSとは、信頼性のある第三者の介在がなしで認証が済むという、有利な特徴を有している。すなわち、PubKKSおよびPPsKSを得た後では、通信者は、互いに認証を直接に行うことができ、その通信者が特定のIDを持っているかどうかを判断できる。略記略記について以下に参照のため述べる。これは、以下の記載でも用いられる。1.KS:キーサーバ2.PubKKS:KSのマスター鍵に対応するその公開鍵ひとつの特定のホストに属さない3.PPsX:装置Xに現在保持されている、KSによって選択された公開パラメータ4.NameX:装置Xのホスト名5.IDX:装置XのIDであり、NameXに失効時間が付加された形式を有する。6.PKX:装置XのIDXに対応する、装置Xの秘密鍵7.SigX:装置Xの秘密鍵PKXによってIBS署名技術を使ってなされたその署名8.{M}IDX:装置XのIDXによってIBE暗号技術を使い暗号化されたメッセージ9.TM:タイムスタンプ10.Nk:時刻kで生成されたランダム数11.SK:セッション鍵対称鍵12.NMSE:NMSネームマッピングシステム装置13.RNI:MNSサブシステムに登録された関連必要情報14.RNISSiHostk:NMSサブシステムSSiに登録された、ホストkのRNI15.ED:エッジドメイン16.EDKS:エッジドメインキーサーバ17.SS:NMSサブシステム18.SSKS:NMSサブシステムのためのキーサーバ19.GW:ゲートウエイ20.{M}SK:SKによって対称暗号技術で暗号化されたメッセージ21.||:付加演算子実施形態における課題の確認われわれは、NMSに自己保護性を持たせ、全体のシステムに信頼性を埋め込むことを意図する。現在の技術は、規模や、アドオンによる認証基礎構造への頻繁なアクセスなどの種々の制限のため適合的でない。そこで、種々の攻撃下でも免疫をもつ自己保護高信頼性NMSSelfprotectableSecureNMS:S2NMSの設計が望まれる。すなわち、次のような手順を設計する。1.信頼性のある登録:ホスト登録情報が中間の装置で改ざんされないことを保証するため、ホストとNMSEとの間の相互認証が実行される一方、過去のパケットが繰り返されないようにする。これは、登録手順において、成りすまし攻撃、MIMA、および繰り返し攻撃を避けようとするものである。2.ひとつのサブシステム内またはひとつのエッジドメイン内での信頼性のある情報交換:これは、ひとつのSS内またはひとつのED内で流された情報が、自称のものから確かに提供されたことを保証するものである。また、MIMAおよび繰り返し攻撃を避けようとすることも含む。2.信頼性のある名前解決:再帰または反復による解決において、ホストとひとつのSS内のNMSEとの間で相互認証がなされように保証すること。また、SSをまたいだ反復による解決が保護されるようにすること。これは、解決の手順における成りすまし攻撃を避けようとするものである。また、MIMAおよび繰り返し攻撃を避けようとすることも含む。3.ホスト間の相互認証:ひとつの特定の名前を有する通信ホストの持ち主を検証できるように保証すること。これは、成りすまし攻撃、MIMA、および繰り返し攻撃を避けようとするものである。4.信頼性のある対応関係の更新:ホストがその移動を通知したときそのホスト名が確かにその自称のものであることを保証すること。これは、成りすまし攻撃、MIMA、および繰り返し攻撃を防止しようとするものである。上記のことから、本実施形態は、NMSを伴ったグローバルな認証枠組みの設計を意図していることがわかる。これにより、各装置に、この構造で情報を提供する通信装置の真の身元を知らしめることができる。課題解決の方向NMS構造に自己保護性を埋め込んで、自己保護性を有しかつ高信頼性としたNMSS2NMSが提案される。これにより、登録、情報交換、解決、通信、および対応関係更新の各手順で用いられる各装置が、確実な情報獲得のため互いを認証できるようにする。このS2NMSでは、IBEおよびIBSを基本とすれば、信頼性ある第三者が必要ないという名前認証における特長を確約するということから、これを基本セキュリティ機能として採用する。S2NMSの構造的レイアウトの全体が図7に示される。これは以下の点は一般的なネットワークと同様である。すなわち、この構造は、前提として、ローカルなエッジドメイン1N1、1N2、...、1N3と、グローバルな情報転送ネットワーク200と、制御プレーンであるNMS100とからなる。なお、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。次に、このNMS構造にセキュリティを組み込むため、2つの新規な装置が導入される。同図中に示すエッジドメインキーサーバEDKS61、62、...、63とNMSサブシステムキーサーバSSKS71、72、...とである。EDKSは、ひとつのドメインにおける、IBEIDベース暗号およびIBSIDベース署名の機能を持ったキーサーバである。例えば、ローカルネットワークのサービスプロバイダや、企業体ネットワークの論理的な管理サーバ、あるいは物理的なドメイン制御サーバなどとすることができる。エッジドメイン1N1、1N2、...、1N3のそれぞれに、ひとつまたはそれ以上のホスト群用として、ひとつまたはそれ以上のEDKSを設けてもよい。EDKSは、そのサービス先のドメインで、秘密のマスター鍵を保持し、その対応の公開鍵PubKEDKSと公開パラメータPPsEDKSとを発信する。また、ネットワークサービスに登録しようとするホストのため、秘密鍵PKHostを生成する責任を負う。もうひとつの新規な装置であるNMSSSキーサーバSSKS71等は、図7に示すように、ひとつのNMSSSにおける、IBEおよびIBSの機能を持ったキーサーバである。このサーバ71等は、マスター鍵を保持し、NMSサブシステムにおけるその対応する公開鍵PubKSSKSおよびPPsSSKSを、ネットワークサービスに登録したホストに通知する。また、NMSSSNMSサブシステム100A、100BのそれぞれのすべてのNMS装置31h~36h、31f~35fに対して秘密鍵PKNMSEも生成する。ひとつのSSには、複数のSSKSが存在する可能性もある。以下では、簡単化のため、ひとつのSSにひとつのSSKSがあるとものとする。図7に示すように、EDKS61、62、...、63、およびSSKS71等は、システムの全体が信頼づけられるように形作られる。EDKS61、62、...、63はひとつの信頼づけられたEDを構築するためのものであり、一方、SSKS71等はひとつのNMSSSに信頼性を与えるものである。これらの構成が、登録手順、情報交換手順、解決手順、通信手順、および対応関係更新手順に信頼性を与え、よってネットワーク構造は当然に認証のサポートされたものになる。実施形態のNMSS2NMS構造は、以下の6つの主たる部分コンポーネントからなる。1.IDフォーマットおよびセキュリティの設定。秘密鍵を失効させることが可能なIDフォーマットが導入される。また、NMSおよびひとつの信頼づけられたEDにおけるセキュリティ設定が示される。2.信頼性のある登録。ここでは、ホストおよびEDKSのセキュアな登録について詳述される。3.ひとつのSSあるいはひとつのEDでの信頼性のある情報交換。この情報交換は、ひとつのSS内のNMSEあるいはひとつのED内の装置に、対応関係やルーティングの情報交換をセキュアに行わせるものである。4.信頼性のある解決および相互認証。ひとつのSSで名前解決手順が行われる間に仕掛けられ得る種々の攻撃を避けるようにセキュアな再帰または反復の解決ステップが設計される。また、解決チェーンの全体を保護するようにSS間で反復解決を行うことの設計もなされる。さらに、ふたつのホスト間のグローバルな相互認証が詳述される。5.信頼性のある対応関係更新。ここでは、CHへのセキュアな更新の手順、およびSSへのセキュアな更新手順が提供される。6.取り消し。ここでは、秘密鍵の自動的な失効と、取り消されたホストのリストの維持とが提供される。これにより、危険に侵されたホストへの解決や接続を防止する。以上のそれぞれのコンポーネントは、次に順に詳述される。1.IDフォーマットおよびセキュリティの設定NMSは、通信のため、ホスト名をホストのRNIに対応づけるシステムである。セキュリティの仕組みとしてIBEおよびIBSが採用される。ホスト名が認証のためのホストIDとして直接に用いられる場合は、このホスト名に対応する秘密鍵が生成、利用されることになる。しかしながら、安全のため秘密鍵は一定時間ごとに失効させる必要があり、これはホスト名が頻繁に変更されることを要する意味になる。同様の考えで、ひとつの名前に対応する秘密鍵が危険に侵された場合は、この名前はほぼ永久に使えなくなる。ホスト名が認証のためのホストIDとして直接に採用されるなら、このように受け入れがたい状況になってしまう。この点を解決するため、ホストIDとしてホスト名を直接に使用しないようにする。つまり、登録手順においてEDKSが、ホスト名として、次のフォーマットのように失効時間を伴ったNameHostであるホストIDをホストに与えるようにする。失効時間は、登録時刻に失効期間を加えたものである。IDHost=NameHost||失効時間例えば、IDHost1=Host1.K.C.Y||201110081200IDHostの例として、ホスト1のホスト名が、Host1.K.C.Yであるとき、IDHost1は、例えば2011年10月8日の12時に失効する、という具合である。このホストIDおよび対応する秘密鍵が、サービスを行っているEDKSによってホストに提供される。NMSサブシステムSSにホスト名およびRNIを登録するときには、このIDがホストの身元を認証するため用いられるが、そのままNMSに登録されず、ホスト名のみが登録される。名前解決手順、相互認証手順、およびローケータ更新手順でも、このIDが互いの認証のために利用されるが、名前解決自体ではホスト名、つまりIDのうちのホスト名の部分が利用される。以上のIDフォーマットを導入し、次に、SSおよびEDのためのセキュリティ設定の導入がなされる。SSは、ホスト名またはRNIを解決するための階層構造または平坦構造のNMSEを有している。例えば、図8aに示すNMSサブシステム100Kでは6つのNMSE31h~36hこれらは階層構造であるが、平坦構造のNMSEが設けられた場合も同様である。以下では、階層構造のNMSE31h~36hとして説明するがある。NMSが信頼性ある名前解決サービスを提供できるようにするため、NMSサブシステム100KにSSKS71Kが導入され、これらのNMSE31h~36hに対してIDベース暗号技術に基づき秘密鍵を生成する。このサブシステム100Kで、SSKS71は、IBEおよびIBSのセキュリティ機能と同様に、ひとつのマスター鍵とこれに対応するひとつの公開鍵とを生成する。そして、公開鍵PubKSSKSkとそのPPsであるPPsSSKSkとをすべてのNMSE31h~36hに通知する。新たにNMSEが加えられたときには、その名前および失効時間に基づいてSSKS71はIDを生成し、さらにこのNMSE31h~36hのためそのIDに対応する秘密鍵をIDベース暗号技術に基づいて生成し、このNMSEにPubKSSKSkおよびPPsSSKSkを送る。基礎的な構成設定のあと、サブシステム100Kでは、NMSE31h~36hそれぞれがIDNMSE、PubKSSKSk、PPsSSKSk、およびその秘密鍵PKNMSEを保持することになる。例えば、NMSE6であるNMSE36hは、IDNMSE6、PubKSSKSk、PPsSSKSk、PKNMSE6を保持する。通信者は、NMSE36hに送るメッセージを、IDNMSE6を用いて暗号化することができ、NMSE36hは、認証づけられた送信元であることを示すため、PKNMSE6を使ってメッセージに署名することができる。同様に、ひとつのED内のEDキーサーバ6Mは、IDおよび秘密鍵の生成を行い、公開鍵および公開パラメータの通知をルータ、ゲートウエイ、およびホストに対して行うことの責任を有している。図8bに例示されるように、基礎的な構成設定のあと、ゲートウエイ4MはPubKEDKSm、PPsEDKSm、IDGW、PKGWを持ち、ルータ91R1は、PubKEDKSm、PPsEDKSm、IDR1、PKR1を持ち、基地局81BS1は、PubKEDKSm、PPsEDKSm、IDBS1、PKBS1を持ち、ホスト11Xは、PubKEDKSm、PPsEDKSm、IDHostX、PKHostXを持つことになる。ルータ92R2、93R3、...についても同様である。2.信頼性のある登録基本的なセキュリティの構成設定のあと、ホストおよびEDKSは、検索され得るように登録される必要がある。異なるサブシステムには異なるRNIが登録され得るが、あるひとつのサブシステムに登録されるとき、登録に関わる装置は、すでに述べた成りすまし攻撃を避けるため、互いに認証を行う必要がある。すなわち、ひとつのホストがそれにサービスを行うNMSEであるNMSEkに登録するとき、そのホストはNMSEkの身元を確認する必要があり、NMSEkは、このホストの正しい構成設定を確認する必要がある。同様な要求は、EDKSの登録手順でも生じる。ホストの登録手順には2つのフェーズがある。最初のフェーズ1は、図9に示されるように、自装置のIDとこれに対応する秘密鍵とをEDKSから手に入れることである。次のフェーズ2は、図10に示すように、ホスト名およびRNIをサブシステムに登録し、その存在を通知することである。図9は、フェーズ1の例を示し、これによりNameHost1の名前のホスト1は、EDKSmがサービスするEDにおいてネットワークサービスを得ることができる。ホスト1の持ち主がEDからサービスを受けるには、まず、サービスセンターからホームルータHRを得る必要がある。あるいは、ホスト1の持ち主は、家にすでに設けられたHRを使うこともできる。図9に示すようにホームルータBが設けられた後、ホスト1は、サービスセンターにあるホームルータBにあらかじめロードされているIDEDKSm、PubKEDKSm、およびPPsEDKSmをホームルータBから手に入れることができる。それからホスト1は、キーサーバであるEDKSmのIDで暗号化された、ホスト1の名前、SK、Nl、およびTMl以上のものを含む暗号情報を送ることによってEDKSmにサービスを要求する。SKセッション鍵は、対称鍵であり、これは、ホスト1とEDKSmとの間のセキュアな通信のため用いられる。EDKSmは、この情報を受け取るとIBE機能を使ってそのメッセージを復号し、この要求を受け入れるか否かを決定する。決定がイエスであれば、EDKSmは、ホスト1に向けて、IDHost1=NameHost1||失効時間、のごとくにそのIDを生成し、さらにIBEおよびIBSの鍵生成手順を用い、IDHost1に対応する秘密鍵PKIDHost1を生成する。それからEDKSmは、セッション鍵SKで暗号化された{IDHost1、PKIDHost1、PubKSSKSl、PPsSSKSl、N1、TM2}を、署名SigIDEDKSmを添えて送る。ここでPubKSSKSlおよびPPsSSKSlは、サブシステムそれぞれで必要とされる公開鍵および公開パラメータを一般化して意味するものである。以下では簡単のため、PubKSSKSlおよびPPsSSKSlがそのそれぞれを表すものとする。PubKSSKSlおよびPPsSSKSlは、ホスト1がSSlに対して登録および名前解決を要求したときに、ホスト1とSSl内のNMSEとが相互認証するため用いられる。署名SigIDEDKSmが添えられたメッセージをホスト1が受け取ると、ホスト1は、この署名を検証しかつセッション鍵による復号を行ってそのIDであるIDHost1およびその秘密鍵PKIDHost1を得、これをインストールする。最後に、ホスト1は、IBS署名SigIDHost1が付されたIDHost1、N2、TM3を送る。このメッセージをEDKSmが受け取ると、EDKSmは、SigIDHost1の正当性を検証することができ、これでホスト1によりPKIDhost1が正しくインストールされたことの確証を得られる。図10は、フェーズ2を示し、これによりホスト1は、そのIDおよび対応の秘密鍵のインストールを完結した後に、ひとつのサブシステムにその情報の登録を行う。別のサブシステムへの登録手順も同様なので、その手順の図解に、例として、SSiへの登録手順を挙げ説明する。この手順において、ホスト1は、最初に、そのIDであるIDHost1を添えて、NMSサブシステムであるSSiに登録要求を送る。SSiは、それに対応してサービスを行うNMSEであるNMSEkの発見を行い、これによりNMSEkは、その署名SigIDNMSEkを添えて、ホスト1に向けIDNMSEk、Ni、TMiを返答する。ホスト1は、IDNMSEkを使うことでその署名SigIDNMSEkを検証してこの情報の正当性を検証する。そして、ホスト1は、IDNMSEkで暗号化された{ホスト1の名前、ホスト1のRNI、PubKEDKSHost1、PPsEDKSHost1、Ni}と、TMjとを含み、かつ署名SigIDHost1を伴った情報を生成して、これをNMSEkに送る。これに対しNMSEkは、SigIDHost1の正当性を検証し、メッセージを復号し、ホスト名およびEDKS情報が正当かどうか点検する。すべての点検に合格すると、EDKSの情報を含むホスト1のすべての情報を登録する。EDKSの情報は、名前解決手順での通信装置によって獲得され得、そのときに相互認証のため用いられる。ホスト名、公開鍵、および公開パラメータは、基本的な登録情報であり、これらはすべてのサブシステムSSに登録される必要がある。なお、異なるSSには異なるRNIが登録され得る。例えば、LISPALTのNMSにおいては、EID情報はDNSサブシステムに登録される一方、RLOCルーティング情報はALTサブシステムに登録される。セキュアなホスト登録手順においては、ホストおよびその対応のNMSEの相互認証が実行される。またそのとき、NMSEはホストから提供された情報の正当性を点検することができ、さらに、MIMAや繰り返し攻撃もランダム数およびタイムスタンプを用いて回避される。ひとつのEDKSでEDがサービスされるように意図するとき、EDKSはEDKS登録手順によりNMSサブシステムに登録される必要がある。これは、ホストのNMSへの登録と同様である。PubKSSKSiおよびPPsSSKSiがEDKSにあらかじめロードされている。EDKSはNMSサブシステムに登録要求を行い、これに対してSSiの特定のNMSEが、そのIDを返答し、それで、EDKSは、ED名、EDKS名、EDKSローケータ、PubKEDKS、PPsEDKS、およびランダム数をNMSEのIDで暗号化し、これにその署名を添える。NMSEがこのメッセージを受け取ると、これを復号し、公開情報を獲得し、署名の正当性を検証する。そして、EDKS情報を登録する。同様にして、EDKSはその情報をすべてのサブシステムに登録する。3.ひとつのSS内またはひとつのED内での信頼性のある情報交換登録されたRNIは、ID、ローケータ、ルーティング情報のほか、別の考え得る情報である可能性がある。ひとつのSS内での情報交換という状況は、そのSS内でRNIを共有する必要がある場合に対応して生じ得る。そこで、ひとつのSS内において情報提供者のために身元認証を行うことが、セキュアな情報交換によって提供される。ひとつのSSに、そこに存在するNMSEのため鍵生成を行い公開鍵および公開パラメータの通知を行うひとつのキーサーバSSKSが存在する。それで、すべてのNMSEは同じ公開鍵PubKSSKSと公開パラメータPPsSSKSとを有する。信頼性のある情報交換手順が図11に示される。図11において、SSi内のNMSExは、NMSEkに対して情報を提供しようとし、提供する情報、現時点でのそのIDであるIDNMSEx、およびNj、TMjを、その署名SigIDNMSExを添えて送り出す。このメッセージをNMSEkが受け取ると、SigIDNMSExを検証し、検証の通過後に、提供された情報を登録する。ひとつのED内でも、ルータ、GW、およびほかの装置などの装置間でルーティング情報を交換するとき、同様の手順がなされ得る。4.信頼性のある解決および相互認証あるホストが別のホストと通信しようとするとき、その通信者の名前をローケータとして解決することを、そのあるホストはNMSに要求する必要がある。これが、いわゆる解決手順である。NMSはひとつまたはそれ以上の数のサブシステムを有するので、解決手順は、単一のSSでの解決で足りるか、または複数のSSにおける連続的な解決になるかのいずれかである。ひとつのSS内での解決モードには、再帰方式および反復方式という2つの方法があり得る。一方、すでに述べたように、SS間をまたがる場合には、それらとの関係として反復方式のみが用いられる。これらのことにより、NMSにおける信頼性のある解決も、3つの部分として実現される。すなわち、ひとつのNMSサブシステム内での信頼性のある再帰解決および反復解決、ならびにNMSサブシステム間での信頼性のある反復解決である。ひとつのNMS内における再帰方式の場合のセキュアな名前解決の手順が図12に示される。図12において、ホスト1が、ひとつのNMSサブシステムであるSSiに対して、ホスト2発信先装置の名前であるNameHost2の解決要求を行う。このサブシステムのキーサーバはSSKSiである。ホスト1は、IDHost1、NameHost2、N1、およびTM1を伴った、その署名SigIDHost1付きの要求メッセージをNMSEmに送る。NMSEmは、このメッセージを受け取ると、次のNMSE0にこの要求を転送する。このような要求の転送により、最後に、対応してサービスを行うNMSExに要求が届く。NMSExは、PubKEDKSHost1およびPPsEDKSHost1をこのサブシステムから獲得する。これは、ホストおよびEDKSの登録がなされたときに、それらがすでにサブシステムに登録されているから可能である。そして、NMSExは、PubKEDKSHost1、PPsDEKSHot1、およびIDHost1によってSigIDHost1の正当性を検証する。これに合格すると、NMSExは、ホスト2のRNIを探索、獲得し、NameHost2、PubKEDKSHost2、PPsEDKSHost2、N1をIDHost1によって暗号化する。最後に、NMSExは、暗号化メッセージにタイムスタンプおよび署名SigIDNMSExを加えてこれをホスト1に送る。ホスト1は、このパケットを受け取ると、PubKSSKSiおよびPPsSSKSiをすでに有しているので、これを用いてSigIDNMSExの正当性を検証できる。そして、暗号化メッセージを復号し、ホスト2に関する情報である、RNIHost2、PubKEDKSHost2、PPsEDKSHost2を獲得する。ひとつのサブシステム内で反復モードが利用されるときには、信頼性のある反復解決がなされる必要があり、これが図13、図14に示される。信頼性のある反復解決手順では、対応のNMSEにたどり着くまでに複数の反復ステップが存在する。図13に示す反復ステップにあるように、ホスト1は、その署名SigIDHost1を添えてIDHost1、NameHost2、N1、TM1を伴う解決要求をNMSEmに送る。ここでNMSEmという表記は、最初のNMSEから最後にサービスを行うNMSEに至るまでのその途上のNMSEを一般化して表したものである。これらのNMSEには、同じ並びのメッセージが送られるからである。この要求をNMSEmが受け取ると、NMSEmは、NMSEmの署名を添えて、IDHost1で暗号化された、次に要求を送ることが可能なNMSEの名前およびローケータの一覧を返答する。ここでは、簡単化のため、このような一覧の代わりに、単一のNMSEの名前およびローケータが送られるものとする。いずれにしてもホスト1は、そのひとつを選んでそれに要求を送るからである。ホスト1がこのメッセージを受け取ると、SigIDNMSEmを検証し、メッセージを復号して次のNMSEの名前およびローケータを獲得する。そして次に、ホスト1は、このNMSEをNMSEmに対応させて同様のことを行う。図14に示すように、要求メッセージが最後にサービスを行うNMSEに達して、最後の解決ステップが実行される。このステップでは、ホスト1は、最後のNMSEであるNMSExに対してNameHost2の解決を要求する。ホスト2は、そのRNIを保持しているNMSExのサービスエリアに存在する。それで、NMSExは、ホスト1に対して、SigIDNMSExを添えて、IDHost1で暗号化された、RNIHost2、PubKEDKSHost2、およびPPsEDKSHost2を提供する。ホスト1は署名を検証し、最後にホスト2の情報を獲得する。以上の記述から、再帰解決でも反復解決でも、ホスト1は安全にホスト2のRNI、公開鍵、および公開パラメータを、NMSサブシステムSSiから手に入れることができることがわかる。そこで、ひとつのサブシステムにおける信頼性のある解決手順を簡略化して描いたものが図15である。図15に示すように、ホスト1は、その署名を添えて解決要求をSSiに対して送り出し、SSiは、ホスト2のRNI、公開鍵、および公開パラメータを返答する。ひとつのNMSサブシステムにおける信頼性のある名前解決についての記載に続いて、NMSサブシステム間での信頼性のある反復解決について図16、図17を参照して説明する。NMSサブシステム間の反復解決手順では、複数のサブシステムが含まれているため、最後のNMSサブシステムでの解決に至るまで複数の反復ステップが存在する。図16に示す反復ステップでは、ホスト1は、その署名SigIDHost1を添えて、SSiに対してIDHost1、NameHost2、Nk、TMkを伴う解決要求を送り出す。SSiは、最後のSSの前に位置するSSを一般化して表したものである。これは、同様の並びのメッセージがSSのそれぞれで取り扱われるためである。SSiは、この要求を受け取ると、SigIDNMSExを添えて、IDHost1で暗号化されたRNISSiHost2、PubKEDKSHost2、およびPPsEDKSHost2をホスト1に対して返答する。ここで、RNISSiHost2は、SSiに登録されたホスト2のRNIである。そこで、ホスト1は、得た署名を検証してホスト2のRNIを獲得する。最後のSSの前に別のSSが存在するならば同様の手順が実行される。ホスト1が最後のNMSサブシステムであるSSkに要求を送ると、図17に示すような最後の解決ステップが実行される。このステップでは、ホスト1は、最後のSSであるSSkに対して、前のサブシステムで得られたRNIに基づいた解決を要求する。ホスト2は、SSkにおいてホスト2のRNIを保持したNMSEyのサービス領域に存在する。それで、NMSEyは、IDHost1で暗号化された、SSkでのRNISSkHost2、PubKEDKSHost2、およびPPsEDKSHost2を、SigIDNMSEyを添えてホスト1に対して提供する。ホスト1は、得た署名を検証し、ホスト2についての最後の解決情報を得る。多くの場合、信頼性のある通信のためには、相互の認証が必要である。上記の一方向の解決手順では、発信元ホストは、発信先ホストの名前、ローケータ、公開鍵、公開パラメータを得るが、これは、発信元ホストから発信先ホストの現在のIDを得てその確認が可能であるということである。しかしながら、この手順では、発信先ホストは、発信元ホストの身元を確認することができない。これは、一方向の解決のみが行われるならば、発信先ホストが確認可能な発信元ホストの情報を持ち得ないからである。S2NMSでは、発信先ホストも発信元ホストの名前、RNI、公開鍵、公開パラメータを獲得できるように、他方向の解決手順を実行するようにする。これにより、発信先ホストと発信元ホストとの相互認証が円滑になされ得る。その認証手順が図18に示される。相互認証を行うため、ホスト1は、ランダム数N1を生成し、その現在のIDであるIDHost1のほか、NameHost2、N1、およびTM1をその署名SigIDHost1を添えてホスト2に送る。ホスト2は、この情報を受け取ると、NMSを用いて、IDHost1の一部であるNameHost1を解決し、ホスト1のPubKEDKSHost1、PPsEDKSHost1を獲得する。そして、SigIDHost1の検証を行う。検証を通過した後、ホスト2は、対称鍵SKを生成し、さらに、IBE暗号化機能によりIDHost1で暗号化された、対称鍵SK、N1、およびN2の暗号情報を生成し、これにその現時点のIDであるIDHost2およびTM2を加え、署名SigIDHost2を添えてホスト1に送る。SigIDHost2をホスト1が検証して、さらにメッセージを復号しSKを得る。そして、SKでN2が暗号化されてホスト2に送られることにより、これらの間に、セキュアな通信チャンネルの確立がなされる。5.信頼性のある対応更新ホスト1がネットワークのあるアタッチポイントから異なるアタッチポイントへ移動したときに、そのホスト名が維持され得るように意図したとする。この状況下では、ホスト1は、その新たなローケータをそのCHであるホスト2および対応するNMSサブシステムに対して更新する必要がある。図19におけるホスト2への信頼性のある対応関係の更新に関して、ホスト1は、その署名SigIDHost1を添えて、そのIDであるIDHost1、古いローケータであるLocator1、新しいローケータであるLocacor2をホスト2に送り出す。ホスト2は、このパケットを受け取ると、すでに解決手順でホスト1の公開鍵および公開パラメータを得ているので、この署名の正当性を直接に検証できる。検証できたら、ホスト2は、ホスト1の古いローケータLocator1を新たなローケータLocator2に置き換える。対応のNMSサブシステムに対してローケータ更新を行う場合にも、同様の手順が実行される。NMSサブシステムにとってホスト1の公開鍵は既知なので、NMSEは容易にホスト1の署名の正当性を検証できそのローケータを更新できる。6.取り消しS2NMSでは、ふたつの方法が取り消しのため採用される。ひとつは、IDに基づく自動的な失効であり、もうひとつは、ブラックリストの維持である。すでに述べたように、ホストIDは、失効時間を伴ったホスト名という形式で、登録手続きによりホストに対して発行される。このIDは、失効時間が示す時刻より前で使用できる。ホストは、失効時間に達する前に、対応してサービスを行うEDKSに対して、さらなる認証のため、失効時間の延長された新しいIDおよび新しい秘密鍵の発行を要求する必要がある。しかし、IDおよび失効時間はNMSに登録される情報でないので、NMSへの登録をやり直す必要はない。一方、IDおよび対応する秘密鍵が失効時間の前に危険に侵された解読された場合についても考慮しておく必要がある。あるホストの現時点の秘密鍵が危険に侵された場合、取り消しの手順が必要である。そこで、対応するNMSEは、ホストについての取り消しリストを保持する。NMSEのそれぞれは、そのサービス領域でサービスされるホストのみについて取り消しホストリストを保持する。この取り消しホストリストには、取り消されたホスト名および失効時間が記録される。したがって、解決手順において、NMS解決が成功裏に終わったとしても、対応のNMSEは、要求された発信先ホストが取り消しリストにあるかどうかを点検する。それがリストにあれば、エラーメッセージが発信元ホストに返信される。それ以外は、通常のNMS解決が実行される。また、これらの取り消された名前は、失効時間に達すれば削除される。実施形態の効果本実施形態によれば、以下の効果が得られる。1.ホストは、信頼性高くそれらの情報をNMSに登録できる。これは、ホストとNMSEとの間の相互認証が可能であるからであり、MIMAや繰り返し攻撃も避けることができる。2.NMS内のNMSEおよびED内の各装置が、登録情報またはルーティング情報を信頼性高く交換することができる。また、MIMAや繰り返し攻撃も防止できる。3.発信元ホストが、信頼性高く発信先ホストの名前をそのローケータ、公開鍵、およびさらなるRNIとして解決できる。これは、発信元ホストとNMSEとの間で、再帰または反復のモードによる相互認証がなされるためであり、NMSサブシステム間では、反復のモードで信頼性のある解決がなされるためである。4.ホスト間の相互認証がなされ得る。相互の名前解決手順のあと、2つのホストは、互いの通信者の現時点のID、ならびにそのサービスを行うEDKSの公開鍵および公開パラメータを得ることができる。これにより、通信開始前に相互の認証が円滑に行われる。5.マッピング対応情報が信頼性高く更新できる。これは、CHおよび対応するNMSEが、更新を必要とするホストの公開鍵を知っているからである。それで、CHおよび対応のNMSEは、受け取った更新パケットの正当性を容易に確認できる。"