JP4727627B2 - 電子メールの検証情報生成プログラム、及びその装置、ならびにその方法、電子メールの検証プログラム、及びその装置 - Google Patents

Description

本発明は、電子メールの検証情報生成装置、及びその検証情報生成方法、ならびに検証情報生成プログラム等に関し、特に、例えば同報メール（例えば、メーリングリストで送信されるメール）に対する電子署名付加方法、および検証方法に関して、送信元メールサーバの正当性確認とメールコンテンツ（例えば差出人、宛先、件名、本文等を含む）の内容保証を両立するための技術に関するものである。

近年のＩＴの進展に伴い、行政文書や民間企業の帳簿、契約書等々の形態は、従来の紙文書での運用、保管から電子（デジタル）文書へと徐々に移行されつつある。具体的には、スキャナ装置の普及に伴い、従来紙で保存されていた文書を容易に電子文書化することが可能となった。更に、高解像度を内蔵するイメージスキャナの実用化に伴い、一定のセキュリティ要件を満足すれば従来認められなかった紙文書の大量の電子保存が容認されるようになった（e-文書法:2005年4月施行に伴う）。

一方、このような文書の電子保存要求の増加と共に、電子文書を安全に保管、管理する技術の必要性が高まっている。

従来、紙として保存されていた文書を、紙と同等の証拠能力を維持した状態で電子的に保存するためには、“改ざん検出・防止”、“作成者の識別”、“アクセス管理・制御”、“履歴管理”等々の技術要件を満たす必要があると言われている。このような要件を満たすためには、従来の文書管理システムでは機能不足であり、最近では、上述のような技術要件を満足する「原本性保証システム」の開発、市場投入が急速に進んでいる。

この「原本性保証システム」において、最も一般的に用いられているセキュリティ要素技術に電子署名とタイムスタンプがある。電子署名は、文書の作成者を特定できる（本人性）と同時に、その文書が作成時点から変更がないこと（非改ざん性）を第三者に証明・確認できる技術である。

またタイムスタンプは、電子署名の機能に加え、電子文書の確定時刻を証明することが可能である。どちらも、文書全体に対して電子署名・タイムスタンプを付加することが大きな特徴である。

上記のような技術を利用して実現されている従来の原本性保証の考え方は、確定された最終形態の文書を原本として安全に管理する、いわゆる紙文書を鍵付き書庫等々に保管するのと同様、原本の所在が明確である文書を対象としている。このような環境下においては、電子署名、タイムスタンプは本人性や非改ざん性を保証するのに非常に有効な技術となる。

また、これらの背景のもと、電子情報を取り扱う代表的なものとして電子メールがある。現在、電子メールは企業（ビジネス）、学校（教育）、知人への私的連絡等、あらゆる場面でのコミュニケーションツールとして、欠かせない存在となっている。

電子メールを利用する情報機器も従来のPC（パソコン）環境のみならず、携帯電話やPDA（Personal Digital Assistant：携帯情報端末装置）等の移動端末装置にもメール機能が搭載され、電子メールは、近年、爆発的に利用・普及している電子情報と言える。

一方で、電子メールの内容保証に関する問題や、迷惑メール（スパムメール）等が社会問題となっている。

この内容保証による対策として、S/MIME（Secure Multipurpose Internet Mail Extensions、電子メールの暗号化方式の標準）方式を用いる方法や、電子メール文書の原本性保証装置に関する技術が知られる。

具体的には、上述のS/MIME方式では、メール本文に対して暗号化や電子署名を施すことにより、盗聴やなりすまし、改ざん等を防いでいる。また、上述の電子メール文書の原本性保証装置では、電子メールの本文とそれに添付されたファイルに対して、メール送信時に電子署名を付加し、メール受信時に改ざんの検知を行うための原本性保証装置を設け、該装置内に電子メールの本文と添付ファイルを暗号化して保存すると共にアクセス制限をかけることで電子メールの機密性の要件を満たしている（例えば下記特許文献１参照）。

更に、迷惑メール対策として、一般的な文書の保存と同様、電子メールにも電子署名を用いて保証する事例が増えている。スパムメールとは、メール送信者が自分の身元を隠蔽するために、送信元に関する情報を詐称して送信されるもので、例えば、メールヘッダ中の差出人（From:メールアドレス部分）を他人のメールのヘッダ中からメールアドレスを引用し、あたかも自分の身元のように偽り送信するものである。

このスパムメールの対策として、近年、偽造メールアドレスの特定に焦点を当てたスパム対策技術（送信ドメイン認証技術）が開発されている。

送信ドメイン認証技術には、IPアドレスを利用するものと、電子署名を利用するものの２種類があり、電子署名を利用するタイプの送信ドメイン認証の代表としては、DKIM（Domain Keys Identified Mail）という方式がある。

DKIM方式では、受信者側でメールを送信したサーバを特定し、チェックすることが可能である。具体的には、メールヘッダと本文を一括してSMTPサーバ（送信者側メールサーバ）の電子署名を付加し、受信者へ送信することで、受信者側では、その電子署名を検証することにより送信されたメールサーバの特定が可能になるという仕組みである。加えて、ヘッダと本文を一括して電子署名するため、ヘッダ（差出人（From））部分の引用等による詐称を防止することができ、安全なメール送信を実現することが可能である。
（例えば下記特許文献１参照）。
特開２００５−１０１８８３号公報

上述したS/MIME方式、特許文献１、DKIM方式の３つの従来技術に関する課題を以下に示す。

まず、S/MIME方式では、差出人（From）、宛先（To）、件名（Subject）等のメールヘッダ情報に関して電子署名を施すことはしていないため、迷惑メール（スパムメール）の対策にはなっていなかった。

特許文献１に開示された技術では、電子メール文書原本性保証装置にて電子メールを安全に管理することに注力している点、およびメール本文と添付ファイルを示す「コンテンツ情報」のみの保証に着眼しているため、差出人（From）、宛先（To）、件名（Subject）等のメールヘッダ情報の変更や追加等がなされても、差出人（From）や件名（Subject）、メール本文の内容を個別に確認できるものではなかった。

DKIM方式では、メールヘッダ部分を自動的に変更するようなメーリングリスト（以降、MLと略）による同報メールには不向きである。メーリングリストとは、一群の読者にだけ送りたいメッセージを自動的に電子メールで届けることができるようにするための、電子メールアドレスのリストである。ある読者がリストに送ったメッセージは、すべて他の読者にも届く。メーリングリストに読者登録している人同士でメッセージを送ったり、それに返事をしたり、読んだりすることが可能である。

