JP2013066104A - ホスト装置 - Google Patents

Abstract

【課題】自己保護性を向上することができるホスト装置を提供すること。
【解決手段】キーサーバの第１ＩＤに基づき、自装置の第２ＩＤとセッション鍵とを含む情報を暗号化して第１暗号情報を生成し、第１暗号情報をキーサーバに送出し、第１暗号情報をキーサーバが復号して得た第２ＩＤに対応してキーサーバが生成した秘密鍵が、キーサーバが復号して得たセッション鍵による暗号化で第２暗号情報とされてかつサーバ署名が付されてキーサーバから送られてきたときに、第２暗号情報およびサーバ署名を受け取り、サーバ署名の正当性を検証し、第２暗号情報からセッション鍵で秘密鍵を復号して得、登録解決サーバの第３ＩＤに基づき、自装置のホスト名と、第２ＩＤと、自装置のローケータと、を含む情報を暗号化して第３暗号情報を生成しかつ第３暗号情報に自装置署名を付し、第３暗号情報および自装置署名を登録解決サーバに送出する。
【選択図】図８

Description

本発明は、ＩＤおよびローケータの情報を持ち得るホスト装置に関する。

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

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

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

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

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

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

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

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.

本発明は、ＩＤおよびローケータの情報を持ち得るホスト装置において、自己保護性を向上することができるホスト装置を提供することを目的とする。

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

また、本発明の別の態様であるホスト装置は、通信をしようとする発信先装置が有するグローバルホスト名の解決を要求する旨の情報を少なくとも含む第１の情報に自装置署名を付して、ドメイン名を登録解決するサーバである第１の登録解決サーバに送出する手段と、前記グローバルホスト名を登録解決するサーバである第２の登録解決サーバが有するＩＤたる第１のＩＤおよび該第２の登録解決サーバのローケータである第１のローケータを少なくとも含む第２の情報が、自装置のＩＤである第２のＩＤに基づく暗号化で第１の暗号情報とされてかつ前記第１の登録解決サーバの署名である第１のサーバ署名が付されて前記第１の登録解決サーバから送られてきたときに、該第１の暗号情報および該第１のサーバ署名を受け取る手段と、前記第１のサーバ署名の正当性を検証する手段と、前記第１の暗号情報から、前記第１のＩＤおよび前記第１のローケータを復号して得る手段と、前記第１のＩＤに基づき、前記グローバルホスト名の解決を要求する旨の情報を少なくとも含む第３の情報を暗号化して第２の暗号情報を生成する手段と、前記第２の暗号情報に自装置署名を付して前記第２の登録情報サーバに送出する手段と、前記発信先装置が有するＩＤである第３のＩＤおよび前記発信先装置のローケータである第２のローケータを少なくとも含む第４の情報が、前記第２のＩＤに基づく暗号化で第３の暗号情報とされてかつ前記第２の登録解決サーバの署名である第２のサーバ署名が付されて前記第２の登録解決サーバから送られてきたときに、該第３の暗号情報および該第２のサーバ署名を受け取る手段と、前記第２のサーバ署名の正当性を検証する手段と、前記第３の暗号情報から、前記第３のＩＤおよび前記第２のローケータを復号して得る手段とを具備することを特徴とする。

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

また、本発明のさらに別の態様であるホスト装置は、自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置のグローバルホスト名を登録解決するサーバである登録解決サーバに送出する手段とを具備することを特徴とする。

本発明によれば、ＩＤおよびローケータの情報をもち得るホスト装置において、自己保護性を向上することができる。

実施形態であるホスト装置が登録と名前解決とを行う手順を示す説明図。 実施形態であるホスト装置のローケータ更新を行う手順を示す説明図。 ＩＤベース暗号（ＩＢＥ）の基本的な仕組みを説明するブロック図。 ＩＤベース署名（ＩＢＳ）の基本的な仕組みを説明するブロック図。 実施形態であるホスト装置が組み込まれ得る、プロアクティブに信頼性のあるＩＤ／ローケータ分離の枠組み（ＰＴＩＳＦ）の構造を示す説明図。 ＰＴＩＳＦにおけるドメイン名レジストリサーバ（ＤＮＲ）システムの構造を示す説明図（図６（ａ））およびＰＴＩＳＦにおけるエッジネットワークの構造を示す説明図（図６（ｂ））。 ＰＴＩＳＦにおける、ホスト名レジストリサーバ（ＨＮＲ）のＤＮＲへの登録手順を時系列に示す説明図。 ＰＴＩＳＦにおける、実施形態であるホスト装置のＨＮＲへの登録手順を時系列に示す説明図。 図８の続図であって、ＰＴＩＳＦにおける、実施形態であるホスト装置のＨＮＲへの登録手順を時系列に示す説明図。 ＰＴＩＳＦにおける、実施形態であるホスト装置が名前解決を行うときの手順を時系列に示す説明図。 図１０の続図であって、ＰＴＩＳＦにおける、実施形態であるホスト装置が名前解決を行うときの手順を時系列に示す説明図。 ＰＴＩＳＦにおける、実施形態であるホスト装置が発信先ホスト装置との相互認証を行うときの手順を時系列に示す説明図。 ＰＴＩＳＦにおける、実施形態であるホスト装置が移動した場合に行われる、発信先ホスト装置へのローケータの更新の手順を時系列に示す説明図。

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

（説明の準備事項）
現在のインターネットの構造は、将来の社会的ニーズを満足させることができない。インターネットを最初から設計し直して、新世代ネットワーク（ＮＷＧＮ）を構築する必要がある。ＮＷＧＮにおける構造に向けて、われわれは、ＨＩＭＡＬＩＳ（Heterogeneity Inclusion and Mobility through Locator ID Separation）という概念を提案した。ＨＩＭＡＬＩＳではＩＤ（識別子）とローケータとを分離する。

