JP5807912B2

JP5807912B2 - ホスト装置

Info

Publication number: JP5807912B2
Application number: JP2011271116A
Authority: JP
Inventors: 睿棟李; カフレベド; 洋明原井
Original assignee: National Institute of Information and Communications Technology
Current assignee: National Institute of Information and Communications Technology
Priority date: 2011-12-12
Filing date: 2011-12-12
Publication date: 2015-11-10
Anticipated expiration: 2031-12-12
Also published as: JP2013123156A

Description

本発明は、例えばＩＰアドレスおよびローケータのような関連必要情報を持ち得るホスト装置に関する。

現在、ホスト装置などが関与する認証の主要な方法は、３つに分類される。対称鍵ベース認証、公開鍵ベース認証、自己証明可アドレス認証である。

典型的な対称鍵ベース認証のプロトコルは、ＲＡＤＩＵＳ（非特許文献１）、Ｄｉａｍｅｔｅｒ（非特許文献２）、ＯｐｅｎＩＤ（非特許文献３）、Ｋｅｒｂｅｒｏｓ（非特許文献４）である。これらのシステムでは、あらかじめ与えられた対称鍵が必要であり、その多くは、登録ユーザのＩＤ認証のために用いられている。これらのシステムは、中心となるサーバを用いるので全世界で通用させるには適さず、規模が限られてしまう。よって、高信頼性のＮＭＳ（Name Mapping System）で用いられるのは適当でない。

現在の典型的な公開鍵ベース認証のプロトコルは、Ｘ．５０９（非特許文献５）、ＰＧＰ（Pretty Good Privacy：非特許文献７）である。Ｘ．５０９システムでは、２つの装置間の認証で認証チェーンを確立するため、階層化された証明機関（ＣＡ）が用いられる。加え合わせられてグローバル化されたＣＡには、通信者の公開鍵の正当性を確認するためアクセスがなされる。これは、やはり名前解決システムで使用することの制限になる。また、その名称づけ枠組みの標準も、インターネット社会で受け入れられることを制限する。現在のインターネットは、インターネット名を用いる同様の別の解決方法が、ドメイン名システム（ＤＮＳ：非特許文献９）に対して提供されている。いわゆるＤＮＳＳＥＣ（非特許文献６）である。

ＤＮＳＳＥＣは、ＤＮＳのため、データ元の認証およびデータの正当性を提供する。ＤＮＳＳＥＣは、承認された領域という概念を採り入れた。それは、ＤＮＳ公開鍵（ＤＮＳＫＥＹ）と、情報資源の記録の署名（ＲＲＳＩＧ）と、次の保証（ＮＳＥＣ）と、随意的に代理の署名者（ＤＳ）記録というような情報資源記録を利用する。ＤＳ記録は、ＤＮＳの領域間での認証チェーンを確立する。すなわち、ＤＮＳＳＥＣは、情報資源記録を署名するときに使っている領域の公開鍵を確認するため、証明チェーンも用いる。ＤＮＳＳＥＣでの証明機関（ＣＡ）の構造は、階層化されたＣＡ構造が採用されているＸ．５０９公開鍵の基礎構造と類似する。ＤＮＳＳＥＣに基づいた公開鍵の基礎構造は、解決の結果がひとつの特定名称のサーバから実際に発せられたということを証明するために用いられるに過ぎないため、次の問題がある。
１．ＤＮＳＳＥＣは、ＤＮＳでの名前解決を要求する者のＩＤを認証する認証手順の枠組みを何ら有していない。
２．ＤＮＳＳＥＣは、２つの装置間での相互認証を提供できない。
３．ＤＮＳＳＥＣは、信頼関係を確立するため、信頼のチェーンを採用する。そのため、良好に構成された階層の証明機関（ＣＡ）構造を要し、これにより公開鍵の信頼性を向上する。これは、融通性に欠ける。
４．公開鍵の基礎構造への追加アクセスが、認証手順で必要である。これは、ホストそれぞれが、名前解決を求めるほぼそのたびに、この基礎構造から公的な証明を求める必要があることを意味し、コスト高である。

次に、ＮＭＳとして、ＬＩＳＰ＋ＡＬＴの基本仕様が非特許文献１０で提供されている。その保護方法は、主に、ｓＢＧＰ（非特許文献１１）であるか、ｓｏＢＧＰ（非特許文献１２）である。これらも構造化されたＣＡを使っていて、これにより、分配されるルーティング情報の信頼性の高い登録を提供する。同様に、ＡＬＴサブシステムでの情報交換に対する保護を図るため、付加的な公開鍵の基本構造へのアクセスが必要である。

以上より、上記のように構成されたＸ．５０９のＣＡシステム、ＤＮＳＳＥＣ、ＬＩＳＰ＋ＡＬＴは、すべて、ＮＭＳ上のセキュリティ要求を達成するには大きな限界を有していることは明らかである。すなわち、信頼性のある第三者の介在を必要とし、シンプルにも機能しない。

一方、ＰＧＰシステムの認証は、既知の友人からの推薦に基づいたものであり、ＩＤ確認の正しさを完全には保証できない。よって、ＮＭＳでの使用には受け入れられない。

上記のセキュリティ対応は、すべて、ネットワーク構造にアドオンさせるものである。近年、ＩＰｖ６を採用するとき近くで認証するために自己証明可アドレスが設計された。この方法も公開鍵ベースと言えるが、当然ながら公開鍵をそのアドレスにつないでそのアドレスが自己証明可となるようにする。そのプロトコルは、いわゆる暗号化技術で生成されたアドレス（ＣＧＡ；非特許文献８）である。ＣＧＡの基本的な考えは、公開鍵の暗号化ハッシュを計算で得て、ＩＰｖ６のアドレスからインターフェースＩＤ（例えば、ＩＰｖ６の右側６４ビット）を生成することである。得られるＩＰｖ６アドレスは、暗号化技術で生成されたアドレスと呼ばれる。ＣＧＡは、隣接での認証のため設計され、隣接のホストを認証する。ＮＭＳが全世界的な名前解決システムであるため、これでは規模の上で制限になる。

国際公開第２０１１／０８８６５８号パンフレット

C.Rigney, S.Willens, A.Rubens, W.simpson, "Remote Authentication Dial In User service (RADIUS)", RFC 2865. P.Calhoun, J.Loughney, E.Guttman, G.Zorn, J.Arkko, "Diameter Base Protocol", RFC 3588. OpenID, http://openid.net/ C.Neuman, T.Yu, S. Hartman, and K.Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120. R.Housley, W.Ford, W.Polk, and D.Solo, "Internet X.509 Public Key Infrastructure-Certificate and Profile", RFC 2459. R.Arends, R.Austein, M.Larson, D.Massey, and S.Rose, "DNS Security Introduction and Requirements", RFC 4033, Mar. 2005. J.Callas, L.Donnerhache, H.Finney, D.Shaw, and R. Thayer, "OpenPGP Message Format", RFC 4880. T.Aura, "Cryptographically Generated Addresses (CGA)", RFC 3972, Mar. 2005. P.Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, Nov. 1987. D.Farinacci, V.Fuller, D,Meyer, and D.Lewis, "LISP Alternative Topology (LISP+ALT)", draft-fuller-lisp-alt-05.txt, Feb. 24, 2009. S.Murphy, "BGP security Analysis", draft-murphy-bgp-sccr-04 (work in progress), November 2001. R.White, "Architecture and Deployment Considerations for Secure Origin BGP (soBGT)", draft-white-sobgparchitecture-00 (work in progress), May 2004.

本発明は、例えばＩＰアドレスおよびローケータのような関連必要情報を持ち得るホスト装置において、自己保護性を向上することができるホスト装置を提供することを目的とする。

上記の課題を解決するため、本発明の一態様であるホスト装置は、キーサーバが有するＩＤである第１のＩＤに基づき、自装置の名前とセッション鍵とを少なくとも含む第１の情報を暗号化して第１の暗号情報を生成する手段と、前記第１の暗号情報を前記キーサーバに送出する手段と、前記第１の暗号情報を前記キーサーバが復号して得た前記名前に対応して前記キーサーバが前記自装置向けに生成したＩＤである第２のＩＤと、該第２のＩＤに対応して前記キーサーバが生成した秘密鍵とを少なくとも含む第２の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第２の暗号情報とされてかつ前記キーサーバの署名である第１のサーバ署名が付されて前記キーサーバから送られてきたときに、該第２の暗号情報および該第１のサーバ署名を受け取る手段と、前記第１のサーバ署名の正当性を検証する手段と、前記第２の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、ホストに関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに対して、前記自装置の登録を要求する旨の情報を前記第２のＩＤを付して送出する手段と、前記登録サーバのＩＤである第３のＩＤを少なくとも含む第３の情報が、前記登録サーバの署名である第２のサーバ署名が付されて前記登録サーバから送られてきたときに、該第３の情報および該第２のサーバ署名を受け取る手段と、前記第２のサーバ署名の正当性を検証する手段と、前記第３のＩＤに基づき、前記自装置の前記名前を少なくとも含む第４の情報を暗号化して第３の暗号情報を生成し、かつ前記秘密鍵に基づき、自装置署名を生成する手段と、前記第３の暗号情報および前記自装置署名を前記登録サーバに送出する手段とを具備する。

また、参考態様であるホスト装置は、通信をしようとする発信先装置が有する名前の解決を要求する旨の情報を少なくとも含む第１の情報に自装置署名を付して、該第１の情報および該自装置署名を、前記発信先装置に関する情報である第２の情報を登録するための登録サーバを含んで構造化されたシステムに対して、該システムが前記登録サーバを見つけられるように送出する手段と、前記第２の情報が、自装置のＩＤに基づく暗号化で暗号情報とされてかつ前記登録サーバの署名であるサーバ署名が付されて前記登録サーバから送られてきたときに、該暗号情報および該サーバ署名を受け取る手段と、前記サーバ署名の正当性を検証する手段と、前記暗号情報から、前記第２の情報を復号して得る手段とを具備する。