メーリングリストでは、MLアドレスで投稿されたメールは、一旦MLサーバへ送られ処理される。この時、MLサーバは、電子署名の対象になる本文やヘッダ（特に、件名（Subject））を再配送する際に自動的に変更する場合が多く、投稿時に作成した電子署名が破壊されてしまい、受信者側で検証ができなくなってしまう。

本発明は、上述した課題を解決するためになされたものであり、電子メール、例えば同報メール（例えば、メーリングリストで送信されるメール）に対する電子署名付加、および検証に関し、送信元メールサーバの正当性確認とメールコンテンツ（差出人、宛先、件名、本文等を含む）の内容保証を両立させることができる電子メールの検証情報生成プログラム、及びその装置、ならびにその方法、電子メールの検証プログラム、及びその装置を提供することを目的とする。

上述した課題を解決するため、本発明の一態様は、電子メールを検証するための検証情報をコンピュータに生成させる電子メールの検証情報生成プログラムであって、前記電子メールの情報からヘッダ情報を抽出し、該ヘッダ情報から原本保証に必要となる原本保証対象ヘッダ情報を抽出し、該原本保証対象ヘッダ情報についての特徴量情報を生成すると共に、前記電子メールの情報から本文情報を抽出し、該本文情報についての特徴量情報を生成する特徴量情報生成ステップと、前記原本保証対象ヘッダ情報についての特徴量情報と、前記本文情報についての特徴量情報とをあわせて署名を行うことができる特徴量集合署名情報を生成する特徴量集合署名情報生成ステップと、生成された前記特徴量集合署名情報に対して証明情報を付加する証明情報付加ステップと、前記証明情報付加ステップで証明情報が付加された特徴量集合署名情報を前記電子メールと関連付けて管理する特徴量集合署名情報管理ステップと、をコンピュータに実行させる。

また、本発明の一態様は、電子メールの検証をコンピュータに実行させる電子メールの検証プログラムであって、前記電子メールのヘッダ情報から、証明情報が付加されたヘッダ情報についての特徴量情報を抽出すると共に、前記電子メールの本文情報についての特徴量情報を抽出する特徴量情報抽出ステップと、抽出されたすべての前記証明情報付き特徴量集合署名情報を抽出して比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証ステップと、をコンピュータに実行させる。

また、本発明の一態様は、電子メールを検証するための検証情報を生成する電子メールの検証情報生成装置であって、前記電子メールの情報からヘッダ情報を抽出し、該ヘッダ情報から原本保証に必要となる原本保証対象ヘッダ情報を抽出し、該原本保証対象ヘッダ情報についての特徴量情報を生成すると共に、前記電子メールの情報から本文情報を抽出し、該本文情報についての特徴量情報を生成する特徴量情報生成部と、前記原本保証対象ヘッダ情報についての特徴量情報と、前記本文情報についての特徴量情報とをあわせて署名を行うことができる特徴量集合署名情報を生成する特徴量集合署名情報生成部と、生成された前記特徴量集合署名情報に対して証明情報を付加する証明情報付加部と、前記証明情報付加部で証明情報が付加された特徴量集合署名情報を前記電子メールと関連付けて管理する特徴量集合署名情報管理部とを備える。

また、本発明の一態様は、電子メールの検証を行う電子メールの検証装置であって、前記電子メールのヘッダ情報から、証明情報が付加されたヘッダ情報についての特徴量情報を抽出すると共に、前記電子メールの本文情報についての特徴量情報を抽出する特徴量情報抽出部と、抽出されたすべての前記証明情報付き特徴量集合署名情報を抽出して比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証部とを備える。

また、本発明の一態様は、電子メールを検証するための検証情報を生成する電子メールの検証情報生成方法であって、前記電子メールの情報からヘッダ情報を抽出し、該ヘッダ情報から原本保証に必要となる原本保証対象ヘッダ情報を抽出し、該原本保証対象ヘッダ情報についての特徴量情報を生成すると共に、前記電子メールの情報から本文情報を抽出し、該本文情報についての特徴量情報を生成する特徴量情報生成ステップと、前記原本保証対象ヘッダ情報についての特徴量情報と、前記本文情報についての特徴量情報とをあわせて署名を行うことができる特徴量集合署名情報を生成する特徴量集合署名情報生成ステップと、生成された前記特徴量集合署名情報に対して証明情報を付加する証明情報付加ステップと、前記証明情報付加ステップで証明情報が付加された特徴量集合署名情報を前記電子メールと関連付けて管理する特徴量集合署名情報管理ステップとを備える。

本発明によれば、送信元メールサーバの正当性確認とメールコンテンツ（例えば差出人、宛先、件名、本文等を含む）の内容保証を両立させることができるという効果を奏する。

以下、本発明の実施の形態を図面を参照して説明する。
まず、本発明の実施の形態の全体概要について図１と図２を用いて説明する。図１は本発明の実施の形態の概要としての原理を説明する原理説明図、図２は、その動作を示すフローチャートである。

電子メール情報は、差出人（From）、宛先（To）、件名（Subject）等を含むヘッダ情報と、メール本文の内容を表す本文情報に区分し、メール本文である本文情報が抽出され（ST-1）、更にヘッダ情報は、事後、原本保証（内容保証）を必要対象としない原本保証非対象ヘッダ情報群と、必要対象とする原本保証対象ヘッダ情報群に分離されて、原本保証対象ヘッダ情報群が区分されて抽出される（ST-2）。

ここでは、分離・区分された前記原本保証対象ヘッダ情報群に対する特徴量情報を生成する（ST-3）ヘッダ情報特徴量生成部１０と、本文情報の特徴量情報を生成する（ST-4）本文情報特徴量生成部２０が備えられている。

更に、原本保証対象ヘッダ情報群の特徴量情報と、本文情報の特徴量情報を一体化して、特徴量集合署名情報を生成する（ST-5-1）特徴量集合署名情報生成部３０が備えられている。ここで、特徴量集合署名情報生成部３０は、生成された差出人（From）、宛先（To）、件名（Subject）、本文情報（Body）等の各特徴量情報に加え、どの項目に対応するかの情報を表す付加情報を記録した上で生成する機能を装備する。

更に、特徴量集合署名情報生成部３０で生成された特徴量集合署名情報に対して、電子署名１００とタイムスタンプ２００を付加する（ST-5-2）証明情報付加部４０が備えられている。また、特徴量集合署名情報生成部３０と証明情報付加部４０で生成された証明情報付き特徴量集合署名情報を電子メール情報中のヘッダ情報内に格納する（ST-6）特徴量集合署名情報格納部５０が備えられている。

