JP4667921B2 - 検証装置及び通信システム及びトラストストア管理装置及びトラストストア監視装置 - Google Patents

Description

本発明は、PKI（Public Key Infrastructure）システムにおいて、エンドユーザが通信相手の証明書を検証する場合に使用する信用情報を、管理者が集中的に管理可能な装置に関する。

PKI(Public Key Infrastructure)対応のアプリケーションにおいて、公開鍵証明書（以下「証明書」ともいう）の検証のために利用する“信用する情報の管理方法”として以下の技術がある。以降、信用する情報の保管先をトラストストアと呼ぶことにする。

なお、証明書、失効情報であるCRL(Certificate Revocation List)はRFC3280（Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile）に規定されている。

また、失効情報を得るためのプロトコルであるOCSP（Online Certificate Status Protocol）はRFC2560（X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP）に規定されている。

セキュアプロトコルであるSSL (Secure Sockets Layer)は、The SSL Protocol Version 3.0, draft-freier-ssl-version3-02.txtで規定されている。

また、TLS(Transport Layer Security)はRFC2246 （The TLS Protocol Version 1.0）で規定されている。

また、セキュアメールであるS/MIMEはRFC2311 (S/MIME Version 2 Message Specification)などで規定されている。
（あ）信用する証明書の管理
１）ユーザによる信用するＣＡ証明書／エンドエンティティ証明書の管理
従来のPKI対応のブラウザ、メーラ等では、アプリケーションベンダにおいて信頼できると判断したＣＡ（Certification Authority：認証局）の証明書を、予めトラストストアへ格納しておく実装がある。加えて、ユーザの責任において、ＣＡ証明書及びエンドエンティティ証明書をトラストストアへ追加格納することが可能である。また、格納されている証明書を指定して削除することも可能である。

２）ユーザによる通信相手の証明書の一時的な受入
従来のPKI対応のブラウザ、セキュアメーラ等に多い実装として、トラストストアに格納されていないＣＡ証明書配下の証明書を受信した場合に、“証明書の安全性が確認できない”という警告を出した上で、処理を続行するか中止するかユーザ選択を可能とするものが挙げられる。処理を続行した場合、一時的に証明書を受け入れることになる。

また、警告を出したうえで、安全性が確認できない通信相手の証明書及びそのＣＡ証明書を表示し、その場で通信相手の証明書及びそのＣＡ証明書をトラストストアへの格納を可能とする実装もある。
３）トラストストアにおけるＣＡ証明書の更新機能
また、ＣＡ証明書の更新に関しては、次のような実装例がある。例えばセキュアプロトコルであるSSL(Secure Sockets Layer, The SSL Protocol Version 3.0, draft-freier-ssl-version3-02.txt)及びTLS(Transport Layer Security, RFC2246 The TLS Protocol Version 1.0)で受信したサーバ証明書がトラストストア内のＣＡ証明書で検証不可能な場合にＣＡ証明書のダウンロードサイトへ接続し、アプリケーションのベンダが信頼する最新のＣＡ証明書をダウンロードし再度検証を試みる機能である。

４）システム管理者が、エンドユーザに対して、トラストストアの編集を禁止する機能
また、システム管理者は、安全性が確認されていないルートＣＡ証明書の追加、及び安全性が確認されているルートＣＡ証明書の削除を、エンドユーザに対して禁止することが可能な実装例がある。

（い）失効情報の管理
証明書の検証の際に、検証対象の証明書が現在失効状態にないかチェックするため、失効情報をダウンロードして利用することがある。失効情報には署名が付与されており、有効期限とともに正当性をチェックして利用する。チェック済みの失効情報を信頼できるものとして有効期限が切れるまでエンドユーザの端末にキャッシュして使用する実装がある。

（う）証明書の検証に用いるパラメータ情報の管理
証明書の検証に用いるパラメータ情報とは、RFC3280に記載される、証明書の検証において必要となるパラメータで、現在時刻、受入可能な証明書ポリシー、証明書の検証段数などがあり証明書の検証者の責任で管理するべき情報である。

また、公開鍵証明書の有効性確認に関する技術として、特開２００２−７２８７６号公報に記載の技術がある。特開２００２−７２８７６号公報では、証明書有効性確認センタが、ブリッジ認証局から各端末認証局までのパスの検索、検証を定期的に行い、検証が成立したパスを端末収容認証局に対応付けてパスＤＢに登録する。また、エンドエンティティＥＥから証明書 の有効性確認依頼があった場合、当該エンドエンティティＥＥを収容する端末収容認証局に対応付けられたパスと依頼対象証明書 を発行した端末収容認証局に対応付けられたパスとがパスＤＢに登録されているか否かを調べ、両者が登録されている場合にのみ、当該証明書 は有効であると判断する。
特開２００２−７２８７６号公報

従来のPKIシステムの課題として、証明書の検証に利用する情報の管理方式には以下の課題があった。
（１）信用する証明書の管理の課題
PKI(PublicKeyInfrastructure)を利用した「SSL対応のWebサイトの閲覧」や「暗号・署名機能を持つS/MIMEなどのセキュアメールの閲覧」等においては、通信相手の証明書の安全性を確認することが通信の安全性に帰結するため、該証明書の確実なチェックが非常に重要である。証明書のチェック方法としては、通信相手の証明書の上位のＣＡ証明書を信頼するものとして予めトラストストアに保管しておき、通信相手の証明書を受信した時点でトラストストア内のＣＡ証明書を利用して検証を行う方法が典型的である。

もし信頼性が不明なＣＡの証明書、或いは通信相手の証明書を保管してしまうと、該当する信頼性の不明なSSL対応WebサイトやS/MIMEメール等を“正常に閲覧できてしまう”ため、エンドユーザは閲覧している情報の信頼性が不明であることに気がつかないという問題がある。従って、PKIシステムの安全性の確保において、トラストストアの管理は極めて重要である。

一般的に、PKIアプリケーションの配布者が、自身が信頼する証明書を予めPKIアプリケーションのトラストストア（信頼できる証明書の格納場所）に格納して配布しておく。加えて、ユーザの責任においてもトラストストアへＣＡ証明書や通信相手の証明書の格納を可能とする実装も多い。背景技術における（あ）の１）が該当する。

企業内PKIシステムなどで、これらのPKIアプリケーションを運用する場合、システム管理者が信用する証明書の格納をユーザマニュアルなどで指示し、ユーザ各自が格納を行う方法がある。つまり、証明書の格納権限はエンドユーザにある。そのため、ユーザが故意或いは無意識に、システム管理者が指示した格納すべき証明書を格納していない場合や、逆に格納を指示していない証明書を格納することが可能である。

例えば、悪意のあるWebサイト管理者やセキュアメールの発信者が、 “添付のＣＡ証明書を予めトラストストアに保管しておくとサイト／メールが安全に閲覧できます”という詐称のメールを送った場合、ユーザがこの情報を信じて添付の証明書をトラストストアに保管してしまうことがあり得る。この場合、格納後は該サイトやメールの閲覧において警告やエラーが発生することがないため、信頼すべきではない該サイトやメールをあたかも信頼できるものとして正常に閲覧でき、その信頼性が不明な情報に基づいて行動を起こす可能性がある。

また、PKI対応のブラウザ、セキュアメーラ等に多い実装として、トラストストアに格納されていないＣＡ証明書配下の証明書を受信した場合に、“証明書の安全性が確認できない”という警告を出した上で、ユーザ選択で処理を続行可能とするものが挙げられる（例：“この証明書を一時的に受け入れる”、“接続しない” という内容のボタンを表示して、ユーザに選択させる）。これは、背景技術における（あ）の２）が該当する。このような実装では、証明書の安全性が確認できないが処理の継続はユーザ責任で可能とすることで、ユーザの利便性を確保している。しかしながら、ユーザが警告をよく読まなかったりユーザ責任であることを意識せずに、或いは誤って継続用のボタンを押すことによりWebサイトに接続することや、メールを閲覧してしまうことが考えられる。

或いは、当機能を悪用し、悪意のあるWebサイト管理者やメールの発信者が、「○○Webサイト閲覧時（○○からのメールの閲覧時）に証明書の安全性に関する警告が表示されますが、××が原因で表示されているだけであり、安全性には問題は無いので “この証明書を一時的に受け入れる”ボタンを押して継続してください」というそれらしい理由を書いた詐称の指示をメールで別途知らせておくことで、ユーザに処理の継続を促し閲覧させてしまうことが考えられる。アプリケーションによってはこの警告画面から証明書をトラストストアへ格納可能なものもあるため（例：“この証明書を永続的に受け入れる”、“この証明書を一時的に受け入れる”、“接続しない” という３つの選択ボタンを表示する）、詐称メールにおいて、「警告画面が出た場合は“この証明書を今後も受け入れる”を押してください」という指示を加えておけば、指示に従いトラストストアに格納してしまうユーザもいる可能性がある。

一時的にでも証明書を受け入れる機能を保持することはエンドユーザの利便性を高めるが、反面、信頼性の不明な情報を閲覧できることになり、当問題を十分意識しているユーザであればその情報をもとに行動を起こすことに注意を払うであろうが、意識していないユーザはその情報をもとに行動を起こす可能性がある。

トラストストアの管理をアプリケーションベンダ側で管理する方法として背景技術における（あ）の３）があげられる。当サービスの主な目的は、受信した証明書がアプリケーションのトラストストアに埋め込みの証明書で検証できない場合にアプリケーションベンダ等のダウンロードサイトに接続し、アプリケーションベンダにおいて信用される証明書の最新リストをダウンロードし、受信した証明書の検証を試みる機能であるが、トラストストアにおける格納するべきではない証明書を削除するなどの管理を行う機能ではないため、（あ）の２）における課題は解決されない。

また、「ユーザ権限によるトラストストアへの証明書の追加・削除をシステム管理者が強制的に禁止する方法」として背景技術における（あ）４）があげられる。当方式を採用すれば、前述の（あ）の１）における課題は解決される。しかし、システム管理者が明示的に許可している証明書以外に明らかにシステムに悪影響を与えない証明書の利用について、エンドユーザ自身が安全性を判断して差し支えない場合に利便性を損ねることになる。例えば、信頼できる社員同士が自作の証明書を作成し業務メールを署名付き電子メールで交換する場合などである。当機能を利用すると（あ）の２）の実装方式においては、トラストストアへ自作の証明書を格納できなくとも、警告画面を経由して一時的な受入が可能なので情報を閲覧することは可能である。しかし、自作の証明書をトラストストアへ格納できない以上、メールを閲覧する毎に警告画面が表示されユーザ選択を要求されるため利便性を損ねる。
（２）失効情報の管理の課題
また、通信相手の証明書の検証時に、証明書が何らかの理由で失効していることを通知する失効情報を参照する場合がある。失効情報の代表的な例として、CRL(Certificate Revocation List)やOCSP(Online Certificate Status Protocol)におけるレスポンスがある。失効情報には有効期限と署名が付与されるが、正しさを検証するめには署名を対応する証明書で検証する必要がある。

失効情報は時間の経過とともに変化することが予想されるので、通信相手の証明書を検証する都度取得することが望ましいが、取得にあたり通信が発生する場合や通信量が懸念される場合があり、その場合、検証に成功した失効情報を信頼できるものとして有効期限が切れるまで（次の更新日まで）エンドユーザの端末にキャッシュして使用する実装がある。背景技術の（い）が該当する。

トラストストアの管理について背景技術の（あ）の１）の実装が採用されていた場合、ユーザにトラストストアの管理権限があるので、トラストストアに失効情報の検証用の信頼性が不明な証明書が格納されていることがあり得る。すると、この証明書を利用して検査を行った失効情報の信頼性は不明であり、この失効情報を用いて有効性の判定を決定した通信相手の証明書の安全性も不明ということになる。

つまり、この場合は、キャッシュしている失効情報について必ずしも信頼できるものであるとは限らないという課題がある。

上記では、トラストストアへの証明書の保管の課題について述べてきたが、キャッシュする失効情報の管理について派生的に課題が生じることになる。

さらに、特開平１１−３４０９６８号公報の課題に示されるように、失効情報の署名の検証において多数の証明書を繰り返し検証する場合があり、これを悪用して、わざと失効情報の署名の検証に無駄な時間を費やさせる失効情報をシステム内ユーザへ送付する攻撃が予想され、防御の課題がある。
（３）証明書の検証に使用するパラメータの管理の課題
証明書を検査するためのパラメータとして、RFC3280に規定される受け入れ可能なCertificatePolicyのIDのセットや、証明書のパスの段数の上限値などがあり、信用できる情報として管理されるものであるが、ユーザが設定可能な場合は、証明書の管理と同様に誤った設定を行うことにより証明書の検証が不可能になったり、受け入れるべきではない証明書を受け入れてしまう課題がある。

この発明は上記のような問題点を解決するためになされたもので、トラストストアの管理をユーザ権限で柔軟に行わせつつ、システム管理者の監視を可能とし、問題のある証明書を受け入れてしまった場合の被害を軽減することを目的とするものである。また、失効情報や証明書の検証のパラメータに関してもシステム管理者が監視可能とすることでエンドユーザによる証明書の検証の信頼性を向上させるものである。

本発明に係る検証装置は、
一つ以上の端末が含まれる所定のネットワーク上で流通するデータを受信するデータ受信部と、
前記データ受信部により受信された受信データ内に公開鍵の有効性を検証するために用いられる公開鍵検証情報が含まれているか否かを解析し、受信データ内に公開鍵検証情報が含まれている場合に、受信データから公開鍵検証情報を抽出する解析抽出部と、
前記解析抽出部により抽出された公開鍵検証情報に対する検証を行い、公開鍵検証情報の受入可否を判定する受入可否判定部と、
前記受入可否判定部により公開鍵検証情報の受入が拒否された場合に、受入が拒否された拒否公開鍵検証情報の前記所定のネットワーク内の端末における利用を抑止する対策処置を行う対策処置実行部とを有することを特徴とする。

