JP4283250B2 - フィッシング詐欺防止のためのメール検証システム - Google Patents

Description

本発明は、フィッシング詐欺防止システムに関し、特に、フィッシング詐欺防止システムのためのメール検証システムに関するものである。

近年各企業は、商工会議所等公的機関が真正なＨＰであることを証明するため各種安全マークをＨＰ上に貼り付ける等、ＨＰのなりすまし防止に努めている。さらに、国内で多発化が予想されるフィシング詐欺防止のために一部企業において、その防止対策として自社発信メール全てに企業認証証明書を添付し送信する企業も現れた（２００４年１１月３０日 産経新聞 朝刊）。 いずれの手段も防止という目的においては、詐欺者に対し一応警戒を促すことになるが安全マークを誰もが知っているかというと疑問であり、企業認証においても同様である。さらに、詐欺団は、技術的にも長けており、これらのマークや証明書を巧妙にまねすることを得意としている。したがって、この手段では、防止できないのが現状である。 前記以外の代表的なフィッシング詐欺防止手段について述べれば、米国テキサス州オースティンに本社を置くインターネットセキュリティ対策企業（Ｗｈｏｌｅ Ｓｅｃｕｒｉｔｙ）は、フィッシング詐欺防止プログラムを発表した。 公開記事によれば、該プログラムは、Ｗｅｂアドレスを分析し、詐欺サイトにつながる可能性のあるＵＲＬやドメイン名が最近登録されたもの、運営者が無償のＷｅｂホスティングサービスを利用しているなどといった疑わしいＵＲＬをプログラムに内蔵することで、ユーザが疑わしいＨＰを訪問する都度警告を表示するソフトウェアが開発されている。（Ａｌｏｒｉｅ Ｇｉｌｂｅｒｔ （ＣＮＥＴ Ｎｅｗｓ．Ｃｏｍ） ２００４／０８／１８ ＣＮＥＴ Ｊａｐａｎ 記事とり）
また、インターネットに関する調査や評価サービスを手がけるＮｅｔｃｒａｆｔ社は、先ごろフィッシング詐欺対策ツールバー「ＮｅｔｃｒａｆｔＴｏｏｌｂａｒ」を公開した。 同ツールバーはＭｉｃｒｏｓｏｆｔ の Ｗｅｂ ブラウザ「Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ」で動作し、フィッシング詐欺の疑いがあるサイトに重要情報を渡すことを防ぐため、そのようなサイトの ＵＲＬ について警告するものだ（Ｙａｈｏｏ コンピュータニュース ２００５年１月６日）。
ＰｈｉｓｈＤｅｔｅｃｔ社は、ＳＳＬサーバ証明書（企業のＷｅｂサイト実在証明）やＵＲＬスプーフィング・ディテクトを提供し、偽Ｗｅｂサイトの判別をしやすくする方法、メールが改ざんされていないことを確認する手段が提供されている。
セキュアブレインのＰｈｉｓｈＷａｌｌはサーバ用ソフトとクライアント用ソフトから成る。 クライアント側にソフトをインストールすると，ＰｈｉｓｈＷａｌｌ対応サーバのデータベースをセキュアブレインが運営するサーバからダウンロードする。 クライアント用ソフトはＷｅｂサーバにアクセスする度にＰｈｉｓｈＷａｌｌ対応かどうかを、データベースを参照してチェックし，対応しているサーバの場合は画面上で通知する。 ユーザがクライアント・ソフトにＷｅｂサーバの登録を指示すると，Ｗｅｂサーバから登録証明書を取得する。次回のアクセスから，この証明書を使って偽装サイトでないかを確認する。 クライアント・ソフトは，Ｗｅｂブラウザ（１．０版ではＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒのみ）にツールバーを加える。 ツールバーには，サイトの安全性を三つの色で表示する部分，Ｗｅｂサイトのドメイン情報を表示する部分，ドメイン名の国情報を国旗で表示する部分がある。安全性を判別する三つの色は，赤が登録情報に合致しないサイト，黄色がＰｈｉｓｈＷａｌｌ対応だが未登録のサイト，青がＰｈｉｓｈＷａｌｌ対応で登録済みの正しいサイトであることを示す。サーバがＰｈｉｓｈＷａｌｌに対応していない場合は色の表示がないため，ドメイン情報や国旗を基にユーザが判断することになる(日経ＢＹＴＥ・２００４／１１／２４ 記事より)。その他、怪しいと思われるサイト（いわゆる黒、グレーの情報を辞書化したものと思える。）を判定するデータベースやソフトに特徴がある。

しかし、前記においては、クライアント側から登録を指示が基本であることから、本人確認が不十分であり本発明の課題を解決できてない。又、対策事例であるが企業から顧客に対し各種証明書やデジタル署名等有償のものを都度メールに添付しているが、費用的にコストがかかり、運用も面倒になっている。
いずれにしても、前記ソフト手段は画期的な防止手段となっていない。 なぜならば、確実に存在している真正な企業であっても、場合によっては疑わしい企業と誤認することを防げない。 本来、疑わしい企業がクライアントから登録される危険性もある。 ＳＳＬサーバ証明書は、一つの手段であるが、はたして運用できるのか、このサーバ証明書が真正であることを、あらゆるネット利用者にどう告知するのか、偽証明書をどう見抜くのか、証明書が改ざんされていないことを確認できるのは、ユーザが事前に具体的に中身を知っていて始めて可能であって、はじめての顧客に対してどう対応するのか課題は山積している。
フィッシング詐欺と共に最近新たにファーミング詐欺が登場した。 このファーミング詐欺は、大勢のユーザをまとめて刈り取ろうとしているネット詐欺の手口である。ファーミング詐欺の手口の概要は、可能な限り多くのユーザを、本来訪れようとしている真正のウェブサイトから、悪意あるウェブサイトへ自動的に導くというものである。このファーミング詐欺においては、ユーザが知らぬ間に偽サイトに誘導され、この誘導される偽サイトは、見た目は、一見本物のサイトと変わらない。だが、これに気づかないで、ユーザが自分の口座番号や暗証番号を入力すると、その情報はサイバー詐欺師たちにいつの間にか盗まれてしまう。このネット詐欺の手口 最近になり、米国から日本へ普及しだした新たなサイバー犯罪の手口である。しかし、現在のところ、これに対して、画期的対応手段が提供されていない。
ファーミング詐欺の手口は、例えば、正しいＤＮＳ情報が「４１．１．２７．２２０ｗｗｗ．ａｃｏｍ．ｃｏ．ｊｐ」であるのに、偽装されたｈｏｓｔｓファイルが、「２０２．２．３５．２１１ｗｗｗ．ａｃｏｍ．ｃｏ．ｊｐ」として変えられ、ユーザのマシンのｈｏｓｔｓファイル若しくは参照するＤＮＳサーバに、偽のドメイン情報を登録するもので、これにより、正しいサイトにアクセスしようとしても、偽サイトにアクセスさせるフィッシングの新しい手口である。