ヘッダ情報中の原本保証対象ヘッダ情報群に含まれる部分項目が配送経路中に一部追加や変更がなされると、同様にヘッダ情報特徴量生成（ST-3）、本文情報特徴量生成（ST-4）、特徴量集合署名情報生成（ST-5-1）、証明情報付加（ST-5-2）が行われ新たな証明情報付き特徴量集合署名情報が生成され、特徴量集合署名情報格納部５０によって、電子メール情報中のヘッダ情報内に格納される（ST-6）。

この時、先にステップST-6により格納された特徴量集合署名情報は上書きされず、版数管理により順次格納・記録がなされていく。その後、検証対象となるすべての証明情報付き特徴量集合署名情報を比較・検証し、項目毎に変更有無の確認を行う（ST-7）機能を有する特徴量集合署名情報検証部６０を備える。

以下、図３〜図１２を用いて、本発明の実施の形態をより具体的に説明する。
本発明の一実施の形態を示すために、図３のような登場エンティティ、メール配送環境を設定し、ユーザA（送信者）から送られた同報メールが、ドメイン１からドメイン３を経由してユーザB（受信者）までメール配送されるシーンを想定して説明する。

具体的には、ユーザA（送信者）により、「差出人（From）：[email protected]」、「宛先（To）：[email protected]」、「件名（Subject）：hello」を含むヘッダ情報を、メール本文情報として、「こんにちは、お元気ですか」という内容のメッセージを記載する場面を想定して同報メールが送信され、ユーザB（受信者）により、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認が行われる場面を想定する。

ここでは、同報メール（[email protected]）はユーザB（受信者）も閲覧・受信できる状況となっていることを前提とする。

また、ドメイン２のMLサーバによるヘッダ情報の追加・変更が行われる事例として、第１の実施の形態として、件名（Subject）のみが書き換わる場面を、第２の実施の形態として、差出人（From）、件名（Subject）が書き換わり、X-Org-From 、X-Org-Subjectが追加になる場面の２つの例を採り上げて説明する。なお、この“X-”が先頭に付くヘッダ情報は、MLサーバが独自につける項目であることを示している。

（第１の実施の形態）
第１の実施形態として、ドメイン２のMLサーバにより、件名（Subject）のみが書き換わる場面を想定して説明する。図４は、本実施の形態におけるSMTPサーバ１による署名付加の様子を示している。

ユーザA（送信者）により、メール作成、およびメール送信の実行ボタンを押下されると、まず、SMTPサーバ１により、ヘッダ情報と本文情報の区分（ST-SMTP1-1）、および原本保証対象ヘッダ情報群抽出（ST-SMTP1-2）が行われる。

この時、原本保証非対象ヘッダ情報群は、差出人（From）、宛先（To）となり、原本保証対象ヘッダ情報群は、件名（Subject）となる。更に、本文情報（Body）についても保証対象とする。

これらの選択設定は、あらかじめメールシステム内で定義されるか、送信者自身が保証したい項目を指定・選択することで実現できる。

本実施の形態では、差出人（From）、宛先（To）は特にユーザB（受信者）による確認が行われないことを意味しており、件名（Subject）、および本文情報（Body）に着目して変更履歴を受信者に伝えることを行う。

次に、ST-SMTP1-2で抽出した原本保証対象ヘッダ情報群（件名（Subject））の特徴量情報の生成（ST-SMTP1-3）、および本文情報（Body）の特徴量情報の生成（ST-SMTP1-4）を行う。

本例では、「Subject: hello、Body: 3cae2」という特徴量結果が得られる。

生成された各特徴量情報を一体化し、特徴量集合署名情報を生成する（ST-SMTP1-5-1）。この時、本例においては原本保証対象ヘッダ情報群（件名（Subject））の特徴量情報はそのままの情報“hello”を格納しているが、メッセージダイジェスト値（例えば、一方向性関数によるハッシュ値）等を使用してもかまわない。また、本文情報（Body）の特徴量に関しては、本文情報（Body）をそのまま記録すると特徴量集合署名情報の増大の原因となるため、メッセージダイジェスト値（例えば、一方向性関数によるハッシュ値）等を算出するのが望ましい。

また、どの項目に対する特徴量情報かを事後確認できるようにするため、Subject: hello、Body: 3cae2のように特徴量の先頭に付加情報を記録した上で列挙している。更に、本文情報（Body）は、メッセージダイジェスト値として、例えば、一方向性関数によるハッシュ値であることを事後確認・判断できるようにするため、特徴量生成方法に関する付加情報を先頭につけている。

例えば、一方向性ハッシュ関数を使用している場合、例えばMD-5、SHA-1、SHA-256等の一方向性ハッシュ関数の生成アルゴリズム情報等が含まれていると、特徴量情報の判断及び生成が容易である。

本例では、生成アルゴリズムとして、SHA-1を使用していることを想定し、「本文情報（Body）: SHA-1:3cae2」のような構成となっている。この付加情報を記録することにより、次回以降、この付加情報を用いることにより、本文情報（Body）の特徴量生成方法、検証時の検索、および次回以降、原本保証対象ヘッダ情報群の抽出を行う際のキーワードの特定が容易となる。

次に、生成された特徴量集合署名情報に対して、証明情報を付加する（ST-SMTP1-5-2）。証明情報の具体的な例として、電子署名・タイムスタンプを付加するのが望ましい。これは、生成された特徴量集合署名情報は事後の検証情報となるため、改変されていないことが要件となる。ここでは、特徴量集合署名情報をいつ、誰が生成したのか、作成後改変されていないことを確認できる必要がある。また、タイムスタンプは、以降、順次作成されていく特徴量集合署名情報の時系列性を確保するために使用する。

この時の電子署名は、SMTPサーバ１の電子署名が付加される（ST-SMTP1-5-2）。続けて、生成された証明情報付き特徴量集合署名情報を電子メール情報中のヘッダ情報内に格納する（ST-SMTP1-6）。

本実施の形態では、証明情報付き特徴量集合署名情報をヘッダ情報の一部として、ヘッダ情報内に格納したが、別サーバで一括管理する方法もあり得る。その場合、どのメールに対する特徴量集合署名情報かを別に管理する必要が生じるため、該電子メール情報のヘッダ情報内に順次格納され、配送されていくのが望ましい。

SMTPサーバ１による証明情報付き特徴量集合署名情報の生成が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ１からドメイン２のPOPサーバ１に対してメールが送信される。