ＨＩＭＡＬＩＳの構造は、ホスト名とＩＤとを形づくる、新規な名称づけの枠組みを提供する。ＨＩＭＡＬＩＳでは、グローバルホスト名は、つながりを表わす記号「＃」を用いてローカルホスト名とドメイン名とを繋ぐことによって構成され、世界で唯一の名称になる。例えば、「sensor-temp-room-5-202#my-domain.com」のごとくである。ホストＩＤは、プレフィックス、スコープ、バージョンの各フィールドに、グローバルホスト名と付加パラメータとの暗号化されたハッシュ値を繋ぐことで発生される。すなわち、ホストＩＤ＝プレフィックス＋バージョン＋スコープ＋ハッシュ（グローバルホスト名、パラメータ）、である。以下、単に「ホスト名」という場合は、ローカルホスト名ではなくグローバルホスト名を意味する。

ＨＩＭＡＬＩＳは、主に、ローカルなエッジ（すなわち、アクセス用の）ネットワークと、グローバルな情報転送ネットワークと、統一された論理制御ネットワークとからなる。ＨＩＭＡＬＩＳでは、３つの構成、すなわち、ドメイン名レジストリサーバ（ＤＮＲ）、ホスト名レジストリサーバ（ＨＮＲ）、ＩＤレジストリサーバ（ＩＤＲ）が導入される。ＤＮＲは、ドメイン名と、いくつかのドメイン内のホスト名を管理するＨＮＲのＩＤおよびローケータとの対応を記憶している。ＨＮＲは、いくつかのドメイン内のホスト名とそのＩＤおよびローケータとのマッピングを記憶している。ＩＤＲは、移動装置の、ホストＩＤとローケータとの間のつながりを記憶しまた分配する。ＤＮＲとＨＮＲとは、通信の初期化の段階で、名前を登録し、ホスト名をローケータとして解決するため用いられる。一方、ＩＤＲは、ネットワークにおけるホストＩＤとローケータとの間のつながりを更新、分配するために使われる。これらの構成は、生来的に、異なるエッジネットワークで使われている不均一なネットワーク層プロトコルを、ゲートウエイを含むネットワークノードを通してグローバルなＮＷＧＮに統合し、その時間的変化にも左右されない。ＨＩＭＡＬＩＳの主たる機能は、名前の登録および解決と、ローケータの更新とからなり、これを次に述べる。

ホスト名の登録と解決のステップが図１に示されている。登録ステップは、ステップ１．１とステップ１．２を含む。ステップ１．１は、ＨＮＲ２１の名前と、そのＩＤおよびローケータとをＤＮＲシステム３Ｓに属するＤＮＲ３１に登録する。ステップ１．２は、ホスト１１のホスト名と、そのＩＤおよびローケータとをＨＮＲ２１に登録する。マッピング手順は、ドメイン名の参照とホスト名の参照とである２つの下位手順からなり、ステップ２．１から２．４である。ステップ２．１、２．２は、ホスト１２が、ＤＮＲ３１によって、ホスト１１のドメイン名をＨＮＲ２１のＩＤおよびローケータとして解決（＝名前解決、以下でも単に「解決」という場合がある）する。ステップ２．３、２．４は、ホスト１２が、ＨＮＲ２１を用いることで、ホスト１１のホスト名をホストＩＤおよびローケータとして解決する。

ホスト１１のローケータ情報の更新ステップが図２に示されている。図２は、実施形態であるホスト装置のローケータ更新を行う手順を示す説明図である。この更新ステップは、対応ノード（ＣＮ）更新とＨＮＲ更新という２つの手順を含む。ＣＮ更新は、ステップ１．１から１．６までとして示されているように、更新要求がＣＮに出され、ＣＮがこの要求を承認する。ＨＮＲ更新は、ステップ２．１から２．４までとして示されているように、更新要求がＨＮＲに出され、ＨＮＲがこの要求を承認する。なお、図２において、符号１Ｎ１、１Ｎ２、１Ｎ３は、それぞれエッジネットワークであり、符号１２は、ホスト１１と通信を行っているホスト（図１中に示した同符号のものと同じ）であり、符号４１、４２、４３は、それぞれ、エッジネットワーク１Ｎ１、１Ｎ２、１Ｎ３と論理制御ネットワーク１００とを結合するゲートウエイであり、符号５１、５２、５３は、それぞれ、ゲートウエイ４１、４２、４３に対応するＩＤＲである。ＨＮＲ２１については、図１中に示した同符号のものと同じである。

ＨＩＭＡＬＩＳが将来のネットワークで広く使われるようにする上で、これらの手順において、ネットワークにある装置間で信頼性のある相互動作が得られるように考えることは重要である。すなわち、ＨＩＭＡＬＩＳのようなＩＤ／ローケータ分離構造を設計する段階で、構造レベルとして脅威を取り除いておくのが好ましい。脅威は、次の４つの手順で生じ得る。すなわち、ＨＮＲ／ホストがそのＩＤおよびローケータを登録するとき、あるホストがほかのホストの名前をＩＤおよびローケータとして解決することを要求するとき、あるホストがほかのホストと通信するとき、およびあるホストがそのローケータを更新するときである。これらの手順において攻撃者は、成りすまし攻撃、中間介入攻撃（ＭＩＭＡ）、または繰り返し攻撃を仕掛ける可能性がある。

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

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

本発明の実施形態は、ＨＩＭＡＬＩＳの構造設計の段階で、これにセキュリティ上の特徴的造作を組み込み、埋め込むものである。これにより、上記の攻撃からその構造自体で自己保護を可能とする。

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

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

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

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