また、本発明に係る通信システムは、
公開鍵の有効性を検証するために用いられる公開鍵検証情報が格納されたトラストストア内の公開鍵検証情報の格納状況を調査し、トラストストア内に格納されている公開鍵検証情報を通知するトラストストア情報を生成するトラストストア管理部と、
前記トラストストア管理部により生成されたトラストストア情報を送信するトラストストア情報送信部と、
前記トラストストア情報送信部により送信されたトラストストア情報に対する応答として送信された処置命令情報を受信する命令受信部とを有するトラストストア管理装置と、
前記トラストストア管理装置からトラストストア情報を受信するトラストストア情報受信部と、
前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成する処置判定部と、
前記処置判定部により生成された処置命令情報を前記トラストストア管理装置に送信する命令送信部とを有するトラストストア監視装置を有し、
前記トラストストア管理装置において、
前記命令受信部は、
前記トラストストア監視装置から送信された処置命令情報を受信し、
前記トラストストア管理部は、
前記命令受信部により受信された処置命令情報に従い、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の行うことを特徴とする。

本発明によれば、公開鍵検証情報の検証をネットワーク内で一元的に行い、公開鍵検証情報の受入が不可能な場合には当該公開鍵検証情報の利用を抑止する対策処置をネットワーク内の端末に対して行うため、公開鍵検証情報の管理をユーザ権限で柔軟に行わせつつ、システム管理者による公開鍵検証情報の監視を可能とし、これにより公開鍵検証情報に対する検証の信頼性を向上させることができる。

また、本発明によれば、トラストストア管理装置からトラストストア監視装置にトラストストア内の公開鍵検証情報の格納状況を通知させ、またトラストストア監視装置の指示に基づきトラストストア管理装置にトラストストア内の公開鍵検証情報の削除、更新、新たな公開鍵検証情報の追加を行わせるため、トラストストアの管理をユーザ権限で柔軟に行わせつつ、トラストストアの管理にシステム管理者の判断を反映させることができ、これによりトラストストア内の公開鍵検証情報の信頼性を向上させることができる。

実施の形態１．
本実施の形態は、発明が解決しようとする課題における（１）信用する証明書の管理の課題に示した課題を解決することを主な目的とする。なお、本明細書では、公開鍵の有効性を検証するために用いられる情報を公開鍵検証情報といい、公開鍵検証情報は、例えば、公開鍵証明書、失効情報、検証パラメータである。本実施の形態では、公開鍵検証情報として、公開鍵証明書の検証を行う場合を説明する。

図１は、本実施の形態に係る証明書検証装置を含むシステムの全体構成例を示す図である。

図１において、証明書検証装置（検証装置）１０１は、所定のネットワーク内に配置され、当該ネットワーク上で流通するデータを取得し、取得したデータに含まれる証明書の検証を行う。図１では、証明書発信機器１０５からユーザの端末１０２に対して送信されたデータ（SSL通信、S/MIMEメール等）を取得（傍受）し、取得したデータに含まれる証明書の検証を行う。ここで、証明書検証装置１０１は、ユーザの端末１０２宛てのデータの複製を取得するのみであり、ユーザの端末１０２は自身宛てのデータを正常に受信する。このため、ユーザの端末１０２宛てのデータに証明書が含まれている場合は、証明書検証装置１０１における証明書の検証結果のいかんにかかわらず、ユーザの端末１０２は、当該データに含まれる証明書を受信する。

ユーザの端末１０２は、証明書検証装置１０１が管理する端末であり、証明書発信機器１０５からの証明書を受信し、受信した証明書が証明書検証装置１０１において有効性が確認された場合等に、受信した証明書をトラストストア１０３に受入れ、証明書を用いた通信を行う。

トラストストア１０３は、ユーザの端末１０２に接続された格納領域であり、前述したように、エンドユーザにおいて、証明書を検証するために必要な信用すべき情報、例えば信用するＣＡ／エンドユーザの証明書の実体、公開鍵と持ち主DistinguishedName、証明書ポリシー、失効情報の取得先、失効情報、利用用途などを管理するための格納場所である。

システム管理者の端末１０４は、証明書検証装置１０１の管理を行う管理者が利用する端末である。

証明書発信機器１０５は、SSLサーバ証明書やS/MIME証明書に基づいて証明書を発信する機器であり、例えばSSLを適用したWebサイトやS/MIMEメーラである。

ＣＡ１０６は、ＣＡ証明書、SSLサーバ証明書、S/MIME証明書等を発行する。

なお、図１において、証明書検証装置１０１は、システム管理者の端末１０４と独立した構成となっているが、ソフトウェアとして実現する場合はシステム管理者の端末１０４に搭載してもよい。

図２は、証明書検証装置１０１の構成例を示す図である。

データ受信部１１１はネットワーク上を流れるデータを受信する機能である。

受信データ解析部１１２は、受信したデータから検査したいプロトコルデータ、アプリケーションデータを解析・抽出する機能であり、証明書や失効情報を含んだデータとプロトコル／アプリケーション（SSL、S/MIMEなど）の識別情報を出力する。

証明書抽出部１２１は証明書を含んだデータから１つ以上の証明書を抽出する機能である。

証明書受入判定部１２２は、予め保持している受入可能証明書情報、及び、受入拒否証明書情報を使用し、抽出した証明書の受入の可否を決定する機能である。

証明書パス構築部１２３は、抽出した証明書を利用し、Subject/Issuerフィールドの関係に基づき証明書パスを構築する機能である。

証明書パス検証部１２４は、証明書パスの正当性を検査する機能であり、各証明書の有効期限、署名、失効状態、エクステンション等を検査する。

失効状態検査部１２５は、証明書が失効しているか検査する機能である。

データベース１１３は、受入可能な証明書等（公開鍵検証情報）の条件などを示した許諾情報（受入可能条件情報）と受入を拒否する証明書等（公開鍵検証情報）の条件などを示した拒否情報（受入拒否条件情報）を格納する。許諾情報は、受入可能な証明書の条件などを示した受入可能証明書情報、受入可能な失効情報の条件などを示した受入可能失効情報、受入可能な検証パラメータの条件などを示した受入可能検証パラメータ情報である。拒否情報は、受入を拒否する証明書の条件などを示した受入拒否証明書情報、受入を拒否する失効情報の条件などを示した受入拒否失効情報、受入を拒否する検証パラメータの条件などを示した受入拒否検証パラメータ情報である。

エラー処理部１１４は、証明書受入判定部１２２において証明書の受入が拒否された場合等においてエラー処理を行う。エラー処理とは、受入が拒否された証明書の利用を抑止する対策処置を意味する。エラー処理部１１４は、以下の警告部１１４ａと強制処理部１１４ｂで構成される。

警告部１１４ａは、受信データ解析部１１２、証明書抽出部１２１、証明書パス構築部１２３、証明書受入判定部１２２、証明書パス検証部１２４においてエラーが出力された場合、データの受信者（ユーザの端末１０２）に対する警告を生成する機能である。警告部１１４ａは、エラー情報、プロトコル／アプリケーションの識別子、データの送信者／受信者情報(src/dst)、タイムスタンプから、データの受信者への警告情報を生成する。

強制処理部１１４ｂはエラー発生時に、送／受信者間のプロトコルの強制切断などの命令を生成する機能である。

データ送信部１１５は警告部１１４ａ、強制処理部１１４ｂで生成された警告や命令を送信する機能である。

なお、受信データ解析部１１２及び証明書抽出部１２１は、解析抽出部の例である。また、証明書受入判定部１２２は、受入可否判定部の例である。また、データベース１１３は、条件情報格納部の例である。また、エラー処理部１１４は、対策処置実行部の例である。

次に、図４のフローチャートを参照しながら動作について説明する。

先ず、データ受信部１１１はネットワーク上を流れるデータを受信し（Ｓ４０１）、受信データ解析部１１２にデータを渡す。

受信データ解析部１１２は、受信データからシステム管理者が指定した検査したいプロトコル／アプリケーションデータが含まれているか否かを解析し（Ｓ４０２）、当該データを抽出する(Ｓ４０３)。例えば、SSLやS/MIMEのデータに含まれる証明書を検査したいのであれば、SSL、S/MIMEのデータを抽出する。抽出されたデータには証明書が含まれている。抽出されたデータは証明書抽出部１２１に渡される。

証明書抽出部１２１はプロトコル／アプリケーションデータから１枚以上の証明書を抽出する(Ｓ４０４)。抽出した証明書は証明書受入判定部１２２へ渡される。

証明書受入判定部１２２は、予め蓄積されている受入可能証明書情報と受入拒否証明書情報を利用して、 抽出された証明書が受入可能か判断する(Ｓ４０５)。

受入可能証明書情報とは、システムにおいて受入可能と判断される通信相手／ＣＡ証明書の情報であり、例えば、IssuerやSubjectのDistinguishedName、公開鍵の値、CertificatePolicy、KeyUsage、ExtendedKeyUsage、CRLDistributionPoint、AIA（AuthorityInformationAccess：例えばOCSPレスポンダのアドレスの記載）証明書本体などである。

受入拒否証明書情報とは、システムにおいて受入を拒否する通信相手／ＣＡ証明書の情報であり、受入可能情報と同様に、例えば、IssuerやSubjectのDistinguishedName、CertificatePolicy、KeyUsage、ExtendedKeyUsage、CRLDistributionPoint、AIA（AuthorityInformationAccess：例えばOCSPレスポンダのアドレスの記載）証明書本体などである。

例えば、抽出した証明書に含まれる属性が、これらの受入可能証明書情報に合致した場合に受入可能と判断し、受入拒否証明書情報に合致した場合に受入不可能と判断する。或いは、受入可能情報のみを利用し、受入可能情報に合致しなかった証明書のみを受入不可能と判断したり、逆に、受入拒否証明書情報に合致しなかった証明書は受入可能と判断しても良い。また、受入可能証明書情報と受入拒否証明書情報の合致判断の適用順番は任意でも良く、受入可能証明書情報→受入拒否証明書情報、またはその逆であったり、各々の要素を任意の順番で組み合わせても良い。

また、複数の受入可能証明書情報、受入拒否証明書情報が存在する場合に、例えば、受入可能証明書情報１→受入拒否証明書情報１０→受入拒否証明書情報２→受入可能証明書情報３といった順序（各情報の末尾の番号は、各情報の識別番号）で複数の受入可能証明書情報、受入拒否証明書情報を用いて、証明書が受け入れ可能か否か判断してもよい。

これらの情報の設定と受入の判定ルールは、例えば、証明書検証装置に入力インターフェースを設け、手入力で追加・削除・変更を条件情報格納部に対して処理する。

証明書受入判定部１２２で受入可能と判断された場合は、証明書を証明書パス構築部１２３に渡す。

証明書パス構築部１２３は、抽出された証明書から証明書パスの構築を行う(Ｓ４０６)。具体的には、各証明書に含まれるIssuer/Subjectの関係から親子関係を判定することでパスを構築する。パスを構築するための証明書が抽出した証明書で不足している場合は、設定によりディレクトリサーバなどに検索しにいってもよい。構築された証明書パスは証明書パス検証部１２４に渡される。

証明書パス検証部１２４は、証明書パスの正当性を検査する機能であり、各証明書の有効期限、署名、失効状態を検査する(Ｓ４０７)。失効状態の検査に関しては、失効状態検査部１２５に対して問い合わせを行う。システムの要件に応じて、RFC3280で規定されているエクステンションの詳細なチェックを行う。例えば、CertificatePolicyのチェックと受け入れCertificatePolicyIDのチェック、NameConstraintsの処理によるNameのチェックである。

失効状態検査部１２５は、CRL(Certificate Revocation List)、OCSP(Online Certificate Status Protocol)などを利用して、証明書パス検証部１２４から問い合わせのあった証明書の失効状態を検査し結果を返す。また、証明書の失効情報を検査する場合に証明書のエクステンションにCRLDistributionPointやAIA（AuthorityInformationAccess：例えばOCSPレスポンダのアドレスの記載）などに失効情報の取得先が示される場合がある。この取得先が既に閉鎖されており取得不可能か、或いは、取得先のサーバが非常に遅く適切な時間でレスポンスが得られないといった取得先に関する不都合な情報も保持し、失効検査の可否を判断する機能も有する。有効と判断された失効情報を受入可能失効情報に蓄積してもよい。

証明書パスの検査の結果問題が無ければ、正常終了である。各部は次の受信データの検査に備える。