図５は、ドメイン２内のPOPサーバ１、およびMLサーバの処理の様子を示している。まず、SMTPサーバ１からの正しい送信情報であることを確認するため、SMTPサーバ１の特徴量集合署名情報に付加された証明情報（電子署名・タイムスタンプ）の検証を行う（ST-POP1-1）。

ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザA（送信者）に対してその旨、通知を行う。正しい送信情報であることが確認できれば、宛先（To）: [email protected]が指定された同報メールは、一旦、管理するMLサーバへ送信される。該同報メールを受信したMLサーバは、ヘッダ情報中の件名（Subject）にMLの項番を表す“[ml:001]”を元の件名の前に追加する（ST-ML-1）。この行為は、MLサーバがヘッダ情報を変更する一般的な（標準的な）動作であり、ヘッダ情報と本文情報を一括して署名を行っているDKIM方式の場合は、この一般的な（標準的な）行為により署名検証に失敗していた。

件名（Subject）を変更したMLサーバはSMTPサーバ２に対して、該電子メール情報を送信する。

図６は、本実施形態におけるSMTPサーバ２による署名付加の様子を示している。SMTPサーバ２における原本保証対象ヘッダ情報群抽出のための項目選択に関しては、SMTPサーバ１の署名付加処理で格納された特徴量集合署名情報から入手する（ST-SMTP2-1）。

SMTPサーバ１の特徴量集合署名情報内を参照し、どの項目が選択・記録されているかの確認、および本文情報（Body）の特徴量生成方法に関する情報を取得する（ST-SMTP2-2）。本例の場合、件名（Subject）はそのままで、本文情報（Body）はSHA-1を使用してメッセージダイジェスト値が生成されていることが確認できる。

次に、確認した原本保証対象ヘッダ情報群（件名（Subject））の特徴量情報の生成（ST-SMTP2-3）、および本文情報の特徴量情報の生成（ST-SMTP2-4）を行う。

ここで、本文情報の特徴量生成方法に関する付加情報として、同様にSHA-1を先頭に記録する。

生成された各特徴量情報を一体化し、特徴量集合署名情報を生成する（ST-SMTP2-5-1）。本例では、「Subject: hello、Body: SHA-1:3cae2」という特徴量が記録される。

次に、生成された特徴量集合署名情報に対して証明情報（電子署名・タイムスタンプ）を付加するが、この時の電子署名は、SMTPサーバ２の電子署名が付加される（ST-SMTP2-5-2）。

続けて、生成された証明情報付き特徴量集合署名情報を電子メール情報中のヘッダ情報内に格納する（ST-SMTP2-6）。この時、ヘッダ情報内には、SMTPサーバ１の特徴量集合署名情報が格納されているため、先に格納された該特徴量集合署名情報は上書きされず、版数管理により順次格納・記録がなされていく。また先に格納されたSMTPサーバ１の特徴量集合署名情報との時系列性に関しては、証明情報の一つであるタイムスタンプが付加されているため、事後確認可能である。

SMTPサーバ２による署名付加が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ２からドメイン３のPOPサーバ２に対してメールが送信される。

ここで、POPサーバ２は、受信した電子メール情報内のヘッダ情報から、SMTPサーバ１の特徴量集合署名情報、およびSMTPサーバ２の特徴量集合署名情報を取り出し、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認・検証を行う。

図７は本実施形態におけるPOPサーバ２による署名検証の様子を示している。

まず、最初に、SMTPサーバ１の特徴量集合署名情報、およびSMTPサーバ２の特徴量集合署名情報に付加された証明情報（電子署名・タイムスタンプ）の検証を行う（ST-POP2-1）。

ここで検証に失敗した場合は、途中なんらかの改変が行われていることを示しているため、ユーザB（受信者）に対してその旨、通知を行う。正しい送信情報であることが確認できれば、ヘッダ情報内の件名（Subject）の内容を取り出し、SMTPサーバ２の特徴量集合署名情報に記録された件名（Subject）の特徴量（“[ml:001] hello“）と比較を行う（ST-POP2-2）。

続けて、本文情報（Body）からSHA-1によるハッシュ値を算出し（ST-POP2-3-1）、SMTPサーバ２の特徴量集合署名情報に記録された本文情報（Body）の特徴量（“3cae2”）と比較を行う（ST-POP2-3-2）。

ここで、本文情報（Body）の特徴量生成方法として、SHA-1によるハッシュ値を算出しているが、これは、SMTPサーバ２の特徴量集合署名情報に記録された「Body: SHA-1:3cae2」から入手可能である。

上記比較の結果、異なる場合は、途中なんらかの改変が行われていることを示しているため、ユーザB（受信者）に対してその旨、通知を行う。同一であれば、SMTPサーバ１の特徴量集合署名情報、およびSMTPサーバ２の特徴量集合署名情報の各特徴量情報の比較・検証を行う（ST-POP2-4）。

この比較及び検証の結果、POPサーバ２は、ユーザB（受信者）に対して、以下のことを通知可能とすることができる。

１）SMTPサーバ１からSMTPサーバ２の経路を辿って配送されてきたこと。
２）SMTPサーバ２が、件名（Subject）に対して[ml:001]を追加したこと。
３）本文情報の内容は配送中、変更が加えられていないこと。

このように第１の実施形態では、件名（Subject）、本文情報（Body）の２項目に関して特徴量を記録、特徴量集合署名情報を追加していくことで、上記のような検証をユーザB（受信者）で行うことが可能となる。

（第２の実施の形態）
第１の実施の形態では、件名（Subject）、本文情報（Body）の確認に留まり、差出人（From）に関する原本性検証が行われない。その結果、迷惑メール（スパムメール）で問題となっていた他人のメールのヘッダ中からアドレスを引用し、あたかも自分の身元のように偽り送信することに対しては、確実に防止することができない。これから述べる第２の実施形態では、より確実に、ドメイン２のMLサーバにより、差出人（From）、件名（Subject）が書き換わり、X-Org-From、X-Org-Subjectが追加になる場面を想定して説明する。

また、第１の実施形態では、本文情報はSMTPサーバ１による署名となっていたため、確かにユーザA（送信者）が自署した内容なのかについては言及していなかった。第２の実施形態では、上記ヘッダ情報の保証に加え、本文情報の本人性保証についても踏み込んで説明する。

図８は、本実施形態におけるユーザA（送信者）による署名付加の様子を示している。ユーザA（送信者）は、メール作成に続けて、ユーザA（送信者）の自署した本文情報であることを受信者が確認できるようにするため、署名付加の実行ボタンを押下する。これにより、本文情報（Body）の特徴量情報の生成（ST-USER-A-1）が行われる。

