JP5953991B2 - 通信制御方法、通信制御装置、通信機器、及びプログラム - Google Patents

Description

本発明は、通信制御方法、通信制御装置、通信機器、及びプログラムに関する。

ＩＰｖ４では、ＩＰアドレスに用いられるビット桁数の制約より、インターネットに接続される全ての通信機器にグローバルに一意なＩＰアドレスを割り当てることができず、例えば、ＮＡＴ（Network Address Translator）を利用して、グローバルＩＰアドレスとプライベートＩＰアドレスとの変換等が行われている。これにより、個別の機器とＩＰアドレスが一意に対応せず、ＩＰアドレスの匿名性が高くなり、インターネット上における不正行為を助長する原因ともなっていた。

ＩＰｖ６による経路集約可能なグローバルユニキャストアドレスを用いることにより、ＩＰｖ４における上記のような匿名性は払拭される。したがって、不正行為者の特定が、従来に比べて容易となることが期待される。

特開平０６−２５０１０号公報 特開平０８−９８９９０号公報 特開平０５−１５０８８８号公報

しかしながら、ＩＰｖ６を用いた通信であることのみをもって、安全な通信は自動的には保証されない。ＩＰｖ６による通信においても、成りすましや盗聴等の不正行為を完全に防止するのは困難である。

そこで、一側面では、安全性が向上された通信環境を提供することを目的とする。

一つの案では、通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証し、前記電子署名の正当性が検証された通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該第パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する処理をコンピュータが実行する。

一態様によれば、安全性が向上された通信環境を提供することができる。

第一の実施の形態におけるネットワークシステムの構成例を示す図である。 第一の実施の形態における通信制御装置のハードウェア構成例を示す図である。 第一の実施の形態における各装置の機能構成例を示す図である。 ホワイトネットの第一の利用形態の例を示す図である。 ホワイトネットの第二の利用形態の例を示す図である。 現行において採用されているＩＰｖ６のグローバルユニキャストアドレスの体系を示す図である。 ホワイトネットＩＤを説明するための図である。 ＩＰｖ６のグローバルユニキャストアドレスの一般的な体系を示す図である。 第一の実施の形態におけるＩＰアドレスの体系を示す図である。 機器証明書の発行処理の処理手順の一例を説明するためのフローチャートである。 機器証明書の構成例を示す図である。 ホワイトネットを利用した通信処理の一連の手順を説明するための図である。 通信機器の認証処理の一例を説明するためのシーケンス図である。 ホワイトネットを介したデータ通信の処理手順の一例を説明するためのシーケンス図である。 ホワイトネットでの再認証処理の処理手順の一例を説明するためのシーケンス図である。 通信制御装置が実行する処理手順の一例を説明するためのフローチャートである。 認証受付処理の処理手順の一例を説明するためのフローチャートである。 セッション情報記憶部の構成例を示す図である。 認証データ検証処理の処理手順の一例を説明するためのフローチャートである。 ルーティング処理の処理手順の一例を説明するためのフローチャートである。 ルーティングポリシー記憶部の構成例を示す図である。 ルーティング情報記憶部の構成例を示す図である。 第二の実施の形態におけるネットワークシステムの構成例を示す図である。 第二の実施の形態における各装置の機能構成例を示す図である。 サブネット証明書の取得処理の処理手順の一例を説明するためのフローチャートである。 ＣＳＲの構成例を示す図である。 サブネット証明書の構成例を示す図である。 ＳＳＬハンドシェイクの処理手順の一例を説明するためのシーケンス図である。 サブネット証明書に基づくサーバ認証の処理手順の一例を説明するためのフローチャートである。 通信機器とサーバ装置との間の通信処理の処理手順の一例を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態におけるネットワークシステムの構成例を示す図である。図１において、通信機器２０ａ、２０ｂ、及び２０等の複数の通信機器２０と、通信制御装置１０と、証明書発行装置３０とは、ネットワークＮ１を介して通信可能とされている。ネットワークＮ１は、例えば、インターネットへのアクセス網又はアクセス回線である。ネットワークＮ１の具体例として、ＮＧＮ（Next Generation Network）又は移動体通信網等が挙げられる。

すなわち、通信制御装置１０は、例えば、各通信機器２０とインターネットとの間に設置される。但し、通信制御装置１０と各通信機器２０との間にインターネットが介在してもよい。また、証明書発行装置３０と各通信機器２０との間にもインターネットが介在してもよい。通信制御装置１０の管理者又は運用者としては、例えば、ＩＳＰ（Internet Service Provider）又はＶＮＥ(Virtual Network Enabler)等が挙げられる。証明書発行装置３０の管理者又は運用者としては、例えば、ＩＳＰや認証局（ＣＡ（Certificate Authority））等が挙げられる。本実施の形態において、通信制御装置１０及び証明書発行装置３０は、説明の便宜上、同一のＩＳＰによって管理及び運用されることとする。

通信機器２０は、IPｖ６によって通信可能な各種の通信機器２０である。すなわち、本実施の形態では、基本的に、通信プロトコルとしてＩＰｖ６が使用される。通信機器２０としては、ＰＣ（Personal Computer）、スマートフォン、携帯電話、タブレット型端末、ＰＤＡ（Personal Digital Assistance）、デジタル家電等、通信機能を有する各種の電子機器が含まれる。

通信制御装置１０は、ＩＳＰの顧客（加入者）に対して、安全なネットワークドメインを提供するための処理を実行するコンピュータ又はネットワーク機器である。安全なネットワークドメインとは、身元が保証されたユーザの通信機器２０のみが接続可能な仮想的又は論理的なサブネット又はネットワークセグメントをいう。以下、安全なネットワークドメイを、便宜上「ホワイトネット」という。ホワイトネットの詳細については、後述される。なお、複数のコンピュータが通信制御装置１０を構成してもよい。すなわち、通信制御装置１０が実行する機能は、複数のコンピュータに分散された実現されてもよい。

証明書発行装置３０は、通信機器２０がホワイトネットへ接続するために必要とされる公開鍵証明書を生成及び発行するコンピュータである。すなわち、或るホワイトネットへ接続する通信機器２０は、当該通信機器２０の身元を証明する公開鍵証明書を有している必要がある。以下、通信機器２０ごとに発行される公開鍵証明書を、「機器証明書」という。

図２は、第一の実施の形態における通信制御装置のハードウェア構成例を示す図である。図２の通信制御装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

通信制御装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って通信制御装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

なお、証明書発行装置３０や通信機器２０も、図２と同様のハードウェア構成を有していてもよい。但し、通信機器２０は、液晶ディスプレイ等の表示装置や、キーボード、マウス、ボタン、又はタッチパネル等の入力装置等を備えていてもよい。

図３は、第一の実施の形態における各装置の機能構成例を示す図である。図３において、証明書発行装置３０は、証明書発行部３１及び確認情報記憶部３２等を有する。証明書発行部３１は、機器証明書の発行処理を実行する。証明書発行部３１は、例えば、証明書発行装置３０にインストールされたプログラムが、証明書発行装置３０のＣＰＵに実行させる処理により実現される。

確認情報記憶部３２は、機器証明書の発行対象となる通信機器２０の身元等を確認するための情報を記憶する。確認情報記憶部３２は、例えば、証明書発行装置３０が有する補助記憶装置、又は証明書発行装置３０にネットワークを介して接続される記憶装置等を用いて実現可能である。

通信機器２０は、通信制御部２１を有する。通信制御部２１は、通信機器２０にインストールされたプログラムが、通信機器２０のＣＰＵに実行させる処理により実現される。通信機器２０は、また、機器証明書記憶部２２を有する。機器証明書記憶部２２は、例えば、通信機器２０が有する補助記憶装置等を用いて実現可能である。

機器証明書記憶部２２は、当該通信機器２０に対して発行された機器証明書を記憶する。機器証明書記憶部２２には、また、機器証明書に含まれている公開鍵に対応する秘密鍵も記憶される。

通信制御部２１は、通信制御装置１０や他の通信機器２０等との通信を制御するための処理を実行する。通信制御部２１は、ホワイトネットへの接続の際に、機器証明書記憶部２２に記憶されている機器証明書や秘密鍵等を用いて、自らの正当性を証明するための処理を実行する。

通信制御装置１０は、認証要求受付部１１、認証データ検証部１２、ルーティング部１３、及び再認証要求部１４等を有する。これら各部は、通信制御装置１０にインストールされたプログラムがＣＰＵ１０４に実行させる処理により実現される。

通信制御装置１０は、また、証明書リスト記憶部１５、セッション情報記憶部１６、ルーティングポリシー記憶部１７、及びルーティング情報記憶部１８等を利用する。これら各記憶部は、補助記憶装置１０２、又は通信制御装置１０にネットワークを介して接続される記憶装置等を用いて実現可能である。

認証要求受付部１１は、ホワイトネットへ接続するための認証要求を通信機器２０より受信する。認証データ検証部１２は、認証要求に係る通信機器２０より当該通信機器２０の正当性等を示す認証データを受信し、当該認証データの検証を、証明書リスト記憶部１５に記憶されている機器証明書等を用いて実行する。証明書リスト記憶部１５は、各通信機器２０に対して発行されている機器証明書を記憶する。

ルーティング部１３は、認証データが検証された、すなわち、正当性が確認された通信機器２０に関して、当該通信機器２０からのパケットのルーティングを行う。ルーティングは、ルーティングポリシー記憶部１７が記憶するルーティングポリシーによって制限される。ルーティングポリシーは、送信元と宛先との組み合わせに応じて、ルーティングの可否を示す情報である。ルーティング部１３は、また、ルーティング情報記憶部１８を利用する。ルーティング情報記憶部１８は、宛先に応じて、出力先のポートを識別する情報等を記憶する。

再認証要求部１４は、所定のタイミングで、再認証を受けることの要求（再認証要求）を、通信機器２０に送信する。再認証要求を受信した通信機器２０は、改めて、ホワイトネットへ接続するための認証要求を通信制御装置１０に送信する。

続いて、ホワイトネットの詳細について説明する。例えば、ホワイトネットの利用形態の一例として、例えば、図４又は図５のような形態が挙げられる。

図４は、ホワイトネットの第一の利用形態の例を示す図である。図４では、企業ごとに、仮想的なイントラネットとしてホワイトネットが利用される形態が示されている。

図４において、ホワイトネットＷＮ１、ＷＮ２、及びＷＮ３のそれぞれは、企業Ａ、企業Ｂ、又は企業Ｃの仮想的なイントラネットである。この場合、たとえば、企業Ａの社員は、自宅や外出先等から、通信機器２０を利用して、ホワイトネットＷＮ１に接続することができる。また、企業Ａの既存の物理的なイントラネットＰＮ１に接続している各通信機器２０も、ホワイトネットＷＮ１に接続することができる。但し、企業Ａの社員以外の者が利用する通信機器２０に関しては、ホワイトネットＷＮ１への接続を拒否することができる。したがって、ホワイトネットＷＮ１は、企業Ａの社員のみが接続可能な安全なネットワークとなる。

なお、企業内の部署ごとに、別々のホワイトネットが形成されることも考えられる。