略記について以下に参照のため述べる。これは、以下の記載でも用いられる。
１．ＫＳ：キーサーバ
２．ＰｕｂＫKS：ＫＳのマスター鍵に対応するその公開鍵（ひとつの特定のホストに属さない）
３．ＰＰSX：装置Ｘに現在保持されている、ＫＳによって選択された公開パラメータ
４．ＩＤX：装置ＸのＩＤ
５．ＰＫX：装置ＸのＩＤXに対応する、装置Ｘの秘密鍵
６．ＳｉｇX：装置Ｘの秘密鍵ＰＫXによってＩＢＳ署名技術を使ってなされたその署名
７．｛Ｍ｝IDX：装置ＸのＩＤXによってＩＢＥ暗号技術を使い暗号化されたメッセージ
８．ＴＭ：タイムスタンプ
９．Ｎk：時刻ｋで生成されたランダム数
１０．ＳＫ：セッション鍵（対称鍵）
１１．ＤＮＲ：ドメイン名レジストリサーバ（第１の登録解決サーバ：ドメイン名を登録解決するサーバ）
１２．ＨＮＲ：ホスト名レジストリサーバ（第２の登録解決サーバ：グローバルホスト名を登録解決するサーバ）
１３．ＩＤＲ：ＩＤレジストリサーバ
１４．ＤｏｍａｉｎＴＰ：ドメイン信頼ポイント（エッジネットワークに備えるキーサーバ）
１５．ＤＮＲ ＫＳ：ドメイン名レジストリサーバシステムのためのキーサーバ
１６．ＧＷ：ゲートウエイ
１７．｛Ｍ｝SK：ＳＫによって対称暗号技術で暗号化されたメッセージ

（実施形態における課題の確認）
われわれは、新規なＩＤ／ローケータ分離システムであるＨＩＭＡＬＩＳに自己保護性を持たせ、全体のシステムに信頼性を埋め込むことを意図する。現在の技術は、規模や、アドオンによる認証基礎構造への頻繁なアクセスなどの種々の制限のため、ＨＩＭＡＬＩＳシステムに適合的でない。そこで、種々の攻撃下でも免疫をもつプロアクティブに信頼性のあるＩＤ／ローケータ分離構造の設計が望まれる。すなわち、次のような手順を設計する。
１．信頼性のある登録：ホストとＨＮＲとの間の登録情報が中間の装置で改ざんされないことを保証するため、ホストとＨＮＲとの間、またはＨＮＲとＤＮＲとの間の相互認証が実行される一方、過去のパケットが繰り返されないようにする。これは、登録手順において、成りすまし攻撃、ＭＩＭＡ、および繰り返し攻撃を避けようとするものである。
２．信頼性のあるＩＤ／ローケータの解決：ホストとＤＮＲとの間、およびホストとＨＮＲとの間の相互認証がなされように保証すること。これは、解決の手順における成りすまし攻撃を避けようとするものである。また、ＭＩＭＡおよび繰り返し攻撃を避けようとすることも含む。
３．ホスト間の相互認証：ひとつの特定ＩＤを有する通信ホストの持ち主が確かめられるように保証すること。これは、成りすまし攻撃、ＭＩＭＡ、および繰り返し攻撃を避けようとするものである。
４．信頼性のあるローケータの更新：ホストがその移動を通知したときそのＩＤの正確さを保証すること。これは、成りすまし攻撃、ＭＩＭＡ、および繰り返し攻撃をやめさせようとするものである。

上記のことから、本実施形態は、ＨＩＭＡＬＩＳのようなＩＤ／ローケータ分離システムと合体したグローバルな認証枠組みの設計を意図していることがわかる。これにより、各装置に対して、この構造で情報を提供する通信装置が有する真のＩＤを知らせることができる。

（課題解決の方向）
ＨＩＭＡＬＩＳに自己保護性を埋め込むため、プロアクティブに信頼性のあるＩＤ／ローケータ分離の枠組み（ＰＴＩＳＦ）が提案される。それにより、登録、解決、通信、およびローケータ更新の各手順で用いられる各装置が確実な情報を獲得するために、互いを認証できるようにする。ＰＴＩＳＦでは、ＩＢＥおよびＩＢＳを基本とすれば、信頼性ある第三者が必要ないというＩＤ認証における特長を確約するということから、これを基本セキュリティ機能として採用する。

ＰＴＩＳＦの構造的レイアウトの全体が図５に示される。これは以下の点はＨＩＭＡＬＩＳと同様である。すなわち、この構造は、主として、ローカルなエッジ（すなわち、アクセス用の）ネットワーク１Ｎ１、１Ｎ２、…、１Ｎ３と、グローバルな情報転送ネットワーク２００と、統一された論理制御ネットワーク１００とからなる。なお、すでに説明した図中に示したものと同一または同一相当のものには同一符号を付してある。情報転送ネットワーク２００は、ゲートウエイ４１、４２、…、４３のほか、ゲートウエイ４４、４５、４６、…を含み得る。

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

図５に示されるように、ひとつのＨＮＲ２１（２２）が担当している領域で、ひとつまたはそれ以上のドメインＴＰ６１（６３）が存在する。ＨＮＲ２１（２２）それ自体も、ひとつのドメインＴＰ６１（６３）で信頼づけられたひとつのドメインで、サービスを受ける。ひとつのドメインＴＰ６１（６３）は、ひとつのＨＮＲのみにサービスするか、複数のＨＮＲにサービスするか、または、ひとつのＨＮＲおよび多くの共用する装置にサービスするかである。ＨＮＲ２１（２２）も、そのサービスエリアにある装置に対して、そのサービスするドメインＴＰ６１（６３）の公開鍵およびＰＰｓを通知する必要がある。

