JP6079394B2 - 証明書生成方法、証明書生成装置、情報処理装置、通信機器、及びプログラム - 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）又はフラッシュメモリ等が挙げられる。記録媒体３０１及び補助記憶装置３０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

なお、通信制御装置１０も、図２と同様のハードウェア構成を有していてもよい。

図３は、本発明の実施の形態における通信機器のハードウェア構成例を示す図である。図３において、通信機器２０は、ＲＯＭ２０１、ＲＡＭ２０２、ＣＰＵ２０３、補助記憶装置２０４、インタフェース装置２０５、及びセキュリティチップ２０６等を備える。ＲＯＭ２０１は、プログラムやデータ等を記憶する。ＲＡＭ２０２は、ＲＯＭ２０１又は補助記憶装置２０４に記憶されたプログラムのうち、起動されたプログラムを読み出して格納する。ＣＰＵ２０３は、ＲＡＭ２０２に格納されたプログラムに従って通信機器２０に係る機能を実行する。補助記憶装置２０４は、プログラムやデータ等を記憶する。インタフェース装置２０５は、ネットワークカード等、ネットワークに接続するためのハードウェアである。セキュリティチップ２０６は、耐タンパ性を有するＬＳＩ（Large Scale Integration）である。セキュリティチップ２０６の一例として、ＴＰＭ（Trusted Platform Module）が挙げられる。

なお、通信機器２０は、液晶ディスプレイ等の表示装置や、キーボード、マウス、ボタン、又はタッチパネル等の入力装置等を備えていてもよい。

図４は、本発明の実施の形態における各装置の機能構成例を示す図である。図４において、証明書発行装置３０は、発行要求受信部３１、発行要求検証部３２、アドレス決定部３３、証明書生成部３４、及び応答返信部３５等を有する。これら各部は、証明書発行装置３０にインストールされたプログラムが、ＣＰＵ３０４に実行させる処理により実現される。証明書発行装置３０は、また、ホワイトリスト記憶部３６及び機器情報記憶部３７等を利用する。これら各記憶部は、補助記憶装置３０２、又は証明書発行装置３０にネットワークを介して接続される記憶装置等を用いて実現可能である。

発行要求受信部３１は、通信機器２０より送信される、機器証明書の発行要求を受信する。発行要求検証部３２は、受信された発行要求の正当性を検証する。アドレス決定部３３は、機器証明書の発行要求元の通信機器２０に対するＩＰアドレスを決定する。証明書生成部３４は、決定されたＩＰアドレス等を含む機器証明書を生成する。応答返信部３５は、機器証明書の発行要求に対する応答を返信する。例えば、応答返信部３５は、証明書生成部３４によって生成された機器証明書を、発行要求元の通信機器２０に送信する。

ホワイトリスト記憶部３６は、発行要求の正当性を検証するための情報を記憶する。機器情報記憶部３７は、通信機器２０ごとの固有情報に対応付けて、通信機器２０に割り当てられたＩＰアドレス等を記憶する。本実施の形態では、各通信機器２０のＭａｃアドレスが、固有情報の一例とされる。

通信機器２０は、レポート生成部２１、証明書発行要求部２２、証明書受信部２３、アドレス設定部２４、及び通信制御部２５等を有する。レポート生成部２１、証明書発行要求部２２、証明書受信部２３、及びアドレス設定部２４は、セキュリティチップ２０６内のメモリに記憶されているプログラムが、セキュリティチップ２０６内のＣＰＵに実行させる処理により実現される。通信制御部２５は、補助記憶装置２０４にインストールされたプログラムが、ＣＰＵ２０３に実行させる処理により実現される。通信機器２０は、また、機器証明書記憶部２６を有する。機器証明書記憶部２６は、例えば、セキュリティチップ２０６内のメモリ、又は補助記憶装置２０４等を用いて実現可能である。機器証明書記憶部２６が、セキュリティチップ２０６の外部に形成される場合、例えば、ＴＰＭのＰｒｏｔｅｃｔｅｄ Ｓｔｏｒａｇｅ機能を利用して、機器証明書記憶部２６のセキュリティを向上させてもよい。