一方、受信データ解析部１１２、証明書抽出部１２１、証明書受入判定部１２２、証明書パス構築部１２３、証明書パス検証部１２４においてエラーが発生した場合(Ｓ４０２〜Ｓ４０７でＮＯの場合）、各部は、エラーが発生した証明書を受入拒否証明書（拒否公開鍵検証情報）と判定し(Ｓ４０８)、エラー情報をエラー処理部１１４に渡す。エラー情報は、例えば以下である。

受信データ解析部１１２が生成するエラー情報：受信データのデコードエラー
証明書抽出部１２１が生成するエラー情報：証明書のデコードエラー（証明書が抽出できない）
証明書受入判定部１２２が生成するエラー情報：受入拒否の証明書である
証明書パス構築部１２３が生成するエラー情報：証明書パスが構築できなかった
証明書パス検証部１２４が生成するエラー情報：有効期限が切れている、署名が改ざんされている失効している（証明書パスが正当でない）
エラー情報は、例えばエラーコードとエラーが発生した証明書の識別情報などで構成される。

エラー処理部１１４では、あらかじめ設定したルールに基づき、データの受信者に対して、警告を行うか、通信の切断などの強制処理を行うか、その両方を同時に行うかを、エラー情報に基づき判断し、エラー処理を行う（Ｓ４０９）。

あらかじめ設定したルールとは、例えば、以下のようなルールである。

例１： Issuer＝XXX、SerialNumber＝YYYで識別されるＣＡ証明書の安全性は把握できないため受信した場合は警告を出す。

例２： Issuer＝XXX、SerialNumber＝YYYで識別されるＣＡ証明書で接続可能なサイトにはウィルスが仕込まれているので、通信を強制的に切断する。
エラー処理部１１４は、当ルールに基づき、警告を出す場合は警告部１１４ａに処理を移す。また、強制処理を行う場合は強制処理部１１４ｂに処理を移す。

警告部１１４ａは次の処理を行う。

受信データ解析部１１２から、受信データの送受信者情報を受け取る。例えばIPパケットのSorceIP/DestinationIP、TCPパケットのSorcePort/DestinationPortとタイムスタンプが該当する。この送受信者情報によりデータ（受入拒否証明書が含まれたデータ）の受信先（ユーザの端末１０２）を特定する。

次に、受信データ解析部１１２、証明書抽出部１２１、証明書パス構築部１２３、証明書受入判定部１２２、証明書パス検証部１２４からのエラー情報に対応する警告メッセージ（警告情報）を生成しデータ送信部１１５へ渡す。警告部１１４ａが作成する警告メッセージは例えば、図３に示すようなメッセージである。

警告メッセージには、受入を拒否する理由が特定できている場合は、その理由の詳細を記しても良い。

例： “以下の証明書で正常に接続可能なWebサイトでは金融に関する詐欺情報を流している恐れがあります。URL情報
http://www.○×△.com
を閲覧した情報は利用しないでください”
データ送信部１１５は、予め設定された送信方法で警告メッセージをデータの受信先へ送付する。例えば、メールにより警告メッセージを送信する（警告メール）。

エラー処理部１１４の強制処理部１１４ｂは、警告部１１４ａと同様に、受信データ解析部１１２から、受信データの送受信者情報を受け取り、データ（受入拒否証明書が含まれたデータ）の送信元（証明書発信機器１０５）とデータ（受入拒否証明書が含まれたデータ）の受信先（ユーザの端末１０２）を特定するとともに、受信データ解析部１１２、証明書抽出部１２１、証明書パス構築部１２３、証明書受入判定部１２２、証明書パス検証部１２４からのエラー情報に対応する予め設定した対応処理を行う。例えば、データ受信先に代わりＲＳＴパケットをデータ送信元に送出し強制切断する、メールサーバに対する受信者へのメールの配信の停止命令を出す、データ受信者に対してその後送受信されるデータの監視を優先する等の処理を行う。

このように、本実施の形態に係る証明書検証装置は、ネットワーク上の独立した機器として動作し、以下の機能を備えていることを特徴とする。
(a)ネットワーク上を流れるデータを受信するデータ受信機能；
(b)受信したデータから検査したいプロトコルデータ、アプリケーションデータを解析・抽出し、証明書や失効情報を含んだデータとプロトコル／アプリケーションの識別情報を出力する受信データ解析機能；
(c)証明書を含んだデータから１つ以上の証明書を抽出する証明書抽出機能；
(d)予め保持している受入可能な証明書に関する情報、及び、受入を拒否する証明書に関する情報を使用し、構築した証明書パス上の各証明書が受入可能な証明書か判定をする証明書受入判定機能；
受入可能／拒否の証明書に関する情報としては、証明書の実体、有効期限、発行者／持ち主のDistinguishedName、証明書のバージョン、公開鍵アルゴリズム、署名アルゴリズム、証明書ポリシー、鍵用途、失効検査方法、失効情報の取得先情報などのエクステンションの値、流入してきた連続する証明書の枚数、１枚の大きさなどを含む。
(e)抽出した１つ以上の証明書を利用し証明書パスを構築する証明書パス構築機能；
(f)証明書パス上の各証明書の有効期限、署名、エクステンション、失効状態等を検査する証明書パス検証機能；
(g)証明書パス上の各証明書が失効しているか検査する失効状態検査機能；
(h)次の警告機能と強制処理機能で構成されるエラー処理機能；
警告機能：証明書抽出機能、証明書パス構築機能、証明書受入判定機能、証明書パス検証機能において異常が検出された場合、データの受信者に対して警告を生成する機能。エラー情報、プロトコル／アプリケーションデータの識別子、データの送信者／受信者情報(src/dst)、タイムスタンプ等、データの受信者に対する警告情報を生成する。

強制処理機能：エラー発生時に、送／受信者間のプロトコルの強制切断などの命令を生成する機能。
(i)警告機能、強制処理機能で生成された警告や命令を送信するデータ送信機能。

そして、本実施の形態に係る証明書検証装置は、ネットワークを流れているデータから、証明書を含んだアプリケーションデータを受信し、さらに証明書を抽出し、予め保持している証明書に関する情報を利用して証明書の受入可否を一元的に検査し、証明書のパス構築、パス検証、失効検査を行い、システムにおいて安全性が不明、或いは受入不可能と判断した場合は、そのデータの受信者に対して、警告メッセージを送信したり、通信を切断するなどの処理を行う。これにより本実施の形態に係る証明書検証装置は、安全性が不明／安全ではないことが判明している証明書をエンドユーザが受け入れてしまうことによるシステムへの脅威を軽減する効果がある。また、本実施の形態に係る証明書検証装置は、ネットワーク上での独立したスニファ装置として機能するため、エンドユーザのアプリケーションの挙動とは非同期、非依存に動作する。

この結果、本実施の形態では、ネットワークを流れる証明書を監視することで、ネットワークとして受入が許可されない証明書の流入を検知した場合、該証明書の受信者に対して“証明書の一時受入を行い、情報を（Ｗｅｂ／メールなどで）閲覧した場合は、その情報を破棄せよ”、“証明書のトラストストアへの格納を禁止する”などの警告をエンドユーザへ送信し、さらには通信の切断などの強制処置も実現することが可能となる。これにより、エンドユーザが安全性が疑わしい或いは安全でないことが判明しているＷｅｂサイトやメール等を閲覧し、入手した情報に基づき行動を起こしたり、或いは、問題のあるコンテンツを端末上にダウンロードしてしまうこと等による危険性を低減することが可能である。

また、上記の説明では、ネットワークへ流入する証明書を監視するように記述したが、エンドユーザからネットワーク外へ送信するデータにおいて証明書が含まれており、かつ、ネットワークで許可されないＣＡから発行されたものであれば、上記と同様の処理により安全性が不確かな通信を未然に防ぐことが可能である。

当実施の形態では、既存のシステムにネットワーク監視装置として証明書検証装置を設置する方式をとるため、クライアントを含め既存のシステムの変更の必要はなく、クライアントの使用するPKIアプリケーションに関係なく動作する。そのため、ユーザ権限でトラストストアに証明書を格納する運用を維持しつつ安全性も確保できる。

実施の形態２．
本実施の形態では、実施の形態１において、証明書抽出部１２１、証明書パス構築部１２３、証明書受入判定部１２２、証明書パス検証部１２４のいずれかにおいてエラーが発生した場合、受入を拒否すると判定した証明書を、受入拒否証明書情報に蓄積し、受入拒否証明書情報を増やすことで、後に続く証明書を含んだデータの検査において受入拒否の証明書の判定を効率化するものである。

図５は、本実施の形態に係る証明書検証装置１０１の構成例を示しており、図１の構成に情報書込み部１２６が追加されている。情報書込み部１２６は、証明書抽出部１２１、証明書パス構築部１２３、証明書受入判定部１２２、証明書パス検証部１２４のいずれかにおいてエラーが発生した場合に、受入拒否証明書と判定された証明書の内容をデータベース１１３の受入拒否証明書情報に書込む。他の構成要素は、図１と同じなので、説明は省略する。

例えば、悪意のあるメール送信者が詐欺メールをネットワーク内の複数のユーザに送付している場合は、最初のメールの検査時に受入拒否証明書情報に証明書が蓄積されるため、以降のメールについては迅速に受入拒否の判定が可能となり、ユーザへの通知も迅速に処理可能となる。

また、当概念を受入可能証明書情報に拡張し、受入可能と判定された証明書を受入可能証明書情報に格納することにすれば、同様に証明書受入判定部１２２における判定が効率化される。

このように、本実施の形態に係る証明書検証装置は、証明書受入判定機能、証明書パス構築機能、証明書パス検証機能の動作の結果として、証明書が受入不可能と判定された場合に、その証明書に関する情報を受入を拒否する証明書として手動または自動的に蓄積するとともに、同様に、これらの機能の動作の結果として、証明書が受入可能と判定された場合に、その証明書に関する情報を受入が可能な証明書として手動または自動的に蓄積する機能を有する。

実施の形態３．
本実施の形態では、実施の形態１に示した受信データ解析部１１２以降の証明書抽出部１２１→証明書受入判定部１２２→証明書パス構築部１２３→証明書パス検証部１２４→失効状態検査部１２５という一連の流れにおいて、任意の機能まで処理を行うものである。

例えば、受入可能証明書情報と受入拒否証明書情報が十分にあり、証明書抽出部１２１→証明書受入判定部１２２までの処理を実施すれば受入を拒否する証明書が識別可能な場合には、証明書抽出部１２１→証明書受入判定部１２２までの処理を行い、証明書受入判定部１２２により受入拒否証明書と判定された証明書についてエラー処理部１１４がエラー処理を行う。よって、証明書検証装置の高速化を実現可能である。

実施の形態４．
実施の形態1では、証明書検証装置が証明書の検証を行う場合について説明した。本実施の形態では、公開鍵検証情報として、証明書の失効状態を調べるための失効情報の検査を行う場合について述べる。本実施の形態は、発明が解決しようとする課題における（２）失効情報の管理の課題に示した課題のうち、失効情報を利用したＤｏＳ(Ｄｅｎｉａｌ Ｏｆ Ｓｅｒｖｉｃｅ)攻撃を回避するものである。

失効情報の署名を検証するためにも証明書が必要であり、論理的にはその証明書の検証処理にも失効情報が使用されることがあるため、証明書と失効情報の検査が繰り返し発生することもあり得る。仮に、この失効情報を検証するための証明書がパケットに含まれていない場合は、エンドユーザがディレクトリサーバなどを検索する必要もあり、さらに、検索して得られた証明書を検査するための失効情報も再度ディレクトリサーバを検索したり、或いは、OCSPサーバに問い合わせることもある。

攻撃者は、この特性を悪用し、失効情報の検査において証明書と失効情報の検査が多段階に必要となるような失効情報を生成することが考えられる。仮に、エンドユーザがこの失効情報の作成者の証明書を詐称メールの指示に従いトラストストアに格納していた場合は、エンドユーザに対して証明書と失効情報の検査に多大な処理を行わせることも可能であり、なおかつ、処理時間はかかるもののエンドユーザには正常な処理を行っているようにしか見えない。このような処理を強いることは、一種のＤｏＳ(Ｄｅｎｉａｌ Ｏｆ Ｓｅｒｖｉｃｅ)攻撃といえる。

本実施の形態に係る証明書検証装置は、上記のような失効情報の署名の検証を悪用したＤｏＳ攻撃に対抗するため、ネットワークに流入してきた失効情報を捕らえ、その失効情報について受入可能か検査する。つまり、ネットワーク上を流れる失効情報について、エンドユーザがその検査を行った場合に、不必要に過大な処理を強いられるような異常なものではないかを検査する。

図６は、本実施の形態に係る証明書検証装置の構成例を示す図である。図６では、図１に示す構成に、失効情報抽出部１３１と失効情報受入判定部１３２を追加した構成となっている。

失効情報抽出部１３１はプロトコルデータからCRLやOCSPレスポンダなどの失効情報を抽出する機能である。

失効情報受入判定部１３２は、予め保持している受入可能失効情報、及び、受入拒否失効情報を使用して抽出した失効情報が受入可能か判定する機能である。

他の構成要素は、図１に示したものと同様なので、説明は省略する。

なお、本実施の形態では、受信データ解析部１１２と失効情報抽出部１３１が解析抽出部の例となり、失効情報受入判定部１３２が受入可否判定部の例となる。

次に、図８のフローチャートを参照して、本実施の形態に係る証明書検証装置の動作について説明する。

先ず、データ受信部１１１はネットワーク上を流れるデータを受信し（Ｓ８０１）、受信データ解析部１１２にデータを渡す。

受信データ解析部１１２は、受信データからシステム管理者が指定した検査したいプロトコル／アプリケーションデータが含まれているか否かを解析し(Ｓ８０２)、当該データを抽出する(Ｓ８０３)。例えば、S/MIMEのデータに含まれる失効情報を検査したいのであれば、S/MIMEのデータを抽出する。或いは、SSLハンドシェイク時における通信相手の証明書の失効チェック時に利用されるCRLのダウンロードデータ、又はOCSPのレスポンスデータを抽出する。抽出されたデータには失効情報が含まれている。抽出されたデータは失効情報抽出部１３１に渡される。

失効情報抽出部１３１はプロトコル／アプリケーションデータから１枚以上の失効情報を抽出する(Ｓ８０４)。抽出した失効情報は失効情報受入判定部１３２へ渡される。

失効情報受入判定部１３２は、予め蓄積されている受入可能失効情報と受入拒否失効情報を利用して、失効情報が受入可能か検査する(Ｓ８０５）。

受入可能失効情報とは、システムにおいて受入可能と判断される失効情報の情報であり、例えば、有効期限、発行者のDistinguishedName、通し番号、IssuingDistributionPoint、署名を検証するために必要な証明書の識別子、失効情報本体などである。

受入拒否失効情報とは、システムにおいて受入を拒否する失効情報の情報であり、受入可能情報と同様に、有効期限、発行者のDistinguishedName、通し番号、IssuingDistributionPoint、署名を検証するために必要な証明書の識別子、失効情報本体などである。

失効情報受入判定部１３２は、失効情報が受入可能と判断した場合は正常終了であり、次の失効情報の判定に備える。或いは、受入可能の情報として受入可能失効情報に蓄積してもよい。

一方、失効情報が受入拒否と判断した場合や、受信データ解析部１１２、失効情報抽出部１３１でエラーが発生した場合(Ｓ８０２〜Ｓ８０５でＮＯの場合)は、各部は、エラーが発生した失効情報を受入拒否失効情報（拒否公開鍵検証情報）と判定し（Ｓ８０６）、エラー情報をエラー処理部１１４に渡す。エラー情報は、例えば以下である。

受信データ解析部１１２が生成するエラー情報：受信データのデコードエラー
失効情報抽出部１３１が生成するエラー情報：失効情報のデコードエラー
失効情報受入判定部１３２が生成するエラー情報：受入拒否の失効情報である
エラー情報は、例えばエラーコードとエラーが発生した失効情報の識別情報などで構成される。

エラー処理部１１４では、あらかじめ設定したルールに基づき、データの受信者（ユーザの端末１０２）に対して、警告を行うか、通信の切断などの強制処理を行うか、その両方を同時に行うかを、エラー情報に基づき判断し、エラー処理を行う（Ｓ８０７）。

あらかじめ設定したルールとは、例えば、以下のようなルールである。

例１：Issuer＝XXX、SerialNumber＝YYY（CRLの場合はCRLNumber）で識別される失効情報の安全性は把握できないため受信した場合は警告を出す。

例２：Issuer＝XXX、SerialNumber＝YYY（CRLの場合はCRLNumber）で識別される失効情報はDoS攻撃の危険性を含んでいるため、通信を強制的に切断する。

エラー処理部１１４は、当ルールに基づき、警告を出す場合は警告部１１４ａに処理を移す。また、強制処理を行う場合は強制処理部１１４ｂに処理を移す。

警告部１１４ａは次の処理を行う。

受信データ解析部１１２から、受信データの送受信者情報を受け取る。例えばIPパケットのSorceIP/DestinationIP、TCPパケットのSorcePort/DestinationPortとタイムスタンプが該当する。この送受信者情報によりデータ（受入拒否失効情報が含まれたデータ）の受信先（ユーザの端末１０２）を特定する。

次に、受信データ解析部１１２、失効情報抽出部１３１、失効情報受入判定部１３２からのエラー情報に対応する警告メッセージ（警告情報）を生成しデータ送信部１１５へ渡す。警告部１１４ａが生成する警告メッセージは、例えば図７に示すメッセージである。

警告メッセージには、受入を拒否する理由が特定できている場合は、その理由の詳細を記しても良い。

データ送信部１１５は、予め設定された送信方法（例えば、メール）で警告メッセージをデータ受信者へ送付する。

エラー処理部１１４の強制処理部１１４ｂは、警告部１１４ａと同様に、受信データ解析部１１２から、受信データの送受信者情報を受け取り、データ（受入拒否失効情報が含まれたデータ）の送信元（証明書発信機器１０５）とデータ（受入拒否失効情報が含まれたデータ）の受信先（ユーザの端末１０２）を特定するとともに、受信データ解析部１１２、失効情報抽出部１３１、失効情報受入判定部１３２からのエラー情報に対応する予め設定した対応処理を行う。例えば、データ受信先に代わりＲＳＴ パケットをデータ送信元に送出し強制切断する、メールサーバに対する受信者へのメールの配信の停止命令を出す、データ受信先に対してその後送受信されるデータの監視を優先する等の処理を行う。

また、上記のエラー処理に加えて、図５に示した情報書込み部１２６を追加して、当失効情報を受入拒否の失効情報として受入可能失効情報に蓄積してもよい。

このように、本実施の形態に係る証明書検証装置は、以下の要素を有することを特徴とする。

(ｊ)失効情報を含んだデータから１つ以上の失効情報を抽出する失効情報抽出機能；
(ｋ)予め保持している受入可能な失効情報に関する情報、及び、受入を拒否する失効情報に関す
る情報を使用し、抽出した失効情報が受入可能か判定をする失効情報受入判定機能。

また、本実施の形態に係る証明書検証装置において、受入可能／拒否の失効情報に関する情報としては、CRLやOCSP等の失効情報の実体、有効期限、発行者のDistinguishedName、失効情報のバージョン、署名アルゴリズム、署名を検証するための証明書の識別子、エクステンションの値、流入してきた連続する失効情報の数、大きさなどを含む。

また、本実施の形態に係る証明書検証装置は、ネットワークを流れているデータから、失効情報を含んだアプリケーションデータを受信し、失効情報抽出機能により失効情報を抽出し、失効情報受入判定機能により失効情報についてもシステムにおいて使用が許諾されるか否かを判定し、システムにおいて受入不可能と判断した場合は、そのデータの受信者に対して、警告メッセージを送信したり、通信を切断するなどの処理を行うことでシステムへの脅威を軽減することを特徴とする。

そして、検査した失効情報が受入不可能と判定された場合、その失効情報に関する情報を受入を拒否する失効情報として蓄積し、以後の失効情報の検査に利用することも可能である。

更に、検査した失効情報が受入可能と判定された場合、その失効情報に関する情報を受入可能な失効情報として蓄積し、以後の失効情報の検査に利用することも可能である。

このように、本実施の形態によれば、失効情報を検査することにより、異常な失効情報によるDoS等の攻撃を早期に検知し、エンドユーザに警告を発したり接続を強制切断することが可能である。

なお、本実施の形態では、失効情報を検査すべき理由としてDoS攻撃対策を例に説明しているが、システムで受け入れられない失効情報の種類や、サポートしていない署名アルゴリズム、失効情報のエンコード、大きさ、有効期限などの情報を、受入可能失効情報／受入拒否失効情報として蓄積していればDoS攻撃防止以外の目的で失効情報の篩い分けが可能である。

実施の形態５．
本実施の形態では、システム管理者が明示的に許可している証明書以外に明らかにシステムに悪影響を与えない証明書の利用を実現する例について説明する。なお、本実施の形態において、ネットワーク内でローカルにやり取りする証明書であって、ネットワークに悪影響を与えないものを「信頼ローカル証明書（ローカル公開鍵検証情報）」と呼ぶ。

例えば、信頼できる社員同士が自作の信頼ローカル証明書を作成し業務メールを署名付き電子メールで交換する場合などにおいて、実施の形態１に示した証明書検証装置をそのまま適用すると、証明書検証装置がこのような証明書の受入を拒否すると判断した場合は、警告や強制処理が行われる。この結果、エンドユーザ自身が安全性を判断して差し支えない場合にまで警告や強制処理が行われるため、エンドユーザの利便性を損ねることになる。

本実施の形態では、図５に示す証明書検証装置１０１の構成に、証明書検証装置のオペレータ（システム管理者）からの入力を受け付けるオペレータ入力部を追加した構成とする。

例えば、信頼ローカル証明書の送信元からの申告により、証明書検証装置のオペレータ（システム管理者）が信頼ローカル証明書の内容をオペレータ入力部を通じて証明書検証装置１０１に入力する。

情報書込み部１２６は、オペレータ入力部より入力された信頼ローカル証明書の内容をデータベース１１３内の受入可能証明書情報に書込む。

そして、信頼ローカル証明書を含むデータがローカルに送受信された際に、受信データ解析部１１２及び証明書抽出部１２１における信頼ローカル証明書の解析抽出処理の後、証明書受入判定部１２２が、証明書抽出部１２１により抽出された信頼ローカル証明書の内容が受入可能証明書情報に含まれているか否かを検証し、当該信頼ローカル証明書の内容が受入可能証明書情報に含まれている場合に、当該信頼ローカル証明書を受入可能と判定する。

このような構成にすることで、エンドユーザ間で信頼ローカル証明書の送受信が行われても、証明書検証装置から警告／強制処理が行われることがなく、エンドユーザ間の利便性を高めることができる。

実施の形態６．
上記実施の形態では、ネットワーク上に証明書検証装置を設置しネットワークデータを監視する形態であるが、例えば、Proxy／ゲートウェイサーバやルータなどの所定のネットワーク内外の通信を中継するネットワーク機器に組み込み、ネットワークデータを検査しても良い。

実施の形態７．
また、証明書／失効情報はエクステンションに付加情報を格納することが可能であり、攻撃コードやウィルスを格納する可能性もある。上記の実施の形態において、証明書抽出部１２１などにウィルス検出機能を実装することで早期に危険な証明書／失効情報を検出してもよい。

実施の形態８．
本実施の形態では、上記の実施の形態に示した証明書検証装置が、ユーザの端末１０２への警告メッセージの通達手段としてメールを利用する場合において、警告メールを受信したエンドユーザが、警告メールに対して、警告対象の証明書（受入拒否証明書）を利用した通信／アプリケーションにおいてどのような処理を行ったかをリプライする例について説明する。

図９は、本実施の形態に係る証明書検証装置の構成例を示す図である。図９では、図６に示す構成に、コンテンツ解析部１１６とペンディング情報蓄積部１１７を追加した構成となっている。

コンテンツ解析部１１６は、ユーザの端末１０２からのリプライ（リプライ情報）に示された警告対象の証明書がユーザの端末においてどのように取扱われたかという取扱態様を解析し、当該警告対応の証明書の取扱態様に応じた対策処置を指定する。エラー処理部１１４は、コンテンツ解析部１１６により指定された対策処置を行う。

ペンディング情報蓄積部１１７は、警告対象の証明書をペンディング情報として一時的に蓄積する。

他の構成要素は、図６に示したものと同様なので、説明は省略する。

なお、本実施の形態では、データ受信部１１１は、リプライ情報受信部の例であり、コンテンツ解析部１１６は、取扱態様解析部の例である。

本実施の形態では、警告部１１４ａは、例えば、図１０に示すように、受入拒否証明書がユーザの端末１０２でどのように扱われたのかを問い合せる警告メッセージを生成し、データ送信部１１５から当該警告メッセージを送信する。

そして、ユーザの端末１０２では、例えば図１１に示すような、受入拒否証明書の取扱態様を示すリプライを送信し、証明書検証装置１０１では、データ受信部１１１が当該リプライを受信する。

そして、受信データ解析部１１２において、データ受信部１１１が受信したデータが、警告メッセージに対するリプライであることを識別し、当該リプライはコンテンツ解析部１１６へ渡される（宛先がシステム管理者であること、件名などから警告のリプライメールであることを判別可能である）。

コンテンツ解析部１１６においては、エンドユーザにおける証明書の取扱態様と対策処置とを予め決定しておき、これに基づき処理を行う。例えば、リプライに示された取扱態様と対策処置とを図１２のように決めておく。そして、コンテンツ解析部１１６は、図１２のルールに従って、実施すべき対策処置を決定し、エラー処理部１１４がコンテンツ解析部１１６の決定した処置を行う。
ペンディング情報蓄積部１１７に蓄積された証明書に関して、システム管理者によりどのような処置が行なわれるのかが決定した場合は、受入可能証明書情報又は受入拒否証明書情報に蓄積し、ペンディング情報蓄積部１１７から削除する。

また、ユーザが警告対象の証明書を利用した通信／アプリケーションにおいてどのような処理を行ったかをリプライする手段として、Ｗｅｂシステムを利用してもよい。例えば、警告メールに処理報告用ＷｅｂサイトのＵＲＬを記載し、ブラウザで指定することで該Ｗｅｂサイトに接続する。そして、当該Ｗｅｂサイトでは、1)一切の処理を中止し通信を行わなかった、2)証明書を一時受け入れ通信した、3)証明書をトラストストアに格納した、4)わからない、のいずれかを選択させるコンテンツを準備する（例：ラジオボタンによる処理の選択とPOSTメソッドによる選択した処理の送信）。