また、別の参考態様であるホスト装置は、通信をしようとする発信先装置が有する名前の解決を要求する旨の情報を少なくとも含む第１の情報に自装置署名を付して、前記発信先装置に関する情報である第２の情報を登録するための登録サーバを含んで階層化されたシステムに送出する手段と、前記システムにおいて前記登録サーバの階層上位に位置するサーバたる第１の上位サーバに関する情報である第３の情報が、自装置のＩＤである第１のＩＤに基づく暗号化で第１の暗号情報とされてかつ前記第１の上位サーバのさらに階層上位に位置する第２の上位サーバの署名である第１のサーバ署名が付されて該第２の上位サーバから送られてきたときに、該第１の暗号情報および該第１のサーバ署名を受け取る手段と、前記第１のサーバ署名の正当性を検証する手段と、前記第１の暗号情報から、前記第３の情報を復号して得る手段と、前記第１の情報に自装置署名を付して、前記第１の上位サーバに送出する手段と、前記登録サーバに関する情報である第４の情報が、前記第１のＩＤに基づく暗号化で第２の暗号情報とされてかつ前記第１の上位サーバの署名である第２のサーバ署名が付されて該第１の上位サーバから送られてきたときに、該第２の暗号情報および該第２のサーバ署名を受け取る手段と、前記第２のサーバ署名の正当性を検証する手段と、前記第２の暗号情報から、前記第４の情報を復号して得る手段と、前記第１の情報に自装置署名を付して、前記登録サーバに送出する手段と、前記第２の情報が、前記第１のＩＤに基づく暗号化で第３の暗号情報とされてかつ前記登録サーバの署名である第３のサーバ署名が付されて前記登録サーバから送られてきたときに、該第３の暗号情報および該第３のサーバ署名を受け取る手段と、前記第３のサーバ署名の正当性を検証する手段と、前記第３の暗号情報から、前記第２の情報を復号して得る手段とを具備する。

また、さらに別の参考態様であるホスト装置は、自装置の名前である第１の名前の情報が含まれたＩＤと、通信しようとする発信先装置の名前である第２の名前とを少なくとも含む第１の情報に自装置署名を付して、前記発信先装置に送出する手段と、前記発信先装置が生成したセッション鍵およびランダム数を少なくとも含む第２の情報が、前記発信先装置が名前解決システムに前記第１の名前を適用して前記自装置の公開鍵および公開パラメータが前記発信先装置によって獲得されたあとに、前記ＩＤに基づく暗号化で第１の暗号情報とされてかつ前記発信先装置の署名である装置署名が付されて前記発信先装置から送られてきたときに、該第１の暗号情報および該装置署名を受け取る手段と、前記装置署名の正当性を検証する手段と、前記第１の暗号情報から、前記セッション鍵および前記ランダム数を復号して得る手段と、前記セッション鍵に基づき、前記ランダム数を暗号化して第２の暗号情報を生成する手段と、前記第２の暗号情報を前記発信先装置に送出する手段とを具備する。

また、さらに別の参考態様であるホスト装置は、自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置に関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに送出する手段とを具備する。

本発明によれば、例えばＩＰアドレスおよびローケータのような関連必要情報を持ち得るホスト装置において、自己保護性を向上することができる。

以下での記載にかかわらず、図１２から図１９の図示およびそれらを参照する説明自体は発明の実施形態に関するものでなく、参考態様としての図示および説明である。ただし、発明の実施形態として参照されるべき内容を含んではいる。
ホスト装置の位置づけを含めた、専用のＮＭＳを備えた一般的なネットワーク構造を示す説明図。ＤＮＳを用いてホスト装置が行う登録および名前解決（再帰方式の場合）の手順を示す説明図。ＤＮＳを用いてホスト装置が行う登録および名前解決（反復方式の場合）の手順を示す説明図。ＬＩＳＰ＋ＡＬＴを用いてホスト装置が行う名前解決の手順を示す説明図。ＩＤベース暗号（ＩＢＥ）の基本的な仕組みを説明するブロック図。ＩＤベース署名（ＩＢＳ）の基本的な仕組みを説明するブロック図。実施形態であるホスト装置が組み込まれ得る、信頼性の向上された一般的なネットワーク構造を示す説明図。信頼性の向上されたネットワークにおけるＮＭＳサブシステムの構造を示す説明図（図８（ａ））および同ネットワークにおけるエッジドメイン（ＥＤ）の構造を示す説明図（図８（ｂ））。信頼性の向上されたネットワークにおける、実施形態であるホスト装置のＮＭＳサブシステムへの登録手順を時系列に示す説明図。図９の続図であって、信頼性の向上されたネットワークにおける、実施形態であるホスト装置のＮＭＳサブシステムへの登録手順を時系列に示す説明図。図１０に登場のＮＭＳサブシステムＳＳi内のＮＭＳ装置間での情報交換手順を時系列に示す説明図。信頼性の向上されたネットワークにおける、実施形態であるホスト装置がひとつのサブシステムを用い名前解決（再帰方式の場合）を行うときの手順を時系列に示す説明図。信頼性の向上されたネットワークにおける、実施形態であるホスト装置がひとつのサブシステムを用い名前解決（反復方式の場合）を行うときの手順を時系列に示す説明図。図１３の続図であって、信頼性の向上されたネットワークにおける、実施形態であるホスト装置がひとつのサブシステムを用い名前解決（反復方式の場合）を行うときの手順を時系列に示す説明図。図１２と、図１３および図１４とをまとめて簡潔に描いた説明図。信頼性の向上されたネットワークにおける、実施形態であるホスト装置が前段に位置するサブシステムを用いて名前解決を行うときの手順を時系列に示す説明図。図１６に示した手順に続いて行われる、信頼性の向上されたネットワークにおける、実施形態であるホスト装置が最終に位置するサブシステムを用いて名前解決を行うときの手順を時系列に示す説明図。信頼性の向上されたネットワークにおける、実施形態であるホスト装置が発信先ホスト装置との相互認証を行うときの手順を時系列に示す説明図。信頼性の向上されたネットワークにおける、実施形態であるホスト装置が移動した場合に行われる、発信先ホスト装置へのローケータ更新の手順を時系列に示す説明図。

以上を踏まえ、以下では本発明の実施形態を適宜、図面を参照しながら説明する。

（説明の準備事項、ＮＭＳ）
専用のＮＭＳを備えた一般的なネットワーク構造が図１に示される。図１に示すように、ネットワーク構造は、通常、データプレーンと制御プレーンとからなる。データ転送に用いられるデータプレーンは、エッジドメイン（ＥＤ）１Ｎ１、１Ｎ２、…、１Ｎ３とグローバルな情報転送ネットワーク（ＧＴＮ）２００とからなる。エッジドメイン１Ｎ１、１Ｎ２、…、１Ｎ３は、エンドホストであるホスト１１、１２に、ネットワークアクセスおよびドメイン内情報転送の便宜を提供する。エッジドメイン１Ｎ１等には、基地局８１やルータ９１が含まれる場合がある。一方、情報転送ネットワーク２００は、サービスプロバイダの基幹ネットワークの集合であり、ドメイン間情報転送のため用いられる。情報転送ネットワーク２００には、通常、ゲートウエイ４１〜４９が設けられる。

制御プレーンであるＮＭＳ１００は、図１のネットワークでのホスト名をホストローケータおよびその他のＲＮＩ（Related Necessary Information）にマッピングするように設計されている。ホスト名は、ホストに割り当てられたユニークな名称であり、ホストローケータは、ホストがネットワークに接続するための接続（アタッチ）ポイントである。

名前付けの方法は、階層構造の名前付けと平坦構造の名前付けという２つのカテゴリに分類することができる。この両者は、状況により利点および弱点を有する。インターネットや、ＬＩＳＰのような考え得る将来の構造では、階層構造の名前付けが採用される。一方、重層技術（オーバーレイ・テクノロジー）に関連するほかの構造は、平坦構造の名前付けが採用される。

ＮＭＳ１００は、一般にＮＭＳサブシステムを複数有し、例えば図１に示すように、ひとつのＮＭＳサブシステム１００ＡたるＮＭＳＳＳ1と、別のＮＭＳサブシステム１００ＢたるＮＭＳＳＳkからなる。異なるＮＭＳサブシステムは、ＮＭＳ全体において異なる役割を有しており、それらは名前解決のためチェーンとなってはたらく。通常、最初のサブシステムが、ホスト名を入力としてそのＲＮＩを提供し、中間のサブシステムが、前のサブシステムが提供したＲＮＩを入力としてそのさらなるＲＮＩを提供し、最後のサブシステムが、ホストローケータおよび別のさらなるＲＮＩを提供する。これらのサブシステムの相互は、場合により接続されまたは切り離される。ひとつのＮＭＳサブシステムは、名前登録、解決に供されるひとつ以上のＮＭＳ装置（ＮＭＳＥ）を有し、それらは、階層構造かあるいは平坦構造で構成されている。図１では、ＮＭＳＳＳ1のＮＭＳ装置３１ｈ〜３６ｈは、階層構造であり、ＮＭＳＳＳkのＮＭＳ装置３１ｆ〜３５ｆは、平坦構造である。ＮＭＳＥは、ホスト名とこのホストのＲＮＩとの対応（マッピング）を記憶している。ＲＮＩには、例として、ＩＤ、ローケータ、公開鍵、公開パラメータ、ＩＰアドレス、終点識別子（Endpoint Identifier）などが挙げられる。ホスト名、公開鍵、および公開パラメータは、以下説明する実施形態において、ＮＭＳＥに蓄えられる基本的な情報として位置づけられる。ローケータおよびＲＮＩを得るため、ホスト名は、ひとつのサブシステムあるいは複数のサブシステムで１回以上の解決手順に付される。