レポート生成部２１は、通信機器２０の構成情報等を含むレポート情報を生成する。通信機器２０の構成情報とは、通信機器２０に接続又は備え付けられているハードウェアの構成情報、及び通信機器２０にインストールされているソフトウェアの構成情報等を含む、通信機器２０の動作環境を示す情報である。証明書発行要求部２２は、機器証明書の発行要求を、証明書発行装置３０に送信する。当該発行要求には、レポート生成部２１によって生成されたレポート情報が指定される。証明書受信部２３は、機器証明書の発行要求に応じて、証明書発行装置３０において生成及び返信される機器証明書を受信する。アドレス設定部２４は、機器証明書に含まれているＩＰアドレスを、通信機器２０の通信制御部２５に設定する。具体的には、当該ＩＰアドレスは、通信機器２０の補助記憶装置２０４において、通信制御部２５が、ＩＰアドレスの記憶領域として予定している領域に記憶される。通信制御部２５は、通信制御装置１０や他の通信機器２０等との通信を制御するための処理を実行する。通信制御部２５は、ホワイトネットへの接続の際に、機器証明書記憶部２６に記憶されている機器証明書や秘密鍵等を用いて、自らの正当性を証明するための処理を実行する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上記の決定事項のうち、割り当て範囲は、例えば、企業ＡからＩＳＰに対して申請される。但し、ＩＳＰが、企業Ａにおけるネットワーク構成の構想を聴取して、企業Ａに適した割り当て範囲及びサブネットマスクを決定してもよい。また、企業Ａは、ホワイトネットに接続を許可する通信機器２０ごとに、当該通信機器２０の固有情報の一例であるＭａｃアドレス、及び当該通信機器２０の所有者を示す情報を、ＩＳＰに対して申請する。以下、当該情報を「機器情報」という。通信機器２０の所有者は、企業Ａである。

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

なお、通信機器２０ごとに申請された機器情報は、証明書発行装置３０の機器情報記憶部３７に記憶される。

以上によって、企業Ａが、各通信機器２０に関して機器証明書の発行を受けるための準備作業が完了する。なお、この時点において、通信機器２０のＩＰアドレスは決定されていない。後述されるように、通信機器２０のＩＰアドレスは、機器証明書の発行に伴って決定されるからである。

続いて、企業Ａにおける各通信機器２０が、ホワイトネットへの接続するために必要とされる機器証明書の発行を証明書発行装置３０に要求する処理について説明する。

図１１は、機器証明書の発行要求処理の処理手順の一例を説明するためのフローチャートである。なお、図１１では、一台の通信機器２０に関する処理について説明するが、各通信機器２０に関して、図１１の処理が実行される。

例えば、通信機器２０がネットワークに接続された後、初めて起動されると、セキュリティチップ２０６内においてプログラムが起動される（Ｓ１１）。当該プログラムは、セキュリティチップ２０６を、レポート生成部２１、証明書発行要求部２２、証明書受信部２３、及びアドレス設定部２４として機能させるプログラムである。以下、当該プログラムを、「証明書取得プログラム」という。証明書取得プログラムは、例えば、通信機器２０の工場出荷前において、セキュリティチップ２０６内のメモリに記憶されている。但し、証明書取得プログラムは、例えば、ＲＯＭ２０１又は補助記憶装置２０４等、セキュリティチップ２０６の外部に記憶されていてもよい。なお、図１１処理が実行されるタイミングは、通信機器２０のネットワークへの接続後の最初の起動時に限定されなくてもよい。例えば、毎回の起動時に実行されてもよいし、所定期間ごとに実行されてもよい。また、機器証明書に有効期限が設けられる場合には、当該有効期限が経過するたびに実行されてもよい。

続いて、セキュリティチップ２０６は、起動された証明書取得プログラムの正当性を検証する（Ｓ１２）。具体的には、起動された証明書取得プログラムは、自らのハッシュ値を生成し、出力する。一方、セキュリティチップ２０６内には、予め、証明書取得プログラムのハッシュ値が記憶されている。セキュリティチップ２０６は、証明書取得プログラムによって生成されたハッシュ値と、予め記憶されているハッシュ値とを比較する。両者が一致すれば、証明書取得プログラムの正当性は肯定される。なお、ここでいう正当性は、改竄されていないことをいう。