例えば、該Ｗｅｂサーバはイントラネット内に設置されシステム管理者により運用してもよい。なお、リプライ状況への対応は図１２と同じでよい。

また、警告メールに対するリプライや処理報告用Webサイトへのリプライが指定期日までに無かった場合は、例えば以下のように処理を取り決めておいてもよい。

警告メールを再度送信する（リプライ期日は延長する）
警告メールを再度送信する（リプライ期日は延長する）。リプライがない場合は以後の同証明書を利用した通信は遮断する旨を警告する。

このように、本実施の形態に係る証明書検証装置は、警告情報を受信したエンドユーザが警告情報を受信した後の処理について証明書検証装置へ報告を行うことで、同報告を元に、再度証明書を利用した通信をやめるように警告したり、トラストストアからの削除を警告することが可能である。警告の報告は、メールへのリプライか、専用Ｗｅｂサイトにおける申告がある。

これにより、エンドユーザにおける取扱態様に応じて、適切な対策処置を実施することができる。

実施の形態９．
本実施の形態では、上記の実施の形態に示した証明書検証装置が、安全性の不明な証明書を含むデータを捕らえた場合、後続のプロトコルデータについても検査を行うことで、証明書を受け入れて通信が行われたか否かを判断する例を説明する。

図１３は、本実施の形態に係る証明書検証装置の構成例を示す図である。図１３では、図６に示す構成に、受信データ蓄積部１１４ｃと蓄積データ解析部１１４ｄを追加した構成となっている。

受信データ蓄積部１１４ｃは、いずれかの証明書が受入拒否証明書と判定された場合に、受入拒否証明書の送信元との受信先との間で送受信されるデータをデータ受信部１１１から取得して蓄積する。

蓄積データ解析部１１４ｄは、いずれかの証明書が受入拒否証明書と判定された場合に、受入拒否証明書の送信元との受信先とを特定するとともに、受信データ蓄積部１１４ｃに蓄積された内容から受入拒否証明書の送信元との受信先との間で送受信されるデータの監視を行い、受入拒否証明書の受信先において受入拒否証明書の受入が行われたか否かを判定する。

他の構成要素は、図６に示したものと同様なので、説明は省略する。

例えば、SSLでは、HandShakeProtocolで証明書を使用した認証や暗号アルゴリズムの調整の後、暗号通信であるApplicationDataProtocolに移行する。

従って、証明書を受信したエンドユーザと送信者間において、ApplicationDataProtocolが送受信された場合は、証明書が受信者において受入れられたことが判定可能である。この場合の受入は、ユーザ選択による一時的な受入、又はトラストストアに該証明書の検証用に必要なＣＡ証明書などが既に格納されている状態での受入のいずれかである。