また、図５は、ホワイトネットの第二の利用形態の例を示す図である。図５では、一つの製造メーカにおいて、製品の型番ごとにホワイトネットが割り当てられる例が示されている。例えば、ホワイトネットＷＮａは、テレビとしての製品Ａのみの接続が許可されるホワイトネットである。ホワイトネットＷＮｂ、ＷＮｃ、及びＷＮｄは、それぞれ、製品Ｂ、製品Ｃ、又は製品Ｄのみの接続が許可されるホワイトネットである。

例えば、市場において販売され、各家庭又は企業等で利用されている製品Ａは、その起動時にホワイトネットＷＮａに接続される。この場合、当該製造メーカは、製品Ａに関してソフトウェアのアップデート等の保守サービスの実施が必要となったときに、当該保守サービスを容易に行うことができる。ホワイトネットＷＮａに接続された通信機器２０をアップデート等の保守サービスの対象として限定することができるからである。

なお、ホワイトネットの利用形態又は用途は、図４又は図５に示されるものに限られない。

ところで、現行において一般的に採用されているＩＰｖ６のグローバルユニキャストアドレスの形式は、図６に示される通りである。「現行において一般的に採用されている」とは、既に構築されているＩＰｖ６ネットワークにおいて採用されているということを含む。

図６は、現行において採用されているＩＰｖ６のグローバルユニキャストアドレスの体系を示す図である。図６では、ＲＦＣ３５８７に記載されているグローバルユニキャストアドレス（以下、単に「ＩＰアドレス」という。）の体系が示されている。ここで、先頭の４９ビット目からの１６ビットは、サブネットごとの識別領域である。すなわち、当該識別領域にはサブネットごとの識別子であるサブネットＩＤが格納される。したがって、現行において採用されているＩＰｖ６のグローバルユニキャストアドレスでは、先頭から６４ビットによって、各サブネットは区別される。

一方、後半の６４ビットは、ＭＡＣアドレスが割り当てられるネットワークインタフェースごとの識別領域である。すなわち、当該識別領域には、ネットワークインタフェースごとの識別子であるインタフェースＩＤが格納される。

例えば、ＩＳＰは、企業ユーザ等の加入者組織に対して、先頭から４８ビットまでを割り当てる。この場合、加入者組織は、最大で下位の８０ビット分を、自由に利用可能となる。

上記したように、一つのホワイトネットは、一つのサブネットである。したがって、仮に、ホワイトネットを図６に示されるアドレス体系に従って割り当てるとすると、一加入者組織は、最大でサブネットＩＤの１６ビット分、すなわち、６５５３６個のホワイトネットを所有することができる。６５５３６個という数は、例えば、図４のような利用形態であれば十分であるかもしれないが、図５のような利用形態を考慮すると、枯渇する虞がある。すなわち、図５のような利用形態では、製品の型番ごとにホワイトネットが割り当てられる。型番は、モデルチェンジが行われるたびに新しい値が割り当てられる。また、旧モデルについても保守サービスを考慮すると、既存の型番を無効とすることは困難である。したがって、一つの製造メーカが、６５５３６以上の型番を有するのは容易に想像できる。そうすると、一加入者組織に対して、１６ビット分のサブネットでは不十分である可能性が高い。

そこで、本実施の形態では、図７に示されるように、インタフェースＩＤの一部をも利用して、ホワイトネットを区別可能とする。換言すれば、サブネットＩＤに加え、インタフェースＩＤの一部の領域が、ホワイトネットの識別子（以下「ホワイトネットＩＤ」という。）を格納するための領域として用いられる。

図７は、ホワイトネットＩＤを説明するための図である。図７に示されるように、本実施の形態では、サブネットＩＤに加えて、インタフェースＩＤの上位の一部が、ホワイトネットＩＤとして利用される。換言すれば、サブネットの識別領域、インタフェースＩＤの上位の一部まで拡張される。なお、サブネットを識別する部分が拡張された分、インタフェースの識別領域は、削減される。

サブネットの識別領域の拡張の程度は、例えば、加入者組織へのＩＰアドレスの割り当ての際に、決定されてもよい。なお、ＩＰアドレスの先頭からホワイトネットＩＤの末尾までのビット長を、以下、「サブネットマスク」という。

一方、ＩＰｖ６のグローバルユニキャストアドレスの一般的な体系は、ＲＦＣ３５１３において、図８に示されるように規定されている。

図８は、ＩＰｖ６のグローバルユニキャストアドレスの一般的な体系を示す図である。図８に示されるように、ＲＦＣ３５１３においては、グローバルルーティングプレフィックス、サブネットＩＤ、及びインタフェースＩＤの長さが、これらの合計が１２８ビット以内である範囲おいて、可変とされている。すなわち、各要素間の双方向の矢印は、当該矢印に係る要素間の境界が移動可能であることを示す。

したがって、ＲＦＣ３５１３に従えば、サブネットＩＤを、１６ビット以上の任意の長さに拡張することができる。その結果、上記におけるホワイトネットＩＤの目的を達成可能なサブネットＩＤを定義することが可能となる。

但し、現時点において、ＲＦＣ３５１３のような、各要素が可変なＩＰアドレスに関する運用等に関しては、明確にされていない。また、既に構築されているＩＰｖ６ネットワークにおいては、図６において説明したアドレス体系が採用されている。

そこで、本実施の形態では、既に構築されているＩＰｖ６ネットワークにおけるアドレス体系との互換性、及びＲＦＣ３５１５との互換性の双方を満たすように、図９に示されるようなアドレス体系を採用する。

図９は、第一の実施の形態におけるＩＰアドレスの体系を示す図である。図９に示されるように、本実施の形態では、サブネットＩＤとインタフェースＩＤとの間に、プライベートＩＤが設けられる。プライベートＩＤは、サブネットＩＤとの組み合わせにより、ホワイトネットＩＤを構成する。プライベートＩＤは、図６に示される、ＲＦＣ３５８７に記載された体系に基づく観点によれば、インタフェースＩＤの一部に相当する。また、図８に示されるＲＦＣ３５１５に記載された体系に基づく観点によれば、サブネットＩＤの一部、又はインタフェースＩＤの一部に相当する。

なお、各要素間の双方向の矢印は、当該矢印に係る要素間の境界が固定であることが前提とされないということを示す。すなわち、本実施の形態では、各要素の長さが可変である場合についても考慮される。

但し、本実施の形態では、ＲＦＣ３５８７に記載された体系との互換性を考慮して、グローバルルーティングプレフィックスは４８ビットであり、サブネットＩＤは、１６ビットである場合について説明する。

続いて、ホワイトネットの構築のための準備作業について説明する。例えば、或る加入者組織（以下、「企業Ａ」という。）では、将来的な拡張等を考慮して、加入者組織における通信機器２０の台数から、ＩＰアドレスの利用範囲（割り当て範囲）が、／６４〜／８０の範囲で決定される。／６４は、上位６４ビットまでが決定された値が企業Ａに対して割り当てられることを意味する。したがって、この場合、企業Ａは、下位６４ビットを自由に利用することができる。また、／８０は、先頭から８０ビットまでが決定された値が企業Ａに対して割り当てられることを意味する。したがって、この場合、企業Ａは、下位４８ビットを自由に利用することができる。

続いて、企業Ａは、ホワイトネットの利用形態に鑑みて、必要なホワイトネットの本数を決定し、サブネットマスクを決定する。割り当て範囲が／６４である場合、サブネットマスクが／８０であれば、ホワイトネットＩＤのビット長は、サブネットＩＤの１６ビット＋プライベートＩＤの１６ビット（インタフェースＩＤの上位１６ビット）の３２ビットとなる。この場合、最大で４２億９４９６万７２９６本のホワイトネットを割り当てることができる。また、２８１兆４７４９億７６７１万６５６個のＩＰアドレスを確保することができる。

上記の決定事項のうち割り当て範囲は、例えば、企業ＡからＩＳＰに対して申請される。但し、ＩＳＰが、企業Ａにおけるネットワーク構成の構想を聴取して、ＩＳＰが、企業Ａに適した割り当て範囲及びサブネットマスクを決定してもよい。また、企業Ａは、ホワイトネットに接続を許可する通信機器２０ごとに、当該通信機器２０及びその利用者を特定可能な情報（以下、「機器情報」という。）を、ＩＳＰに対して申請する。当該情報には、例えば、通信機器２０のＭＡＣアドレス、ＢＩＯＳ（Basic Input/Output System）シリアル番号、ＯＳ（Operating System）シリアル番号、及び利用者氏名等が含まれる。但し、利用者氏名は、必ずしも含まれなくてもよい。また、ＢＩＯＳの起動シリアル番号及びＯＳシリアル番号も含まれなくてもよい。

ＩＳＰは、上記申請を受けると、申請された割り当て範囲に対応したＩＰアドレス群を用意する。用意されたＩＰアドレス群は、例えば、企業Ａに対する加入者ＩＤに対応付けられて管理される。加入者ＩＤとは、ＩＳＰが各加入者を識別するための識別情報である。割り当て範囲が／６４である場合、例えば、「２００１：０ｄｂ８：ａａａａ：００００：００００：０００：００００：０００１〜２００１：０ｄｂ８：ａａａａ：ｆｆｆｆ：ｆｆｆｆ：ｆｆｆｆｆ：ｆｆｆｆｆ：ｆｆｆｆｆ」の範囲のＩＰアドレスが用意される。

また、ＩＳＰは、通信機器２０ごとに申請された機器情報を、証明書発行装置３０に設定しておく。設定された機器情報は、確認情報記憶部３２に記憶される。

続いて、企業Ａは、ホワイトネットへの接続を許可する通信機器２０ごとに、公開鍵暗号方式における公開鍵と秘密鍵とのペアを生成する。少なくとも秘密鍵は、各通信機器２０の記憶装置に安全に保存される。

以上によって、企業Ａが、各通信機器２０に関して機器証明書の発行を受けるための準備作業が完了する。

続いて、企業Ａは、例えば、非図示のＰＣ（Personal Computer）等の情報処理装置を利用して、ホワイトネットへの接続を許可する各通信機器２０に対する機器証明書の発行要求を、証明書発行装置３０に送信する。当該発行要求に応じて、証明書発行装置３０が実行する処理について説明する。

図１０は、機器証明書の発行処理の処理手順の一例を説明するためのフローチャートである。

証明書発行装置３０の証明書発行部３１は、機器証明書の発行要求の受信を待機している（Ｓ１１）。機器証明書の発行要求が受信されると、証明書発行部３１は、当該発行要求の内容を、確認情報記憶部３２が記憶する機器情報と照合することにより、当該発行要求の正当性を確認する（Ｓ１２）。具体的には、機器証明書の発行要求には、企業Ａの加入者ＩＤ、機器証明書の発行対象の通信機器２０の機器情報（ＭＡＣアドレス、ＢＩＯＳシリアル番号、ＯＳシリアル番号、利用者氏名）、公開鍵、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスク等が指定される。グローバルルーティングプレフィックスマスクは、ＩＰアドレスの先頭からのグローバルルーティングプレフィックスのビット長である。サブネットＩＤマスクは、グローバルルーティングプレフィックスマスクに続くサブネットＩＤのビット長である。プライベートＩＤマスクは、サブネットＩＤに続くプライベートＩＤのビット長である。本実施の形態では、これらのビット長が固定であるという前提は排除されているため、これらのビット長の指定が必要とされる。