ここでは、本文情報に対するユーザA（送信者）の署名付加が目的のため、ヘッダ情報に関しては、この時点では署名付加が行われず、本文情報の特徴量情報のみが特徴量集合署名情報となる。

次に、生成された特徴量集合署名情報に対して証明情報（電子署名・タイムスタンプ）を付加するが、この時の電子署名は、ユーザA（送信者）の電子署名が付加される（ST-USER-A-2）。続けて、生成された証明情報付き特徴量集合署名情報を電子メール情報中のヘッダ情報内に格納する（ST-USER-A-3）。

図９は、本実施形態におけるSMTPサーバ１による署名付加の様子を示している。ユーザA（送信者）によるメール作成と署名付加実行が完了し、メール送信の実行ボタンが押下されると、SMTPサーバ１により、ヘッダ情報と本文情報の区分が行われる（ST-SMTP1-1）と共に、原本保証対象ヘッダ情報群抽出が行われる（ST-SMTP1-2）。

この時、原本保証非対象ヘッダ情報群は、宛先（To）となり、原本保証対象ヘッダ情報群は、差出人（From）、件名（Subject）となる。更に、本文情報（Body）についても、保証対象となる。この選択は、あらかじめメールシステム内で定義されるか、送信者自身が保証したい項目を指定・選択することで実現できる。

本実施形態では、ユーザA（送信者）による署名付加が事前に行われているため、本文情報（Body）についても保証対象としている。また、本実施形態では、宛先（To）は特にユーザB（受信者）による確認が行われないことを意味しており、差出人（From）、件名（Subject）、および本文情報（Body）に着目して変更履歴を受信者に伝えることを行う。

更に、SMTPサーバ１における本文情報の特徴量生成方法に関しては、ユーザA（送信者）の署名付加処理で格納された特徴量集合署名情報から入手する（ST-SMTP1-3）。

ユーザA（送信者）の特徴量集合署名情報内を参照し、本文情報（Body）の特徴量生成方法に関する情報を取得する（ST-SMTP1-4）。本例の場合、本文情報（Body）はSHA-1を使用してメッセージダイジェスト値が生成されていることが確認できる。

次に、ST-SMTP1-2で抽出した原本保証対象ヘッダ情報群（差出人（From）、件名（Subject））の特徴量情報の生成を行う（ST-SMTP1-5）と共に、本文情報の特徴量情報の生成を行う（ST-SMTP1-6）。

ここで、本文情報の特徴量生成方法に関する付加情報として、同様にSHA-1を先頭に記録する。生成された各特徴量情報を一体化し、特徴量集合署名情報を生成する（ST-SMTP1-7-1）。

本例では、「From: [email protected]、Subject: hello、Body: SHA-1:3cae2」という特徴量が記録される。

次に、生成された特徴量集合署名情報に対して証明情報（電子署名・タイムスタンプ）を付加するが、この時の電子署名は、SMTPサーバ１の電子署名が付加される（ST-SMTP1-7-2）。続けて、生成された証明情報付き特徴量集合署名情報を電子メール情報中のヘッダ情報内に格納する（ST-SMTP1-8）。

この時、ヘッダ情報内には、ユーザA（送信者）の特徴量集合署名情報が格納されているため、先に格納された該特徴量集合署名情報は上書きされず、版数管理により順次格納・記録がなされていく。また先に格納されたユーザA（送信者）の特徴量集合署名情報との時系列性に関しては、証明情報の一つであるタイムスタンプが付加されているため、事後確認可能である。

SMTPサーバ１による署名付加が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ１からドメイン２のPOPサーバ１に対してメールが送信される。

図１０は、ドメイン２内のPOPサーバ１、およびMLサーバの処理の様子を示している。まず、SMTPサーバ１からの正しい送信情報であることを確認するため、ユーザA（送信者）、SMTPサーバ１の各特徴量集合署名情報に付加された証明情報（電子署名・タイムスタンプ）の検証を行う（ST-POP1-1）。

ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザA（送信者）に対してその旨、通知を行う。正しい送信情報であることが確認できれば、宛先（To）: [email protected]が指定された同報メールは、一旦、管理するMLサーバへ送信される。

該同報メールを受信したMLサーバは、ヘッダ情報中の差出人（From）を、[email protected]に変更し、件名（Subject）をMLの項番を表す“[ml:001]”を元の件名の前に追加する。加えて、X-Org-From、X-Org-Subjectの項目を追加し、それぞれ元の差出人（From）、件名（Subject）の内容を転記する（ST-ML-1）。ヘッダ情報の変更を行ったMLサーバは、SMTPサーバ２に対して、該電子メール情報を送信する。

図１１は、本実施形態におけるSMTPサーバ２による署名付加の様子を示している。

SMTPサーバ２における原本保証対象ヘッダ情報群抽出のための項目選択に関しては、SMTPサーバ１の署名付加処理で格納された特徴量集合署名情報から入手する（ST-SMTP2-1）。

SMTPサーバ１の特徴量集合署名情報内を参照し、どの項目が選択・記録されているかを確認すると共に本文情報（Body）の特徴量生成方法に関する情報を取得する（ST-SMTP2-2）。

本例の場合、差出人（From）、件名（Subject）はそのままで、本文情報（Body）はSHA-1を使用してメッセージダイジェスト値が生成されていることが確認できる。更に、SMTPサーバ１の特徴量集合署名情報に記録されていない本時点で新たに追加されたX-Org-From、X-Org-Subjectに関しても、原本保証対象ヘッダ情報群として記録することとする。この判断も同様に、あらかじめメールシステム内で定義されるか、送信者自身が保証したい項目を指定・選択することで実現できる。

次に、確認した原本保証対象ヘッダ情報群（差出人（From）、件名（Subject）、X-Org-From、X-Org-Subject）の特徴量情報を生成する（ST-SMTP2-3）と共に、本文情報（Body）の特徴量情報の生成を行う（ST-SMTP2-4）。

ここで、本文情報の特徴量生成方法に関する付加情報として、同様にSHA-1を先頭に記録する。生成された各特徴量情報を一体化し、特徴量集合署名情報を生成する（ST-SMTP2-5-1）。

本例では、「From: [email protected]、Subject: [ml:001] hello、X-Org-From: [email protected]、X-Org-Subject: hello、Body: SHA-1:3cae2」という特徴量が記録される。

次に、生成された特徴量集合署名情報に対して証明情報（電子署名・タイムスタンプ）を付加するが、この時の電子署名は、SMTPサーバ２の電子署名が付加される（ST-SMTP2-5-2）。続けて、生成された証明情報付き特徴量集合署名情報を電子メール情報中のヘッダ情報内に格納する（ST-SMTP2-6）。