本実施の形態では、受信データ解析部１１２がプロトコルデータを受信し、証明書受入判定部１２２等により当該プロトコルデータに含まれた証明書の受入が拒否された際に、当該プロトコルデータの送信元及び受信先の間で送受信される以降のデータが受信データ蓄積部１１４ｃに蓄積される。例えば、SSLであれば、HandShakeProtocolデータからApplicationDataProtocolまで蓄積する。

つまり、証明書抽出部１２１、証明書パス構築部１２３、証明書パス検証部１２４、失効状態検査部１２５からの応答において、証明書が受入不可能と判定された場合、エラー処理部１１４へ証明書の受入は不可能であることが通知される。この場合に、蓄積データ解析部１１４ｄが、受入が拒否された証明書の送信元及び受信先を特定するとともに、受信データ蓄積部１１４ｃが、当該送信元及び受信先の間で送受信される以降のデータを蓄積する。そして、蓄積データ解析部１１４ｄは、受信データ蓄積部１１４ｃに蓄積される同送受信者間のデータを監視し、蓄積されているデータに、受入拒否証明書の受信先における受入を基にセキュア通信が行われていることを示すデータが含まれているかどうかを判断し、そのようなデータが含まれている場合は、証明書の受信先において受入拒否証明書が受入れられたと判断し、警告部１１４ａ、強制処理１１４ｂにより受信者へのエラー処理用のメッセージが生成される。SSLの場合ではApplicationDataProtocolのデータが蓄積されていた場合に、証明書の受信先において受入拒否証明書が受入れられたと判断する。

さらに、受信先において証明書が受入れられている場合に、当該証明書の受入が、ユーザ選択による一時受入であるのか、トラストストアに該証明書の検証用に必要なＣＡ証明書などが既に格納されている状態で受け入れているかを判定するには、HandShakeProtocolにおける証明書の処理時間（証明書の受入に要する時間）を計測する。例えば、HandShakeProtocolにおいては、サーバ証明書は、ServerHello, (Server)Certificates, ServerHelloDone という一連のメッセージでサーバからクライアントへ送信され、クライアントにおいてはServerHelloDone受信後にCertificatesに含まれるサーバ証明書の確認処理を行い、その後、ClientKeyExchange及びその他のメッセージを送信する。

そこで、このプロトコルデータの送受信の処理順序に基づき、ServerHelloDoneを受信してから次のクライアント側からサーバ側への送信メッセージであるClientKeyExchangeを送出するまでにＮ秒以上経過している場合はＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）によるユーザ選択による受入の可能性があるという判断を行い、一方Ｎ秒未満の場合はトラストストアに該証明書を検証用に必要なＣＡ証明書などが既に格納されている状態で受け入れている可能性があるという判断を行う。

ブラウザによってはHandShakeProtocol自体は完了させてしまい、ApplicationDataProtocolに遷移する前にGUIによるユーザ選択を表示する実装もあるが、HandShakeProtocolからApplicationDataProtocolへの遷移にかかる時間がＮ秒以上の場合は一時受入の可能性がある、という判断が可能である。証明書の処理時間がＮ秒以上であるか否かは、例えば、サーバ側からのChangeCipherSpecの送信時刻とクライアントからのApplicationDataProtocolの送信時刻の差分を調べればよい。

ここで、上記Ｎはシステム管理者が予め設定する値であり、エンドユーザにおける使用している端末の処理性能に基づき決定する。なお、現在の通信がどのブラウザにより行われているか判別するためには、HTTPS(RFC2818 HTTP Over TLS)通信であれば、ハンドシェイク開始前にProxyサーバへのCONNECTメソッド送信時に送られるユーザエージェントを識別すればよい。

本実施の形態では、図１３において、プロトコルデータが受信され、プロトコルデータに含まれた証明書の受入が拒否された場合は、以降のデータが受信データ蓄積部１１４ｃに蓄積される。例えば、SSLであれば、HandShakeProtocolデータからApplicationDataProtocolまで蓄積する。証明書はHandShakeProtocolデータに含まれるため、実際にはHandShakeProtocol開始時点から受信データ蓄積部１１４ｃにプロトコルデータを蓄積し、証明書が拒否された場合に、蓄積データを破棄せずに、プロトコルデータを継続して蓄積し、証明書の受入が行われたか判断するための情報として利用する実装でも良い。

つまり、証明書抽出部１２１、証明書パス構築部１２３、証明書パス検証部１２４、失効状態検査部１２５からの応答において、証明書が受入不可能と判定された場合、エラー処理部１１４へ証明書の受入は不可能であることが通知される。蓄積データ解析部１１４ｃは、その時点で受信データ蓄積部１１４ｃに蓄積されている同送受信者間のデータで、証明書の受信データと、証明書の受入が行われた場合に継続処理されるデータの受信時刻の差分を計算し、システムで規定した時間（Ｎ秒）以上の差分であるならば、ユーザ選択による一時受入が発生しており、それ以外の場合は、トラストストアに該証明書の検証に必要なＣＡ証明書などが既に格納されていると判断する。

SSLであれば、ServerHelloDoneの受信時刻とClientKeyExchangeの送出時刻の差分（或いは、サーバ側からのChangeCipherSpecの送信時刻とクライアント側からのApplicationDataProtocolの送信時刻の差分）等を調べる。

このように、本実施の形態に係る証明書検証装置は、セキュアプロトコルデータを監視し、安全性が確認できない、或いは受入が不可能な証明書を捕らえた場合、その後のプロトコルデータを継続監視し、証明書を使用したセキュア通信が実施されたか否か判定する。通常、セキュアプロトコルのシーケンスでは、証明書のチェックのタイミングか決まっているため、プロトコルシーケンスを監視することで証明書が受け入れられたかの判定が可能である。

また、本実施の形態に係る証明書検証装置は、セキュアプロトコルデータを監視し、安全性が確認できない、或いは受入が不可能な証明書を捕らえた場合、その後のプロトコルデータを継続監視し、証明書を使用したセキュア通信が実施された場合において、同通信が、証明書の一時的な受入によるものか、既にトラストストアに検証に必要な証明書が格納されているためにセキュア通信が行われたのかを、プロトコルシーケンスと証明書の処理タイミングに基づき、証明書の処理に規定時間以上の時間が費やされているか否かを計測することで判定する。

このように、本実施の形態では、セキュアプロトコルにおいて、通信相手の証明書を受け入れた結果発生するはずであるセキュア通信を捕らえることにより、通信相手の証明書の受入の有無を識別し、さらに、プロトコルシーケンスにおける証明書の処理のタイミングに基づき、証明書を処理する時間を把握し、規定時間よりも処理時間がかかっていた場合は、ユーザ判断による証明書の受入が発生したことを判定する。これにより、証明書の受信先における証明書の受入状況に対応した適切な対策処置を実施することができる。

実施の形態１０．
本実施の形態は、上記の実施の形態に示した証明書検証装置が、安全性の不明な証明書を含むデータを捕らえた場合において、証明書の受信者から送信されるデータを監視することにより、証明書の受信者が所定の行動を起こしていると判断する例について説明する。

証明書検証装置が、安全性の不明な証明書を含むデータを捕らえた場合において、データがセキュアメールであれば、メールを受信したエンドユーザから送信者へリプライメールが送られていた場合は証明書を受け入れたセキュアメールを閲覧した結果、所定の行動を起こしていると判断することができる。

セキュアメールの場合は受信からリプライまでの期間を予め証明書検証装置で指定する。例えば、Ｍ時間はリプライメールの有無を監視するなど規定する。

ここで、上記Ｍはシステム管理者が予め設定する値でありシステム運用のポリシーから決定する。０．５時間でも良いし１年でも良い。無制限に設定してもよく、実質は時間の制限をかけていないことになる。

本実施の形態に係る証明書検証装置は、図１３に示したものと同じ構成である。

本実施の形態では、証明書が含まれたセキュアメールデータが受信され、証明書受入判定部１２２等により当該セキュアメールに含まれた証明書の受入が拒否された際に、蓄積データ解析部１１４ｄが当該セキュアメールデータの送信元及び受信先を特定するとともに、当該送信元及び受信先の間で送受信される以降のデータが受信データ蓄積部１１４ｃに蓄積される。

つまり、証明書抽出部１２１、証明書パス構築部１２３、証明書パス検証部１２４、失効状態検査部１２５からの応答において、証明書が受入不可能と判定された場合、エラー処理部１１４へ証明書の受入が不可能であることが通知される。エラー処理部１１４は、この時点で、エラー処理を実施するが、一方で、蓄積データ解析部１１４ｄが、受入が拒否された証明書が含まれたセキュアメールの送信元及び受信先を特定し、受信データ蓄積部１１４ｃがＭ時間の間当該送信元及び受信先間で送受信されるデータを継続して蓄積する。蓄積データ解析部１１４ｄが、受信データ蓄積部１１４ｃに蓄積されたデータに基づいて該セキュアメールの受信者が送信者に対してメールを送信したことを検知した場合は、該セキュアメールを閲覧した結果何らかの行動を起こしたと判断し、以降、警告部１１４ａ、強制処理１１４ｂにより受信者へのエラー処理用のメッセージが生成される（再度エラー処理を行う）。

また、セキュアメールが暗号メールではなく、署名メールであった場合にはメールの内容は証明書検証装置１０１でも把握可能である。受信データ解析部１１２より証明書を含んだセキュアメールデータを受信し、証明書抽出部１２１、証明書パス構築部１２３、証明書パス検証部１２４、失効状態検査部１２５からの応答において、証明書が受入不可能と判定された場合、エラー処理部１１４へ証明書の受入は不可能であることが通知される。エラー処理部１１４はこの時点で、エラー処理を実施するが、一方で、蓄積データ解析部１１４ｄはメールの内容を解析し、当該セキュアメールデータの送信元及び受信先を特定するとともに、送信者アドレス、ＣＣに記載されているアドレス、本文に記載のＵＲＬ(Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ)などを抽出し、受信データ蓄積部１１４ｃに渡す。受信データ蓄積部１１４ｃはＭ時間の間セキュアメールデータの受信者から送信されたデータがあれば当該受信者からの送信データを蓄積する。

蓄積データ解析部１１４ｄが、受信データ蓄積部１１４ｃに蓄積されたデータに基づいて、蓄積データ解析部１１４ｄにより抽出された送信者アドレス又はＣＣ先アドレスを宛先とするメールが該セキュアメールの受信者から送信されたこと、又は蓄積データ解析部１１４ｄにより抽出されたＵＲＬを宛先とするＨＴＴＰ等の通信によるアクセスが該セキュアメールの受信者から行われたことを検知した場合に、該セキュアメールを閲覧した結果何らかの行動を起こしたと判断し、以降、警告部１１４ａ、強制処理１１４ｂにより受信者へのエラー処理用のメッセージが生成される（再度エラー処理を行う）。

このように、本実施の形態に係る証明書検証装置は、セキュアメールデータを監視し、安全性が確認できない、或いは受入が不可能な証明書を捕らえた場合、その後、同メールの受信者が同メールの送信者にメールを送信したか否かを継続監視することで、メールの受信者がセキュアメールデータに対する処理を実施しているか否かを判定する。

また、本実施の形態に係る証明書検証装置は、セキュアメールが暗号化メールではなく、署名メールなどの場合は、メールの内容を閲覧することが可能である。そこで、セキュアメールデータを監視し、安全性が確認できない、或いは受入が不可能な証明書を捕らえた場合、メールのコンテンツから、送信元アドレス、ＣＣ先アドレス、本文中に記載されているＵＲＬなど通信に関する情報を抽出・蓄積し、以後、当受信者の通信を監視し、蓄積しているメールアドレスやＵＲＬへアクセスしていることを検出した場合は、上記セキュアメールの内容を元に処理を実行していると判断し、警告や切断などの強制処理を実現する。

このように、本実施の形態によれば、証明書の安全性が不明／受入不可のセキュアメールの受信に対してエンドユーザがこれを閲覧し何らかの行動を起こしたか否かを、該メールのリプライメールを監視することでチェック可能であり、エンドユーザの行動の有無に対応して適切な対策処置を実施することができる。

実施の形態１１．
本実施の形態は、上記の実施の形態に示す証明書検証装置に、レポート情報生成通知部を追加することにより、データベース内の許諾情報（受入可能条件情報）や拒否情報（受入拒否条件情報）の内容を示すレポート情報を生成し、生成したレポート情報をネットワーク内のユーザの端末１０２等に対して通知する。

上記の実施の形態に示す証明書検証装置には受入可能／不可能な証明書／失効情報のデータが蓄積される。本実施の形態では、レポート情報生成通知部により、蓄積されたこれらのデータを定期的にレポート化する。例えば、週１回ＨＴＭＬコンテンツでレポートを作成してシステム内イントラネットに公表することで、システム内エンドユーザへの安全性情報として提示することが可能であり、エンドユーザへのフィードバックがかけられる。

このように、本実施の形態に係る証明書検証装置は、蓄積された受入可能／不可能な証明書／失効情報のデータを予め定められたフォーマット（例：ＨＴＭＬコンテンツ）にレポート化する。

実施の形態１２．
実施の形態１〜１１に係る証明書検証装置は、ネットワーク上を流れる送受信データを監視して受入が許可されない証明書の流入を察知し、エンドユーザへ警告や強制処理を実施するようにしたものであるが、以下にシステム管理者がエンドユーザのトラストストアを直接管理する実施の形態を示す。

本実施の形態は、発明が解決しようとする課題における（１）信用する証明書の管理の課題に示した課題を解決するものである。

図１４は、本実施の形態に係るトラストストア管理装置及びトラストストア監視装置を含むシステム全体の構成を示す図である。