ドメインＴＰがひとつのドメインにサービスを行いＨＮＲが複数のドメインにサービスを行うという構造は、ドメインを信頼づけるための設定を融通性よいものにする。すなわち、ひとつのドメインのサイズとそのドメインの物理的または論理的な定義は、異なるオペレータによって多様に決定され得る。

もうひとつの新規な装置ＤＮＲキーサーバ（ＤＮＲＫＳ）７１は、図５に示すように、ドメイン名登録システムにおける、ＩＢＥ（ＩＤベース暗号）およびＩＢＳ（ＩＤベース署名）の機能を持ったキーサーバである。このサーバ７１は、マスター鍵を保持し、ＤＮＲシステムにおけるその対応する公開鍵ＰｕｂＫDNRKSおよびＰＰｓを、ＨＮＲに、およびネットワークサービスに登録したホストに通知する。また、ＤＮＲシステム３ＳにおけるすべてのＤＮＲ３１〜３６に対して秘密鍵ＰＫDNRXも生成する。

図５に示すように、ドメインＴＰ６１、６２、…、６３、ＨＮＲ２１、２２、…、およびＤＮＲＫＳ７１は信頼づけられたシステムの全体を形作る。ドメインＴＰ６１、６２、…、６３はひとつの信頼づけられたドメインを構築するためのものであり、ＨＲＮ２１、２２、…は複数の信頼づけられたドメインに対してサービスを行うものであり、一方、ＤＮＲＫＳ７１はＤＮＲシステム３Ｓの全体に信頼性を与えるものである。これらの３つの構成が、登録手順、解決手順、通信手順、およびローケータ更新手順に信頼性を与え、よってネットワーク構造は当然に認証がサポートされたものになる。実施形態のＰＴＩＳＦは、６つの主たる部分からなる。１．ＤＮＲシステムおよび信頼性あるドメインセキュリティの設定。２．信頼性ある登録。ここでは、ＨＮＲ、ドメインＴＰ、およびホストのセキュアな登録がなされる。３．信頼性のある解決および相互認証。セキュアなＤＮＲ名前解決、ＨＮＲ名前解決、および２つのホスト間のグローバルな相互認証が説明される。４．信頼性あるローケータ更新。ここでは、ＣＮ（対応ノード）へのセキュアな更新の手順およびＨＮＲへのセキュアな更新の手順が提供される。５．取り消し。ここでは、取り消されたホストのリストは、名前が解決されることや危険にさらされたホストへの接続を避けるため、維持される。６．キャッシング。ホストは、頻繁に接続するホストのＩＤ、公開鍵、およびパラメータをキャッシュする機能を持つ。これにより、素早い認証と名前解決ができる。以上の部分はそれぞれ、次に順に詳述する。

（１．ＤＮＲシステムおよび信頼性あるドメインセキュリティの設定）
ＤＮＲシステム３Ｓは、ドメイン名をＨＮＲのＩＤおよびローケータとして解決する、階層的なＤＮＲ３１〜３６からなる。例えば、図６（ａ）に示すＤＮＲシステム３Ｓでは６つのＤＮＲ３１〜３６がある。ＤＮＲシステム３Ｓが信頼性ある名前解決サービスを提供できるようにするため、ＤＮＲＫＳ７１が導入され、これらのＤＮＲ３１〜３６に対してＩＤベース暗号技術に基づいて秘密鍵を生成する。このシステム３Ｓで、ＤＮＲＫＳ７１は、ＩＢＥおよびＩＢＳのセキュリティ機能における、ひとつのマスター鍵とこれに対応するひとつの公開鍵を生成する。そして、公開鍵ＰｕｂＫDNRKSとＰＰsとをすべてのＤＮＲ３１〜３６に通知する。新たにＤＮＲが加えられたときには、ＩＤベース暗号技術に基づいた、そのＩＤに対応する秘密鍵をこのＤＮＲに対して生成して、ＰｕｂＫDNRKSおよびＰＰsを送る。基礎的な構成設定のあと、ＤＮＲシステム３Ｓでは、ＤＮＲ３１〜３６それぞれがＰｕｂＫDNRKS、ＰＰs、およびその秘密鍵を保持することになる。例えば、ＤＮＲX.A３１は、ＩＤDNRX.A、ＰｕｂＫDNRKS、ＰＫDNRX.Aを保持する。通信者は、ＤＮＲX.A３１に送るメッセージを、ＩＤDNRX.Aを用いて暗号化することができ、ＤＮＲX.A３１は、認証づけられた送信元であることを示すため、ＰＫDNRX.Aを使ってメッセージに署名することができる。

同様に、ドメインＴＰ６１、…は、秘密鍵の生成を行い、公開鍵の通知をルータ、ゲートウエイ、およびホストに対して行うことの責任を有している。図６（ｂ）における基礎的な構成設定のあと、ゲートウエイ４１はＰｕｂＫdomainTP、ＰＫGWを持ち、ルータ９１（Ｒ１）は、ＰｕｂＫdomainTP、ＰＫR1を持ち、アクセスポイント８１（ＡＰ１）は、ＰｕｂＫDomainTP、ＰＫAP1を持ち、ホスト１１（Ｘ）は、ＰｕｂＫDomainTP、ＰＫHostXを持つことになる。ルータ９２（Ｒ２）、９３（Ｒ３）、…についても同様である。

また、ＨＮＲ２１は、信頼性のあるひとつのドメインに属している必要があるため、その識別子ＩＤHNRに対応する秘密鍵ＰＫHNRをこのドメインＴＰ６１から獲得することになる。さらに、ドメインＴＰ６１は、それ自体の情報をこのＨＮＲ２１に登録する必要がある。ドメインＴＰ６１は、このＨＮＲ２１に対してだけサービスを行うか、複数のＨＮＲに対してサービスを行うか、または、ＧＷ、ルータ、およびホストを含む多数の装置を伴ったひとつのＨＮＲに対してサービスを行うかである。