確認情報記憶部３２が記憶する機器情報のうち、受信された発行要求に指定された加入者ＩＤに対応付けられている機器情報のいずれかと、当該発行要求に指定された機器情報が一致する場合、証明書発行部３１は、当該発行要求は正当であると判定する。すなわち、当該発行要求は、ホワイトネットへの接続が許可されるべき、実在する通信機器２０に対する発行要求であることが確認される。一方、確認情報記憶部３２が記憶する機器情報のうち、受信された発行要求に指定された加入者ＩＤに対応付けられている機器情報のいずれとも、当該発行要求に指定された機器情報が一致しない場合、証明書発行部３１は、当該発行要求は不正であると判定する。

このように、確認情報記憶部３２に記憶される機器情報は、機器証明書の発行要求の正当性の判定に利用される。したがって、例えば、企業Ａ以外の信頼できる者から確認情報記憶部３２に記憶される機器情報が入手されるようにしてもよい。機器情報の入手先となりうる者としては、例えば、企業Ａに対する通信機器２０の販売者が一例として挙げられる。例えば、当該販売者は、ＩＳＰからの要請に応じ、企業Ａに対して販売した各通信機器２０の機器情報を、ＩＳＰに提供する。ＩＳＰは、提供された機器情報を確認情報記憶部３２に設定する。

確認情報記憶部３２に記憶される機器情報の入手先が、機器証明書の発行要求元と異なることで、確認情報記憶部３２の信頼性を高めることができる。例えば、受信される発行要求が、企業Ａには存在しない通信機器２０に対する発行要求であることを検知できる可能性を高めることができる。

受信された発行要求が不正であると判定された場合（Ｓ１３でＮｏ）、証明書発行部３１は、エラー情報を返信し（Ｓ１４）、当該発行要求に応じた処理を終了させる。すなわち、この場合、機器証明書の発行は行われない。

一方、受信された発行要求が正当であると判定された場合（Ｓ１３でＹｅｓ）、証明書発行部３１は、発行対象の通信機器２０に対する機器証明書を生成する（Ｓ１５）。

図１１は、機器証明書の構成例を示す図である。図１１に示される機器証明書は、Ｘ５０９ ｖ３フォーマットに準拠したものであるため、基本的なフィールドの説明は省略する。なお、発行要求に指定された、通信機器２０の公開鍵は、ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏフィールドに格納される。

ｅｘｔｅｎｓｉｏｎｓフィールドは、Ｘ５０９ ｖ３において定義されている拡張領域である。本実施の形態では、拡張型（ｅｘＩｎｄ）として、ＩＰアドレス（ＩＰｖ６ Ｇｌｏｂａｌ Ｕｎｉｃａｓｔ Ａｄｄｒｅｓｓ）、グローバルルーティングプレフィックスマスク（Ｇｌｏｂａｌ Ｒｏｕｔｉｎｇ Ｐｒｅｆｉｘ Ｍａｓｋ）、サブネットＩＤマスク（Ｓｕｂ−Ｎｅｔ ＩＤ Ｍａｓｋ）、プライベートＩＤマスク（Ｐｒｉｖａｔｅ ＩＤ Ｍａｓｋ）、及びＭａｃアドレス（Ｍａｃ ａｄｄｒｅｓｓ）等が含まれる。これらの拡張型のうち、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、プライベートＩＤマスク、及びＭａｃアドレスの値には、機器証明書の発行要求に指定されている値が格納される。

ＩＰアドレスには、例えば、機器証明書の生成の際に、発行要求に指定された加入者ＩＤに対応付けられているＩＰアドレス群の中から、証明書発行部３１によって割り当てられた値が格納される。但し、ＩＰアドレスは、発行要求に指定されていてもよい。この場合、企業Ａに割り当てられたＩＰアドレス群が予めＩＳＰから通知されていればよい。発行要求にＩＰアドレスが指定されている場合、証明書発行部３１は、当該ＩＰアドレスを機器証明書に格納する。

続いて、証明書発行部３１は、生成された機器証明書を返信する（Ｓ１６）。

企業Ａの情報処理装置において機器証明書が受信されると、企業Ａでは、当該機器証明書に対応する通信機器２０に対して当該機器証明書の保存が行われる。

なお、図１０の処理は、通信機器２０一台ごとに行われてもよいし、複数の通信機器２０に関してまとめて行われてもよい。

企業Ａにおいて機器証明書が保存された通信機器２０は、当該機器証明書に対応するホワイトネットでの通信が可能となる。当該機器証明書に対応するホワイトネットとは、当該機器証明書に記録されているＩＰアドレス、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスクに基づいて特定可能なホワイトネットＩＤによって識別されるホワイトネットをいう。

続いてホワイトネットを利用した通信処理について説明する。図１２は、ホワイトネットを利用した通信処理の一連の手順を説明するための図である。

まず、ホワイトネットへの接続を要求する通信機器２０に関して、通信制御装置１０によって認証処理が実行される（Ｓ１０１）。認証された通信機器２０は、当該通信機器２０の機器証明書に対応するホワイトネットに論理的に収容される。また、認証処理において、暗号通信のための共通鍵が、通信制御装置１０と通信機器２０との間で共有される。

続いて、通常のデータ通信が行われる（Ｓ１０２）。ホワイトネットに収容された通信機器２０のパケットは、通信制御装置１０によってルーティングされる。なお、データ通信において、ホワイトネットの外部へのデータの送信、又はホワイトネットの外部からのデータの受信を許可するか否かは、ホワイトネットごとに設定されるルーティングポリシーに依存する。

データ通信の合間において、所定のタイミングで通信機器２０に関して再認証処理が実行される（Ｓ１０３）。すなわち、通信機器２０の正当性が、例えば、定期的に確認される。データ通信が完了すると、通信機器２０は、ホワイトネットとの接続を切断する（Ｓ１０４）。

続いて、ステップＳ１０１の詳細について説明する。図１３は、通信機器の認証処理の一例を説明するためのシーケンス図である。

ステップＳ１１１において、通信機器２０の通信制御部２１は、認証要求を示すパケットを通信制御装置１０に送信する。認証要求を示すパケット（以下、単に、「認証要求」という。）とは、例えば、認証要求であることを示す情報が含まれているパケットをいう。通信制御装置１０において認証要求が受信されると、認証要求受付部１１は、認証要求の送信元ＩＰアドレスに対応付けられている機器証明書を、証明書リスト記憶部１５より取得する。認証要求受付部１１は、また、認証要求が受信された時刻を示す時刻情報を記憶しておく。

なお、該当する機器証明書が証明書リスト記憶部１５に記憶されていない場合、認証要求受付部１１は、認証要求元の通信機器２０に対する機器証明書をネットワークを介して取得してもよい。例えば、当該通信機器２０に対して機器証明書の送信が要求されたり、又は機器証明書が公開されているサイトに対して、認証要求の送信元ＩＰアドレスに対する機器証明書の取得が要求されたりすることにより、該当する機器証明書が取得されてもよい。取得された機器証明書は、機器証明書記憶部２２に記憶される。また、ステップＳ１１１の認証要求に、認証要求元の通信機器２０の機器証明書が指定されるようにしてもよい。

続いて、認証要求受付部１１は、通信機器２０との認証処理ごとに一意な暗号用共通鍵を生成し、当該暗号用共通鍵を、通信機器２０の機器証明書に含まれている公開鍵で暗号化する。また、認証要求受付部１１は、チャレンジワード又はチャレンジフレーズ（以下、「チャレンジワード」という。）をランダムに生成し、チャレンジワードと、暗号化された暗号用共通鍵とを含む認証要求応答パケットを、認証要求の送信元ＩＰアドレス宛に返信する（Ｓ１１２）。チャレンジワードは、ランダムな文字列である。

通信機器２０において認証要求応答パケットが受信されると、通信制御部２１は、認証要求応答パケットに含まれている、暗号化された暗号用共通鍵を、当該通信機器２０の秘密鍵で復号する。仮に、なりすまし等で不正な通信機器２０が認証要求応答パケットを受信した場合、当該通信機器２０は、暗号化された暗号用共通鍵を復号可能な秘密鍵を有していない。したがって、当該通信機器２０は、暗号化された暗号用共通鍵を復号することが出来ず、暗号用共通鍵の漏洩が防止される。復号された暗号用共通鍵は、例えば、セッションが有効な間、安全な場所に保存され、セッション終了時に破棄される。

通信制御部２１は、また、チャレンジワードを暗号用共通鍵で暗号化し、暗号化されたチャレンジワードに対する電子署名を生成する。当該電子署名は、暗号化されたチャレンジワードのハッシュ値を、当該通信機器２０の秘密鍵によって暗号化することにより生成される。更に、通信制御部２１は、現在時刻のタイムスタンプを、例えば、第三者認証機関より取得する。

続いて、通信制御部２１は、暗号化されたチャレンジワード、電子署名、及びタイムスタンプ等の認証データを含むパケット（以下、「認証データパケット」という。）を通信制御装置１０に送信する（Ｓ１１３）。

通信制御装置１０において、認証データパケットが受信されると、認証データ検証部１２は、認証データを検証する。具体的には、認証データ検証部１２は、認証データに含まれているタイムスタンプが示す時刻と、認証要求の受信に応じて記憶されている時刻情報が示す時刻との間の経過時間の妥当性について検証する。当該経過時間が所定値未満である場合、認証データ検証部１２は、当該経過時間は妥当であると判定する。この判定は、認証データが不正に横取りされてしまったことを検知するためのものである。仮に、不正な横取りが行われ、横取りした者から認証データが送信された場合、当該経過時間は長くなる可能性が高いからである。

認証データ検証部１２は、また、認証データに含まれている電子署名を、機器証明書等を用いて検証する。認証データ検証部１２は、また、認証データに含まれているチャレンジワードを暗号用共通鍵で復号し、復号結果が、送信したチャレンジワードと一致するか否かを検証する。認証データ検証部１２は、更に、認証データパケットの送信元ＩＰアドレスと、ステップＳ１１１に応じて取得された機器証明書に含まれているＩＰアドレスとを比較する両者が一致する場合、認証データパケットの送信元ＩＰアドレスは正しいと判定される。

要するに、電子署名の検証によって、通信機器２０が成りすまされていないことが検証される。また、チャレンジワードが復号されることにより、暗号用共通鍵が安全に通信機器２０に転送されたことが検証される。送信元ＩＰアドレスと機器証明書内のＩＰアドレスとの比較によって、通信機器２０のＩＰアドレスの正当性が検証される。

電子署名、チャレンジワード、及び送信元ＩＰアドレスの全ての正当性が検証されると、認証データ検証部１２は、通信機器２０を、当該通信機器２０の機器証明書に対応するホワイトネットに収容する。すなわち、当該通信機器２０は、当該ホワイトネットへの接続が許可される。そこで、認証要求部は、ホワイトネットへの接続の許可を示す接続許可応答を、認証データパケットの送信元ＩＰアドレス宛に返信する（Ｓ１１４）。

続いて、図１２のステップＳ１０２の詳細について説明する。図１４は、ホワイトネットを介したデータ通信の処理手順の一例を説明するためのシーケンス図である。図１４では、通信機器２０ａと通信機器２０ｂとの間で通信が行われる例を説明する。通信機器２０ａ及び通信機器２０ｂは、それぞれ、図１３の処理の実行により、同一のホワイトネット、又は相互に異なるホワイトネットに収容されていることとする。