トラストストア管理装置２０１は、ユーザの端末４０１にあるトラストストア４０２内の証明書などを管理する。また、トラストストア監視装置３０１からの指示に基づき、トラストストア４０２に格納されている証明書などの格納状況を調査し、トラストストア４０２に格納されている証明書などを通知するトラストストア情報を生成し、トラストストア監視装置３０１にトラストストア情報を送信する。また、トラストストア監視装置３０１からの指示に基づき、トラストストア内の証明書などの削除、更新、追加の処置を行う。当装置はエンドユーザの端末などに設置される。実装形態はソフトウェアでもハードウェアでも良い。

トラストストア監視装置３０１は、トラストストア管理装置２０１に対してトラストストア情報の作成及び送信を命じ、また、トラストストア情報の内容に従って、トラストストア内の証明書などの削除、更新、追加の処置の要否を判断し、いずれかの処置が必要な場合に、トラストストア管理装置２０１に証明書などの削除、更新、追加のいずれかの処置を命ずる。当装置はシステム管理者の端末に設置される。実装形態はソフトウェアでもハードウェアでも良い。

ユーザの端末４０１、トラストストア４０２、システム管理者の端末５０１、ＣＡ６０1は、それぞれ図１に示したものと同様なので、説明を省略する。

図１５は、本実施の形態に係るトラストストア管理装置２０１の構成例を示す図である。

命令受信部２１３はトラストストア監視装置３０１からトラストストアを管理するための命令情報を受信する機能である。受信する命令情報は、トラストストア情報の生成及び送信を命令する送信命令情報と、トラストストア内の証明書などの削除、更新、追加を命じる処置命令情報がある。

トラストストア管理部２１２は、命令受信部２１３が受け取った命令情報に従って、格納されている証明書の情報を収集してトラストストア情報を生成し、また、指定された証明書などを削除、更新、追加するなど、トラストストアの管理を行う機能である。

トラストストア情報送信部２１１はトラストストア情報をトラストストア監視装置３０１に送信する機能である。

図１６は、本実施の形態に係るトラストストア監視装置３０１の構成例を示す図である。

トラストストア情報受信部３１１はトラストストア管理装置２０１からのトラストストア情報を受信する機能である。

処置判定部３１２は、受信したトラストストア情報の内容から、トラストストア４０２内の証明書などの削除、更新、或いは新たな証明書などのトラストストア４０２への追加のいずれか処置の要否を判定し、いずれかの処置が必要な場合に、必要な処置の実行をトラストストア管理装置２０１に命令する処置命令情報を生成する。

データベース３１３は、図２に示すデータベース１１３と同様であり、受入可能な証明書等（公開鍵検証情報）の条件などを示した許諾情報（受入可能条件情報）と受入を拒否する証明書等（公開鍵検証情報）の条件などを示した拒否情報（受入拒否条件情報）を格納する。許諾情報は、受入可能な証明書の条件などを示した受入可能証明書情報、受入可能な失効情報の条件などを示した受入可能失効情報、受入可能な検証パラメータの条件などを示した受入可能検証パラメータ情報である。拒否情報は、受入を拒否する証明書の条件などを示した受入拒否証明書情報、受入を拒否する失効情報の条件などを示した受入拒否失効情報、受入を拒否する検証パラメータの条件などを示した受入拒否検証パラメータ情報である。

送信命令生成部３１６は、トラストストア監視装置３０１のオペレータのマニュアル操作に基づき、送信命令情報を生成する。

命令送信部３１４はトラストストア管理装置２０１へ送信命令情報や処置命令情報を送信する機能である。

次に、図１７及び図１８のフローチャートを参照して、本実施の形態に係るトラストストア管理装置２０１及びトラストストア監視装置３０１の動作について説明する。

なお、図１７がトラストストア監視装置３０１の動作例を示し、図１８がトラストストア管理装置２０１の動作例を示す。

先ず、トラストストア監視装置３０１において、送信命令生成部３１６は、マニュアル操作により送信命令情報の生成指示があった場合に（Ｓ１７０１）、送信命令情報を生成し（Ｓ１７０２）、命令送信部３１４が、送信命令情報をトラストストア管理装置２０１へ送信する（Ｓ１７０３）。

次に、トラストストア管理装置２０１において、命令受信部２１３が、トラストストア監視装置３０１からの送信命令情報を受信すると（Ｓ１８０１）、送信命令情報をトラストストア管理部２１２へ渡す。

トラストストア管理部２１２では、トラストストアから現在の証明書格納状態を収集し、トラストストア情報を生成し（Ｓ１８０２）、トラストストア情報送信部２１１へ渡す。

トラストストア情報送信部２１１は、トラストストア情報をトラストストア監視装置３０１へ送信する（Ｓ１８０３）。

次に、トラストストア監視装置３０１において、トラストストア情報受信部３１１は、トラストストア管理装置２０１からトラストストア情報を受信し（Ｓ１７０４）、トラストストア情報を処置判定部３１２へ渡す。なお、トラストストア情報受信部３１１は、一定期間を経過してもトラストストア管理装置２０１からトラストストア情報を受信しない場合は、命令送信部３１４に再送を依頼し、命令送信部３１４は、送信命令情報を再送する（Ｓ１７０３）。

トラストストア情報を受取った処置判定部３１２は、証明書の受入を許諾する判断情報として、システムで受入可能な証明書の情報（受入可能証明書情報）、受入を拒否する証明書の情報（受入拒否証明書情報）とトラストストア管理装置２０１から送られてきたトラストストア情報を突きあわせ、削除、更新、追加のいずれかの処置の要否を判定し（Ｓ１７０５）、削除、更新、追加の少なくともいずれかの処置が必要と判断した場合に（Ｓ１７０６）、必要な処置を命令する処置命令情報を生成する（Ｓ１７０７）。生成された処置命令情報は命令送信部３１４へ渡される。

なお、処置判定部３１２が、処置の要否を判定する際に用いる受入可能証明書情報としては、例えば、ＣＡ／エンドユーザの証明書の実体、証明書内に含まれる各種情報（Issuer名、失効情報の取得先、エクステンション値など）、である。また、受入拒否証明書情報としては、ＣＡ／エンドユーザの証明書の実体、証明書内に含まれる各種情報（Issuer名、失効情報の取得先、エクステンション値など）、である。なお、受入可能証明書書情報と受入拒否証明書情報の両方を参照してもよいし、いずれか一方のみでもよい。

命令送信部３１４は、処置判定部３１２から受取った処置命令情報をトラストストア管理装置２０１へ送信する。

次に、トラストストア管理装置２０１において、命令受信部２１３は、トラストストア監視装置３０１からの処置命令情報を受信すると（Ｓ１８０４）、処置命令情報をトラストストア管理部２１２へ渡す。

トラストストア管理部２１２は、処置命令情報の内容に従い、証明書の削除、更新、追加を行う（Ｓ１８０５）。

以上のように、本実施の形態では、トラストストア管理装置とトラストストア監視装置を利用し、エンドユーザのトラストストアの状態を監視・管理することでシステムへの攻撃を軽減する。

そして、本実施の形態に係るトラストストア管理装置は、以下の機能を備える。

ネットワークからトラストストアを管理するための命令情報を受信する命令受信機能；
命令受信機能から受け取った命令情報に従って、格納されている証明書などを調査・収集したり、指定された証明書などを削除、更新、追加するトラストストア管理機能；
トラストストアの状態等、トラストストア管理機能の出力をトラストストア監視装置に通知するトラストストア情報送信機能。

また、本実施の形態に係るトラストストア監視装置は、以下の機能を備える。

マニュアル操作によりトラストストア情報の生成及び送信を命ずる送信命令情報を生成する送信命令生成機能；
トラストストア管理装置からのトラストストア情報を受信するトラストストア情報受信機能；
トラストストア監視装置に蓄積されている受入可能証明書情報及び受入拒否証明書情報から、トラストストア管理装置においてトラストストア内のどの証明書などを削除、更新、追加すべきか判定し、削除、更新、追加の処置命令情報を生成する状態判定機能；
送信命令情報及び処置命令情報をトラストストア管理装置へ送信する命令送信機能。

以上のように、本実施の形態によれば、システムの管理者はネットワーク経由でエンドユーザのトラストストアの状態を把握し、不必要な証明書をエンドユーザのトラストストアから削除、更新し、また新たな証明書を追加することが可能である。

実施の形態１３．
図１９は、本実施の形態の形態に係るトラストストア監視装置の構成例を示す図である。図１９では、タイマー部３１５が追加されている。他の要素は図１６と同じなので説明を省略する。

本実施の形態では、トラストストア監視装置３０１は、タイマー部３１５からのイベント（例えば毎日決まった時刻にタイマー部３１５が送信命令生成部３１６を起動する）により送信命令情報を生成し、トラストストア管理装置２０１へ送信する。従って、システム管理者のマニュアル操作を必要とせず自動的にトラストストア管理装置２０１へ送信命令情報を送信可能である。

また、受入可能証明書情報において受入可能な証明書が追加された場合、これをトリガとして、送信命令生成部３１６は送信命令情報を生成しトラストストア管理装置２０１へ送信しても良い。同様に、受入拒否証明書情報において受入を拒否する証明書が追加された場合、これをトリガとして、送信命令生成部３１６は送信命令情報を生成しトラストストア管理装置２０１へ送信しても良い。

また、受入可能証明書情報において受入可能な証明書が追加された場合、これをトリガとして、処置判定部３１２は同証明書の追加を命じる処置命令情報を生成しトラストストア管理装置２０１へ送信しても良い。同様に、受入拒否証明書情報において受入を拒否する証明書が追加された場合、これをトリガとして、処置判定部３１２は同証明書の削除を命じる処置命令情報を生成しトラストストア管理装置２０１へ送信しても良い。

このように、本実施の形態に係るトラストストア監視装置は、以下の機能を備える。

予め設定された時刻になると、送信命令生成機能に対してトラストストアの状態を調査する指示を出すタイマー機能；
タイマー機能からのトラストストアの状態調査の指示に従い、トラストストアの調査命令を生成する送信命令生成機能；
システムとして受入可能な許諾情報／受入不可能な拒否情報の追加／削除／更新があった場合、これをトリガとし、自立的に同変更をトラストストア管理装置で管理するトラストストアへ反映するための命令を生成し、トラストストア管理装置へ送信する処置判定機能。

そして、本実施の形態に係るトラストストア監視装置は、マニュアル操作によってトラストストア管理装置へトラストストアの状態を調査する命令を送信するだけでなく、タイマー機能やシステムとして受入可能な許諾情報／受入不可能な拒否情報に変更があった際に自立的に命令生成しトラストストア管理装置へ送信可能である。

実施の形態１４．
図２０は、本実施の形態の形態に係るトラストストア管理装置の構成例を示す図である。図２０では、タイマー部２１４が追加されている。他の要素は図１５と同じなので説明を省略する。

本実施の形態では、トラストストア管理装置２０１は、トラストストア監視装置３０１からの送信命令情報を待つだけではなく、タイマー部２１４からのイベントをトリガにトラストストアから現在の証明書格納状態を収集し、トラストストア情報を生成し、トラストストア情報送信部２１１へ渡す機能を有する（例えば毎日決まった時刻にタイマー部２１４がトラストストア管理部２１２を起動する）。

以上のように、トラストストア管理装置２０１は自立的にトラストストア監視装置３０１へトラストストア情報を通知可能なので、システムの管理者は自動的にトラストストア管理装置２０１が管理するトラストストアの状態を収集可能である。

また、トラストストアのユーザによる変更をトリガにトラストストア管理部２１２が起動されてもよい。つまり、トラストストアに格納されている証明書等に削除、更新、追加などの変更があった場合に、トラストストア管理部２１２はトラストストア情報を生成するようにしてもよい。

この場合はユーザがトラストストアから証明書を削除、追加した場合などがトリガになるためリアルタイムにトラストストア監視装置３０１へトラストストア情報が送信されることになる。

このように、本実施の形態に係るトラストストア管理装置は、以下の機能を備える。

予め設定された時刻になると、トラストストア管理機能に対してトラストストアの状態を調査する指示を出すタイマー機能；
タイマー機能からのトラストストアの状態調査の指示に従い、トラストストアの調査を行なうトラストストア管理機能；
トラストストアにおける情報の追加、削除、更新が発生した場合に自立的にトラストストアの調査を行うトラストストア管理機能。

そして、本実施の形態に係るトラストストア管理装置は、トラストストア監視装置からの命令を受信することによりトラストストアの状態報告を行うだけでなく、タイマー機能やトラストストアの変更をトリガに自立的にトラストストア監視装置へ状態報告を行う。

実施の形態１５．
本実施の形態では、トラストストア監視装置３０１の処置判定部３１２は、トラストストア監視装置のオペレータ（システム管理者）からのマニュアル指定により特定の証明書の削除、更新、追加を命令する処置命令情報を生成しトラストストア管理装置２０１へ送信可能である。

このことにより、例えば緊急で特定の証明書の受入を拒否すべき事態になった場合は、トラストストア情報を収集する過程を経なくとも、該証明書の削除命令をトラストストア管理装置２０１へ送信可能である。

実施の形態１６．
本実施の形態では、トラストストアにおける管理対象を、CRLやOCSPレスポンスなどの失効情報に拡張し、発明が解決しようとする課題における（２）失効情報の管理の課題に示した課題のうち、キャッシングしている失効情報の信頼性に関する課題を解決するためのものである。

本実施の形態に係るトラストストア管理装置２０１は図１５又は図２０に示す構成により実現可能であり、トラストストア監視装置３０１は図１６又は図１９に示す構成により実現可能である。

一度検証を済ませた失効情報は証明書の検証に使用され、次回の使用に備えてユーザ端末上にキャッシングされる実装がある。

本実施の形態では、失効情報のキャッシング先をトラストストアとする。トラストストア管理装置２０１は、キャッシングしている失効情報についてもトラストストア情報としてトラストストア監視装置３０１へ報告する。トラストストア監視装置３０１では、失効情報の受入を許諾する判断情報として、システムで受入可能な失効情報の情報（受入可能失効情報）、受入を拒否する失効情報の情報（受入拒否失効情報）に対して、処置判定部３１２は、トラストストア管理装置２０１から送られてきたキャッシングしている失効情報の情報を含むトラストストア情報を突きあわせ、削除、更新、追加すべき失効情報を判定し、失効情報の削除、更新、追加を命令する処置命令情報を生成する。生成された処置命令情報は命令送信部３１４へ渡される。