ここで、ｈｏｓｔｓファイルとは、一般に、ＴＣＰ／ＩＰを使ったネットワーク（インターネットなど）で、あるノード（ＩＰアドレスが付いている端末のこと）のＩＰアドレスと、そのノードをあらわす文字列（別名）の対応を記録したファイルです。
その効果は、ｈｏｓｔｓファイルにＩＰアドレスと名前の対応を書いておくと、ＤＮＳサーバを参照することなくＩＰアドレスが解決できる。例えば、ＬＡＮにおいていくつかのパソコンを連結し、そのうちの一つをＷｅｂサーバとするとき、ｈｏｓｔｓファイルに該ＷｅｂサーバのＩＰアドレスと名前の対応を書いておくと、ＤＮＳサーバを参照することなく名前の解決が出来る。Ｗｅｂアクセスに限らずドメイン名を使ったサーバへのアクセスはｈｏｓｔｓファイルが優先される。
従って、通常のＷｅｂ検索において、ｈｏｓｔｓファイルには一般的にはＩＰアドレスが記載されていない。 ファーミング詐欺においては、該ｈｏｓｔｓファイルに誘導先ＩＰアドレスを書き込むことで目的のサイトに誘導し端末側ユーザ情報（住所、氏名、口座番号、暗証番号、クレジット等のカード番号、生年月日等）を不正に取得しようとする。
ｈｏｓｔｓファイルは、通常は、Ｗｉｎｄｏｗｓ（登録商標）２０００／ＸＰの場合、「C:\ＷＩＮＮＴ（またはＷｉｎｄｏｗｓ(登録商標））\ｓｙｓｔｅｍ３２￥Ｄｒｉｖｅｒｓ￥ｅｔｃ．」、Ｗｉｎｄｏｗｓ(登録商標)９８の場合は「Ｃ:￥Ｗｉｎｄｏｗｓ（登録商標）」にある。Ｌｉｎｕｘ（登録商標）の場合は、一般に「／ｅｔｃ／ｈｏｓｔｓ」にあることが、技術マニュアルなどで公開されている。

しかし、ユーザのマシンも、ＤＮＳサーバもその書き換えはウィルスソフトによるものが殆どであったが最近ではＤＮＳサーバをなりすまして設定する悪質行為も発生している（２００５年５月３０日、日経産業新聞、朝刊）。書き換えを防ぐ対策はウィルスバスターなどにより採られ、アクセスに関しての対策としては、ｈｏｓｔｓファイル、ＤＮＳサーバから取得したＩＰアドレスと認証局が使うＤＮＳ情報から取得したＩＰアドレスを比較することによって判断することは可能であるが、上記したように例えば、正しいＤＮＳ情報が「４１．１．２７．２２０ｗｗｗ．ａｃｏｍ．ｃｏ．ｊｐ」であるのに、偽装されたｈｏｓｔｓファイルが、「２０２．２．３５．２１１ｗｗｗ．ａｃｏｍ．ｃｏ．ｊｐ」として変えられているときには、Ｗｅｂページにアクセスする場合に、通常は使用しているＤＮＳサーバに登録されている情報を基にＩＰアドレスを変換してアクセスするが、ｈｏｓｔｓファイルは、ＤＮＳサーバよりも先に判断されるので、ｈｏｓｔｓファイルに偽の情報が書かれていると、偽の情報が先に判断され、これに気づかないという問題を残すものであった。
なお、ここで、ＤＮＳとは、ドメイン名をＩＰアドレスに変換するための通信サービスの一つであり、コンピュータネットワークによる通信の際には人間が覚えやすいドメイン名を使用するのに対し、コンピュータは数値で表わせるＩＰアドレスを使用して通信を実行しなければならないので、ドメイン名とＩＰアドレスの対応づけが必要であり、この対応付けのため、ドメイン名とＩＰアドレスの対応づけのデータベースを登録管理し、ドメイン名のＩＰアドレスへの変換を行う通信サービスのことである。また、ＤＮＳサーバとは、ＤＮＳのプログラムとデータベースを備え、各コンピュータの要求に応えてドメイン名をＩＰアドレスに変換し、結果をコンピュータに返すサーバをいう。

また、具体的手口は、ファーミング詐欺プログラム（不正プログラム）がサーバに進入しｈｏｓｔｓファイルを書き換えたり、一時的に外部から不正侵入しｈｏｓｔｓファイルを書き換えたりする場合がある。

例えば、（１）サーバドメインに対応するＩＰアドレスの書き換えは、各種サーバドメインに対応するＩＰアドレス（ｈｔｔｐ、ｆｔｐ、ＳＭＴＰ）のｈｏｓｔｓファイル書き換えである。
ドメイン名によるｈｔｔｐアクセス時にｈｏｓｔｓファイルが書き換えられていた場合、より具体的には、「ｈｔｔｐ：／／ｗｗｗ．ｈｏｇｅ．ｈｏｇｅ．ｊｐ」にアクセスしようとしたときに、「ｗｗｗ．ｈｏｇｅ．ｈｏｇｅ．ｊｐ」がｈｏｓｔｓファイルで偽装定義されている場合であり、この場合には、偽のＷｅｂサイトにアクセスされることになり、クレジットカード番号や各種のＩＤが盗まれ。 したがって、何らかの対策をしなければ気がつきにくいという問題がある。

また、（２）ドメイン名によるｆｔｐアクセス時にｈｏｓｔｓファイルが書き換えられていた場合、より具体的には、「ｆｔｐ：／／ｆｔｐ．ｈｏｇｅ．ｈｏｇｅ．ｊｐ」にアクセスしようとしたときに、「ｆｔｐ．ｈｏｇｅ．ｈｏｇｅ．ｊｐ」がｈｏｓｔｓファイルで偽装定義されている場合であり、この場合には、偽のｆｔｐサーバにアクセスされることになり、アップロードの場合、転送したファイルが盗まれる。この場合には、ダウンロードの際に、必要なファイルがないことに気づく可能性はあるが、気づくまでは時間がかかる。また、アップロードの際に、真正のサーバにファイルがないことに気づく可能性があるが、気づくまでに時間がかかるという問題がある。

さらに、（３）ドメイン名によるメール送信時にｈｏｓｔｓファイルが書き換えられていた場合、より具体的には、メール送信しようとした場合に、指定しているＳＭＴＰサーバ、「ｓｍｔｐ．ｈｏｇｅ．ｈｏｇｅ．ｊｐ」が、ｈｏｓｔｓファイルで偽装定義されている場合であり、この場合には、送信メールが全て盗まれてしまう。この場合、メールは相手に届くと共にメールの送受信とも行なわれるので、非常に気がつきにくいという問題がある。

新聞情報（日経産業新聞２００５年５月３０日付朝刊）によれば、ブログを使い、架空請求詐欺を狙った動きが急増し、「トラックバック」機能を使い特定プログとリンクを張る手口が現れた。さらに、ドメイン名を管理するＤＮＳサーバになりすまして住所を書換え、偽サイトに導く手法も出現し、セキュリテー業界からも恐れられている。これらの現状から、早急な対応が求められている。
以上の状況から、ｈｏｓｔｓファイルを監視し書き換えられたことをいち早く検知し、該不正プログラムの存在を発見削除し、ｈｏｓｔｓファイルを復元するプログラムにより詐欺を防止する手段が待たれている。
特願２００５−１０７５４０ Ｗｉｒｅｄ Ｎｅｗｓ−正しいＵＲＬを偽サイトにつなげる「ファーミング詐欺」（上）

従って、本願発明は、正規メールと影メールとのダブルチェックにより、送付されたメールが改ざんされていない真正な本人からのメールであることを一層厳格に証明することを可能にすることである。
使用メールヘッド情報のワンタイムパスワード情報を併用することによって、他の秘密鍵、共通鍵等の手段（取引先相手ごとに鍵が発生、複数の鍵や相手ごとのプログラム管理が発生）に比べ運用が簡単となり、相手を限定することなく共通的に使用できるので汎用性に優れ、真正メールのやり取りの容易化を図ることができる。
また、メールヘッド情報ＭＨのＭｅｓｓａｇｅ−ＩＤ情報を利用するに当って、このＭｅｓｓａｇｅ−ＩＤ情報に、ワンタイムパスワード情報を併用することにより、二重三重のチェックができ、真正な相手からのメールであることの証明とその保証を一層確実にすることである。
メール本文ＭＳのハッシュ値を利用することにより、メール本文が改ざんされていないことを証明すること、真正な相手からのメールであることを重ねてチェックすることを可能とし、原文をハッシュ値化し、正規メールと影メールとの両方メールでチェックし保証されたメールの確保が可能であり、これによって、原本保証と改ざん防止手段を提供することである。
本願発明のメール検証システムによれば、ユーザが受信するメールが正規メールであることを検証し、保証されたメールを確保することができるので、フィッシング詐欺防止を一層確実に遂行することができ、先行出願に係る発明に追加するときには、フィッシング詐欺防止のための二重、三重のチェックにより、さらにフィッシング詐欺防止効果を増すことができる。

本願発明のフィッシング詐欺防止のためのメール検証装置は、（イ）ワンタイムパスワード申請を登録企業の端末からネットワークを介して受信し、このワンタイムパスワード申請に対応するワンタイムパスワードを検索情報データベースから検索し登録企業の端末にネットワークを介して発行すると共に、（ロ）登録企業の端末から「送信先ユーザアドレス」と、「Ｍｅｓｓａｇｅ−ＩＤ」と、正規メールの本文を符号化したハッシュ値と、ワンタイムパスワードと、を含むハッシュ値メールをネットワークを介して受信し、（ハ）検索情報データベースから検索するワンタイムパスワードと対になる登録企業のＳＭＴＰサーバ情報と、登録企業のＦｒｏｍアドレス情報と、「送信先ユーザアドレス」と、「Ｍｅｓｓａｇｅ−ＩＤ」と、ハッシュ値とを含む影メールを生成し、この影メールをネットワークを介して送信先ユーザアドレスに対応するユーザ端末の代理POPサーバへ送信する。

また、本願発明は、ネットワークを介して登録企業端末からユーザ端末にメールヘッダ情報としてワンタイムパスワード、Ｍｅｓｓａｇｅ−ＩＤを含む正規メールを送信する際に、（イ）ネットワークを介して認証局のコンピュータが、メールヘッダ情報としてワンタイムパスワード、符号化によりハッシュ値化した本文のメールを受信し、このメールに基づきメールヘッダ情報として前記ワンタイムパスワードと対になるキー、Ｍｅｓｓａｇｅ−ＩＤ及び符号化情報の本文を含む影メールを生成し、この影メールをユーザ端末の代理ＰＯＰサーバへ送信する手段と、（ロ）代理ＰＯＰサーバが、受信した正規メールと影メールの間で、ワンタイムパスワードチェック、本文のハッシュ値チェック、及びＭｅｓｓａｇｅ−ＩＤチェックを行い、それらが正常であればＯＫと判定する手段と、を備えることを特徴とするフィッシング詐欺防止のためのメール検証装置および検証方法を提供する。

本願発明のフィッシング詐欺防止のためのメール検証方法は、（イ）登録企業の端末により、認証局のコンピュータにワンタイムパスワードを申請して検索情報データベースから検索しその認証局のコンピュータからワンタイムパスワードを取得する工程と、（ロ）登録企業の端末からユーザ端末に、ワンタイムパスワード、Ｍｅｓｓａｇｅ−ＩＤを有する正規メールを送信するとともに、認証局のコンピュータに、正規メールの本文をハッシュ値で符号化しワンタイムパスワードを有するハッシュ値メールを送信する工程と、（ハ）認証局のコンピュータが、受信したハッシュ値メールに基づいて、ワンタイムパスワードと対になる登録企業のＳＭＴＰサーバ情報と、登録企業のＦｒｏｍアドレス情報と、Ｍｅｓｓａｇｅ−ＩＤと、ハッシュ値を有する影メールをユーザ端末に送信する工程と、（ニ）ユーザ端末が、認証局のコンピュータから所定のチェックのための検索情報データベースの情報を受信する工程と、（ホ）ユーザ端末が、認証局のコンピュータから受信した影メールと、この影メールの受信を条件に引渡され登録企業のコンピュータから受信する正規メールとを、検索情報データベースの情報によりワンタイムパスワードと、本文のハッシュ値と、Ｍｅｓｓａｇｅ−ＩＤと、登録企業のＳＭＴＰサーバ情報と、登録企業のＦｒｏｍアドレス情報のチェックを行い、すべてが正常であればユーザ端末のメーラに引き渡す工程と、を含む。

正規メールＭ１と影メールＭ３とのダブルチェックにより、送付されたメールが真正な本人からのメールであり、改ざんされていないことを、正規メールＭ１にチェックの場合より一層厳格に証明できる。
メールヘッド情報ＭＨのワンタイムパスワード情報を併用する場合には、これによって、他の秘密鍵、共通鍵等の手段（取引先相手ごとに鍵が発生、複数の鍵や相手ごとのプログラム管理が発生）に比べ運用が簡単となり、相手を限定することなく共通的に使用できるので汎用性に優れる。
また、メールヘッド情報ＭＨのＭｅｓｓａｇｅ−ＩＤ情報を利用するとき、真正な相手からのメールであることを証明するために、このＭｅｓｓａｇｅ−ＩＤ情報に、ワンタイムパスワード情報を併用する場合には、二重三重のチェックができ、さらに確実な証明が保証できる。
メール本文ＭＳのハッシュ値を利用する場合には、これにより、メール本文ＭＳが改ざんされていないことを証明すること、真正な相手からのメールであることを重ねてチェックすることができる。従って、原文をハッシュ値化し、正規メールＭ１と影メールＭ３との両方メールでチェックし保証されたメールの確保が可能であり、これによって、原本保証と改ざん防止の斬新な手段を提供する。

本願発明のメール検証システムによれば、ユーザが受信するメールが正規メールであることを検証し、保証されたメールを確保することができるので、フィッシング詐欺防止を一層確実に遂行することができ、先行出願に係る発明に追加するときには、フィッシング詐欺防止のための二重、三重のチェックにより、さらにフィッシング詐欺防止効果を増すことができる。
本出願人になるフィッシング詐欺防止システムに係る先行出願に記載の発明について、そのメール判定処理において、同様に機能アップするための追加処理として応用することも可能である。
フィッシング詐欺の一形態であるファーミング詐欺であるｈｏｓｔｓファイルの書き換えに対して、また、ｈｏｓｔｓファイルの書き換え以外に、ＤＮＳサーバに存在するドメイン名とＩＰアドレス対応テーブルのＩＰアドレスを書き換えに対しても、これらの場合にファーミング詐欺防止機能を果すことができる。

本願発明は、先行出願（特願２００５−１０７５４０）に係る発明と同様に、登録企業が認証局との間で、厳正な本人確認を行った上で、真正な登録企業のドメイン名とＩＰアドレスを対でドメイン情報として登録することを前提とした発明である。
ユーザ側で実施するチェックは、代理ＰＯＰサーバにおいて、正規メールＭ１と影メールＭ３の間で、少なくとも、ワンタイムパスワードチェックＣ１、本文のハッシュ値チェックＣ２、及びメッセージチェックＣ３を行うものとし、それらが正常であればＯＫとする判定が可能となっている。
なお、ユーザが受信しチェックする正規メール、影メールについて、ワンタイムパスワードチェックＣ１、本文のハッシュ値チェックＣ２、Ｍｅｓｓａｇｅ−ＩＤチェックＣ３の少なくとも一つチェックを実行し、それらの少なくとも一つが正常であればＯＫと判定することも可能であり、また、対比チェックされる正規メール、影メールの各ヘッダ情報について、先行出願（特願２００５−１０７５４０）に係る発明に記載された、認証局の企業ドメインセンターに登録された登録ドメイン情報としての、登録ＩＤ、パスワード、 企業名、ドメイン名（複数登録可能）、公安委員会古物商（ネットオークション含む）許認可番号、電話番号、郵便番号、住所、その他 登録に必要な情報、企業ドメイン情報登録センターのＵＲＬ等を選択することも可能である。
上記によれば、登録企業により、ユーザ宛にメールヘッダ情報を備えた正規メールＭ１を送信すると共に認証局宛てにメールヘッダ情報及び符号化によりハッシュ値化した本文を備えたメールＭ２を送信する手段と、認証局により、ユーザ宛に登録企業から送信されたメールＭ２に基づく影メールＭ３を送信する手段と、ユーザにより、代理ＰＯＰサーバが受信した前記正規メールＭ１及び影メールＭ３につき、ワンタイムパスワードチェックＣ１、本文のハッシュ値チェックＣ２、Ｍｅｓｓａｇｅ−ＩＤチェックＣ３の少なくとも一つチェックを実行し、それらの少なくとも一つが正常であればＯＫと判定するする手段とを備えたフィッシング詐欺防止のためのメール検証装置を提供することもできる。
図１から図８までは、本出願人になる先行出願に記載の発明における、そのメール判定処理において機能アップするための追加処理システムとして組み込むことのできるメール検証システムでもある。その処理は、先行出願（特願２００５−１０７５４０）に係る発明の運用処理に適用する場合には、その運用処理におけるメール判定処理前にあって、メール受信後、直ちに実行される、メール検証システムとして適用される。なお、以下説明の実施例において、１００点加点、１００点減点後の処理は、前述の先行出願に示す運用での判定に利用される。
以下、図面にしたがって、メール検証システムＶ１、Ｖ２及びＶ３を、それぞれ実施例１、実施例２、実施例３として説明する。

図１は、本発明のメール検証システムＶ１を説明するための概要図である。
メール検証システムＶ１は、登録企業１０、認証局２０及びユーザ３０の間で実施され、ユーザ３０においては、登録企業１０から直接受信され、受領する正規メールＭ１と、認証局２０を迂回して送信され、登録企業１０から間接的に受領する影メールＭ３との両者をチェックすることにより保証されたメールを確保することができるシステムである。すなわち、登録企業１０から認証局２０宛メールＭ２が送付され、このメールＭ２を認証局２０で所定の処理の施された影メールＭ３をユーザ３０が受信し、ユーザ３０は、各受信する正規メールＭ１と影メールＭ３とを、認証局２０からのチェック情報ＤＢ２１に基づいてチェックし、これによって保証されたメールを確保するものである。
さらに、そのフローを簡単に説明する。所定メールの送付に先立って、登録企業１０は認証局２０にワンタイムパスワードＭ１Ｈ３を申請（１０Ａ）し、認証局２０からワンタイムパスワードＭ１Ｈ３が発行（２０Ａ）され、これを取得する。
登録企業１０は、一方で、ユーザ３０へ正規メールＭ１を送信（１０Ｂ）し、他方で、認証局２０へ正規メールＭ１の本文をハッシュ値化した認証局宛てメールＭ２として送信（１０Ｃ）する。ここで、当該認証局宛てメールＭ２は、ワンタイムパスワードＭ１Ｈ３と、ユーザへの「Ｍｅｓｓａｇｅ−ＩＤ」Ｍ１Ｈ２と、正規メールの本文を符号化した値（ハッシュ値）Ｍ２Ｈ４を包含するハッシュ値メールＭ２である。
そこで、認証局２０は、認証局宛てメールＭ２を、ワンタイムパスワードＭ１Ｈ３と対になるキーＭ３Ｈ３を付してユーザ３０へ影メールＭ３として送付（２０Ｂ）する。このとき、認証局２０から、契約登録企業からの送信である場合には、そのワンタイムパスワードＭ１Ｈ３、Ｍｅｓｓａｇｅ−ＩＤと対になるキーＭ３Ｈ３、ハッシュ値Ｍ２Ｈ４を有した影メールＭ３が送信される。言い換えれば、影メールＭ３は、対になるキーＭ３Ｈ３、「正規メールのＭｅｓｓａｇｅ−ＩＤ」Ｍ１Ｈ２、本文の符号化情報（ハッシュ値）Ｍ２Ｈ４を付加してユーザ３０に送信される。
ユーザ３０は、登録企業１０からの正規メールＭ１の送付（１０Ｂ）を受けると共に、認証局２０からの影メールＭ３の送付（２０Ｂ）を受ける。ユーザ３０の端末３０Tは、本出願人による先行特許出願に示されるように、代理POPサーバを備えることができ、また備えていて、ユーザ３０では、送付された正規メールＭ１を受領しても、送付された正規メールＭ１と対となる情報を持つ影メールＭ３が到着するまでは、通常のメーラに引き渡すことはできないものと設定されている。
認証局２０には、検索情報データベース２１が設置され、検索情報データベース２１には、ワンタイムパスワードと対になるキーＭ３Ｈ３を検索する乱数表情報が蓄積されると共に、メール本文をハッシュ値にする関数ソフト、登録企業のSMTPとＦｒｏｍアドレス情報、認証局のSMTPとＦｒｏｍアドレス情報が蓄積されている。
ユーザ３０は、認証局２０から検索情報データベース２１の前記した乱数表情報等の情報を、USBメモリやCD−ROM又はダウンロードデータにより提供（２０C）を受け、これらの情報を蓄積情報ＤＢ２１として記録する。そこで、ユーザ３０の端末３０Tにおいて、代理POPサーバは、正規のメールＭ１と影メールＭ３との間で、ワンタイムパスワードチェックＣ１、本文ハッシュ値チェックＣ２及びＭｅｓｓａｇｅ−ＩＤチェックＣ３を実施し、それらのチェックが全て正常である場合には、OKとする処理が実施される。

図２は、本発明の実施例において登録企業１０、認証局２０及びユーザ３０の相互間で送受信される正規メールＭ１、ハッシュ値メールＭ２及び影メールＭ３の各メールの盛り込まれる具体的項目情報及びその機能を詳細に示す図である。この図２に示す、これらの正規メールＭ１、ハッシュ値メールＭ２及び影メールＭ３における各メールヘッダ情報ＭＨ及び本文情報ＭＳは、次のように構成されている。
なお、ここで「ＭＨ」はメールヘッダ情報一般を表わすものとし、以下、「ＭＨ」の「Ｍ」の次ぎの数字は対象とするメール「正規メールＭ１」「ハッシュ値メールＭ２」「影メールＭ３」の種別を、「Ｈ」の次ぎの数字は対象とする「ＭＨ」に盛り込まれる項目情報、具体的にユーザアドレスを掲載する「Ｔｏ」等の種別を示すものとする。
登録企業１０では、ユーザ３０宛て正規メールＭ１の送信と、認証局２０宛てハッシュ値メールＭ２の送信が可能となっている。
正規メールＭ１の詳細は、ユーザアドレスを掲載する「Ｔｏ」情報Ｍ１Ｈ１、ＳＭＴＰサーバが自動的に付加したユニークなＩＤを掲載する「Ｍｅｓｓａｇｅ−ＩＤ」情報Ｍ１Ｈ２、（拡張ヘッダ）認証局から発行されたワンタイムパスワードを掲載する「Ｘ−ｈｏｇｅｈｏｇｅ」情報Ｍ１Ｈ３を含むヘッダ情報Ｍ１Ｈ及びユーザへのメール内容を掲載する「本文」情報Ｍ１Ｓから構成される。
また、登録企業１０から発信する認証局２０宛てのハッシュ値メールＭ２の詳細は、認証局アドレスを掲載する「Ｔｏ」情報Ｍ２Ｈ１、ＳＭＴＰサーバが自動的に付加したユニークなＩＤを掲載する「Ｍｅｓｓａｇｅ−ＩＤ」情報Ｍ２Ｈ２（正規メールと同じ、Ｍ１Ｈ２となっている）、正規メールの本文を符号化した値（ハッシュ値）を掲載するハッシュ値情報Ｍ２Ｈ４、及び（拡張ヘッダ）認証局から発行されたワンタイムパスワードを掲載する「Ｘ−ｈｏｇｅｈｏｇｅ」情報Ｍ２Ｈ３（正規メールと同じＭ１Ｈ３となっている）から構成される。
一方、認証局２０では、受信したハッシュ値メールＭ２を基礎とする影メールＭ３の送信が可能である。影メールＭ３は、ユーザアドレスを掲載する「Ｔｏ」情報Ｍ３Ｈ１（Ｍ１Ｈ１と同じとなっている）、登録企業が出したメールの「Ｍｅｓｓａｇｅ−ＩＤ」情報Ｍ３Ｈ２（Ｍ１Ｈ２と同じとなっている）、ハッシュ値情報Ｍ３Ｈ４（Ｍ２Ｈ４と同じになっている）及びワンタイムパスワードと対になるキーを掲載する「Ｘ−ｈｏｇｅｈｏｇｅ―Ｍａｓｔｅｒ」情報Ｍ３Ｈ３から構成される。

以上、本発明装置のメール検証システムＶ１における登録企業１０、認証局２０及びユーザ３０の相互間で送受信される正規メールＭ１、ハッシュ値メールＭ２及び影メールＭ３の各メールの受発信形態及び各メールに盛り込まれる具体的項目、機能について延べてきたが、以下、図３により、メール検証システムＶ１の検証フローについて説明する。

登録企業１０は、正規メールＭ１を、そのヘッダ情報Ｍ１Ｈとして、認証局発行のワンタイムパスワード「Ｘ−ｈｏｇｅｈｏｇｅ」情報、送信先ユーザアドレスを示す「Ｔｏ」情報、認証局に登録したサーバのＳＭＴＰサーバ情報、認証局に登録したアドレスの「Ｆｒｏｍアドレス」及び「Ｍｅｓｓａｇｅ−ＩＤ」を含んで、ユーザに送信する。この登録企業１０は、また、認証局２０の登録企業ドメイン情報登録センター２１に、ヘッダ情報ＭＨとして、認証局発行のワンタイムパスワード「Ｘ−ｈｏｇｅｈｏｇｅ」情報、送信先ユーザアドレス情報、正規メールの「Ｍｅｓｓａｇｅ−ＩＤ」情報、正規メールの本文をハッシュ値にした内容、認証局に登録したサーバのＳＭＴＰサーバ情報、認証局に登録したアドレスの「Ｆｒｏｍアドレス」情報を含んで、ハッシュ値メールＭ２として送信する。
認証局２０は、その登録企業ドメイン情報センター２０Ｔにおいて、登録企業１０からのハッシュ値メールＭ２を受信すると、「登録済の登録企業か」否かを、ワンタイムパスワード、ＳＭＴＰサーバ情報、「Ｆｒｏｍアドレス」情報により、その一致性をチェック（Ｑ１０）する。
チェック（Ｑ１０）の結果一致している場合には、認証局の影メールＭ３として、影メールのヘッダ情報Ｍ３Ｈに、「Ｘ−ｈｏｇｅｈｏｇｅ」情報、送信先ユーザアドレス情報、正規メールの「Ｍｅｓｓａｇｅ−ＩＤ」情報、正規メールの本文をハッシュ値にした内容、認証局に登録したサーバのＳＭＴＰサーバ情報、認証局に登録したアドレスの「Ｆｒｏｍアドレス」情報を含んで、ユーザ３０に送信する。
チェック（Ｑ１０）の結果不一致の場合には、評価点から１００点減算する処理が実行される。
ユーザ３０は、登録企業１０から正規メールＭ１を受信し、また、ハッシュ値メールＭ２が登録済み登録企業からのメールであることの確認チェック（ＱＶ１０）を経た影メールＭ３を受信する。そこで、正規メールＭ１にワンタイムパスワードＭ１Ｈ３が有ったか否かをチェック（Ｑ１１）し、ワンタイムパスワードＭ１Ｈ３が無い場合には、通常のフィルタ処理へと回され、ワンタイムパスワードＭ１Ｈ３が有った場合には、正規メールＭ１について、次ぎの「ＳＭＴＰサーバ」、「Ｆｒｏｍアドレス」及び「登録済の登録企業か」がチェック（Ｑ１２）される。この正規メールＭ１に係るチェック（Ｑ１２）の結果、「ＮＯ」の場合には、評価点から１００点減算する。一方「ＹＥＳ」の場合には、「正規メールのワンタイムパスワードと対になるキーを含む影メールが届いたか」 対キー包含影メールＭ３受領チェック（Ｑ１３）が実行される。チェック（Ｑ１３）の結果、「ＮＯ」の場合には、影メールＭ３の着信を待つため本チェック（Ｑ１３）の開始点に戻り、「ＹＥＳ」の場合には、「影メールＭ３の、ＳＭＴＰ、Ｆｒｏｍアドレス、ワンタイムパスワード、附属Ｍｅｓｓａｇｅ−ＩＤ、ハッシュ値情報は正しいか」、影メールＭ３ヘッダ情報適否チェック（Ｑ１４）が実施される。影メールＭ３ヘッダ情報（Ｍ３Ｈ）適否チェック（Ｑ１４）の結果、「ＮＯ」の場合には、評価点から１００点減算し、一方、「ＹＥＳ」の場合には、評価点に１００点加算する処理が実行される。
以上のチェック処理経過において、評価点に１００点加算したときには、通常メーラに引渡し、「OK」のフラグを立てる。また、評価点から１００点減算したときには、メールを破棄し、偽装された登録企業に連絡する。すなわち、上記、チェック（Ｑ１０）、チェック（Ｑ１２）、チェック（Ｑ１４）において、ＮＯの場合には、評価点の減点処理で１００点減算された後、それらのメールは破棄され、また、偽装された登録企業に連絡される。これら加点減点後の処理は、前述の先行出願に示す運用での判定に利用される。

本発明のメール検証システムＶ１によれば、
（１） 正規メールＭ１と影メールＭ３とのダブルチェックを行なうので、これによって、送付されたメールが真正な本人からのメールであり、改ざんされていないことを厳格に証明できる。
（２）メールヘッド情報ＭＨのワンタイムパスワード情報を併用するので、これによって、他の秘密鍵、共通鍵等の手段（取引先相手ごとに鍵が発生、複数の鍵や相手ごとのプログラム管理が発生）に比べ運用が簡単にすることができ、どんな相手とも共通的に使用できるので汎用性に優れる。
（３）メールヘッド情報ＭＨのＭｅｓｓａｇｅ−ＩＤ情報を利用するので、これにより、真正な相手からのメールであることを証明するために、Ｍｅｓｓａｇｅ−ＩＤ情報も併用し、ワンタイムパスワード情報とも併せて、二重三重のチェックができる。
（４）メール本文ＭＳのハッシュ値を利用するので、これにより、メール本文ＭＳが改ざんされていないことを証明すること、真正な相手からのメールであることを重ねてチェックする方法を採用することができる。従って、原文をハッシュ値化し、正規メールＭ１と影メールＭ３との両方メールでチェックするものであり、斬新な手段である。

図４は、本発明のメール検証システムＶ２を説明するための概要図である。
メール検証システムＶ２においては、登録企業１０、認証局２０及びユーザ３０の間でメールの遣り取りが実施される。ここで、認証局２０には、そのデータベース２１にＭｅｓｓａｇｅ−ＩＤ情報を登録する登録企業ドメイン情報センター２０Ｔが設置されている。
登録企業１０、認証局２０及びユーザ３０の間でメールの遣り取りの概要を述べれば次ぎのとおりである。
メールを送信する登録企業１０は、ユーザへのメール発信の都度、登録企業１０から認証局２０へ、ＩＤパスワードにより一旦ｌｏｇｉｎし、所定の送信フォームに従ってメールを作成し、送信し、また、認証局２０の登録企業ドメイン情報センター２０ＴにＭｅｓｓａｇｅ−ＩＤを登録する。
認証局２０では、認証局チェックアドレスを「Ｒｅｐｌｙ−Ｔｏ」情報に含めたメールをユーザ３０に送信する。
当該メールを受信するユーザ３０では、メールフィルターは認定局ＳＭＴＰから送信されるメールを特例的に許可するものとして構成されている。
ユーザ３０は、「Ｒｅｐｌｙ−Ｔｏ」情報の参照を付して、認証局２０に返信する。受信した認証局２０は、メールヘッダ情報Ｍ４Ｈを検証し、ヘッド情報Ｍ４Ｈをチェックし、正規メールＭ４か否か、そのチェック結果をユーザ３０に返信する。その際、不正な場合も告知する。
ヘッド情報Ｍ４Ｈのチェックにおいては、認証局２０のＳＭＴＰサーバからのメールＭ４に添付されているＭｅｓｓａｇｅ−ＩＤと、受信後認証局からゲットできる該メールのＭｅｓｓａｇｅ−ＩＤとの同一性チェックを行なう。具体的には、ユーザ３０が返信したメールＭ５のヘッダの「Ｉｎ−Ｒｅｐｌｙ−Ｔｏ」もしくは「Ｒｅｆｅｒｅｎｃｅｓ」の情報（認証局２０のＳＭＴＰサーバからのメールヘッダのＭｅｓｓａｇｅ−ＩＤ）と、認証局２０のＤＢに登録されているユーザに送信したメールＭ４の「Ｍｅｓｓａｇｅ−ＩＤ」の同一性のチェックである。もちろん認証局２０でのチェックも同様な効果を意図したものである。

図５は、メール検証システムの第２実施例Ｖ２の検証フローを示す図である。
図５では省略されているが、登録企業と認証局の間には、登録企業から予め認証局に申請し、ドメイン名とＩＰアドレスを対として登記され、登録企業はこれらの登録ドメイン名とＩＰアドレスを受領している。
送信登録企業１０がメールＭ４作成のために認証局サーバへ、必要なＩＤとパスワードを賦与の下に、ｌｏｇｉｎする。これを受けて、認証局サーバは、送信フォームにより、ヘッダ情報Ｍ４Ｈとして、送信先ユーザアドレスの「Ｔｏ」情報Ｍ４Ｈ１、認証局のSMTPサーバを示す「SMTPサーバ」情報Ｍ４Ｈ２、登録企業の送信アドレスを示す「Ｆｒｏｍアドレス」情報Ｍ４Ｈ３、Ｍｅｓｓａｇｅ−ＩＤ情報Ｍ４Ｈ４、及び認証局チェックアドレスを示す「Reply-To」情報Ｍ４Ｈ５を含んで、ユーザに送信する。また、認証局では、このユーザに送信する正規メールＭ４の「Ｍｅｓｓａｇｅ−ＩＤ」Ｍ４Ｈ４及び「メール本文」Ｍ４Ｓが、認証局２０の登録企業ドメイン情報登録センター２１に、データベースとして登録される。データベースは正規メールＭ４ＤＢ、Ｍｅｓｓａｇｅ−ＩＤ情報Ｍ４Ｈ４、本文情報Ｍ４Ｓを内容とするもので、「検証用ＷｅｂｐａｇｅＭｅｓｓａｇｅ−ＩＤ本文」情報ＭＶが含まれるものである。
登録企業１０からの正規メールＭ４の送信を受けてユーザ３０が受信すると、「認証局のSMTPサーバからの送信か」が送信元チェック（ＱＶ２１）される。送信元チェック（ＱＶ２１）の結果、「ＹＥＳ」の場合には、次ぎの「メールの検証が必要か」を判定するメール検証の必要性チェック（ＱＮ２２）が実施される。また、「ＮＯ」である場合には、先行特許出願に示す運用処理でのメール判定処理へと進められる。
前述のメール検証の必要性チェック（ＱＶ２２）の結果、「ＮＯ」の場合には、通常メーラに引渡しOKのフラグを立てる。一方、「ＹＥＳ」の場合には、確認メールＭ５を認証局２０へ送信し、その際、確認メールのヘッダ情報Ｍ５Ｈとして、認証局チェックアドレスを示す「Ｔｏ」情報Ｍ５Ｈ１及び登録企業からのメールのＭｅｓｓａｇｅ−ＩＤを示す「in-Reply-To」情報Ｍ５Ｈ２を含んで送信される。
認証局２０が確認メールＭ５を受信すると、登録企業ドメイン情報登録センター２１の正規メールＤＢに、「Ｍｅｓｓａｇｅ−ＩＤがＤＢにあったか」を判定するため、ＤＢにおけるＭｅｓｓａｇｅ−ＩＤの有無を問い合せ、Ｍｅｓｓａｇｅ−ＩＤ有無チェック（ＱＶ２３）を実施する。
Ｍｅｓｓａｇｅ−ＩＤ有無チェック（ＱＶ２３）の結果、「ＮＯ」の場合には検証メールの送信（偽）と判断し、偽メールであることの告知をユーザ３０に送信し、また、「ＹＥＳ」の場合には、検証メールの送信（正）と判断し、検証用ＵＲＬをユーザ３０に送付する。
ユーザ３０は、認証局２０から送信された偽メールの告知又は検証用ＵＲＬを受信した後、「正規メールか」を判断し、正規メール適否チェック（ＱＶ２４）を実施する。このチェック（ＱＶ２４）実行の結果、「ＹＥＳ」の場合には、評価点に１００点を加算し、通常メーラに引渡しOKのフラグを立てる。一方、「ＮＯ」の場合には、評価点から１００点を減算し、メールを破棄すると共に、偽装された登録企業に連絡する。これら加点減点後の処理は、前述の先行出願に示す運用での判定に利用される。

図６は、本発明装置のメール検証システムＶ３の概要図を示す。
登録企業１０は、使用する「Ｆｒｏｍアドレス」と「ＳＭＴＰサーバドメイン」を認証局２０に登録する（１０Ｅ）。これに対して、認証局２０は、前記登録が完了すると、登録企業１０にユニークキーを発行する（２０Ｆ）。
登録企業１０は、ユニークキー、Ｍｅｓｓａｇｅ−ＩＤ、送信日時を基に特殊なアルゴリズムを使い生成したワンタイムパスワードをオリジナルヘッダに付加するメールを作成し、当該メールＭ７をユーザ３０に送信する。一方、認証局２０において登録企業情報を記録蓄積したＤＢ２１から、これに記録された登録企業ＳＭＴＰサーバ情報、登録企業Ｆｒｏｍアドレス情報、登録企業ユニークキー情報を、ＵＳＢメモリやＣＤ−ＲＯＭ、ダウンロードデータにより提供（２０Ｇ）を受け、ユーザ３０の端末３０Ｔに、キーの情報ＤＢが記録蓄積される。そこで、ユーザ端末３０Ｔにおいて、登録企業情報のキー情報ＤＢ２１から、該当するユニークキーを割り出す。そこで、割り出されたユニークキーによって、オリジナルヘッダに含まれるワンタイムパスワードを復号化し、そのＭｅｓｓａｇｅ−ＩＤ、送信日時が正常ならば、ＯＫとする。これによって、保証されたメールを受信することができる。
以上のメール検証システム（Ｖ３）において、ユーザ端末Ｔにおけるチェック形態としては、ワンタイムパスワードを利用するチェック、ＳＭＴＰとＦｒｏｍのアドレスがドメイン情報と一致するかのチェック、及びメールヘッダのＭｅｓｓａｇｅ−ＩＤと送信日時に関し認証局に記録されている同一内容か否かのチェックが実行される。

図７は、第３実施例のメールヘッダＭ７Ｈ及びその解析方法を説明する概要図である。
これによれば、メールのヘッダにおける解析方法として、一方の登録企業１０については、ユニークキーから生成したワンタイムパスワードを掲載する「Ｘ−ｈｏｇｅｈｏｇｅ―Ｍａｓｔｅｒ」情報を対象として解析し、他方のユーザ３０については、「Ｆｒｏｍアドレス」、「ＳＭＴＰサーバドメイン情報」を対象として解析するもので、代理ＰＯＰサーバにより、「Ｆｒｏｍアドレス」、「ＳＭＴＰサーバドメイン情報」を基にして、登録企業情報から、該当するユニークキーが割り出される。この割り出されたユニークキーにより、オリジナルヘッダに含まれるワンタイムパスワードを復号化した「Ｍｅｓｓａｇｅ−ＩＤ」、送信日時が正常ならばＯＫとする判定が可能となっている。

図８は、メール検証システムＶ３の検証フローを示す図である。
登録企業１０はユーザ３０にメールＭ７を送信する。その際、送信メールＭ７のヘッダ情報Ｍ７Ｈとして、認証局発行のユニークキーＫを使い、このメールのＭｅｓｓａｇｅ−ＩＤＭ７Ｈ１１、及び送信日時Ｍ７Ｈ１２を特殊なアルゴリズムで暗号化したワンタイムパスワードを示す「Ｘ−ｈｏｇｅｈｏｇｅ」情報Ｍ７Ｈ１、送信先ユーザアドレスを示す「Ｔｏ」情報Ｍ７Ｈ２、認証局に登録したサーバを示す「ＳＭＴＰサーバ」情報Ｍ７Ｈ３、認証局に登録したアドレスを示す「Ｆｒｏｍアドレス」情報Ｍ７Ｈ４を含んで送信される。
登録企業１０からのメールＭ７をユーザ３０が受信すると、「メールにワンタイムパスワードがあったか」 を判定する受信メールにおけるワンタイムパスワード有無チェック（ＱＶ３１）を行なう。このチェック（ＱＶ３１）において、「ＮＯ」の場合には、本出願人に係る先行特許出願に係る運用処理によるメール判定処理へと進められる。一方、「ＹＥＳ」の場合には、次ぎの「メールのSMTP、ＦｒｏｍアドレスがＤＢにあったか」 を判定するSMTP、Ｆｒｏｍアドレス有無チェック（ＱＶ３２）が実施される。このチェック（ＱＶ３２）において、「ＮＯ」の場合には、評価点から１００点を減点すると共に、その後、偽装の可能性が高いため、破棄若しくは認証局の最新ＤＢに問い合せ、再確認する。一方「ＹＥＳ」の場合には、ＤＢから送信登録企業１０のユニークキーＫを検索し、ワンタイムパスワードＭ７Ｈ１を復号し、Ｍｅｓｓａｇｅ−ＩＤＭ７Ｈ１１、及び送信日時Ｍ７Ｈ１２を取得する。
次いで、取得したＭｅｓｓａｇｅ−ＩＤＭ７Ｈ１１及び送信日時Ｍ７Ｈ１２について、「複合した結果はメールヘッダと一致するか」、メールヘッダとの一致性チェック（ＱＶ３３）を実施する。一致性チェック（ＱＶ３３）の結果、「ＮＯ」の場合には、偽装の可能性が高いため、破棄若しくは認証局の最新ＤＢに問合せ、再確認する。一方、「ＹＥＳ」の場合には、評価点に１００点を加算し、通常メーラに引渡しOKのフラグを立てる。これら加点減点後の処理は、先の先行出願に示す運用での判定に利用される。

尚、本実施例において、ワンタイムパスワードを前提に記載しているが、これに拘るものではない。パスワードの漏洩や、運用上において最も適切と考えるからである。

実施例１としてのメール検証システムＶ１の概要図である。 メール検証システムＶ１における該当するチェックでの本文情報詳細説明図を示す図である。 メール検証システムＶ１における検証フローを示す図である。 実施例２としてのメール検証システムＶ２の概要図である。 メール検証システムＶ２における検証フローを示す図である。 実施例３としてのメール検証システムＶ３の概要図である。 メール検証システムＶ３に記載されているオリジナルヘッダに付加した場合のユーザによる本発明ソフトのチェックを示す図である。 メール検証システム１Ｖ３における検証フローを示す図である。

符号の説明

１０ 登録企業
１０Ｔ 登録企業端末
２０ 認証局（登録機関）
２０Ｔ 登録企業ドメイン情報登録センター
２１ 登録企業ドメイン情報ＤＢ
２２ ウィルス情報ＤＢ
３０ ユーザ
３０Ｔ ユーザ端末
Ｖ１，V2，V3 メール検証システム
F１，F２ ファーミング詐欺防止システム
Ｍ１，Ｍ４，Ｍ7 正規メール
Ｍ２ ハッシュ値メール
Ｍ３ 影メール
Ｍ５ 確認メール
Ｍ６ 返信メール
ＭＨ メールヘッダ情報
Ｍ１Ｈ 正規メールのメールヘッダ情報
Ｍ１Ｈ１ 「Ｔｏ」：ユーザアドレス
Ｍ１Ｈ２ 「Ｍｅｓｓａｇｅ−ＩＤ」：ＳＭＴＰサーバが自動的に付加したユニークなＩＤ
Ｍ１Ｈ３ 「Ｘ−ｈｏｇｅｈｏｇｅ」：（拡張ヘッダ）認証局から発行されたワンタイムパスワード
ＭＴ 本文：ユーザへのメール内容
Ｍ２Ｈ ハッシュ値メールのメールヘッダ情報
Ｍ２Ｈ１ 「Ｔｏ」：認証局アドレス
Ｍ２Ｈ２ 正規メールの「Ｍｅｓｓａｇｅ−ＩＤ」：ＳＭＴＰサーバが自動的に付加したユニークなＩＤ
Ｍ２Ｈ３ 「Ｘ−ｈｏｇｅｈｏｇｅ」：（拡張ヘッダ）認証局から発行されたワンタイムパスワード
Ｍ２Ｈ４ 正規メール本文（ＭＴ）を符号化した値（ハッシュ値）
Ｍ３Ｈ 影メールのメールヘッダ情報
Ｍ３Ｈ１ 「Ｔｏ」：ユーザアドレス
Ｍ３Ｈ２ 登録企業が出したメールの「Ｍｅｓｓａｇｅ−ＩＤ」
Ｍ３Ｈ３ ハッシュ値
Ｍ３Ｈ４ 「Ｘ−ｈｏｇｅｈｏｇｅ」：（拡張ヘッダ）認証局から発行されたワンタイムパスワードと対になるキー
Ｃ１ ワンタイムパスワードチェック
Ｃ２ 本文ハッシュ値チェック
Ｃ３ Ｍｅｓｓａｇｅ−ＩＤチェック

Claims (2)

1. ワンタイムパスワード申請を登録企業の端末からネットワークを介して受信し、このワンタイムパスワード申請に対応するワンタイムパスワードを検索情報データベースから検索し前記登録企業の端末に前記ネットワークを介して発行すると共に、前記登録企業の端末から「送信先ユーザアドレス」と、「Ｍｅｓｓａｇｅ−ＩＤ」と、正規メールの本文を符号化したハッシュ値と、前記ワンタイムパスワードと、を含むハッシュ値メールを前記ネットワークを介して受信し、前記検索情報データベースから検索する前記ワンタイムパスワードと対になる前記登録企業のＳＭＴＰサーバ情報と、前記登録企業のＦｒｏｍアドレス情報と、前記「送信先ユーザアドレス」と、前記「Ｍｅｓｓａｇｅ−ＩＤ」と、前記ハッシュ値とを含む影メールを生成し、この影メールを前記ネットワークを介して前記送信先ユーザアドレスに対応するユーザ端末の代理POPサーバへ送信することを特徴とするフィッシング詐欺防止のためのメール検証装置。
2. 登録企業の端末により、認証局のコンピュータにワンタイムパスワードを申請して検索情報データベースから検索しその認証局のコンピュータからワンタイムパスワードを取得する工程と、
   前記登録企業の端末からユーザ端末に、前記ワンタイムパスワード、Ｍｅｓｓａｇｅ−ＩＤを有する正規メールを送信するとともに、前記認証局のコンピュータに、前記正規メールの本文をハッシュ値で符号化し前記ワンタイムパスワードを有するハッシュ値メールを送信する工程と、
   前記認証局のコンピュータが、受信した前記ハッシュ値メールに基づいて、前記ワンタイムパスワードと対になる前記登録企業のＳＭＴＰサーバ情報と、前記登録企業のＦｒｏｍアドレス情報と、前記Ｍｅｓｓａｇｅ−ＩＤと、前記ハッシュ値を有する影メールをユーザ端末に送信する工程と、
   前記ユーザ端末が、前記認証局のコンピュータから所定のチェックのための前記検索情報データベースの情報を受信する工程と、
   前記ユーザ端末が、前記認証局のコンピュータから受信した前記影メールと、この影メールの受信を条件に引渡され前記登録企業のコンピュータから受信する正規メールとを、前記検索情報データベースの情報により前記ワンタイムパスワードと、前記本文のハッシュ値と、前記Ｍｅｓｓａｇｅ−ＩＤと、前記登録企業のＳＭＴＰサーバ情報と、前記登録企業のＦｒｏｍアドレス情報のチェックを行い、すべてが正常であれば前記ユーザ端末のメーラに引き渡す工程と、
   を含むフィッシング詐欺防止のためのメール検証方法。