（２．信頼性のある登録）
基本的なセキュリティの構成設定のあと、ＨＮＲ、ドメインＴＰ、およびホストは、検索できるように登録される必要がある。登録されるとき、登録に関わる装置は、すでに述べた成りすまし攻撃を避けるため、互いに認証を行う必要がある。すなわち、ひとつのＨＮＲがＤＮＲX.Yに登録するとき、ＤＮＲX.YのＩＤを確認する必要があり、ＤＮＲX.Yは、このＨＮＲの正しい構成設定を確認する必要がある。同様な要求は、ドメインＴＰやホストの登録手順でも生じる。

図７は、ＨＮＲ登録手順を示す。ひとつのＨＮＲがＤＮＲシステムに登録しようとするとき、そのＨＮＲは、ＤＮＲサービスセンターのような信頼のある場所からＰｕｂＫDNRKSおよびＤＮＲＫＳのＰＰSを獲得することができる。図７に示すように、ＨＮＲAは、どのＤＮＲが自身のためサービスを行っているかわからないので、ＨＮＲAは、ＤＮＲシステムに登録の要求を送る。ＤＮＲシステムは、ＤＮＲX.YがＨＮＲAを記録することになるとの決定を行い、そしてＤＮＲX.YがＨＮＲAにコンタクトを行ってその識別子ＩＤDNRX.YをＨＮＲAに告げ、登録できるようにする。ここで、成りすまし攻撃およびＭＩＭＡを避けるため、ＩＢＳ署名がメッセージに添えられる。そして、ランダム数Ｎlが認証のため使われ、タイムスタンプＴＭ1が繰り返し攻撃を避けるため使われる。ＨＮＲAは、この情報を受けたあと、このＩＢＳ署名ＳｉｇIDDNRX.Yの正当性をＩＤDNRX.YおよびＰｕｂＫDNRKSを使って確かめることができる。この点検に合格することで、ＨＮＲAは、通信者が真にＤＮＲX.Yであることを確信できる。そして、ＨＮＲAは、ＩＤDNRX.Yで暗号化された｛ドメイン名、ＨＮＲのＩＤおよびローケータ、ＰｕｂＫDomainTPHNRA、ＰＰSHNRA、Ｎ1｝と、Ｎ2、ＴＭ2とを含み、かつ署名ＳｉｇHNRAを伴った情報を送ることができる。ＤＮＲX.Yがこの情報を受けると、最初にＩＢＥ復号機能でそのメッセージを復号し、ＰｕｂＫDomainTPHNRを得る。そして、この情報が、もし存在するならすでに登録された情報に一致していないかを点検し、さらに、ＩＢＳ確認によりＳｉｇHNRAの正当性を検証する。すべての点検に合格すると、ＨＮＲAのすべての情報を登録する。最後に、承認（ＡＣＫ）をＨＮＲAに返答する。

セキュアなＨＮＲ登録手順においては、ＨＮＲおよび対応するＤＮＲの相互認証が実行される。また、ＤＮＲはＨＮＲから提供された情報の正当性を点検することができ、ＭＩＭＡや繰り返し攻撃は回避される。

ドメインがひとつのＨＮＲでサービスを受ける場合には、そのドメインＴＰは、ドメインＴＰ登録手順によりＨＮＲに登録される必要があるが、それはＨＮＲのＤＮＲへの登録と同様である。ドメインＴＰが最初にＨＮＲに対して登録の要求を行い、ＨＮＲがそのＩＤとともに返答を行い、そして、ドメインＴＰがＨＮＲのＩＤで、ドメイン名、ドメインＴＰのＩＤおよびローケータ、ＰｕｂＫDomainTP、およびランダム数を暗号化し、この暗号化されたメッセージに署名を加える。ＨＮＲがこのメッセージを受けると、これを復号し、公開情報を獲得し、署名の正当性を検証する。さらに、ドメインＴＰの情報を、ＨＮＲの記録部に登録する。それから、ＨＮＲはＰｕｂＫDNRKSおよびＰＰSDNRKSをドメインＴＰに送る。これらは、ホストの登録を行うとき、およびドメインＴＰおよびホストのためＤＮＲ解決をするとき、ドメインＴＰによって使われ得る。また、ＨＮＲに新たなドメインＴＰが登録される場合には、ＤＮＲが正しくホスト名を解決できるようにＤＮＲにその新しいドメイン情報を登録する必要がある。この手順は、ＨＮＲ登録と同様であるが、｛新規なドメイン名、ＨＮＲのＩＤおよびローケータ、ＩＤDomainTP、ＰｕｂＫDomainTP、ＰＰSDomainTP｝という異なる情報が登録される。

ホストの登録手順には２つのフェーズがある。最初のフェーズ１は、図８に示されるように、ホストのＩＤに対応する秘密鍵をドメインＴＰから手に入れることである。次のフェーズ２は、図９に示すように、ホスト情報をＨＮＲに登録し、その存在を通知することである。