この時、ヘッダ情報内には、ユーザA（送信者）の特徴量集合署名情報と、SMTPサーバ１の特徴量集合署名情報が格納されているため、先に格納された２つの特徴量集合署名情報は上書きされず、版数管理により順次格納・記録がなされていく。

また先に格納された２つの特徴量集合署名情報との時系列性に関しては、証明情報の一つであるタイムスタンプが付加されているため、事後確認可能である。

SMTPサーバ２による署名付加が完了し、電子メール情報のヘッダ内に該情報が格納されると、SMTPサーバ２からドメイン３のPOPサーバ２に対してメールが送信される。

ここで、POPサーバ２は、受信した電子メール情報内のヘッダ情報から、ユーザA（送信者）の特徴量集合署名情報、SMTPサーバ１の特徴量集合署名情報、およびSMTPサーバ２の特徴量集合署名情報を取り出し、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認・検証を行う。

図１２は本実施形態におけるPOPサーバ２による署名検証の様子を示している。

まず、最初に、ユーザA（送信者）の特徴量集合署名情報、SMTPサーバ１の特徴量集合署名情報、およびSMTPサーバ２の特徴量集合署名情報に付加された証明情報（電子署名・タイムスタンプ）の検証を行う（ST-POP2-1）。

ここで検証に失敗した場合、途中なんらかの改変が行われていることを示しているため、ユーザB（受信者）に対してその旨、通知を行う。

正しい送信情報であることが確認できれば、ヘッダ情報内の差出人（From）、件名（Subject）、X-Org-From、X-Org-Subjectの内容を取り出し、SMTPサーバ２の特徴量集合署名情報に記録された差出人（From）、件名（Subject）、X-Org-From、X-Org-Subjectの各特徴量と比較を行う（ST-POP2-2）。

続けて、本文情報（Body）からSHA-1によるハッシュ値を算出し（ST-POP2-3-1）、SMTPサーバ２の特徴量集合署名情報に記録された本文情報のハッシュ値（“3cae2”）と比較を行う（ST-POP2-3-2）。

ここで、本文情報の特徴量生成方法として、SHA-1によるハッシュ値を算出しているが、SMTPサーバ２の特徴量集合署名情報に記録された「Body: SHA-1:3cae2」から入手可能である。

上記比較の結果、異なる場合は、途中なんらかの改変が行われていることを示しているため、ユーザB（受信者）に対してその旨、通知を行う。同一であれば、ユーザA（送信者）の特徴量集合署名情報、SMTPサーバ１の特徴量集合署名情報、およびSMTPサーバ２の特徴量集合署名情報の各特徴量情報の比較・検証を行う。

まず、ST-POP2-4-1の検証では、１）ユーザA（送信者）、SMTPサーバ１、SMTPサーバ２の全エンティティの本文情報（Body）の特徴量が“3cae2”で同一であること、２）ST-POP2-4-2の検証では、ユーザA（送信者）の特徴量集合署名情報には、差出人（From）、件名（Subject）の項目がなく、SMTPサーバ１により追加されたことに加えて、SMTPサーバ２により、差出人（From）、件名（Subject）が変更されたこと、３）ST-POP2-4-3の検証では、ユーザA（送信者）の特徴量集合署名情報、ならびにSMTPサーバ１の特徴量集合署名情報には、X-Org-From、X-Org-Subjectの項目がなく、SMTPサーバ２により追加されたこと、４）またその変更内容は各特徴量集合署名情報の記載、および特徴量集合署名情報に付加された証明情報（電子署名・タイムスタンプ）により、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認を行うことが可能である。

この比較・検証の結果、POPサーバ２は、ユーザB（受信者）に対して、以下のことを通知することができる。

１）SMTPサーバ１からSMTPサーバ２の経路を辿って配送されてきたこと。
２）SMTPサーバ１が、差出人（From）、件名（Subject）を追加したこと。
３）SMTPサーバ２が、差出人（From）を[email protected]から[email protected]に変更したこと。
４）SMTPサーバ２が、件名（Subject）に対して[ml:001]を追加したこと。
５）本文情報の内容はユーザA（送信者）自署で、配送中、変更が加えられていないこと。
６）本文情報の内容はユーザA（送信者）自署で、userA＠xx.comから送られてきたこと。
７）X-Org-From、X-Org-Subjectは、SMTPサーバ２が追加し、元の情報を正しく転記していること。

これにより、第１の実施形態に比べ、ユーザB（受信者）による各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認を厳密に行うことが可能になる。

以上に詳述したように、本実施の形態によれば、メール受信者による、各配送時点での変更者の確認、どのような経路を辿って配送されてきたかの経路情報の確認、およびメール情報（ヘッダ情報、本文情報）の内容確認及び検証を行うことができ、このような確認及び検証の内容を第三者に対して証明を行うことが可能となる。送信元メールサーバの正当性確認とメールコンテンツ（例えば差出人、宛先、件名、本文等を含む）の内容保証を両立させることができる。