証明書取得プログラムの正当性が否定された場合（Ｓ１３でＮｏ）、ステップＳ１４以降の処理は実行されない。証明書取得プログラムの正当性が肯定された場合（Ｓ１３でＹｅｓ）、証明書取得プログラムは、セキュリティチップ２０６に、ステップＳ１４以降の処理を実行させる。

ステップＳ１４において、レポート生成部２１は、通信機器２０の構成情報の収集を行う。すなわち、ハードウェアの構成情報及びソフトウェアの構成情報の収集が行われる。ハードウェアの構成情報には、機器ＩＤ、ＣＰＵ２０３のＩＤ、ＲＡＭ２０２のＩＤ、ＲＯＭ２０１のＩＤ、補助記憶装置２０４のＩＤ等が含まれる。その他の非図示のハードウェアのＩＤが含まれてもよい。なお、機器ＩＤは、ＢＩＯＳ（Basic Input/Output System）に問い合わせることに取得される、通信機器２０ごとの識別情報である。ソフトウェアの構成情報には、ＢＩＯＳのバージョン、ＯＳ（Operating System）のバージョン、ＯＳを構成する各ファイルのハッシュ値等が含まれる。ＯＳを構成する各ファイルには、実行形式のプログラムを格納したファイルや、各種の設定情報を格納したファイル等が有る。レポート生成部２１は、また、通信機器２０の固有情報の一例であるＭａｃアドレスを、インタフェース装置２０５より取得する。なお、Ｍａｃアドレスの他に、又はＭａｃアドレスの代わりに「Ｖａｌｉｄａｔｉｏｎ Ｃｒｅｄｅｎｔｉａｌ」が、インタフェース装置２０５より取得され、「Ｖａｌｉｄａｔｉｏｎ Ｃｒｅｄｅｎｔｉａｌ」が通信機器２０の固有情報とされてもよい。「Ｖａｌｉｄａｔｉｏｎ Ｃｒｅｄｅｎｔｉａｌ」は、ＴＰＭの仕様において定義されている、コンポーネンツの電子証明書である。ネットワークインタフェースコンポーネンツ（本実施の形態におけるインタフェース装置２０５）の電子証明書としては、製造メーカ、製造シリアル番号、及びＭａｃアドレス等が記述されていることが想定されている。但し、現時点において、詳細仕様は決定されていない。

レポート生成部２１は、Ｍａｃアドレス、ハードウェアの構成情報、及びソフトウェアの構成情報を含むレポート情報と、レポート情報のハッシュ値とを出力する。

ところで、ＴＰＭは、各ハードウェアや各ソフトウェア等が起動する前において、各ハードウェア及び各ソフトウェアの情報を取得することができる。したがって、セキュリティチップ２０６としてＴＰＭを用いた場合、通信機器２０の起動によって、設定情報等が書き換えられる前の状態の構成情報を収集することができる。すなわち、工場出荷前と同じ状態の構成情報の収集が可能となる。

続いて、証明書発行要求部２２は、機器証明書に対する公開鍵と秘密鍵とのペアを生成する（Ｓ１５）。少なくとも秘密鍵は、例えば、機器証明書記憶部２６に記憶される。なお、ここで生成される公開鍵及び秘密鍵のそれぞれを、「通信機器２０の公開鍵」、「通信機器２０の秘密鍵」という。

続いて、証明書発行要求部２２は、機器証明書の発行要求に対する電子署名を生成する（Ｓ１６）。具体的には、機器証明書の発行要求には、例えば、ＣＳＲ（Certificate Signing Request）等の発行要求を示すデータ、レポート情報、及びレポート情報のハッシュ値等が指定される。また、当該発行要求には、当該通信機器２０の公開鍵、グローバルルーティングプレフィックスマスク、サブネットＩＤマスク、及びプライベートＩＤマスク等も指定される。グローバルルーティングプレフィックスマスクは、ＩＰアドレスの先頭からのグローバルルーティングプレフィックスのビット長である。サブネットＩＤマスクは、グローバルルーティングプレフィックスマスクに続くサブネットＩＤのビット長である。プライベートＩＤマスクは、サブネットＩＤに続くプライベートＩＤのビット長である。本実施の形態では、これらのビット長が固定であるという前提は排除されているため、これらのビット長の指定が必要とされる。