図８は、フェーズ１を示し、これによりホストＡは、ドメインＴＰがサービスするドメインにおいてネットワークサービスを得ることができる。ホストＡの持ち主がドメインＴＰからサービスを受ける最初は、サービスセンターからホームルータ（ＨＲ）を得る必要がある。あるいは、ホストＡの持ち主は、家にすでに設けられたＨＲを使うこともできる。図８に示すようにホームルータＢが設けられた後、ホストＡは、サービスセンターにあるホームルータＢにあらかじめロードされているＩＤDomainTP、ＰｕｂＫDomainTP、およびＰＰSDomainTPをホームルータＢから手に入れることができる。それからホストＡは、キーサーバであるドメインＴＰのＩＤで暗号化された、ＩＤHostA（自装置のＩＤ）、ＳＫ、Ｎl、およびＴＭl（以上のものを含む暗号情報）を送ることによってドメインＴＰにサービスを要求する。ＳＫ（セッション鍵）は、対称鍵であり、これは、ホストＡとドメインＴＰとの間のセキュアな通信のため用いられる。ドメインＴＰは、この情報を受け取るとＩＢＥ機能を使ってそのメッセージを復号し、この要求を受け入れるか否かを決定する。決定がイエスであれば、ドメインＴＰは、ＩＢＥおよびＩＢＳの鍵生成手順を用い、ホストＡに向けて、ＩＤHostAに対応する秘密鍵ＰＫHostAを生成する。それからドメインＴＰは、セッション鍵ＳＫで暗号化された｛ＩＤHost、ＰＫHostA、ＰｕｂＫDNRKS、ＰＰSDNRS、ＩＤHNR、ＰｕｂＫHNR、ＰＰSHNR、Ｎl、ＴＭ2｝を、署名を添えて送る。ＰｕｂＫDNRKSは、ホストＡがＤＮＲ解決を問い合わせたときに、ホストＡとＤＮＲサーバとを相互認証するため用いられる。一方、ＩＤHNRおよびＰｕｂＫHNRは、ＨＮＲ登録のフェーズ２で用いられる。このメッセージをホストＡが受け取ると、ホストＡは、ドメインＴＰの署名を検証しかつセッション鍵による復号を行いその秘密鍵ＰＫHostAを得、これをインストールする。最後に、ホストＡは、ＩＢＳ署名ＳｉｇHostAが付されたＩＤHostA、Ｎ2、ＴＭ3を送る。このメッセージをドメインＴＰが受け取ると、ドメインＴＰは、ＳｉｇHostAの正当性を検証することができ、これでホストＡによりＰＫhostAが正しくインストールされたことを確信することができる。

図９は、フェーズ２を示し、これによりホストＡは、その秘密鍵のインストールを完結した後に、ＨＮＲに情報の登録ができる。ホストＡはＨＮＲの情報をドメインＴＰから得ているので、ホストＡは、ホスト名、ホストのＩＤおよびローケータ、ＩＤDomainTP、ＰｕｂＫDomainTP、ＰＰSDomainTP、Ｎi、ＴＭiを含む情報をＨＮＲのＩＤで暗号化し、自装置署名ＳｉｇHostAを加えてＨＮＲに送る。ＨＮＲはＩＤDomainTPなどのドメインＴＰ情報が正当であるかどうかを点検し、その後ＳｉｇHostAの正当性を検証する。すべての点検が合格なら、ＨＮＲは、ドメインＴＰの情報を含むホストＡの情報を記憶部に記憶する。記憶部の内容は、解決手順の間、通信者によって獲得され得、その後に相互認証のため用いられる。

（３．信頼性のある解決および相互認証）
あるホストが別のホストと通信しようとするとき、その通信者の名前をローケータとして解決することを、そのあるホストはネットワークに要求する必要がある。これは、いわゆる解決手順であり、すでに述べたように、ＤＮＲ解決およびＨＮＲ解決という２つのフェーズを含む。そこで、信頼性のある解決がこの２つのフェーズにも導入される。すなわち、セキュアなＤＮＲ解決およびセキュアなＨＮＲ解決である。

セキュアなＤＮＲ解決の手順が図１０に示される。図１０において、Ｈｏｓｔ１＃ＤｏｍａｉｎＸが、ＤＮＲシステムに対して、Ｈｏｓｔ２＃ＤｏｍａｉｎＹ（発信先装置のグローバルホスト名）の解決要求を行う。ホスト１は、ランダム数およびタイムスタンプを伴った、その署名付きの要求メッセージをＤＮＲシステムに送る。ＤＮＲシステムは、このメッセージを受け取ると、ＤＮＲzがこの要求に対処することを決定する。ＤＮＲzは、ＤＮＲシステムからドメインＸのＰｕｂＫDomainTPHNRXおよびＰＰSDomainTPHNRXを獲得する。これは、ドメインＴＰ登録がなされたときにＤＮＲシステムにＰｕｂＫDomainTPHNRXが登録されているから可能である。そして、ＤＮＲzは、ＰｕｂＫDomainTPHNRXおよびＩＤHost1によってＳｉｇHost1の正当性を検証する。これらの点検に合格すると、ＤＮＲZは、ドメインＹにサービスを行うＨＮＲYの情報を探索、獲得し、これをＩＤHost1によって暗号化する。最後に、ＤＮＲZは、その署名をメッセージに加えてこれをホスト１に送る。ホスト１は、このパケットを受け取ると、ＳｉｇDNRZの正当性を検証してメッセージを復号し、Ｈｏｓｔ２＃ＤｏｍａｉｎＹのＨＮＲ情報を獲得する。

対応するＨＮＲの情報が得られたあとは、図１１に示されるように、セキュアなＨＮＲ解決がなされる。セキュアなＨＮＲ解決手順においては、ホスト１は、ＩＤHNRY、ＬｏｃａｔｏｒHNRY、ＰｕｂＫHNRY、およびＰＰSHNRYを前提として獲得している。ホスト１は、ＨＮＲYに対して、ＩＤHNRYで暗号化され署名ＳｉｇHost1が伴われているＨｏｓｔ２＃ＤｏｍａｉｎＹを解決することをランダム数およびタイムスタンプを付して要求する。ＨＮＲYは、このパケットを受け取ると、ドメインＸの公開鍵をローカルに探索し、ＳｉｇHost1の正当性を検証する。検証が完結すると、ＨＮＲYは、ホスト１に対して、ＩＤHost2、ＬｏｃａｔｏｒHost2、ＰｕｂＫHost2、およびＰＰSHost2を含むホスト２の情報を返信する。これらの情報は、ＩＤHost1で暗号化され、ＳｉｇHNRYが伴われている。ホスト１は、署名を検証し、暗号化情報を復号して最終的にホスト２の情報を獲得する。

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