ステップＳ１２１において、通信機器２０ａの通信制御部２１ａは、通信機器２０ｂ宛への通信データを暗号鍵ａによって暗号化する。暗号鍵ａは、図１３のステップＳ１１２において通信制御装置１０より受信した暗号用共通鍵である。続いて、通信制御部２１ａは、暗号化された通信データを含むパケットを、通信機器２０ｂのＩＰアドレス宛に送信する（Ｓ１２２）。

当該パケットは、ネットワークＮ１を介して通信制御装置１０によって受信される。通信制御装置１０のルーティング部１３は、通信機器２０ａからのパケットに含まれている通信データを、暗号鍵ａによって復号する（Ｓ１２３）。続いて、ルーティング部１３は、当該パケットの宛先ＩＰアドレスに対応する、通信機器２０ｂに対する暗号用共通鍵（以下、「暗号鍵ｂ」という。）によって、復号された通信データを暗号化する（Ｓ１２４）。すなわち、通信制御装置１０には、図１３の認証処理を経てホワイトネットに収容された各通信機器２０に対して生成された暗号用共通鍵が、例えば、各通信端末のＩＰアドレスに対応付けられて補助記憶装置１０２に記憶されている。

続いて、ルーティング部１３は、暗号鍵ｂによって暗号化された通信データを含むパケットを、ネットワークＮ１を介して通信機器２０ｂ宛に転送する（Ｓ１２５）。

なお、厳密には、ルーティング部１３は、ルーティングポリシーに従って、通信機器２０ａから通信機器２０ｂへのルーティング（通信データの転送）の可否の判定をも行うが、この点については後述される。

通信機器２０ｂの通信制御部２１ｂは、通信データを受信すると、当該通信データを暗号鍵ｂによって復号する（Ｓ１２６）。通信機器２０ｂについても、図１３のステップＳ１１２において、通信制御装置１０より暗号鍵ｂが受信されている。なお、通常、暗号鍵ａと暗号鍵ｂとは異なる暗号鍵である。ステップＳ１１２に関して説明したように、暗号用共通鍵は、認証処理ごとに生成されるからである。

続いて、通信機器２０ｂは、例えば、復号された通信データを利用した処理を実行する。続いて、通信制御部２１ｂは、受信された通信データに対応する応答データを、暗号鍵ｂによって暗号化する（Ｓ１２７）。応答データは、例えば、通信機器２０ｂによる処理結果を示すデータであってもよいし、通信データを受信できたことを示すデータであってもよい。続いて、通信制御部２１ｂは、暗号化された応答データを含むパケットを、通信機器２０ａのＩＰアドレス宛に返信する（Ｓ１２８）。

当該パケットは、ネットワークＮ１を介して通信制御装置１０によって受信される。通信制御装置１０のルーティング部１３は、当該パケットに含まれている応答データを、当該パケットの送信元ＩＰアドレスに対応付けられている暗号鍵ｂによって復号する（Ｓ１２９）。続いて、ルーティング部１３は、当該パケットの宛先ＩＰアドレスに対応する、通信機器２０ａに対する暗号鍵ａによって、復号された応答データを暗号化する（Ｓ１３０）。続いて、ルーティング部１３は、暗号鍵ａによって暗号化された応答データを含むパケット、ネットワークＮ１を介して通信機器２０ａ宛に転送する（Ｓ１３１）。

通信機器２０ａの通信制御部２１ａは、応答データを受信すると、当該応答データを暗号鍵ａによって復号する（Ｓ１３２）。通信機器２０ａは、例えば、復号された応答データを利用した処理を実行する。

このように、各通信機器２０と通信制御装置１０との間の通信は、各通信機器２０の認証処理ごとの暗号用共通鍵によって暗号化される。したがって、データ通信に関して高い安全性が確保される。また、通信機器２０ごとの暗号用共通鍵による通信は、通信制御装置１０によって仲介される。したがって、通信機器２０同士で暗号用共通鍵を交換する必要はない。すなわち、各通信機器２０は、通信相手に応じて使用する暗号用共通鍵を切り替える必要はない。

続いて、図１２のステップＳ１０３の詳細について説明する。図１５は、ホワイトネットでの再認証処理の処理手順の一例を説明するためのシーケンス図である。

例えば、通信機器２０の通信制御部２１が、通信データを含むパケットを送信する（Ｓ１４１）。ステップＳ１４１は、図１４におけるステップＳ１２２と同様の処理である。通信制御装置１０の再認証要求部１４は、当該パケットを受信すると、当該パケットの送信元ＩＰアドレスに係るセッションはタイムアウトであるか否かを判定する。例えば、当該セッションに関して、最後の通信時刻から所定時間経過しているか否かが判定される。なお、図１４においては、便宜上省略されたが、通信機器２０からのパケットが受信されるたびに、斯かる判定が行われる。

再認証要求部１４は、タイムアウトであることを検知すると、送信元ＩＰアドレス宛に再認証要求を送信する（Ｓ１４２）。通信機器２０の通信制御部２１は、再認証要求に応じ、図１３において説明した認証処理を開始する（Ｓ１４３）。

続いて、図１２〜図１５おいて説明した処理において、通信制御装置１０が実行する処理について更に詳しく説明する。

図１６は、通信制御装置が実行する処理手順の一例を説明するためのフローチャートである。

通信制御装置１０は、パケットの受信を待機している。受信されたパケットが認証要求である場合（Ｓ２０１でＹｅｓ）、認証要求受付部１１は、認証要求受付処理を実行する（Ｓ２０２）。受信されたパケットが認証データを含むパケットである場合（Ｓ２０３でＹｅｓ）、認証データ検証部１２は、認証データ検証処理を実行する（Ｓ２０４）。

受信されたパケットが、通信データを含むパケット、すなわち、通信制御装置１０以外を宛先とするパケットである場合（Ｓ２０５でＹｅｓ）、再認証要求部１４は、当該パケットの送信元ＩＰアドレスに関するセッションについて、タイムアウトであるか否かを判定する（Ｓ２０６）。タイムアウトでない場合（Ｓ２０６でＮｏ）、ルーティング部１３は、当該パケットに関してルーティング処理を実行する（Ｓ２０７）。タイムアウトである場合（Ｓ２０６でＹｅｓ）、再認証要求部１４は、再認証要求を、当該パケットの送信元ＩＰアドレス宛に送信する（Ｓ２０８）。

続いて、ステップＳ２０２の詳細について説明する。図１７は、認証受付処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２１１において、認証要求受付部１１は、送信元ＩＰアドレスを認証要求より取得する。続いて、認証要求受付部１１は、送信元ＩＰアドレスに対応する機器証明書を、証明書リスト記憶部１５より取得する（Ｓ２１２）。該当する機器証明書の取得に失敗した場合（Ｓ２１３でＮｏ）、認証要求受付部１１は、エラー処理を実行する（Ｓ２１９）。例えば、再認証要求が送信元ＩＰアドレス宛に送信される。または、当該通信機器２０から、又は機器証明書が公開されているサイトから、当該送信元ＩＰアドレスに対する機器証明書が取得されてもよい。機器証明書が取得された場合、ステップＳ２１４以降が実行されてもよい。

一方、該当する機器証明書の取得に成功した場合（Ｓ２１３でＹｅｓ）、認証要求受付部１１は、通信機器２０とのセッションごとに一意な暗号用共通鍵を生成する（Ｓ２１４）。続いて、認証要求受付部１１は、セッションごとに一意なチャレンジワードを生成する（Ｓ２１５）。続いて、認証要求受付部１１は、ステップＳ２１２において取得された機器証明書に格納されている公開鍵によって、暗号用共通鍵を暗号化する（Ｓ２１６）。続いて、認証要求受付部１１は、暗号化された暗号用共通鍵及びチャレンジワード等を含む認証要求応答パケットを、認証要求の送信元ＩＰアドレス宛に送信する（Ｓ２１７）。

続いて、認証要求受付部１１は、セッション情報記憶部１６に、認証要求元の通信機器２０に対応するレコードを生成し、当該レコードに、当該通信機器２０に関するセッション情報を記憶する（Ｓ２１８）。

図１８は、セッション情報記憶部の構成例を示す図である。図１８に示されるように、セッション情報記憶部１６は、セッションごとに、サブネットアドレス、セッションＩＤ、接続元ＩＰ、接続先ＩＰ、ステータス、暗号用共通鍵、チャレンジワード、認証要求時刻、及び最終応答時刻等を記憶する。

サブネットアドレスは、当該セッションに係る通信機器２０が接続するホワイトネットのアドレスである。すなわち、サブネットアドレスは、当該通信機器２０のＩＰアドレスにおいて、サブネットマスクに対応する部分である。サブネットマスクの範囲には、グローバルルーティングプレフィックス、サブネットＩＤ、及びプライベートＩＤが含まれる。

セッションＩＤは、セッションごとに割り当てられる識別子である。接続元ＩＰは、当該セッションの接続元の通信機器２０のＩＰアドレスである。接続先ＩＰは、図１４において説明したデータ通信においては、接続元ＩＰに係る通信機器２０ａが、接続先としている通信機器２０ｂのＩＰアドレスである。ステータスは、当該セッションの状態である。暗号用共通鍵は、当該セッションに係る通信機器２０と通信制御装置１０との間の通信において使用される暗号用共通鍵である。チャレンジワードは、当該セッションに関して生成されたチャレンジワードである。認証要求時刻は、認証要求が受信された時刻である。最終応答時刻は、当該セッションに係る通信機器２０からの要求に対して、最後に応答が返信された時刻である。

ステップＳ２１８では、新たに生成されたレコードに対し、サブネットアドレス、セッションＩＤ、接続元ＩＰ、ステータス、暗号用共通鍵、及びチャレンジワード等が記憶される。サブネットアドレスは、ステップＳ２１２において取得された機器証明書（図１１）に格納されている、ＩＰアドレス、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスクに基づいて導出可能である。セッションＩＤには、セッションごとに生成される一意な値が記憶される。接続元ＩＰには、認証要求の送信元ＩＰアドレスが記憶される。ステータスには、「初期化中」が記憶される。暗号用共通鍵には、ステップＳ２１４において生成された暗号用共通鍵が記憶される。チャレンジワードには、ステップＳ２１５において生成されたチャレンジワードが記憶される。認証要求時刻には、現在時刻が記憶される。

続いて、図１６におけるステップＳ２０４の詳細について説明する。図１９は、認証データ検証処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２２１において、認証データ検証部１２は、認証データを含むパケットより送信元ＩＰアドレスを取得する。続いて、認証データ検証部１２は、送信元ＩＰアドレスに対応する機器証明書を、証明書リスト記憶部１５より取得する（Ｓ２２２）。該当する機器証明書の取得に成功した場合（Ｓ２２３でＹｅｓ）、認証データに含まれているタイムスタンプに基づいて、認証要求が受信されてから認証データが受信されるまでの経過時間を算出する（Ｓ２２４）。当該経過時間は、ステップＳ２２１において取得された送信元ＩＰアドレスを接続元ＩＰとして含む、セッション情報記憶部１６レコードの認証要求受信時刻と、タイムスタンプが示す時刻との差分を求めることにより算出可能である。