なお、図示したフローチャートやステップに示された各動作をコンピュータにより実行させるプログラムを提供することにより、本発明の電子メールの検証情報生成プログラムを提供することができる。これらプログラムはコンピュータにより読取可能な媒体に記録されてコンピュータにより実行させることができる。ここで、コンピュータにより読取可能な媒体としては、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
（付記１） 電子メールを検証するための検証情報をコンピュータに生成させる電子メールの検証情報生成プログラムであって、
前記電子メールの情報からヘッダ情報を抽出し、該ヘッダ情報から原本保証に必要となる原本保証対象ヘッダ情報を抽出し、該原本保証対象ヘッダ情報についての特徴量情報を生成すると共に、前記電子メールの情報から本文情報を抽出し、該本文情報についての特徴量情報を生成する特徴量情報生成ステップと、
前記原本保証対象ヘッダ情報についての特徴量情報と、前記本文情報についての特徴量情報とをあわせて署名を行うことができる特徴量集合署名情報を生成する特徴量集合署名情報生成ステップと、
生成された前記特徴量集合署名情報に対して証明情報を付加する証明情報付加ステップと、
前記証明情報付加ステップで証明情報が付加された特徴量集合署名情報を前記電子メールと関連付けて管理する特徴量集合署名情報管理ステップと、
をコンピュータに実行させる電子メールの検証情報生成プログラム。
（付記２） 付記１に記載の電子メールの検証情報生成プログラムにおいて、
前記特徴量集合署名情報管理ステップは、前記証明情報付加ステップで証明情報が付加された特徴量集合署名情報を前記電子メールのヘッダ情報として、該電子メールのヘッダ情報内に格納することで、前記特徴量集合署名情報を前記電子メールと関連付けて管理する電子メールの検証情報生成プログラム。
（付記３） 付記１に記載の電子メールの検証情報生成プログラムにおいて、
前記特徴量集合署名情報管理ステップは、前記電子メールについて、前記特徴量集合署名情報生成ステップで生成された特徴量集合署名情報の版数を管理する電子メールの検証情報生成プログラム。
（付記４） 付記１に記載の電子メールの検証情報生成プログラムにおいて、
前記特徴量情報生成ステップは、前記原本保証対象ヘッダ情報の特徴量情報と本文情報の特徴量情報における特徴量情報に、これら特徴量情報と前記電子メールの情報の項目との対応関係又は前記特徴量情報の生成方法を示す付加情報を生成して付加する電子メールの検証情報生成プログラム。
（付記５） 付記４に記載の電子メールの検証情報生成プログラムにおいて、
受信した前記電子メールの情報に、本文情報についての特徴量情報と、前記付加情報とが付されている場合、
前記特徴量情報生成ステップは、前記電子メールに付された前記付加情報に基づいて該電子メールの本文情報についての特徴量情報を生成する電子メールの検証情報生成プログラム。
（付記６） 付記１に記載の電子メールの検証情報生成プログラムにおいて、
受信した電子メールについて、前記特徴量情報生成ステップに先立って、
前記電子メールのヘッダ情報から、検証対象となるすべての前記証明情報付き特徴量集合署名情報を抽出して比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証ステップを
コンピュータに実行させる電子メールの検証情報生成プログラム。
（付記７） 電子メールの検証をコンピュータに実行させる電子メールの検証プログラムであって、
前記電子メールのヘッダ情報から、証明情報が付加されたヘッダ情報についての特徴量情報を抽出すると共に、前記電子メールの本文情報についての特徴量情報を抽出する特徴量情報抽出ステップと、
抽出されたすべての前記証明情報付き特徴量集合署名情報を抽出して比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証ステップと、
をコンピュータに実行させる電子メールの検証プログラム。
（付記８） 電子メールを検証するための検証情報を生成する電子メールの検証情報生成装置であって、
前記電子メールの情報からヘッダ情報を抽出し、該ヘッダ情報から原本保証に必要となる原本保証対象ヘッダ情報を抽出し、該原本保証対象ヘッダ情報についての特徴量情報を生成すると共に、前記電子メールの情報から本文情報を抽出し、該本文情報についての特徴量情報を生成する特徴量情報生成部と、
前記原本保証対象ヘッダ情報についての特徴量情報と、前記本文情報についての特徴量情報とをあわせて署名を行うことができる特徴量集合署名情報を生成する特徴量集合署名情報生成部と、
生成された前記特徴量集合署名情報に対して証明情報を付加する証明情報付加部と、
前記証明情報付加部で証明情報が付加された特徴量集合署名情報を前記電子メールと関連付けて管理する特徴量集合署名情報管理部と、
を備える電子メールの検証情報生成装置。
（付記９） 付記８に記載の電子メールの検証情報生成装置において、
前記特徴量集合署名情報管理部は、前記証明情報付加部で証明情報が付加された特徴量集合署名情報を前記電子メールのヘッダ情報として、該電子メールのヘッダ情報内に格納することで、前記特徴量集合署名情報を前記電子メールと関連付けて管理する電子メールの検証情報生成装置。
（付記１０） 付記８に記載の電子メールの検証情報生成装置において、
前記特徴量集合署名情報管理装置は、前記電子メールについて、前記特徴量集合署名情報生成部で生成された特徴量集合署名情報の版数を管理する電子メールの検証情報生成装置。
（付記１１） 付記８に記載の電子メールの検証情報生成装置において、
前記特徴量情報生成部は、前記原本保証対象ヘッダ情報の特徴量情報と本文情報の特徴量情報における特徴量情報に、これら特徴量情報と前記電子メールの情報の項目との対応関係又は前記特徴量情報の生成方法を示す付加情報を生成して付加する電子メールの検証情報生成装置。
（付記１２） 付記１１に記載の電子メールの検証情報生成装置において、
受信した前記電子メールの情報に、本文情報についての特徴量情報と、前記付加情報と、前記電子メール送信者の署名が付されている場合、
前記特徴量情報生成部は、前記電子メールに付された前記付加情報に基づいて該電子メールの本文情報についての特徴量情報を生成する電子メールの検証情報生成装置。
（付記１３） 付記１１に記載の電子メールの検証情報生成装置において、
受信した電子メールのヘッダ情報から、検証対象となる前記証明情報付き特徴量集合署名情報を比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証部を
備える電子メールの検証情報生成装置。
（付記１４） 電子メールの検証を行う電子メールの検証装置であって、
前記電子メールのヘッダ情報から、証明情報が付加されたヘッダ情報についての特徴量情報を抽出すると共に、前記電子メールの本文情報についての特徴量情報を抽出する特徴量情報抽出部と、
抽出されたすべての前記証明情報付き特徴量集合署名情報を抽出して比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証部と、
を備える電子メールの検証装置。
（付記１５） 電子メールを検証するための検証情報を生成する電子メールの検証情報生成方法であって、
前記電子メールの情報からヘッダ情報を抽出し、該ヘッダ情報から原本保証に必要となる原本保証対象ヘッダ情報を抽出し、該原本保証対象ヘッダ情報についての特徴量情報を生成すると共に、前記電子メールの情報から本文情報を抽出し、該本文情報についての特徴量情報を生成する特徴量情報生成ステップと、
前記原本保証対象ヘッダ情報についての特徴量情報と、前記本文情報についての特徴量情報とをあわせて署名を行うことができる特徴量集合署名情報を生成する特徴量集合署名情報生成ステップと、
生成された前記特徴量集合署名情報に対して証明情報を付加する証明情報付加ステップと、
前記証明情報付加ステップで証明情報が付加された特徴量集合署名情報を前記電子メールと関連付けて管理する特徴量集合署名情報管理ステップと、
を備える電子メールの検証情報生成方法。
（付記１６） 付記１５に記載の電子メールの検証情報生成方法において、
前記特徴量集合署名情報管理ステップは、前記証明情報付加ステップで証明情報が付加された特徴量集合署名情報を前記電子メールのヘッダ情報として、該電子メールのヘッダ情報内に格納することで、前記特徴量集合署名情報を前記電子メールと関連付けて管理する電子メールの検証情報生成方法。
（付記１７） 付記１５に記載の電子メールの検証情報生成方法において、
前記特徴量集合署名情報管理ステップは、前記電子メールについて、前記特徴量集合署名情報生成ステップで生成された特徴量集合署名情報の版数を管理する電子メールの検証情報生成方法。
（付記１８） 付記１５に記載の電子メールの検証情報生成方法において、
前記特徴量情報生成ステップは、前記原本保証対象ヘッダ情報の特徴量情報と本文情報の特徴量情報における特徴量情報に、これら特徴量情報と前記電子メールの情報の項目との対応関係又は前記特徴量情報の生成方法を示す付加情報を生成して付加する電子メールの検証情報生成方法。
（付記１９） 付記１８に記載の電子メールの検証情報生成方法において、
受信した前記電子メールの情報に、本文情報についての特徴量情報と、前記付加情報と、前記電子メール送信者の署名が付されている場合、
前記特徴量情報生成ステップは、前記電子メールに付された前記付加情報に基づいて該電子メールの本文情報についての特徴量情報を生成する電子メールの検証情報生成方法。
（付記２０） 付記１５に記載の電子メールの検証情報生成方法において、
受信した電子メールについて、前記特徴量情報生成ステップに先立って、
検証対象となるすべての前記証明情報付き特徴量集合署名情報を比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証ステップを
備える電子メールの検証情報生成方法。