相互認証を行うため、ホスト１は、ランダム数Ｎ1を生成し、これに図示するようなホスト１のグローバスホスト名などの情報を加え、さらにこれをＩＢＥ暗号化機能によりＩＤHost2で暗号化する。ホスト１は、この情報に署名を添えてホスト２に送る。ホスト２は、この情報を受け取ると、Ｈｏｓｔ１＃ＤｏｍａｉｎＸを解決して、その公開鍵、ＩＤHost1、ＰｕｂＫHost1を獲得し、さらにＳｉｇHost1を検証する。検証が完結すると、ホスト２は、ＩＤHost1で暗号化されその署名が伴われた、対称なセッション鍵（ＳＫ）およびランダム数Ｎ2を生成する。ホスト１は、ＳｉｇHost2を検証しかつ復号してＳＫ、Ｎ2を獲得する。そして、ＳＫでＮ2が暗号化されてホスト２に送られることにより、これらの間に、セキュアな通信チャンネルの確立がなされる。

（４．信頼性のあるローケータ更新）
ホスト１がネットワークのある場所から異なる場所へ移動したとすると、ホスト１はその新しいローケータを、ＣＮ、ホスト２、および担当のＨＮＲに対して更新する必要がある。

図１３におけるホスト２へのローケータ更新に関して、ホスト１は、その署名を添えて新たなローケータＬｏｃａｔｏｒ２を送り出す。ホスト２は、このパケットを受け取ると、この署名の正当性を検証する。検証できたら、ホスト２は、古いホスト１のローケータＬｏｃａｔｏｒ１を新たなローケータＬｏｃａｔｅｒ２に置き換える。

ＨＮＲへのローケータ更新を行う場合も同様の手順が実行される。ＨＮＲにとってホスト１の公開鍵は既知なので、ＨＮＲは容易にホスト１の正当性を確認できそのローケータを更新できる。

（５．取り消し）
あるホストの秘密鍵が危険にさらされたときには、取り消しの手順が必要である。これについては、２つの方法を採用し得る。ひとつは、ホストＩＤに期限切れ時間を加え、その時点を過ぎるとホストＩＤが自動的に無効になる。もうひとつは、ＨＮＲがそれぞれホストの取り消しリストを保持し、ＨＮＲは、そのサービスエリアでサービスを受けていた、取り消されたホストのリストだけを保持する。この取り消しリストでは、取り消されたホスト名とＩＤとがすべて蓄積される。そして、解決手順においては、ＤＮＲ解決が成功したとしても、ＨＮＲは要求された発信先ホストが取り消しリストにあるか否かを点検する。そして、発信先ホストの最新ＩＤを確認する。取り消しリストにある場合または最新ＩＤ期限切れの場合には、エラーメッセージが発信元ホストに返される。それ以外は、通常のＨＮＲ解決が実行される。

（６．キャッシング）
相互認証の動作を改善するため、各ホストは、担当のＨＮＲのＩＤおよびローケータ、公開鍵、およびある程度頻繁に通信するホストのパラメータをキャッシュするメモリを保持する。あるホストが別のホストと通信を開始しようとするとき、そのメモリにそれらの情報が存在しているかを点検する。もし存在して発信先ホストにも発信元ホストの情報がキャッシュされているときには、相互解決なしに、キャッシュ情報を直接に利用してＨＮＲ解決および相互認証を行う。

（実施形態の効果）
本実施形態によれば、以下の効果が得られる。
１．ホストおよびＨＮＲは、信頼性高くそれらの情報をネットワークシステムに登録できる。これは、ＨＮＲとＤＮＲとの間またはホストとＨＮＲとの間の相互認証が可能であるからであり、ＭＩＭＡや繰り返し攻撃も避けることができる。
２．発信元ホストは、信頼性高く、発信先ホストの名前をそのＩＤ／ローケータおよび対応する公開鍵として解決できる。これは、発信元ホストとＤＮＲとの間の相互認証、および発信元ホストと発信先ホストのＨＮＲとの相互認証がなされるためである。また、発信元ホストは、発信先ノードの真のＩＤを認証することもできる。
３．ホスト間の相互認証がなされ得る。相互の名前解決手順のあと、２つのホストは、通信者のＩＤおよびそのドメインＴＰの公開鍵を得ることができる。それにより、通信開始前に相互の認証が円滑に行われる。
４．ＩＤおよびローケータのつながりを信頼性高く更新できる。これは、ＣＮおよび対応するＨＮＲが、更新を必要とするホストのＩＤと公開鍵を知っているからである。それで、ＣＮおよび対応のＨＮＲは、受け取った更新パケットの正当性を容易に確認できる。

１Ｎ１，１Ｎ２，１Ｎ３…エッジネットワーク、３…キーサーバ、３Ｓ…ドメイン名レジストリサーバシステム（ＤＮＲシステム）、１１，１２…ホスト、２１，２２…ホスト名レジストリサーバ（ＨＮＲ）、３１，３２，３３，３４，３５，３６…ドメイン名レジストリサーバ（ＤＮＲ）、４１，４２，４３，４４，４５，４６…ゲートウエイ、５１，５２，５３…ＩＤレジストリサーバ、６１，６２，６３…ドメイン信頼ポイント、７１…ＤＮＲキーサーバ、８１…アクセスポイント、９１，９２，９３…ルータ、１００…統一された論理制御ネットワーク、２００…グローバルな情報転送ネットワーク。