証明書発行要求部２２は、機器証明書の発行要求に指定される全情報のハッシュ値を生成し、当該ハッシュ値を、セキュリティチップ２０６の秘密鍵によって暗号化することにより、当該発行要求に対する電子署名を生成する。なお、セキュリティチップ２０６の秘密鍵は、通信機器２０の秘密鍵とは異なる。セキュリティチップ２０６の秘密鍵は、セキュリティチップ２０６の電子署名を作成するための秘密鍵として、予めセキュリティチップ２０６に記憶されている。

続いて、証明書発行要求部２２は、生成された電子署名を付与して、機器証明書の発行要求を証明書発行装置３０に送信する（Ｓ１７）。なお、証明書発行装置３０のＩＰアドレスは、セキュリティチップ２０６内、又は証明書取得プログラム内に書き込まれていてもよいし、ネットワークを介して取得されてもよい。また、この時点において、通信機器２０には、正式なＩＰアドレスは割り当てられていない。したがって、例えば、仮のＩＰアドレスが設定され、当該ＩＰアドレスを用いられて通信が行われてもよい。仮のＩＰアドレスは、ＤＨＣＰ（Dynamic Host Configuration Protocol）によって割り当てられてもよい。

証明書発行要求部２２によって、機器証明書の発行要求が送信されると、証明書受信部２３は、証明書発行装置３０からの機器証明書の返信を待機する（Ｓ１８）。証明書受信部２３は、機器証明書を受信すると（Ｓ１８でＹｅｓ）、当該機器証明書を、機器証明書記憶部２６に記憶する（Ｓ１９）。続いて、アドレス設定部２４は、当該機器証明書に含まれているＩＰアドレスを、通信機器２０の通信制御部２５に設定する（Ｓ２０）。

続いて、図１１のステップＳ１７において通信機器２０より送信される、機器証明書の発行要求に応じて、証明書発行装置３０が実行する処理について説明する。

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

証明書発行装置３０の発行要求受信部３１は、機器証明書の発行要求の受信を待機している（Ｓ３１）。機器証明書の発行要求が発行要求受信部３１によって受信されると（Ｓ３１でＹｅｓ）、発行要求検証部３２は、当該発行要求に付与されている電子署名を検証する（Ｓ３２）。具体的には、証明書発行装置３０の補助記憶装置３０２には、セキュリティチップ２０６の公開鍵証明書が記憶されている。当該公開鍵証明書には、セキュリティチップ２０６の秘密鍵に対応する公開鍵が含まれている。発行要求検証部３２は、当該電子署名を当該公開鍵によって復号する。発行要求検証部３２は、また、当該発行要求のハッシュ値を算出し、算出されたハッシュ値と、電子署名を復号することにより得られるハッシュ値とを比較する。両者が一致すれば、当該発行要求の送信元の正当性と、当該発行要求が改竄されていないこととが確認される。

続いて、発行要求検証部３２は、当該発行要求に含まれているレポート情報のハッシュ値を算出し、算出されたハッシュ値と、当該発行要求に含まれている、レポート情報のハッシュ値とを比較することにより、レポート情報が改竄されていないことを確認する（Ｓ３３）。続いて、発行要求検証部３２は、当該レポート情報と、ホワイトリスト記憶部３６に記憶されているレコードとを比較する（Ｓ３４）。

図１３は、ホワイトリスト記憶部の構成例を示す図である。ホワイトリスト記憶部３６の各レコードは、機器ＩＤに対応付けて、当該機器ＩＤに係る通信機器２０のレポート情報の正解又は模範解答が記憶されている。図１３では、ＣＰＵのＩＤ及び補助記憶装置のＩＤ等を含むハードウェアの構成情報、ＢＩＯＳのバージョン、ＯＳのバージョン、及びＯＳを構成する各ファイルのハッシュ値等を含むソフトウェアの構成情報、並びにＭａｃアドレス等がレコードを構成する例が示されている。なお、各ハードウェアのＩＤ、各ソフトウェアのバージョン等、及びＭａｃアドレス等は、ハッシュ値に変換されていてもよい。