ＮＭＳサブシステムの根本的な機能は、名前解決の問合せに返答することである。共通事項として、ひとつのサブシステムにおいて名前をＲＮＩとして解決することに関し、再帰モードと反復モードというふたつの名前解決モードが存在する。一方、異なるサブシステム間での関係は、必ず反復モードである。ひとつのサブシステムにおいて、再帰モードでは、ＮＭＳＥは、このサブシステム内で直接的に、再帰的手法でたどり着いた対応のＮＭＳＥに対して名前解決要求を出す。これに対して、対応のＮＭＳＥは、要求者または代理の要求者に対して目的のホストのＲＮＩを返答する。以下では、簡単のため、「要求者」という場合には、最初の要求者および代理の要求者の両者を含むものとする。ひとつのサブシステムにおいて、反復モードでは、ＮＭＳＥが次に対応のＮＭＳＥのローケータを要求者に返答することを複数回反復し、最後に対応のＮＭＳＥが目的のホストのＲＮＩを要求者に返答する。ＮＭＳにひとつしかサブシステムがない場合は、得られたＲＮＩが、ＤＮＳでのＩＰアドレスのごとき最終的に要求されたＲＮＩになる。ＮＭＳが複数のサブシステムを含む場合には、さらに続けて名前解決の手順がなされる必要がある。このような連続する名前解決は、異なるサブシステム間における反復モードとして実行される。すなわち、前のサブシステムから得られた名前解決結果が要求者に返答され、これに基づいて要求者は新たな要求を新たなサブシステムに対して開始する。そして最後に、目的のホストのＲＮＩが、最後のサブシステムによる解決結果として得られる。

ここで、上記説明のＮＭＳを一般的なネットワーク構造で説明するため、ＤＮＳ、および、ＬＩＳＰ＋ＡＬＴについてそれぞれ説明する。これらは典型的なＮＭＳである。

（ＤＮＳ）
ＤＮＳは、インターネットの核となる機能であり、ホスト名をＩＰアドレスに対応づけるものである。ＤＮＳではＤＮＳサーバ（ＤＮＳＳ）が用いられ、これは、ＤＮＳにおける名前サーバを意味するＮＭＳＥ相当のものである。ＤＮＳはシステムとしてひとつなので、このＮＭＳにほかのサブシステムは存在しない。ＤＮＳは、例えばtokyo-u.ac.jpのように階層構造の名前付けを採用している。ＤＮＳにおけるＤＮＳＳは、ツリー構造として階層的に構成される。そのデータベースは、ゾーンと呼ばれるセクションに分割されており、ＤＮＳＳ間で分配される。ＤＮＳＳのそれぞれは、ＤＮＳの名前空間内の隣接する領域であるゾーンについて責任を有している。すなわち、ＤＮＳＳは、そのサブツリーの一部について機能する。ＤＮＳＳは、そのゾーン内のホストについての問合せに対して返答する。

ＤＮＳは、再帰モードと反復モードとを両者ともサポートする。再帰モードでは、ＤＮＳＳが再帰動作して、たどり着いた対応のＤＮＳＳに対して直接に名前解決要求を出す。これに対して、対応のＤＮＳＳは、目的のホストのＩＰアドレスを要求者に返答する。反復モードでは、ＤＮＳＳが次に対応のＤＮＳＳのＩＰアドレスを要求者に返答することを複数回反復し、最後に、その対応のＤＮＳＳが目的のホストのＩＰアドレスを要求者に返答する。ＩＰアドレスはほかでもなくホストから要求された情報であり、よってさらなる名前解決（以下では、「名前解決」を単に「解決」と言う場合がある）のための別のサブシステムは必要ない。

ＤＮＳの再帰モードにおけるホスト名の登録解決のステップが、一例として、図２に示される。図２において、図１中に示したものと同一または同一相当のものには同一符号を付してある。図２では、ＮＭＳＥ３１ｈ〜３７ｈに相当して、ＤＮＳサーバ３１〜３７が設けられる。登録ステップであるステップ１では、ホスト名とそのＩＰアドレスとをＤＮＳ１１０に登録する。対応のＤＮＳサーバ（ＤＮＳＳ）３７であるＤＮＳＳZ.A.Xは、図２中に示したホスト１１Ｐの名前であるＨｏｓｔ２．Ｚ．Ａ．ＸをそのＩＰアドレス情報と対応づけて記憶する。名前解決の手順では、まず、解決の問合せがローカルＤＮＳサーバ（ＬＤＮＳＳ）３０Ｌに送られる。次に、ローカルＤＮＳサーバ３０Ｌが問合せを基底（ルート）サーバＤＮＳＳ0（ＤＮＳサーバ３１）に送る。サーバが回答を示せないならば、その問合せを「最も近い既知の」信頼すべきＤＮＳＳに送る。最後に、その対応のＤＮＳＳ（ＤＮＳサーバ３７）がホスト名に対応するホストのＩＰアドレスをローカルＤＮＳサーバ３０Ｌに返答し、ローカルＤＮＳサーバ３０Ｌはその解決結果を要求ホストに転送する。図２に示すように、名前解決の手順は、ステップ２．１から２．７である。

一方、ＤＮＳでの反復モードによる名前解決が、一例として、図３に示される。図３において、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。名前解決の手順は、ステップ２．１から２．１０である。まず、Ｈｏｓｔ１．Ｋ．Ｃ．Ｙのホスト１２が解決の問合せを、ＤＮＳ１２０内のローカルＤＮＳサーバ３０Ｌに送り、ローカルＤＮＳサーバ３０Ｌはその問合せを基底サーバ（ＤＮＳサーバ３１）に送る。反復の問合せでは、ＤＮＳＳは毎回、ＤＮＳＳが複数記載されたリストをローカルＤＮＳサーバ３０Ｌに返答する可能性がある。その場合には、ローカルＤＮＳサーバ３０Ｌは、次のＤＮＳＳとしてその中からひとつ選択し次の問合せを送る。簡単のため、図示では、次のＤＮＳＳとして単一のＩＰアドレスが特定されていることとしている。この反復モードの手順では、中間のＤＮＳＳは、次のＤＮＳＳのＩＰアドレスを返答し、ローカルＤＮＳサーバ３０Ｌは、それに応じて問合せを反復する。最後に、ローカルＤＮＳサーバ３０Ｌは、目的のホストのＩＰアドレスを得、この結果を要求者（ホスト１２）に提供する。

なお、ホストは、その名前を維持する一方で接続を変更するときに、そのＩＰアドレスの更新を要する場合がある。このような場合は、対応ホスト（ＣＨ）への更新とＤＮＳへの更新というふたつの手順が必要である。ＣＨ更新のためには、更新要求がＣＨに送られ、ＣＨはそのアドレスを更新しこの要求を了知する。ＤＮＳ更新のためには、更新要求が対応のＤＮＳＳに送られ、ＤＮＳＳはアドレスを更新しこの要求を了知する。

（ＬＩＳＰ＋ＡＬＴ）
ＬＩＳＰ＋ＡＬＴは、もうひとつの典型的なＮＭＳの例である。ＬＩＳＰ＋ＡＬＴでは、ホストＩＤとして終点識別子（Endpoint Identifier：ＥＩＤ）を用いる一方、ローケータとしてルーティングローケータ（ＲＬＯＣ）を用いる。ＥＩＤおよびＲＬＯＣは、階層構造の名前付けをその方法として使用する。このＮＭＳは、インターネットのような機能を有するＤＮＳとオルタナティブ・トポロジー（ＡＬＴ）というふたつのサブシステムを有する。ＤＮＳサブシステムがホスト名をホストＥＩＤとして解決し、一方ＡＬＴサブシステムがホストＥＩＤをホストＲＬＯＣとして解決する。ＤＮＳサブシステムにおけるＮＭＳＥは階層構造を有し、一方ＡＬＴサブシステムにおけるＮＭＳＥは平坦構造を有する。

ＤＮＳサブシステムは、再帰モードと反復モードの両者をサポートする。一方、ＡＬＴサブシステムにおいては、ＬＩＳＰがＢＧＰ（ボーダー・ゲートウエイ・プロトコル）を使用してＥＩＤプリフィックスの更新情報を送り、そのＥＩＤプリフィックスのＥＩＤからＲＬＯＣへの対応を保持しているＥＴＲ（エグレス・トンネル・ルータ）に要求が転送されるように動作が生じる。つまり、ＡＬＴサブシステムは、再帰モードだけをサポートする。ＤＮＳのシステムによる解決のあと、目的のホストＥＩＤを含む中間のＲＮＩが要求者によって取得される。そして、代理の要求者であるＩＴＲ（イングレス・トンネル・ルータ）は、このＥＩＤを用い、名前解決の要求をＡＬＴサブシステムに送る。中間のＮＭＳＥであるＡＬＴサーバは、ＥＴＲに達するまで再帰的にこの要求を転送する。ＥＴＲは、ホストにとって最終的な要求ＲＮＩである、対応するＲＬＯＣを要求元のＩＴＲに返答する。ふたつのサブシステムが異なる要求者を有する点は、注目すべきである。ＤＮＳサブシステムでは要求者はホスト自体であり、一方ＡＬＴサブシステムでは代理の要求者ＩＴＲが存在する。