続いて、認証データ検証部１２は、算出された経過時間が所定値未満であるか否かを判定する（Ｓ２２５）。当該経過時間が所定値未満である場合（Ｓ２２５でＹｅｓ）、認証データ検証部１２は、認証データに含まれている電子署名を検証する（Ｓ２２６）。電子署名の検証は、ステップＳ２２２において取得された機器証明書に含まれている公開鍵を用いて行われる。すなわち、電子署名を当該公開鍵によって復号した結果と、認証データパケットの送信元ＩＰアドレスに対応付けられてセッション情報記憶部１６に記憶されているチャレンジワードのハッシュ値とが一致すれば、電子署名は正しいと判定される。

電子署名が正しい場合（Ｓ２２７でＹｅｓ）、認証データ検証部１２は、セッション情報記憶部１６から、認証データパケットの送信元アドレスに対応付けられている暗号用共通鍵を取得する（Ｓ２２８）。続いて、認証データ検証部１２は、認証データに含まれているチャレンジワードを当該暗号用共通鍵で復号する（Ｓ２２９）。

続いて、認証データ検証部１２は、復号されたチャレンジワードと、認証データパケットの送信元アドレスに対応付けられてセッション情報記憶部１６に記憶されているチャレンジワードとを比較することにより、認証データに含まれているチャレンジワードの正当性を検証する（Ｓ２３０）。両者が一致する場合（Ｓ２３０でＹｅｓ）、認証データ検証部１２は、認証データパケットの送信元アドレスに対応付けられてセッション情報記憶部１６に記憶されているステータスの値を「接続中」に更新する（Ｓ２３１）。続いて、認証データ検証部１２は、ホワイトネットへの接続の許可を示す接続許可応答を、認証データパケットの送信元ＩＰアドレス宛に返信する（Ｓ２３２）。

一方、ステップＳ２２２において機器証明書の取得に失敗した場合（Ｓ２２３でＮｏ）、ステップＳ２２４において算出された経過時間が所定値以上である場合（Ｓ２２５でＮｏ）、認証データに含まれている電子署名又はチャレンジワードが不正である場合（Ｓ２２７でＮｏ又はＳ２３０でＮｏ）、認証データ検証部１２は、エラー処理を行う（Ｓ２３３）。エラー処理においては、例えば再認証要求が送信元ＩＰアドレス宛に送信される。

続いて、図１６のステップＳ２０７の詳細について説明する。図２０は、ルーティング処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２４１において、ルーティング部１３は、通信データを含むパケットの送信元の通信機器２０は認証済みであるか否かを判定する。具体的には、当該パケットの送信元ＩＰアドレスを接続元ＩＰとして含むレコードがセッション情報記憶部１６に記憶されており、かつ、当該レコードのステータスの値が「接続中」であれば、当該通信機器２０は、認証済みであると判定される。以上の条件が満たされていない場合、当該通信機器２０は、認証されていないと判定される。

当該通信機器２０が認証されている場合（Ｓ２４１でＹｅｓ）、ルーティング部１３は、通信データを含むパケットから送信元ＩＰアドレス及び宛先ＩＰアドレスを取得する（Ｓ２４２）。続いて、ルーティング部１３は、送信元ＩＰアドレスと宛先ＩＰアドレスとは、同一のホワイトネットに属するＩＰアドレスであるか否かを判定する（Ｓ２４３）。すなわち、送信元ＩＰアドレスのサブネットアドレスと宛先ＩＰアドレスのサブネットアドレスとが一致するか否かが判定される。

送信元ＩＰアドレス及び宛先ＩＰアドレスのそれぞれのサブネットアドレスは、例えば、それぞれのＩＰアドレスに対応付けられて証明書リスト記憶部１５に記憶されている機器証明書（図１１）に基づいて特定可能である。すなわち、それぞれのＩＰアドレスと、それぞれに対応する機器証明書のグローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスクに基づいて、それぞれのサブネットアドレスは特定可能である。

送信元ＩＰアドレスのサブネットアドレスと宛先ＩＰアドレスのサブネットアドレスとが一致する場合（Ｓ２４３でＹｅｓ）、ステップＳ２４６に進む。

送信元ＩＰアドレスのサブネットアドレスと宛先ＩＰアドレスのサブネットアドレスとが一致しない場合（Ｓ２４３でＮｏ）、ルーティング部１３は、ルーティングポリシー記憶部１７が記憶するルーティングポリシーを参照する（Ｓ２４４）。なお、宛先ＩＰアドレスに対応する機器証明書が証明書リスト記憶部１５に記憶されていない場合も、送信元ＩＰアドレスのサブネットアドレスと宛先ＩＰアドレスのサブネットアドレスとが一致しない場合に該当する。この場合、宛先ＩＰアドレスに係る通信機器２０は、いずれのホワイトネットにも属していないことになる。

図２１は、ルーティングポリシー記憶部の構成例を示す図である。図２１において、ルーティングポリシー記憶部１７は、グローバルルーティングプレフィックス、グローバルルーティングプレフィックスマスク、送信元ホワイトネットＩＤ、サブネットマスク、許可リスト、及び拒否リスト等の項目を有する。

グローバルルーティングプレフィックス及び送信元ホワイトネットＩＤによって、送信元のホワイトネットのサブネットアドレスが特定される。また、グローバルルーティングプレフィックス及び許可リストによって、送信元のホワイトネットからのデータ送信が許可されるホワイトネットのサブネットアドレスが特定される。更に、グローバルルーティングプレフィックス及び拒否リストによって、送信元のホワイトネットからのデータ送信が許可されないホワイトネットのサブネットアドレスが特定される。

したがって、ステップＳ２４４において、ルーティング部１３は、まず、グローバルルーティングプレフィックス及び送信元ホワイトネットＩＤの組み合わせが、送信元ＩＰアドレスのサブネットアドレスに一致するレコードを特定する。ルーティング部１３は、当該レコードの中のグローバルルーティングプレフィックス及び許可リストのいずれかの組み合わせに、宛先ＩＰアドレスのサブネットアドレスが一致すれば、ルーティングは許可されると判定する。一方、当該レコードの中のグローバルルーティングプレフィックス及び拒否リストのいずれかの組み合わせに、宛先ＩＰアドレスのサブネットアドレスが一致する場合、ルーティング部１３は、ルーティングは許可されないと判定する。

なお、ルーティングポリシー記憶部１７には、許可リスト又は拒否リストの一方のみが記憶されていてもよい。

ルーティングは許可されると判定された場合（Ｓ２４５でＹｅｓ）、ステップＳ２４６に進む。ステップＳ２４６において、ルーティング部１３は、通信データを含むパケットの送信元ＩＰアドレスに対応付けて記憶されている暗号用共通鍵によって、当該通信データを復号する（Ｓ２４６）。続いて、ルーティング部１３は、通信データを含むパケットの宛先ＩＰアドレスに対応付けて記憶されている暗号用共通鍵によって、当該通信データを暗号化する（Ｓ２４７）。続いて、ルーティング部１３は、暗号化された通信データを含むパケットを、宛先ＩＰアドレスにルーティング（転送）する（Ｓ２４８）。ルーティングには、例えば、ルーティング情報記憶部１８が記憶するルーティング情報が使用される。

図２２は、ルーティング情報記憶部の構成例を示す図である。図２２において、ルーティング情報記憶部１８は、グローバルルーティングプレフィックス、グローバルルーティングプレフィックスマスク、サブネットマスク、ホワイトネットＩＤ、及びポート番号等の項目を有する。すなわち、ルーティング情報記憶部１８には、グローバルルーティングプレフィックスマスク及びホワイトネットＩＤの組み合わせによって特定されるサブネットアドレスに対応するポート番号が記憶されている。

したがって、ルーティング部１３は、宛先ＩＰアドレスのサブネットアドレスと一致するグローバルルーティングプレフィックスマスク及びホワイトネットＩＤの組み合わせをルーティング情報記憶部１８より検索する。ルーティング部１３は、検索された組み合わせに対応するポート番号に係るポートに、通信データを含むパケットを出力する。

なお、宛先ＩＰアドレスのサブネットアドレスは、例えば、宛先ＩＰアドレスを含む機器証明書に基づいて特定可能である。

上述したように、第一の実施の形態によれば、機器証明書に基づいて認証された通信機器２０のみが接続可能な仮想的なサブネットであるホワイトネットが形成される。ホワイトネットに接続されている通信機器２０は、機器証明書等に基づいて身元が保証されている。したがって、ホワイトネットにおいては、安全性が向上された通信環境を提供することができる。

また、各ホワイトネットのサブネットアドレスは、サブネットＩＤと、インタフェースＩＤの一部が含まれる。したがって、サブネットＩＤの長さの制限を超えた本数のホワイトネットを構築することができる。また、仮に、ＲＦＣ３５１３に準拠した、サブネットＩＤの長さが可変である環境が実現されたとしても、インタフェースＩＤの一部がサブネットアドレスに利用されることにより、サブネットアドレスを外部から隠蔽することができる。すなわち、サブネットＩＤが可変である場合であっても、サブネットＩＤの範囲は、ルータ等の各ネットワーク機器に対して公開される必要性が高いと考えられる。したがって、仮に、サブネットＩＤのみによってホワイトネットを識別した場合、各ホワイトネットのサブネットアドレスは、パケットの内容を解析することによって容易に把握されてしまう。一方、インタフェースＩＤの一部であるプライベートＩＤの長さは、ルータ等の各ネットワーク機器に対して公開される必要性は低い。したがって、サブネットＩＤとは別にプライベートＩＤが設けられることにより、ＩＰアドレスのいずれの部分がホワイトネットのサブネットアドレスであるかを特定するのは困難となる。その結果、ホワイトネットへの不正アクセスの困難性を高めることができる。

次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態において説明したホワイトネットに接続された通信機器２０による、任意のサーバ装置へのアクセスについて説明する。サーバ装置とは、Ｗｅｂサーバ等に代表されるような、ネットワークを介して何らかのサービスを提供するコンピュータである。なお、第二の実施の形態は、第一の実施の形態と排他的な関係に有るものではなく、第一の実施の形態と同時に実施可能である。したがって、第二の実施の形態において第一の実施の形態と共通する部分については説明を省略する。

一般的に、多数のクライアントからの要求が集中するサービスに関しては、ＤＮＳ（Domain Name System）ラウンドロビン等の方法により、複数のクライアントからの要求を、複数サーバ装置に負荷分散する仕組みが採用されている。

他方において、クライアントが不正なサーバ装置にアクセスすることを防ぐため、ＳＳＬ（Secure Socket Layer）又はＴＬＳ（Transport Layer Security）によるサーバ装置へのアクセス時には、サーバ認証が行われる。サーバ認証は、サーバ装置に発行されている公開鍵証明書であるサーバ証明書をクライアントに提示し、クライアントが当該サーバ証明書等を利用して、サーバ装置の正当性を確認することをいう。

負荷分散が行われる場合、サーバ装置の運用者は、複数存在する各サーバ装置についてサーバ証明書の発行を受ける必要がある。また、クライアントは、複数存在する各サーバ装置についてサーバ認証を行う必要がある。そうすると、サーバ装置の台数の増加に伴い、運用が複雑化してしまう可能性がある。

このような課題を解決するために、従来、ワイルドカード証明書というものが提供されている。ワイルドカード証明書を利用すれば、一つの証明書を、同一ドメインに属する複数のサーバ装置のサーバ証明書として利用することができる。