ステップＳ３４において、発行要求検証部３２は、発行要求に指定されたレポート情報に含まれている機器ＩＤに対応付いているレポート情報を、ホワイトリスト記憶部３６より検索する。発行要求検証部３２は、発行要求に指定されたレポート情報と、検索されたレポート情報とを照合する。すなわち、発行要求に指定されたレポート情報に含まれている、通信機器２０の構成情報とＭａｃアドレスとの組み合わせが、ホワイトリスト記憶部３６に予め記憶されている正解又は模範解答に合致するか否かが判定される。

両者が一致した場合、発行要求検証部３２は、発行要求は正当であると判定する。なお、ステップＳ３４では、発行要求元の通信機器２０が、正規又は所定の構成又は状態であることが確認される。例えば、通信機器２０にインストールされているプログラムが、改竄されていないことが確認される。

このように、ホワイトリスト記憶部３６に記憶されるレポート情報は、機器証明書の発行要求の正当性の検証に利用される。そこで、当該レポート情報は、例えば、企業Ａ以外の信頼できる者から入手されるようにしてもよい。レポート情報の入手先となりうる者としては、例えば、企業Ａに対する通信機器２０の販売者又は製造者が一例として挙げられる。例えば、当該販売者又は製造者は、ＩＳＰからの要請に応じ、企業Ａに対して販売される各通信機器２０の出荷前の状態におけるレポート情報を、ＩＳＰに提供する。ＩＳＰは、提供されたレポート情報をホワイトリスト記憶部３６に設定する。

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

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

一方、ステップＳ３２〜Ｓ３４の処理によって、発行要求は正当であると判定されると（Ｓ３５でＹｅｓ）、アドレス決定部３３は、機器情報記憶部３７を参照して、発行要求元の通信機器２０に対するＩＰアドレスを決定する（Ｓ３６）。

図１４は、機器情報記憶部の構成例を示す図である。図１４において、機器情報記憶部３７の各レコードは、Ｍａｃアドレス、ＩＰアドレス、ドメイン名、所有者名、住所、及び電話番号等を記憶する。

Ｍａｃアドレスは、通信機器２０のＭａｃアドレスである。ＩＰアドレスは、当該Ｍａｃアドレスに係る通信機器２０に対して割り当てられたＩＰアドレスである。ドメイン名は、当該通信機器２０に対するドメイン名である。所有者名は、当該通信機器２０の所有者の名前である。本実施の形態では、企業Ａが通信機器２０の所有者である。住所及び電話番号は、所有者の住所又は電話番号である。

ステップＳ３６では、発行要求に指定されたレポート情報に含まれているＭａｃアドレスに対応付けられているＩＰアドレスが、機器情報記憶部３７より取得される。当該ＩＰアドレスが、発行要求元の通信機器２０に対するＩＰアドレスとして決定される。

なお、発行要求元の通信機器２０に対するＩＰアドレスのインタフェーＩＤは、機器証明書の発行要求に応じて動的に生成されてもよい。例えば、当該ＩＰアドレスのインタフェースＩＤは、発行要求元の通信機器２０のＭａｃアドレス等の固有情報に基づいて、算出されてもよい。

続いて、証明書生成部３４は、発行要求元の通信機器２０に対する機器証明書を生成する（Ｓ３７）。

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

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

続いて、応答返信部３５は、生成された機器証明書を返信する（Ｓ３８）。

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

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

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

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

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

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

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

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

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

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

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

続いて、通信制御部２５は、暗号化されたチャレンジワード、電子署名、及びタイムスタンプ等の認証データを含むパケットを通信制御装置１０に送信する（Ｓ１１３）。以下、認証データを含むパケットを「認証データパケット」という。なお、認証データパケット等、通信制御部２５によって送信されるパケットの送信元ＩＰアドレスは、図１１の処理によって取得された機器証明書に含まれ、ステップＳ２０において通信制御部２５に設定されたＩＰアドレスである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、本実施の形態によれば、機器証明書の発行対象が、正当又は真正な通信機器２０に限定される可能性を高めることができる。すなわち、図１１のステップＳ１７において、証明書発行要求部２２によって送信される機器証明書の発行要求に指定される情報は、セキュリティチップ２０６内の証明書取得プログラムが、セキュリティチップ２０６に実行させる処理によって収集される。一般的に、情報の改竄は、プログラムによって行われる。例えば、インタフェース装置２０５に記憶されているＭａｃアドレスを改変するのは困難であるため、当該Ｍａｃアドレスの改竄は、当該Ｍａｃアドレスを読み出したプログラム内において行われる。本実施の形態では、ステップＳ１２において、証明書取得プログラムが改竄されていないことが、セキュリティチップ２０６によって検証される。また、セキュリティチップ２０６の耐タンパ性により、セキュリティチップ２０６内に記憶されている証明書取得プログラム及びそのハッシュ値を書き換えるのは困難である。したがって、Ｍａｃアドレスや、レポート情報等、セキュリティチップ２０６によって収集され、証明書発行装置３０に送信されるまでの過程において、収集された情報が改竄される可能性は低いといえる。換言すれば、通信機器２０が、自らのＭａｃアドレスや、構成情報等を詐称するのは困難であるといえる。