ＬＩＳＰ＋ＡＬＴにおけるふたつのサブシステムでの反復解決手順が、一例として、図４に示される。図４において、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。ＤＮＳサブシステム１３０での対応解決手順はステップ１．１から１．５を含む。Ｈｏｓｔ１．Ｋ．Ｃ．Ｙのホスト１２が解決要求をローカルＤＮＳサーバ３０Ｌを介してＤＮＳサブシステム１３０に送り、ＤＮＳサブシステム１３０は再帰のまたは反復の手順を遂行しローカルＤＮＳサーバ３０Ｌを介してＨｏｓｔ１．Ｋ．Ｃ．ＹにＥＩＤHost2を返答する。それから、反復的にＩＴＲ２１がＡＬＴサブシステム１４０での対応解決手順ステップ２．１から２．３を実行する。ＩＴＲ２１はＡＬＴサブシステム１４０に、最初の対応解決手順で得ているＥＩＤを伴う要求を行い、これにより、ＡＬＴサブシステム１４０は再帰的解決を行って、ＩＴＲ２１に対してホスト１１ＰのＲＬＯＣであるＲＬＯＣHost2を返答する。符号２２は、既述したＥＴＲである。

（脅威）
上記記載の各ＮＭＳは、種々の攻撃下で脆弱性を有する。このような脅威は、以下のような５つの手順において生じる可能性がある。すなわち、１）ひとつのホストがその名前とＲＮＩとを登録するとき、２）ＮＭＳＥが登録情報を交換するとき、３）ひとつのホストがほかのホストの名前解決を要求するとき、４）ひとつのホストがほかのホストと通信を行うとき、５）ひとつのホストがその情報を更新するとき、である。これらの５つの手順において攻撃者は、成りすまし攻撃、中間介入攻撃（ＭＩＭＡ）、または繰り返し攻撃を仕掛ける可能性がある。

成りすまし攻撃は、上記の各手順において異なる形式を持ち得る。登録の手順では、攻撃者は、正規のホストを騙り、成りすましでホスト名やＲＮＩを登録する可能性があり、あるいは、正規のＮＭＳＥに対して、真の身分を隠してホストのための登録を行う可能性がある。情報交換の手順では、攻撃者は、真の身分を隠して正規のＮＭＳＥに対して偽の情報をほかのＮＭＳＥに提供するよう仕向け、ＮＭＳを誤動作させる可能性がある。名前解決の手順では、攻撃者は、正規のＮＭＳＥを騙り、ホストに偽の情報を提供して、ＤｏＳ攻撃やサイトの乗っ取りを行う可能性がある。また、攻撃者は、正規のホストを騙り、ＮＭＳから情報を不正に得、あるいは、ＮＭＳの動作を途切れさすように偽のメッセージを浴びせる可能性もある。また、通信の手順では、攻撃者は、正規のホストに成りすましてほかの個人使用のホストをだます可能性がある。同様に、攻撃者は、ＣＨやＮＭＳＥに偽のＲＮＩを通知して特定のホストとの正規の相互通信を切断する可能性もある。

ＭＩＭＡは、中間介入の攻撃者による送信メッセージの改ざんで行われ得る。例えば、ホストとＮＭＳＥとの中間に介入した攻撃者は、ホストの登録情報を変更する可能性があり、また、送信された解決結果におけるマッピング情報を変更する可能性がある。繰り返し攻撃は、攻撃者が個人的目的を達するため、過去のパケットを繰り返し送りつけなされる。

本発明の実施形態は、一般的な世界規模のＮＭＳの構造にセキュリティ上の特徴的造作を組み込み、埋め込むものである。これにより、上記の攻撃からその構造自体で自己保護を可能とする。

（ＩＢＥ、ＩＢＳ）
この実施形態において、ＩＤベース暗号（ＩＢＥ）とＩＤベース署名（ＩＢＳ）とを含むＩＤベース暗号技術が利用される。この技術は、自己証明できるＩＤに大きな利点を有するためである。ここで、その基本的な機能を説明する。

ＩＢＥの基本的な仕組みが図５に示される。ＩＢＥによって、送信者アリスは、受信者ボブのＩＤを利用しメッセージＭを暗号化することができる（符号１Ａ）。受信者ボブは、キーサーバ（ＫＳ）３から得た秘密鍵（ＰＫBob）を利用し、暗号文を復号（解読）することができる（符号２Ａ）。ＩＢＥにおける基本的機能は次である。１）準備：ＫＳ３は、ハッシュ関数の情報を含む、双線形群と公開パラメータ（ＰＰｓ）とを選択し、マスター鍵ＭＫおよび対応する公開鍵ＰｕｂＫKSを生成する。図５において、ＰｕｂＫKSとＰＰｓとはアリスおよびボブ両者に通知される。２）鍵生成：ＫＳ３は、ユーザ（ボブ）のＩＤに基づいて関数ＫｅｙＧｅｎ（ＭＫ，ＩＤ）を用いてユーザのため秘密鍵を生成する。図５において、ボブは、その秘密鍵ＰＫBobを獲得する。ＰＫBobは、ボブのＩＤとＰｕｂＫKSとＰＰｓとに対応づけられている。３）暗号化：通信者（アリス）は、ボブのＩＤを使ってメッセージを暗号化する。図５において、アリスは、メッセージＭを暗号化し、ボブのＩＤを使い暗号文Ｃを得る。４）復号：通信者（ボブ）は、その秘密鍵を用いて暗号文を復号する。図５において、ボブは、その秘密鍵ＰＫBobを用いてアリスからの暗号文を復号し、平文のメッセージを得る。

ＩＢＳの基本的な仕組みが図６に示される。ＩＢＳによって、送信者アリスは、その秘密鍵を用いてメッセージＭに署名をし、署名のあるメッセージＳｉｇAliceを受信者ボブに送る（符号１Ｂ）。受信者ボブは、アリスのＩＤを利用して署名の正当性を検証できる（符号２Ｂ）。ＩＢＳにおける基本機能は以下である。１）準備：ＫＳ３は、双線形群とＰＰｓとを選択し、マスター鍵ＭＫおよび対応する公開鍵ＰｕｂＫKSを生成する。２）鍵生成：ＫＳ３は、ユーザ（アリス）のＩＤに基づいて関数ＫｅｙＧｅｎ（ＭＫ，ＩＤ）を用い、ユーザのため秘密鍵を生成する。この関数は、ＩＢＥでのものと同一でもよくまたは違っていてもよい。図６において、アリスは、そのＩＤに対応して秘密鍵ＰＫAliceを獲得する。３）署名：通信者（アリス）は、その秘密鍵を用いメッセージに署名を行う。図６において、アリスは、メッセージＭに署名を行い、ＰＫAliceを使い、そして署名ＳｉｇAliceを得る。４）認証：通信者（ボブ）は、アリスのＩＤを使い署名を検証できる。図６において、ボブは、アリスのＩＤAliceを使いアリスからの署名を検証する。

ＩＢＥとＩＢＳとで、マスター鍵、公開鍵、公開パラメータ、および鍵生成関数は同一でも異なってもよい。以下の説明では、その簡単化のため、それらは、ＩＢＥとＩＢＳとで同一であるとして説明する。

ＩＢＥとＩＢＳとは、信頼性のある第三者の介在がなしで認証が済むという、有利な特徴を有している。すなわち、ＰｕｂＫKSおよびＰＰｓKSを得た後では、通信者は、互いに認証を直接に行うことができ、その通信者が特定のＩＤを持っているかどうかを判断できる。

（略記）
略記について以下に参照のため述べる。これは、以下の記載でも用いられる。
１．ＫＳ：キーサーバ
２．ＰｕｂＫKS：ＫＳのマスター鍵に対応するその公開鍵（ひとつの特定のホストに属さない）
３．ＰＰｓX：装置Ｘに現在保持されている、ＫＳによって選択された公開パラメータ
４．ＮａｍｅX：装置Ｘのホスト名
５．ＩＤX：装置ＸのＩＤであり、ＮａｍｅXに失効時間が付加された形式を有する。
６．ＰＫX：装置ＸのＩＤXに対応する、装置Ｘの秘密鍵
７．ＳｉｇX：装置Ｘの秘密鍵ＰＫXによってＩＢＳ署名技術を使ってなされたその署名
８．｛Ｍ｝IDX：装置ＸのＩＤXによってＩＢＥ暗号技術を使い暗号化されたメッセージ
９．ＴＭ：タイムスタンプ
１０．Ｎk：時刻ｋで生成されたランダム数
１１．ＳＫ：セッション鍵（対称鍵）
１２．ＮＭＳＥ：ＮＭＳ（ネームマッピングシステム）装置
１３．ＲＮＩ：ＭＮＳサブシステムに登録された関連必要情報
１４．ＲＮＩSSiHostk：ＮＭＳサブシステムＳＳｉに登録された、ホストｋのＲＮＩ
１５．ＥＤ：エッジドメイン
１６．ＥＤＫＳ：エッジドメインキーサーバ
１７．ＳＳ：ＮＭＳサブシステム
１８．ＳＳＫＳ：ＮＭＳサブシステムのためのキーサーバ
１９．ＧＷ：ゲートウエイ
２０．｛Ｍ｝SK：ＳＫによって対称暗号技術で暗号化されたメッセージ
２１．｜｜：付加演算子