しかしながら、ワイルドカード証明書を利用した場合、クライアントに対しては、単一のサービスに関して、複数のサーバ名（ＦＱＤＮ（Fully Qualified Domain Name）：完全修飾ドメイン名）によってサービスが提供されるように見える。例えば、ユーザが、Ｗｅｂブラウザを利用して或るＷｅｂサイトにアクセスした場合、ユーザから見れば、単一のサイト内であるにも拘わらず、Ｗｅｂブラウザに表示されるＦＤＱＮが切り替わってしまうといった状況が発生する。これは、負荷分散等によって、クライアントのアクセス先のサーバ装置が切り替わることに起因する。

このような状況は、昨今のフィシング等の被害に鑑みれば、ユーザに対して、不正なＷｅｂサイトに誘導されてしまったのではないかという不安を与えてしまう可能性が有る。したがって、ユーザ心理等を考慮すれば、一つのサービスに対するアクセスに対して、単一のサーバ名によるサービスの提供が望ましい。

第二の実施の形態では、ホワイトネットに接続された通信機器２０によるサーバ装置へのアクセに関して、上記のような課題を解決する例について説明する。

図２３は、第二の実施の形態におけるネットワークシステムの構成例を示す図である。図２３中、図１と同一部分には同一符号を付し、その説明は省略する。

図２３において、通信制御装置１０には、サブネットＮｓａ〜Ｎｓｂの４つのサブネットが接続されている。なお、各サブネットは、或るホワイトネットの所有者である企業内の物理的なネットワークである。例えば、サブネットＮｓａ、Ｎｓｂ、Ｎｓｃ、及びＮｓｄは、企業Ａにおいて物理的に施設されているサブネットである。以下、各サブネットを区別しない場合、「サブネットＮｓ」という。

なお、サブネットＮｓの単位は、第一の実施の形態のホワイトネットと同様である。すなわち、第二の実施の形態において、各サブネットＮｓは、サブネットＩＤのみならず、サブネットＩＤとプライベートＩＤとの組み合わせ（すなわち、ホワイトネットＩＤ）を含むサブネットアドレスによって区別される単位である。

各サブネットには、一以上のサーバ装置４０が物理的に接続されている。また、複数のサーバ装置４０が接続されているサブネットには、負荷分散装置５０が接続されている。図２３では、サブネットの代表的な形態の一例が示されている。

例えば、サブネットＮｓａには、負荷分散装置５０ａ、サーバ装置４０ａ１、及びサーバ装置４０ａ２が含まれる。サブネットＮｓａにおいては、負荷分散装置５０ａがサブネットＮｓａの代表アドレスを有し、各サーバ装置４０ａは、負荷分散装置５０ａを起点とし、それぞれに独立及び分離した内部ネットワークによって、負荷分散装置５０ａに接続されている。すなわち、二つの内部ネットワークがサブネットＮｓａを構成するともいえる。サーバ装置４０ａ１及びａ２のそれぞれのＩＰアドレスは、負荷分散装置５０ａにより付与及び管理される。

サブネットＮｓａでは、サーバ装置４０ａごとに内部ネットワークが構築されるが、各サーバ装置４０ａのサブネットアドレスは共通である。負荷分散装置５０ａは、代表アドレス宛の要求をいずれかのサーバ装置４０ａに振り分け、当該サーバ装置４０ａが接続されている内部ネットワークへ、当該要求のルーティングを行う。

サブネットＮｓｂには、負荷分散装置５０ｂ、サーバ装置４０ｂ１、及びサーバ装置４０ｂ２が含まれる。サブネットＮｓｂにおいては、負荷分散装置５０ｂがサブネットＮｓｂの代表アドレスを有し、各サーバ装置４０ｂは、負荷分散装置５０ａを起点する単一の内部ネットワークを介して負荷分散装置５０ｂに接続されている。サーバ装置４０ｂ１及びｂ２のそれぞれのＩＰアドレスは、負荷分散装置５０ｂにより付与及び管理される。負荷分散装置５０ｂは、代表アドレス宛の要求をいずれかのサーバ装置４０ｂに振り分け、当該サーバ装置４０ｂのＩＰアドレス宛へ、当該要求を転送する。

サブネットＮｓｃには、負荷分散装置５０ｃ、サーバ装置４０ｃ１、及びサーバ装置４０ｃ２が含まれる。サブネットＮｓｃにおいては、負荷分散装置５０ｃがサブネットＮｓｃの代表アドレスを有し、各サーバ装置４０ｃは、負荷分散装置５０ｃからの内部ネットワークではなく、負荷分散装置５０ｃが外部と接続されるネットワークに接続される。サーバ装置４０ｃ１及びｃ２のそれぞれのＩＰアドレスは、負荷分散装置５０ｃにより付与及び管理される。負荷分散装置５０ｃは、いずれかのサーバ装置４０ｃ宛の要求の受信を代行し、当該要求を当該サーバ装置４０ｃに転送する。

サブネットＮｓｄは、サーバ装置４０ｄ１を含む。サーバ装置４０ｄ１は、通信機器２０からの要求を直接的に処理する。すなわち、サブネットＮｓｄにおいて、負荷分散は行われない。

以上のようなネットワーク構成において、第二の実施の形態では、サーバ装置４０ごとではなく、サブネットＮｓごとにサーバ証明書と同様の役割を担う公開鍵証明書が発行される。以下、当該公開鍵証明書を、「サブネット証明書」という。一つのサブネット証明書は、当該サブネット証明書に属する全てのサーバ装置４０に導入される。すなわち、同一のサブネットＮｓに属するサーバ装置４０には、同一又は共通のサブネット証明書が導入される。

通信機器２０がサーバ装置４０にアクセスする際は、サブネット証明書がサーバ証明書の代わりに利用されて、サーバ認証が実行される。

なお、図２３のサブネットＮｓｄには、更に、証明書取得装置６０が含まれている。証明書取得装置６０は、証明書発行装置３０より各サブネットＮｓのサブネット証明書の発行を受けるための機能が実装されたコンピュータである。証明書取得装置６０は、必ずしもいずれかのサブネットＮｓに接続されていなくてもよいが、図２３では、便宜上、サブネットＮｓｄに接続された例が示されている。

図２４は、第二の実施の形態における各装置の機能構成例を示す図である。図２４中、図３と同一部分には同一符号を付し、その説明は省略する。

図２４において、通信機器２０は、更に、サーバ認証部２３を有する。サーバ認証部２３は、サーバ認証のための処理を実行する。

サーバ装置４０は、サーバ通信部４１及びサブネット証明書記憶部４２等を有する。サーバ通信部４１は、通信機器２０等のクライアントとの通信を制御する。サブネット証明書記憶部４２は、サブネット証明書を記憶する。なお、サーバ通信部４１は、サーバ装置４０にインストールされたプログラムがサーバ装置４０のＣＰＵに実行させる処理により実現される。サブネット証明書記憶部４２は、例えば、サーバ装置４０の補助記憶装置等を用いて実現可能である。

続いて、各サブネットＮｓに関してサブネット証明書の発行を受けるための準備作業について説明する。

まず、サブネットの所有者である企業Ａは、サブネットの数や、各サブネットに接続されるサーバ装置４０の台数等を考慮して、ＩＰアドレスの利用範囲（割り当て範囲）を、例えば、／６４〜／８０の範囲で決定する。／６４は、上位６４ビットまでが決定された値が企業Ａに対して割り当てられることを意味する。したがって、この場合、企業Ａは、下位６４ビットを自由に利用することができる。また、／８０は、先頭から８０ビットまでが決定された値が企業Ａに対して割り当てられることを意味する。したがって、この場合、企業Ａは、下位４８ビットを自由に利用することができる。

続いて、企業Ａは、必要なサブネットの本数を決定し、サブネットマスクを決定する。各サブネットＮｓのアドレス体系は、第一の実施の形態と同様に、図９に示したものに従う。すなわち、サブネットマスクとは、ＩＰアドレスの先頭から、プライベートＩＤの末尾（ホワイトネットＩＤの末尾）までのビット長をいう。サブネットマスクの決定は、インタフェースＩＤの上位の何ビットをプライベートＩＤとするか（ホワイトネットＩＤに含めるか）の決定に相当する。

割り当て範囲が／６４である場合、サブネットマスクが／８０であれば、ホワイトネットＩＤのビット長は、サブネットＩＤの１６ビット＋プライベートＩＤの１６ビット（インタフェースＩＤの上位１６ビット）の３２ビットとなる。

上記の決定事項のうち、割り当て範囲は、例えば、企業ＡからＩＳＰに対して申請される。ＩＳＰは、当該申請を受けると、申請された割り当て範囲に対応したＩＰアドレス群を用意する。用意されたＩＰアドレス群は、例えば、企業Ａに対する加入者ＩＤに対応付けられて管理される。通常、グローバルルーティングプレフィックスの値が、企業Ａに割り当てられる。

続いて、企業Ａは、割り当てられたＩＰアドレス群（グローバルルーティングプレフィックス）及びサブネットマスク等に基づくサブネットアドレスが割り当てられたサブネットＮｓを構築する。

続いて、証明書取得装置６０を利用して、サブネット証明書の取得処理が行われる。図２５は、サブネット証明書の取得処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、証明書取得装置６０は、所有者情報の入力をユーザより受け付ける。所有者情報には、サブネットＮｓの所有者の組織名や所在地等が含まれる。続いて、証明書取得装置６０は、サブネット証明書の取得対象のサブネットＮｓに関する、サブネットアドレス、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスク等の入力をユーザより受け付ける（Ｓ３０２）。

続いて、証明書取得装置６０は、公開鍵及び秘密鍵のペアを生成する（Ｓ３０３）。続いて、証明書取得装置６０は、証明書署名要求（ＣＳＲ（Certificate Signing Request））を生成する（Ｓ３０４）。ＣＳＲには、ステップＳ３０１及びＳ３０２において入力された情報と、ステップＳ３０３において生成された公開鍵とが含まれる。

図２６は、ＣＳＲの構成例を示す図である。図２６は、一般的なＣＳＲの形式に準拠したものであるため、基本的なフィールドの説明は省略する。なお、公開鍵は、ＰｕｂｕｌｉｃＫｅｙフィールドに格納される。

ｅｘｔｅｎｓｉｏｎｓフィールドは、拡張領域である。本実施の形態では、拡張型（ｅｘＩｎｄ）として、サブネットアドレス（ＩＰｖ６ Ｇｌｏｂａｌ Ｎｅｔｗｏｒｋ Ｓｕｂ−Ｎｅｔ Ａｄｄｒｅｓｓ）、グローバルルーティングプレフィックスマスク（Ｇｌｏｂａｌ Ｒｏｕｔｉｎｇ Ｐｒｅｆｉｘ Ｍａｓｋ）、サブネットＩＤマスク（Ｓｕｂ−Ｎｅｔ ＩＤ Ｍａｓｋ）、及びプライベートＩＤマスク（Ｐｒｉｖａｔｅ ＩＤ Ｍａｓｋ）等が含まれる。これらの拡張型には、ステップＳ３０２において入力された値が格納される。

続いて、証明書取得装置６０は、生成されたＣＳＲを証明書発行装置３０に送信する（Ｓ３０５）。

証明書発行装置３０は、ＣＳＲの受信に応じ、サブネット証明書を生成し、当該サブネット証明書を証明書取得装置６０に返信する。

証明書取得装置６０は、サブネット証明書を受信すると（Ｓ３０６でＹｅｓ）、例えば、当該サブネット証明書に対応するサブネットＮｓに属する各サーバ装置４０に、秘密鍵と、当該サブネット証明書とを配信（エクスポート）する（Ｓ３０７）。