また、機器証明書の発行要求に指定されるレポート情報は、予め、信頼できるルートで入手され、ホワイトリスト記憶部３６に記憶されているレポート情報の正解又は模範解答と照合される。当該照合によって、例えば、通信機器２０において、不正なプログラムがインストールされたことや、予めインストールされているＯＳ等が改竄されたこと、更に、不正なハードウェアが設置されたこと等を検知することができる。このようなことが検知された場合、ホワイトネットに接続するために必要とされる機器証明書の発行は行われない。したがって、機器構成が不正に改竄された通信機器２０によるホワイトネットへの接続を回避できる可能性を高めることができる。

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

なお、本実施の形態において、セキュリティチップ２０６は、耐タンパ性を有する情報処理装置の一例である。ＩＰアドレスは、通信アドレスの一例である。証明書発行装置３０は、証明書生成装置の一例である。発行要求受信部３１は、受信部の一例である。ホワイトリスト記憶部３６は、証明書生成装置の記憶部の一例である。アドレス決定部３３は、決定部の一例である。証明書生成部３４は、生成部の一例である。応答返信部３５は、証明書生成装置の送信部の一例である。

レポート生成部２１は、収集部の一例である。証明書発行要求部２２は、情報処理装置の送信部の一例である。証明書受信部２３は、受信部の一例である。機器証明書記憶部２６は、情報処理装置の記憶部の一例である。

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

以上の説明に関し、更に以下の項を開示する。
（付記１）
耐タンパ性を有する情報処理装置を備える通信機器から送信される、前記情報処理装置によって収集された前記通信機器の固有情報及び構成情報を受信し、
受信した前記通信機器の固有情報及び構成情報の組み合わせが、記憶部に予め記憶されている情報に合致する場合に、当該固有情報に基づいて、前記通信機器について通信アドレスを決定し、
受信した前記通信機器の固有情報と構成情報とのうち、一部又は全部を含む情報と、決定した前記通信アドレスと、を含む電子証明書を生成し、
前記電子証明書を、前記通信機器に送信する、
処理をコンピュータが実行する証明書生成方法。
（付記２）
前記受信する処理は、前記情報処理装置の秘密鍵による電子署名を更に受信し、
前記決定する処理は、前記電子署名が正当な場合に、前記通信アドレスを決定する付記１記載の証明書生成方法。
（付記３）
耐タンパ性を有する情報処理装置を備える通信機器から送信される、前記情報処理装置によって収集された前記通信機器の固有情報及び構成情報を受信する受信部と、
前記受信部が受信した前記通信機器の固有情報及び構成情報の組み合わせが、記憶部に予め記憶されている情報に合致する場合に、当該固有情報に基づいて、前記通信機器について通信アドレスを決定する決定部と、
前記受信部が受信した前記通信機器の固有情報と構成情報とのうち、一部又は全部を含む情報と、前記決定部が決定した前記通信アドレスと、を含む電子証明書を生成する生成部と、
前記電子証明書を、前記通信機器に送信する送信部と、
を有する証明書生成装置。
（付記４）
通信機器が備える耐タンパ性を有する情報処理装置であって、
前記通信機器の固有情報と前記通信機器の構成情報とを収集する収集部と、
収集された前記固有情報及び前記構成情報を含み、当該情報処理装置の秘密鍵によって電子署名が付与された、電子証明書の発行要求を送信する送信部と、
前記発行要求に応じて返信される電子証明書を受信する受信部と、
受信された電子証明書を記憶する記憶部と、
を有する情報処理装置。
（付記５）
耐タンパ性を有する情報処理装置を備える通信機器であって、
前記情報処理装置に記憶されている、当該通信機器の通信アドレスと当該通信機器の固有情報とを含む電子証明書に対応する秘密鍵による電子署名と、前記通信アドレスとを含むデータを送信する送信部を有する通信機器。
（付記６）
耐タンパ性を有する情報処理装置を備える通信機器に、
前記情報処理装置に記憶されている、当該通信機器の通信アドレスと当該通信機器の固有情報とを含む電子証明書に対応する秘密鍵による電子署名と、前記通信アドレスとを含むデータを送信する処理を実行させるプログラム。