一方、トラストストア管理装置２０１では、受信した処置命令情報に従いトラストストア管理部２１２が失効情報の削除、更新、追加を処理する。

本実施の形態により、システム管理者はエンドユーザの失効情報のキャッシュ状態を、ネットワーク経由で監視しシステム管理者の管理方針に基づいた、削除、更新、追加などの管理が可能である。

なお、受入可能失効情報、受入拒否失効情報の具体例については、実施の形態１〜１１で記述された同情報と同じとする。

また、実施の形態１２〜１５におけるトラストストア管理装置２０１、トラストストア監視装置３０１内の各機能の動作は、証明書を失効情報に読み替えることで、失効情報についても適用可能である。

実施の形態１７．
本実施の形態では、トラストストアにおける管理対象を、証明書の検証に関わるパラメータに拡張し、発明が解決しようとする課題における（３）証明書の検証に使用するパラメータの管理の課題を解決するためのものである。

本実施の形態に係るトラストストア管理装置２０１は図１５又は図２０に示す構成により実現可能であり、トラストストア監視装置３０１は図１６又は図１９に示す構成により実現可能である。

本実施の形態では、トラストストアにおける管理対象を、証明書の検証に関わるパラメータに拡張する。例えば、証明書を検証する場合に、検証パラメータとしてRFC3280などで定義されている最大パス長、受入可能なCertificatePolicyのID群などが該当する。これらのパラメータは“信用できる情報”として使用されなくてはならない。従って、システム管理者はこれらのパラメータが正しく使用されているか否かについての監視・管理が必要となる場合がある。該パラメータ群を管理するストアにおいて、ユーザの権限で追加、変更、削除などが実行可能であれば、誤ったパラメータを該ストアに保存した場合に正しい検証が行われずセキュリティホールになりうる。

トラストストア管理装置２０１は、格納している検証パラメータについてもトラストストア情報としてトラストストア監視装置３０１へ報告する。トラストストア監視装置３０１では、検証パラメータの受入を許諾する判断情報として、システムで受入可能な検証パラメータの情報（受入可能検証パラメータ）、受入を拒否する検証パラメータの情報（受入拒否検証パラメータ）に対して、処置判定部３１２は、トラストストア管理装置２０１から送られてきた検証パラメータの情報を含むトラストストア情報を突きあわせ、削除、更新、追加すべき検証パラメータを判定し、検証パラメータの削除、更新、追加を命令する処置命令情報を生成する。生成された処置命令情報は命令送信部３１４へ渡される。

一方、トラストストア管理装置２０１では、受信した処置命令情報に従いトラストストア管理部２１２が検証パラメータの削除、更新、追加を処理する。

本実施の形態により、システム管理者はエンドユーザの検証パラメータの利用状況を、ネットワーク経由で監視しシステム管理者の管理方針に基づいた、削除、更新、追加などの管理が可能である。

実施の形態１８．
実施の形態１２〜１７において、トラストストア監視装置３０１の処置判定部３１２は、トラストストアの処置命令情報（削除、更新、追加）を生成する際に、その処置の根拠、理由を示す情報（処置理由情報）、例えば、証明書の削除であればＣＡ証明書に不備が見つかったことが判明したことを文書化したもの等が存在すれば、このような情報を付加情報として処置命令情報に付加する。

処置理由情報が付加された処置命令情報を受信したトラストストア管理装置２０１では、処置理由情報を保管するとともに、自動、又は手動で処置理由情報をディスプレイ等の表示部に表示することでエンドユーザにトラストストアにおける変更とその理由を通知することが可能となる。

このように、本実施の形態に係るトラストストア監視装置は、証明書等の削除、更新、追加命令を生成し、トラストストア管理装置に送信する際に、命令を生成した理由を示した付加情報を追加して送付可能であり、本実施の形態に係るトラストストア管理装置は、トラストストア監視装置からのトラストストアにおける証明書等の削除、更新、追加の命令を受信した場合に、付加情報が添付されていた場合、該情報を蓄積し、手動、又は自動で該情報を表示可能である。

実施の形態１９．
本実施の形態では、エンドユーザ自身がトラストストアに証明書を追加、更新、削除した場合において、トラストストア管理装置２０１のトラストストア管理部２１２は、その操作を行った理由となる情報（変更理由情報）を証明書とともにトラストストアに格納する。

例えば、証明書の追加であれば、システム管理者或いは通信相手による追加指示のメールや電子的なドキュメント、閲覧したＷｅｂサイトにおける追加の指示（ＵＲＬ）である。これらの情報が無い場合は、エンドユーザ自身が理由を記した電子的なドキュメントでも良い。当実施の形態は、これらの情報を指定するＧＵＩを実装することにより実現する。

そして、トラストストア管理部２１２は、トラストストア情報を生成する際にトラストストアに格納された変更理由情報を抽出し、トラストストア情報に変更理由情報を付加する。そして、トラストストア情報送信部２１１は、変更理由情報が付加されたトラストストア情報をトラストストア監視装置３０１に対して送信する。

このように、本実施の形態に係るトラストストア管理装置は、マニュアル操作で証明書等を変更した場合、その理由を記録する機能（例：ＧＵＩからのキーボード入力を記録する、マニュアル操作を指示したメールなどを記録するなど）を備え、トラストストア監視装置に対してトラストストアの状態を通知する場合において、該理由も併せて通知可能である。

以上のように、本実施の形態によれば、システム管理者はエンドユーザがどのようにトラストストアを管理しているのかその理由まで把握することが可能である。

実施の形態２０．
本実施の形態は、トラストストア監視装置３０１に、レポート情報生成通知部を追加することにより、トラストストアの状況を示すレポート情報を生成し、生成したレポート情報をネットワーク内のユーザの端末１０２等に対して通知する。

本実施の形態１２〜１９において、トラストストア監視装置３０１では、エンドユーザのトラストストア情報が蓄積される。

本実施の形態では、これらのデータからシステム全体におけるトラストストアの状況を定期的にレポート化する。例えば、週１回ＨＴＭＬコンテンツでレポートを作成してシステム内イントラネットに公表することで、システム内エンドユーザへの安全性情報として提示することが可能であり、エンドユーザへのフィードバックがかけられる。

このように、本実施の形態におけるトラストストア監視装置は、トラストストア管理装置から報告された証明書等の内容を蓄積し、予め定められたフォーマットにレポート化する機能（例：ＨＴＭＬコンテンツ）を有する。

前述した各実施の形態で、証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１は、コンピュータで実現できるものである。

図示していないが、証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。

例えば、ＣＰＵは、バスを介して、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、通信ボード、表示装置、Ｋ／Ｂ（キーボード）、マウス、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、ＣＤＤ（コンパクトディスクドライブ）、磁気ディスク装置、光ディスク装置、プリンタ装置、スキャナ装置等と接続可能である。

ＲＡＭは、揮発性メモリの一例である。ＲＯＭ、ＦＤＤ、ＣＤＤ、磁気ディスク装置、光ディスク装置は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。

前述した各実施の形態の証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１が扱うデータや情報は、記憶装置あるいは記憶部に保存され、証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１の各部により、記録され読み出されるものである。

また、通信ボードは、例えば、ＬＡＮ、インターネット、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されている。

磁気ディスク装置には、オペレーティングシステム（ＯＳ）、ウィンドウシステム、プログラム群、ファイル群（データベース）が記憶されている。

プログラム群は、ＣＰＵ、ＯＳ、ウィンドウシステムにより実行される。

上記証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１の各部は、一部或いはすべてコンピュータで動作可能なプログラムにより構成しても構わない。或いは、ＲＯＭに記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実施されても構わない。

上記プログラム群には、実施の形態の説明において「〜部」として説明した処理をＣＰＵに実行させるプログラムが記憶される。これらのプログラムは、例えば、Ｃ言語やＨＴＭＬやＳＧＭＬやＸＭＬなどのコンピュータ言語により作成される。

また、上記プログラムは、磁気ディスク装置、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）、光ディスク、ＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のその他の記録媒体に記憶され、ＣＰＵにより読み出され実行される。

実施の形態１〜１１に係る証明書検証装置を含むシステム全体の構成例を示す図。 実施の形態１に係る証明書検証装置の構成例を示す図。 実施の形態１に係る証明書検証装置の警告メッセージの例を示す図。 実施の形態１に係る証明書検証装置の動作例を示すフローチャート図。 実施の形態２に係る証明書検証装置の構成例を示す図。 実施の形態４に係る証明書検証装置の構成例を示す図。 実施の形態４に係る証明書検証装置の警告メッセージの例を示す図。 実施の形態４に係る証明書検証装置の動作例を示すフローチャート図。 実施の形態８に係る証明書検証装置の構成例を示す図。 実施の形態８に係る証明書検証装置の警告メールの例を示す図。 実施の形態８に係る証明書検証装置の警告メールへのリプライの例を示す図。 実施の形態７に係る証明書検証装置におけるリプライに示された取扱態様に対する対策処置の例を示す図。 実施の形態９に係る証明書検証装置の構成例を示す図。 実施の形態１２〜２０に係るトラストストア管理装置及びトラストストア監視装置を含むシステム全体の構成例を示す図。 実施の形態１２に係るトラストストア管理装置の構成例を示す図。 実施の形態１２に係るトラストストア監視装置の構成例を示す図。 実施の形態１２に係るトラストストア監視装置の動作例を示すフローチャート図。 実施の形態１２に係るトラストストア管理装置の動作例を示すフローチャート図。 実施の形態１３に係るトラストストア監視装置の構成例を示す図。 実施の形態１４に係るトラストストア管理装置の構成例を示す図。

符号の説明

１０１ 証明書検証装置、１０２ ユーザの端末、１０３ トラストストア、１０４ システム管理者の端末、１０５ 証明書発信機器、１０６ ＣＡ、１１１ データ受信部、１１２ データ解析部、１１３ データベース、１１４ エラー処理部、１１４ａ 警告部、１１４ｂ 強制処理部、１１４ｃ 受信データ蓄積部、１１４ｄ 蓄積データ解析部、１１６ コンテンツ解析部、１１７ ペンディング情報蓄積部、１２１ 証明書抽出部、１２２ 証明書受入判定部、１２３ 証明書パス構築部、１２４ 証明書パス検証部、１２５ 失効状態検査部、１２６ 情報書込み部、１３１ 失効情報抽出部、１３２ 失効情報受入判定部、２０１ トラストストア管理装置、２１１ トラストストア情報送信部、２１２ トラストストア管理部、２１３ 命令受信部、２１４ タイマー部、３０１ トラストストア監視装置、３１１ トラストストア情報受信部、３１２ 処置判定部、３１３ データベース、３１４ 命令送信部、３１５ タイマー部、３１６ 送信命令生成部、４０１ ユーザの端末、４０２ トラストストア、５０１ システム管理者の端末、６０１ ＣＡ。

Claims (32)

1. 一つ以上の端末が含まれる所定のネットワーク上で流通するデータの複製を受信データとして受信するデータ受信部と、
   前記データ受信部により受信された受信データ内に公開鍵の有効性を検証するために用いられる公開鍵証明書が含まれているか否かを解析し、受信データ内に公開鍵証明書が含まれている場合に、受信データから公開鍵証明書を抽出する解析抽出部と、
   前記解析抽出部により抽出された公開鍵証明書に対する検証を行い、公開鍵証明書の受入可否を判定する受入可否判定部と、
   前記受入可否判定部により公開鍵証明書の受入が拒否された場合に、受入が拒否された拒否公開鍵証明書の送信元と拒否公開鍵証明書の受信先とを特定し、拒否公開鍵証明書の送信元と拒否公開鍵証明書の受信先との間で通信されるデータの監視を行い、拒否公開鍵証明書の受信先において拒否公開鍵証明書の受入が行われたか否かを判定し、拒否公開鍵証明書の受信先において拒否公開鍵証明書の受入が行われた場合に、拒否公開鍵証明書の受信先による拒否公開鍵証明書の利用を抑止する対策処置を行う対策処置実行部とを有することを特徴とする検証装置。
2. 前記対策処置実行部は、
   拒否公開鍵証明書の受信先において拒否公開鍵証明書の受入が行われた場合に、拒否公開鍵証明書の受入に要した時間を解析し、解析結果に基づき、当該拒否公開鍵証明書の受入が一時的な受入なのか、拒否公開鍵証明書の受信先が拒否公開鍵証明書の検証用の情報を保有している状態での受入なのかを判定し、拒否公開鍵証明書の受入状況に応じた対策処置を行うことを特徴とする請求項１に記載の検証装置。
3. 前記検証装置は、更に、
   受入可能な公開鍵証明書の条件を示した受入可能条件情報と、受入を拒否する公開鍵証明書の条件を示した受入拒否条件情報とを格納する条件情報格納部を有し、
   前記受入可否判定部は、
   前記条件情報格納部に格納された受入可能条件情報と受入拒否条件情報とに基づいて、前記解析抽出部により抽出された公開鍵証明書に対する検証を行うことを特徴とする請求項１に記載の検証装置。
4. 前記検証装置は、更に、
   前記受入可否判定部により受入可能と判定された公開鍵証明書を用いて証明書パスの構築を試行し、受入可能と判断された公開鍵証明書を用いて証明書パスの構築ができなかった場合に、当該受入可能と判断された公開鍵証明書を受入を拒否する拒否公開鍵証明書と判定する証明書パス構築部を有し、
   前記対策処置実行部は、
   前記証明書パス構築部により判定された拒否公開鍵証明書の前記所定のネットワーク内の端末における利用を抑止する対策処置を行うことを特徴とする請求項１に記載の検証装置。