図２７は、サブネット証明書の構成例を示す図である。図２７に示されるサブネット証明書は、Ｘ５０９ ｖ３フォーマットに準拠したものであるため、基本的なフィールドの説明は省略する。なお、図２６のＣＳＲに含まれていた公開鍵は、ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏフィールドに格納される。

また、拡張領域であるｅｘｔｅｎｓｉｏｎｓフィールドの内容は、図２６のＣＳＲのｅｘｔｅｎｓｉｏｎｓフィールドの内容と同じである。

なお、秘密鍵及びサブネット証明書の配信を受けた各サーバ装置４０は、配信された秘密鍵及びサブネット証明書を、当該サーバ装置４０のサブネット証明書記憶部４２に安全に保存する。すなわち、当該各サーバ装置４０に、秘密鍵及びサブネット証明書が導入される。

なお、サブネット証明書の取得処理は、例えば、負荷分散装置５０やいずれかのサーバ装置４０等、証明書取得装置６０以外のコンピュータによって実行されてもよい。

秘密鍵及びサブネット証明書が導入されたサーバ装置４０は、ＳＳＬハンドシェイク等の過程で行われるサーバ認証において、自らの正当性を証明することができる。

図２８は、ＳＳＬハンドシェイクの処理手順の一例を説明するためのシーケンス図である。図２８における通信機器２０ａは、サーバ装置４０ａ１が属するサブネットＮｓａへの接続が許可されるホワイトネットに収容済みであるとする。サブネットＮｓａへの接続制限は、例えば、通信制御装置１０のルーティングポリシーによって実現することができる。または、サブネットＮｓａのサブネットアドレスは、通信機器２０ａが収容されたホワイトネットのサブネットアドレスに一致していてもよい。

なお、図２８において、通信機器２０ａとサーバ装置４０ａ１との間の通信には、通信制御装置１０及び負荷分散装置５０ａが介在するが、図２８においては便宜上省略されている。

ステップＳ４０１において、通信機器２０ａのサーバ認証部２３は、ＣｌｉｅｎｔＨｅｌｌｏメッセージをサーバ装置４０ａ１宛のＩＰアドレスに送信することにより、暗号通信において使用する暗号方式等をサーバ装置４０ａ１に提案する。なお、通信機器２０ａから見た場合、厳密には、サーバ装置４０ａ１宛のＩＰアドレスは、負荷分散装置５０ａ宛のＩＰアドレスということになる。通信機器２０ａが、サーバ装置４０ａ１及びａ２のいずれと通信するかは、負荷分散装置５０ａによる負荷分散機能によって動的に決定されるからである。

サーバ装置４０ａ１のサーバ通信部４１は、提案された暗号方式の中から一つの暗号方式を選択し、ＳｅｖｅｒＨｅｌｌｏメッセージによって選択結果を返信する（Ｓ４０２）。その結果、暗号方式が決定される。

続いて、サーバ装置４０ａ１のサーバ通信部４１は、Ｃｅｒｔｉｆｉｃａｔｅメッセージによって、サブネット証明書記憶部４２に記憶されているサブネット証明書を通信機器２０ａに送信する（Ｓ４０３）。サブネット証明書の送信が完了すると、サーバ通信部４１は、ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージを通信機器２０ａに送信し、サブネット証明書の送信の完了を通信機器２０ａに通知する（Ｓ４０４）。

続いて、通信機器２０ａのサーバ認証部２３は、受信されたサブネット証明書の検証処理を実行する（Ｓ４０５）。当該検証処理の詳細については後述される。サブネット証明書の正当性が確認された場合、ステップＳ４０６以降が実行される。

ステップＳ４０６において、サーバ認証部２３は、ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージをサーバ装置４０ａ１に送信する（Ｓ４０５）。ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージには、ステップＳ４０３において受信されたサブネット証明書に格納されている、サーバ装置４０ａ１の公開鍵によって暗号化されたプレマスタ・シークレットが含まれている。プレマスタ・シークレットは、図２８に示される処理の実行後の暗号通信に使用される共通鍵の基となるデータである。

サーバ装置４０ａ１のサーバ通信部４１は、ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージを受信すると、当該メッセージに含まれている、暗号化されたプレマスタ・シークレットを、サブネット証明書記憶部４２に記憶されている秘密鍵によって復号する。その結果、通信機器２０ａとサーバ装置４０との間で、プレマスタ・シークレットが共有される。

続いて、通信機器２０ａのサーバ認証部２３は、これまでに決定されている暗号方式の採用を宣言するＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージをサーバ装置４０ａ１に送信する（Ｓ４０８）。続いて、サーバ認証部２３は、Ｆｉｎｉｓｈｅｄメッセージをサーバ装置４０ａ１に送信し、ＳＳＬハンドシェイクの終了をサーバ装置４０ａ１に通知する（Ｓ４０９）。

Ｆｉｎｉｓｈｅｄメッセージの受信に応じ、サーバ装置４０ａ１のサーバ通信部４１は、通信機器２０ａと同様に、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ及びＦｉｎｉｓｈｅｄメッセージを通信機器２０ａに送信する。

その後、通信機器２０ａの通信制御部２１及びサーバ装置４０ａ１のサーバ通信部４１のそれぞれは、共有されたプレマスタ・シークレットを使用して、暗号用の共通鍵を生成する。通信機器２０ａの通信制御部２１及びサーバ装置４０ａ１は、当該共通鍵を使用して暗号通信を実行する。

なお、第一の実施の形態において説明したように、通信機器２０ａと通信制御装置１０との間においても暗号用共通鍵を用いてホワイトネットに関する暗号通信が行われる。当該暗号通信は、通信機器２０ａとサーバ装置４０ａ１との間の暗号通信の外側において実行されるものである。すなわち、通信機器２０ａの通信制御部２１は、サーバ装置４０ａ１との暗号通信用の共通鍵によって通信データを暗号化し、更に、その暗号結果を通信制御装置１０との暗号用共通鍵によって暗号化する。通信制御部２１は、その暗号結果を含むパケットを送信する。

続いて、ステップＳ４０５の詳細について説明する。図２９は、サブネット証明書に基づくサーバ認証の処理手順の一例を説明するためのフローチャートである。

ステップＳ４２１において、サーバ認証部２３は、受信されたサブネット証明書自体の正当性を検証する。サブネット証明書自体の検証方法は、一般的な公開鍵証明書の検証方法と同様でよい。すなわち、サブネット証明書に含まれている、認証局の署名等に基づいて検証が行われる。

サブネット証明書が正しい場合（Ｓ４２２でＹｅｓ）、サーバ認証部２３は、サブネット証明書（図２７）より、サブネットアドレス、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスクを取得する（Ｓ４２３）。

続いて、サーバ認証部２３は、例えば、これまでにサーバ装置４０ａ１から受信されているパケットから送信元ＩＰアドレスを取得する（Ｓ４２４）。これまでにサーバ装置４０ａ１から受信されているパケットとは、例えば、ＳｅｖｅｒＨｅｌｌｏＤｏｎｅメッセージに係るパケット等である。

続いて、サーバ認証部２３は、サブネット証明書より取得されたグローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスクに基づいて、サブネットマスクを生成する。

例えば、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスクの値が、図２７に示されるように、／４８、／１６、／１６である場合、サブネットマスクの値は、以下の通りとなる。

ＦＦＦＦ：ＦＦＦＦ：ＦＦＦＦ：ＦＦＦＦ：ＦＦＦＦ：００００：００００：００００
すなわち、サブネットマスクは、／４８＋／１６＋／１６＝／８０となる。

続いて、サーバ認証部２３は、ステップＳ４２４において取得された送信元ＩＰアドレスと、ステップＳ４２５において生成されたサブネットマスクとの論理積を算出することにより、送信元ＩＰアドレスのサブネットアドレスを取得する（Ｓ４２６）。

続いて、サーバ認証部２３は、ステップＳ４２６において取得されたサブネットアドレスと、ステップＳ４２３においてサブネット証明書より取得されたサブネットアドレスとを比較する（Ｓ４２７）。両者が一致する場合（Ｓ４２８でＹｅｓ）、サーバ認証部２３は、サーバ装置４０ａ１は正しいと判定する。両者が一致しない場合（Ｓ４２８でＮｏ）、又はサブネット証明書が不正である場合（Ｓ４２２でＮｏ）、サーバ認証部２３は、エラー処理を実行する（Ｓ４２９）。エラー処理としては、例えば、図２８の処理手順が最初から再実行される。

続いて、ＳＳＬハンドシェイク後の、通信機器２０ａとサーバ装置４０ａ１との間の通信処理について説明する。

図３０は、通信機器とサーバ装置との間の通信処理の処理手順の一例を説明するためのシーケンス図である。図３０では、通信機器２０ａとサーバ装置４０ａ１との間で通信が行われる例を説明する。通信機器２０ａは、サーバ装置４０ａ１が属するサブネットＮｓａへの接続が許可されるホワイトネットに収容済みであるとする。

ステップＳ５０１において、通信機器２０ａの通信制御部２１は、サーバ装置４０ａ１宛への要求データを、ＳＳＬ用の共通鍵（以下、「ＳＳＬ用鍵」という。）によって暗号化する。ＳＳＬ用鍵は、図２８の処理に基づいて、サーバ装置４０ａ１との間で共有されている暗号鍵（共通鍵）である。続いて、通信制御部２１は、暗号化された要求データを、更に、暗号鍵ａによって暗号化する。暗号鍵ａは、図１３のステップＳ１１２において通信制御装置１０より受信した暗号用共通鍵である。続いて、通信制御部２１は、暗号化された要求データを含むパケット、サーバ装置４０ａ１（負荷分散装置５０ａ）のＩＰアドレス宛に送信する（Ｓ５０３）。

当該パケットは、ネットワークＮ１を介して通信制御装置１０によって受信される。通信制御装置１０のルーティング部１３は、通信機器２０ａからのパケットに含まれる要求データを、暗号鍵ａによって復号する（Ｓ５０３）。続いて、ルーティング部１３は、復号された要求データを、ネットワークＮ１を介してサーバ装置４０ａ１宛（負荷分散装置５０ａ宛）に転送する（Ｓ５０５）。なお、暗号鍵ａによって復号された状態においても、要求データはＳＳＬ用鍵によって暗号化されている。したがって、要求データは安全に転送される。

なお、ルーティングポリシーに従った、通信機器２０ａからサーバ装置４０ａ１へのルーティング（要求データの転送）の可否の判定は、図２０において説明した通り実行される。すなわち、要求データの受信に応じた詳細な処理は、図２０において説明した通りである。但し、通信制御装置１０は、サーバ装置４０ａ１に対応する暗号用共通鍵は保持していない。サーバ装置４０ａ１は、ホワイトネットの所有者が実際に所有する物理的なネットワークに物理的に接続されているコンピュータであり、概念的にはホワイトネットの内側に存在する。したがって、ホワイトネットの所有者にとっては、サーバ装置４０ａ１の身元は確かであり、サーバ装置４０ａ１に関してホワイトネットへの接続のための認証を行う必要性は低いからである。但し、サーバ装置４０ａ１等、図２３に示される各サブネットＮｓに接続されている各サーバ装置４０に関しても、ホワイトネットへの接続のための認証処理が行われてもよい。この場合、通信制御装置１０のルーティング部１３は、サーバ装置４０ａ１に対応する暗号用共通鍵によって、要求データを暗号化してもよい。

