(57)【要約】【課題】  公開鍵証明書の検証を一元的に行うことで公開鍵証明書の検証の信頼性を向上させる。【解決手段】  証明書検証装置１０１は、ユーザの端末１０２へのデータを受信（傍受）し、受信したデータに公開鍵証明書や失効情報が含まれていた場合に、当該公開鍵証明書や失効情報の検証を行い、当該公開鍵証明書や失効情報の受入が可能か否かを判断し、当該公開鍵証明書や失効情報の受入が不可能である場合に、ユーザの端末１０２に対して当該公開鍵証明書や失効情報の利用に対する警告メッセージを送信したり、ユーザの端末１０２と証明書発信機器１０５との間の通信を強制的に切断する等の対策処置を行う。【選択図】        図１
2006270504.tif 000002
【特許請求の範囲】
【請求項１】
一つ以上の端末が含まれる所定のネットワーク上で流通するデータを受信するデータ受信部と、
前記データ受信部により受信された受信データ内に公開鍵の有効性を検証するために用いられる公開鍵検証情報が含まれているか否かを解析し、受信データ内に公開鍵検証情報が含まれている場合に、受信データから公開鍵検証情報を抽出する解析抽出部と、
前記解析抽出部により抽出された公開鍵検証情報に対する検証を行い、公開鍵検証情報の受入可否を判定する受入可否判定部と、
前記受入可否判定部により公開鍵検証情報の受入が拒否された場合に、受入が拒否された拒否公開鍵検証情報の前記所定のネットワーク内の端末における利用を抑止する対策処置を行う対策処置実行部とを有することを特徴とする検証装置。
【請求項２】
前記解析抽出部は、
受信データ内に公開鍵検証情報が含まれていると判断したにも関わらず公開鍵検証情報が抽出できなかった場合に、抽出できなかった公開鍵検証情報を受入を拒否する拒否公開鍵検証情報と判定し、
前記対策処置実行部は、
前記解析抽出部により判定された拒否公開鍵検証情報の前記所定のネットワーク内の端末における利用を抑止する対策処置を行うことを特徴とする請求項１に記載の検証装置。
【請求項３】
前記検証装置は、更に、
受入可能な公開鍵検証情報の条件を示した受入可能条件情報と、受入を拒否する公開鍵検証情報の条件を示した受入拒否条件情報とを格納する条件情報格納部を有し、
前記受入可否判定部は、
前記条件情報格納部に格納された受入可能条件情報と受入拒否条件情報とに基づいて、前記解析抽出部により抽出された公開鍵検証情報に対する検証を行うことを特徴とする請求項１に記載の検証装置。
【請求項４】
前記解析抽出部は、
公開鍵検証情報として公開鍵証明書が受信データに含まれているか否かを解析し、受信データ内に公開鍵証明書が含まれている場合に、受信データから公開鍵証明書を抽出し、
前記受入可否判定部は、
前記解析抽出部により抽出された公開鍵証明書に対する検証を行い、公開鍵証明書の受入可否を判定することを特徴とする請求項１に記載の検証装置。
【請求項５】
前記検証装置は、更に、
前記受入可否判定部により受入可能と判定された公開鍵証明書を用いて証明書パスの構築を試行し、受入可能と判断された公開鍵証明書を用いて証明書パスの構築ができなかった場合に、当該受入可能と判断された公開鍵証明書を受入を拒否する拒否公開鍵検証情報と判定する証明書パス構築部を有し、
前記対策処置実行部は、
前記証明書パス構築部により判定された拒否公開鍵検証情報の前記所定のネットワーク内の端末における利用を抑止する対策処置を行うことを特徴とする請求項４に記載の検証装置。
【請求項６】
前記検証装置は、更に、
前記証明書パス構築部により構築された証明書パスの検証を行い、前記証明書パス構築部により構築された証明書パスを正当と判断しなかった場合に、正当と判断されなかった証明書パスの構築に用いられた公開鍵証明書を受入を拒否する拒否公開鍵検証情報と判定する証明書パス検証部を有し、
前記対策処置実行部は、
前記証明書パス検証部により判定された拒否公開鍵検証情報の前記所定のネットワーク内の端末における利用を抑止する対策処置を行うことを特徴とする請求項５に記載の検証装置。
【請求項７】
前記解析抽出部は、
公開鍵検証情報として公開鍵証明書の失効情報が受信データに含まれているか否かを解析し、受信データ内に失効情報が含まれている場合に、受信データから失効情報を抽出し、
前記受入可否判定部は、
前記解析抽出部により抽出された失効情報に対する検証を行い、失効情報の受入可否を判定することを特徴とする請求項１に記載の検証装置。
【請求項８】
前記対策処置実行部は、
いずれかの公開鍵検証情報が拒否公開鍵検証情報と判定された場合に、拒否公開鍵検証情報の受信先を特定し、拒否公開鍵検証情報の受信先に対して拒否公開鍵検証情報の利用を警告する警告情報を生成し、生成した警告情報を拒否公開鍵検証情報の受信先に対して送信することを特徴とする請求項１、２、５及び６のいずれかに記載の検証装置。
【請求項９】
前記対策処置実行部は、
いずれかの公開鍵検証情報が拒否公開鍵検証情報と判定された場合に、拒否公開鍵検証情報の送信元と拒否公開鍵検証情報の受信先とを特定し、拒否公開鍵検証情報の送信元と拒否公開鍵検証情報の受信先との通信を切断することを特徴とする請求項１、２、５及び６のいずれかに記載の検証装置。
【請求項１０】
前記検証装置は、更に、
受入可能な公開鍵検証情報の条件を示した受入可能条件情報と、受入を拒否する公開鍵検証情報の条件を示した受入拒否条件情報とを格納する条件情報格納部と、
いずれかの公開鍵検証情報が受入可能と判定された場合に、受入可能と判定された公開鍵検証情報の内容を受入可能条件情報に書込み、いずれかの公開鍵検証情報が拒否公開鍵検証情報と判定された場合に、拒否公開鍵検証情報の内容を受入拒否条件情報に書込む情報書込み部とを有することを特徴とする請求項１、２、５及び６のいずれかに記載の検証装置。
【請求項１１】
前記検証装置は、更に、
検証装置のオペレータから、前記所定のネットワーク内の端末間でローカルに送受信されるローカル公開鍵検証情報の内容を入力するオペレータ入力部を有し、
前記情報書込み部は、
前記オペレータ入力部より入力されたローカル公開鍵検証情報の内容を受入可能条件情報に書込み、
前記受入可否判定部は、
前記解析抽出部によりローカル公開鍵検証情報が抽出された場合に、当該ローカル公開鍵検証情報の内容が受入可能条件情報に含まれているか否かを検証し、当該ローカル公開鍵検証情報の内容が受入可能条件情報に含まれている場合に、当該ローカル公開鍵検証情報を受入可能と判定することを特徴とする請求項１０に記載の検証装置。
【請求項１２】
前記検証装置は、
前記所定のネットワーク内外の通信を中継するネットワーク機器であることを特徴とする請求項１の検証装置。
【請求項１３】
前記検証装置は、更に、
前記対策処置実行部から拒否公開鍵検証情報の受信先に対して警告情報が送信された場合に、拒否公開鍵検証情報が拒否公開鍵検証情報の受信先においてどのように取扱われたかを示すリプライ情報を拒否公開鍵検証情報の受信先から受信するリプライ情報受信部と、
前記リプライ情報受信部により受信されたリプライ情報に示された拒否公開鍵検証情報の取扱態様を解析し、拒否公開鍵検証情報の取扱態様に応じた対策処置を指定する取扱態様解析部とを有し、
前記対策処置実行部は、
前記取扱態様解析部により指定された対策処置を行うことを特徴とする請求項８に記載の検証装置。
【請求項１４】
前記対策処置実行部は、
いずれかの公開鍵検証情報が拒否公開鍵検証情報と判定された場合に、拒否公開鍵検証情報の送信元と拒否公開鍵検証情報の受信先とを特定し、拒否公開鍵検証情報の送信元と拒否公開鍵検証情報の受信先との間で通信されるデータの監視を行い、拒否公開鍵検証情報の受信先において拒否公開鍵検証情報の受入が行われたか否かを判定し、拒否公開鍵検証情報の受信先において拒否公開鍵検証情報の受入が行われた場合に、拒否公開鍵検証情報の受信先による拒否公開鍵検証情報の利用を抑止する対策処置を行うことを特徴とする請求項１、２、５及び６のいずれかに記載の検証装置。
【請求項１５】
前記対策処置実行部は、
拒否公開鍵検証情報の受信先において拒否公開鍵検証情報の受入が行われた場合に、拒否公開鍵検証情報の受入に要した時間を解析し、解析結果に基づき、当該拒否公開鍵検証情報の受入が一時的な受入なのか、拒否公開鍵検証情報の受信先が拒否公開鍵検証情報の検証用の情報を保有している状態での受入なのかを判定することを特徴とする請求項１４に記載の検証装置。
【請求項１６】
前記対策処置実行部は、
いずれかの公開鍵検証情報が拒否公開鍵検証情報と判定された場合に、拒否公開鍵検証情報の送信元と拒否公開鍵検証情報の受信先とを特定し、拒否公開鍵検証情報の受信先から拒否公開鍵検証情報の送信元に対してデータが送信された場合に、拒否公開鍵検証情報の受信先による拒否公開鍵検証情報の利用を抑止する対策処置を行うことを特徴とする請求項１、２、５及び６のいずれかに記載の検証装置。
【請求項１７】
前記対策処置実行部は、
いずれかの公開鍵検証情報が拒否公開鍵検証情報と判定された場合に、拒否公開鍵検証情報の送信元と拒否公開鍵検証情報の受信先とを特定するとともに、拒否公開鍵検証情報が含まれていた受信データを解析し、当該受信データに拒否公開鍵検証情報の送信元以外の通信アドレスが含まれていた場合に、拒否公開鍵検証情報の受信先から前記通信アドレスを宛先とするデータが送信された場合に、拒否公開鍵検証情報の受信先による拒否公開鍵検証情報の利用を抑止する対策処置を行うことを特徴とする請求項１、２、５及び６のいずれかに記載の検証装置。
【請求項１８】
前記検証装置は、更に、
受入可能条件情報の内容及び受入拒否条件情報の内容を示すレポート情報を生成し、生成したレポート情報を前記所定のネットワーク内の端末に対して通知するレポート情報生成通知部とを有することを特徴とする請求項３に記載の検証装置。
【請求項１９】
公開鍵の有効性を検証するために用いられる公開鍵検証情報が格納されたトラストストア内の公開鍵検証情報の格納状況を調査し、トラストストア内に格納されている公開鍵検証情報を通知するトラストストア情報を生成するトラストストア管理部と、
前記トラストストア管理部により生成されたトラストストア情報を送信するトラストストア情報送信部と、
前記トラストストア情報送信部により送信されたトラストストア情報に対する応答として送信された処置命令情報を受信する命令受信部とを有するトラストストア管理装置と、
前記トラストストア管理装置からトラストストア情報を受信するトラストストア情報受信部と、
前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成する処置判定部と、
前記処置判定部により生成された処置命令情報を前記トラストストア管理装置に送信する命令送信部とを有するトラストストア監視装置を有し、
前記トラストストア管理装置において、
前記命令受信部は、
前記トラストストア監視装置から送信された処置命令情報を受信し、
前記トラストストア管理部は、
前記命令受信部により受信された処置命令情報に従い、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の行うことを特徴とする通信システム。
【請求項２０】
前記トラストストア監視装置は、更に、
前記トラストストア管理装置に対してトラストストア情報の送信を命ずる送信命令情報を生成する送信命令生成部を有し、
前記命令送信部は、
前記送信命令生成部により生成された送信命令情報を前記トラストストア管理装置に対して送信し、
前記トラストストア管理装置において、
前記命令受信部は、
前記トラストストア監視装置から送信された送信命令情報を受信し、
前記トラストストア管理部は、
前記命令受信部により受信された送信命令情報に従って、トラストストア情報を生成することを特徴とする請求項１９に記載の通信システム。
【請求項２１】
前記トラストストア監視装置は、更に、
タイマー通知を行うタイマー部を有し、
前記送信命令生成部は、
前記タイマー部からのタイマー通知に基づいて、送信命令情報を生成することを特徴とする請求項１９に記載の通信システム。
【請求項２２】
前記トラストストア監視装置は、更に、
トラストストアへの受入が可能な公開鍵検証情報の条件を示した受入可能条件情報と、トラストストアへの受入を拒否する公開鍵検証情報の条件を示した受入拒否条件情報とを格納する条件情報格納部を有し、
前記処置判定部は、
前記トラストストア情報受信部により受信されたトラストストア情報と、前記条件情報格納部に格納されている受入可能条件情報及び受入拒否条件情報の少なくともいずれかとを照合して、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定することを特徴とする請求項１９に記載の通信システム。
【請求項２３】
前記処置判定部は、
前記条件情報格納部に格納された受入可能条件情報及び受入拒否条件情報の少なくともいずれかにおいて変更が生じた場合に、当該変更に従った処置を前記トラストストア管理装置に命ずる処置命令情報を生成することを特徴とする請求項２２に記載の通信システム。
【請求項２４】
前記トラストストア管理装置は、更に、
タイマー通知を行うタイマー部を有し、
前記トラストストア管理部は、
前記タイマー部からのタイマー通知に基づいて、トラストストア情報を生成することを特徴とする請求項１９に記載の通信システム。
【請求項２５】
前記トラストストア管理装置において、
前記トラストストア管理部は、
トラストストア内に格納されている公開鍵検証情報に変更が生じた場合に、トラストストア情報を生成することを特徴とする請求項１９に記載の通信システム。
【請求項２６】
前記トラストストア監視装置において、
前記処置判定部は、
所定の場合に、トラストストア監視装置のオペレータからの指示に基づき、トラストストア内の公開鍵検証情報の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置を命ずる処置命令情報を生成することを特徴とする請求項１９に記載の通信システム。
【請求項２７】
前記トラストストア監視装置において、
前記処置判定部は、
処置命令情報で命ずる処置の理由が示された処置理由情報が存在する場合に、処置命令情報に処置理由情報を付加し、
前記命令送信部は、
処置理由情報が付加された処置命令情報を前記トラストストア管理装置に対して送信し、
前記トラストストア管理装置は、更に、
処置命令情報に付加された処置理由情報に示された処置の理由を表示する表示部とを有することを特徴とする請求項１９に記載の通信システム。
【請求項２８】
前記トラストストア管理装置において、
前記トラストストア管理部は、
トラストストア内に格納されている公開鍵検証情報に変更が生じた場合に、変更の理由を示す変更理由情報を生成し、生成した変更理由情報をトラストストアに格納させ、トラストストア情報を生成する際にトラストストアに格納された変更理由情報を抽出し、トラストストア情報に変更理由情報を付加し、
前記トラストストア情報送信部は、
変更理由情報が付加されたトラストストア情報を前記トラストストア監視装置に対して送信することを特徴とする請求項１９に記載の通信システム。
【請求項２９】
前記トラストストア監視装置は、更に、
受入可能条件情報の内容及び受入拒否条件情報の内容を示すレポート情報を生成し、生成したレポート情報を所定のネットワーク内の端末に対して通知するレポート情報生成通知部とを有することを特徴とする請求項２２に記載の通信システム。
【請求項３０】
前記トラストストア管理装置において、
トラストストア管理部は、
トラストストア内の公開鍵検証情報の格納状況として公開鍵証明書の格納状況を調査し、トラストストア内に格納されている公開鍵証明書を通知するトラストストア情報を生成し、
前記トラストストア監視装置において
前記処置判定部は、
前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の公開鍵証明書の削除、更新、及びトラストストアへの公開鍵検証情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成し、
前記トラストストア管理装置において、
前記トラストストア管理部は、
処置命令情報に従い、トラストストア内の公開鍵証明書の削除、更新、及びトラストストアへの公開鍵証明書の追加の少なくともいずれかの処置の行うことを特徴とする請求項１９に記載の通信システム。
【請求項３１】
前記トラストストア管理装置において、
トラストストア管理部は、
トラストストア内の公開鍵検証情報の格納状況として公開鍵証明書の失効情報の格納状況を調査し、トラストストア内に格納されている失効情報を通知するトラストストア情報を生成し、
前記トラストストア監視装置において
前記処置判定部は、
前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の失効情報の削除、更新、及びトラストストアへの失効情報の追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成し、
前記トラストストア管理装置において、
前記トラストストア管理部は、
処置命令情報に従い、トラストストア内の失効情報の削除、更新、及びトラストストアへの失効情報の追加の少なくともいずれかの処置の行うことを特徴とする請求項１９に記載の通信システム。
【請求項３２】
前記トラストストア管理装置において、
トラストストア管理部は、
トラストストア内の公開鍵検証情報の格納状況として公開鍵証明書を検証するための検証パラメータの格納状況を調査し、トラストストア内に格納されている検証パラメータを通知するトラストストア情報を生成し、
前記トラストストア監視装置において
前記処置判定部は、
前記トラストストア情報受信部により受信されたトラストストア情報に基づき、トラストストア内の検証パラメータの削除、更新、及びトラストストアへの検証パラメータの追加の少なくともいずれかの処置の要否を判定し、いずれかの処置が必要と判断した場合に、必要な処置を前記トラストストア管理装置に対して命ずる処置命令情報を生成し、
前記トラストストア管理装置において、
前記トラストストア管理部は、
処置命令情報に従い、トラストストア内の検証パラメータの削除、更新、及びトラストストアへの検証パラメータの追加の少なくともいずれかの処置の行うことを特徴とする請求項１９に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、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群などが該当する。これらのパラメータは“信用できる情報”として使用されなくてはならない。従って、システム管理者はこれらのパラメータが正しく使用されているか否かについての監視・管理が必要となる場合がある。該パラメータ群を管理するストアにおいて、ユーザの権限で追加、変更、削除などが実行可能であれば、誤ったパラメータを該ストアに保存した場合に正しい検証が行われずセキュリティホールになりうる。
【０２５７】
トラストストア管理装置２０１は、格納している検証パラメータについてもトラストストア情報としてトラストストア監視装置３０１へ報告する。トラストストア監視装置３０１では、検証パラメータの受入を許諾する判断情報として、システムで受入可能な検証パラメータの情報（受入可能検証パラメータ）、受入を拒否する検証パラメータの情報（受入拒否検証パラメータ）に対して、処置判定部３１２は、トラストストア管理装置２０１から送られてきた検証パラメータの情報を含むトラストストア情報を突きあわせ、削除、更新、追加すべき検証パラメータを判定し、検証パラメータの削除、更新、追加を命令する処置命令情報を生成する。生成された処置命令情報は命令送信部３１４へ渡される。
【０２５８】
一方、トラストストア管理装置２０１では、受信した処置命令情報に従いトラストストア管理部２１２が検証パラメータの削除、更新、追加を処理する。
【０２５９】
本実施の形態により、システム管理者はエンドユーザの検証パラメータの利用状況を、ネットワーク経由で監視しシステム管理者の管理方針に基づいた、削除、更新、追加などの管理が可能である。
【０２６０】
実施の形態１８．
実施の形態１２〜１７において、トラストストア監視装置３０１の処置判定部３１２は、トラストストアの処置命令情報（削除、更新、追加）を生成する際に、その処置の根拠、理由を示す情報（処置理由情報）、例えば、証明書の削除であればＣＡ証明書に不備が見つかったことが判明したことを文書化したもの等が存在すれば、このような情報を付加情報として処置命令情報に付加する。
【０２６１】
処置理由情報が付加された処置命令情報を受信したトラストストア管理装置２０１では、処置理由情報を保管するとともに、自動、又は手動で処置理由情報をディスプレイ等の表示部に表示することでエンドユーザにトラストストアにおける変更とその理由を通知することが可能となる。
【０２６２】
このように、本実施の形態に係るトラストストア監視装置は、証明書等の削除、更新、追加命令を生成し、トラストストア管理装置に送信する際に、命令を生成した理由を示した付加情報を追加して送付可能であり、本実施の形態に係るトラストストア管理装置は、トラストストア監視装置からのトラストストアにおける証明書等の削除、更新、追加の命令を受信した場合に、付加情報が添付されていた場合、該情報を蓄積し、手動、又は自動で該情報を表示可能である。
【０２６３】
実施の形態１９．
本実施の形態では、エンドユーザ自身がトラストストアに証明書を追加、更新、削除した場合において、トラストストア管理装置２０１のトラストストア管理部２１２は、その操作を行った理由となる情報（変更理由情報）を証明書とともにトラストストアに格納する。
【０２６４】
例えば、証明書の追加であれば、システム管理者或いは通信相手による追加指示のメールや電子的なドキュメント、閲覧したＷｅｂサイトにおける追加の指示（ＵＲＬ）である。これらの情報が無い場合は、エンドユーザ自身が理由を記した電子的なドキュメントでも良い。当実施の形態は、これらの情報を指定するＧＵＩを実装することにより実現する。
【０２６５】
そして、トラストストア管理部２１２は、トラストストア情報を生成する際にトラストストアに格納された変更理由情報を抽出し、トラストストア情報に変更理由情報を付加する。そして、トラストストア情報送信部２１１は、変更理由情報が付加されたトラストストア情報をトラストストア監視装置３０１に対して送信する。
【０２６６】
このように、本実施の形態に係るトラストストア管理装置は、マニュアル操作で証明書等を変更した場合、その理由を記録する機能（例：ＧＵＩからのキーボード入力を記録する、マニュアル操作を指示したメールなどを記録するなど）を備え、トラストストア監視装置に対してトラストストアの状態を通知する場合において、該理由も併せて通知可能である。
【０２６７】
以上のように、本実施の形態によれば、システム管理者はエンドユーザがどのようにトラストストアを管理しているのかその理由まで把握することが可能である。
【０２６８】
実施の形態２０．
本実施の形態は、トラストストア監視装置３０１に、レポート情報生成通知部を追加することにより、トラストストアの状況を示すレポート情報を生成し、生成したレポート情報をネットワーク内のユーザの端末１０２等に対して通知する。
【０２６９】
本実施の形態１２〜１９において、トラストストア監視装置３０１では、エンドユーザのトラストストア情報が蓄積される。
【０２７０】
本実施の形態では、これらのデータからシステム全体におけるトラストストアの状況を定期的にレポート化する。例えば、週１回ＨＴＭＬコンテンツでレポートを作成してシステム内イントラネットに公表することで、システム内エンドユーザへの安全性情報として提示することが可能であり、エンドユーザへのフィードバックがかけられる。
【０２７１】
このように、本実施の形態におけるトラストストア監視装置は、トラストストア管理装置から報告された証明書等の内容を蓄積し、予め定められたフォーマットにレポート化する機能（例：ＨＴＭＬコンテンツ）を有する。
【０２７２】
前述した各実施の形態で、証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１は、コンピュータで実現できるものである。
【０２７３】
図示していないが、証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を備えている。
【０２７４】
例えば、ＣＰＵは、バスを介して、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、通信ボード、表示装置、Ｋ／Ｂ（キーボード）、マウス、ＦＤＤ（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＣＤＤ（コンパクトディスクドライブ）、磁気ディスク装置、光ディスク装置、プリンタ装置、スキャナ装置等と接続可能である。
【０２７５】
ＲＡＭは、揮発性メモリの一例である。ＲＯＭ、ＦＤＤ、ＣＤＤ、磁気ディスク装置、光ディスク装置は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
【０２７６】
前述した各実施の形態の証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１が扱うデータや情報は、記憶装置あるいは記憶部に保存され、証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１の各部により、記録され読み出されるものである。
【０２７７】
また、通信ボードは、例えば、ＬＡＮ、インターネット、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されている。
【０２７８】
磁気ディスク装置には、オペレーティングシステム（ＯＳ）、ウィンドウシステム、プログラム群、ファイル群（データベース）が記憶されている。
【０２７９】
プログラム群は、ＣＰＵ、ＯＳ、ウィンドウシステムにより実行される。
【０２８０】
上記証明書検証装置１０１、トラストストア管理装置２０１、トラストストア監視装置３０１の各部は、一部或いはすべてコンピュータで動作可能なプログラムにより構成しても構わない。或いは、ＲＯＭに記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実施されても構わない。
【０２８１】
上記プログラム群には、実施の形態の説明において「〜部」として説明した処理をＣＰＵに実行させるプログラムが記憶される。これらのプログラムは、例えば、Ｃ言語やＨＴＭＬやＳＧＭＬやＸＭＬなどのコンピュータ言語により作成される。
【０２８２】
また、上記プログラムは、磁気ディスク装置、ＦＤ（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ）、光ディスク、ＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のその他の記録媒体に記憶され、ＣＰＵにより読み出され実行される。
【図面の簡単な説明】
【０２８３】
【図１】実施の形態１〜１１に係る証明書検証装置を含むシステム全体の構成例を示す図。
【図２】実施の形態１に係る証明書検証装置の構成例を示す図。
【図３】実施の形態１に係る証明書検証装置の警告メッセージの例を示す図。
【図４】実施の形態１に係る証明書検証装置の動作例を示すフローチャート図。
【図５】実施の形態２に係る証明書検証装置の構成例を示す図。
【図６】実施の形態４に係る証明書検証装置の構成例を示す図。
【図７】実施の形態４に係る証明書検証装置の警告メッセージの例を示す図。
【図８】実施の形態４に係る証明書検証装置の動作例を示すフローチャート図。
【図９】実施の形態８に係る証明書検証装置の構成例を示す図。
【図１０】実施の形態８に係る証明書検証装置の警告メールの例を示す図。
【図１１】実施の形態８に係る証明書検証装置の警告メールへのリプライの例を示す図。
【図１２】実施の形態７に係る証明書検証装置におけるリプライに示された取扱態様に対する対策処置の例を示す図。
【図１３】実施の形態９に係る証明書検証装置の構成例を示す図。
【図１４】実施の形態１２〜２０に係るトラストストア管理装置及びトラストストア監視装置を含むシステム全体の構成例を示す図。
【図１５】実施の形態１２に係るトラストストア管理装置の構成例を示す図。
【図１６】実施の形態１２に係るトラストストア監視装置の構成例を示す図。
【図１７】実施の形態１２に係るトラストストア監視装置の動作例を示すフローチャート図。
【図１８】実施の形態１２に係るトラストストア管理装置の動作例を示すフローチャート図。
【図１９】実施の形態１３に係るトラストストア監視装置の構成例を示す図。
【図２０】実施の形態１４に係るトラストストア管理装置の構成例を示す図。
【符号の説明】
【０２８４】
１０１  証明書検証装置、１０２  ユーザの端末、１０３  トラストストア、１０４  システム管理者の端末、１０５  証明書発信機器、１０６  ＣＡ、１１１  データ受信部、１１２  データ解析部、１１３  データベース、１１４  エラー処理部、１１４ａ  警告部、１１４ｂ  強制処理部、１１４ｃ  受信データ蓄積部、１１４ｄ  蓄積データ解析部、１１６  コンテンツ解析部、１１７  ペンディング情報蓄積部、１２１  証明書抽出部、１２２  証明書受入判定部、１２３  証明書パス構築部、１２４  証明書パス検証部、１２５  失効状態検査部、１２６  情報書込み部、１３１  失効情報抽出部、１３２  失効情報受入判定部、２０１  トラストストア管理装置、２１１  トラストストア情報送信部、２１２  トラストストア管理部、２１３  命令受信部、２１４  タイマー部、３０１  トラストストア監視装置、３１１  トラストストア情報受信部、３１２  処置判定部、３１３  データベース、３１４  命令送信部、３１５  タイマー部、３１６  送信命令生成部、４０１  ユーザの端末、４０２  トラストストア、５０１  システム管理者の端末、６０１  ＣＡ。
【図１】
2006270504.tif 000003
【図２】
2006270504.tif 000004
【図３】
2006270504.tif 000005
【図４】
2006270504.tif 000006
【図５】
2006270504.tif 000007
【図６】
2006270504.tif 000008
【図７】
2006270504.tif 000009
【図８】
2006270504.tif 000010
【図９】
2006270504.tif 000011
【図１０】
2006270504.tif 000012
【図１１】
2006270504.tif 000013
【図１２】
2006270504.tif 000014
【図１３】
2006270504.tif 000015
【図１４】
2006270504.tif 000016
【図１５】
2006270504.tif 000017
【図１６】
2006270504.tif 000018
【図１７】
2006270504.tif 000019
【図１８】
2006270504.tif 000020
【図１９】
2006270504.tif 000021
【図２０】
2006270504.tif 000022