(57)【要約】【課題】対応すべき証明書の種類が増えても、公開暗号の秘密鍵を用いる処理の追加変更をすることなく拡張できる。【解決手段】ＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）クライアント１とＭ個のアクセスゲートウェイ３、４、５はそれぞれ公開鍵暗号の鍵対（秘密鍵および公開鍵）を所有している。ＶＰＮクライアント１からアクセスゲートウェイ３、４、５に、ＰＫＩ（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）による署名を用いた認証情報を送ると、アクセスゲートウェイは、その認証情報を検証する処理をアクセスゲートウェイではなく認証サーバプロキシ７を介して認証サーバ８、９、１０に依頼し検証結果のみを受け取る。逆に、アクセスゲートウェイからＶＰＮクライアントに対して送るための、ＰＫＩによる署名を用いた認証情報を作成する時には、アクセスゲートウェイのみで行う。このようにして、アクセスゲートウェイと認証サーバが役割分担をしながら一連のＰＫＩ対応を実現する。【選択図】　　　　図１
2004032311.tif 000002
【特許請求の範囲】
【請求項１】
ＰＫＩ対応のエンドエンティティを用いて証明書の確認処理を行うＰＫＩ対応の証明書確認処理方法において、
少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、
次いで前記抽出データに基づいてクライアント証明書の確認処理を行うことを特徴とするＰＫＩ対応の証明書確認処理方法。
【請求項２】
前記証明書の確認処理は、前記抽出データに基づいて証明書の内容を解析し、その解析データに基づいて証明書の検証を行い、その検証結果に基づいて検証結果の問合せに応答することを特徴とする請求項１に記載のＰＫＩ対応の証明書確認処理方法。
【請求項３】
前記証明書の確認処理を並列処理することを特徴とする請求項１又は２に記載のＰＫＩ対応の証明書確認処理方法。
【請求項４】
ＰＫＩ対応のエンドエンティティを用いて証明書の確認処理を行うＰＫＩ対応の証明書確認処理装置において、
前記ＰＫＩ対応のエンドエンティティの機能部は、第１の機能部と第２の機能部とに分割されており、
前記第１の機能部は、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、その抽出データを前記第２の機能部に出力するものであり、
前記第２の機能部は、前記第１の機能部から入力される前記抽出データに基づいてクライアント証明書の確認処理を行うものであることを特徴とするＰＫＩ対応の証明書確認処理装置。
【請求項５】
前記第２の機能部は、前記抽出データに基づいて証明書の内容を解析し、その解析データに基づいて証明書の検証を行い、検証結果の問合せに前記検証結果に基づいて応答することにより、前記証明書の確認処理を実行するものであることを特徴とする請求項４に記載のＰＫＩ対応の証明書確認処理装置。
【請求項６】
前記第２の機能部は、前記証明書の確認処理を並列処理するものであることを特徴とする請求項４又は５に記載のＰＫＩ対応の証明書確認処理装置。
【請求項７】
前記第２の機能部は、認証サーバプロキシと認証部とを有しており、
前記認証サーバプロキシは、前記抽出データに含まれる証明書の種類を識別し、その種類に対応して証明書の確認処理を振り分け、また検証結果の問合せに応答するものであり、
前記認証部は、証明書の種類に対応して前記認証サーバプロキシにより振り分けられた前記抽出データに基づいて証明書の確認処理を行い、その検証結果を前記認証サーバプロキシに出力するものであることを特徴とする請求項４又は５に記載のＰＫＩ対応の証明書確認処理装置。
【請求項８】
前記認証部は、認証サーバと証明書検証サーバとを有しており、
前記認証サーバは、前記証明書の内容を解析し、証明書検証の要求を前記証明書検証サーバに出力し、また前記認証サーバプロキシの検証結果問合せに応答するものであり、
前記証明書検証サーバは、前記認証サーバの証明書検証要求に対応して前記認証サーバの解析データに基づいて証明書の検証を行い、その検証結果を前記認証サーバに出力するものであることを特徴とする請求項７に記載のＰＫＩ対応の証明書確認処理装置。
【請求項９】
前記認証サーバは、前記証明書検証サーバの機能を兼ね備えていることを特徴とする請求項８に記載のＰＫＩ対応の証明書確認処理装置。
【請求項１０】
ＰＫＩ対応のエンドエンティティに組み込まれて証明書の確認処理を行うＰＫＩ対応の証明書確認処理プログラムにおいて、
ＰＫＩ対応のエンドエンティティの機能部を第１の機能部と第２の機能部とに機能別に分割してソフトウェアにより構築したものであり、
前記第１の機能部は、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、その抽出データを前記第２の機能部に出力する機能を実行するソフトウェアであり、
前記第２の機能部は、前記第１の機能部から入力される前記抽出データに基づいてクライアント証明書の確認機能を実行するソフトウェアであり、
これらのソフトウェアは、コンピュータを機能させるためのものであることを特徴とするＰＫＩ対応の証明書確認処理プログラム。
【請求項１１】
前記第２の機能部を構成するソフトウェアは、前記抽出データに基づいて証明書の内容を解析し、その解析データに基づいて証明書の検証を行い、その検証結果に基づいて検証結果の問合せに応答することにより、前記証明書の確認機能を実行するものであることを特徴とする請求項１０に記載のＰＫＩ対応の証明書確認処理プログラム。
【請求項１２】
前記第２の機能部を構成するソフトウェアは、前記証明書の確認を並列処理するものであることを特徴とする請求項１０又は１１に記載のＰＫＩ対応の証明書確認処理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、公開鍵インフラストラクチャ（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ；ＰＫＩ）対応の証明書確認処理方法及びその装置、並びにＰＫＩ対応の証明書確認処理プログラムに関する。
【０００２】
【従来の技術】
従来、ＰＫＩ対応のエンドエンティティは、ＰＫＩ対応に必要な署名、証明書発行要求、証明書内容解析、証明書検証などの確認処理機能を全て備えているか、或いは、この確認処理機能を全く備えずに該エンドエンティティとオンライン接続されるプロキシ機能部にエンドエンティティ自身の秘密鍵と証明書の管理とを含めて全て任せるかのいずれか一方の構成であった。
【０００３】
【発明が解決しようとする課題】
証明書の確認処理機能を全て備えた、すなわちＰＫＩに１００％対応したエンドエンティティの場合には、ＰＫＩに対応させるための開発コストが莫大となり、エンドエンティティのＰＫＩ対応の促進を妨げる要因となっていた。
【０００４】
仮に、エンドエンティティ側でＰＫＩ仕様を固定化して、その仕様に合わせて最小限のＰＫＩ対応を実現した場合には、証明書確認処理の対象として、前記固定したＰＫＩ仕様と異なるＰＫＩ仕様による通信相手が現れたときに、その通信相手との通信を中止して証明書の確認処理を拒否せざるを得ないこととなる。
【０００５】
これを避けるためには、エンドエンティティ側でＰＫＩ仕様を固定化しないこととなるが、証明書の確認処理の対象となる通信相手の複数種のＰＫＩ仕様に対応させて、証明書内容解析機能や証明書検証ポリシを変更し、カスタマイズの開発が必要となる。例えば、ＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）クライアントに対応するＭ個のアクセスゲートウェイがＰＫＩ対応済みの証明書確認機能を有している場合に、新たに異なる仕様の証明書が確認処理対象に加わったときには、前記Ｍ個のアクセスゲートウェイの全てに新たに加わった証明書の仕様を解析するためのルール機能を追加する管理を行う必要がある。
【０００６】
上述したようなカスタマイズの開発及び管理の方法による、アクセスゲートウェイのようなエンドエンティティへのＰＫＩ対応策は、開発コストが莫大となるばかりでなく、管理コストを抑制することができず却って上昇させてしまうこととなり、現実的な解決策とはならないという問題があった。
【０００７】
そこで、証明書確認処理用プログラムを階層構造（Ｈｉｅｒａｒｃｈｉｃａｌ　Ｓｔｒｕｃｔｕｒｅ）とすることにより、該プログラムの開発やメンテナンスの生産性を向上させる方法や、複数存在する認証局（ＣＡ；Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ）をブリッジ型に連携させる方法が考えられている。
【０００８】
しかし、例えば、企業のＰＫＩのように多数の利用目的がある中で、ある目的に特化して、企業ごとのＣＡを連携させるということは、現実問題として技術的に難しく、解決策として採用されていないのが実情である。
【０００９】
一方、証明書の確認処理機能を備えていない、すなわちＰＫＩに１００％対応していないエンドエンティティの場合には、該エンドエンティティにオンライン接続されるプロキシ機能部が該エンドエンティティの秘密鍵と証明書との管理をオンラインで行うため、エンドエンティティとプロキシ機能部との間における通信の安全性と、プロキシ機能部自身の安全性確保との両方の問題を解決する必要があり、その解決に莫大な費用を要するという問題がある。
【００１０】
【発明の目的】
本発明の目的は、ＰＫＩ対応の証明書確認処理方法及びその装置、並びにＰＫＩ対応の証明書確認処理プログラムを提供することにある。
【００１１】
【課題を解決するための手段】
前記目的を達成するため、本発明に係るＰＫＩ対応の証明書確認処理方法は、ＰＫＩ対応のエンドエンティティを用いて証明書の確認処理を行うＰＫＩ対応の証明書確認処理方法において、
少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、
次いで前記抽出データに基づいてクライアント証明書の確認処理を行うことを特徴とするものである。
【００１２】
また、前記証明書の確認処理は、前記抽出データに基づいて証明書の内容を解析し、その解析データに基づいて証明書の検証を行い、その検証結果に基づいて検証結果の問合せに応答することが望ましく、また前記証明書の確認処理を並列処理することが望ましいものである。
【００１３】
本発明において、ＰＫＩによる署名を用いた証明書の認証情報が入力すると、その認証情報を検証するために、先ず、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離する。必要なデータが抽出された後、その抽出データに基づいてクライアント証明書の確認処理を行う。前記公開鍵を用いる証明書の確認処理は、公開鍵暗号方式の秘密鍵を用いてＰＫＩによる認証情報を作成して通信相手方に送出する処理から分離独立させて行われる。
【００１４】
本発明によれば、機能の役割分担をしながら一連のＰＫＩ対応を実現することにより、対応すべき仕様の異なる新たな種類の証明書が認証対象に加わったとしても、公開鍵を用いる証明書の確認ステップのみを追加するのみで対処することができ、秘密鍵を用いる処理ステップを含めた全体の処理ステップを変更する必要がなく、柔軟なＰＫＩ対応を実現できるという効果を奏するものである。この効果は、前記証明書の確認処理を並列処理する場合に顕著に発揮される。
【００１５】
上述した本発明に係るＰＫＩ対応の証明書確認処理方法に使用するＰＫＩ対応の証明書確認処理装置は、ＰＫＩ対応のエンドエンティティを用いて証明書の確認処理を行うＰＫＩ対応の証明書確認処理装置において、前記ＰＫＩ対応のエンドエンティティの機能部は、第１の機能部と第２の機能部とに分割されており、
前記第１の機能部は、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、その抽出データを前記第２の機能部に出力するものであり、
前記第２の機能部は、前記第１の機能部から入力される前記抽出データに基づいてクライアント証明書の確認処理を行うものであることを特徴とするものである。
【００１６】
また前記第２の機能部は、前記抽出データに基づいて証明書の内容を解析し、その解析データに基づいて証明書の検証を行い、検証結果の問合せに前記検証結果に基づいて応答することにより、前記証明書の確認処理を実行するように構成することが望ましい。また前記第２の機能部は、前記証明書の確認処理を並列処理する構成とすることが望ましいものである。
【００１７】
本発明において、前記第１の機能部と、該第１の機能部の相手方とは、それぞれ公開鍵暗号の鍵対（秘密鍵および公開鍵）を所有している。前記相手方から前記第１の機能部に対して、ＰＫＩによる署名を用いた認証情報が送くられると、第１の機能部は、その認証情報を検証する処理を自身で行わずに前記第２の機能部に依頼し、その検証結果のみを受け取る。逆に、第１の機能部から相手方に対して送るための、ＰＫＩによる署名を用いた認証情報を作成する時には、第１の機能部のみで行う。
【００１８】
このようにして、第１の機能部と第２の機能部との２つのエンティティが役割分担をしながら一連のＰＫＩ対応を実現することにより、対応すべき証明書の種類が増えたときにも、第１機能部には、証明書の確認処理機能を追加する必要はなくなり、第１の機能部のみで１００％ＰＫＩに対応させるよりも柔軟なＰＫＩ対応を実現できるという効果を奏するものである。
【００１９】
前記装置はハードウェアとして構築したが、ＰＫＩ対応のエンドエンティティの機能部を第１の機能部と第２の機能部とに機能別に分割してソフトウェアにより構築してもよく、前記第１の機能部は、公開鍵を用いて少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、その抽出データを前記第２の機能部に出力する機能を実行するソフトウェアとして構築し、前記第２の機能部は、前記第１の機能部から入力される前記抽出データに基づいてクライアント証明書の確認機能を実行するソフトウェアとして構築する。これらのソフトウェアは、コンピュータを機能させるためのものである。
【００２０】
このように、ＰＫＩ対応のエンドエンティティの機能部をソフトウェアで構成してＰＫＩ対応の証明書確認処理プログラムとすることにより、このプログラムを既存のコンピュータ、特にパーソナルコンピュータにインストールして証明書の認証を安全にかつ迅速に行うことができるという効果を奏するものである。
【００２１】
本発明は、上述した内容に限られることはなく、発明の趣旨の範囲内で種々変更が可能であり、その詳細な内容について下記の実施形態を用いて説明する。
【００２２】
【発明の実施の形態】
図１に示すように本発明の特徴は、ＰＫＩ対応ずみのＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）クライアント１がアクセスゲートウェイ３、４、５とのＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を構築するためにＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）などによる鍵交換を行う場合、特に、公開鍵暗号の署名機能を利用した認証方式に着目している点にある。上述した本発明の特徴は、一部の構成が変更されているが、図１以外に示す他の実施形態においても共通している。
【００２３】
上述したように本発明に係るＰＫＩ対応の証明書確認処理方法は、ＰＫＩ対応のエンドエンティティを用いて証明書の確認処理を行うＰＫＩ対応の証明書確認処理方法において、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、次いで前記抽出データに基づいてクライアント証明書の確認処理を行うことを特徴とするものであり、次に図面を用いて本発明に係るＰＫＩ対応の証明書確認処理方法に使用する証明書確認処理装置の実施形態について説明する。
【００２４】
本発明に係るＰＫＩ対応の証明書確認処理装置は基本的構成として、ＰＫＩ対応のエンドエンティティの機能部は、第１の機能部と第２の機能部とに分割しており、前記第１の機能部は、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、その抽出データを前記第２の機能部に出力するものであり、前記第２の機能部は、前記第１の機能部から入力される前記抽出データに基づいてクライアント証明書の確認処理を行うようになっている。
【００２５】
図１に示す実施形態では、前記第１の機能部は、ＰＫＩ対応ずみのＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）クライアント１に対応して複数（Ｍ個）存在するアクセスゲートウェイ３、４、５と、前記複数のアクセスゲートウェイ３、４、５に対応するＭ個（複数）の証明書を発行するゲートウェイＣＡ６とを有している。この構成により前記第１の機能部は、少なくともユーザＩＤデータ，クライアント証明書データ，署名対象データ及び署名データを抽出分離し、その抽出データを出力する機能を実行するようになっている。２は、前記ＶＰＮクライアント１の証明書を発行するクライアントＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ；認証局）である。
【００２６】
前記第２の機能部は、前記第１の機能部から入力される前記抽出データに基づいてクライアント証明書の確認処理を行う、より具体的には前記抽出データに基づいて証明書の内容を解析し、その解析データに基づいて証明書の検証を行い、検証結果の問合せに前記検証結果に基づいて応答することにより、前記証明書の確認機能を実行するようになっており、前記第２の機能部は、認証サーバプロキシと認証部とを有している。
【００２７】
前記認証サーバプロキシは、前記抽出データに含まれる証明書の種類を識別し、その種類に対応して証明書の確認処理を振り分け、また検証結果の問合せに応答するものであり、図１に示す実施形態では、認証サーバプロキシ７により構成している。
【００２８】
前記認証部は、証明書の種類に対応して前記認証サーバプロキシ７により振り分けられた前記抽出データに基づいて証明書の確認処理を行い、その検証結果を前記認証サーバプロキシ７に出力するものであり、より具体的には、認証サーバと証明書検証サーバとを有しており、前記認証サーバは、前記証明書の内容を解析し、証明書検証の要求を前記証明書検証サーバに出力し、また前記認証サーバプロキシの検証結果問合せに応答するようになっており、前記証明書検証サーバは、前記認証サーバの証明書検証要求に対応して前記認証サーバの解析データに基づいて証明書の検証を行い、その検証結果を前記認証サーバに出力するようになっている。図１に示す実施形態では、複数（Ｎ個）存在する認証サーバ８、９、１０と、前記複数の認証サーバ８、９、１０に対応する複数の証明書検証サーバ１１、１３、１５とを含んでいる。この構成により前記第２の機能部は、証明書の確認処理を並列処理するようになっている。
【００２９】
図１では、前記複数のアクセスゲートウェイのうち、ＶＰＮの終端となる１個目のアクセスゲートウェイを符号３、ＶＰＮの終端となる２個目のアクセスゲートウェイを符号４、ＶＰＮの終端となるＭ個目のアクセスゲートウェイを符号５でそれぞれ示している。また、前記複数（Ｎ個）の認証サーバのうち、認証サーバプロキシ７で１個目のアクセスゲートウェイ３に対応するように振り分けられる１個目の認証サーバを符号８、認証サーバプロキシ７で２個目のアクセスゲートウェイ４に対応するように振り分けられる２個目の認証サーバを符号９、認証サーバプロキシ７でＭ個目のアクセスゲートウェイ５に対応するように振り分けられるＮ個目の認証サーバを符号１０でそれぞれ示している。また、１個目の認証サーバ８に対応する証明書検証サーバを符号１１、２個目の認証サーバ９に対応する証明書検証サーバを符号１３、Ｎ個目の認証サーバ１０に対応する証明書検証サーバを符号１５でそれぞれ示している。
【００３０】
また図１では、前記証明書検証サーバ１１、１３、１５は、それぞれ証明書検証用データ１２、１４、１６を所有しているが、これらの証明書検証用データ１２、１４、１６は、それぞれ認証サーバ８、９、１０が所有する、すなわち認証サーバ８、９、１０は証明書検証サーバ１１、１３、１５の前記機能を兼ね備えるようにしてもよい。これらの証明書検証用データ１２、１４、１６を認証サーバ８、９、１０が所有する構成では、それぞれに対応する証明書検証サーバ１１、１３、１５は不要となり、その分だけ構成を簡素することができるという利点がある。
【００３１】
図２を用いて、図１に示すアクセスゲートウェイ（３、４、５）、認証サーバプロキシ（７）及び認証サーバ（８、９、１０）の具体的構成について説明する。図２では、一のアクセスゲートウェイ３の構成と、これに対応する認証サーバ１０の構成と、認証サーバプロキシ７との構成について図示している。
【００３２】
図２において、アクセスゲートウェイ３と認証サーバ１０と間の通信は、ＲＡＤＩＵＳ（Ｒｅｍｏｔｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｄｉａｌ−ｉｎ　Ｕｓｅｒ　Ｓｅｒｖｉｃｅ）やＤＩＡＭＥＴＥＲなどの既存の認証情報運搬プロトコルによって行われる。
【００３３】
アクセスゲートウェイ３は、鍵対作成手段（鍵対作成機能）３００、署名手段（署名機能）３０１、復号化手段（復号化機能）３０２、署名検証要求手段（署名検証要求機能）３０３及び鍵交換処理手段（鍵交換処理機能）３０４を有している。
【００３４】
前記鍵対作成手段３００は、公開鍵暗号における秘密鍵と公開鍵との鍵対を作成する処理を行うものであり、この機能はオプショナルなものである。前記署名手段３０１は、鍵対作成手段３００が作成する鍵対（秘密鍵と公開鍵）のうち秘密鍵により、入力データに対して署名を生成する処理を行うものである。
【００３５】
また前記復号化手段３０２は、鍵対作成手段３００が作成する鍵対（秘密鍵と公開鍵）のうち秘密鍵により、入力データを復号する処理を行うものである。前記署名検証要求手段３０３は、ＶＰＮクライアント１から受け取った署名データを、ＶＰＮクライアント１のユーザＩＤ及びＶＰＮクライアント１の証明書とともに前記認証サーバプロキシ７に送信して署名検証を要求し、認証サーバプロキシ７から署名検証の結果を受け取る処理を行うものである。
【００３６】
前記鍵交換処理手段３０４は、ＶＰＮクライアント１との間でＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）などの鍵交換プロトコルにより鍵交換の処理を行うものである。
【００３７】
なお、他のアクセスゲートウェイ４、５は、一のアクセスゲートウェイ３と同様に鍵対作成手段（３００）、署名手段（３０１）、復号化手段（３０２）、署名検証要求手段（３０３）及び鍵交換処理手段（３０４）を有している点では一のアクセスゲートウェイ３と共通するが、鍵対作成手段が作成する秘密鍵及び公開鍵と、ゲートウェイＣＡ６が作成する証明書の種類の点で相違している。
【００３８】
前記認証サーバプロキシ７は認証サーバ振分手段７００を有している。前記認証サーバ振分手段７００は、アクセスゲートウェイ（３、４、５）から受け取ったＶＰＮクライアント１のユーザＩＤ等のデータに基づいて適切な認証サーバ（８、９、１０）を決定し、その決定した認証サーバに、署名データ、ＶＰＮクライアント１のユーザＩＤ、ＶＰＮクライアント１の証明書を送信して前記認証サーバに署名検証を要求し、認証サーバからの認証結果を受け取り、これをアクセスゲートウェイに送る処理を行うものである。
【００３９】
前記認証サーバ１０は、証明書内容解析手段（証明書内容解析機能）１０００、署名検証手段（署名検証機能）１００１及び証明書検証要求手段（証明書検証要求機能）１００２を有している。
【００４０】
前記証明書内容解析手段１０００は、認証サーバプロキシ７から受信した証明書を解析し、ＶＰＮクライアント１のユーザＩＤ情報を取り出す処理を行うものである。前記署名手段１００１は、認証サーバプロキシ７から受信した署名データを、同じく受信したＶＰＮクライアント１の証明書を使って検証し、その検証結果を認証サーバプロキシ７に送信する処理を行うものである。前記証明書検証要求手段１００２は、認証サーバプロキシ７から受信したＶＰＮクライアント１の証明書を、証明書検証サーバ１５に送信し、該証明書検証サーバ１５からの検証結果を受け取り、これを認証サーバプロシキ７に送信する処理を行うものである。
【００４１】
前記認証サーバ１０が所有する証明書検証用データ１６には、クライアントＣＡ２が発行する、クライアントＣＡ２のＣＲＬ（クライアントＣＡ２を特定するための情報）と、クライアントＣＡ２自身の証明書とが含まれる。また前記証明書検証用データ１２、１４には、クライアントＣＡ２以外のクライアントが発行する、クライアントＣＡ　ＣＲＬと、クライアントＣＡ２以外のクライアントＣＡ証明書とが含まれるものとする。なお、前記ＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ）は、クライアントＣＡ２が発行したＶＰＮクライアント証明書のうち、証明を取り消したＶＰＮクライアント証明書について、証明書のシリアル番号と取り消し日時をリストに記したデータでり、このデータにも、クライアントＣＡ２の秘密鍵を用いた署名が行われている。
【００４２】
図１を参照すると、ＶＰＮクライアント１は既存のＰＫＩ対応が行われている。そして、ＶＰＮクライアント１はあらかじめクライアントＣＡ２から既存の方法によりＶＰＮクライアント１の証明書発行を受け、この証明書を所有している。また、アクセスゲートウェイ３、４、５はあらかじめゲートウェイＣＡ６から既存の方法により、直接的または間接的にアクセスゲートウェイ３、４、５の証明書の発行をそれぞれ受け、この証明書をそれぞれ所有している。なお、例えば、鍵対作成手段３００によってアクセスゲートウェイ３の内部で作成した公開鍵を取り出し、ゲートウェイＣＡ６にネットワークを通じて、またはネットワーク以外の方法を用いてアクセスゲートウェイ３の証明書の発行を受けてもよい。また、ゲートウェイＣＡ６などによりアクセスゲートウェイ３、４、５の巳秘密鍵と公開鍵との鍵対をそれぞれ作成し、この鍵を使ってゲートウェイＣＡ６から証明書の発行を受けてもよい。
【００４３】
次に、図３のシーケンスチャートを参照して本発明の全体の動作について詳細に説明する。まず、ＶＰＮクライアント１がユーザＩＤをアクセスゲートウェイ３に送り（ステップＡ１）、アクセスゲートウェイ３がＶＰＮクライアント１に該アクセスゲートウェイ３のユーザＩＤ（アクセスサーバＩＤ）を送る（ステップＢ１）。
【００４４】
次に、ＶＰＮクライアント１では、アクセスゲートウェイ３とのやりとりによって得られる乱数等からなる署名対象データに対して、ＰＫＩの署名機能により署名を行って署名データを作成し、この署名データをＶＰＮクライアント１の証明書とともにアクセスゲートウェイ３に送る（ステップＡ２）。
【００４５】
アクセスゲートウェイ３では、ＶＰＮクライアント１から受け取った、ユーザＩＤ、ＶＰＮクライアント１の証明書、署名データと、アクセスゲートウェイ３が所有する署名対象データを署名検証要求手段３０３を使って認証サーバプロキシ７に出力する（ステップＢ２）。
【００４６】
認証サーバプロキシ７では、アクセスゲートウェイ３から受け取った、ＶＰＮクライアントのユーザＩＤ、ＶＰＮクライアント１の証明書、署名対象データ及び署名データに基づいてクライアント１のユーザＩＤパターンを得て、認証サーバリスト１７を使用して認証サーバ振分手段７００で、アクセスゲートウェイ３からのデータを渡すべき適切な認証サーバを振分決定する。この場合、認証サーバ１０が選択決定されたものとする。
【００４７】
認証サーバプロキシ７は、認証サーバ振分手段７００で認証サーバ１０を選択決定した場合に、アクセスゲートウェイ３から受け取った、ＶＰＮクライアント１のユーザＩＤ、ＶＰＮクライアント１の証明書、署名データ、署名対象データを該認証サーバ１０に送る（ステップＣ１）。
【００４８】
選択決定された認証サーバ１０は、認証サーバプロキシ７から前記データを受け取ると、署名検証手段１００１により署名データと署名対象データが正しいことの確認を行い、かつＶＰＮクライアント１の証明書を使った署名データの署名検証を行う。
【００４９】
次に、認証サーバ１０は、証明書内容解析手段１０００によりＶＰＮクライアント１の証明書の内容解析を行い、ユーザＩＤがＶＰＮクライアント１の証明書に含まれているかを確認する。ここで、受け取ったユーザＩＤがＶＰＮクライアント１の証明書に含まれるユーザＩＤと完全一致している必要はなく、システムごとに確認ルールを決め、認証サーバ１０にてそのルールに従った確認を行う。
【００５０】
続いて、認証サーバ１０は、証明書検証要求手段１００２により、ＶＰＮクライアント１の証明書検証要求を対応する証明書検証サーバ１５に送る（ステップＤ１）。
【００５１】
証明書検証サーバ１５は、前記認証サバー１０から証明書検証要求を受け取ると、証明書検証用データ１６を用いてＶＰＮクライアント１の証明書の検証を行い、その証明書の検証結果を認証サーバ１０に送り返す（ステップＥ１）。ここで、認証サーバ１０は、証明書検証サーバ１５に代って証明書検証用データ（１６）を所有する、すなわち証明書検証サーバ１５が不要である構成とした場合には、直接にＶＰＮクライアント１の証明書を検証するようにしてもよい。
【００５２】
認証サーバ１０は、署名検証手段１００１で検証された署名検証結果を、認証サーバプロキシ７に送り返す（ステップＤ２）。
【００５３】
認証サーバプロキシ７は、認証サーバ１０から署名検証結果を受け取ると、これをアクセスゲートウェイ３に送る（ステップＣ２）。アクセスゲートウェイ３は、認証サーバプロキシ７から受け取った署名検証結果が正しければ、ＶＰＮクライアント１とのやりとりによって得られる、乱数等からなる署名対象データに対して、署名手段３０１により署名を行い、ゲートウェイＣＡ６がアクセスゲートウェイ３について発行した証明書とともに、ＶＰＮクライアント１に送る（ステップＢ３）。
【００５４】
ＶＰＮクライアント１は、アクセスゲートウェイ３から受け取った証明書及び署名のデータに対して、通常のＰＫＩ対応機能を利用して、署名検証および証明書検証、アクセスゲートウェイ３のユーザＩＤ確認を行うことによって、アクセスゲートウェイ３を認証する。
【００５５】
以上のように公開暗号の公開鍵を用いた処理が行われて相互認証が終了すると、ＶＰＮクライアント１とアクセスゲートウェイ３との間の処理は秘密鍵を使った処理を行うための鍵交換フェーズに移行し、ＶＰＮクライアント１とアクセスゲートウェイ３との間で鍵交換処理手段３０４を使って鍵が共有される。
【００５６】
本発明の実施形態において、認証サーバ８、９、１０及び証明書検証サーバ１１、１３、１５による認証対象以外のクライアントＣＡの証明書が認証対象に加わった場合には、その新たに加わったクライアントとの間に秘密鍵を用いて相互の認証を行うためのアクセスゲートウェイと、その認証を行うのに必要な認証サーバ及び証明書検証サーバ並びに証明書検証用データを追加することとなる。アクセスゲートウェイは必ずしも追加する必要はない。
【００５７】
アクセスゲートウェイを追加した場合、アクセスゲートウェイにはクライアントの証明書データを組み込む必要がなく、汎用のアクセスゲートウェイを追加すればよく、しかも前記アクセスゲートウェイに対応して追加される認証サーバ及び証明書検証サーバ並びに証明書検証用データは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することが可能となる。
【００５８】
次に、具体例を用いて更に詳細に説明する。図１のように、ＶＰＮクライアント１からアクセスゲートウェイ３にアクセスすると、ＶＰＮクライアント１とアクセスゲートウェイ３との間において、まず最初にユーザＩＤの交換等が行われる。この交換されるユーザＩＤを”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”とする。
【００５９】
アクセスゲートウェイ３は、ＶＰＮクライアント１を認証するために、ＶＰＮクライアント１からアクセスゲートウェイ３にＰＫＩによる署名データとクライアント証明書とを送る。
【００６０】
アクセスゲートウェイ３は、ＶＰＮクライアント１からの署名データの確認を自ら行うのではなく、署名検証要求手段３０３により認証サーバプロキシ７に署名検証要求を行う。つまり、図３のステップＢ２のように、アクセスゲートウェイ３は、ＶＰＮクライアント１から受け取った、ユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”、クライアント１の証明書、署名対象データ、署名データを署名検証要求手段３０３を介して認証サーバプロキシ７に送る。
【００６１】
認証サーバプロキシ７は、アクセスゲートウェイ３から受け取ったユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”から”ａｂｃ（ホスト名）”というパターンを認証サーバ振分手段７００により取り出し、前記パターン（ａｂｃ）に基づいて認証サーバリスト１７を参照し認証サーバ１０を選ぶ。図２の実施形態では、パターンがａｂｃの場合には認証サーバ１０を、パターンがｄｅｆの場合には認証サーバ９を、パターンがｇｈｉの場合には認証サーバ８をそれぞれ選択決定するように設定しているが、これらに限定されるものではない。
【００６２】
認証サーバプロキシ７は、認証サーバ１０を選択決定した場合に、アクセスゲートウェイ３から受け取った全ての情報、つまり、ユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”、クライアント証明書、署名対象データ、署名データを認証サーバ１０に送る。
【００６３】
認証サーバ１０は、認証サーバプロキシ７からデータを受け取ると、証明書内容解析手段１０００によりクライアント証明書の内容を解析し、その解析結果により、ユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”がクライアント証明書の決められた箇所に含まれる（換言すれば、記載されている）ことの確認、署名検証を行う。
【００６４】
さらに認証サーバ１０は、クライアント１の証明書を検証するために、証明書検証要求手段１００２により証明書検証サーバ１５にクライアント１の証明書の検証要求を送る。
【００６５】
証明書検証サーバ１５は、認証サーバ１０からの証明書検証の要求を受け取ると、ＶＰＮクライントのユーザＩＤ、クライアントＣＡ証明書、署名対象データ、署名データ、クライアントＣＡ　ＣＲＬの証明書検証用データに基づいて署名検証手段１００１により証明書検証を行い、その検証結果を認証サーバ１０に送り返す。認証サーバ１０は、署名検証手段１００１による検証結果が”ＯＫ”であれば、”ＯＫ”である検証結果を認証サーバプロキシ７を介してアクセスゲートウェイ３に送り返す。
【００６６】
アクセスゲートウェイ３側でのＶＰＮクライアント１の認証が終了した段階において、ＶＰＮクライアント側においてアクセスゲートウェイ３の認証が行われる。すなわち、ＶＰＮクライアント１がアクセスゲートウェイ３を認証するために、アクセスゲートウェイ３は、署名対象データを作成し、署名手段３０１により署名を行い、このデータをアクセスゲートウェイ３の証明書とともに、ＶＰＮクライアント１に送る。
【００６７】
ＶＰＮクライアント１は、アクセスゲートウェイ３から前記データを受けると、通常のＰＫＩ対応機能を利用して、署名検証および証明書検証、アクセスゲートウェイ３のユーザＩＤの確認を行うことによって、アクセスゲートウェイ３を認証する。
【００６８】
このようにして相互認証が終了すると、鍵交換フェーズに移行され、ＶＰＮクライアント１とアクセスゲートウェイ３との間で鍵交換手段３０４を介して鍵の交換が行われ、鍵（秘密鍵）が共有される。
【００６９】
その後、共有された鍵を用いて、ＶＰＮクライアント１とアクセスゲートウェイ３との間でＩＰｓｅｃ−ＶＰＮ（ＩＰ　Ｓｅｃｕｒｉｔｙ　Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）通信が確立する。そして、秘密鍵を使った処理が行われる。
【００７０】
上述したように、認証サーバ８、９、１０及び証明書検証サーバ１１、１３、１５による認証対象以外のクライアントによる証明書が認証対象に加わった場合には、その新たに加わったクライアントとの間に秘密鍵を用いて相互の認証を行うためのアクセスゲートウェイと、そのクライアントの認証を行うのに必要な認証サーバ及び証明書検証サーバ並びに証明書検証用データを追加することとなる。アクセスゲートウェイは必ずしも追加する必要はない。
【００７１】
この場合、アクセスゲートウェイにはクライアントの証明書データを組み込む必要がなく、汎用のアクセスゲートウェイを追加すればよく、しかも前記アクセスゲートウェイに対応して追加される認証サーバ及び証明書検証サーバ並びに証明書検証データは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することが可能となる。
【００７２】
また、図１及び図２では、ＶＰＮクライアント、アクセスゲートウェイ、認証サーバプロキシ、認証サーバ及び証明書検証サーバをハードウェアでそれぞれ構成したが、これに限定されるものではなく、これらをソフトウェアで構成することにより、図３に示すシーケンスの処理を行う証明書確認処理プログラムとして構成してもよいものである。
【００７３】
以上のように本発明の一実施形態による第一の効果は、各アクセスゲートウェイに複数のクライアントＣＡ証明書を格納する必要がなくなり、新たに追加されるクライアントＣＡの証明書が認証対象に加わったとしても、アクセスゲートウェイに新たに追加されるクライアントＣＡ証明書を認証するための機能を追加する必要がなくなることにある。
【００７４】
その理由は、アクセスゲートウェイと認証サーバが分離しており、クライアントＣＡが増設されたとしても、その増設されるクライアントＣＡに対応する認証サーバを増設し、認証サーバプロキシが所有する認証サーバリストに、新たに増設される認証サーバ（証明書検証サーバも含む）に振り分けるための識別用パターンを追加するだけで対応が可能となるためである。
【００７５】
第二の効果は、アクセスゲートウェイは、対応するクライアントＣＡの仕様に依存させる必要がなく、結果として汎用品を用いることができることにある。
【００７６】
その理由は、ユーザＩＤの確認、署名検証、証明書検証などのクライアントＣＡの仕様に依存する公開鍵を用いた処理を全て認証サーバに任せるためであり、認証パターン（例えば、証明書の中のユーザＩＤが具体的にどの属性に含まれているか、また、認証終了後に別のプロセスに識別子を渡す必要がある場合に、証明書の中のユーザＩＤとどのように対応づけるかといったルール等）を追加するだけで対処することができるためである。この認証パターンは、アクセスゲートウェイごとのソフトウェアを作成する際に証明書の認証に必要な全体の処理をソフトウェア化する場合と比較して開発費を大幅に削減することができる。
【００７７】
第三の効果は、アクセスゲートウェイは、アクセスゲートウェイを１００％ＰＫＩに対応する場合と同等の秘密鍵管理上の安全性を確保できることにある。
【００７８】
その理由は、ＰＫＩによりクライアントから認証される場合には、鍵対を作成し署名を行う能力を持つことから、秘密鍵管理をアクセスゲートウェイ内で閉じる、言換えれば認証サーバ側から要求されることがなく、秘密鍵を外部に出力することがなく、鍵管理を安全に行うことができる。
【００７９】
第四の効果は、異なるＰＫＩに対応した各クライアントから見て、どのアクセスゲートウェイにアクセスしても、各アクセスゲートウェイはその異なる全てのＰＫＩに対応できる点にある。
【００８０】
その理由は、アクセスゲートウェイと認証サーバが分離しており、アクセスゲートウェイは認証サーバプロキシを介して、それぞれ異なるクライアントＣＡに対応した複数の認証サーバにアクセスを振り分けることが可能となるためである（ユーザＩＤの確認、署名検証、証明書検証などのクライアントＣＡの仕様に依存する公開鍵を用いた処理を全て認証サーバに任せるためである。）。
【００８１】
第五の効果は、ＶＰＮクライアントは、既存のＰＫＩ対応のみで新たなＰＫＩに対応する必要がなく、既存のＶＰＮを利用できることにある。
【００８２】
その理由は、ＶＰＮクライアントは既に従っているクライアントＣＡがあれば、その仕様を認証サーバ側で吸収する（アクセスゲートウェイは変わらないまま、認証サーバがＰＫＩの仕様を吸収する）ことが可能な構成となっているためである。
【００８３】
次に、本発明の他の実施形態について図面を参照して詳細に説明する。
【００８４】
図４を参照すると、本実施形態は、図１のＶＰＮクライアント１がＷｅｂブラウザ１’に、図１のアクセスゲートウェイ３がＷＷＷサーバ３’に置き換わり、図１のＶＰＮクライアント１とアクセスゲートウェイ３と間のプロトコルがＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）であった点が、図４ではＴＬＳ（Ｔｒａｎｓｐｏｒｔ　Ｌａｙｅｒ　Ｓｅｃｕｒｉｔｙ）であるという点でシーケンスが異なっている。ＷＷＷサーバ３’の具体的な構成、認証サーバ１０の具体的な構成は図１及び図２に示す最初の実施形態と同じである。また図４では、一個のＷＷＷサーバ及び認証サーバのみを図示しているが、図１に示すように、ＷＷＷサーバ及び認証サーバは複数存在しているものである。
【００８５】
本実施形態の動作を図５のシーケンスチャートを参照して詳細に説明する。まず、Ｗｅｂブラウザ１’がＴＬＳの初期処理としてＣｌｉｅｎｔ　Ｈｅｌｌｏ（通信開始信号）を送る（ステップＡ１）。
【００８６】
ＷＷＷサーバ３’はＷｅｂブラウザ１にＳｅｒｖｅｒ　Ｈｅｌｌｏ（通信開始信号）とともに、サーバＣＡ６が発行したＷＷＷサーバ証明書を送る（ステップＢ１）。この場合、ＷＷＷサーバ証明書にはＷＷＷサーバの公開鍵が含まれているが、秘密鍵は含まれていない。次に、Ｗｅｂブラウザ１’では、ＷＷＷサーバ３’からのＷＷＷサーバ証明書を用いてＷＷＷサーバ３’のみに復号できる秘密共有のための暗号化情報を作成し、ＷＷＷサーバ３’に送信する（ステップＡ２）。
【００８７】
そして、Ｗｅｂブラウザ１’では、ＷＷＷサーバ３’とのやりとりによって得られる乱数等からなる署名対象データに対して、ＰＫＩの署名機能により署名を行い、これを署名データとして、Ｗｅｂブラウザ１’の証明書であるクライアント証明書（クライアントＣＡ２がブラウザ１’に対して発行する証明書）をＷＷＷサーバ３’に送る（ステップＡ３）。
【００８８】
ＷＷＷサーバ３’は、Ｗｅｂブラウザ１’から受け取った、鍵対作成手段３００が作成する鍵対のうち秘密鍵を用い秘密共有のための暗号化情報をＷＷＷサーバ３’の復号化手段３０２により復号する。
【００８９】
そして、ＷＷＷサーバ３’は、Ｗｅｂブラウザ１’から受け取った、クライアント証明書、署名データと、ＷＷＷサーバ３’が所有する署名対象デー　タを認証サーバプロキシ７に署名検証要求手段３０３を介して送る（ステップＢ２）。
【００９０】
認証サーバプロキシ７では、ＷＷＷサーバ３’から送られたＷＷＷブラウザ１’のクライアント証明書を元にしてＷＷＷブラウザ１’のユーザＩＤのパターンを得て、認証サーバリスト１７を参照し、適切な認証サーバを決定する。この場合、認証サーバ１０が選択されたものとする。
【００９１】
認証サーバプロキシ７はＷＷＷサーバ３’から受け取った、クライアント証明書、署名データ、署名対象データを認証サーバ振分手段７００を介して認証サーバ１０に送る（ステップＣ１）。
【００９２】
認証サーバ１０は、認証サーバプロキシ７からデータを受け取ると、証明書内容解析手段１０００を用いて、署名データと署名対象データが正しいことの確認を行う。そして、前記クライアント証明書を利用して署名データの署名検証を署名検証手段１００１により行う。続いて、クライアント証明書検証要求を証明書検証サーバ１５に証明書検証要求手段１００２を介して送る（ステップＤ１）。
【００９３】
証明書検証サーバ１５では、証明書検証要求手段１００２からの要求に応じて証明書検証用データ１６を用いてクライアント証明書検証を行い、その証明書検証結果を認証サーバ１０に送り返す（ステップＤ２）。なお、認証サーバ１０が証明書検証用データ１６を所有する場合には、直接にクライアント証明書を検証するようにしてもよい。
【００９４】
認証サーバ１０は署名検証結果を、認証サーバプロキシ７に送る（ステップＣ２）。認証サーバプロキシ７は認証サーバ１０から署名検証結果を受け取ると、これをＷＷＷサーバ３’に送る。
【００９５】
Ｗｅｂブラウザ１’の認証が終了すると、ＷＷＷサーバ３’が復号して得た、Ｗｅｂブラウザ１’とＷＷＷサーバ３’との間で共有された秘密鍵を用いた、ＴＬＳによる暗号通信フェーズに移行する。
【００９６】
以上のように暗号通信ができることによって、相互認証が完了する。そして、秘密鍵を使った処理が行われる。
【００９７】
本発明の実施形態において、認証サーバ１０及び証明書検証サーバ１５による認証対象以外のクライアントＣＡの証明書（ＷＷＷブラウザ１’のためにクライアントＣＡ２が発行する証明書）が認証対象に加わった場合には、その新たに加わったＷＷＷブラウザとの間に秘密鍵を用いて相互の認証を行うためのＷＷＷサーバと、その認証を行うのに必要な認証サーバ及び証明書検証サーバを追加することとなる。ＷＷＷサーバは必ずしも追加する必要はない。
【００９８】
ＷＷＷサーバを追加した場合、ＷＷＷサーバには前記クライアント証明書のデータを組み込む必要がなく、汎用のＷＷＷサーバを追加すればよく、しかも前記ＷＷＷサーバに対応して追加される認証サーバ及び証明書検証サーバは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なソフトウェアを追加するだけで対処することが可能となる。
【００９９】
次に、具体例を用いて説明する。図４のように、Ｗｅｂブラウザ１’からＷＷＷサーバ３’にＨＴＴＰ　ｏｖｅｒ　ＴＬＳ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ　ｏｖｅｒ　Ｔｒａｎｓｐｏｒｔ　Ｌａｙｅｒ　Ｓｅｃｕｒｉｔｙ）でアクセスすると、ＷＷＷサーバ３’からＷｅｂブラウザ１’にクライアントＣＡ６が発行するＷｅｂサーバ３’の証明書が送られる。この場合、前記証明書は、鍵対作成手段３００が作成する鍵対（秘密鍵と公開鍵）のうち公開鍵を含ませて送られる。
【０１００】
Ｗｅｂブラウザ１’は、ＷＷＷサーバ３’を認証するために秘密共有のためのデータをＷＷＷサーバ証明書の公開鍵を用いて暗号化した暗号化情報を送る。また、ＷＷＷサーバ３’がＷｅｂブラウザ１’を認証するために、ＷＷＷブラウザ１’は、署名データを作成し、クライアントＣＡ２がＷＷＷブラウザ１’のために発行した証明書とともに送る。
【０１０１】
ＷＷＷサーバ３’は、Ｗｅｂブラウザ１’からのデータを受け取ると、鍵対作成手段３００が発行する鍵対のうち秘密鍵を使って復号化手段３０２により秘密共有のための暗号化データを自力で復号し秘密情報を得る。そして、ＷＷＷサーバ３’は、公開鍵の情報と共に前記証明書、署名対象データ、署名データを認証サーバプロキシ７に送る。
【０１０２】
認証サーバプロキシ７では、ＷＷＷサーバ３’からの前記証明書からＷＷＷブラウザ１’のユーザＩＤのうちから”ａｂｃ”（ホスト名）を取り出し、このデータに基づいて認証サーバリスト１７を参照して認証サーバを選ぶ。この場合、認証サーバとして認証サーバ１０は選択決定されたものとする。
【０１０３】
認証サーバプロキシ７は、前記選択決定された認証サーバ１０に、クライアント証明書、署名対象データ、署名データを送る。
【０１０４】
認証サーバ１０では、前記認証サーバプロキシ７から送られたデータを証明書内容解析手段１０００で解析し、クライアント証明書からＷＷＷブラウザ１’のユーザＩＤを確認し、署名データを署名検証手段１００１で検証し、証明書検証サーバ１５にクライアント証明書検証要求を送る。
【０１０５】
証明書検証サーバ１５が証明書検証用データ１６を用いて証明書検証結果を行い、その証明書検証結果を認証サーバ１０に送り返すと、認証サーバ１０は認証サーバプロキシ７を介してＷＷＷサーバ３’に署名検証結果を送り返し、ＷＷＷサーバ３’によるＷｅｂブラウザ１’の認証が完了する。
【０１０６】
続いて、ＷＷＷサーバ３’が得たＷＷＷブラウザ１’からの秘密情報を用いて、暗号通信フェーズに入り、暗号通信が成功した時点で、Ｗｅｂブラウザ１’もＷＷＷサーバ３’を認証することができ、相互認証が完了する。そして、秘密鍵を使った処理が行われる。
【０１０７】
上述したように、認証サーバによる認証対象に新たな証明書が加わった場合には、その新たに加わったＷｅｂブラウザ１’との間に秘密鍵を用いて相互の認証を行うためのＷｅｂサーバ３’と、そのＷｅｂブラウザ１’の認証を行うのに必要な認証サーバ１０及び証明書検証データ１６を追加することとなる。Ｗｅｂサーバ３’は必ずしも追加する必要はない。
【０１０８】
Ｗｅｂサーバ３’を追加した場合、Ｗｅｂサーバ３’には証明書データを組み込む必要がなく、汎用のＷｅｂサーバ３’を追加すればよく、しかも前記Ｗｅｂサーバ３’に対応して追加される認証サーバ及び証明書検証データは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することが可能となる。
【０１０９】
また、図４では、Ｗｅｂブラウザ、ＷＷＷサ−バ、認証サーバプロキシ、認証サーバ及び認証サーバをハードウェアで構成したが、これに限定されるものではなく、これらをソフトウェアで構成することにより、図５に示すシーケンスの処理を行う証明書確認の集中処理用プログラムとして構成してもよいものである。
【０１１０】
図４及び図５に示す実施形態によれば、ＶＰＮクライアント及びアクセスゲートウェイに代えてＷＷＷブラウザ及びＷＷＷサーバを用いているため、ＶＰＮを構築する必要がなく、既存のインターネット網を使用して通信を行うことができ、新たに通信網の整備を行う必要がないという利点を有している。
【０１１１】
さらに、本発明の他の実施形態について図面を参照して詳細に説明する。本実施形態では、ＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）のような鍵交換プロトコルのうち、公開鍵暗号の暗号機能を利用した認証方式に着目している。
【０１１２】
図６を参照すると、本実施形態は、図１の構成に加え、証明書データ１８、１９、２０を増設させている点で異なっている。これらの証明書データ１８、１９、２０はそれぞれ認証サーバ８、９、１０が所有している。
【０１１３】
図７は、図６に示す本実施形態におけるアクセスゲートウェイ、認証サーバ、認証サーバの具体例を示す図である。図７を参照すると、図２に加え、アクセスゲートウェイ３に暗号化手段３０５が、認証サーバ４に証明書検索手段１００３がそれぞれ増設されている点が異なっている。また、証明書データ（１８、１９、２０）には、クライアントＣＡ２及びクライアントＣＡ２以外のクライアント証明書がそれぞれ含まれる。
【０１１４】
本実施形態の動作を図８のシーケンスチャートを参照して詳細に説明する。まず、ＶＰＮクライアント１がアクセスゲートウェイ３に対して、該クライアント１のユーザＩＤをアクセスサーバ３の公開鍵で暗号化して作成した、該クライアント１のユーザＩＤの暗号化データ、及び乱数をアクセスゲートウェイ３の公開鍵で暗号化して作成した、乱数の暗号化データとを送る（ステップＡ１）。
【０１１５】
アクセスゲートウェイ３では、アクセスゲートウェイ３の復号化手段３０２を用いて、ＶＰＮクライアント１から送られた暗号化情報を復号し、ユーザＩＤと乱数とを得る。
【０１１６】
次に、アクセスゲートウェイ３は、認証サーバプロキシ７に対して前記クライアントのユーザＩＤを送る（ステップＢ１）。
【０１１７】
認証サーバプロキシ７では、前記クライアントのユーザＩＤからＩＤパターンを得て、認証サーバリスト１７を参照し、前記クライアント１のユーザＩＤに対応する証明書を所有している認証サーバを決定する。この場合、認証サーバ１０が選択決定されたものとする。
【０１１８】
認証サーバプロキシ７は、認証サーバ１０に対して前記クライアント１のユーザＩＤを送る（ステップＣ１）。認証サーバ１０は、証明書検索手段１００３を用いて前記ユーザＩＤに対応したクライアント証明書を証明書検証用データ１６から取り出す。
【０１１９】
そして、認証サーバ１０は、証明書検証要求手段１００２を用いて証明書検証サーバ１５に、クライアント証明書検証要求を送る（ステップＤ１）。
【０１２０】
証明書検証サーバ１５は、クライアントＣＡ証明書やクライアントＣＡ　ＣＲＬなどの証明書検証用データを用いて証明書検証を行い、その証明書検証結果を認証サーバ１０に送り返す（ステップＥ１）。認証サーバ１０はクライアント証明書を認証サーバプロキシ７を介して（ステップＤ２）、アクセスゲートウェイ３に送り返す（ステップＣ２）。
【０１２１】
認証サーバプロキシ７からアクセスゲートウェイ３に送り返すときは、クライアント証明書はクライアント公開鍵を含めてもよい。
【０１２２】
続いて、アクセスゲートウェイ３は、認証サーバプロキシ７から送り返されたクライアント証明書を用いて、アクセスゲートウェイＩＤを暗号化して作成した、アクセスゲートウェイＩＤの暗号化データと、乱数を暗号化して作成した、乱数の暗号化データとをＶＰＮクライアント１に送る（ステップＢ２）。
【０１２３】
ＶＰＮクライアント１は、ＶＰＮクライアントの復号化手段を用いて、アクセスゲートウェイ３から送られた暗号化情報を復号し、アクセスゲートウェイＩＤと乱数とを得る。
【０１２４】
このようにして、相互認証が成立すると、鍵交換フェーズとなり、ＶＰＮクライ　アント１とアクセスゲートウェイ３との間で鍵が共有される。そして、秘密鍵を使った処理が行われる。
【０１２５】
本発明の実施形態において、認証サーバによる認証対象以外のクライアント証明書が認証対象に加わった場合には、その新たに加わったクライアントとの間に秘密鍵を用いて相互の認証を行うためのアクセスゲートウェイと、そのクライアントの認証を行うのに必要な認証サーバ、証明書検証サーバ、証明書検証用データ及び証明書データを追加することとなる。アクセスゲートウェイは、必ずしも追加する必要はない。
【０１２６】
アクセスゲートウェイを追加した場合、アクセスゲートウェイにはクライアントの証明書データを組み込む必要がなく、汎用のアクセスゲートウェイを追加すればよく、しかも前記アクセスゲートウェイに対応して追加される認証サーバ、証明書検証サーバ、証明書検証用データ及び証明書データは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することが可能となる。
【０１２７】
次に、具体例を用いて説明する。ＶＰＮクライアント１がアクセスゲートウェイ３に対して、ＶＰＮクライアント１のユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”をアクセスゲートウェイ３の公開鍵で暗号化して作成した、ユーザＩＤの暗号化データ、および乱数Ｎ１をアクセスゲートウェイ３の公開鍵で暗号化して作成した、乱数の暗号化データとを送る。
【０１２８】
アクセスゲートウェイ３では、アクセスゲートウェイ３の復号化手段３０２を用いて、ＶＰＮクライアント１から送られた暗号化情報を復号し、ＶＰＮクライアント１のユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”と乱数Ｎ１を得る。
【０１２９】
次に、アクセスゲートウェイ３は、認証サーバプロキシ７に対してクライアント１のユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”を送る。
【０１３０】
認証サーバプロキシ７では、前記ユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”　からＩＤパターン”ａｂｃ”を取り出し、このデータに基づいて認証サーバリスト１７を参照して認証サーバ１０を選択決定する。
【０１３１】
そして、認証サーバプロキシ７は認証サーバ１０に対して、前記ユーザＩＤ”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”を送る。認証サーバ１０は、証明書検索手段１００３を用いて前記ユーザＩＤからユーザＩＤに対応したクライアント証明書を証明書データ２０から取り出す。
【０１３２】
そして、認証サーバ１０は、証明書検証要求手段１００２を用いて証明書検証サーバ１５に、クライアント証明書検証要求を送る。
【０１３３】
証明書検証サーバ１５は、クライアントＣＡ証明書やクライアントＣＡ　ＣＲＬなどの証明書検証用データを用いて証明書検証を行い、その証明書検証結果を認証サーバ１０に送り返すと、認証サーバ１０は”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”の公開鍵を、認証サーバプロキシ７を介してアクセスゲートウェイ３に送り返す。
【０１３４】
続いて、アクセスゲートウェイ３は、”ｔａｒｏ＠ａｂｃ．ｃｏ．ｊｐ”の公開鍵を用いて、クライアントＣＡ６がアクセスゲートウェイ３のために発行するアクセスゲートウェイのユーザＩＤ”ｓｅｒｖｅｒ３．ｄｅｆ．ｃｏ．ｊｐ”を暗号化手段３０５により暗号化して作成した、アクセスゲートウェイのユーザＩＤの暗号化データと、乱数Ｎ２とを暗号化して作成した、乱数の暗号化データとをＶＰＮクライアント１に送る。
【０１３５】
ＶＰＮクライアント１は、ＶＰＮクライアントの復号化手段を用いて、アクセスゲートウェイ３から送られた暗号化情報を復号し、アクセスゲートウェイ３のアクセスゲートウェイユーザＩＤ”ｓｅｒｖｅｒ３．ｄｅｆ．ｃｏ．ｊｐ”と乱数Ｎ２とを得る。
【０１３６】
このようにして、相互認証が成立すると、鍵交換フェーズとなり、ＶＰＮクライアント１とアクセスゲートウェイ３との間で鍵が共有される。
【０１３７】
ここで、認証サーバによる認証対象以外のクライアント証明書が認証対象に加わった場合には、その新たに加わったクライアントとの間に相互認証を行うためのアクセスゲートウェイと、そのクライアントの認証を行うのに必要な認証サーバ、証明書検証サーバ、証明書検証用データ及び証明書データを追加することとなる。アクセスゲートウェイは必ずしも追加する必要はない。
【０１３８】
アクセスゲートウェイを追加した場合、アクセスゲートウェイにはクライアントの証明書データを組み込む必要がなく、汎用のアクセスゲートウェイを追加すればよく、しかも前記アクセスゲートウェイに対応して追加される認証サーバ、証明書検証サーバ、証明書検証用データ及び証明書データは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することが可能となる。
【０１３９】
また、図６及び図７では、ＶＰＮクライアント、アクセスゲートウェイ、認証サーバプロキシ、認証サーバ及び証明書検証サーバをハードウェアで構成したが、これに限定されるものではなく、これらをソフトウェアで構成することにより、図８に示すシーケンスの処理を行う証明書確認の集中処理用プログラムとして構成してもよいものである。
【０１４０】
さらに、本発明の他の実施形態について図面を参照して詳細に説明する。
【０１４１】
図９を参照すると、本実施形態は、図１の構成をサービス事業者に対して適用した場合を示している。図９に示すように、図１に示すゲートウェイＣＡ６、アクセスゲートウェイ３、４、５、認証サーバリスト１７を所有する認証サーバプロキシ７をサービス事業者Ｐに、認証サーバ１０、証明書検証用データ１６を所有する証明書検証サーバ１５をサービス事業者Ｑに、認証サーバ９、証明書検証用データ１４を所有する証明書検証サーバ１３をサービス事業者Ｙに、認証サーバ８、証明書検証用データ１２を所有する証明書検証サーバ１１をサービス事業者Ｘにそれぞれ振り分けている。
【０１４２】
図９に示すように、機能別にサービス事業者に切り分ける、すなわちユニット化してオンライン接続する構成とすることにより、サービス事業者Ｐは、サービス事業者Ｑ、Ｘ、ＹそれぞれのＰＫＩ仕様を受け入れることが可能なアクセスサービスを提供することができる。しかも、アクセスゲートウェイに必要な証明書については、サービス事業者Ｐで一括して仕様を決めることができる。
【０１４３】
ＶＰＮクライアント１を使用するユーザは、アクセスゲートウェイＣＡ証明書のみを有するクライアントプログラムを所有しておれば、サービス事業者Ｘ、Ｙ、Ｑなどの様々なサービス事業者のサービスにアクセスできるようになる。つまり、ＶＰＮクライアント１を使用するユーザにとって、利用するサービス事業者がＸ、Ｙ、Ｑ以外に増えても、クライアントプログラムに変更が必要ないという効果を奏する。
【０１４４】
ここで、認証サーバによる認証対象以外のクライアント証明書が認証対象に加わった場合には、その新たに加わったクライアントとの間に相互の認証を行うためのアクセスゲートウェイをサービス事業者Ｐに追加し、前記クライアントの認証を行うのに必要な認証サーバ及び証明書検証サーバを有する、サービス事業者Ｑ、Ｘ、Ｙに相当するサービス事業者を追加することとなる。アクセスゲートウェイはサービス事業者Ｐに必ずしも追加する必要はない。
【０１４５】
アクセスゲートウェイを追加した場合、アクセスゲートウェイにはクライアントの証明書データを組み込む必要がなく、汎用のアクセスゲートウェイを追加すればよく、しかも前記アクセスゲートウェイに対応して追加される認証サーバ及び証明書検証サーバは、公開鍵を使って認証処理を行うものであるから、公開されている公開鍵に基づいて処理を行うために、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することが可能となる（？）。
【０１４６】
また、図９では、ＶＰＮクライアント、アクセスゲートウェイ、認証サーバプロキシ、認証サーバ及び証明書サーバをハードウェアで構成したが、これに限定されるものではなく、これらをソフトウェアで構成することにより、図１に示すシーケンスの処理を行う証明書確認の処理用プログラムとして構成してもよいものである。
【０１４７】
【発明の効果】
以上説明したように本発明によれば、公開鍵暗号の秘密鍵を用いる処理と、秘密鍵を用いずに公開鍵を用いる処理とを分割し、前記公開鍵を用いる処理に証明書の確認手続を集中させることによって、対応すべき証明書の種類が増えても、前記秘密鍵を用いる処理の追加変更をすることなく拡張できる。しかも、証明書の確認手続が集中する公開鍵を用いた処理機能を追加するものであるため、ユーザＩＤ、署名検証、証明書検証処理用に必要なカスタマイズされたソフトウェアを追加するだけで対処することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態を示す構成図である。
【図２】図１に示す本発明の一実施形態におけるアクセスゲートウェイと認証サーバプロキシと認証サーバとの具体的構成を示す構成図である。
【図３】図１及び図２に示す本発明の一実施形態の全体的な動作を示すシーケンスチャートを示す図である。
【図４】本発明の他の実施形態を示す構成図である。
【図５】図４に示す本発明の他の実施形態の全体的な動作を示すシーケンスチャートを示す図である。
【図６】本発明の他の実施形態を示す構成図である。
【図７】図６に示す本発明の他の実施形態におけるアクセスゲートウェイ、認証サーバプロキシ、認証サーバの具体例を示す構成図である。
【図８】図６及び図７に示す本発明の他の実施形態の全体の動作を示すシーケンスチャートを示す図である。
【図９】
本発明の他の実施形態を示す構成図である。
【符号の説明】
１　ＶＰＮクライント
２　クライアントＣＡ
３、４、５　アクセスゲートウェイ
６　ゲートウェイＣＡ
７　認証サーバプロキシ
８、９、１０　認証サーバ
１１、１３、１５　証明書検証サーバ
１６　証明書検証用データ
１７　認証サーバリスト
【図１】
2004032311.tif 000003
【図２】
2004032311.tif 000004
【図３】
2004032311.tif 000005
【図４】
2004032311.tif 000006
【図５】
2004032311.tif 000007
【図６】
2004032311.tif 000008
【図７】
2004032311.tif 000009
【図８】
2004032311.tif 000010
【図９】
2004032311.tif 000011