サーバ認証方法及びクライアント端末
【課題】確実に危険サイトを検出することが可能なサーバ認証方法を提供する。
【解決手段】検証クライアント端末４００が、被評価サーバ２００との間でセキュアな通信経路（ＳＳＬ）を確立し、確立時に被評価サーバ２００の公開鍵を受信する（Ｓ２２）。そして、検証クライアント端末４００が、ＳＳＬを介して被評価サーバ２００にＩＤ（Ａ１）を送信する（Ｓ２５）。そして、ＳＳＬを介して被評価サーバ２００からＩＤ（Ａ２）及び乱数（Ｂ１）を受信する（Ｓ２７）。そして、受信した乱数（Ｂ１）が送信したＩＤ（Ａ１）に対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部４０１に保持された公開鍵と受信した公開鍵とが一致する場合、被評価サーバ２００は正当であると判定する。そして、被評価サーバ２００が正当であると判定した場合、ＳＳＬを介して被評価サーバ２００にＩＤ（Ａ２）に対応する乱数（Ｂ２）を送信する（Ｓ３１）。
【解決手段】検証クライアント端末４００が、被評価サーバ２００との間でセキュアな通信経路（ＳＳＬ）を確立し、確立時に被評価サーバ２００の公開鍵を受信する（Ｓ２２）。そして、検証クライアント端末４００が、ＳＳＬを介して被評価サーバ２００にＩＤ（Ａ１）を送信する（Ｓ２５）。そして、ＳＳＬを介して被評価サーバ２００からＩＤ（Ａ２）及び乱数（Ｂ１）を受信する（Ｓ２７）。そして、受信した乱数（Ｂ１）が送信したＩＤ（Ａ１）に対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部４０１に保持された公開鍵と受信した公開鍵とが一致する場合、被評価サーバ２００は正当であると判定する。そして、被評価サーバ２００が正当であると判定した場合、ＳＳＬを介して被評価サーバ２００にＩＤ（Ａ２）に対応する乱数（Ｂ２）を送信する（Ｓ３１）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、不正サイトや有害サイトなどの危険サイトを検出するサーバ認証方法及びクライアント端末に関する。
【背景技術】
【０００２】
近年、フィッシングサイトやワンクリック詐欺サイトに代表される犯罪を目的とした不正サイト、及び自殺幇助サイトや児童ポルノサイト等の有害サイトが社会問題となっている。本明細書ではこれらを危険サイトと呼ぶ。
【０００３】
危険サイトには、不正サイト及び有害サイトが含まれ、不正サイトには更に成済ましサイト、改竄サイト、及びクローンサイトが含まれる。成済ましサイトとは、既存の正規サイトに似せたコンテンツやＵＲＩ（Uniform Resource Identifier）を有するサイトである。改竄サイトとは、不正な目的により改竄された正規サイトであり、例えば正規サイトのｉｆｒａｍｅにフィッシングサイトへのＵＲＩが埋め込まれたサイトである。クローンサイトとは、既存正規サイトと全く同じコンテンツとＵＲＩを有するサイトであり、例えばＤＮＳ脆弱性を用いてＵＲＩが偽装されているサイトである。有害サイトとは、多数のユーザが閲覧したくないまたは閲覧させたくないと考えるサイトである。
【０００４】
不正サイトの対策基本はサイトのドメイン名を確認することであるが、不正サイトのドメイン名は正規のドメイン名と似たものが多く、慣れたユーザでも間違える可能性がある。さらにＤＮＳサーバの脆弱性を利用することで、限定的に正規ドメインが乗っ取られる可能性すらある。また、有害サイトは、ユーザ自身がコンテンツを評価することで判定することは可能であるが、サイトへ接続したのみで不快となるサイトもあり、接続自体できないことが望ましい。
【０００５】
従来の危険サイトの対策として、サイト接続時に自動的にＵＲＩを予め用意されたリストと比較することでＵＲＩを評価するシステムが実用化されている。主流は、ＴＴＰ（Trusted Third Party）である民間企業が発行したブラック／ホワイトリストを用いたフィルタリング方式である。一方、民間企業に依存する危険性や有料サービスであることを背景とし、知り合いや多数のユーザの評価を信頼するＷｏＴ（Web of Trust）コンセプトに基づくサイト評価システムも運用されている。
【０００６】
上記危険サイトのうち、公開鍵証明書（以下、単に公開鍵という）を評価することで、成済ましサイトを検出できる。
【０００７】
ＴＴＰ利用型では、厳密な手順によりＴＬＳ（Transport Layer Security）／ＳＳＬ(Secure Socket Layer)向けサーバ証明書を発行するＥＶ−ＳＳＬ（Extended Validation SSL）を利用することで、成済ましサイトを検出する。例えば、ブラウザからサイトにアクセスする際に、サイト評価情報データベースにアクセスすることで、フィルタリングを行うことが知られている（例えば、特許文献１参照）。
【０００８】
一方、ＷｏＴ利用型では、最初に接続したサイト公開鍵を信頼するＴｏｆｕ（Trust-on-first-use）コンセプトも併用し、複数サーバが保持する複数の公開鍵キャッシュを比較することで自己署名公開鍵を評価することより、成済ましサイトを検出する。例えば、サイト公開鍵を複数のキャッシュサーバに登録し、サイト認証時にサイトから入手した公開鍵と、キャッシュサーバの公開鍵を比較することで成済ましサイトを検出することが知られている（例えば、非特許文献１参照）。
【０００９】
【特許文献１】米国特許出願公開第２００７／０２９４３３９号明細書
【非特許文献１】D. Wendlandt et al, “Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing,” In Proc. 2008 USENIX Annual Technical Conference, June 2008.
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、特許文献１の技術では、信頼のおける評価情報をキャッシュするデータベースサーバ（評価情報サーバ）が必要となり、上記サイト評価情報の妥当性を確認することもできない。また、公開鍵を含むコンテンツ全てをコピーしたクローンサイトは検出できない。
【００１１】
また、特許文献２の技術では、評価情報サーバに相当するキャッシュサーバが必要となり、一度キャッシュサーバに登録された公開鍵については、公開鍵を再登録しないとサイトが公開鍵を更新することができない。また、ある程度信用のおけるキャッシュサーバが複数必要となる。また、ＥＶ−ＳＳＬは、実在を確認できる法人に対してのみ発行されるものであるため、個人では利用することができない。更に、改竄サイトやクローンサイトは検出できない。
【００１２】
本発明は、上記事情に鑑みてなされたものであって、確実に危険サイトを検出することが可能なサーバ認証方法及びクライアント端末を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明のサーバ認証方法は、評価対象となる被評価サーバ及び前記被評価サーバとの間で通信可能なクライアント端末を有する通信システムにおけるサーバ認証方法であって、前記クライアント端末が、前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に前記被評価サーバの公開鍵を受信するステップと、前記クライアント端末が、前記通信経路を介して前記被評価サーバに第１のＩＤを送信するステップと、前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するステップと、前記クライアント端末が、前記受信した第１の乱数が前記送信した第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定するステップと、前記クライアント端末が、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信するステップとを有する。
【００１４】
この方法により、危険サイト（特に成済ましサイト及びクローンサイト）を検出することが可能である。具体的には、公開鍵の一致を確認しているために、成済ましサイトを検出できる。また、被評価サーバとクライアント端末との間で通信時に用いる乱数やＩＤを接続毎に更新していくため、一時的にＩＤや乱数を取得したクローンサイトを検出することもできる。
【００１５】
また、本発明のサーバ認証方法は、前記クライアント端末が、前記被評価サーバへ前記クライアント端末が初めてアクセス要求を行った場合に、前記セキュアな通信経路を介して前記被評価サーバから前記第１のＩＤを受信するステップと、前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバへ前記第１のＩＤに対応する前記第１の乱数を送信するステップとを有する。
【００１６】
この方法により、被評価サーバとクライアント端末との初回接続時に、クライアント端末がＩＤを、被評価サーバが乱数を保持しておくことが可能である。
【００１７】
また、本発明のサーバ認証方法は、前記被評価サーバが、コンテンツ記憶部に記憶されたコンテンツの種別毎にハッシュ値を算出するステップと、前記被評価サーバが、算出したハッシュ値に前記被評価サーバの公開鍵に基づく署名を計算して前記コンテンツとともに送信するステップと、前記クライアント端末が、署名及びコンテンツを受信するステップと、前記クライアント端末が、受信したコンテンツのハッシュ値を算出するステップと、前記クライアント端末が、算出したハッシュ値及びあらかじめ前記公開鍵管理部に保持された公開鍵を用いて受信した署名を検証して正しい場合、受信したコンテンツをデコードするステップとを有する。
【００１８】
この方法により、改竄サイトを検出することができる。また、改竄サイトを検出した場合には、コンテンツのデコードを行うことがないため、クライアント端末の安全性が向上する。
【００１９】
また、本発明のサーバ認証方法は、前記クライアント端末が、前記被評価サーバから、前記被評価サーバの評価結果を保持する評価サーバを識別するための評価サーバ識別情報を取得するステップと、前記クライアント端末が、前記評価サーバ識別情報に基づいて、前記評価サーバから前記被評価サーバの評価結果を取得するステップと、前記クライアント端末が、取得した前記被評価サーバの評価結果と所定のセキュリティポリシに基づいて、前記被評価サーバへのアクセスを許可するか否かを判定するステップとを有する。
【００２０】
この方法により、有害サイトを検出することができる。具体的には、クライアント端末が独自のセキュリティポリシをあらかじめ保持し、セキュリティポリシに照らして有害サイトであるか否かを判定している。
【００２１】
また、本発明のサーバ認証方法は、前記クライアント端末が、前記被評価サーバを評価する評価端末へ、評価対象となる前記評価結果を識別するための評価結果識別情報と第３の乱数とをメール送信するステップと、前記クライアント端末が、前記評価結果及び前記評価結果識別情報を記憶する評価結果記憶部に前記第３の乱数を記憶させるステップと、前記評価端末が、前記評価結果識別情報と前記第３の乱数とをメール受信するステップと、前記評価端末が、前記評価結果識別情報に対応する前記評価結果、前記評価結果識別情報、及び、前記受信した第３の乱数のハッシュ値を算出するステップと、前記評価端末が、前記ハッシュ値を前記クライアント端末へメール送信するステップと、前記クライアント端末が、前記ハッシュ値をメール受信するステップと、前記クライアント端末が、前記評価結果記憶部に記憶された評価結果、評価結果識別情報、第３の乱数のハッシュ値を算出するステップと、前記クライアント端末が、メール受信したハッシュ値及び算出したハッシュ値が一致し、かつ、送信先メールアドレスのドメインが正当である場合、前記評価結果は正当であると判定するステップとを有する。
【００２２】
この方法により、ハッシュ値の比較や送信先メールアドレスのドメインが正当であるか否かを判定することで、被評価サーバ２００の評価結果の正当性を確認することができる。具体的には「対象となる評価結果の作成者が（ボットなどのロボットではなく）携帯電話のユーザであること」を確認している。
【００２３】
また、本発明のサーバ認証方法は、前記被評価サーバを評価する評価端末が、前記評価サーバへ前記評価結果を送信するステップを有する。
【００２４】
この方法により、評価端末が被評価サーバを評価し、その結果を評価サーバへアップロードすることで、被評価サーバと通信を行うクライアント端末が当該サーバが危険サイトであるか否かを確認するために、評価サーバから評価結果を取得することができるようになる。
【００２５】
また、本発明のサーバ認証方法は、前記評価端末が、携帯電話端末である。
【００２６】
この方法により、評価端末が信頼性の高い携帯電話端末であるため、評価結果の正当性の確認結果が信頼性の高いものとなる。
【００２７】
本発明のクライアント端末は、評価対象となる被評価サーバとの間で通信可能なクライアント端末であって、前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に被評価サーバの公開鍵を受信する公開鍵受信部と、前記セキュアな通信経路を介して前記被評価サーバに第１のＩＤを送信する送信部と、前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するＩＤ乱数受信部と、前記ＩＤ乱数受信部により受信した第１の乱数が前記送信部により送信した前記第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記公開鍵受信部により受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定する判定部と、を備え、前記送信部が、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信する。
【００２８】
この構成により、確実に危険サイト（特に成済ましサイト及びクローンサイト）を検出することが可能である。具体的には、公開鍵の一致を確認しているために、成済ましサイトを検出できる。また、被評価サーバとクライアント端末との間で通信時に用いる乱数やＩＤを接続毎に更新していくため、一時的にＩＤや乱数を取得したクローンサイトを検出することもできる。
【発明の効果】
【００２９】
本発明によれば、確実に危険サイトを検出することが可能である。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施形態のサーバ認証方法及びクライアント端末について、添付図面を参照して詳細に説明する。
【００３１】
以下に説明する各実施形態では、サーバと、サーバに管理されるサイトと、が１対１に対応しているものとする。サーバは、１つのサイトの管理を、実際には物理的なサーバ装置が１台で行ってもよいし、複数台で行ってもよい。また、実際には物理的なサーバ装置１台によって管理されるサイトが複数であっても、１つのサーバにより１つのサイトが管理されているものとする。つまり、あるサーバにアクセスすることにより、当該サーバが管理するサイトにアクセスすることになる。また、あるサーバの識別情報を指定することにより、当該サーバにより管理されるサイトの識別情報を指定することになる。また、あるサーバの評価情報は、当該サーバが管理するサイトの評価情報になる。
【００３２】
（第１の実施形態）
図１は本発明の第１の実施形態における危険サイト検出システムの構成の一例を示すブロック図である。図１に示す危険サイト検出システム１は、評価サーバ１００、被評価サーバ２００、評価クライアント端末３００、検証クライアント端末４００を有して構成される。
【００３３】
評価サーバ１００は、被評価サーバ２００の評価情報（後述）を有するサーバであり、例えばＢｌｏｇサーバである。評価サーバにより、評価サイトが管理されている。
【００３４】
被評価サーバ２００は、評価クライアント端末３００により評価されるサーバであり、例えばＢｌｏｇサーバである。被評価サーバ２００により、被評価サイトが管理されている。各実施形態では、被評価サーバ２００が評価されることは、被評価サイトが評価されることと同義である。
【００３５】
評価クライアント端末３００は、被評価サーバ２００を評価し、その結果を評価結果として評価サーバ１００へ送信する。評価クライアント端末３００は、例えば携帯電話端末である。
【００３６】
検証クライアント端末４００は、評価サーバ１００へアクセスして被評価サーバ２００の評価情報を取得し、独自のセキュリティポリシと比較することで、被評価サーバ２００へのアクセス可否を判定する。検証クライアント端末４００は、アクセス許可と判定した場合にのみ被評価サーバ２００へアクセスすることができる。検証クライアント端末４００は、例えばＰＣや携帯電話端末である。検証クライアント端末４００は、被評価サーバ２００との間で通信可能なクライアント端末の一例である。
【００３７】
次に、危険サイト検出システム１の動作の概要について説明する。
図２は危険サイト検出システム１の動作の概要を示すフローチャートである。
【００３８】
まず、評価クライアント端末３００は、被評価サーバ２００（被評価サイト）の評価処理を行う（ステップＳ１００）。評価処理の詳細については後述する。
【００３９】
続いて、評価クライアント端末３００は、被評価サーバ２００の評価処理による評価結果を評価サーバ１００へ送信する。そして、評価サーバ１００は、評価クライアント端末３００から取得した被評価サーバ２００の評価結果を保持し、評価結果を被評価サーバ２００へトラックバックする（ステップＳ２００）。トラックバックとは、評価サーバ１００が、被評価サーバ２００へ、被評価サーバ２００の評価結果を評価サーバ１００が保持していることを通知することであり、例えば被評価サーバ２００が管理する被評価サイト上に、被評価サーバ２００の評価情報へのリンクを生成する。トラックバック技術は一般的なＢｌｏｇサーバには搭載されている。
【００４０】
続いて、検証クライアント端末４００は、被評価サーバ２００へアクセスし、不正サイト検出処理を行う（ステップＳ３００）。不正サイト検出処理の詳細については、後述する。不正サイト検出処理では、例えば、被評価サーバ２００のサーバ公開鍵を評価して被評価サイトが成済ましサイト及びクローンサイトではないことをチェックしたり、被評価サーバ２００が提供するコンテンツの期待値ハッシュ（ハッシュ値）と対応する署名を検証することで改竄サイトでないことをチェックしたりする。
【００４１】
続いて、検証クライアント端末４００は、被評価サイトが不正サイトでないとき、被評価サイトから評価結果を保持する評価サーバ１００の情報（例えば評価サイトのＵＲＩなどのサイト識別情報）を取得する（ステップＳ４００）。このとき、クライアント端末にローカルにキャッシュされた公開鍵証明書やＰ２Ｐネットワーク上のキャッシュも想定する。ただし、前記キャッシュが利用できない、かつ初回接続時に限っては評価情報から公開鍵を取得する必要があるため、被評価サイトが不正サイトでないことを検証する前に被評価サイトにアクセスする必要がある。そのため、ブラウザは被評価サイトへの接続時に本システムへ接続判定を要求し、本システムが接続許可した場合にのみ被評価サイトへ接続を行う。本システムはブラウザとは別メモリ空間で動作、かつ、提案システムのメモリ空間から他メモリ空間へはアクセスできないものとする。
【００４２】
続いて、検証クライアント端末４００は、評価サーバ１００へアクセスし、評価サーバ１００が保持している被評価サーバ２００の評価結果を取得する（ステップＳ５００）。このとき、評価サーバ１００から検証クライアント端末４００自身のセキュリティポリシを満たす数の評価結果を取得する。評価結果を取得する評価サーバ１００は複数であってもよい。
【００４３】
続いて、検証クライアント端末４００は、評価サーバ１００から取得した被評価サーバ２００の評価結果と検証クライアント端末４００自身のセキュリティポリシとに基づいて、被評価サーバ２００へのアクセスを行うか否かを判定する（ステップＳ６００）。
【００４４】
続いて、検証クライアント端末４００は、被評価サーバ２００へアクセスを行うことを決定し、実際にアクセスを行った場合、アクセス結果を自身のセキュリティポリシに反映する（ステップＳ７００）。アクセス結果を検証クライアント端末４００のユーザが確認する必要があるため、検証クライアント端末４００上にＵＩにより表示する。具体的には、ユーザに被評価サーバ２００へ接続したことによる問題の有無などを確認するための情報を表示する。そして、ＵＩにより指示を行い、ユーザの意向を反映した内容をセキュリティポリシにフィードバックする。
【００４５】
危険サイト検出システム１が図２の処理を行うことで、不正サイト（成済ましサイト、クローンサイト、改竄サイト）や有害サイトなどの危険サイトを確実に検出することができる。
【００４６】
次に、危険サイト検出システム１の各構成部１００〜４００の具体的な構成について説明する。図３は被評価サーバ２００の具体的な構成の一例を示すブロック図である。図４は検証クライアント端末４００の具体的な構成の一例を示すブロック図である。図５は評価クライアント端末３００の具体的な構成の一例を示すブロック図である。
【００４７】
評価サーバ１００は、詳細について図示しないが、クライアント端末へ情報を提供するための一般的なサーバが有する構成を備えている。
【００４８】
また、被評価サーバ２００は、署名生成部２０１、ハッシュ生成部２０２、一時ＩＤ生成部２０３、乱数・一時ＩＤ管理部２０４、一意性情報生成部２０５、クライアント接続部２０６、ページ記憶部２０７、正当性情報生成部２０８、完全性情報生成部２０９とを有して構成される。
【００４９】
署名生成部２０１は、被評価サーバ２００が提供する各種コンテンツの完全性を保証するための署名情報を生成する。
【００５０】
ハッシュ生成部２０２は、被評価サーバ２００が提供する各種コンテンツについて所定のハッシュ関数により演算を行い、ハッシュ値を算出する。
【００５１】
一時ＩＤ生成部２０３は、一時ＩＤ（Ａ１、Ａ２、・・・）を生成する。
【００５２】
乱数・一時ＩＤ管理部２０４は、クライアント接続部２０６により受信した乱数（Ｂ１、Ｂ２、・・・）を保持する。また、一時ＩＤ生成部２０３により生成された一時ＩＤを保持する。
【００５３】
一意性情報生成部２０５は、検証クライアント端末４００からの一時ＩＤに対応した乱数を一意性情報として、乱数・一時ＩＤ管理部２０４から取得する。一意性情報は、クローン検出のために用いられる。
【００５４】
クライアント接続部２０６は、他のサーバや各種クライアント端末と通信を行うための通信回線の接続を行う。
【００５５】
ページ記憶部２０７は、被評価サーバ２００が提供する各種コンテンツについて所定の単位毎（例えばページ単位）に記憶する。
【００５６】
正当性情報生成部２０８は、ＳＳＬのサーバ認証に必要な情報（正当性情報）を生成する。正当性情報は、成済まし検出のために用いられる。
【００５７】
完全性情報生成部２０９は、署名が付加されたコンテンツのハッシュ値を完全性情報として生成する。完全性情報は、改竄検出のために用いられる。
【００５８】
また、検証クライアント端末４００は、公開鍵管理部４０１、乱数・一時ＩＤ管理部４０２、サイト接続部４０３、正当性検証部４０４、一意性検証部４０５、改竄検証部４０６、評価結果収集部４０７、接続判定部４０８、ハッシュ生成部４０９、結果反映部４１０、ＵＩ部４１１、ページデコード部４１２を有して構成される。
【００５９】
なお、検証クライアント端末４００のサイト接続部４０３及びページデコード部４１２（ブラウザとして機能する構成部）以外の構成部４０１〜４０２、４０４〜４１１は、独立したセキュアな空間に配置される。
【００６０】
公開鍵管理部４０１は、被評価サーバ２００が使用する公開鍵を保持し、管理する。このように、本実施形態では、被評価サーバ２００の公開鍵がローカルキャッシュに保持される。
【００６１】
乱数・一時ＩＤ管理部４０２は、乱数を生成し、保持する。また、サイト接続部４０３により受信した一時ＩＤを保持する。
【００６２】
サイト接続部４０３は、各種サーバや他のクライアント端末と通信を行うための通信回線の接続を行う。
【００６３】
正当性検証部４０４は、受信した正当性情報に基づいて、被評価サーバ２００が管理する被評価サイトが成済ましサイトであるか否かを検証する。
【００６４】
一意性検証部４０５は、受信した一意性情報に基づいて、被評価サーバ２００が管理する被評価サイトがクローンサイトであるか否かを検証する。
【００６５】
改竄検証部４０６は、受信した完全性情報に基づいて、被評価サーバ２００が管理する被評価サイトが改竄サイトであるか否かを検証する。
【００６６】
評価結果収集部４０７は、被評価サーバ２００の評価結果を保持する。評価結果収集部４０７は、複数の評価サーバ１００から取得した複数の評価結果を保持することが可能であり、同一の評価対象について多くの評価結果を保持することで、評価結果の信用が高くなる。
【００６７】
接続判定部４０８は、所定のセキュリティポリシに基づいて、接続判定を行うことで、被評価サーバ２００が管理する被評価サイトが有害サイトであるか否かを判定する。
【００６８】
ここで、セキュリティポリシには、評価ポリシ、検証ポリシ、接続ポリシが含まれる。評価ポリシには、評価結果の有効性を判断する基準となる有効期間、カテゴリ、キーワード（評価結果のコメントからカテゴリを推測するためのワードの抽出に用いられる）、評価結果の取得先の情報を含む。検証ポリシには、各検証部４０４〜４０６による検証結果の正当性を判断する基準となる有効公開鍵キャッシュ数、改竄コンテンツ、クローン検出用乱数の有効期限の情報を含む。接続ポリシには、評価結果と各検証部４０４〜４０６による検証結果とに基づいて接続判定を行うために必要な有効サンプル数の情報と接続許可閾値を含む。
【００６９】
ハッシュ生成部４０９は、被評価サーバ２００から提供された各種コンテンツについて所定のハッシュ関数により演算を行い、ハッシュ値を算出する。
【００７０】
結果反映部４１０は、接続判定部４０８による接続判定の結果に基づいて、セキュリティポリシの内容を更新する。セキュリティポリシは予め定められているものであるが、結果反映部４１０により結果を反映することで、セキュリティポリシを所望の判断基準とすることができる。
【００７１】
ＵＩ部４１１は、各種操作キーやマイクなどの入力手段やディスプレイなどの表示手段である。
【００７２】
ページデコード部４１２は、各種コンテンツに対してデコード処理（復号化処理）を行う。例えば、ＨＴＭＬのパーサー（Ｐａｒｓｅｒ）、Ｊｐｅｇのデコーダ、Ｆｌａｓｈ Ｐｌａｙｅｒなどを用いてデコード処理を行う。
【００７３】
また、評価クライアント端末３００は、サイト接続部３０１、評価結果生成部３０２、評価結果ＩＤ生成部３０３、ＵＩ部３０４を有して構成される。
【００７４】
サイト接続部３０１は、各種サーバや他のクライアント端末と通信を行うための通信回線の接続を行う。
【００７５】
評価結果生成部３０２は、被評価サーバ２００を評価し、評価結果を生成して保持する。評価結果には、評価結果ＩＤ、評価日時、被評価サーバ２００への接続可否の情報（接続許可値）、被評価サーバ２００の公開鍵証明書（公開鍵）、被評価サーバ２００のカテゴリ、被評価サーバ２００のＵＲＩ、評価クライアント端末を識別するための情報（ＰＣメールアドレスや携帯メールアドレスなど）、コメント等が含まれる。評価結果ＩＤ、評価日時、接続許可値は、評価結果に必須の情報である。
【００７６】
評価結果ＩＤ生成部３０３は、評価結果生成部３０２により生成された評価結果を識別するための識別情報としての評価結果ＩＤを生成する。生成された評価結果ＩＤは他の評価結果の情報とともに評価結果生成部３０２で保持される。
【００７７】
ＵＩ部３０４は、各種操作キーやマイクなどの入力手段やディスプレイなどの表示手段である。
【００７８】
次に、ステップＳ１００及びＳ２００における被評価サーバ２００（被評価サイト）の評価処理について詳細に説明する。
【００７９】
図６は被評価サーバ２００の評価処理の一例を示すフローチャートである。図６のステップＳ１０１〜Ｓ１０３は、図２のステップＳ１００に相当し、図６のステップＳ２０１は、図２のステップＳ２００に相当する。
【００８０】
まず、評価クライアント端末３００は、ＵＩ部３０４を介した指示により、サイト接続部３０１が、被評価サーバ２００に接続する（ステップＳ１０１）。
【００８１】
続いて、評価クライアント端末３００は、サイト接続部３０１が、被評価サーバ２００との間でＳＳＬ認証に成功した公開鍵を評価結果生成部３０２に入力する（ステップＳ１０２）。
【００８２】
続いて、評価クライアント端末３００は、評価結果生成部３０２が、被評価サーバ２００を評価し、評価結果を保持する。評価結果のうち被評価サーバ２００への接続可否の情報（接続許可値）、被評価サーバ２００のカテゴリ、コメントは評価クライアント端末３００の操作者の指示に基づいてＵＩ部３０４が入力する。（ステップＳ１０３）。
【００８３】
続いて、評価クライアント端末３００は、サイト接続部３０１が、評価結果生成部３０２に保持された評価結果を評価サーバ１００へ送信する（ステップＳ２０１）。
【００８４】
このように、評価クライアント端末３００が被評価サーバ２００（被評価サイト）を評価し、その結果を評価サーバ１００へアップロードすることで、被評価サーバ２００へアクセスする端末が当該サーバにより管理されるサイトが危険サイトであるか否かを確認するために、評価サーバ１００から評価結果を取得することができるようになる。特に、評価クライアント端末３００が携帯電話端末等の信頼性の高い端末を用いて評価しているため、第２の実施形態に示すように、評価結果は信頼性の高いものとなる。
【００８５】
次に、ステップＳ３００及びＳ７００における危険サイト検出処理（不正サイト検出処理及び有害サイト検出処理）の詳細について説明する。
【００８６】
図７及び図８は、危険サイト検出処理の一例を示すフローチャートである。図７及び図８のステップＳ３１０〜Ｓ３７０は、図２のステップＳ３００に相当する不正サイト検出処理の内容であり、図７及び図８のステップＳ６０１及びＳ７０１は、図２のステップＳ６００及びＳ７００に相当する有害サイト検出処理の内容である。図７及び図８では、主に被評価サーバ２００と検証クライアント端末４００との２回目以降接続時の動作について示している。
【００８７】
まず、検証クライアント端末４００は、ＵＩ部４１１を介した指示により、サイト接続部４０３が、被評価サーバ２００に接続する（ステップＳ３０１）。
【００８８】
続いて、被評価サーバ２００は、正当性情報生成部２０８が、クライアント接続部２０６を介して、ＳＳＬ処理を行う（ステップＳ３０２）。ＳＳＬ処理では、被評価サーバ２００の公開鍵を検証クライアント端末４００へ送信し、検証クライアント端末４００との間でＳＳＬによる通信セッションを確立する。なお、ＳＳＬによる通信セッションは、セキュアな通信経路の一例である。ステップＳ３０１〜Ｓ３０２は、既存の技術と同様の方法で実行可能である。
【００８９】
続いて、検証クライアント端末４００は、正当性検証部４０４が、公開鍵管理部４０１により保持されている前回使用された公開鍵（ただし、初回は評価結果から取得される。詳細は後述）と今回受信された公開鍵とが一致するか否かを判定する（ステップＳ３０３）。一致する、かつＳＳＬサーバ認証が成功した場合には、正当性有りと判定し、サイト接続部４０３が、乱数・一時ＩＤ管理部４０２から一時ＩＤを取得し、被評価サーバ２００に送信する（ステップＳ３０４）。
【００９０】
このように、ステップＳ３０１〜Ｓ３０３の処理を行うことで、成済ましサイトを検出することが可能である。成済ましサイトでない場合には、ステップＳ３０４において正当性有りと判定され、成済ましサイトである場合には、ステップＳ３０４において正当性なしと判定される。
【００９１】
続いて、被評価サーバ２００は、一意性情報生成部２０５が、検証クライアント端末４００からの一時ＩＤに対応した乱数を乱数・一時ＩＤ管理部２０４から取得する。そして、クライアント接続部２０６が、取得した乱数を検証クライアント端末４００へ送信する（ステップＳ３０５）。
【００９２】
続いて、検証クライアント端末４００は、一意性検証部４０５が、乱数・一時ＩＤ管理部により保持された乱数とサイト接続部４０３により受信した乱数とを比較し（ステップＳ３０６）、これらの乱数が一致した場合に一意性有りと判定する（ステップＳ３０７）。
【００９３】
このように、ステップＳ３０４〜Ｓ３０６の処理を行うことで、クローンサイトを検出することが可能である。クローンサイトでない場合には、ステップＳ３０７において一意性ありと判定され、成済ましサイトである場合には、ステップＳ３０７において一意性なしと判定される。
【００９４】
続いて、被評価サーバ２００は、ハッシュ生成部２０２が、ページ記憶部２０７により記憶されたページを取得し、取得したページについて種別毎にハッシュ値を計算する。そして、完全性情報生成部２０９が、ハッシュ生成部２０２により計算されたハッシュ値に署名生成部２０１により生成された署名を付加する。そして、クライアント接続部２０６が、署名が付加されたハッシュ値を検証クライアント端末４００へ送信する（ステップＳ３０８）。なお、本ステップの送信する前の段階まで（つまり署名を付加する段階まで）は、改竄検証を行うために事前に行われているものである。なお、上記種別とは、コンテンツ種別であり、例えばＨＴＭＬ、ＦＬＡＳＨ、ＪＰＥＧなどのコンテンツ種別である。ディジタル署名方式としてＲＳＡを利用する場合、署名生成は「公開鍵と対になる秘密鍵でハッシュ値を暗号化する」、署名の検証は「公開鍵で署名を復号して所定のハッシュ値が得る」ことを意味する。
【００９５】
続いて、検証クライアント端末４００は、ハッシュ生成部４０９が、サイト接続部４０３により受信したページ（受信ページ）についてハッシュ値を計算する。そして、改竄検証部４０６が、サイト接続部４０３により受信した署名を公開鍵管理部４０１に保持された公開鍵で検証し、正当な署名であるか否かを判定する（ステップＳ３０９）。そして、判定の結果、正当な署名である場合には、ページデコード部４１２が、受信ページをデコードする（ステップＳ３１０）。
具体的には、被評価サイトはコンテンツのハッシュ値Ａに対して公開鍵に対応した秘密鍵で署名（暗号化）してディジタル署名を計算しておき、ステップＳ３０９において検証クライアント４００は署名を公開鍵で検証（復号）してハッシュ値Ａを取得し、ステップＳ３１０において被評価サイトから取得したコンテンツから計算したハッシュ値Ａ’と前記ハッシュ値Ａを比較して一致することを確認する。
【００９６】
このように、ステップＳ３０８〜Ｓ３０９の処理を行うことで、改竄サイトを検出することが可能である。改竄サイトでない場合には、ステップＳ３１０において正当な署名であると判定され、改竄サイトである場合には、ステップＳ３１０において正当な署名であると判定される。
【００９７】
続いて、検証クライアント端末４００は、接続判定部４０８が、評価結果収集部４０７により収集された複数の評価結果を、所定の評価ポリシに基づいて集約する。評価結果に含まれる情報（被評価サーバ２００への接続可否の情報（接続許可値）、被評価サーバ２００の公開鍵証明書（公開鍵）、被評価サーバ２００のカテゴリ、被評価サーバ２００のＵＲＩ）は個々の評価結果で異なることが予想される。そのため、接続許可値など数値の場合は平均値を算出し、数値以外の公開鍵やＵＲＩやカテゴリの場合は最も多い内容を調査し、これらを最終的な評価情報として扱う。
そして、接続判定部４０８が、各検証部（正当性検証部４０４、一意性検証部４０５、及び、改竄検証部４０６）による検証結果を、所定の検証ポリシに基づいて集約する。そして、接続判定部４０８が、これらの集約結果と所定の接続ポリシに基づいて、被評価サーバ２００への接続判定を行う。つまり、接続判定部４０８が、所定のセキュリティポリシを満たしているか否かを判定する（ステップＳ７０１）。満たしている場合には、接続判定部４０８が、被評価サーバ２００への接続を許可する（ステップＳ７０２）。さらに、結果反映部４１０が、接続判定の結果を各ポリシに反映するようにしてもよい。
【００９８】
このように、ステップＳ７０１の処理を行うことで、有害サイトを検出することが可能である。有害サイトでない場合には、ステップＳ７０２において所定の各ポリシを満たし、有害サイトである場合には、ステップＳ７０２において所定の各ポリシを満たさない状態となる。
【００９９】
なお、ステップＳ３０１〜Ｓ３１０の処理後にステップＳ７０１〜Ｓ７０２の処理を行うことを説明したが、ステップＳ７０１〜Ｓ７０２の処理後にステップＳ３０１〜Ｓ３１０の処理を行ってもよい。
【０１００】
次に、図７及び図８における、被評価サーバ２００と検証クライアント端末４００との初回接続時及び２回目以降接続時のデータ（一時ＩＤ及び乱数）の流れについて、図９及び図１０を用いて説明する。図９及び図１０では、成済ましサイト検出及びクローンサイト検出に係る部分について示している。
【０１０１】
図９は初回接続時のデータの流れの一例を示すシーケンス図である。
まず、検証クライアント端末４００が、検証クライアント端末４００と被評価サーバ２００との接続要求を被評価サーバ２００へ送信する（ステップＳ１１）。
【０１０２】
続いて、被評価サーバ２００が、検証クライアント端末４００からの接続要求（ＳＳＬではＣｌｉｅｎｔ Ｈｅｌｌｏメッセージに相当）を受けて、署名付き公開鍵を検証クライアント端末４００へ送信する（ステップＳ１２）。
【０１０３】
続いて、検証クライアント端末４００が、被評価サーバ２００からの署名付き公開鍵の署名が正当であるかを検証する等の一連のＳＳＬサーバ認証処理を実行し、ＳＳＬ／ＴＬＳによるセキュアな通信セッションが確立される（ステップＳ１３）。確立後、公開鍵を保存する（ステップＳ１４）
【０１０４】
以上のステップＳ１１〜Ｓ１４は、図７のステップＳ３０１〜Ｓ３０３に相当する。
【０１０５】
続いて、セキュアな通信セッションが確立されると、被評価サーバ２００が、一時ＩＤ（Ａ１）を生成し、一時ＩＤ（Ａ１）を検証クライアント端末４００へ送信する（ステップＳ１５）。そして、検証クライアント端末４００が、一時ＩＤ（Ａ１）を保持する（ステップＳ１６）。
【０１０６】
続いて、検証クライアント端末４００が、乱数（Ｂ１）を生成し（ステップＳ１７）、乱数（Ｂ１）を被評価サーバ２００へ送信する（ステップＳ１８）。なお、２回目接続時に使用するため、検証クライアント端末４００は、生成した乱数（Ｂ１）を乱数・一時ＩＤ管理部４０２（図４参照）に保持しておく。また、被評価サーバ２００も、受信した乱数（Ｂ１）を乱数・一時ＩＤ管理部２０４に保持しておく。
【０１０７】
以上のステップＳ１５〜Ｓ１８は、図７のステップでは不図示である。
【０１０８】
図１０は２回目以降接続時のデータの流れの一例を示すシーケンス図である。
図１０の処理を開始する前に、検証クライアント端末４００は一時ＩＤ（Ａ１）及び乱数（Ｂ１’）を予め保持しているものとし、被評価サーバ２００は一時ＩＤ（Ａ１）に対応する乱数として乱数（Ｂ１）を予め保持しているものとする。
【０１０９】
まず、検証クライアント端末４００が、検証クライアント端末４００と被評価サーバ２００との接続要求を被評価サーバ２００へ送信する（ステップＳ２１）。
【０１１０】
続いて、被評価サーバ２００が、検証クライアント端末４００からの接続要求を受けて、署名付き公開鍵を検証クライアント端末４００へ送信する（ステップＳ２２）。以降、ＳＳＬ処理を行い、セキュアな通信セッションが確立される（ステップＳ２３）。
【０１１１】
続いて、検証クライアント端末４００が、事前に保持された公開鍵（例えば初回接続時に使用した公開鍵）と今回被評価サーバ２００から受信した公開鍵とを比較する（ステップＳ２４）。
【０１１２】
以上のステップＳ２１〜Ｓ２４は、図７のステップＳ３０１〜Ｓ３０３に相当する。
【０１１３】
続いて、公開鍵が一致した場合、検証クライアント端末４００が、事前に保持された一時ＩＤ（Ａ１）を被評価サーバ２００へ送信する（ステップＳ２５）。
【０１１４】
続いて、被評価サーバ２００が、検証クライアント端末４００からの一時ＩＤ（Ａ１）に対応する事前に保持された乱数（Ｂ１）を選択し、また、一時ＩＤ（Ａ２）を生成するする（ステップＳ２６）。そして、被評価サーバ２００が、乱数（Ｂ１）と一時ＩＤ（Ａ２）とを検証クライアント端末４００へ送信する（ステップＳ２７）。
【０１１５】
続いて、検証クライアント端末４００が、受信した乱数（Ｂ１）と事前に保持された乱数（Ｂ１’）とを比較する（ステップＳ２８）。比較の結果、両者が異なる場合（Ｂ１≠Ｂ１’）、被評価サイトがクローンサイトであると判定できる。
【０１１６】
続いて、検証クライアント端末４００が、保持している一時ＩＤ（Ａ１）を受信した一時ＩＤ（Ａ２）で更新し、乱数・一時ＩＤ管理部４０２に一時ＩＤ（Ａ２）を保持する（ステップＳ２９）。
【０１１７】
続いて、検証クライアント端末４００が、乱数（Ｂ２）を生成し（ステップＳ３０）、乱数（Ｂ２）を被評価サーバ２００へ送信する（ステップＳ３１）。そして、被評価サーバ２００が、保持している乱数（Ｂ１）を受信した乱数（Ｂ２）で更新し、乱数・一時ＩＤ管理部４０２に乱数（Ｂ２）を保持する（ステップＳ３２）。
【０１１８】
以上のステップＳ２５〜Ｓ３２は、図７のステップＳ３０４〜Ｓ３０７に相当する。
【０１１９】
図９及び図１０に示した初回接続時及び２回目以降接続時の危険サイト検出システム１の動作によれば、たとえ被評価サイトのクローンサイトが作成されたとしても、乱数（Ｂ）の更新前後ではクローンサイトとオリジナルサイトとの間で乱数が異なるため、クローンサイトであることを検出可能である。つまり、一時ＩＤ（Ａ）及び乱数（Ｂ）は検証クライアント端末４００が被評価サーバ２００へアクセスする度に変更されることになり、安全性が向上させることが可能である。
【０１２０】
なお、ステップＳ２３〜Ｓ２４において、検証クライアント端末４００が、公開鍵の比較の結果、一致しない場合であっても、ＳＳＬサーバ認証が成功している、かつステップＳ２８において、乱数の比較の結果、一致する場合には、被評価サーバ２００がクローンサイトではないと判定するようにしてもよい。この場合、検証クライアント端末４００は、ステップＳ２３において受信した公開鍵を新たな公開鍵として保持する。このように、危険サイト検出システム１は、一度登録された被評価サーバ２００の公開鍵を更新することもできる。但し、頻繁な公開鍵の更新は一般にはありえないため、セキュリティポリシに許容可能な更新間隔を設定できるものとし、これを下回る場合は不正な更新であるとして検証を失敗させてもよい。
【０１２１】
また、本実施形態の危険サイト検出システム１によれば、ＥＶ−ＳＳＬ、有料ソフトなどを用いないため、システム自体が低コストである。また、ＥＶ−ＳＳＬ対応サイトに対して本発明を併用する場合、更に成り済まし耐性を向上できる。
【０１２２】
（第２の実施形態）
本実施形態では、評価クライアント端末３００による被評価サーバ２００（被評価サイト）の評価結果がどの程度妥当なものであるかを確認するための処理、つまり評価結果の正当性の確認処理を行う。
【０１２３】
本実施形態の危険サイト検出システムの構成は、基本的に図１と同様であるが、評価クライアント端末及び検証クライアント端末の具体的な構成が異なっている。通常の評価クライアント端末は、第１の実施形態における評価クライアント端末３００の構成と本実施形態の評価クライアント端末３００Ｂの構成とをいずれも含むように構成される。また、通常の検証クライアント端末は、第１の実施形態における検証クライアント端末４００の構成と本実施形態の検証クライアント端末４００Ｂの構成とをいずれも含むように構成される。
【０１２４】
図１１は本実施形態の評価クライアント端末３００Ｂの具体的な構成の一例を示すブロック図である。図１２は本実施形態の検証クライアント端末４００Ｂの具体的な構成の一例を示すブロック図である。図１１及び図１２において、第１の実施形態の評価クライアント端末３００及び検証クライアント端末４００と同一の構成については、同一の符号を付し、説明を省略または簡略化する。
【０１２５】
評価クライアント端末３００Ｂは、評価結果ＤＢ３１２、評価結果検索部３１３、応答メール生成部３１４、ハッシュ生成部３１５、応答確認部３１６、メール送受信部３１７、ＵＩ部３０４を有して構成される。
【０１２６】
評価結果ＤＢ３１２は、図５の評価結果生成部３０２により保持される評価結果と同様の情報を保持する。
【０１２７】
評価結果検索部３１３は、評価結果ＤＢ３１２を参照し、１つ以上の評価結果から検索対象の評価結果を検索する。
【０１２８】
応答メール生成部３１４は、他の端末等へ送信すべきメールを生成する。
【０１２９】
ハッシュ生成部３１５は、所定の情報について所定のハッシュ関数により演算を行い、ハッシュ値を算出する。
【０１３０】
応答確認部３１６は、メール送受信部３１７により受信したメールの内容を確認し、メールの内容に応じて、評価結果検索部３１３、応答メール生成部３１４、ハッシュ生成部３１５へ制御指令を送る。
【０１３１】
メール送受信部３１７は、他の端末等からメールを受信する。また、他の端末等へメールを送信する。
【０１３２】
検証クライアント端末４００Ｂは、乱数生成部４２１、メール送受信部４２２、正当性確認部４２３、正当性確認メール生成部４２４、評価結果記憶部４２５、ハッシュ生成部４０９、ＵＩ部４１１を有して構成される。
【０１３３】
乱数生成部４２１は、乱数を生成し、保持する。
【０１３４】
メール送受信部４２２は、他の端末等からメールを受信する。また、他の端末等へメールを送信する。
【０１３５】
正当性確認部４２３は、評価結果の正当性を確認するために必要な判定を行う。例えば、生成した乱数と受信した乱数とが一致するか否かの判定や、生成したハッシュ値と受信したハッシュ値が一致する否かの判定を行う。
【０１３６】
正当性確認メール生成部４２４は、他の端末等へ送信すべきメールを生成する。
【０１３７】
評価結果記憶部４２５は、図４の評価結果収集部４０７により保持される評価結果と同様の情報を保持する。
【０１３８】
次に、評価結果の正当性の確認処理について説明する。
図１３及び図１４は被評価サーバ２００（被評価サイト）の評価結果の確認処理の一例を示すフローチャートである。なお、図１３及び図１４の処理は、通常、第１の実施形態における図２の処理と並行して定期的に実施される。また、評価結果に評価クライアント端末３００Ｂの携帯メールアドレスが含まれていない場合には、評価クライアント端末３００Ｂの所有者のＰＣメールアドレスが含まれているものとする。
【０１３９】
まず、検証クライアント端末４００Ｂは、ＵＩ部４１１を介した指示により、メール送受信部４２２が、評価結果の正当性の確認要求を送信する（ステップＳ８０１）。この確認要求は、ステップＳ８０２に示すＰＣメールアドレスへ送信する。評価クライアント端末３００Ｂとしては、携帯電話を想定する。携帯電話はＰＣメールアドレスへ送信されたメールを受信することも可能である。なお、ステップＳ８０１の処理は次のステップＳ８０２の処理とまとめて行ってもよい。
【０１４０】
続いて、検証クライアント端末４００Ｂは、乱数生成部４２１が、乱数を生成する。また、正当性確認メール生成部４２４が、ＵＩ部４１１を介した指示により、評価結果記憶部４２５により記憶された正当性の確認を希望する評価結果の評価結果ＩＤを取得する。そして、正当性確認メール生成部４２４が、生成された乱数、取得した評価結果ＩＤの情報を含むメールを生成する。そして、メール送受信部４２２が、評価結果記憶部４２５により記憶された評価クライアント端末３００Ｂの識別情報（ここではＰＣメールアドレスを想定）を取得し、生成されたメールを取得したＰＣメールアドレスへ送信する（ステップＳ８０２）。
【０１４１】
続いて、評価クライアント端末３００Ｂは、メール送受信部３１７により検証クライアント端末４００Ｂからのメールを受信する。そして、応答確認部３１６が、当該メールの内容を確認する。そして、ＵＩ部３０４が、当該メールに対して応答するか否かを指定するための情報を提示する（ステップＳ８０３）。そして、ＵＩ部４１１が、応答するか否かを指定する（ステップＳ８０４）。
【０１４２】
続いて、評価クライアント端末３００Ｂは、応答メール生成部３１４が、受信した検証クライアント端末４００Ｂからの乱数と、図示しない記憶部に保持された評価クライアント端末３００Ｂの携帯メールアドレスと、を含む応答メールを生成する。そして、メール送受信部３１７が、生成された応答メールを検証クライアント端末４００Ｂへ送信する（ステップＳ８０５）。
【０１４３】
ステップＳ８０１〜Ｓ８０５の処理によれば、評価クライアント端末が使用する携帯メールアドレスを評価結果に含めてＩｎｔｅｒｎｅｔ全体に公開したくない場合であっても（評価結果に携帯メールアドレスが含まれていない場合であっても）、検証クライアント端末４００Ｂに当該携帯メールアドレスを知らせることができる。さらに、評価結果に携帯メールアドレスが含まれている場合には、ステップＳ８０２〜Ｓ８０６の処理を省略可能である。
【０１４４】
続いて、検証クライアント端末４００Ｂは、正当性確認部４２３が、乱数生成部４２１で生成した乱数とメール送受信部４２２により受信した応答メールに含まれる乱数とが一致するか否かを判定する（ステップＳ８０６）。一致した場合、評価クライアント端末からのＰＣメールのＦｒｏｍ行が改竄されていた場合であっても、ステップＳ８０２のメール送信先とステップＳ８０５の応答メールの送信元との一致を乱数により検証可能である為、評価情報に含まれるＰＣメールアドレスから携帯メールアドレスが送られたことを把握することができる。次に、正当性確認部４２３は、携帯メールアドレスのドメインが正当であるか否か（つまり、携帯メールアドレスのドメインが正当な携帯電話会社を示すものであり、信頼できるものであるか否か）を判定する（ステップＳ８０７）。正当である場合、メール送受信部４２２が、乱数と評価結果ＩＤとを含むメールを、受信した応答メールに含まれる携帯メールアドレスへ送信する（ステップＳ８０８）。なお、ステップＳ８０８において送信される乱数と評価結果ＩＤは、ステップＳ８０２において送信されたものと同様である。
【０１４５】
続いて、評価クライアント端末３００Ｂは、検証クライアント端末４００Ｂからのメールを受信する。そして、応答確認部３１６が、当該メールの内容を確認する。そして、評価結果検索部３１３が、受信した評価結果ＩＤをキーとして評価結果ＤＢ３１２から評価結果を取得する。そして、ハッシュ生成部３１５が、評価結果、評価結果ＩＤ、乱数（検証クライアント端末４００Ｂからの乱数）、被評価サーバ２００の識別情報（例えば被評価サイトのＵＲＩなどのサイト識別情報）のハッシュ値を生成する。そして、応答メール生成部３１４が、ハッシュ値の情報を含む応答メールを生成し、メール送受信部３１７が、当該応答メールを検証クライアント端末４００Ｂへ送信する（ステップＳ８０９）。
【０１４６】
続いて、検証クライアント端末４００Ｂは、ハッシュ生成部４０９が、自端末に保持している評価結果、評価結果ＩＤ、乱数、被評価サーバ２００の識別情報（例えば被評価サイトのＵＲＩなどのサイト識別情報）のハッシュ値を生成する（ステップＳ８１０）。そして、正当性確認部４２３が、ハッシュ生成部４０９により生成されたハッシュ値とメール送受信部４２２により受信された応答メールに含まれるハッシュ値とが一致するか否かを判定する（ステップＳ８１１）。一致する場合、正当性確認部４２３が、評価結果は正当性ありと判断する（ステップＳ８１２）。評価クライアント端末からの携帯電話メールのＦｒｏｍ行が改竄されていた場合であっても、ステップＳ８０８のメール送信先とステップＳ８０９の応答メールの送信元との一致を乱数により検証可能である為、送信した先の携帯電話から応答があったことを把握することができる。
【０１４７】
このように、本実施形態の危険サイト検出システムによれば、被評価サーバ２００（被評価サイト）の評価結果の正当性を確認することができる。また、本実施形態では、評価クライアント端末３００Ｂとして携帯電話端末を想定している。携帯電話端末の購入時には身分証明書等の提示が必要であるため、信頼性が高い。また、携帯電話端末は、所有者が常に持ち歩き摺る可能性が高く、ＧＰＳ機能等により移動の有無を検証可能であり、さらにＰＩＮや指紋認証により実際の使用者を認証可能である。したがって、評価クライアント端末３００Ｂとして携帯電話端末を使用することで、評価結果が、ボット等により不正に公開されたものまたは自動的に改竄されて正当でなくなったものではなく、人間の指示により正当に評価されたものとして信頼可能なものとなる。
なお、検証クライアント端末４００Ｂからの評価結果の確認メールは、ＵＩ部４１１を介さずセキュリティポリシに従って自動で発信しても構わない。同様に確認メールに対応する応答メールは、ＵＩ部４１１を介さずセキュリティポリシに従って自動で応答して構わない。但し、安全性を担保するため応答メールに関しては評価者の利便性を損なわない範囲で一定の割合でＵＩ部４１１を介す実装とすることが望ましい。
【産業上の利用可能性】
【０１４８】
本発明は、確実に危険サイトを検出可能なサーバ認証方法、クライアント端末、危険サイト検出システム等に有用である。
【図面の簡単な説明】
【０１４９】
【図１】本発明の実施形態における危険サイト検出システムの構成の一例を示すブロック図
【図２】本発明の第１の実施形態における危険サイト検出システムの動作の概要を示すフローチャート
【図３】本発明の第１の実施形態における被評価サーバの具体的な構成の一例を示すブロック図
【図４】本発明の第１の実施形態における検証クライアント端末の具体的な構成の一例を示すブロック図
【図５】本発明の第１の実施形態における評価クライアント端末の具体的な構成の一例を示すブロック図
【図６】本発明の第１の実施形態における被評価サーバの評価処理の一例を示すフローチャート
【図７】本発明の第１の実施形態における危険サイト検出処理の一例を示すフローチャート
【図８】本発明の第１の実施形態における危険サイト検出処理の一例を示すフローチャート
【図９】本発明の第１の実施形態における被評価サーバと検証クライアント端末との初回接続時のデータの流れの一例を示すシーケンス
【図１０】本発明の第１の実施形態における被評価サーバと検証クライアント端末との２回目以降接続時のデータの流れの一例を示すシーケンス
【図１１】本発明の第２の実施形態における評価クライアント端末の具体的な構成の一例を示すブロック図
【図１２】本発明の第２の実施形態における検証クライアント端末の具体的な構成の一例を示すブロック図
【図１３】本発明の第２の実施形態における評価結果の確認処理の一例を示すフローチャート
【図１４】本発明の第２の実施形態における評価結果の確認処理の一例を示すフローチャート
【符号の説明】
【０１５０】
１ 危険サイト検出システム
１００ 評価サーバ
２００ 被評価サーバ
２０１ 署名生成部
２０２ ハッシュ生成部
２０３ 一時ＩＤ生成部
２０４ 乱数・一時ＩＤ管理部
２０５ 一意性情報生成部
２０６ クライアント接続部
２０７ ページ記憶部
２０８ 正当性情報生成部
２０９ 完全性情報生成部
３００、３００Ｂ 評価クライアント端末
３０１ サイト接続部
３０２ 評価結果生成部
３０３ 評価結果ＩＤ生成部
３０４ ＵＩ部
３１２ 評価結果ＩＤ
３１３ 評価結果検索部
３１４ 応答メール生成部
３１５ ハッシュ生成部
３１６ 応答確認部
３１７ メール送受信部
４００、４００Ｂ 検証クライアント端末
４０１ 公開鍵管理部
４０２ 乱数・一時ＩＤ管理部
４０３ サイト接続部
４０４ 正当性検証部
４０５ 一意性検証部
４０６ 改竄検証部
４０７ 評価結果収集部
４０８ 接続判定部
４０９ ハッシュ生成部
４１０ 結果反映部
４１１ ＵＩ部
４１２ ページデコード部
４２１ 乱数生成部
４２２ メール送受信部
４２３ 正当性確認部
４２４ 正当性確認メール生成部
４２５ 評価結果記憶部
【技術分野】
【０００１】
本発明は、不正サイトや有害サイトなどの危険サイトを検出するサーバ認証方法及びクライアント端末に関する。
【背景技術】
【０００２】
近年、フィッシングサイトやワンクリック詐欺サイトに代表される犯罪を目的とした不正サイト、及び自殺幇助サイトや児童ポルノサイト等の有害サイトが社会問題となっている。本明細書ではこれらを危険サイトと呼ぶ。
【０００３】
危険サイトには、不正サイト及び有害サイトが含まれ、不正サイトには更に成済ましサイト、改竄サイト、及びクローンサイトが含まれる。成済ましサイトとは、既存の正規サイトに似せたコンテンツやＵＲＩ（Uniform Resource Identifier）を有するサイトである。改竄サイトとは、不正な目的により改竄された正規サイトであり、例えば正規サイトのｉｆｒａｍｅにフィッシングサイトへのＵＲＩが埋め込まれたサイトである。クローンサイトとは、既存正規サイトと全く同じコンテンツとＵＲＩを有するサイトであり、例えばＤＮＳ脆弱性を用いてＵＲＩが偽装されているサイトである。有害サイトとは、多数のユーザが閲覧したくないまたは閲覧させたくないと考えるサイトである。
【０００４】
不正サイトの対策基本はサイトのドメイン名を確認することであるが、不正サイトのドメイン名は正規のドメイン名と似たものが多く、慣れたユーザでも間違える可能性がある。さらにＤＮＳサーバの脆弱性を利用することで、限定的に正規ドメインが乗っ取られる可能性すらある。また、有害サイトは、ユーザ自身がコンテンツを評価することで判定することは可能であるが、サイトへ接続したのみで不快となるサイトもあり、接続自体できないことが望ましい。
【０００５】
従来の危険サイトの対策として、サイト接続時に自動的にＵＲＩを予め用意されたリストと比較することでＵＲＩを評価するシステムが実用化されている。主流は、ＴＴＰ（Trusted Third Party）である民間企業が発行したブラック／ホワイトリストを用いたフィルタリング方式である。一方、民間企業に依存する危険性や有料サービスであることを背景とし、知り合いや多数のユーザの評価を信頼するＷｏＴ（Web of Trust）コンセプトに基づくサイト評価システムも運用されている。
【０００６】
上記危険サイトのうち、公開鍵証明書（以下、単に公開鍵という）を評価することで、成済ましサイトを検出できる。
【０００７】
ＴＴＰ利用型では、厳密な手順によりＴＬＳ（Transport Layer Security）／ＳＳＬ(Secure Socket Layer)向けサーバ証明書を発行するＥＶ−ＳＳＬ（Extended Validation SSL）を利用することで、成済ましサイトを検出する。例えば、ブラウザからサイトにアクセスする際に、サイト評価情報データベースにアクセスすることで、フィルタリングを行うことが知られている（例えば、特許文献１参照）。
【０００８】
一方、ＷｏＴ利用型では、最初に接続したサイト公開鍵を信頼するＴｏｆｕ（Trust-on-first-use）コンセプトも併用し、複数サーバが保持する複数の公開鍵キャッシュを比較することで自己署名公開鍵を評価することより、成済ましサイトを検出する。例えば、サイト公開鍵を複数のキャッシュサーバに登録し、サイト認証時にサイトから入手した公開鍵と、キャッシュサーバの公開鍵を比較することで成済ましサイトを検出することが知られている（例えば、非特許文献１参照）。
【０００９】
【特許文献１】米国特許出願公開第２００７／０２９４３３９号明細書
【非特許文献１】D. Wendlandt et al, “Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing,” In Proc. 2008 USENIX Annual Technical Conference, June 2008.
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、特許文献１の技術では、信頼のおける評価情報をキャッシュするデータベースサーバ（評価情報サーバ）が必要となり、上記サイト評価情報の妥当性を確認することもできない。また、公開鍵を含むコンテンツ全てをコピーしたクローンサイトは検出できない。
【００１１】
また、特許文献２の技術では、評価情報サーバに相当するキャッシュサーバが必要となり、一度キャッシュサーバに登録された公開鍵については、公開鍵を再登録しないとサイトが公開鍵を更新することができない。また、ある程度信用のおけるキャッシュサーバが複数必要となる。また、ＥＶ−ＳＳＬは、実在を確認できる法人に対してのみ発行されるものであるため、個人では利用することができない。更に、改竄サイトやクローンサイトは検出できない。
【００１２】
本発明は、上記事情に鑑みてなされたものであって、確実に危険サイトを検出することが可能なサーバ認証方法及びクライアント端末を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明のサーバ認証方法は、評価対象となる被評価サーバ及び前記被評価サーバとの間で通信可能なクライアント端末を有する通信システムにおけるサーバ認証方法であって、前記クライアント端末が、前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に前記被評価サーバの公開鍵を受信するステップと、前記クライアント端末が、前記通信経路を介して前記被評価サーバに第１のＩＤを送信するステップと、前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するステップと、前記クライアント端末が、前記受信した第１の乱数が前記送信した第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定するステップと、前記クライアント端末が、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信するステップとを有する。
【００１４】
この方法により、危険サイト（特に成済ましサイト及びクローンサイト）を検出することが可能である。具体的には、公開鍵の一致を確認しているために、成済ましサイトを検出できる。また、被評価サーバとクライアント端末との間で通信時に用いる乱数やＩＤを接続毎に更新していくため、一時的にＩＤや乱数を取得したクローンサイトを検出することもできる。
【００１５】
また、本発明のサーバ認証方法は、前記クライアント端末が、前記被評価サーバへ前記クライアント端末が初めてアクセス要求を行った場合に、前記セキュアな通信経路を介して前記被評価サーバから前記第１のＩＤを受信するステップと、前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバへ前記第１のＩＤに対応する前記第１の乱数を送信するステップとを有する。
【００１６】
この方法により、被評価サーバとクライアント端末との初回接続時に、クライアント端末がＩＤを、被評価サーバが乱数を保持しておくことが可能である。
【００１７】
また、本発明のサーバ認証方法は、前記被評価サーバが、コンテンツ記憶部に記憶されたコンテンツの種別毎にハッシュ値を算出するステップと、前記被評価サーバが、算出したハッシュ値に前記被評価サーバの公開鍵に基づく署名を計算して前記コンテンツとともに送信するステップと、前記クライアント端末が、署名及びコンテンツを受信するステップと、前記クライアント端末が、受信したコンテンツのハッシュ値を算出するステップと、前記クライアント端末が、算出したハッシュ値及びあらかじめ前記公開鍵管理部に保持された公開鍵を用いて受信した署名を検証して正しい場合、受信したコンテンツをデコードするステップとを有する。
【００１８】
この方法により、改竄サイトを検出することができる。また、改竄サイトを検出した場合には、コンテンツのデコードを行うことがないため、クライアント端末の安全性が向上する。
【００１９】
また、本発明のサーバ認証方法は、前記クライアント端末が、前記被評価サーバから、前記被評価サーバの評価結果を保持する評価サーバを識別するための評価サーバ識別情報を取得するステップと、前記クライアント端末が、前記評価サーバ識別情報に基づいて、前記評価サーバから前記被評価サーバの評価結果を取得するステップと、前記クライアント端末が、取得した前記被評価サーバの評価結果と所定のセキュリティポリシに基づいて、前記被評価サーバへのアクセスを許可するか否かを判定するステップとを有する。
【００２０】
この方法により、有害サイトを検出することができる。具体的には、クライアント端末が独自のセキュリティポリシをあらかじめ保持し、セキュリティポリシに照らして有害サイトであるか否かを判定している。
【００２１】
また、本発明のサーバ認証方法は、前記クライアント端末が、前記被評価サーバを評価する評価端末へ、評価対象となる前記評価結果を識別するための評価結果識別情報と第３の乱数とをメール送信するステップと、前記クライアント端末が、前記評価結果及び前記評価結果識別情報を記憶する評価結果記憶部に前記第３の乱数を記憶させるステップと、前記評価端末が、前記評価結果識別情報と前記第３の乱数とをメール受信するステップと、前記評価端末が、前記評価結果識別情報に対応する前記評価結果、前記評価結果識別情報、及び、前記受信した第３の乱数のハッシュ値を算出するステップと、前記評価端末が、前記ハッシュ値を前記クライアント端末へメール送信するステップと、前記クライアント端末が、前記ハッシュ値をメール受信するステップと、前記クライアント端末が、前記評価結果記憶部に記憶された評価結果、評価結果識別情報、第３の乱数のハッシュ値を算出するステップと、前記クライアント端末が、メール受信したハッシュ値及び算出したハッシュ値が一致し、かつ、送信先メールアドレスのドメインが正当である場合、前記評価結果は正当であると判定するステップとを有する。
【００２２】
この方法により、ハッシュ値の比較や送信先メールアドレスのドメインが正当であるか否かを判定することで、被評価サーバ２００の評価結果の正当性を確認することができる。具体的には「対象となる評価結果の作成者が（ボットなどのロボットではなく）携帯電話のユーザであること」を確認している。
【００２３】
また、本発明のサーバ認証方法は、前記被評価サーバを評価する評価端末が、前記評価サーバへ前記評価結果を送信するステップを有する。
【００２４】
この方法により、評価端末が被評価サーバを評価し、その結果を評価サーバへアップロードすることで、被評価サーバと通信を行うクライアント端末が当該サーバが危険サイトであるか否かを確認するために、評価サーバから評価結果を取得することができるようになる。
【００２５】
また、本発明のサーバ認証方法は、前記評価端末が、携帯電話端末である。
【００２６】
この方法により、評価端末が信頼性の高い携帯電話端末であるため、評価結果の正当性の確認結果が信頼性の高いものとなる。
【００２７】
本発明のクライアント端末は、評価対象となる被評価サーバとの間で通信可能なクライアント端末であって、前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に被評価サーバの公開鍵を受信する公開鍵受信部と、前記セキュアな通信経路を介して前記被評価サーバに第１のＩＤを送信する送信部と、前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するＩＤ乱数受信部と、前記ＩＤ乱数受信部により受信した第１の乱数が前記送信部により送信した前記第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記公開鍵受信部により受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定する判定部と、を備え、前記送信部が、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信する。
【００２８】
この構成により、確実に危険サイト（特に成済ましサイト及びクローンサイト）を検出することが可能である。具体的には、公開鍵の一致を確認しているために、成済ましサイトを検出できる。また、被評価サーバとクライアント端末との間で通信時に用いる乱数やＩＤを接続毎に更新していくため、一時的にＩＤや乱数を取得したクローンサイトを検出することもできる。
【発明の効果】
【００２９】
本発明によれば、確実に危険サイトを検出することが可能である。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施形態のサーバ認証方法及びクライアント端末について、添付図面を参照して詳細に説明する。
【００３１】
以下に説明する各実施形態では、サーバと、サーバに管理されるサイトと、が１対１に対応しているものとする。サーバは、１つのサイトの管理を、実際には物理的なサーバ装置が１台で行ってもよいし、複数台で行ってもよい。また、実際には物理的なサーバ装置１台によって管理されるサイトが複数であっても、１つのサーバにより１つのサイトが管理されているものとする。つまり、あるサーバにアクセスすることにより、当該サーバが管理するサイトにアクセスすることになる。また、あるサーバの識別情報を指定することにより、当該サーバにより管理されるサイトの識別情報を指定することになる。また、あるサーバの評価情報は、当該サーバが管理するサイトの評価情報になる。
【００３２】
（第１の実施形態）
図１は本発明の第１の実施形態における危険サイト検出システムの構成の一例を示すブロック図である。図１に示す危険サイト検出システム１は、評価サーバ１００、被評価サーバ２００、評価クライアント端末３００、検証クライアント端末４００を有して構成される。
【００３３】
評価サーバ１００は、被評価サーバ２００の評価情報（後述）を有するサーバであり、例えばＢｌｏｇサーバである。評価サーバにより、評価サイトが管理されている。
【００３４】
被評価サーバ２００は、評価クライアント端末３００により評価されるサーバであり、例えばＢｌｏｇサーバである。被評価サーバ２００により、被評価サイトが管理されている。各実施形態では、被評価サーバ２００が評価されることは、被評価サイトが評価されることと同義である。
【００３５】
評価クライアント端末３００は、被評価サーバ２００を評価し、その結果を評価結果として評価サーバ１００へ送信する。評価クライアント端末３００は、例えば携帯電話端末である。
【００３６】
検証クライアント端末４００は、評価サーバ１００へアクセスして被評価サーバ２００の評価情報を取得し、独自のセキュリティポリシと比較することで、被評価サーバ２００へのアクセス可否を判定する。検証クライアント端末４００は、アクセス許可と判定した場合にのみ被評価サーバ２００へアクセスすることができる。検証クライアント端末４００は、例えばＰＣや携帯電話端末である。検証クライアント端末４００は、被評価サーバ２００との間で通信可能なクライアント端末の一例である。
【００３７】
次に、危険サイト検出システム１の動作の概要について説明する。
図２は危険サイト検出システム１の動作の概要を示すフローチャートである。
【００３８】
まず、評価クライアント端末３００は、被評価サーバ２００（被評価サイト）の評価処理を行う（ステップＳ１００）。評価処理の詳細については後述する。
【００３９】
続いて、評価クライアント端末３００は、被評価サーバ２００の評価処理による評価結果を評価サーバ１００へ送信する。そして、評価サーバ１００は、評価クライアント端末３００から取得した被評価サーバ２００の評価結果を保持し、評価結果を被評価サーバ２００へトラックバックする（ステップＳ２００）。トラックバックとは、評価サーバ１００が、被評価サーバ２００へ、被評価サーバ２００の評価結果を評価サーバ１００が保持していることを通知することであり、例えば被評価サーバ２００が管理する被評価サイト上に、被評価サーバ２００の評価情報へのリンクを生成する。トラックバック技術は一般的なＢｌｏｇサーバには搭載されている。
【００４０】
続いて、検証クライアント端末４００は、被評価サーバ２００へアクセスし、不正サイト検出処理を行う（ステップＳ３００）。不正サイト検出処理の詳細については、後述する。不正サイト検出処理では、例えば、被評価サーバ２００のサーバ公開鍵を評価して被評価サイトが成済ましサイト及びクローンサイトではないことをチェックしたり、被評価サーバ２００が提供するコンテンツの期待値ハッシュ（ハッシュ値）と対応する署名を検証することで改竄サイトでないことをチェックしたりする。
【００４１】
続いて、検証クライアント端末４００は、被評価サイトが不正サイトでないとき、被評価サイトから評価結果を保持する評価サーバ１００の情報（例えば評価サイトのＵＲＩなどのサイト識別情報）を取得する（ステップＳ４００）。このとき、クライアント端末にローカルにキャッシュされた公開鍵証明書やＰ２Ｐネットワーク上のキャッシュも想定する。ただし、前記キャッシュが利用できない、かつ初回接続時に限っては評価情報から公開鍵を取得する必要があるため、被評価サイトが不正サイトでないことを検証する前に被評価サイトにアクセスする必要がある。そのため、ブラウザは被評価サイトへの接続時に本システムへ接続判定を要求し、本システムが接続許可した場合にのみ被評価サイトへ接続を行う。本システムはブラウザとは別メモリ空間で動作、かつ、提案システムのメモリ空間から他メモリ空間へはアクセスできないものとする。
【００４２】
続いて、検証クライアント端末４００は、評価サーバ１００へアクセスし、評価サーバ１００が保持している被評価サーバ２００の評価結果を取得する（ステップＳ５００）。このとき、評価サーバ１００から検証クライアント端末４００自身のセキュリティポリシを満たす数の評価結果を取得する。評価結果を取得する評価サーバ１００は複数であってもよい。
【００４３】
続いて、検証クライアント端末４００は、評価サーバ１００から取得した被評価サーバ２００の評価結果と検証クライアント端末４００自身のセキュリティポリシとに基づいて、被評価サーバ２００へのアクセスを行うか否かを判定する（ステップＳ６００）。
【００４４】
続いて、検証クライアント端末４００は、被評価サーバ２００へアクセスを行うことを決定し、実際にアクセスを行った場合、アクセス結果を自身のセキュリティポリシに反映する（ステップＳ７００）。アクセス結果を検証クライアント端末４００のユーザが確認する必要があるため、検証クライアント端末４００上にＵＩにより表示する。具体的には、ユーザに被評価サーバ２００へ接続したことによる問題の有無などを確認するための情報を表示する。そして、ＵＩにより指示を行い、ユーザの意向を反映した内容をセキュリティポリシにフィードバックする。
【００４５】
危険サイト検出システム１が図２の処理を行うことで、不正サイト（成済ましサイト、クローンサイト、改竄サイト）や有害サイトなどの危険サイトを確実に検出することができる。
【００４６】
次に、危険サイト検出システム１の各構成部１００〜４００の具体的な構成について説明する。図３は被評価サーバ２００の具体的な構成の一例を示すブロック図である。図４は検証クライアント端末４００の具体的な構成の一例を示すブロック図である。図５は評価クライアント端末３００の具体的な構成の一例を示すブロック図である。
【００４７】
評価サーバ１００は、詳細について図示しないが、クライアント端末へ情報を提供するための一般的なサーバが有する構成を備えている。
【００４８】
また、被評価サーバ２００は、署名生成部２０１、ハッシュ生成部２０２、一時ＩＤ生成部２０３、乱数・一時ＩＤ管理部２０４、一意性情報生成部２０５、クライアント接続部２０６、ページ記憶部２０７、正当性情報生成部２０８、完全性情報生成部２０９とを有して構成される。
【００４９】
署名生成部２０１は、被評価サーバ２００が提供する各種コンテンツの完全性を保証するための署名情報を生成する。
【００５０】
ハッシュ生成部２０２は、被評価サーバ２００が提供する各種コンテンツについて所定のハッシュ関数により演算を行い、ハッシュ値を算出する。
【００５１】
一時ＩＤ生成部２０３は、一時ＩＤ（Ａ１、Ａ２、・・・）を生成する。
【００５２】
乱数・一時ＩＤ管理部２０４は、クライアント接続部２０６により受信した乱数（Ｂ１、Ｂ２、・・・）を保持する。また、一時ＩＤ生成部２０３により生成された一時ＩＤを保持する。
【００５３】
一意性情報生成部２０５は、検証クライアント端末４００からの一時ＩＤに対応した乱数を一意性情報として、乱数・一時ＩＤ管理部２０４から取得する。一意性情報は、クローン検出のために用いられる。
【００５４】
クライアント接続部２０６は、他のサーバや各種クライアント端末と通信を行うための通信回線の接続を行う。
【００５５】
ページ記憶部２０７は、被評価サーバ２００が提供する各種コンテンツについて所定の単位毎（例えばページ単位）に記憶する。
【００５６】
正当性情報生成部２０８は、ＳＳＬのサーバ認証に必要な情報（正当性情報）を生成する。正当性情報は、成済まし検出のために用いられる。
【００５７】
完全性情報生成部２０９は、署名が付加されたコンテンツのハッシュ値を完全性情報として生成する。完全性情報は、改竄検出のために用いられる。
【００５８】
また、検証クライアント端末４００は、公開鍵管理部４０１、乱数・一時ＩＤ管理部４０２、サイト接続部４０３、正当性検証部４０４、一意性検証部４０５、改竄検証部４０６、評価結果収集部４０７、接続判定部４０８、ハッシュ生成部４０９、結果反映部４１０、ＵＩ部４１１、ページデコード部４１２を有して構成される。
【００５９】
なお、検証クライアント端末４００のサイト接続部４０３及びページデコード部４１２（ブラウザとして機能する構成部）以外の構成部４０１〜４０２、４０４〜４１１は、独立したセキュアな空間に配置される。
【００６０】
公開鍵管理部４０１は、被評価サーバ２００が使用する公開鍵を保持し、管理する。このように、本実施形態では、被評価サーバ２００の公開鍵がローカルキャッシュに保持される。
【００６１】
乱数・一時ＩＤ管理部４０２は、乱数を生成し、保持する。また、サイト接続部４０３により受信した一時ＩＤを保持する。
【００６２】
サイト接続部４０３は、各種サーバや他のクライアント端末と通信を行うための通信回線の接続を行う。
【００６３】
正当性検証部４０４は、受信した正当性情報に基づいて、被評価サーバ２００が管理する被評価サイトが成済ましサイトであるか否かを検証する。
【００６４】
一意性検証部４０５は、受信した一意性情報に基づいて、被評価サーバ２００が管理する被評価サイトがクローンサイトであるか否かを検証する。
【００６５】
改竄検証部４０６は、受信した完全性情報に基づいて、被評価サーバ２００が管理する被評価サイトが改竄サイトであるか否かを検証する。
【００６６】
評価結果収集部４０７は、被評価サーバ２００の評価結果を保持する。評価結果収集部４０７は、複数の評価サーバ１００から取得した複数の評価結果を保持することが可能であり、同一の評価対象について多くの評価結果を保持することで、評価結果の信用が高くなる。
【００６７】
接続判定部４０８は、所定のセキュリティポリシに基づいて、接続判定を行うことで、被評価サーバ２００が管理する被評価サイトが有害サイトであるか否かを判定する。
【００６８】
ここで、セキュリティポリシには、評価ポリシ、検証ポリシ、接続ポリシが含まれる。評価ポリシには、評価結果の有効性を判断する基準となる有効期間、カテゴリ、キーワード（評価結果のコメントからカテゴリを推測するためのワードの抽出に用いられる）、評価結果の取得先の情報を含む。検証ポリシには、各検証部４０４〜４０６による検証結果の正当性を判断する基準となる有効公開鍵キャッシュ数、改竄コンテンツ、クローン検出用乱数の有効期限の情報を含む。接続ポリシには、評価結果と各検証部４０４〜４０６による検証結果とに基づいて接続判定を行うために必要な有効サンプル数の情報と接続許可閾値を含む。
【００６９】
ハッシュ生成部４０９は、被評価サーバ２００から提供された各種コンテンツについて所定のハッシュ関数により演算を行い、ハッシュ値を算出する。
【００７０】
結果反映部４１０は、接続判定部４０８による接続判定の結果に基づいて、セキュリティポリシの内容を更新する。セキュリティポリシは予め定められているものであるが、結果反映部４１０により結果を反映することで、セキュリティポリシを所望の判断基準とすることができる。
【００７１】
ＵＩ部４１１は、各種操作キーやマイクなどの入力手段やディスプレイなどの表示手段である。
【００７２】
ページデコード部４１２は、各種コンテンツに対してデコード処理（復号化処理）を行う。例えば、ＨＴＭＬのパーサー（Ｐａｒｓｅｒ）、Ｊｐｅｇのデコーダ、Ｆｌａｓｈ Ｐｌａｙｅｒなどを用いてデコード処理を行う。
【００７３】
また、評価クライアント端末３００は、サイト接続部３０１、評価結果生成部３０２、評価結果ＩＤ生成部３０３、ＵＩ部３０４を有して構成される。
【００７４】
サイト接続部３０１は、各種サーバや他のクライアント端末と通信を行うための通信回線の接続を行う。
【００７５】
評価結果生成部３０２は、被評価サーバ２００を評価し、評価結果を生成して保持する。評価結果には、評価結果ＩＤ、評価日時、被評価サーバ２００への接続可否の情報（接続許可値）、被評価サーバ２００の公開鍵証明書（公開鍵）、被評価サーバ２００のカテゴリ、被評価サーバ２００のＵＲＩ、評価クライアント端末を識別するための情報（ＰＣメールアドレスや携帯メールアドレスなど）、コメント等が含まれる。評価結果ＩＤ、評価日時、接続許可値は、評価結果に必須の情報である。
【００７６】
評価結果ＩＤ生成部３０３は、評価結果生成部３０２により生成された評価結果を識別するための識別情報としての評価結果ＩＤを生成する。生成された評価結果ＩＤは他の評価結果の情報とともに評価結果生成部３０２で保持される。
【００７７】
ＵＩ部３０４は、各種操作キーやマイクなどの入力手段やディスプレイなどの表示手段である。
【００７８】
次に、ステップＳ１００及びＳ２００における被評価サーバ２００（被評価サイト）の評価処理について詳細に説明する。
【００７９】
図６は被評価サーバ２００の評価処理の一例を示すフローチャートである。図６のステップＳ１０１〜Ｓ１０３は、図２のステップＳ１００に相当し、図６のステップＳ２０１は、図２のステップＳ２００に相当する。
【００８０】
まず、評価クライアント端末３００は、ＵＩ部３０４を介した指示により、サイト接続部３０１が、被評価サーバ２００に接続する（ステップＳ１０１）。
【００８１】
続いて、評価クライアント端末３００は、サイト接続部３０１が、被評価サーバ２００との間でＳＳＬ認証に成功した公開鍵を評価結果生成部３０２に入力する（ステップＳ１０２）。
【００８２】
続いて、評価クライアント端末３００は、評価結果生成部３０２が、被評価サーバ２００を評価し、評価結果を保持する。評価結果のうち被評価サーバ２００への接続可否の情報（接続許可値）、被評価サーバ２００のカテゴリ、コメントは評価クライアント端末３００の操作者の指示に基づいてＵＩ部３０４が入力する。（ステップＳ１０３）。
【００８３】
続いて、評価クライアント端末３００は、サイト接続部３０１が、評価結果生成部３０２に保持された評価結果を評価サーバ１００へ送信する（ステップＳ２０１）。
【００８４】
このように、評価クライアント端末３００が被評価サーバ２００（被評価サイト）を評価し、その結果を評価サーバ１００へアップロードすることで、被評価サーバ２００へアクセスする端末が当該サーバにより管理されるサイトが危険サイトであるか否かを確認するために、評価サーバ１００から評価結果を取得することができるようになる。特に、評価クライアント端末３００が携帯電話端末等の信頼性の高い端末を用いて評価しているため、第２の実施形態に示すように、評価結果は信頼性の高いものとなる。
【００８５】
次に、ステップＳ３００及びＳ７００における危険サイト検出処理（不正サイト検出処理及び有害サイト検出処理）の詳細について説明する。
【００８６】
図７及び図８は、危険サイト検出処理の一例を示すフローチャートである。図７及び図８のステップＳ３１０〜Ｓ３７０は、図２のステップＳ３００に相当する不正サイト検出処理の内容であり、図７及び図８のステップＳ６０１及びＳ７０１は、図２のステップＳ６００及びＳ７００に相当する有害サイト検出処理の内容である。図７及び図８では、主に被評価サーバ２００と検証クライアント端末４００との２回目以降接続時の動作について示している。
【００８７】
まず、検証クライアント端末４００は、ＵＩ部４１１を介した指示により、サイト接続部４０３が、被評価サーバ２００に接続する（ステップＳ３０１）。
【００８８】
続いて、被評価サーバ２００は、正当性情報生成部２０８が、クライアント接続部２０６を介して、ＳＳＬ処理を行う（ステップＳ３０２）。ＳＳＬ処理では、被評価サーバ２００の公開鍵を検証クライアント端末４００へ送信し、検証クライアント端末４００との間でＳＳＬによる通信セッションを確立する。なお、ＳＳＬによる通信セッションは、セキュアな通信経路の一例である。ステップＳ３０１〜Ｓ３０２は、既存の技術と同様の方法で実行可能である。
【００８９】
続いて、検証クライアント端末４００は、正当性検証部４０４が、公開鍵管理部４０１により保持されている前回使用された公開鍵（ただし、初回は評価結果から取得される。詳細は後述）と今回受信された公開鍵とが一致するか否かを判定する（ステップＳ３０３）。一致する、かつＳＳＬサーバ認証が成功した場合には、正当性有りと判定し、サイト接続部４０３が、乱数・一時ＩＤ管理部４０２から一時ＩＤを取得し、被評価サーバ２００に送信する（ステップＳ３０４）。
【００９０】
このように、ステップＳ３０１〜Ｓ３０３の処理を行うことで、成済ましサイトを検出することが可能である。成済ましサイトでない場合には、ステップＳ３０４において正当性有りと判定され、成済ましサイトである場合には、ステップＳ３０４において正当性なしと判定される。
【００９１】
続いて、被評価サーバ２００は、一意性情報生成部２０５が、検証クライアント端末４００からの一時ＩＤに対応した乱数を乱数・一時ＩＤ管理部２０４から取得する。そして、クライアント接続部２０６が、取得した乱数を検証クライアント端末４００へ送信する（ステップＳ３０５）。
【００９２】
続いて、検証クライアント端末４００は、一意性検証部４０５が、乱数・一時ＩＤ管理部により保持された乱数とサイト接続部４０３により受信した乱数とを比較し（ステップＳ３０６）、これらの乱数が一致した場合に一意性有りと判定する（ステップＳ３０７）。
【００９３】
このように、ステップＳ３０４〜Ｓ３０６の処理を行うことで、クローンサイトを検出することが可能である。クローンサイトでない場合には、ステップＳ３０７において一意性ありと判定され、成済ましサイトである場合には、ステップＳ３０７において一意性なしと判定される。
【００９４】
続いて、被評価サーバ２００は、ハッシュ生成部２０２が、ページ記憶部２０７により記憶されたページを取得し、取得したページについて種別毎にハッシュ値を計算する。そして、完全性情報生成部２０９が、ハッシュ生成部２０２により計算されたハッシュ値に署名生成部２０１により生成された署名を付加する。そして、クライアント接続部２０６が、署名が付加されたハッシュ値を検証クライアント端末４００へ送信する（ステップＳ３０８）。なお、本ステップの送信する前の段階まで（つまり署名を付加する段階まで）は、改竄検証を行うために事前に行われているものである。なお、上記種別とは、コンテンツ種別であり、例えばＨＴＭＬ、ＦＬＡＳＨ、ＪＰＥＧなどのコンテンツ種別である。ディジタル署名方式としてＲＳＡを利用する場合、署名生成は「公開鍵と対になる秘密鍵でハッシュ値を暗号化する」、署名の検証は「公開鍵で署名を復号して所定のハッシュ値が得る」ことを意味する。
【００９５】
続いて、検証クライアント端末４００は、ハッシュ生成部４０９が、サイト接続部４０３により受信したページ（受信ページ）についてハッシュ値を計算する。そして、改竄検証部４０６が、サイト接続部４０３により受信した署名を公開鍵管理部４０１に保持された公開鍵で検証し、正当な署名であるか否かを判定する（ステップＳ３０９）。そして、判定の結果、正当な署名である場合には、ページデコード部４１２が、受信ページをデコードする（ステップＳ３１０）。
具体的には、被評価サイトはコンテンツのハッシュ値Ａに対して公開鍵に対応した秘密鍵で署名（暗号化）してディジタル署名を計算しておき、ステップＳ３０９において検証クライアント４００は署名を公開鍵で検証（復号）してハッシュ値Ａを取得し、ステップＳ３１０において被評価サイトから取得したコンテンツから計算したハッシュ値Ａ’と前記ハッシュ値Ａを比較して一致することを確認する。
【００９６】
このように、ステップＳ３０８〜Ｓ３０９の処理を行うことで、改竄サイトを検出することが可能である。改竄サイトでない場合には、ステップＳ３１０において正当な署名であると判定され、改竄サイトである場合には、ステップＳ３１０において正当な署名であると判定される。
【００９７】
続いて、検証クライアント端末４００は、接続判定部４０８が、評価結果収集部４０７により収集された複数の評価結果を、所定の評価ポリシに基づいて集約する。評価結果に含まれる情報（被評価サーバ２００への接続可否の情報（接続許可値）、被評価サーバ２００の公開鍵証明書（公開鍵）、被評価サーバ２００のカテゴリ、被評価サーバ２００のＵＲＩ）は個々の評価結果で異なることが予想される。そのため、接続許可値など数値の場合は平均値を算出し、数値以外の公開鍵やＵＲＩやカテゴリの場合は最も多い内容を調査し、これらを最終的な評価情報として扱う。
そして、接続判定部４０８が、各検証部（正当性検証部４０４、一意性検証部４０５、及び、改竄検証部４０６）による検証結果を、所定の検証ポリシに基づいて集約する。そして、接続判定部４０８が、これらの集約結果と所定の接続ポリシに基づいて、被評価サーバ２００への接続判定を行う。つまり、接続判定部４０８が、所定のセキュリティポリシを満たしているか否かを判定する（ステップＳ７０１）。満たしている場合には、接続判定部４０８が、被評価サーバ２００への接続を許可する（ステップＳ７０２）。さらに、結果反映部４１０が、接続判定の結果を各ポリシに反映するようにしてもよい。
【００９８】
このように、ステップＳ７０１の処理を行うことで、有害サイトを検出することが可能である。有害サイトでない場合には、ステップＳ７０２において所定の各ポリシを満たし、有害サイトである場合には、ステップＳ７０２において所定の各ポリシを満たさない状態となる。
【００９９】
なお、ステップＳ３０１〜Ｓ３１０の処理後にステップＳ７０１〜Ｓ７０２の処理を行うことを説明したが、ステップＳ７０１〜Ｓ７０２の処理後にステップＳ３０１〜Ｓ３１０の処理を行ってもよい。
【０１００】
次に、図７及び図８における、被評価サーバ２００と検証クライアント端末４００との初回接続時及び２回目以降接続時のデータ（一時ＩＤ及び乱数）の流れについて、図９及び図１０を用いて説明する。図９及び図１０では、成済ましサイト検出及びクローンサイト検出に係る部分について示している。
【０１０１】
図９は初回接続時のデータの流れの一例を示すシーケンス図である。
まず、検証クライアント端末４００が、検証クライアント端末４００と被評価サーバ２００との接続要求を被評価サーバ２００へ送信する（ステップＳ１１）。
【０１０２】
続いて、被評価サーバ２００が、検証クライアント端末４００からの接続要求（ＳＳＬではＣｌｉｅｎｔ Ｈｅｌｌｏメッセージに相当）を受けて、署名付き公開鍵を検証クライアント端末４００へ送信する（ステップＳ１２）。
【０１０３】
続いて、検証クライアント端末４００が、被評価サーバ２００からの署名付き公開鍵の署名が正当であるかを検証する等の一連のＳＳＬサーバ認証処理を実行し、ＳＳＬ／ＴＬＳによるセキュアな通信セッションが確立される（ステップＳ１３）。確立後、公開鍵を保存する（ステップＳ１４）
【０１０４】
以上のステップＳ１１〜Ｓ１４は、図７のステップＳ３０１〜Ｓ３０３に相当する。
【０１０５】
続いて、セキュアな通信セッションが確立されると、被評価サーバ２００が、一時ＩＤ（Ａ１）を生成し、一時ＩＤ（Ａ１）を検証クライアント端末４００へ送信する（ステップＳ１５）。そして、検証クライアント端末４００が、一時ＩＤ（Ａ１）を保持する（ステップＳ１６）。
【０１０６】
続いて、検証クライアント端末４００が、乱数（Ｂ１）を生成し（ステップＳ１７）、乱数（Ｂ１）を被評価サーバ２００へ送信する（ステップＳ１８）。なお、２回目接続時に使用するため、検証クライアント端末４００は、生成した乱数（Ｂ１）を乱数・一時ＩＤ管理部４０２（図４参照）に保持しておく。また、被評価サーバ２００も、受信した乱数（Ｂ１）を乱数・一時ＩＤ管理部２０４に保持しておく。
【０１０７】
以上のステップＳ１５〜Ｓ１８は、図７のステップでは不図示である。
【０１０８】
図１０は２回目以降接続時のデータの流れの一例を示すシーケンス図である。
図１０の処理を開始する前に、検証クライアント端末４００は一時ＩＤ（Ａ１）及び乱数（Ｂ１’）を予め保持しているものとし、被評価サーバ２００は一時ＩＤ（Ａ１）に対応する乱数として乱数（Ｂ１）を予め保持しているものとする。
【０１０９】
まず、検証クライアント端末４００が、検証クライアント端末４００と被評価サーバ２００との接続要求を被評価サーバ２００へ送信する（ステップＳ２１）。
【０１１０】
続いて、被評価サーバ２００が、検証クライアント端末４００からの接続要求を受けて、署名付き公開鍵を検証クライアント端末４００へ送信する（ステップＳ２２）。以降、ＳＳＬ処理を行い、セキュアな通信セッションが確立される（ステップＳ２３）。
【０１１１】
続いて、検証クライアント端末４００が、事前に保持された公開鍵（例えば初回接続時に使用した公開鍵）と今回被評価サーバ２００から受信した公開鍵とを比較する（ステップＳ２４）。
【０１１２】
以上のステップＳ２１〜Ｓ２４は、図７のステップＳ３０１〜Ｓ３０３に相当する。
【０１１３】
続いて、公開鍵が一致した場合、検証クライアント端末４００が、事前に保持された一時ＩＤ（Ａ１）を被評価サーバ２００へ送信する（ステップＳ２５）。
【０１１４】
続いて、被評価サーバ２００が、検証クライアント端末４００からの一時ＩＤ（Ａ１）に対応する事前に保持された乱数（Ｂ１）を選択し、また、一時ＩＤ（Ａ２）を生成するする（ステップＳ２６）。そして、被評価サーバ２００が、乱数（Ｂ１）と一時ＩＤ（Ａ２）とを検証クライアント端末４００へ送信する（ステップＳ２７）。
【０１１５】
続いて、検証クライアント端末４００が、受信した乱数（Ｂ１）と事前に保持された乱数（Ｂ１’）とを比較する（ステップＳ２８）。比較の結果、両者が異なる場合（Ｂ１≠Ｂ１’）、被評価サイトがクローンサイトであると判定できる。
【０１１６】
続いて、検証クライアント端末４００が、保持している一時ＩＤ（Ａ１）を受信した一時ＩＤ（Ａ２）で更新し、乱数・一時ＩＤ管理部４０２に一時ＩＤ（Ａ２）を保持する（ステップＳ２９）。
【０１１７】
続いて、検証クライアント端末４００が、乱数（Ｂ２）を生成し（ステップＳ３０）、乱数（Ｂ２）を被評価サーバ２００へ送信する（ステップＳ３１）。そして、被評価サーバ２００が、保持している乱数（Ｂ１）を受信した乱数（Ｂ２）で更新し、乱数・一時ＩＤ管理部４０２に乱数（Ｂ２）を保持する（ステップＳ３２）。
【０１１８】
以上のステップＳ２５〜Ｓ３２は、図７のステップＳ３０４〜Ｓ３０７に相当する。
【０１１９】
図９及び図１０に示した初回接続時及び２回目以降接続時の危険サイト検出システム１の動作によれば、たとえ被評価サイトのクローンサイトが作成されたとしても、乱数（Ｂ）の更新前後ではクローンサイトとオリジナルサイトとの間で乱数が異なるため、クローンサイトであることを検出可能である。つまり、一時ＩＤ（Ａ）及び乱数（Ｂ）は検証クライアント端末４００が被評価サーバ２００へアクセスする度に変更されることになり、安全性が向上させることが可能である。
【０１２０】
なお、ステップＳ２３〜Ｓ２４において、検証クライアント端末４００が、公開鍵の比較の結果、一致しない場合であっても、ＳＳＬサーバ認証が成功している、かつステップＳ２８において、乱数の比較の結果、一致する場合には、被評価サーバ２００がクローンサイトではないと判定するようにしてもよい。この場合、検証クライアント端末４００は、ステップＳ２３において受信した公開鍵を新たな公開鍵として保持する。このように、危険サイト検出システム１は、一度登録された被評価サーバ２００の公開鍵を更新することもできる。但し、頻繁な公開鍵の更新は一般にはありえないため、セキュリティポリシに許容可能な更新間隔を設定できるものとし、これを下回る場合は不正な更新であるとして検証を失敗させてもよい。
【０１２１】
また、本実施形態の危険サイト検出システム１によれば、ＥＶ−ＳＳＬ、有料ソフトなどを用いないため、システム自体が低コストである。また、ＥＶ−ＳＳＬ対応サイトに対して本発明を併用する場合、更に成り済まし耐性を向上できる。
【０１２２】
（第２の実施形態）
本実施形態では、評価クライアント端末３００による被評価サーバ２００（被評価サイト）の評価結果がどの程度妥当なものであるかを確認するための処理、つまり評価結果の正当性の確認処理を行う。
【０１２３】
本実施形態の危険サイト検出システムの構成は、基本的に図１と同様であるが、評価クライアント端末及び検証クライアント端末の具体的な構成が異なっている。通常の評価クライアント端末は、第１の実施形態における評価クライアント端末３００の構成と本実施形態の評価クライアント端末３００Ｂの構成とをいずれも含むように構成される。また、通常の検証クライアント端末は、第１の実施形態における検証クライアント端末４００の構成と本実施形態の検証クライアント端末４００Ｂの構成とをいずれも含むように構成される。
【０１２４】
図１１は本実施形態の評価クライアント端末３００Ｂの具体的な構成の一例を示すブロック図である。図１２は本実施形態の検証クライアント端末４００Ｂの具体的な構成の一例を示すブロック図である。図１１及び図１２において、第１の実施形態の評価クライアント端末３００及び検証クライアント端末４００と同一の構成については、同一の符号を付し、説明を省略または簡略化する。
【０１２５】
評価クライアント端末３００Ｂは、評価結果ＤＢ３１２、評価結果検索部３１３、応答メール生成部３１４、ハッシュ生成部３１５、応答確認部３１６、メール送受信部３１７、ＵＩ部３０４を有して構成される。
【０１２６】
評価結果ＤＢ３１２は、図５の評価結果生成部３０２により保持される評価結果と同様の情報を保持する。
【０１２７】
評価結果検索部３１３は、評価結果ＤＢ３１２を参照し、１つ以上の評価結果から検索対象の評価結果を検索する。
【０１２８】
応答メール生成部３１４は、他の端末等へ送信すべきメールを生成する。
【０１２９】
ハッシュ生成部３１５は、所定の情報について所定のハッシュ関数により演算を行い、ハッシュ値を算出する。
【０１３０】
応答確認部３１６は、メール送受信部３１７により受信したメールの内容を確認し、メールの内容に応じて、評価結果検索部３１３、応答メール生成部３１４、ハッシュ生成部３１５へ制御指令を送る。
【０１３１】
メール送受信部３１７は、他の端末等からメールを受信する。また、他の端末等へメールを送信する。
【０１３２】
検証クライアント端末４００Ｂは、乱数生成部４２１、メール送受信部４２２、正当性確認部４２３、正当性確認メール生成部４２４、評価結果記憶部４２５、ハッシュ生成部４０９、ＵＩ部４１１を有して構成される。
【０１３３】
乱数生成部４２１は、乱数を生成し、保持する。
【０１３４】
メール送受信部４２２は、他の端末等からメールを受信する。また、他の端末等へメールを送信する。
【０１３５】
正当性確認部４２３は、評価結果の正当性を確認するために必要な判定を行う。例えば、生成した乱数と受信した乱数とが一致するか否かの判定や、生成したハッシュ値と受信したハッシュ値が一致する否かの判定を行う。
【０１３６】
正当性確認メール生成部４２４は、他の端末等へ送信すべきメールを生成する。
【０１３７】
評価結果記憶部４２５は、図４の評価結果収集部４０７により保持される評価結果と同様の情報を保持する。
【０１３８】
次に、評価結果の正当性の確認処理について説明する。
図１３及び図１４は被評価サーバ２００（被評価サイト）の評価結果の確認処理の一例を示すフローチャートである。なお、図１３及び図１４の処理は、通常、第１の実施形態における図２の処理と並行して定期的に実施される。また、評価結果に評価クライアント端末３００Ｂの携帯メールアドレスが含まれていない場合には、評価クライアント端末３００Ｂの所有者のＰＣメールアドレスが含まれているものとする。
【０１３９】
まず、検証クライアント端末４００Ｂは、ＵＩ部４１１を介した指示により、メール送受信部４２２が、評価結果の正当性の確認要求を送信する（ステップＳ８０１）。この確認要求は、ステップＳ８０２に示すＰＣメールアドレスへ送信する。評価クライアント端末３００Ｂとしては、携帯電話を想定する。携帯電話はＰＣメールアドレスへ送信されたメールを受信することも可能である。なお、ステップＳ８０１の処理は次のステップＳ８０２の処理とまとめて行ってもよい。
【０１４０】
続いて、検証クライアント端末４００Ｂは、乱数生成部４２１が、乱数を生成する。また、正当性確認メール生成部４２４が、ＵＩ部４１１を介した指示により、評価結果記憶部４２５により記憶された正当性の確認を希望する評価結果の評価結果ＩＤを取得する。そして、正当性確認メール生成部４２４が、生成された乱数、取得した評価結果ＩＤの情報を含むメールを生成する。そして、メール送受信部４２２が、評価結果記憶部４２５により記憶された評価クライアント端末３００Ｂの識別情報（ここではＰＣメールアドレスを想定）を取得し、生成されたメールを取得したＰＣメールアドレスへ送信する（ステップＳ８０２）。
【０１４１】
続いて、評価クライアント端末３００Ｂは、メール送受信部３１７により検証クライアント端末４００Ｂからのメールを受信する。そして、応答確認部３１６が、当該メールの内容を確認する。そして、ＵＩ部３０４が、当該メールに対して応答するか否かを指定するための情報を提示する（ステップＳ８０３）。そして、ＵＩ部４１１が、応答するか否かを指定する（ステップＳ８０４）。
【０１４２】
続いて、評価クライアント端末３００Ｂは、応答メール生成部３１４が、受信した検証クライアント端末４００Ｂからの乱数と、図示しない記憶部に保持された評価クライアント端末３００Ｂの携帯メールアドレスと、を含む応答メールを生成する。そして、メール送受信部３１７が、生成された応答メールを検証クライアント端末４００Ｂへ送信する（ステップＳ８０５）。
【０１４３】
ステップＳ８０１〜Ｓ８０５の処理によれば、評価クライアント端末が使用する携帯メールアドレスを評価結果に含めてＩｎｔｅｒｎｅｔ全体に公開したくない場合であっても（評価結果に携帯メールアドレスが含まれていない場合であっても）、検証クライアント端末４００Ｂに当該携帯メールアドレスを知らせることができる。さらに、評価結果に携帯メールアドレスが含まれている場合には、ステップＳ８０２〜Ｓ８０６の処理を省略可能である。
【０１４４】
続いて、検証クライアント端末４００Ｂは、正当性確認部４２３が、乱数生成部４２１で生成した乱数とメール送受信部４２２により受信した応答メールに含まれる乱数とが一致するか否かを判定する（ステップＳ８０６）。一致した場合、評価クライアント端末からのＰＣメールのＦｒｏｍ行が改竄されていた場合であっても、ステップＳ８０２のメール送信先とステップＳ８０５の応答メールの送信元との一致を乱数により検証可能である為、評価情報に含まれるＰＣメールアドレスから携帯メールアドレスが送られたことを把握することができる。次に、正当性確認部４２３は、携帯メールアドレスのドメインが正当であるか否か（つまり、携帯メールアドレスのドメインが正当な携帯電話会社を示すものであり、信頼できるものであるか否か）を判定する（ステップＳ８０７）。正当である場合、メール送受信部４２２が、乱数と評価結果ＩＤとを含むメールを、受信した応答メールに含まれる携帯メールアドレスへ送信する（ステップＳ８０８）。なお、ステップＳ８０８において送信される乱数と評価結果ＩＤは、ステップＳ８０２において送信されたものと同様である。
【０１４５】
続いて、評価クライアント端末３００Ｂは、検証クライアント端末４００Ｂからのメールを受信する。そして、応答確認部３１６が、当該メールの内容を確認する。そして、評価結果検索部３１３が、受信した評価結果ＩＤをキーとして評価結果ＤＢ３１２から評価結果を取得する。そして、ハッシュ生成部３１５が、評価結果、評価結果ＩＤ、乱数（検証クライアント端末４００Ｂからの乱数）、被評価サーバ２００の識別情報（例えば被評価サイトのＵＲＩなどのサイト識別情報）のハッシュ値を生成する。そして、応答メール生成部３１４が、ハッシュ値の情報を含む応答メールを生成し、メール送受信部３１７が、当該応答メールを検証クライアント端末４００Ｂへ送信する（ステップＳ８０９）。
【０１４６】
続いて、検証クライアント端末４００Ｂは、ハッシュ生成部４０９が、自端末に保持している評価結果、評価結果ＩＤ、乱数、被評価サーバ２００の識別情報（例えば被評価サイトのＵＲＩなどのサイト識別情報）のハッシュ値を生成する（ステップＳ８１０）。そして、正当性確認部４２３が、ハッシュ生成部４０９により生成されたハッシュ値とメール送受信部４２２により受信された応答メールに含まれるハッシュ値とが一致するか否かを判定する（ステップＳ８１１）。一致する場合、正当性確認部４２３が、評価結果は正当性ありと判断する（ステップＳ８１２）。評価クライアント端末からの携帯電話メールのＦｒｏｍ行が改竄されていた場合であっても、ステップＳ８０８のメール送信先とステップＳ８０９の応答メールの送信元との一致を乱数により検証可能である為、送信した先の携帯電話から応答があったことを把握することができる。
【０１４７】
このように、本実施形態の危険サイト検出システムによれば、被評価サーバ２００（被評価サイト）の評価結果の正当性を確認することができる。また、本実施形態では、評価クライアント端末３００Ｂとして携帯電話端末を想定している。携帯電話端末の購入時には身分証明書等の提示が必要であるため、信頼性が高い。また、携帯電話端末は、所有者が常に持ち歩き摺る可能性が高く、ＧＰＳ機能等により移動の有無を検証可能であり、さらにＰＩＮや指紋認証により実際の使用者を認証可能である。したがって、評価クライアント端末３００Ｂとして携帯電話端末を使用することで、評価結果が、ボット等により不正に公開されたものまたは自動的に改竄されて正当でなくなったものではなく、人間の指示により正当に評価されたものとして信頼可能なものとなる。
なお、検証クライアント端末４００Ｂからの評価結果の確認メールは、ＵＩ部４１１を介さずセキュリティポリシに従って自動で発信しても構わない。同様に確認メールに対応する応答メールは、ＵＩ部４１１を介さずセキュリティポリシに従って自動で応答して構わない。但し、安全性を担保するため応答メールに関しては評価者の利便性を損なわない範囲で一定の割合でＵＩ部４１１を介す実装とすることが望ましい。
【産業上の利用可能性】
【０１４８】
本発明は、確実に危険サイトを検出可能なサーバ認証方法、クライアント端末、危険サイト検出システム等に有用である。
【図面の簡単な説明】
【０１４９】
【図１】本発明の実施形態における危険サイト検出システムの構成の一例を示すブロック図
【図２】本発明の第１の実施形態における危険サイト検出システムの動作の概要を示すフローチャート
【図３】本発明の第１の実施形態における被評価サーバの具体的な構成の一例を示すブロック図
【図４】本発明の第１の実施形態における検証クライアント端末の具体的な構成の一例を示すブロック図
【図５】本発明の第１の実施形態における評価クライアント端末の具体的な構成の一例を示すブロック図
【図６】本発明の第１の実施形態における被評価サーバの評価処理の一例を示すフローチャート
【図７】本発明の第１の実施形態における危険サイト検出処理の一例を示すフローチャート
【図８】本発明の第１の実施形態における危険サイト検出処理の一例を示すフローチャート
【図９】本発明の第１の実施形態における被評価サーバと検証クライアント端末との初回接続時のデータの流れの一例を示すシーケンス
【図１０】本発明の第１の実施形態における被評価サーバと検証クライアント端末との２回目以降接続時のデータの流れの一例を示すシーケンス
【図１１】本発明の第２の実施形態における評価クライアント端末の具体的な構成の一例を示すブロック図
【図１２】本発明の第２の実施形態における検証クライアント端末の具体的な構成の一例を示すブロック図
【図１３】本発明の第２の実施形態における評価結果の確認処理の一例を示すフローチャート
【図１４】本発明の第２の実施形態における評価結果の確認処理の一例を示すフローチャート
【符号の説明】
【０１５０】
１ 危険サイト検出システム
１００ 評価サーバ
２００ 被評価サーバ
２０１ 署名生成部
２０２ ハッシュ生成部
２０３ 一時ＩＤ生成部
２０４ 乱数・一時ＩＤ管理部
２０５ 一意性情報生成部
２０６ クライアント接続部
２０７ ページ記憶部
２０８ 正当性情報生成部
２０９ 完全性情報生成部
３００、３００Ｂ 評価クライアント端末
３０１ サイト接続部
３０２ 評価結果生成部
３０３ 評価結果ＩＤ生成部
３０４ ＵＩ部
３１２ 評価結果ＩＤ
３１３ 評価結果検索部
３１４ 応答メール生成部
３１５ ハッシュ生成部
３１６ 応答確認部
３１７ メール送受信部
４００、４００Ｂ 検証クライアント端末
４０１ 公開鍵管理部
４０２ 乱数・一時ＩＤ管理部
４０３ サイト接続部
４０４ 正当性検証部
４０５ 一意性検証部
４０６ 改竄検証部
４０７ 評価結果収集部
４０８ 接続判定部
４０９ ハッシュ生成部
４１０ 結果反映部
４１１ ＵＩ部
４１２ ページデコード部
４２１ 乱数生成部
４２２ メール送受信部
４２３ 正当性確認部
４２４ 正当性確認メール生成部
４２５ 評価結果記憶部
【特許請求の範囲】
【請求項１】
評価対象となる被評価サーバ及び前記被評価サーバとの間で通信可能なクライアント端末を有する通信システムにおけるサーバ認証方法であって、
前記クライアント端末が、前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に前記被評価サーバの公開鍵を受信するステップと、
前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバに第１のＩＤを送信するステップと、
前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するステップと、
前記クライアント端末が、前記受信した第１の乱数が前記送信した第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定するステップと、
前記クライアント端末が、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信するステップと
を有するサーバ認証方法。
【請求項２】
請求項１に記載のサーバ認証方法であって、更に、
前記クライアント端末が、前記被評価サーバへ前記クライアント端末が初めてアクセス要求を行った場合に、前記セキュアな通信経路を介して前記被評価サーバから前記第１のＩＤを受信するステップと、
前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバへ前記第１のＩＤに対応する前記第１の乱数を送信するステップと
を有するサーバ認証方法。
【請求項３】
請求項１または２に記載のサーバ認証方法であって、更に、
前記被評価サーバが、コンテンツ記憶部に記憶されたコンテンツの種別毎にハッシュ値を算出するステップと、
前記被評価サーバが、算出したハッシュ値に前記被評価サーバの公開鍵に基づく署名を計算して前記コンテンツとともに送信するステップと、
前記クライアント端末が、署名及びコンテンツを受信するステップと、
前記クライアント端末が、受信したコンテンツのハッシュ値を算出するステップと、
前記クライアント端末が、算出したハッシュ値及びあらかじめ前記公開鍵管理部に保持された公開鍵を用いて受信した署名を検証して正しい場合、受信したコンテンツをデコードするステップと
を有するサーバ認証方法。
【請求項４】
請求項１ないし３のいずれか１項に記載のサーバ認証方法であって、更に、
前記クライアント端末が、前記被評価サーバから、前記被評価サーバの評価結果を保持する評価サーバを識別するための評価サーバ識別情報を取得するステップと、
前記クライアント端末が、前記評価サーバ識別情報に基づいて、前記評価サーバから前記被評価サーバの評価結果を取得するステップと、
前記クライアント端末が、取得した前記被評価サーバの評価結果と所定のセキュリティポリシに基づいて、前記被評価サーバへのアクセスを許可するか否かを判定するステップと
を有するサーバ認証方法。
【請求項５】
請求項１ないし４のいずれか１項に記載のサーバ認証方法であって、更に、
前記クライアント端末が、前記被評価サーバを評価する評価端末へ、評価対象となる前記評価結果を識別するための評価結果識別情報と第３の乱数とをメール送信するステップと、
前記クライアント端末が、前記評価結果及び前記評価結果識別情報を記憶する評価結果記憶部に前記第３の乱数を記憶させるステップと、
前記評価端末が、前記評価結果識別情報と前記第３の乱数とをメール受信するステップと、
前記評価端末が、前記評価結果識別情報に対応する前記評価結果、前記評価結果識別情報、及び、前記受信した第３の乱数のハッシュ値を算出するステップと、
前記評価端末が、前記ハッシュ値を前記クライアント端末へメール送信するステップと、
前記クライアント端末が、前記ハッシュ値をメール受信するステップと、
前記クライアント端末が、前記評価結果記憶部に記憶された評価結果、評価結果識別情報、第３の乱数のハッシュ値を算出するステップと、
前記クライアント端末が、メール受信したハッシュ値及び算出したハッシュ値が一致し、かつ、送信先メールアドレスのドメインが正当である場合、前記評価結果は正当であると判定するステップと
を有するサーバ認証方法。
【請求項６】
請求項５に記載のサーバ認証方法であって、更に、
前記被評価サーバを評価する評価端末が、前記評価サーバへ前記評価結果を送信するステップを有するサーバ認証方法。
【請求項７】
請求項５または６に記載のサーバ認証方法であって、
前記評価端末は、携帯電話端末である
サーバ認証方法。
【請求項８】
評価対象となる被評価サーバとの間で通信可能なクライアント端末であって、
前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に被評価サーバの公開鍵を受信する公開鍵受信部と、
前記セキュアな通信経路を介して前記被評価サーバに第１のＩＤを送信する送信部と、
前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するＩＤ乱数受信部と、
前記ＩＤ乱数受信部により受信した第１の乱数が前記送信部により送信した前記第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記公開鍵受信部により受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定する判定部と、
を備え、
前記送信部は、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信する
クライアント端末。
【請求項１】
評価対象となる被評価サーバ及び前記被評価サーバとの間で通信可能なクライアント端末を有する通信システムにおけるサーバ認証方法であって、
前記クライアント端末が、前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に前記被評価サーバの公開鍵を受信するステップと、
前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバに第１のＩＤを送信するステップと、
前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するステップと、
前記クライアント端末が、前記受信した第１の乱数が前記送信した第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定するステップと、
前記クライアント端末が、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信するステップと
を有するサーバ認証方法。
【請求項２】
請求項１に記載のサーバ認証方法であって、更に、
前記クライアント端末が、前記被評価サーバへ前記クライアント端末が初めてアクセス要求を行った場合に、前記セキュアな通信経路を介して前記被評価サーバから前記第１のＩＤを受信するステップと、
前記クライアント端末が、前記セキュアな通信経路を介して前記被評価サーバへ前記第１のＩＤに対応する前記第１の乱数を送信するステップと
を有するサーバ認証方法。
【請求項３】
請求項１または２に記載のサーバ認証方法であって、更に、
前記被評価サーバが、コンテンツ記憶部に記憶されたコンテンツの種別毎にハッシュ値を算出するステップと、
前記被評価サーバが、算出したハッシュ値に前記被評価サーバの公開鍵に基づく署名を計算して前記コンテンツとともに送信するステップと、
前記クライアント端末が、署名及びコンテンツを受信するステップと、
前記クライアント端末が、受信したコンテンツのハッシュ値を算出するステップと、
前記クライアント端末が、算出したハッシュ値及びあらかじめ前記公開鍵管理部に保持された公開鍵を用いて受信した署名を検証して正しい場合、受信したコンテンツをデコードするステップと
を有するサーバ認証方法。
【請求項４】
請求項１ないし３のいずれか１項に記載のサーバ認証方法であって、更に、
前記クライアント端末が、前記被評価サーバから、前記被評価サーバの評価結果を保持する評価サーバを識別するための評価サーバ識別情報を取得するステップと、
前記クライアント端末が、前記評価サーバ識別情報に基づいて、前記評価サーバから前記被評価サーバの評価結果を取得するステップと、
前記クライアント端末が、取得した前記被評価サーバの評価結果と所定のセキュリティポリシに基づいて、前記被評価サーバへのアクセスを許可するか否かを判定するステップと
を有するサーバ認証方法。
【請求項５】
請求項１ないし４のいずれか１項に記載のサーバ認証方法であって、更に、
前記クライアント端末が、前記被評価サーバを評価する評価端末へ、評価対象となる前記評価結果を識別するための評価結果識別情報と第３の乱数とをメール送信するステップと、
前記クライアント端末が、前記評価結果及び前記評価結果識別情報を記憶する評価結果記憶部に前記第３の乱数を記憶させるステップと、
前記評価端末が、前記評価結果識別情報と前記第３の乱数とをメール受信するステップと、
前記評価端末が、前記評価結果識別情報に対応する前記評価結果、前記評価結果識別情報、及び、前記受信した第３の乱数のハッシュ値を算出するステップと、
前記評価端末が、前記ハッシュ値を前記クライアント端末へメール送信するステップと、
前記クライアント端末が、前記ハッシュ値をメール受信するステップと、
前記クライアント端末が、前記評価結果記憶部に記憶された評価結果、評価結果識別情報、第３の乱数のハッシュ値を算出するステップと、
前記クライアント端末が、メール受信したハッシュ値及び算出したハッシュ値が一致し、かつ、送信先メールアドレスのドメインが正当である場合、前記評価結果は正当であると判定するステップと
を有するサーバ認証方法。
【請求項６】
請求項５に記載のサーバ認証方法であって、更に、
前記被評価サーバを評価する評価端末が、前記評価サーバへ前記評価結果を送信するステップを有するサーバ認証方法。
【請求項７】
請求項５または６に記載のサーバ認証方法であって、
前記評価端末は、携帯電話端末である
サーバ認証方法。
【請求項８】
評価対象となる被評価サーバとの間で通信可能なクライアント端末であって、
前記被評価サーバとの間でセキュアな通信経路を確立し、確立時に被評価サーバの公開鍵を受信する公開鍵受信部と、
前記セキュアな通信経路を介して前記被評価サーバに第１のＩＤを送信する送信部と、
前記セキュアな通信経路を介して前記被評価サーバから第２のＩＤ及び第１の乱数を受信するＩＤ乱数受信部と、
前記ＩＤ乱数受信部により受信した第１の乱数が前記送信部により送信した前記第１のＩＤに対応し、かつ、あらかじめ公開鍵を管理する公開鍵管理部に保持された公開鍵と前記公開鍵受信部により受信した公開鍵とが一致する場合、前記被評価サーバは正当であると判定する判定部と、
を備え、
前記送信部は、前記被評価サーバが正当であると判定した場合、前記セキュアな通信経路を介して前記被評価サーバに前記第２のＩＤに対応する第２の乱数を送信する
クライアント端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１０−１６５２３１（Ｐ２０１０−１６５２３１Ａ）
【公開日】平成２２年７月２９日（２０１０．７．２９）
【国際特許分類】
【出願番号】特願２００９−７７２３（Ｐ２００９−７７２３）
【出願日】平成２１年１月１６日（２００９．１．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２２年７月２９日（２０１０．７．２９）
【国際特許分類】
【出願日】平成２１年１月１６日（２００９．１．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]