１０ 通信制御装置
１１ 認証要求受付部
１２ 認証データ検証部
１３ ルーティング部
１４ 再認証要求部
１５ 証明書リスト記憶部
１６ セッション情報記憶部
１７ ルーティングポリシー記憶部
１８ ルーティング情報記憶部
２０ 通信機器
２１ レポート生成部
２２ 証明書発行要求部
２３ 証明書受信部
２４ アドレス設定部
２５ 通信制御部
２６ 機器証明書記憶部
３０ 証明書発行装置
３１ 発行要求受信部
３２ 発行要求検証部
３３ アドレス決定部
３４ 証明書生成部
３５ 応答返信部
３６ ホワイトリスト記憶部
３７ 機器情報記憶部
４０ サーバ装置
４１ サーバ通信部
４２ サブネット証明書記憶部
５０ 負荷分散装置
６０ 証明書取得装置
２０１ ＲＯＭ
２０２ ＲＡＭ
２０３ ＣＰＵ
２０４ 補助記憶装置
２０５ インタフェース装置
２０６ セキュリティチップ
３００ ドライブ装置
３０１ 記録媒体
３０２ 補助記憶装置
３０３ メモリ装置
３０４ ＣＰＵ
３０５ インタフェース装置
Ｂ バス

Claims (4)

1. 耐タンパ性を有する情報処理装置を備える通信機器から送信される、前記情報処理装置によって収集された前記通信機器の固有情報及び構成情報を受信し、
   受信した前記通信機器の固有情報及び構成情報の組み合わせが、記憶部に予め記憶されている情報に合致する場合に、当該固有情報に基づいて、前記通信機器について通信アドレスを決定し、
   受信した前記通信機器の固有情報と構成情報とのうち、一部又は全部を含む情報と、決定した前記通信アドレスと、を含む電子証明書を生成し、
   前記電子証明書を、前記通信機器に送信する、
   処理をコンピュータが実行する証明書生成方法。
2. 前記受信する処理は、前記情報処理装置の秘密鍵による電子署名を更に受信し、
   前記決定する処理は、前記電子署名が正当な場合に、前記通信アドレスを決定する請求項１記載の証明書生成方法。
3. 耐タンパ性を有する情報処理装置を備える通信機器から送信される、前記情報処理装置によって収集された前記通信機器の固有情報及び構成情報を受信する受信部と、
   前記受信部が受信した前記通信機器の固有情報及び構成情報の組み合わせが、記憶部に予め記憶されている情報に合致する場合に、当該固有情報に基づいて、前記通信機器について通信アドレスを決定する決定部と、
   前記受信部が受信した前記通信機器の固有情報と構成情報とのうち、一部又は全部を含む情報と、前記決定部が決定した前記通信アドレスと、を含む電子証明書を生成する生成部と、
   前記電子証明書を、前記通信機器に送信する送信部と、
   を有する証明書生成装置。
4. 通信機器が備える耐タンパ性を有する情報処理装置であって、
   前記通信機器の固有情報と前記通信機器の構成情報とを収集する収集部と、
   収集された前記固有情報及び前記構成情報を含み、当該情報処理装置の秘密鍵によって電子署名が付与された、電子証明書の発行要求を送信する送信部と、
   前記発行要求に応じて返信される電子証明書を受信する受信部と、
   受信された電子証明書を記憶する記憶部と、
   を有する情報処理装置。

Images