（実施形態における課題の確認）
われわれは、ＮＭＳに自己保護性を持たせ、全体のシステムに信頼性を埋め込むことを意図する。現在の技術は、規模や、アドオンによる認証基礎構造への頻繁なアクセスなどの種々の制限のため適合的でない。そこで、種々の攻撃下でも免疫をもつ自己保護・高信頼性ＮＭＳ（Self-protectable Secure NMS：S²NMS）の設計が望まれる。すなわち、次のような手順を設計する。
１．信頼性のある登録：ホスト登録情報が中間の装置で改ざんされないことを保証するため、ホストとＮＭＳＥとの間の相互認証が実行される一方、過去のパケットが繰り返されないようにする。これは、登録手順において、成りすまし攻撃、ＭＩＭＡ、および繰り返し攻撃を避けようとするものである。
２．ひとつのサブシステム内またはひとつのエッジドメイン内での信頼性のある情報交換：これは、ひとつのＳＳ内またはひとつのＥＤ内で流された情報が、自称のものから確かに提供されたことを保証するものである。また、ＭＩＭＡおよび繰り返し攻撃を避けようとすることも含む。
２．信頼性のある名前解決：再帰または反復による解決において、ホストとひとつのＳＳ内のＮＭＳＥとの間で相互認証がなされように保証すること。また、ＳＳをまたいだ反復による解決が保護されるようにすること。これは、解決の手順における成りすまし攻撃を避けようとするものである。また、ＭＩＭＡおよび繰り返し攻撃を避けようとすることも含む。
３．ホスト間の相互認証：ひとつの特定の名前を有する通信ホストの持ち主を検証できるように保証すること。これは、成りすまし攻撃、ＭＩＭＡ、および繰り返し攻撃を避けようとするものである。
４．信頼性のある対応関係の更新：ホストがその移動を通知したときそのホスト名が確かにその自称のものであることを保証すること。これは、成りすまし攻撃、ＭＩＭＡ、および繰り返し攻撃を防止しようとするものである。

上記のことから、本実施形態は、ＮＭＳを伴ったグローバルな認証枠組みの設計を意図していることがわかる。これにより、各装置に、この構造で情報を提供する通信装置の真の身元を知らしめることができる。

（課題解決の方向）
ＮＭＳ構造に自己保護性を埋め込んで、自己保護性を有しかつ高信頼性としたＮＭＳ（Ｓ^２ＮＭＳ）が提案される。これにより、登録、情報交換、解決、通信、および対応関係更新の各手順で用いられる各装置が、確実な情報獲得のため互いを認証できるようにする。このＳ^２ＮＭＳでは、ＩＢＥおよびＩＢＳを基本とすれば、信頼性ある第三者が必要ないという名前認証における特長を確約するということから、これを基本セキュリティ機能として採用する。

Ｓ^２ＮＭＳの構造的レイアウトの全体が図７に示される。これは以下の点は一般的なネットワークと同様である。すなわち、この構造は、前提として、ローカルなエッジドメイン１Ｎ１、１Ｎ２、…、１Ｎ３と、グローバルな情報転送ネットワーク２００と、制御プレーンであるＮＭＳ１００とからなる。なお、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。

次に、このＮＭＳ構造にセキュリティを組み込むため、２つの新規な装置が導入される。同図中に示すエッジドメインキーサーバ（ＥＤＫＳ）６１、６２、…、６３とＮＭＳサブシステムキーサーバ（ＳＳＫＳ）７１、７２、…とである。ＥＤＫＳは、ひとつのドメインにおける、ＩＢＥ（ＩＤベース暗号）およびＩＢＳ（ＩＤベース署名）の機能を持ったキーサーバである。例えば、ローカルネットワークのサービスプロバイダや、企業体ネットワークの論理的な管理サーバ、あるいは物理的なドメイン制御サーバなどとすることができる。エッジドメイン１Ｎ１、１Ｎ２、…、１Ｎ３のそれぞれに、ひとつまたはそれ以上のホスト群用として、ひとつまたはそれ以上のＥＤＫＳを設けてもよい。ＥＤＫＳは、そのサービス先のドメインで、秘密のマスター鍵を保持し、その対応の公開鍵ＰｕｂＫEDKSと公開パラメータＰＰｓEDKSとを発信する。また、ネットワークサービスに登録しようとするホストのため、秘密鍵ＰＫHostを生成する責任を負う。

もうひとつの新規な装置であるＮＭＳＳＳキーサーバ（ＳＳＫＳ）７１等は、図７に示すように、ひとつのＮＭＳＳＳにおける、ＩＢＥおよびＩＢＳの機能を持ったキーサーバである。このサーバ７１等は、マスター鍵を保持し、ＮＭＳサブシステムにおけるその対応する公開鍵ＰｕｂＫSSKSおよびＰＰｓSSKSを、ネットワークサービスに登録したホストに通知する。また、ＮＭＳＳＳ（ＮＭＳサブシステム１００Ａ、１００Ｂ）のそれぞれのすべてのＮＭＳ装置３１ｈ〜３６ｈ、３１ｆ〜３５ｆに対して秘密鍵ＰＫNMSEも生成する。ひとつのＳＳには、複数のＳＳＫＳが存在する可能性もある。以下では、簡単化のため、ひとつのＳＳにひとつのＳＳＫＳがあるとものとする。

図７に示すように、ＥＤＫＳ６１、６２、…、６３、およびＳＳＫＳ７１等は、システムの全体が信頼づけられるように形作られる。ＥＤＫＳ６１、６２、…、６３はひとつの信頼づけられたＥＤを構築するためのものであり、一方、ＳＳＫＳ７１等はひとつのＮＭＳＳＳに信頼性を与えるものである。これらの構成が、登録手順、情報交換手順、解決手順、通信手順、および対応関係更新手順に信頼性を与え、よってネットワーク構造は当然に認証のサポートされたものになる。

実施形態のＮＭＳ（Ｓ^２ＮＭＳ）構造は、以下の６つの主たる部分（コンポーネント）からなる。１．ＩＤフォーマットおよびセキュリティの設定。秘密鍵を失効させることが可能なＩＤフォーマットが導入される。また、ＮＭＳおよびひとつの信頼づけられたＥＤにおけるセキュリティ設定が示される。２．信頼性のある登録。ここでは、ホストおよびＥＤＫＳのセキュアな登録について詳述される。３．ひとつのＳＳあるいはひとつのＥＤでの信頼性のある情報交換。この情報交換は、ひとつのＳＳ内のＮＭＳＥあるいはひとつのＥＤ内の装置に、対応関係やルーティングの情報交換をセキュアに行わせるものである。４．信頼性のある解決および相互認証。ひとつのＳＳで名前解決手順が行われる間に仕掛けられ得る種々の攻撃を避けるようにセキュアな再帰または反復の解決ステップが設計される。また、解決チェーンの全体を保護するようにＳＳ間で反復解決を行うことの設計もなされる。さらに、ふたつのホスト間のグローバルな相互認証が詳述される。５．信頼性のある対応関係更新。ここでは、ＣＨへのセキュアな更新の手順、およびＳＳへのセキュアな更新手順が提供される。６．取り消し。ここでは、秘密鍵の自動的な失効と、取り消されたホストのリストの維持とが提供される。これにより、危険に侵されたホストへの解決や接続を防止する。以上のそれぞれのコンポーネントは、次に順に詳述される。

（１．ＩＤフォーマットおよびセキュリティの設定）
ＮＭＳは、通信のため、ホスト名をホストのＲＮＩに対応づけるシステムである。セキュリティの仕組みとしてＩＢＥおよびＩＢＳが採用される。ホスト名が認証のためのホストＩＤとして直接に用いられる場合は、このホスト名に対応する秘密鍵が生成、利用されることになる。しかしながら、安全のため秘密鍵は一定時間ごとに失効させる必要があり、これはホスト名が頻繁に変更されることを要する意味になる。同様の考えで、ひとつの名前に対応する秘密鍵が危険に侵された場合は、この名前はほぼ永久に使えなくなる。ホスト名が認証のためのホストＩＤとして直接に採用されるなら、このように受け入れがたい状況になってしまう。

この点を解決するため、ホストＩＤとしてホスト名を直接に使用しないようにする。つまり、登録手順においてＥＤＫＳが、ホスト名として、次のフォーマットのように失効時間を伴ったＮａｍｅHostであるホストＩＤをホストに与えるようにする。失効時間は、登録時刻に失効期間を加えたものである。
ＩＤHost＝ＮａｍｅHost｜｜失効時間（例えば、ＩＤHost1＝Ｈｏｓｔ１．Ｋ．Ｃ．Ｙ｜｜２０１１１００８１２００）

ＩＤHostの例として、ホスト１のホスト名が、Ｈｏｓｔ１．Ｋ．Ｃ．Ｙであるとき、ＩＤHost1は、例えば２０１１年１０月８日の１２時に失効する、という具合である。

このホストＩＤおよび対応する秘密鍵が、サービスを行っているＥＤＫＳによってホストに提供される。ＮＭＳサブシステム（ＳＳ）にホスト名およびＲＮＩを登録するときには、このＩＤがホストの身元を認証するため用いられるが、そのままＮＭＳに登録されず、ホスト名のみが登録される。名前解決手順、相互認証手順、およびローケータ更新手順でも、このＩＤが互いの認証のために利用されるが、名前解決自体ではホスト名、つまりＩＤのうちのホスト名の部分が利用される。