本発明の実施の形態の概要構成を示すブロック図である。 本発明の実施の形態の概要構成における動作を示すフローチャートである。 本発明の第１の実施形態の構成（登場エンティティ、環境）を示す図である。 本発明の第１の実施形態におけるSMTPサーバ１による署名付加処理を示すフローチャートである。 本発明の第１の実施形態におけるドメイン２内のPOPサーバ１、MLサーバの処理を示す図である。 本発明の第１の実施形態におけるSMTPサーバ２による署名付加処理を示すフローチャートである。 本発明の第１の実施形態におけるPOPサーバ２による署名検証処理を示す図である。 本発明の第２の実施形態におけるユーザA（送信者）による署名付加処理を示す図である。 本発明の第２の実施形態におけるSMTPサーバ１による署名付加処理を示す図である。 本発明の第２の実施形態におけるドメイン２内のPOPサーバ１、MLサーバの処理を示す図である。 本発明の第２の実施形態におけるSMTPサーバ２による署名付加処理を示す図である。 本発明の第２の実施形態におけるPOPサーバ２による署名検証処理を示す図である。

符号の説明

１０ ヘッダ情報特徴量生成部、２０ 本文情報特徴量生成部、３０ 特徴量集合署名情報生成部、４０ 証明情報付加部、５０ 特徴量集合署名情報格納部、６０ 特徴量集合署名情報検証部、１００ 電子署名、２００ タイムスタンプ。

Claims (2)

1. 電子メールを検証するための検証情報を、特徴量情報生成部と特徴量集合署名情報生成部と証明情報付加部と特徴量集合署名情報管理部とを有するコンピュータに生成させる電子メールの検証情報生成プログラムであって、
   前記特徴量情報生成部が、前記電子メールのヘッダ情報から件名情報を抽出し、該件名情報についての特徴量情報を生成する特徴量情報生成ステップと、
   前記特徴量集合署名情報生成部が、前記件名情報についての特徴量情報に基づいて、特徴量集合署名情報を生成する特徴量集合署名情報生成ステップと、
   前記証明情報付加部が、生成された前記特徴量集合署名情報に対して、該特徴量集合署名情報に対する前記コンピュータの電子署名を含む証明情報を付加して検証情報を生成する証明情報付加ステップと、
   前記特徴量集合署名情報管理部が、前記検証情報を前記電子メールのヘッダ情報に追加して格納する特徴量集合署名情報管理ステップと、
   受信した電子メールについて、前記特徴量情報生成ステップに先立って、
   前記受信した電子メールの配送の経路上にあるコンピュータが、それぞれ、前記受信した電子メールの件名情報についての特徴量情報を生成し、該特徴量情報に基づいて特徴量集合署名情報を生成し、該特徴量集合署名情報に対して、該特徴量集合署名情報を生成したコンピュータの電子署名を含む証明情報を付加した検証情報を追加した、前記受信した電子メールのヘッダ情報から、検証対象となるすべての前記配送の経路上にあるコンピュータの証明情報が付加された特徴量集合署名情報を抽出して、抽出されたそれぞれのコンピュータが生成した特徴量集合署名情報を比較し、項目毎に変更有無の確認を行う特徴量集合署名情報検証ステップと、
   をコンピュータに実行させる電子メールの検証情報生成プログラム。
2. 電子メールの検証を、特徴量情報抽出部と特徴量集合署名情報検証部とを有する第１コンピュータに実行させる電子メールの検証プログラムであって、
   前記電子メールを検証するための検証情報を、特徴量情報生成部と特徴量集合署名情報生成部と証明情報付加部と特徴量集合署名情報管理部とを有する第２コンピュータに生成させる電子メールの検証情報生成プログラムであって、前記特徴量情報生成部が、前記電子メールのヘッダ情報から件名情報を抽出し、該件名情報についての特徴量情報を生成する特徴量情報生成ステップと、前記特徴量集合署名情報生成部が、前記件名情報についての特徴量情報に基づいて、特徴量集合署名情報を生成する特徴量集合署名情報生成ステップと、前記証明情報付加部が、生成された前記特徴量集合署名情報に対して、該特徴量集合署名情報に対する第２コンピュータの電子署名を含む証明情報を付加して検証情報を生成する証明情報付加ステップと、前記特徴量集合署名情報管理部が、前記検証情報を前記電子メールのヘッダ情報に追加して格納する特徴量集合署名情報管理ステップとを第２コンピュータに実行させる電子メールの検証情報生成プログラムが前記電子メールの配送の経路上にある第２コンピュータでそれぞれ実行され、前記特徴量集合署名情報管理ステップにより格納された前記電子メールのヘッダ情報から、前記特徴量情報抽出部が、前記電子メールの配送の経路上にある第２コンピュータのそれぞれの検証情報を抽出し、
   前記特徴量集合署名情報検証部が、抽出されたそれぞれの検証情報の特徴量情報を前記電子メールの配送の経路上にある第２コンピュータごとに比較し、それぞれの変更有無の確認を行なう特徴量集合署名情報検証ステップ
   を第１コンピュータに実行させる電子メールの検証プログラム。

Images