Claims (6)

1. キーサーバが有するＩＤである第１のＩＤに基づき、自装置のＩＤである第２のＩＤとセッション鍵とを少なくとも含む第１の情報を暗号化して第１の暗号情報を生成する手段と、
   前記第１の暗号情報を前記キーサーバに送出する手段と、
   前記第１の暗号情報を前記キーサーバが復号して得た前記第２のＩＤに対応して前記キーサーバが生成した秘密鍵を少なくとも含む第２の情報が、前記キーサーバが復号して得た前記セッション鍵による暗号化で第２の暗号情報とされてかつ前記キーサーバの署名であるサーバ署名が付されて前記キーサーバから送られてきたときに、該第２の暗号情報および該サーバ署名を受け取る手段と、
   前記サーバ署名の正当性を検証する手段と、
   前記第２の暗号情報から前記セッション鍵で前記秘密鍵を復号して得る手段と、
   自装置のグローバルホスト名を登録解決するサーバである登録解決サーバのＩＤたる第３のＩＤに基づき、自装置の前記グローバルホスト名と、前記第２のＩＤと、自装置のローケータと、を少なくとも含む第３の情報を暗号化して第３の暗号情報を生成しかつ該第３の暗号情報に自装置署名を付す手段と、
   前記第３の暗号情報および前記自装置署名を前記登録解決サーバに送出する手段と
   を具備することを特徴とするホスト装置。
2. 前記第１の暗号情報が、前記第１の情報にランダム数およびタイムスタンプをさらに含ませるようにして得た情報を暗号化して得られた暗号情報であり、
   前記第３の暗号情報が、前記第３の情報に、前記ランダム数とは異なる第２のランダム数および前記タイムスタンプとは異なる第２のタイムスタンプをさらに含ませるようにして得た情報を暗号化して得られた暗号情報であること
   を特徴とする請求項１記載のホスト装置。
3. 通信をしようとする発信先装置が有するグローバルホスト名の解決を要求する旨の情報を少なくとも含む第１の情報に自装置署名を付して、ドメイン名を登録解決するサーバである第１の登録解決サーバに送出する手段と、
   前記グローバルホスト名を登録解決するサーバである第２の登録解決サーバが有するＩＤたる第１のＩＤおよび該第２の登録解決サーバのローケータである第１のローケータを少なくとも含む第２の情報が、自装置のＩＤである第２のＩＤに基づく暗号化で第１の暗号情報とされてかつ前記第１の登録解決サーバの署名である第１のサーバ署名が付されて前記第１の登録解決サーバから送られてきたときに、該第１の暗号情報および該第１のサーバ署名を受け取る手段と、
   前記第１のサーバ署名の正当性を検証する手段と、
   前記第１の暗号情報から、前記第１のＩＤおよび前記第１のローケータを復号して得る手段と、
   前記第１のＩＤに基づき、前記グローバルホスト名の解決を要求する旨の情報を少なくとも含む第３の情報を暗号化して第２の暗号情報を生成する手段と、
   前記第２の暗号情報に自装置署名を付して前記第２の登録情報サーバに送出する手段と、
   前記発信先装置が有するＩＤである第３のＩＤおよび前記発信先装置のローケータである第２のローケータを少なくとも含む第４の情報が、前記第２のＩＤに基づく暗号化で第３の暗号情報とされてかつ前記第２の登録解決サーバの署名である第２のサーバ署名が付されて前記第２の登録解決サーバから送られてきたときに、該第３の暗号情報および該第２のサーバ署名を受け取る手段と、
   前記第２のサーバ署名の正当性を検証する手段と、
   前記第３の暗号情報から、前記第３のＩＤおよび前記第２のローケータを復号して得る手段と
   を具備することを特徴とするホスト装置。
4. 前記第１の情報が、ランダム数およびタイムスタンプをさらに含む情報であり、
   前記第２の暗号情報に、前記自装置署名のほか、前記ランダム数とは異なる第２のランダム数および前記タイムスタンプとは異なる第２のタイムスタンプが付されて前記第２の登録情報サーバに送出がなされること
   を特徴とする請求項３記載のホスト装置。
5. 通信をしようとする発信先装置が有する第１のＩＤに基づき、発信元である自装置のグローバルホスト名を少なくとも含む第１の情報を暗号化して第１の暗号情報を生成する手段と、
   前記第１の暗号情報に自装置署名を付して、前記発信先装置に送出する手段と、
   前記発信先装置が生成したセッション鍵およびランダム数を少なくとも含む第２の情報が、前記グローバルホスト名を前記発信先装置が名前解決システムを用いて解決し得た前記自装置のＩＤである第２のＩＤに基づく暗号化で第２の暗号情報とされてかつ前記発信先装置の署名である装置署名が付されて前記発信先装置から送られてきたときに、該第２の暗号情報および該装置署名を受け取る手段と、
   前記装置署名の正当性を検証する手段と、
   前記第２の暗号情報から、前記セッション鍵および前記ランダム数を復号して得る手段と、
   前記セッション鍵に基づき、前記ランダム数を暗号化して第３の暗号情報を生成する手段と、
   前記第３の暗号情報を前記発信先装置に送出する手段と
   を具備することを特徴とするホスト装置。
6. 自装置の新たなローケータの情報に自装置署名を付して発信先装置に送出する手段と、
   自装置の新たなローケータの前記情報に前記自装置署名を付して、自装置のグローバルホスト名を登録解決するサーバである登録解決サーバに送出する手段と
   を具備することを特徴とするホスト装置。

Images