以上のＩＤフォーマットを導入し、次に、ＳＳおよびＥＤのためのセキュリティ設定の導入がなされる。ＳＳは、ホスト名またはＲＮＩを解決するための階層構造または平坦構造のＮＭＳＥを有している。例えば、図８（ａ）に示すＮＭＳサブシステム１００Ｋでは６つのＮＭＳＥ３１ｈ〜３６ｈ（これらは階層構造であるが、平坦構造のＮＭＳＥが設けられた場合も同様である。以下では、階層構造のＮＭＳＥ３１ｈ〜３６ｈとして説明する）がある。ＮＭＳが信頼性ある名前解決サービスを提供できるようにするため、ＮＭＳサブシステム１００ＫにＳＳＫＳ７１Ｋが導入され、これらのＮＭＳＥ３１ｈ〜３６ｈに対してＩＤベース暗号技術に基づき秘密鍵を生成する。このサブシステム１００Ｋで、ＳＳＫＳ７１は、ＩＢＥおよびＩＢＳのセキュリティ機能と同様に、ひとつのマスター鍵とこれに対応するひとつの公開鍵とを生成する。そして、公開鍵ＰｕｂＫSSKSkとそのＰＰｓであるＰＰｓSSKSkとをすべてのＮＭＳＥ３１ｈ〜３６ｈに通知する。新たにＮＭＳＥが加えられたときには、その名前および失効時間に基づいてＳＳＫＳ７１はＩＤを生成し、さらにこのＮＭＳＥ３１ｈ〜３６ｈのためそのＩＤに対応する秘密鍵をＩＤベース暗号技術に基づいて生成し、このＮＭＳＥにＰｕｂＫSSKSkおよびＰＰｓSSKSkを送る。基礎的な構成設定のあと、サブシステム１００Ｋでは、ＮＭＳＥ３１ｈ〜３６ｈそれぞれがＩＤNMSE、ＰｕｂＫSSKSk、ＰＰｓSSKSk、およびその秘密鍵ＰＫNMSEを保持することになる。例えば、ＮＭＳＥ6であるＮＭＳＥ３６ｈは、ＩＤNMSE6、ＰｕｂＫSSKSk、ＰＰｓSSKSk、ＰＫNMSE6を保持する。通信者は、ＮＭＳＥ３６ｈに送るメッセージを、ＩＤNMSE6を用いて暗号化することができ、ＮＭＳＥ３６ｈは、認証づけられた送信元であることを示すため、ＰＫNMSE6を使ってメッセージに署名することができる。

同様に、ひとつのＥＤ内のＥＤキーサーバ６Ｍは、ＩＤおよび秘密鍵の生成を行い、公開鍵および公開パラメータの通知をルータ、ゲートウエイ、およびホストに対して行うことの責任を有している。図８（ｂ）に例示されるように、基礎的な構成設定のあと、ゲートウエイ４ＭはＰｕｂＫEDKSm、ＰＰｓEDKSm、ＩＤGW、ＰＫGWを持ち、ルータ９１（Ｒ１）は、ＰｕｂＫEDKSm、ＰＰｓEDKSm、ＩＤR1、ＰＫR1を持ち、基地局８１（ＢＳ１）は、ＰｕｂＫEDKSm、ＰＰｓEDKSm、ＩＤBS1、ＰＫBS1を持ち、ホスト１１（Ｘ）は、ＰｕｂＫEDKSm、ＰＰｓEDKSm、ＩＤHostX、ＰＫHostXを持つことになる。ルータ９２（Ｒ２）、９３（Ｒ３）、…についても同様である。

（２．信頼性のある登録）
基本的なセキュリティの構成設定のあと、ホストおよびＥＤＫＳは、検索され得るように登録される必要がある。異なるサブシステムには異なるＲＮＩが登録され得るが、あるひとつのサブシステムに登録されるとき、登録に関わる装置は、すでに述べた成りすまし攻撃を避けるため、互いに認証を行う必要がある。すなわち、ひとつのホストがそれにサービスを行うＮＭＳＥであるＮＭＳＥkに登録するとき、そのホストはＮＭＳＥkの身元を確認する必要があり、ＮＭＳＥkは、このホストの正しい構成設定を確認する必要がある。同様な要求は、ＥＤＫＳの登録手順でも生じる。

ホストの登録手順には２つのフェーズがある。最初のフェーズ１は、図９に示されるように、自装置のＩＤとこれに対応する秘密鍵とをＥＤＫＳから手に入れることである。次のフェーズ２は、図１０に示すように、ホスト名およびＲＮＩをサブシステムに登録し、その存在を通知することである。

図９は、フェーズ１の例を示し、これによりＮａｍｅHost1の名前のホスト１は、ＥＤＫＳmがサービスするＥＤにおいてネットワークサービスを得ることができる。ホスト１の持ち主がＥＤからサービスを受けるには、まず、サービスセンターからホームルータ（ＨＲ）を得る必要がある。あるいは、ホスト１の持ち主は、家にすでに設けられたＨＲを使うこともできる。図９に示すようにホームルータＢが設けられた後、ホスト１は、サービスセンターにあるホームルータＢにあらかじめロードされているＩＤEDKSm、ＰｕｂＫEDKSm、およびＰＰｓEDKSmをホームルータＢから手に入れることができる。それからホスト１は、キーサーバであるＥＤＫＳmのＩＤで暗号化された、ホスト１の名前、ＳＫ、Ｎl、およびＴＭl（以上のものを含む暗号情報）を送ることによってＥＤＫＳｍにサービスを要求する。ＳＫ（セッション鍵）は、対称鍵であり、これは、ホスト１とＥＤＫＳｍとの間のセキュアな通信のため用いられる。ＥＤＫＳｍは、この情報を受け取るとＩＢＥ機能を使ってそのメッセージを復号し、この要求を受け入れるか否かを決定する。決定がイエスであれば、ＥＤＫＳｍは、ホスト１に向けて、ＩＤHost1＝ＮａｍｅHost1｜｜失効時間、のごとくにそのＩＤを生成し、さらにＩＢＥおよびＩＢＳの鍵生成手順を用い、ＩＤHost1に対応する秘密鍵ＰＫIDHost1を生成する。それからＥＤＫＳｍは、セッション鍵ＳＫで暗号化された｛ＩＤHost1、ＰＫIDHost1、ＰｕｂＫSSKSl、ＰＰｓSSKSl、Ｎ1、ＴＭ2｝を、署名ＳｉｇIDEDKSmを添えて送る。ここでＰｕｂＫSSKSlおよびＰＰｓSSKSlは、サブシステムそれぞれで必要とされる公開鍵および公開パラメータを一般化して意味するものである。以下では簡単のため、ＰｕｂＫSSKSlおよびＰＰｓSSKSlがそのそれぞれを表すものとする。ＰｕｂＫSSKSlおよびＰＰｓSSKSlは、ホスト１がＳＳlに対して登録および名前解決を要求したときに、ホスト１とＳＳl内のＮＭＳＥとが相互認証するため用いられる。署名ＳｉｇIDEDKSmが添えられたメッセージをホスト１が受け取ると、ホスト１は、この署名を検証しかつセッション鍵による復号を行ってそのＩＤであるＩＤHost1およびその秘密鍵ＰＫIDHost1を得、これをインス
トールする。最後に、ホスト１は、ＩＢＳ署名ＳｉｇIDHost1が付されたＩＤHost1、Ｎ2、ＴＭ3を送る。このメッセージをＥＤＫＳmが受け取ると、ＥＤＫＳmは、ＳｉｇIDHost1の正当性を検証することができ、これでホスト１によりＰＫIDhost1が正しくインストールされたことの確証を得られる。

図１０は、フェーズ２を示し、これによりホスト１は、そのＩＤおよび対応の秘密鍵のインストールを完結した後に、ひとつのサブシステムにその情報の登録を行う。別のサブシステムへの登録手順も同様なので、その手順の図解に、例として、ＳＳiへの登録手順を挙げ説明する。この手順において、ホスト１は、最初に、そのＩＤであるＩＤHost1を添えて、ＮＭＳサブシステムであるＳＳiに登録要求を送る。ＳＳiは、それに対応してサービスを行うＮＭＳＥであるＮＭＳＥkの発見を行い、これによりＮＭＳＥkは、その署名ＳｉｇIDNMSEkを添えて、ホスト１に向けＩＤNMSEk、Ｎi、ＴＭiを返答する。ホスト１は、ＩＤNMSEkを使うことでその署名ＳｉｇIDNMSEkを検証してこの情報の正当性を検証する。そして、ホスト１は、ＩＤNMSEkで暗号化された｛ホスト１の名前、ホスト１のＲＮＩ、ＰｕｂＫEDKSHost1、ＰＰｓEDKSHost1、Ｎi｝と、ＴＭjとを含み、かつ署名ＳｉｇIDHost1を伴った情報を生成して、これをＮＭＳＥkに送る。これに対しＮＭＳＥkは、ＳｉｇIDHost1の正当性を検証し、メッセージを復号し、ホスト名およびＥＤＫＳ情報が正当かどうか点検する。すべての点検に合格すると、ＥＤＫＳの情報を含むホスト１のすべての情報を登録する。ＥＤＫＳの情報は、名前解決手順での通信装置によって獲得され得、そのときに相互認証のため用いられる。

ホスト名、公開鍵、および公開パラメータは、基本的な登録情報であり、これらはすべてのサブシステム（ＳＳ）に登録される必要がある。なお、異なるＳＳには異なるＲＮＩが登録され得る。例えば、ＬＩＳＰ＋ＡＬＴのＮＭＳにおいては、ＥＩＤ情報はＤＮＳサブシステムに登録される一方、ＲＬＯＣルーティング情報はＡＬＴサブシステムに登録される。

セキュアなホスト登録手順においては、ホストおよびその対応のＮＭＳＥの相互認証が実行される。またそのとき、ＮＭＳＥはホストから提供された情報の正当性を点検することができ、さらに、ＭＩＭＡや繰り返し攻撃もランダム数およびタイムスタンプを用いて回避される。

ひとつのＥＤＫＳでＥＤがサービスされるように意図するとき、ＥＤＫＳはＥＤＫＳ登録手順によりＮＭＳサブシステムに登録される必要がある。これは、ホストのＮＭＳへの登録と同様である。ＰｕｂＫSSKSiおよびＰＰｓSSKSiがＥＤＫＳにあらかじめロードされている。ＥＤＫＳはＮＭＳサブシステムに登録要求を行い、これに対してＳＳiの特定のＮＭＳＥが、そのＩＤを返答し、それで、ＥＤＫＳは、ＥＤ名、ＥＤＫＳ名、ＥＤＫＳローケータ、ＰｕｂＫEDKS、ＰＰｓEDKS、およびランダム数をＮＭＳＥのＩＤで暗号化し、これにその署名を添える。ＮＭＳＥがこのメッセージを受け取ると、これを復号し、公開情報を獲得し、署名の正当性を検証する。そして、ＥＤＫＳ情報を登録する。同様にして、ＥＤＫＳはその情報をすべてのサブシステムに登録する。

