"キーサーバが有するIDである第1のIDに基づき、自装置のIDである第2のIDとセッション鍵とを少なくとも含む第1の情報を暗号化して第1の暗号情報を生成する手段と、前記第1の暗号情報を前記キーサーバに送出する手段と、前記第1の暗号情報を前記キーサーバが復号して得た前記第2のIDに対応して前記キーサーバが生成した秘密鍵を少なくとも含む第2の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第2の暗号情報とされてかつ前記キーサーバの署名であるサーバ署名が付されて前記キーサーバから送られてきたときに、該第2の暗号情報および該サーバ署名を受け取る手段と、前記サーバ署名の正当性を検証する手段と、前記第2の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、自装置のグローバルホスト名を登録解決するサーバである登録解決サーバのIDたる第3のIDに基づき、自装置の前記グローバルホスト名と、前記第2のIDと、自装置のローケータと、を少なくとも含む第3の情報を暗号化して第3の暗号情報を生成しかつ該第3の暗号情報に自装置署名を付す手段と、前記第3の暗号情報および前記自装置署名を前記登録解決サーバに送出する手段とを具備することを特徴とするホスト装置。前記第1の暗号情報が、前記第1の情報にランダム数およびタイムスタンプをさらに含ませるようにして得た情報を暗号化して得られた暗号情報であり、前記第3の暗号情報が、前記第3の情報に、前記ランダム数とは異なる第2のランダム数および前記タイムスタンプとは異なる第2のタイムスタンプをさらに含ませるようにして得た情報を暗号化して得られた暗号情報であることを特徴とする請求項1記載のホスト装置。通信をしようとする発信先装置が有するグローバルホスト名の解決を要求する旨の情報を少なくとも含む第1の情報に自装置署名を付して、ドメイン名を登録解決するサーバである第1の登録解決サーバに送出する手段と、前記グローバルホスト名を登録解決するサーバである第2の登録解決サーバが有するIDたる第1のIDおよび該第2の登録解決サーバのローケータである第1のローケータを少なくとも含む第2の情報が、自装置のIDである第2のIDに基づく暗号化で第1の暗号情報とされてかつ前記第1の登録解決サーバの署名である第1のサーバ署名が付されて前記第1の登録解決サーバから送られてきたときに、該第1の暗号情報および該第1のサーバ署名を受け取る手段と、前記第1のサーバ署名の正当性を検証する手段と、前記第1の暗号情報から、前記第1のIDおよび前記第1のローケータを復号して得る手段と、前記第1のIDに基づき、前記グローバルホスト名の解決を要求する旨の情報を少なくとも含む第3の情報を暗号化して第2の暗号情報を生成する手段と、前記第2の暗号情報に自装置署名を付して前記第2の登録情報サーバに送出する手段と、前記発信先装置が有するIDである第3のIDおよび前記発信先装置のローケータである第2のローケータを少なくとも含む第4の情報が、前記第2のIDに基づく暗号化で第3の暗号情報とされてかつ前記第2の登録解決サーバの署名である第2のサーバ署名が付されて前記第2の登録解決サーバから送られてきたときに、該第3の暗号情報および該第2のサーバ署名を受け取る手段と、前記第2のサーバ署名の正当性を検証する手段と、前記第3の暗号情報から、前記第3のIDおよび前記第2のローケータを復号して得る手段とを具備することを特徴とするホスト装置。前記第1の情報が、ランダム数およびタイムスタンプをさらに含む情報であり、前記第2の暗号情報に、前記自装置署名のほか、前記ランダム数とは異なる第2のランダム数および前記タイムスタンプとは異なる第2のタイムスタンプが付されて前記第2の登録情報サーバに送出がなされることを特徴とする請求項3記載のホスト装置。通信をしようとする発信先装置が有する第1のIDに基づき、発信元である自装置のグローバルホスト名を少なくとも含む第1の情報を暗号化して第1の暗号情報を生成する手段と、前記第1の暗号情報に自装置署名を付して、前記発信先装置に送出する手段と、前記発信先装置が生成したセッション鍵およびランダム数を少なくとも含む第2の情報が、前記グローバルホスト名を前記発信先装置が名前解決システムを用いて解決し得た前記自装置のIDである第2のIDに基づく暗号化で第2の暗号情報とされてかつ前記発信先装置の署名である装置署名が付されて前記発信先装置から送られてきたときに、該第2の暗号情報および該装置署名を受け取る手段と、前記装置署名の正当性を検証する手段と、前記第2の暗号情報から、前記セッション鍵および前記ランダム数を復号して得る手段と、前記セッション鍵に基づき、前記ランダム数を暗号化して第3の暗号情報を生成する手段と、前記第3の暗号情報を前記発信先装置に送出する手段とを具備することを特徴とするホスト装置。自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置のグローバルホスト名を登録解決するサーバである登録解決サーバに送出する手段とを具備することを特徴とするホスト装置。本発明は、IDおよびローケータの情報を持ち得るホスト装置において、自己保護性を向上することができるホスト装置を提供することを目的とする。上記の課題を解決するため、本発明の一態様であるホスト装置は、キーサーバが有するIDである第1のIDに基づき、自装置のIDである第2のIDとセッション鍵とを少なくとも含む第1の情報を暗号化して第1の暗号情報を生成する手段と、前記第1の暗号情報を前記キーサーバに送出する手段と、前記第1の暗号情報を前記キーサーバが復号して得た前記第2のIDに対応して前記キーサーバが生成した秘密鍵を少なくとも含む第2の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第2の暗号情報とされてかつ前記キーサーバの署名であるサーバ署名が付されて前記キーサーバから送られてきたときに、該第2の暗号情報および該サーバ署名を受け取る手段と、前記サーバ署名の正当性を検証する手段と、前記第2の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、自装置のグローバルホスト名を登録解決するサーバである登録解決サーバのIDたる第3のIDに基づき、自装置の前記グローバルホスト名と、前記第2のIDと、自装置のローケータと、を少なくとも含む第3の情報を暗号化して第3の暗号情報を生成しかつ該第3の暗号情報に自装置署名を付す手段と、前記第3の暗号情報および前記自装置署名を前記登録解決サーバに送出する手段とを具備することを特徴とする。また、本発明の別の態様であるホスト装置は、通信をしようとする発信先装置が有するグローバルホスト名の解決を要求する旨の情報を少なくとも含む第1の情報に自装置署名を付して、ドメイン名を登録解決するサーバである第1の登録解決サーバに送出する手段と、前記グローバルホスト名を登録解決するサーバである第2の登録解決サーバが有するIDたる第1のIDおよび該第2の登録解決サーバのローケータである第1のローケータを少なくとも含む第2の情報が、自装置のIDである第2のIDに基づく暗号化で第1の暗号情報とされてかつ前記第1の登録解決サーバの署名である第1のサーバ署名が付されて前記第1の登録解決サーバから送られてきたときに、該第1の暗号情報および該第1のサーバ署名を受け取る手段と、前記第1のサーバ署名の正当性を検証する手段と、前記第1の暗号情報から、前記第1のIDおよび前記第1のローケータを復号して得る手段と、前記第1のIDに基づき、前記グローバルホスト名の解決を要求する旨の情報を少なくとも含む第3の情報を暗号化して第2の暗号情報を生成する手段と、前記第2の暗号情報に自装置署名を付して前記第2の登録情報サーバに送出する手段と、前記発信先装置が有するIDである第3のIDおよび前記発信先装置のローケータである第2のローケータを少なくとも含む第4の情報が、前記第2のIDに基づく暗号化で第3の暗号情報とされてかつ前記第2の登録解決サーバの署名である第2のサーバ署名が付されて前記第2の登録解決サーバから送られてきたときに、該第3の暗号情報および該第2のサーバ署名を受け取る手段と、前記第2のサーバ署名の正当性を検証する手段と、前記第3の暗号情報から、前記第3のIDおよび前記第2のローケータを復号して得る手段とを具備することを特徴とする。また、本発明のさらに別の態様であるホスト装置は、通信をしようとする発信先装置が有する第1のIDに基づき、発信元である自装置のグローバルホスト名を少なくとも含む第1の情報を暗号化して第1の暗号情報を生成する手段と、前記第1の暗号情報に自装置署名を付して、前記発信先装置に送出する手段と、前記発信先装置が生成したセッション鍵およびランダム数を少なくとも含む第2の情報が、前記グローバルホスト名を前記発信先装置が名前解決システムを用いて解決し得た前記自装置のIDである第2のIDに基づく暗号化で第2の暗号情報とされてかつ前記発信先装置の署名である装置署名が付されて前記発信先装置から送られてきたときに、該第2の暗号情報および該装置署名を受け取る手段と、前記装置署名の正当性を検証する手段と、前記第2の暗号情報から、前記セッション鍵および前記ランダム数を復号して得る手段と、前記セッション鍵に基づき、前記ランダム数を暗号化して第3の暗号情報を生成する手段と、前記第3の暗号情報を前記発信先装置に送出する手段とを具備することを特徴とする。また、本発明のさらに別の態様であるホスト装置は、自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置のグローバルホスト名を登録解決するサーバである登録解決サーバに送出する手段とを具備することを特徴とする。本発明によれば、IDおよびローケータの情報をもち得るホスト装置において、自己保護性を向上することができる。以上を踏まえ、以下では本発明の実施形態を適宜、図面を参照しながら説明する。説明の準備事項現在のインターネットの構造は、将来の社会的ニーズを満足させることができない。インターネットを最初から設計し直して、新世代ネットワークNWGNを構築する必要がある。NWGNにおける構造に向けて、われわれは、HIMALISHeterogeneityInclusionandMobilitythroughLocatorIDSeparationという概念を提案した。HIMALISではID識別子とローケータとを分離する。HIMALISの構造は、ホスト名とIDとを形づくる、新規な名称づけの枠組みを提供する。HIMALISでは、グローバルホスト名は、つながりを表わす記号を用いてローカルホスト名とドメイン名とを繋ぐことによって構成され、世界で唯一の名称になる。例えば、sensortemproom5202mydomaincomのごとくである。ホストIDは、プレフィックス、スコープ、バージョンの各フィールドに、グローバルホスト名と付加パラメータとの暗号化されたハッシュ値を繋ぐことで発生される。すなわち、ホストID=プレフィックスバージョンスコープハッシュグローバルホスト名、パラメータ、である。以下、単にホスト名という場合は、ローカルホスト名ではなくグローバルホスト名を意味する。HIMALISは、主に、ローカルなエッジすなわち、アクセス用のネットワークと、グローバルな情報転送ネットワークと、統一された論理制御ネットワークとからなる。HIMALISでは、3つの構成、すなわち、ドメイン名レジストリサーバDNR、ホスト名レジストリサーバHNR、IDレジストリサーバIDRが導入される。DNRは、ドメイン名と、いくつかのドメイン内のホスト名を管理するHNRのIDおよびローケータとの対応を記憶している。HNRは、いくつかのドメイン内のホスト名とそのIDおよびローケータとのマッピングを記憶している。IDRは、移動装置の、ホストIDとローケータとの間のつながりを記憶しまた分配する。DNRとHNRとは、通信の初期化の段階で、名前を登録し、ホスト名をローケータとして解決するため用いられる。一方、IDRは、ネットワークにおけるホストIDとローケータとの間のつながりを更新、分配するために使われる。これらの構成は、生来的に、異なるエッジネットワークで使われている不均一なネットワーク層プロトコルを、ゲートウエイを含むネットワークノードを通してグローバルなNWGNに統合し、その時間的変化にも左右されない。HIMALISの主たる機能は、名前の登録および解決と、ローケータの更新とからなり、これを次に述べる。ホスト名の登録と解決のステップが図1に示されている。登録ステップは、ステップ1.1とステップ1.2を含む。ステップ1.1は、HNR21の名前と、そのIDおよびローケータとをDNRシステム3Sに属するDNR31に登録する。ステップ1.2は、ホスト11のホスト名と、そのIDおよびローケータとをHNR21に登録する。マッピング手順は、ドメイン名の参照とホスト名の参照とである2つの下位手順からなり、ステップ2.1から2.4である。ステップ2.1、2.2は、ホスト12が、DNR31によって、ホスト11のドメイン名をHNR21のIDおよびローケータとして解決=名前解決、以下でも単に解決という場合があるする。ステップ2.3、2.4は、ホスト12が、HNR21を用いることで、ホスト11のホスト名をホストIDおよびローケータとして解決する。ホスト11のローケータ情報の更新ステップが図2に示されている。図2は、実施形態であるホスト装置のローケータ更新を行う手順を示す説明図である。この更新ステップは、対応ノードCN更新とHNR更新という2つの手順を含む。CN更新は、ステップ1.1から1.6までとして示されているように、更新要求がCNに出され、CNがこの要求を承認する。HNR更新は、ステップ2.1から2.4までとして示されているように、更新要求がHNRに出され、HNRがこの要求を承認する。なお、図2において、符号1N1、1N2、1N3は、それぞれエッジネットワークであり、符号12は、ホスト11と通信を行っているホスト図1中に示した同符号のものと同じであり、符号41、42、43は、それぞれ、エッジネットワーク1N1、1N2、1N3と論理制御ネットワーク100とを結合するゲートウエイであり、符号51、52、53は、それぞれ、ゲートウエイ41、42、43に対応するIDRである。HNR21については、図1中に示した同符号のものと同じである。HIMALISが将来のネットワークで広く使われるようにする上で、これらの手順において、ネットワークにある装置間で信頼性のある相互動作が得られるように考えることは重要である。すなわち、HIMALISのようなID/ローケータ分離構造を設計する段階で、構造レベルとして脅威を取り除いておくのが好ましい。脅威は、次の4つの手順で生じ得る。すなわち、HNR/ホストがそのIDおよびローケータを登録するとき、あるホストがほかのホストの名前をIDおよびローケータとして解決することを要求するとき、あるホストがほかのホストと通信するとき、およびあるホストがそのローケータを更新するときである。これらの手順において攻撃者は、成りすまし攻撃、中間介入攻撃MIMA、または繰り返し攻撃を仕掛ける可能性がある。成りすまし攻撃は、上記の各手順において異なる形式を持ち得る。登録の手順では、攻撃者は、正規のHNRまたはホストを騙り、成りすましでIDを登録する可能性があり、あるいは、正規のDNRまたは正規のHNRに対して、真の身分を隠してHNRまたはホストのための登録を行う可能性がある。名前解決の手順では、攻撃者は、正規のDNRやHNRを騙り、ホストに偽の情報を提供して、DoS攻撃やサイトの乗っ取りを行う可能性がある。また、攻撃者は、正規のホストを騙り、DNRやHNRから情報を不正に得、あるいは、DNRやHNRの動作を途切れさすように偽のメッセージを充満させる可能性もある。また、通信の手順では、攻撃者は、正規のホストに成りすましてほかの個人使用のホストをだます可能性がある。同様に、攻撃者は、CNやHNRに偽のローケータ更新情報を通知して特定のホストとの正規の相互通信を切断する可能性もある。MIMAは、中間介入の攻撃者による送信メッセージの改ざんで行われ得る。例えば、ホストとHNRとの中間に介入した攻撃者は、ホストの登録情報を変更する可能性があり、また、送信された解決結果におけるマッピング情報を変更する可能性がある。繰り返し攻撃は、攻撃者が個人的目的を達するため、過去のパケットを繰り返し送りつけなされる。本発明の実施形態は、HIMALISの構造設計の段階で、これにセキュリティ上の特徴的造作を組み込み、埋め込むものである。これにより、上記の攻撃からその構造自体で自己保護を可能とする。この実施形態において、IDベース暗号IBEとIDベース署名IBSとを含むIDベース暗号技術が利用される。この技術は、自己証明できるIDに大きな利点を有するためである。ここで、その基本的な機能を説明する。IBEの基本的な仕組みが図3に示される。IBEによって、送信者アリスは、受信者ボブのIDを利用しメッセージを暗号化することができる符号1A。受信者ボブは、キーサーバKS3から得た秘密鍵PKBobを利用し、暗号文を復号解読することができる符号2A。IBEにおける基本的機能は次である。1準備:KS3は、ハッシュ関数の情報を含む、双線形群と公開パラメータPPSとを選択し、マスター鍵MKおよび対応する公開鍵PubKKSを生成する。図3において、PubKKSとPPSとはアリスおよびボブ両者に通知される。2鍵生成:KS3は、ユーザボブのIDに基づいて関数KeyGenMK,IDを用いてユーザのため秘密鍵を生成する。図3において、ボブは、その秘密鍵PKBobを獲得する。PKBobは、ボブのIDとPubKKSとPPSとに対応づけられている。3暗号化:通信者アリスは、ボブのIDを使ってメッセージを暗号化する。図3において、アリスは、メッセージMを暗号化し、ボブのIDを使い暗号文Cを得る。4復号:通信者ボブは、その秘密鍵を用いて暗号文を復号する。図3において、ボブは、その秘密鍵PKBobを用いてアリスからの暗号文を復号し、平文のメッセージを得る。IBSの基本的な仕組みが図4に示される。IBSによって、送信者アリスは、その秘密鍵を用いてメッセージMに署名をし、署名のあるメッセージSigAliceを受信者ボブに送る符号1B。受信者ボブは、アリスのIDを利用して署名の正当性を検証できる符号2B。IBSにおける基本機能は以下である。1準備:KS3は、双線形群とPPSとを選択し、マスター鍵MKおよび対応する公開鍵PubKKSを生成する。2鍵生成:KS3は、ユーザアリスのIDに基づいて関数KeyGenMK,IDを用い、ユーザのため秘密鍵を生成する。この関数は、IBEでのものと同一でもよくまたは違っていてもよい。図4において、アリスは、そのIDに対応して秘密鍵PKAliceを獲得する。3署名:通信者アリスは、その秘密鍵を用いメッセージに署名を行う。図4において、アリスは、メッセージMに署名を行い、PKAliceを使い、そして署名SigAliceを得る。4認証:通信者ボブは、アリスのIDを使い署名を検証できる。図4において、ボブは、アリスのIDAliceを使いアリスからの署名を検証する。なお、以下の説明では、その簡単化のため、関数KeyGenMK,IDは、IBEでのものと同一として説明している。同一でない場合は、ホストに対して、2つの秘密鍵暗号化用および署名用を生成することになる。IBEとIBSとは、信頼性のある第三者の介在がなしで認証が済むという、有利な特徴を有している。すなわち、PubKKSを得た後では、通信者は、互いに認証を直接に行うことができ、その通信者が特定のIDを持っているかどうかを判断できる。略記について以下に参照のため述べる。これは、以下の記載でも用いられる。1.KS:キーサーバ2.PubKKS:KSのマスター鍵に対応するその公開鍵ひとつの特定のホストに属さない3.PPSX:装置Xに現在保持されている、KSによって選択された公開パラメータ4.IDX:装置XのID5.PKX:装置XのIDXに対応する、装置Xの秘密鍵6.SigX:装置Xの秘密鍵PKXによってIBS署名技術を使ってなされたその署名7.{M}IDX:装置XのIDXによってIBE暗号技術を使い暗号化されたメッセージ8.TM:タイムスタンプ9.Nk:時刻kで生成されたランダム数10.SK:セッション鍵対称鍵11.DNR:ドメイン名レジストリサーバ第1の登録解決サーバ:ドメイン名を登録解決するサーバ12.HNR:ホスト名レジストリサーバ第2の登録解決サーバ:グローバルホスト名を登録解決するサーバ13.IDR:IDレジストリサーバ14.DomainTP:ドメイン信頼ポイントエッジネットワークに備えるキーサーバ15.DNRKS:ドメイン名レジストリサーバシステムのためのキーサーバ16.GW:ゲートウエイ17.{M}SK:SKによって対称暗号技術で暗号化されたメッセージ実施形態における課題の確認われわれは、新規なID/ローケータ分離システムであるHIMALISに自己保護性を持たせ、全体のシステムに信頼性を埋め込むことを意図する。現在の技術は、規模や、アドオンによる認証基礎構造への頻繁なアクセスなどの種々の制限のため、HIMALISシステムに適合的でない。そこで、種々の攻撃下でも免疫をもつプロアクティブに信頼性のあるID/ローケータ分離構造の設計が望まれる。すなわち、次のような手順を設計する。1.信頼性のある登録:ホストとHNRとの間の登録情報が中間の装置で改ざんされないことを保証するため、ホストとHNRとの間、またはHNRとDNRとの間の相互認証が実行される一方、過去のパケットが繰り返されないようにする。これは、登録手順において、成りすまし攻撃、MIMA、および繰り返し攻撃を避けようとするものである。2.信頼性のあるID/ローケータの解決:ホストとDNRとの間、およびホストとHNRとの間の相互認証がなされように保証すること。これは、解決の手順における成りすまし攻撃を避けようとするものである。また、MIMAおよび繰り返し攻撃を避けようとすることも含む。3.ホスト間の相互認証:ひとつの特定IDを有する通信ホストの持ち主が確かめられるように保証すること。これは、成りすまし攻撃、MIMA、および繰り返し攻撃を避けようとするものである。4.信頼性のあるローケータの更新:ホストがその移動を通知したときそのIDの正確さを保証すること。これは、成りすまし攻撃、MIMA、および繰り返し攻撃をやめさせようとするものである。上記のことから、本実施形態は、HIMALISのようなID/ローケータ分離システムと合体したグローバルな認証枠組みの設計を意図していることがわかる。これにより、各装置に対して、この構造で情報を提供する通信装置が有する真のIDを知らせることができる。課題解決の方向HIMALISに自己保護性を埋め込むため、プロアクティブに信頼性のあるID/ローケータ分離の枠組みPTISFが提案される。それにより、登録、解決、通信、およびローケータ更新の各手順で用いられる各装置が確実な情報を獲得するために、互いを認証できるようにする。PTISFでは、IBEおよびIBSを基本とすれば、信頼性ある第三者が必要ないというID認証における特長を確約するということから、これを基本セキュリティ機能として採用する。PTISFの構造的レイアウトの全体が図5に示される。これは以下の点はHIMALISと同様である。すなわち、この構造は、主として、ローカルなエッジすなわち、アクセス用のネットワーク1N1、1N2、...、1N3と、グローバルな情報転送ネットワーク200と、統一された論理制御ネットワーク100とからなる。なお、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。情報転送ネットワーク200は、ゲートウエイ41、42、...、43のほか、ゲートウエイ44、45、46、...を含み得る。次に、HIMALISに組み込みセキュリティを持たせるため、2つの新規な装置が導入される。図5に示すドメイン信頼ポイントドメインTP61、62、...、63とDNRキーサーバDNRKS71とであり、また、HNRには多少の追加的機能を持たせる。図5のドメイン信頼ポイントドメインTP61、62、...、63は、ひとつのドメインにおける、IBEおよびIBS機能を持ったキーサーバである。例えば、ローカルネットワークのサービスプロバイダや、企業体ネットワークの論理的な管理サーバ、物理的なドメイン制御サーバなどとすることができる。ひとつのエッジネットワーク1N1、1N2、...、1N3それぞれに、ひとつまたはそれ以上のホスト群用として、ひとつまたはそれ以上のドメインTPを設けてもよい。ドメインTPは、そのサービス先のドメインで、秘密のマスター鍵を保持し、その対応の公開鍵PubKDomainTPsと公開パラメータPPsとを通知する。また、ネットワークサービスに登録しようとするホストのため、秘密鍵PKHostxを生成する責任を負う。図5に示されるように、ひとつのHNR2122が担当している領域で、ひとつまたはそれ以上のドメインTP6163が存在する。HNR2122それ自体も、ひとつのドメインTP6163で信頼づけられたひとつのドメインで、サービスを受ける。ひとつのドメインTP6163は、ひとつのHNRのみにサービスするか、複数のHNRにサービスするか、または、ひとつのHNRおよび多くの共用する装置にサービスするかである。HNR2122も、そのサービスエリアにある装置に対して、そのサービスするドメインTP6163の公開鍵およびPPsを通知する必要がある。ドメインTPがひとつのドメインにサービスを行いHNRが複数のドメインにサービスを行うという構造は、ドメインを信頼づけるための設定を融通性よいものにする。すなわち、ひとつのドメインのサイズとそのドメインの物理的または論理的な定義は、異なるオペレータによって多様に決定され得る。もうひとつの新規な装置DNRキーサーバDNRKS71は、図5に示すように、ドメイン名登録システムにおける、IBEIDベース暗号およびIBSIDベース署名の機能を持ったキーサーバである。このサーバ71は、マスター鍵を保持し、DNRシステムにおけるその対応する公開鍵PubKDNRKSおよびPPsを、HNRに、およびネットワークサービスに登録したホストに通知する。また、DNRシステム3SにおけるすべてのDNR31~36に対して秘密鍵PKDNRXも生成する。図5に示すように、ドメインTP61、62、...、63、HNR21、22、...、およびDNRKS71は信頼づけられたシステムの全体を形作る。ドメインTP61、62、...、63はひとつの信頼づけられたドメインを構築するためのものであり、HRN21、22、...は複数の信頼づけられたドメインに対してサービスを行うものであり、一方、DNRKS71はDNRシステム3Sの全体に信頼性を与えるものである。これらの3つの構成が、登録手順、解決手順、通信手順、およびローケータ更新手順に信頼性を与え、よってネットワーク構造は当然に認証がサポートされたものになる。実施形態のPTISFは、6つの主たる部分からなる。1.DNRシステムおよび信頼性あるドメインセキュリティの設定。2.信頼性ある登録。ここでは、HNR、ドメインTP、およびホストのセキュアな登録がなされる。3.信頼性のある解決および相互認証。セキュアなDNR名前解決、HNR名前解決、および2つのホスト間のグローバルな相互認証が説明される。4.信頼性あるローケータ更新。ここでは、CN対応ノードへのセキュアな更新の手順およびHNRへのセキュアな更新の手順が提供される。5.取り消し。ここでは、取り消されたホストのリストは、名前が解決されることや危険にさらされたホストへの接続を避けるため、維持される。6.キャッシング。ホストは、頻繁に接続するホストのID、公開鍵、およびパラメータをキャッシュする機能を持つ。これにより、素早い認証と名前解決ができる。以上の部分はそれぞれ、次に順に詳述する。1.DNRシステムおよび信頼性あるドメインセキュリティの設定DNRシステム3Sは、ドメイン名をHNRのIDおよびローケータとして解決する、階層的なDNR31~36からなる。例えば、図6aに示すDNRシステム3Sでは6つのDNR31~36がある。DNRシステム3Sが信頼性ある名前解決サービスを提供できるようにするため、DNRKS71が導入され、これらのDNR31~36に対してIDベース暗号技術に基づいて秘密鍵を生成する。このシステム3Sで、DNRKS71は、IBEおよびIBSのセキュリティ機能における、ひとつのマスター鍵とこれに対応するひとつの公開鍵を生成する。そして、公開鍵PubKDNRKSとPPsとをすべてのDNR31~36に通知する。新たにDNRが加えられたときには、IDベース暗号技術に基づいた、そのIDに対応する秘密鍵をこのDNRに対して生成して、PubKDNRKSおよびPPsを送る。基礎的な構成設定のあと、DNRシステム3Sでは、DNR31~36それぞれがPubKDNRKS、PPs、およびその秘密鍵を保持することになる。例えば、DNRXA31は、IDDNRXA、PubKDNRKS、PKDNRXAを保持する。通信者は、DNRXA31に送るメッセージを、IDDNRXAを用いて暗号化することができ、DNRXA31は、認証づけられた送信元であることを示すため、PKDNRXAを使ってメッセージに署名することができる。同様に、ドメインTP61、...は、秘密鍵の生成を行い、公開鍵の通知をルータ、ゲートウエイ、およびホストに対して行うことの責任を有している。図6bにおける基礎的な構成設定のあと、ゲートウエイ41はPubKdomainTP、PKGWを持ち、ルータ91R1は、PubKdomainTP、PKR1を持ち、アクセスポイント81AP1は、PubKDomainTP、PKAP1を持ち、ホスト11Xは、PubKDomainTP、PKHostXを持つことになる。ルータ92R2、93R3、...についても同様である。また、HNR21は、信頼性のあるひとつのドメインに属している必要があるため、その識別子IDHNRに対応する秘密鍵PKHNRをこのドメインTP61から獲得することになる。さらに、ドメインTP61は、それ自体の情報をこのHNR21に登録する必要がある。ドメインTP61は、このHNR21に対してだけサービスを行うか、複数のHNRに対してサービスを行うか、または、GW、ルータ、およびホストを含む多数の装置を伴ったひとつのHNRに対してサービスを行うかである。2.信頼性のある登録基本的なセキュリティの構成設定のあと、HNR、ドメインTP、およびホストは、検索できるように登録される必要がある。登録されるとき、登録に関わる装置は、すでに述べた成りすまし攻撃を避けるため、互いに認証を行う必要がある。すなわち、ひとつのHNRがDNRXYに登録するとき、DNRXYのIDを確認する必要があり、DNRXYは、このHNRの正しい構成設定を確認する必要がある。同様な要求は、ドメインTPやホストの登録手順でも生じる。図7は、HNR登録手順を示す。ひとつのHNRがDNRシステムに登録しようとするとき、そのHNRは、DNRサービスセンターのような信頼のある場所からPubKDNRKSおよびDNRKSのPPSを獲得することができる。図7に示すように、HNRAは、どのDNRが自身のためサービスを行っているかわからないので、HNRAは、DNRシステムに登録の要求を送る。DNRシステムは、DNRXYがHNRAを記録することになるとの決定を行い、そしてDNRXYがHNRAにコンタクトを行ってその識別子IDDNRXYをHNRAに告げ、登録できるようにする。ここで、成りすまし攻撃およびMIMAを避けるため、IBS署名がメッセージに添えられる。そして、ランダム数Nlが認証のため使われ、タイムスタンプTM1が繰り返し攻撃を避けるため使われる。HNRAは、この情報を受けたあと、このIBS署名SigIDDNRXYの正当性をIDDNRXYおよびPubKDNRKSを使って確かめることができる。この点検に合格することで、HNRAは、通信者が真にDNRXYであることを確信できる。そして、HNRAは、IDDNRXYで暗号化された{ドメイン名、HNRのIDおよびローケータ、PubKDomainTPHNRA、PPSHNRA、N1}と、N2、TM2とを含み、かつ署名SigHNRAを伴った情報を送ることができる。DNRXYがこの情報を受けると、最初にIBE復号機能でそのメッセージを復号し、PubKDomainTPHNRを得る。そして、この情報が、もし存在するならすでに登録された情報に一致していないかを点検し、さらに、IBS確認によりSigHNRAの正当性を検証する。すべての点検に合格すると、HNRAのすべての情報を登録する。最後に、承認ACKをHNRAに返答する。セキュアなHNR登録手順においては、HNRおよび対応するDNRの相互認証が実行される。また、DNRはHNRから提供された情報の正当性を点検することができ、MIMAや繰り返し攻撃は回避される。ドメインがひとつのHNRでサービスを受ける場合には、そのドメインTPは、ドメインTP登録手順によりHNRに登録される必要があるが、それはHNRのDNRへの登録と同様である。ドメインTPが最初にHNRに対して登録の要求を行い、HNRがそのIDとともに返答を行い、そして、ドメインTPがHNRのIDで、ドメイン名、ドメインTPのIDおよびローケータ、PubKDomainTP、およびランダム数を暗号化し、この暗号化されたメッセージに署名を加える。HNRがこのメッセージを受けると、これを復号し、公開情報を獲得し、署名の正当性を検証する。さらに、ドメインTPの情報を、HNRの記録部に登録する。それから、HNRはPubKDNRKSおよびPPSDNRKSをドメインTPに送る。これらは、ホストの登録を行うとき、およびドメインTPおよびホストのためDNR解決をするとき、ドメインTPによって使われ得る。また、HNRに新たなドメインTPが登録される場合には、DNRが正しくホスト名を解決できるようにDNRにその新しいドメイン情報を登録する必要がある。この手順は、HNR登録と同様であるが、{新規なドメイン名、HNRのIDおよびローケータ、IDDomainTP、PubKDomainTP、PPSDomainTP}という異なる情報が登録される。ホストの登録手順には2つのフェーズがある。最初のフェーズ1は、図8に示されるように、ホストのIDに対応する秘密鍵をドメインTPから手に入れることである。次のフェーズ2は、図9に示すように、ホスト情報をHNRに登録し、その存在を通知することである。図8は、フェーズ1を示し、これによりホストAは、ドメインTPがサービスするドメインにおいてネットワークサービスを得ることができる。ホストAの持ち主がドメインTPからサービスを受ける最初は、サービスセンターからホームルータHRを得る必要がある。あるいは、ホストAの持ち主は、家にすでに設けられたHRを使うこともできる。図8に示すようにホームルータBが設けられた後、ホストAは、サービスセンターにあるホームルータBにあらかじめロードされているIDDomainTP、PubKDomainTP、およびPPSDomainTPをホームルータBから手に入れることができる。それからホストAは、キーサーバであるドメインTPのIDで暗号化された、IDHostA自装置のID、SK、Nl、およびTMl以上のものを含む暗号情報を送ることによってドメインTPにサービスを要求する。SKセッション鍵は、対称鍵であり、これは、ホストAとドメインTPとの間のセキュアな通信のため用いられる。ドメインTPは、この情報を受け取るとIBE機能を使ってそのメッセージを復号し、この要求を受け入れるか否かを決定する。決定がイエスであれば、ドメインTPは、IBEおよびIBSの鍵生成手順を用い、ホストAに向けて、IDHostAに対応する秘密鍵PKHostAを生成する。それからドメインTPは、セッション鍵SKで暗号化された{IDHost、PKHostA、PubKDNRKS、PPSDNRS、IDHNR、PubKHNR、PPSHNR、Nl、TM2}を、署名を添えて送る。PubKDNRKSは、ホストAがDNR解決を問い合わせたときに、ホストAとDNRサーバとを相互認証するため用いられる。一方、IDHNRおよびPubKHNRは、HNR登録のフェーズ2で用いられる。このメッセージをホストAが受け取ると、ホストAは、ドメインTPの署名を検証しかつセッション鍵による復号を行いその秘密鍵PKHostAを得、これをインストールする。最後に、ホストAは、IBS署名SigHostAが付されたIDHostA、N2、TM3を送る。このメッセージをドメインTPが受け取ると、ドメインTPは、SigHostAの正当性を検証することができ、これでホストAによりPKhostAが正しくインストールされたことを確信することができる。図9は、フェーズ2を示し、これによりホストAは、その秘密鍵のインストールを完結した後に、HNRに情報の登録ができる。ホストAはHNRの情報をドメインTPから得ているので、ホストAは、ホスト名、ホストのIDおよびローケータ、IDDomainTP、PubKDomainTP、PPSDomainTP、Ni、TMiを含む情報をHNRのIDで暗号化し、自装置署名SigHostAを加えてHNRに送る。HNRはIDDomainTPなどのドメインTP情報が正当であるかどうかを点検し、その後SigHostAの正当性を検証する。すべての点検が合格なら、HNRは、ドメインTPの情報を含むホストAの情報を記憶部に記憶する。記憶部の内容は、解決手順の間、通信者によって獲得され得、その後に相互認証のため用いられる。3.信頼性のある解決および相互認証あるホストが別のホストと通信しようとするとき、その通信者の名前をローケータとして解決することを、そのあるホストはネットワークに要求する必要がある。これは、いわゆる解決手順であり、すでに述べたように、DNR解決およびHNR解決という2つのフェーズを含む。そこで、信頼性のある解決がこの2つのフェーズにも導入される。すなわち、セキュアなDNR解決およびセキュアなHNR解決である。セキュアなDNR解決の手順が図10に示される。図10において、Host1DomainXが、DNRシステムに対して、Host2DomainY発信先装置のグローバルホスト名の解決要求を行う。ホスト1は、ランダム数およびタイムスタンプを伴った、その署名付きの要求メッセージをDNRシステムに送る。DNRシステムは、このメッセージを受け取ると、DNRzがこの要求に対処することを決定する。DNRzは、DNRシステムからドメインXのPubKDomainTPHNRXおよびPPSDomainTPHNRXを獲得する。これは、ドメインTP登録がなされたときにDNRシステムにPubKDomainTPHNRXが登録されているから可能である。そして、DNRzは、PubKDomainTPHNRXおよびIDHost1によってSigHost1の正当性を検証する。これらの点検に合格すると、DNRZは、ドメインYにサービスを行うHNRYの情報を探索、獲得し、これをIDHost1によって暗号化する。最後に、DNRZは、その署名をメッセージに加えてこれをホスト1に送る。ホスト1は、このパケットを受け取ると、SigDNRZの正当性を検証してメッセージを復号し、Host2DomainYのHNR情報を獲得する。対応するHNRの情報が得られたあとは、図11に示されるように、セキュアなHNR解決がなされる。セキュアなHNR解決手順においては、ホスト1は、IDHNRY、LocatorHNRY、PubKHNRY、およびPPSHNRYを前提として獲得している。ホスト1は、HNRYに対して、IDHNRYで暗号化され署名SigHost1が伴われているHost2DomainYを解決することをランダム数およびタイムスタンプを付して要求する。HNRYは、このパケットを受け取ると、ドメインXの公開鍵をローカルに探索し、SigHost1の正当性を検証する。検証が完結すると、HNRYは、ホスト1に対して、IDHost2、LocatorHost2、PubKHost2、およびPPSHost2を含むホスト2の情報を返信する。これらの情報は、IDHost1で暗号化され、SigHNRYが伴われている。ホスト1は、署名を検証し、暗号化情報を復号して最終的にホスト2の情報を獲得する。多くの場合、信頼性のある通信のためには、相互の認証が必要である。上記の解決手順では、発信元ホストは、発信先ホストのID、ローケータ、公開鍵、公開パラメータを得るが、これは、発信先ホストにとって発信元の確認になる。しかしながら、この手順では、発信先ホストは、発信元ホストのIDを確認することができない。これは、一方向の解決のみが行われるならば、発信先ホストが確認可能な発信元ホストの情報を持ち得ないからである。発信先ホストも、発信元ホストの情報を獲得できるように、他方向の解決手順を実行するようにする。これにより、発信先ホストは、PTISFで発信元ホストのID、ローケータ、公開鍵を獲得できる。そして、発信元ホストと発信先ホストとの相互認証が円滑になされ得る。その認証手順が図12に示される。相互認証を行うため、ホスト1は、ランダム数N1を生成し、これに図示するようなホスト1のグローバスホスト名などの情報を加え、さらにこれをIBE暗号化機能によりIDHost2で暗号化する。ホスト1は、この情報に署名を添えてホスト2に送る。ホスト2は、この情報を受け取ると、Host1DomainXを解決して、その公開鍵、IDHost1、PubKHost1を獲得し、さらにSigHost1を検証する。検証が完結すると、ホスト2は、IDHost1で暗号化されその署名が伴われた、対称なセッション鍵SKおよびランダム数N2を生成する。ホスト1は、SigHost2を検証しかつ復号してSK、N2を獲得する。そして、SKでN2が暗号化されてホスト2に送られることにより、これらの間に、セキュアな通信チャンネルの確立がなされる。4.信頼性のあるローケータ更新ホスト1がネットワークのある場所から異なる場所へ移動したとすると、ホスト1はその新しいローケータを、CN、ホスト2、および担当のHNRに対して更新する必要がある。図13におけるホスト2へのローケータ更新に関して、ホスト1は、その署名を添えて新たなローケータLocator2を送り出す。ホスト2は、このパケットを受け取ると、この署名の正当性を検証する。検証できたら、ホスト2は、古いホスト1のローケータLocator1を新たなローケータLocater2に置き換える。HNRへのローケータ更新を行う場合も同様の手順が実行される。HNRにとってホスト1の公開鍵は既知なので、HNRは容易にホスト1の正当性を確認できそのローケータを更新できる。5.取り消しあるホストの秘密鍵が危険にさらされたときには、取り消しの手順が必要である。これについては、2つの方法を採用し得る。ひとつは、ホストIDに期限切れ時間を加え、その時点を過ぎるとホストIDが自動的に無効になる。もうひとつは、HNRがそれぞれホストの取り消しリストを保持し、HNRは、そのサービスエリアでサービスを受けていた、取り消されたホストのリストだけを保持する。この取り消しリストでは、取り消されたホスト名とIDとがすべて蓄積される。そして、解決手順においては、DNR解決が成功したとしても、HNRは要求された発信先ホストが取り消しリストにあるか否かを点検する。そして、発信先ホストの最新IDを確認する。取り消しリストにある場合または最新ID期限切れの場合には、エラーメッセージが発信元ホストに返される。それ以外は、通常のHNR解決が実行される。6.キャッシング相互認証の動作を改善するため、各ホストは、担当のHNRのIDおよびローケータ、公開鍵、およびある程度頻繁に通信するホストのパラメータをキャッシュするメモリを保持する。あるホストが別のホストと通信を開始しようとするとき、そのメモリにそれらの情報が存在しているかを点検する。もし存在して発信先ホストにも発信元ホストの情報がキャッシュされているときには、相互解決なしに、キャッシュ情報を直接に利用してHNR解決および相互認証を行う。実施形態の効果本実施形態によれば、以下の効果が得られる。1.ホストおよびHNRは、信頼性高くそれらの情報をネットワークシステムに登録できる。これは、HNRとDNRとの間またはホストとHNRとの間の相互認証が可能であるからであり、MIMAや繰り返し攻撃も避けることができる。2.発信元ホストは、信頼性高く、発信先ホストの名前をそのID/ローケータおよび対応する公開鍵として解決できる。これは、発信元ホストとDNRとの間の相互認証、および発信元ホストと発信先ホストのHNRとの相互認証がなされるためである。また、発信元ホストは、発信先ノードの真のIDを認証することもできる。3.ホスト間の相互認証がなされ得る。相互の名前解決手順のあと、2つのホストは、通信者のIDおよびそのドメインTPの公開鍵を得ることができる。それにより、通信開始前に相互の認証が円滑に行われる。4.IDおよびローケータのつながりを信頼性高く更新できる。これは、CNおよび対応するHNRが、更新を必要とするホストのIDと公開鍵を知っているからである。それで、CNおよび対応のHNRは、受け取った更新パケットの正当性を容易に確認できる。"