サーバ装置４０ａ１のサーバ通信部４１は、要求データを受信すると、当該要求データをＳＳＬ用鍵によって復号する（Ｓ５０６）。続いて、サーバ装置４０ａ１は、例えば、復号された要求データが示す要求に応じた処理を実行する（Ｓ５０７）。続いて、サーバ通信部４１は、例えば、処理結果を含む応答データを、ＳＳＬ用鍵によって暗号化する（Ｓ５０８）。続いて、サーバ通信部４１は、暗号化された応答データを含むパケットを、通信機器２０ａのＩＰアドレス宛に返信する（Ｓ５０９）。

当該パケットは、通信制御装置１０によって受信される。通信制御装置１０のルーティング部１３は、当該パケットの宛先ＩＰアドレスに対応する、通信機器２０ａに対する暗号鍵ａによって、当該応答データを暗号化する（Ｓ５１０）。続いて、ルーティング部１３は、暗号鍵ａによって暗号化された応答データを含むパケットを、ネットワークＮ１を介して通信機器２０ａ宛に転送する（Ｓ５１１）。

通信機器２０ａの通信制御部２１は、応答データを含むパケットを受信すると、当該応答データを暗号鍵ａによって復号する（Ｓ５１２）。通信制御部２１は、更に、復号された応答データを、ＳＳＬ用鍵で復号する（Ｓ５１３）通信機器２０ａは、例えば、復号された応答データを利用した処理を実行する。

上述したように、第二の実施の形態によれば、サブネットＮｓごとにサーバ証明書が発行される。したがって、同一のサブネットＮｓに属する複数のサーバ装置４０のそれぞれごとにサーバ証明書の発行を受ける必要性を低減させることができる。

また、負荷分散装置５０によって、要求が振り分けられるサーバ装置４０が途中で変化したとしても、各サーバ装置４０は共通のサーバ証明書を利用しているため、クライアントである通信機器２０に提示されるサーバ名が変化する可能性は低い。したがって、サーバ名が変化することによってユーザが不安を感じる可能性を低減させることができる。

なお、第二の実施の形態は、ホワイトネットとは無関係に実施されてもよい。すなわち、ホワイトネットに収容されていないクライアントに対してサービスを提供するサーバ装置に関して、サブネット証明書が発行されてもよい。

また、同一のハードウェア上において起動される複数の仮想マシンに関して、共通のサブネット証明書が発行されてもよい。

なお、上記各実施の形態において、プライベートＩＤマスクの長さが０であってもよい。この場合、サブネットＩＤによって各ホワイトネット又は各サブネットＮｓが識別されることになる。

なお、上記各実施の形態において、データ検証部１２は、検証部の一例である。ルーティング部１３は、転送部の一例である。サーバ認証部２３は、共有部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証し、
前記電子署名の正当性が検証された通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する処理をコンピュータが実行する通信制御方法。
（付記２）
前記サブネットアドレスは、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む付記１記載の通信制御方法。
（付記３）
前記電子署名の正当性が検証された第一の通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、当該パケットに含まれているデータを、前記第一の通信機器との間で共有されている共通鍵によって復号し、
当該パケットの宛先ＩＰアドレスに係る第二の通信機器との間で共有されている共通鍵によって前記データを暗号化し、
暗号化された前記データを含むパケットを当該宛先ＩＰアドレス宛に転送する処理を前記コンピュータが実行する付記１又は２記載の通信制御方法。
（付記４）
通信機器からの要求に応じた処理を実行するサーバ装置から送信されるサブネットごとの公開鍵証明書に含まれているサブネットアドレスと、前記サーバ装置からのパケットの送信元アドレスのサブネットアドレスとを比較し、
比較された二つのサブネットアドレスが一致する場合に、前記サーバ装置との間で共通鍵を共有し、
前記共通鍵を用いた暗号通信によって前記サーバ装置に対する要求を送信する処理を通信機器が実行する通信制御方法。
（付記５）
前記サブネットアドレスは、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む付記４記載の通信制御方法。
（付記６）
通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証する検証部と、
前記電子署名の正当性が検証された通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該第パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する転送部とを有する通信制御装置。
（付記７）
前記サブネットアドレスは、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む付記６記載の通信制御装置。
（付記８）
前記転送部は、
前記電子署名の正当性が検証された第一の通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、当該パケットに含まれているデータを、前記第一の通信機器との間で共有されている共通鍵によって復号し、
当該パケットの宛先ＩＰアドレスに係る第二の通信機器との間で共有されている共通鍵によって前記データを暗号化し、
暗号化された前記データを含むパケットを当該宛先ＩＰアドレス宛に転送する付記６又は７記載の通信制御装置。
（付記９）
通信機器からの要求に応じた処理を実行するサーバ装置から送信されるサブネットごとの公開鍵証明書に含まれているサブネットアドレスと、前記サーバ装置からのパケットの送信元アドレスのサブネットアドレスとを比較し、比較された二つのサブネットアドレスが一致する場合に、前記サーバ装置との間で共通鍵を共有する共有部と、
前記共通鍵を用いた暗号通信によって前記サーバ装置に対する要求を送信する通信制御部とを有する通信機器。
（付記１０）
前記サブネットアドレスは、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む付記９記載の通信機器。
（付記１１）
通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証し、
前記電子署名の正当性が検証された通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該第パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する処理をコンピュータに実行させるプログラム。
（付記１２）
前記サブネットアドレスは、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む付記１１記載のプログラム。
（付記１３）
前記電子署名の正当性が検証された第一の通信機器から送信されるパケットの宛先ＩＰアドレスのサブネットアドレスが、当該パケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定されるサブネットアドレスと一致する場合に、当該パケットに含まれているデータを、前記第一の通信機器との間で共有されている共通鍵によって復号し、
当該パケットの宛先ＩＰアドレスに係る第二の通信機器との間で共有されている共通鍵によって前記データを暗号化し、
暗号化された前記データを含むパケットを当該宛先ＩＰアドレス宛に転送する処理を前記コンピュータが実行させる付記１１又は１２記載のプログラム。
（付記１４）
通信機器からの要求に応じた処理を実行するサーバ装置から送信されるサブネットごとの公開鍵証明書に含まれているサブネットアドレスと、前記サーバ装置からのパケットの送信元アドレスのサブネットアドレスとを比較し、
比較された二つのサブネットアドレスが一致する場合に、前記サーバ装置との間で共通鍵を共有し、
前記共通鍵を用いた暗号通信によって前記サーバ装置に対する要求を送信する処理を通信機器に実行させるプログラム。
（付記１５）
前記サブネットアドレスは、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む付記１４記載のプログラム。

１０ 通信制御装置
１１ 認証要求受付部
１２ 認証データ検証部
１３ ルーティング部
１４ 再認証要求部
１５ 証明書リスト記憶部
１６ セッション情報記憶部
１７ ルーティングポリシー記憶部
１８ ルーティング情報記憶部
２０ 通信機器
２１ 通信制御部
２２ 機器証明書記憶部
２３ サーバ認証部
３０ 証明書発行装置
３１ 証明書発行部
３２ 確認情報記憶部
４０ サーバ装置
４１ サーバ通信部
４２ サブネット証明書記憶部
５０ 負荷分散装置
６０ 証明書取得装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

Claims (9)

1. 通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証し、
   前記電子署名の正当性が検証された通信機器から送信されるパケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定される、ＩＰアドレスに関して少なくともサブネットごとの識別領域を含む範囲について、当該送信元ＩＰアドレスと当該パケットの宛先ＩＰアドレスとが一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する処理をコンピュータが実行する通信制御方法。
2. 前記範囲は、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む請求項１記載の通信制御方法。
3. 前記電子署名の正当性が検証された第一の通信機器から送信されるパケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定される、ＩＰアドレスに関して少なくともサブネットごとの識別領域を含む範囲について、当該送信元ＩＰアドレスと当該パケットの宛先ＩＰアドレスとが一致する場合に、当該パケットに含まれているデータを、前記第一の通信機器との間で共有されている共通鍵によって復号し、
   当該パケットの宛先ＩＰアドレスに係る第二の通信機器との間で共有されている共通鍵によって前記データを暗号化し、
   暗号化された前記データを含むパケットを当該宛先ＩＰアドレス宛に転送する処理を前記コンピュータが実行する請求項１又は２記載の通信制御方法。
4. 通信機器からの要求に応じた処理を実行するサーバ装置から送信される、サブネットごとの公開鍵証明書に含まれている、ＩＰアドレスに関して少なくとも前記サブネットごとの識別領域を含む範囲に係るアドレスと、前記サーバ装置からのパケットの送信元アドレスの前記範囲に係るアドレスとを比較し、
   比較された二つのアドレスが一致する場合に、前記サーバ装置との間で共通鍵を共有し、
   前記共通鍵を用いた暗号通信によって前記サーバ装置に対する要求を送信する処理を通信機器が実行する通信制御方法。
5. 前記範囲は、ＩＰｖ６のアドレス体系におけるサブネットごとの識別領域とネットワークインタフェースごとの識別領域の一部とを含む請求項４記載の通信制御方法。
6. 通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証する検証部と、
   前記電子署名の正当性が検証された通信機器から送信されるパケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定される、ＩＰアドレスに関して少なくともサブネットごとの識別領域を含む範囲について、当該送信元ＩＰアドレスと当該パケットの宛先ＩＰアドレスとが一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する転送部とを有する通信制御装置。
7. 通信機器からの要求に応じた処理を実行するサーバ装置から送信される、サブネットごとの公開鍵証明書に含まれている、ＩＰアドレスに関して少なくとも前記サブネットごとの識別領域を含む範囲に係るアドレスと、前記サーバ装置からのパケットの送信元アドレスの前記範囲に係るアドレスとを比較し、比較された二つのアドレスが一致する場合に、前記サーバ装置との間で共通鍵を共有する共有部と、
   前記共通鍵を用いた暗号通信によって前記サーバ装置に対する要求を送信する通信制御部とを有する通信機器。
8. 通信機器から送信される所定のパケットに含まれている電子署名の正当性を、前記所定のパケットの送信元ＩＰアドレスに関して発行されている公開鍵証明書によって検証し、
   前記電子署名の正当性が検証された通信機器から送信されるパケットの送信元ＩＰアドレスに関して発行されている前記公開鍵証明書に含まれている情報に基づいて特定される、ＩＰアドレスに関して少なくともサブネットごとの識別領域を含む範囲について、当該送信元ＩＰアドレスと当該パケットの宛先ＩＰアドレスとが一致する場合に、前記宛先ＩＰアドレス宛に当該パケットを転送する処理をコンピュータに実行させるプログラム。
9. 通信機器からの要求に応じた処理を実行するサーバ装置から送信される、サブネットごとの公開鍵証明書に含まれている、ＩＰアドレスに関して少なくとも前記サブネットごとの識別領域を含む範囲に係るアドレスと、前記サーバ装置からのパケットの送信元アドレスの前記範囲に係るアドレスとを比較し、
   比較された二つのアドレスが一致する場合に、前記サーバ装置との間で共通鍵を共有し、
   前記共通鍵を用いた暗号通信によって前記サーバ装置に対する要求を送信する処理を通信機器に実行させるプログラム。

Images