（３．ひとつのＳＳ内またはひとつのＥＤ内での信頼性のある情報交換）
登録されたＲＮＩは、ＩＤ、ローケータ、ルーティング情報のほか、別の考え得る情報である可能性がある。ひとつのＳＳ内での情報交換という状況は、そのＳＳ内でＲＮＩを共有する必要がある場合に対応して生じ得る。そこで、ひとつのＳＳ内において情報提供者のために身元認証を行うことが、セキュアな情報交換によって提供される。

ひとつのＳＳに、そこに存在するＮＭＳＥのため鍵生成を行い公開鍵および公開パラメータの通知を行うひとつのキーサーバＳＳＫＳが存在する。それで、すべてのＮＭＳＥは同じ公開鍵ＰｕｂＫSSKSと公開パラメータＰＰｓSSKSとを有する。信頼性のある情報交換手順が図１１に示される。図１１において、ＳＳｉ内のＮＭＳＥxは、ＮＭＳＥkに対して情報を提供しようとし、提供する情報、現時点でのそのＩＤであるＩＤNMSEx、およびＮj、ＴＭjを、その署名ＳｉｇIDNMSExを添えて送り出す。このメッセージをＮＭＳＥkが受け取ると、ＳｉｇIDNMSExを検証し、検証の通過後に、提供された情報を登録する。

ひとつのＥＤ内でも、ルータ、ＧＷ、およびほかの装置などの装置間でルーティング情報を交換するとき、同様の手順がなされ得る。

（４．信頼性のある解決および相互認証）
あるホストが別のホストと通信しようとするとき、その通信者の名前をローケータとして解決することを、そのあるホストはＮＭＳに要求する必要がある。これが、いわゆる解決手順である。ＮＭＳはひとつまたはそれ以上の数のサブシステムを有するので、解決手順は、単一のＳＳでの解決で足りるか、または複数のＳＳにおける連続的な解決になるかのいずれかである。ひとつのＳＳ内での解決モードには、再帰方式および反復方式という２つの方法があり得る。一方、すでに述べたように、ＳＳ間をまたがる場合には、それらとの関係として反復方式のみが用いられる。これらのことにより、ＮＭＳにおける信頼性のある解決も、３つの部分として実現される。すなわち、ひとつのＮＭＳサブシステム内での信頼性のある再帰解決および反復解決、ならびにＮＭＳサブシステム間での信頼性のある反復解決である。

ひとつのＮＭＳ内における再帰方式の場合のセキュアな名前解決の手順が図１２に示される。図１２において、ホスト１が、ひとつのＮＭＳサブシステムであるＳＳiに対して、ホスト２（発信先装置）の名前であるＮａｍｅHost2の解決要求を行う。このサブシステムのキーサーバはＳＳＫＳiである。ホスト１は、ＩＤHost1、ＮａｍｅHost2、Ｎ1、およびＴＭ1を伴った、その署名ＳｉｇIDHost1付きの要求メッセージをＮＭＳＥmに送る。ＮＭＳＥｍは、このメッセージを受け取ると、次のＮＭＳＥ0にこの要求を転送する。このような要求の転送により、最後に、対応してサービスを行うＮＭＳＥxに要求が届く。ＮＭＳＥxは、ＰｕｂＫEDKSHost1およびＰＰｓEDKSHost1をこのサブシステムから獲得する。これは、ホストおよびＥＤＫＳの登録がなされたときに、それらがすでにサブシステムに登録されているから可能である。そして、ＮＭＳＥxは、ＰｕｂＫEDKSHost1、ＰＰｓDEKSHot1、およびＩＤHost1によってＳｉｇIDHost1の正当性を検証する。これに合格すると、ＮＭＳＥxは、ホスト２のＲＮＩを探索、獲得し、ＮａｍｅHost2、ＰｕｂＫEDKSHost2、ＰＰｓEDKSHost2、Ｎ1をＩＤHost1によって暗号化する。最後に、ＮＭＳＥxは、暗号化メッセージにタイムスタンプおよび署名ＳｉｇIDNMSExを加えてこれをホスト１に送る。ホスト１は、このパケットを受け取ると、ＰｕｂＫSSKSiおよびＰＰｓSSKSiをすでに有しているので、これを用いてＳｉｇIDNMSExの正当性を検証できる。そして、暗号化メッセージを復号し、ホスト２に関する情報である、ＲＮＩHost2、ＰｕｂＫEDKSHost2、ＰＰｓEDKSHost2を獲得する。

ひとつのサブシステム内で反復モードが利用されるときには、信頼性のある反復解決がなされる必要があり、これが図１３、図１４に示される。信頼性のある反復解決手順では、対応のＮＭＳＥにたどり着くまでに複数の反復ステップが存在する。図１３に示す反復ステップにあるように、ホスト１は、その署名ＳｉｇIDHost1を添えてＩＤHost1、ＮａｍｅHost2、Ｎ1、ＴＭ1を伴う解決要求をＮＭＳＥmに送る。ここでＮＭＳＥmという表記は、最初のＮＭＳＥから最後にサービスを行うＮＭＳＥに至るまでのその途上のＮＭＳＥを一般化して表したものである。これらのＮＭＳＥには、同じ並びのメッセージが送られるからである。この要求をＮＭＳＥmが受け取ると、ＮＭＳＥmは、ＮＭＳＥmの署名を添えて、ＩＤHost1で暗号化された、次に要求を送ることが可能なＮＭＳＥの名前およびローケータの一覧を返答する。ここでは、簡単化のため、このような一覧の代わりに、単一のＮＭＳＥの名前およびローケータが送られるものとする。いずれにしてもホスト１は、そのひとつを選んでそれに要求を送るからである。ホスト１がこのメッセージを受け取ると、ＳｉｇIDNMSEmを検証し、メッセージを復号して次のＮＭＳＥの名前およびローケータを獲得する。そして次に、ホスト１は、このＮＭＳＥをＮＭＳＥmに対応させて同様のことを行う。

図１４に示すように、要求メッセージが最後にサービスを行うＮＭＳＥに達して、最後の解決ステップが実行される。このステップでは、ホスト１は、最後のＮＭＳＥであるＮＭＳＥxに対してＮａｍｅHost2の解決を要求する。ホスト２は、そのＲＮＩを保持しているＮＭＳＥxのサービスエリアに存在する。それで、ＮＭＳＥxは、ホスト１に対して、ＳｉｇIDNMSExを添えて、ＩＤHost1で暗号化された、ＲＮＩHost2、ＰｕｂＫEDKSHost2、およびＰＰｓEDKSHost2を提供する。ホスト１は署名を検証し、最後にホスト２の情報を獲得する。

以上の記述から、再帰解決でも反復解決でも、ホスト１は安全にホスト２のＲＮＩ、公開鍵、および公開パラメータを、ＮＭＳサブシステムＳＳiから手に入れることができることがわかる。そこで、ひとつのサブシステムにおける信頼性のある解決手順を簡略化して描いたものが図１５である。図１５に示すように、ホスト１は、その署名を添えて解決要求をＳＳiに対して送り出し、ＳＳiは、ホスト２のＲＮＩ、公開鍵、および公開パラメータを返答する。

ひとつのＮＭＳサブシステムにおける信頼性のある名前解決についての記載に続いて、ＮＭＳサブシステム間での信頼性のある反復解決について図１６、図１７を参照して説明する。ＮＭＳサブシステム間の反復解決手順では、複数のサブシステムが含まれているため、最後のＮＭＳサブシステムでの解決に至るまで複数の反復ステップが存在する。図１６に示す反復ステップでは、ホスト１は、その署名ＳｉｇIDHost1を添えて、ＳＳiに対してＩＤHost1、ＮａｍｅHost2、Ｎk、ＴＭｋを伴う解決要求を送り出す。ＳＳiは、最後のＳＳの前に位置するＳＳを一般化して表したものである。これは、同様の並びのメッセージがＳＳのそれぞれで取り扱われるためである。ＳＳiは、この要求を受け取ると、ＳｉｇIDNMSExを添えて、ＩＤHost1で暗号化されたＲＮＩSSiHost2、ＰｕｂＫEDKSHost2、およびＰＰｓEDKSHost2をホスト１に対して返答する。ここで、ＲＮＩSSiHost2は、ＳＳiに登録されたホスト２のＲＮＩである。そこで、ホスト１は、得た署名を検証してホスト２のＲＮＩを獲得する。最後のＳＳの前に別のＳＳが存在するならば同様の手順が実行される。

ホスト１が最後のＮＭＳサブシステムであるＳＳkに要求を送ると、図１７に示すような最後の解決ステップが実行される。このステップでは、ホスト１は、最後のＳＳであるＳＳkに対して、前のサブシステムで得られたＲＮＩに基づいた解決を要求する。ホスト２は、ＳＳkにおいてホスト２のＲＮＩを保持したＮＭＳＥyのサービス領域に存在する。それで、ＮＭＳＥyは、ＩＤHost1で暗号化された、ＳＳkでのＲＮＩSSkHost2、ＰｕｂＫEDKSHost2、およびＰＰｓEDKSHost2を、ＳｉｇIDNMSEyを添えてホスト１に対して提供する。ホスト１は、得た署名を検証し、ホスト２についての最後の解決情報を得る。