5. 前記検証装置は、更に、
   前記証明書パス構築部により構築された証明書パスの検証を行い、前記証明書パス構築部により構築された証明書パスを正当と判断しなかった場合に、正当と判断されなかった証明書パスの構築に用いられた公開鍵証明書を受入を拒否する拒否公開鍵証明書と判定する証明書パス検証部を有し、
   前記対策処置実行部は、
   前記証明書パス検証部により判定された拒否公開鍵証明書の前記所定のネットワーク内の端末における利用を抑止する対策処置を行うことを特徴とする請求項４に記載の検証装置。
6. 前記対策処置実行部は、
   拒否公開鍵証明書の受信先に対して拒否公開鍵証明書の利用を警告する警告情報を生成し、生成した警告情報を拒否公開鍵証明書の受信先に対して送信することを特徴とする請求項１に記載の検証装置。
7. 前記対策処置実行部は、
   拒否公開鍵証明書の送信元と拒否公開鍵証明書の受信先との通信を切断することを特徴とする請求項１に記載の検証装置。
8. 前記検証装置は、更に、
   受入可能な公開鍵証明書の条件を示した受入可能条件情報と、受入を拒否する公開鍵証明書の条件を示した受入拒否条件情報とを格納する条件情報格納部と、
   いずれかの公開鍵証明書が受入可能と判定された場合に、受入可能と判定された公開鍵証明書の内容を受入可能条件情報に書込み、いずれかの公開鍵証明書が拒否公開鍵証明書と判定された場合に、拒否公開鍵証明書の内容を受入拒否条件情報に書込む情報書込み部とを有することを特徴とする請求項１に記載の検証装置。
9. 前記検証装置は、更に、
   検証装置のオペレータから、前記所定のネットワーク内の端末間でローカルに送受信されるローカル公開鍵証明書の内容を入力するオペレータ入力部を有し、
   前記情報書込み部は、
   前記オペレータ入力部より入力されたローカル公開鍵証明書の内容を受入可能条件情報に書込み、
   前記受入可否判定部は、
   前記解析抽出部によりローカル公開鍵証明書が抽出された場合に、当該ローカル公開鍵証明書の内容が受入可能条件情報に含まれているか否かを検証し、当該ローカル公開鍵証明書の内容が受入可能条件情報に含まれている場合に、当該ローカル公開鍵証明書を受入可能と判定することを特徴とする請求項８に記載の検証装置。
10. 前記検証装置は、更に、
    前記対策処置実行部から拒否公開鍵証明書の受信先に対して警告情報が送信された場合に、拒否公開鍵証明書が拒否公開鍵証明書の受信先においてどのように取扱われたかを示すリプライ情報を拒否公開鍵証明書の受信先から受信するリプライ情報受信部と、
    前記リプライ情報受信部により受信されたリプライ情報に示された拒否公開鍵証明書の取扱態様を解析し、拒否公開鍵証明書の取扱態様に応じた対策処置を指定する取扱態様解析部とを有し、
    前記対策処置実行部は、
    前記取扱態様解析部により指定された対策処置を行うことを特徴とする請求項６に記載の検証装置。
11. 前記対策処置実行部は、
    拒否公開鍵証明書の受信先から拒否公開鍵証明書の送信元に対してデータが送信された場合に、拒否公開鍵証明書の受信先による拒否公開鍵証明書の利用を抑止する対策処置を行うことを特徴とする請求項１に記載の検証装置。
12. 前記対策処置実行部は、
    拒否公開鍵証明書が含まれていた受信データを解析し、当該受信データに拒否公開鍵証明書の送信元以外の通信アドレスが含まれていた場合に、拒否公開鍵証明書の受信先から前記通信アドレスを宛先とするデータが送信された場合に、拒否公開鍵証明書の受信先による拒否公開鍵証明書の利用を抑止する対策処置を行うことを特徴とする請求項１に記載の検証装置。
13. 一つ以上の端末が含まれる所定のネットワーク上で流通するデータの複製を受信データとして受信するデータ受信部と、
    前記データ受信部により受信された受信データ内に公開鍵証明書の有効性を検証する際に用いられる失効情報が含まれているか否かを解析し、受信データ内に失効情報が含まれている場合に、受信データから失効情報を抽出する解析抽出部と、
    前記解析抽出部により抽出された失効情報に対する検証を行い、失効情報の受入可否を判定する受入可否判定部と、
    前記受入可否判定部により失効情報の受入が拒否された場合に、受入が拒否された拒否失効情報の前記所定のネットワーク内の端末における利用を抑止する対策処置を行う対策処置実行部とを有することを特徴とする検証装置。
14. 前記対策処置実行部は、
    いずれかの失効情報が拒否失効情報と判定された場合に、拒否失効情報の受信先を特定し、拒否失効情報の受信先に対して拒否失効情報の利用を警告する警告情報を生成し、生成した警告情報を拒否失効情報の受信先に対して送信することを特徴とする請求項１３に記載の検証装置。
15. 前記対策処置実行部は、
    いずれかの失効情報が拒否失効情報と判定された場合に、拒否失効情報の送信元と拒否失効情報の受信先とを特定し、拒否失効情報の送信元と拒否失効情報の受信先との通信を切断することを特徴とする請求項１３に記載の検証装置。
16. 前記検証装置は、更に、
    受入可能な失効情報の条件を示した受入可能条件情報と、受入を拒否する失効情報の条件を示した受入拒否条件情報とを格納する条件情報格納部と、
    いずれかの失効情報が受入可能と判定された場合に、受入可能と判定された失効情報の内容を受入可能条件情報に書込み、いずれかの失効情報が拒否失効情報と判定された場合に、拒否失効情報の内容を受入拒否条件情報に書込む情報書込み部とを有することを特徴とする請求項１３に記載の検証装置。
17. 公開鍵の有効性を検証するために用いられる公開鍵検証情報が格納されたトラストストア内の公開鍵検証情報の格納状況を調査し、トラストストア内に格納されている公開鍵検証情報を通知するトラストストア情報を生成するトラストストア管理部と、
    前記トラストストア管理部により生成されたトラストストア情報を送信するトラストストア情報送信部と、
    前記トラストストア情報送信部により送信されたトラストストア情報に対する応答として送信された処置命令情報を受信する命令受信部とを有するトラストストア管理装置と、
    前記トラストストア管理装置からトラストストア情報を受信するトラストストア情報受信部と、
    前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成する処置判定部と、
    前記処置判定部により生成された処置命令情報を前記トラストストア管理装置に送信する命令送信部とを有するトラストストア監視装置を有し、
    前記トラストストア管理装置において、
    前記命令受信部は、
    前記トラストストア監視装置から送信された処置命令情報を受信し、
    前記トラストストア管理部は、
    前記命令受信部により受信された処置命令情報に従い、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置を行うことを特徴とする通信システム。
18. 前記トラストストア監視装置は、更に、
    前記トラストストア管理装置に対してトラストストア情報の送信を命ずる送信命令情報を生成する送信命令生成部を有し、
    前記命令送信部は、
    前記送信命令生成部により生成された送信命令情報を前記トラストストア管理装置に対して送信し、
    前記トラストストア管理装置において、
    前記命令受信部は、
    前記トラストストア監視装置から送信された送信命令情報を受信し、
    前記トラストストア管理部は、
    前記命令受信部により受信された送信命令情報に従って、トラストストア情報を生成することを特徴とする請求項１７に記載の通信システム。
19. 前記トラストストア監視装置は、更に、
    タイマー通知を行うタイマー部を有し、
    前記送信命令生成部は、
    前記タイマー部からのタイマー通知に基づいて、送信命令情報を生成することを特徴とする請求項１７に記載の通信システム。
20. 前記トラストストア監視装置は、更に、
    トラストストアへの受入が可能な公開鍵検証情報の条件を示した受入可能条件情報と、トラストストアへの受入を拒否する公開鍵検証情報の条件を示した受入拒否条件情報とを格納する条件情報格納部を有し、
    前記処置判定部は、
    前記トラストストア情報受信部により受信されたトラストストア情報と、前記条件情報格納部に格納されている受入可能条件情報及び受入拒否条件情報の少なくともいずれかとを照合して、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定することを特徴とする請求項１７に記載の通信システム。
21. 前記処置判定部は、
    前記条件情報格納部に格納された受入可能条件情報及び受入拒否条件情報の少なくともいずれかにおいて変更が生じた場合に、当該変更に従った処置を前記トラストストア管理装置に命ずる処置命令情報を生成することを特徴とする請求項２０に記載の通信システム。
22. 前記トラストストア管理装置は、更に、
    タイマー通知を行うタイマー部を有し、
    前記トラストストア管理部は、
    前記タイマー部からのタイマー通知に基づいて、トラストストア情報を生成することを特徴とする請求項１７に記載の通信システム。
23. 前記トラストストア管理装置において、
    前記トラストストア管理部は、
    トラストストア内に格納されている公開鍵検証情報に変更が生じた場合に、トラストストア情報を生成することを特徴とする請求項１７に記載の通信システム。
24. 前記トラストストア監視装置において、
    前記処置判定部は、
    所定の場合に、トラストストア監視装置のオペレータからの指示に基づき、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置を命ずる処置命令情報を生成することを特徴とする請求項１７に記載の通信システム。
25. 前記トラストストア監視装置において、
    前記処置判定部は、
    処置命令情報で命ずる処置の理由が示された処置理由情報が存在する場合に、処置命令情報に処置理由情報を付加し、
    前記命令送信部は、
    処置理由情報が付加された処置命令情報を前記トラストストア管理装置に対して送信し、
    前記トラストストア管理装置は、更に、
    処置命令情報に付加された処置理由情報に示された処置の理由を表示する表示部とを有することを特徴とする請求項１７に記載の通信システム。
26. 前記トラストストア管理装置において、
    前記トラストストア管理部は、
    トラストストア内に格納されている公開鍵検証情報に変更が生じた場合に、変更の理由を示す変更理由情報を生成し、生成した変更理由情報をトラストストアに格納させ、トラストストア情報を生成する際にトラストストアに格納された変更理由情報を抽出し、トラストストア情報に変更理由情報を付加し、
    前記トラストストア情報送信部は、
    変更理由情報が付加されたトラストストア情報を前記トラストストア監視装置に対して送信することを特徴とする請求項１７に記載の通信システム。
27. 前記トラストストア監視装置は、更に、
    受入可能条件情報の内容及び受入拒否条件情報の内容を示すレポート情報を生成し、生成したレポート情報を所定のネットワーク内の端末に対して通知するレポート情報生成通知部とを有することを特徴とする請求項２０に記載の通信システム。
28. 前記トラストストア管理装置において、
    トラストストア管理部は、
    トラストストア内の公開鍵検証情報の格納状況として公開鍵証明書の格納状況を調査し、トラストストア内に格納されている公開鍵証明書を通知するトラストストア情報を生成し、
    前記トラストストア監視装置において
    前記処置判定部は、
    前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の公開鍵証明書の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成し、
    前記トラストストア管理装置において、
    前記トラストストア管理部は、
    処置命令情報に従い、トラストストア内の公開鍵証明書の削除、更新、及びトラストストアへの公開鍵証明書の追加の少なくともいずれかの処置の行うことを特徴とする請求項１７に記載の通信システム。
29. 前記トラストストア管理装置において、
    トラストストア管理部は、
    トラストストア内の公開鍵検証情報の格納状況として公開鍵証明書の失効情報の格納状況を調査し、トラストストア内に格納されている失効情報を通知するトラストストア情報を生成し、
    前記トラストストア監視装置において
    前記処置判定部は、
    前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の失効情報の削除、更新、及びトラストストアへの失効情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成し、
    前記トラストストア管理装置において、
    前記トラストストア管理部は、
    処置命令情報に従い、トラストストア内の失効情報の削除、更新、及びトラストストアへの失効情報の追加の少なくともいずれかの処置の行うことを特徴とする請求項１７に記載の通信システム。
30. 前記トラストストア管理装置において、
    トラストストア管理部は、
    トラストストア内の公開鍵検証情報の格納状況として公開鍵証明書を検証するための検証パラメータの格納状況を調査し、トラストストア内に格納されている検証パラメータを通知するトラストストア情報を生成し、
    前記トラストストア監視装置において
    前記処置判定部は、
    前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の検証パラメータの削除、更新、及びトラストストアへの検証パラメータの追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成し、
    前記トラストストア管理装置において、
    前記トラストストア管理部は、
    処置命令情報に従い、トラストストア内の検証パラメータの削除、更新、及びトラストストアへの検証パラメータの追加の少なくともいずれかの処置の行うことを特徴とする請求項１７に記載の通信システム。
31. 所定のトラストストア監視装置に接続され、
    公開鍵の有効性を検証するために用いられる公開鍵検証情報が格納されたトラストストア内の公開鍵検証情報の格納状況を調査し、トラストストア内に格納されている公開鍵検証情報を通知するトラストストア情報を生成するトラストストア管理部と、
    前記トラストストア管理部により生成されたトラストストア情報を前記トラストストア監視装置に送信するトラストストア情報送信部と、
    前記トラストストア情報送信部により送信されたトラストストア情報に対する応答として前記トラスト監視装置から送信された、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置を命ずる処置命令情報を受信する命令受信部とを有し、
    前記トラストストア管理部は、
    前記命令受信部により受信された処置命令情報に従い、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置を行うことを特徴とするトラストストア管理装置。
32. 公開鍵の有効性を検証するために用いられる公開鍵検証情報が格納されたトラストストア内の公開鍵検証情報の格納状況を調査し、トラストストア内に格納されている公開鍵検証情報を通知するトラストストア情報を生成し、送信するトラストストア管理装置と接続され、
    前記トラストストア管理装置からトラストストア情報を受信するトラストストア情報受信部と、
    前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成する処置判定部と、
    前記処置判定部により生成された処置命令情報を前記トラストストア管理装置に送信して、前記トラストストア管理装置にトラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置を行わせる命令送信部とを有することを特徴とするトラストストア監視装置。

Images