多くの場合、信頼性のある通信のためには、相互の認証が必要である。上記の一方向の解決手順では、発信元ホストは、発信先ホストの名前、ローケータ、公開鍵、公開パラメータを得るが、これは、発信元ホストから発信先ホストの現在のＩＤを得てその確認が可能であるということである。しかしながら、この手順では、発信先ホストは、発信元ホストの身元を確認することができない。これは、一方向の解決のみが行われるならば、発信先ホストが確認可能な発信元ホストの情報を持ち得ないからである。Ｓ^２ＮＭＳでは、発信先ホストも発信元ホストの名前、ＲＮＩ、公開鍵、公開パラメータを獲得できるように、他方向の解決手順を実行するようにする。これにより、発信先ホストと発信元ホストとの相互認証が円滑になされ得る。その認証手順が図１８に示される。

相互認証を行うため、ホスト１は、ランダム数Ｎ1を生成し、その現在のＩＤであるＩＤHost1のほか、ＮａｍｅHost2、Ｎ1、およびＴＭ1をその署名ＳｉｇIDHost1を添えてホスト２に送る。ホスト２は、この情報を受け取ると、ＮＭＳを用いて、ＩＤHost1の一部であるＮａｍｅHost1を解決し、ホスト１のＰｕｂＫEDKSHost1、ＰＰｓEDKSHost1を獲得する。そして、ＳｉｇIDHost1の検証を行う。検証を通過した後、ホスト２は、対称鍵ＳＫを生成し、さらに、ＩＢＥ暗号化機能によりＩＤHost1で暗号化された、対称鍵ＳＫ、Ｎ1、およびＮ2の暗号情報を生成し、これにその現時点のＩＤであるＩＤHost2およびＴＭ2を加え、署名ＳｉｇIDHost2を添えてホスト１に送る。ＳｉｇIDHost2をホスト１が検証して、さらにメッセージを復号しＳＫを得る。そして、ＳＫでＮ2が暗号化されてホスト２に送られることにより、これらの間に、セキュアな通信チャンネルの確立がなされる。

（５．信頼性のある対応更新）
ホスト１がネットワークのあるアタッチポイントから異なるアタッチポイントへ移動したときに、そのホスト名が維持され得るように意図したとする。この状況下では、ホスト１は、その新たなローケータをそのＣＨであるホスト２および対応するＮＭＳサブシステムに対して更新する必要がある。

図１９におけるホスト２への信頼性のある対応関係の更新に関して、ホスト１は、その署名ＳｉｇIDHost1を添えて、そのＩＤであるＩＤHost1、古いローケータであるＬｏｃａｔｏｒ1、新しいローケータであるＬｏｃａｃｏｒ2をホスト２に送り出す。ホスト２は、このパケットを受け取ると、すでに解決手順でホスト１の公開鍵および公開パラメータを得ているので、この署名の正当性を直接に検証できる。検証できたら、ホスト２は、ホスト１の古いローケータＬｏｃａｔｏｒ1を新たなローケータＬｏｃａｔｏｒ2に置き換える。

対応のＮＭＳサブシステムに対してローケータ更新を行う場合にも、同様の手順が実行される。ＮＭＳサブシステムにとってホスト１の公開鍵は既知なので、ＮＭＳＥは容易にホスト１の署名の正当性を検証できそのローケータを更新できる。

（６．取り消し）
Ｓ^２ＮＭＳでは、ふたつの方法が取り消しのため採用される。ひとつは、ＩＤに基づく自動的な失効であり、もうひとつは、ブラックリストの維持である。すでに述べたように、ホストＩＤは、失効時間を伴ったホスト名という形式で、登録手続きによりホストに対して発行される。このＩＤは、失効時間が示す時刻より前で使用できる。ホストは、失効時間に達する前に、対応してサービスを行うＥＤＫＳに対して、さらなる認証のため、失効時間の延長された新しいＩＤおよび新しい秘密鍵の発行を要求する必要がある。しかし、ＩＤおよび失効時間はＮＭＳに登録される情報でないので、ＮＭＳへの登録をやり直す必要はない。

一方、ＩＤおよび対応する秘密鍵が失効時間の前に危険に侵された（解読された）場合についても考慮しておく必要がある。あるホストの現時点の秘密鍵が危険に侵された場合、取り消しの手順が必要である。そこで、対応するＮＭＳＥは、ホストについての取り消しリストを保持する。ＮＭＳＥのそれぞれは、そのサービス領域でサービスされるホストのみについて取り消しホストリストを保持する。この取り消しホストリストには、取り消されたホスト名および失効時間が記録される。したがって、解決手順において、ＮＭＳ解決が成功裏に終わったとしても、対応のＮＭＳＥは、要求された発信先ホストが取り消しリストにあるかどうかを点検する。それがリストにあれば、エラーメッセージが発信元ホストに返信される。それ以外は、通常のＮＭＳ解決が実行される。また、これらの取り消された名前は、失効時間に達すれば削除される。

（実施形態の効果）
本実施形態によれば、以下の効果が得られる。
１．ホストは、信頼性高くそれらの情報をＮＭＳに登録できる。これは、ホストとＮＭＳＥとの間の相互認証が可能であるからであり、ＭＩＭＡや繰り返し攻撃も避けることができる。
２．ＮＭＳ内のＮＭＳＥおよびＥＤ内の各装置が、登録情報またはルーティング情報を信頼性高く交換することができる。また、ＭＩＭＡや繰り返し攻撃も防止できる。
３．発信元ホストが、信頼性高く発信先ホストの名前をそのローケータ、公開鍵、およびさらなるＲＮＩとして解決できる。これは、発信元ホストとＮＭＳＥとの間で、再帰または反復のモードによる相互認証がなされるためであり、ＮＭＳサブシステム間では、反復のモードで信頼性のある解決がなされるためである。
４．ホスト間の相互認証がなされ得る。相互の名前解決手順のあと、２つのホストは、互いの通信者の現時点のＩＤ、ならびにそのサービスを行うＥＤＫＳの公開鍵および公開パラメータを得ることができる。これにより、通信開始前に相互の認証が円滑に行われる。
５．マッピング対応情報が信頼性高く更新できる。これは、ＣＨおよび対応するＮＭＳＥが、更新を必要とするホストの公開鍵を知っているからである。それで、ＣＨおよび対応のＮＭＳＥは、受け取った更新パケットの正当性を容易に確認できる。

１Ｎ１，１Ｎ２，１Ｎ３，１ＮＭ…エッジドメイン（ＥＤ）、３…キーサーバ（ＫＳ）、１１，１１Ｐ，１２…ホスト、２１…ＩＴＲ、２２…ＥＴＲ、３０Ｌ…ローカルＤＮＳサーバ（ＬＤＮＳＳ）、３１，３２，３３，３４，３５，３６…ＤＮＳサーバ（ＤＮＳＳ；階層構造のＮＭＳ装置の一例）、３１ｈ，３２ｈ，３３ｈ，３４ｈ，３５ｈ，３６ｈ，３７ｈ…階層構造のＮＭＳ装置（階層構造のＮＭＳＥ）、３１ｆ，３２ｆ，３３ｆ，３４ｆ，３５ｆ，３１ｇ，３２ｇ，３３ｇ，３４ｇ，３５ｇ，３６ｇ…平坦構造のＮＭＳ装置（平坦構造のＮＭＳＥ）、４１，４２，４３，４４，４５，４６，４７，４８，４９，４Ｍ…ゲートウエイ（ＧＷ）、６１，６２，６３，６Ｍ…ＥＤキーサーバ（ＥＤＫＳ）、７１，７２，７１Ｋ…ＮＭＳサブシステムキーサーバ（ＮＭＳＳＳＫＳ）、８１…基地局、９１，９２，９３…ルータ、１００…ＮＭＳ、１００Ａ，１００Ｂ，１００Ｋ…ＮＭＳサブシステム、１１０，１２０…ＤＮＳ（ドメイン名システム）、１３０…ＤＮＳサブシステム、１４０…ＡＬＴサブシステム、２００…グローバルな情報転送ネットワーク。

Claims

キーサーバが有するＩＤである第１のＩＤに基づき、自装置の名前とセッション鍵とを少なくとも含む第１の情報を暗号化して第１の暗号情報を生成する手段と、
前記第１の暗号情報を前記キーサーバに送出する手段と、
前記第１の暗号情報を前記キーサーバが復号して得た前記名前に対応して前記キーサーバが前記自装置向けに生成したＩＤである第２のＩＤと、該第２のＩＤに対応して前記キーサーバが生成した秘密鍵とを少なくとも含む第２の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第２の暗号情報とされてかつ前記キーサーバの署名である第１のサーバ署名が付されて前記キーサーバから送られてきたときに、該第２の暗号情報および該第１のサーバ署名を受け取る手段と、
前記第１のサーバ署名の正当性を検証する手段と、
前記第２の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、
ホストに関する情報を登録するサーバたる登録サーバを含んで構造化されたシステムに対して、前記自装置の登録を要求する旨の情報を前記第２のＩＤを付して送出する手段と、
前記登録サーバのＩＤである第３のＩＤを少なくとも含む第３の情報が、前記登録サーバの署名である第２のサーバ署名が付されて前記登録サーバから送られてきたときに、該第３の情報および該第２のサーバ署名を受け取る手段と、
前記第２のサーバ署名の正当性を検証する手段と、
前記第３のＩＤに基づき、前記自装置の前記名前を少なくとも含む第４の情報を暗号化して第３の暗号情報を生成し、かつ前記秘密鍵に基づき、自装置署名を生成する手段と、
前記第３の暗号情報および前記自装置署名を前記登録サーバに送出する手段と
を具備することを特徴とするホスト装置。
前記第１の暗号情報が、前記第１の情報にランダム数およびタイムスタンプをさらに含ませるようにして得た情報を暗号化して得られた暗号情報であり、
前記第３の暗号情報が、前記第４の情報に、前記ランダム数とは異なる第２のランダム数をさらに含ませるようにして得た情報を暗号化して得られた暗号情報であること
を特徴とする請求項１記載のホスト装置。