(57)【要約】【課題】  暗号化された電子メールや電子署名付きの電子メールを受信しても、メールサーバからクライアントに転送する際に、暗号化されていたことや電子署名付きであったことが不明になってしまう。  【解決手段】  電子メールを受信した際に、暗号化メールであればその旨を、電子署名付きであれば検証結果を、電子メールの本文などにコメントとして付加する。【選択図】    図６
2006148658.tif 000002
【特許請求の範囲】
【請求項１】
電子メールの暗号化と復号、及び電子署名とその検証とを行うようにした暗号メールサーバにおいて、
電子メールサーバをクライアントにＬＡＮを介して接続自在にすると共に、ＬＡＮ外からの暗号化電子メールを復号するための復号手段と、暗号文で受信した旨をコメントとして付加して、該電子メールを平文でクライアントに転送するための転送手段を設けたことを特徴とする、暗号メールサーバ。
【請求項２】
前記転送手段では、ＬＡＮ外からの電子メールの電子署名を検証した際に、その検証結果をコメントとして付加してクライアントに転送するようにしたことを特徴とする、請求項１の暗号メールサーバ。
【請求項３】
クライアントから受信した平文で電子署名なしの電子メールを、暗号化するための暗号化手段と、該電子メールに電子署名するための電子署名手段とを設けて、暗号化もしくは電子署名した電子メールをＬＡＮ外へ送信するようにしたことを特徴とする、請求項１又は２の暗号メールサーバ。
【請求項４】
電子メールの暗号化と復号、及び電子署名とその検証、とを行うようにした暗号メールサーバ用のプログラムにおいて、
ＬＡＮ外からの暗号化電子メールを復号するための命令と、暗号文で受信した旨のコメントを、電子メールのヘッダ又は本文に付加するための命令、とを設けたことを特徴とする、暗号メールサーバ用のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、電子メールを暗号化して通信するサーバに関し、特に暗号化された電子メールの復号や電子署名の検証に関する。
【背景技術】
【０００２】
電子メールを暗号化して第三者に解読されることを防止することや、電子メールに電子署名を付加して、送信者からのメールでしかも途中で改ざんされていないことを確認出来るようにすることが、提案されている（特許文献１，２）。
【０００３】
ところで発明者は、暗号化された電子メールや電子署名付きの電子メールを受信する際に、以下の問題が生じることに着目した。即ち、メールサーバで暗号文を復号し、あるいは電子署名を検証して、クライアントに転送すると、暗号化されていた事実や電子署名を施されていた事実が記述されないことになる。このためクライアント側では、暗号化されていたことや電子署名されていたことが不明になってしまう。またこれを避けるために、クライアント側で復号や電子署名の検証を行うと、クライアントの負担が大きくなる。
【特許文献１】特開２００２−３６８８２３
【特許文献２】特開２００３−１９８６３２
【発明の開示】
【発明が解決しようとする課題】
【０００４】
この発明の課題は、クライアント側で電子メールを復号する必要が無く、しかも暗号化通信により安全に送信されてきたことが、クライアント側で判明するようにすることにある（請求項１〜４）。
請求項２の発明の追加の課題は、クライアント側で電子署名を検証する必要を解消すると共に、クライアント側で電子署名が施されていた事実を確認できるようにすることにある。
請求項３の発明の追加の課題は、暗号メールサーバとクライアントがＬＡＮを通信路として通信する際に、平文で通信できるようにして、クライアントの負担を軽減することにある。
【課題を解決するための手段】
【０００５】
この発明の暗号メールサーバは、電子メールの暗号化と復号、及び電子署名とその検証、とを行うようにした暗号メールサーバにおいて、電子メールサーバとクライアントとをＬＡＮを介して接続自在にすると共に、ＬＡＮ外からの暗号化電子メールを復号するための復号手段と、暗号文で受信した旨をコメントとして付加して、該電子メールを平文でクライアントに転送するための転送手段を設けたことを特徴とする。
【０００６】
好ましくは、前記転送手段では、ＬＡＮ外からの電子メールの電子署名を検証した際に、その検証結果をコメントとして付加してクライアントに転送する。
また好ましくは、クライアントから受信した平文で電子署名なしの電子メールを、暗号化するための暗号化手段と、該電子メールに電子署名するための電子署名手段とを設けて、暗号化もしくは電子署名した電子メールをＬＡＮ外へ送信する。
【０００７】
この発明の暗号メールサーバ用のプログラムは、電子メールの暗号化と復号、及び電子署名とその検証、とを行うようにした暗号メールサーバ用のプログラムにおいて、ＬＡＮ外からの暗号化電子メールを復号するための命令と、暗号文で受信した旨のコメントを、電子メールのヘッダ又は本文に付加するための命令、とを設けたことを特徴とする。
【発明の効果】
【０００８】
この発明では、受信した暗号電子メールを暗号メールサーバが復号するので、クライアントは復号する必要がない。また暗号文で受信した旨のコメントを付加して受信メールをクライアントに転送するので、安全に送信されてきたことが、クライアント側でも判明する（請求項１〜４）。
【０００９】
請求項２の発明では、受信した電子メールに付加されていた電子署名を暗号メールサーバで検証し、検証結果をコメントとして付加して、クライアントに転送するので、クライアント側では、電子署名の検証能力を持つ必要がなく、しかも電子署名の検証結果をコメントから知ることができる。
【００１０】
請求項３の発明では、ＬＡＮ内では平文でかつ電子署名なしで電子メールを送信し、暗号メールサーバで暗号化や電子署名を行ってＬＡＮ外へ送信する。このためクライアントは暗号化や復号、電子署名やその検証能力を持つ必要がない。
【発明を実施するための最良の形態】
【００１１】
以下に本発明を実施するための最適実施例を示す。
【実施例】
【００１２】
図１〜図９に、実施例の暗号メールサーバ２，３とその変形を示す。４はメールエージェントで、ＳＭＴＰやＰＯＰあるいはＩＭＡＰなどのプロトコルにより、ＬＡＮ２４，２５の内外での電子メールの送受信を行う。６はWebサーバで、例えばＬＡＮ２４内のクライアントに対して、ＨＴＴＰなどによりＨＴＭＬ文書としてWeb電子メールの送受信を行うためのものである。またWebサーバ６は、暗号メールサーバ２の管理者のパーソナルコンピュータなどに対して、自己の設定データをＨＴＭＬ文書などとして送付し、管理者が自己のパーソナルコンピュータなどから設定データを編集できるようにする。なお暗号化メールサーバ２，３の構成は同一で、２４，２５の符号は送信側のＬＡＮと受信側のＬＡＮとを区別するために用いた。
【００１３】
８は暗号化部で、公開鍵暗号や秘密鍵暗号での暗号化を行い、電子メールの送受信で行われる主な種類の暗号化アルゴリズムに対応済みである。１０は電子署名部で、送信する電子メールに電子署名を付与し、例えば電子署名済みの電子メールの送信に先立ち、電子署名の証明書を送付する。そして証明書に記述の公開鍵に対応する秘密鍵により、署名しようとする電子メールの本文、もしくは本文と添付ファイルなどに対する、メッセージダイジェストを計算し、メッセージダイジェストを秘密鍵で処理したものを電子署名として付加する。署名しようとするデータの範囲が狭い場合、例えば僅かな行数の本文のみの場合、本文全体を秘密鍵で処理して、メッセージダイジェストを用いなくても良い。
【００１４】
電子署名には、暗号メールサーバ２のＬＡＮ２４内のクライアントに共有の証明書を用いた電子署名と、クライアント毎の個別の証明書を用いた電子署名の２種類がある。署名の強弱では、クライアント毎の個別の証明書による電子署名が強く、暗号メールサーバ２のクライアントに共有の電子署名が弱いものとする。個別の電子署名は、個々のクライアントの単位でも、あるいはクライアントのグループで、暗号メールサーバ２のクライアント全体よりは小さなグループ単位のものでも良い。
【００１５】
複数の証明書を用いることができるクライアントは、適宜の設定などによるデフォールト値やオプションでの指定により、もしくは送信しようとする電子メール毎に、いずれの電子署名を用いるかを選択できる。例えば、送信先毎に証明書を指定する、あるいは送信先よりも、ヘッダや本文中に表れる「重要」、「緊急」などのキーワードや、サブジェクト欄の記述などを優先して、証明書の種類を指定する、また例えば送信先とは別に、前回用いた証明書を、特に指定がなければ、次回の送信でも使用するなどのことができる。なお各クライアントは、電子メールを暗号化するかどうか、電子署名を付与するかどうか、また暗号化と電子署名の双方を行うかどうかを、選択できる。
【００１６】
復号部１２は、暗号化された電子メールを受信した際に、平文に復号する。検証部１４は、電子署名付きの電子メールを受信した際に、送信者の公開鍵を用いて電子署名を処理し、例えばメッセージダイジェストの値と一致するかどうかを検証する。この値が一致する場合、送信者は公開鍵の所有者であり、かつ電子署名を付与された部分には、送信過程での改ざんが施されていないことを確認できる。
【００１７】
証明書データベース１６には、暗号メールサーバ２のクライアント間で共有の電子署名の証明書と、クライアントの個別の証明書とを記憶し、有効期限切れや失効の有無などを管理する。また検証部１４は、認証局のホームページなどから、証明書データベース１６に記憶した証明書の失効の有無などを検査する。証明書データベース１６への問い合わせに対して、有効期限切れの場合などは、その旨と代替し得る証明書がある場合は、代替の証明書のデータを出力する。例えばユーザ個人の証明書が有効期限切れの場合、共有の証明書のデータを代替の証明書として出力する。クライアントデータベース１８には、暗号メールサーバ２のクライアントに関するデータを記憶し、特に共有の証明書のみを用いることができるのか、それ以外に個別の証明書も用いることができるのか、などの使用し得る証明書の範囲と、どの証明書を優先して用いるのかの基準とを記憶する。
【００１８】
宛先データベース２０には電子メールの送信先毎に、暗号化の要否や、送信先の暗号化用の公開鍵や電子署名用の公開鍵の証明書を記憶し、他に暗号化用の公開鍵のアルゴリズムや、電子署名の検証用の公開鍵の署名アルゴリズムなどを記憶する。これらの証明書は、例えば受信した電子メールに付加されていたものなどを記憶し、例えば定期的に認証局のホームページなどを閲覧して、証明書が有効かどうかなどを検査する。またローカルメールボックス２２には、各クライアントの送信メールや受信メールを格納する。
【００１９】
２３はコメント部で、暗号化した電子メールを受信し、復号部１２で復号した際には、暗号化電子メールとして受信した旨のコメントを、ＬＡＮ２４内のクライアントへ転送する平文の電子メールに付加する。また電子署名付きの電子メールをＬＡＮ２４外から受信した際には、電子署名の検証結果、即ち、送信者の名称などの送信者を特定する情報と、改ざんがなされていないこととをコメントとして、ＬＡＮ２４内のクライアントへ転送する電子メールに付加する。なお電子署名の検証に失敗した場合、通信過程で改ざんがされた可能性がある電子メールであることを、コメントとして付加する。
【００２０】
２６はインターネットファクシミリ装置で、Ｇ３ファクシミリなどの他に、電子メールなどの形式でのインターネットファクシミリを行い、ＳＭＴＰやＩＭＡＰあるいはＰＯＰなどのプロトコルにより、電子メールの送受信を行う。なお暗号メールサーバ２，３は、例えばインターネットファクシミリ装置２６と一体にして、その一部としても良い。２８はパーソナルコンピュータで、クライアントの例である。
【００２１】
ＬＡＮ２４はルータ３０を介して、外部のメールサーバ３２に接続され、インターネットファクシミリ装置２６や暗号メールサーバ２，３は、外部のメールサーバ３２，３３のＰＯＰクライアントとして動作すると共に、ＳＭＴＰサーバなどとして独自に電子メールの送受信を行う。メールサーバ３２は、インターネットなどのＷＡＮを介して送信先側のメールサーバ３３と通信し、ルータ３１を介して例えば暗号メールサーバ３などとの間で、電子メールを送受信する。そして無線ＬＡＮなどではなく、地上側に設置されたＬＡＮ２４，２５内を安全な環境と見なして、ＬＡＮ２４，２５内では平文で電子メールを送受信し、また電子署名は不要とする。ＬＡＮ２４，２５の外部への送信時の暗号化や電子署名は、暗号メールサーバ２，３が行い、ＬＡＮ２４の外部から受信した電子メールの復号や電子署名の検証も、暗号メールサーバ２，３が行う。このためクライアントは暗号通信や電子署名に資源を割り当てる必要がない。
【００２２】
図２に、証明書データベース１６の例を示すと、各列は１つの証明書を示し、公開鍵とそれに対応する秘密鍵、証明書を発行した認証局の名称と証明書の有効期限、及び電子署名のアルゴリズムなどが記述されている。これ以外に暗号化用の公開鍵や秘密鍵、そのアルゴリズムなどを記述しても良い。各証明書に対して、暗号メールサーバのクライアント間で共有の証明書か、個別の証明書かが記述され、個別の証明書にはその署名の強弱がＡ，Ｂなどのランクで記述してある。例えば暗号メールサーバ２のクライアント数が全体で１００で、そのうち１０のクライアントがＩＤ２の証明書を共有し、そのうち更に特定のクライアントのみがＩＤ３の証明書を有しているとする。するとＩＤ３の証明書はランクＢで、ＩＤ２の証明書のランクＡよりも高いランクで、ＩＤ１の共有の証明書が最も弱いランクとなる。即ち証明書を共有するクライアント数が少ないほど、一般に強い証明書となる。また各証明書に対してその所有者が記憶され、共有の証明書の所有者は暗号メールサーバ２のクライアントの全体である。
【００２３】
図３に、クライアントデータベース１８の例を示すと、各クライアントに対してローカルアドレスとローカルアカウント並びにローカルなパスワードを記憶し、これ以外にＬＡＮの外部との送受信用の、グローバルなメールアドレス並びにグローバルなアカウントと、パスワードとを記憶する。各クライアントに対して、電子署名や暗号受信などで用いることができる証明書のＩＤを記憶し、例えば図３の左側の列のクライアントは共有の証明書のみを用いることができ、右側の列のクライアントは証明書１，２，３を用いることができる。
【００２４】
デフォールトの欄には、複数の証明書を用いることができるクライアントの場合、個別の指定が無い際に、どの証明書を用いるかが記憶されている。デフォールト値に優先するデータが、オプションの欄に記憶され、例えば送信先や、あるいはヘッダや本文中の適宜のキーワード毎に、用いる証明書を定めることができる。あるいは前回用いたのと同じ証明書が、デフォールト値として用いられるべきことを記憶する。なお各クライアントは、電子メールの送信を依頼する際に電子署名が必要かどうか、また電子署名の種類は、平文に対する電子署名（クリア電子署名）か、暗号文に対する電子署名かを選択でき、また電子署名に用いる証明書は共有か個別かなどを指定できる。この指定は、クライアントデータベース１８で定まる証明書の種類よりも優先する。
【００２５】
図４に宛先データベース２０の例を示すと、宛先となるメールアドレス毎に、送信する電子メールの暗号化の要否のデフォールト値、宛先（送信先）側の公開鍵証明書の番号と公開鍵やそのアルゴリズム、証明書を発行した認証局と証明書の有効期限などが記憶されている。さらに宛先側の電子署名の公開鍵や署名のアルゴリズムも記憶されている。宛先データベース２０を設けることにより、受信した電子メールに付与されている電子署名の検証が容易になると共に、電子メールの送信前に一々公開鍵を取得する必要が解消する。
【００２６】
図５に、暗号化や電子署名用の公開鍵の証明書４０の例を示すと、例えば証明書のバージョンと証明書の番号、並びに署名に用いるアルゴリズムなどが記述されている。そして証明書を発行した認証局の名称と、証明書の有効期限の開始日と最終日とが記述され、証明書の所有者の情報、即ち証明書に記述された暗号化や電子署名の公開鍵を用いる人物やクライアントの情報が記述されている。また暗号化と電子署名の双方について、公開鍵とアルゴリズムとが記述されている。
【００２７】
図６，図７に、暗号化されていた電子メールであったことや、電子署名の検証結果を、コメントとして付加する際の処理を示す。ここでは図７に示すように、インターネットファクシミリ装置２６などのクライアントから、暗号メールサーバ２などの送信側メールサーバを介して、受信側の暗号メールサーバ３へと、暗号化した電子メールや電子署名付きの電子メールを送信する場面を想定する。そして暗号メールサーバ３で復号や電子署名の検証を行い、それに対応するコメント５２，５３を電子メールのヘッダあるいは本文に付加して、クライアントのインターネットファクシミリ装置２７などへ平文で転送する。
【００２８】
図６のアルゴリズムでは、受信側の暗号メールサーバはＬＡＮ外のメールサーバから新着メールの有無をチェックし（ステップ１）、新着メールが存在する場合（ステップ２）、電子メールをダウンロードする（ステップ３）。電子メールが暗号化されている場合（ステップ４）、ステップ５で電子メールを復号し、ステップ６で、「このメールは暗号化され（通信過程で）安全に受信されました」などのコメント５２を付加する。なお平文で受信した電子メールでは、ステップ５，ステップ６は省略する。
【００２９】
ステップ７で電子署名の有無を検査し、電子署名が存在する場合、ステップ８で電子署名を検証する。検証結果がＯＫの場合のコメント５３として、「署名検証ＯＫ；  署名者ＸＵＺ；  署名の有効期限  ；改ざんを受けることなく、署名者が送信したままの状態で受信されています」などを付加する。検証に失敗した場合、通信経路で改ざんされた電子メールである可能性があることを、コメントとして付加して警告する。電子署名が施されていない場合、ステップ８，ステップ９は省略する。なお電子署名が暗号文に対して施されている場合、ステップ７〜ステップ９を、ステップ４〜ステップ６の前に実行する。復号と検証とを行った電子メールを、ローカルメールボックスに格納する（ステップ１０）。
【００３０】
図８，図９に、ＬＡＮ外等から暗号メールサーバに対して、不正なアクセスがされた場合への対策を追加したアルゴリムを示す。このアルゴリズムは、ステップ９で電子署名の検証結果をコメントとして付加するところまでは、図６のアルゴリズム（ステップ１〜９）と同様である。ただしステップ５の復号はパラメータの取得のためなので、例えば本文のみを復号し、添付ファイルは復号しなくても良い。またヘッダは通常は暗号化されずに送信されてくる。
【００３１】
ローカルメールボックスに復号した電子メールを保存する必要を無くすため、ステップ１１で暗号化した電子メールであるかどうかを検査する。暗号化した電子メールの場合、ステップ１２で、暗号文で送信されたことや、電子署名の署名者や途中で改ざんが施されていなかったことなどのコメント、及び添付ファイルの有無やそのデータ長、送信日その他のキーワード、などをパラメーターとして取得する。ステップ１３で復号データを消去し、暗号化された電子メールとパラメーターとをローカルメールボックスに格納する（ステップ１４）。この結果、ローカルメールボックスへの不正アクセスが行われても、電子メールの平文にアクセスされることを防止できる。
【００３２】
続いて図９のアルゴリズムでは、ステップ２１でクライアントからのメールチャックの有無を検査し、メールチェックが行われている場合、ローカルメールボックス内のデータに基づき応答する（ステップ２２）。即ち平文の電子メールがローカルメールボックスに格納されている場合、平文に基づいて応答し、暗号文が格納されている場合、そのヘッダやパラメーターなどの暗号化されていない部分により応答する。これによってクライアント側では、電子メールの長さや添付ファイルの有無、送信日、暗号化の有無や電子署名の有無とその検証結果、送信者などを知ることができる。ステップ２３でメールのダウンロードを行うかどうかを判断し、ダウンロードする場合、暗号化メールであれば（ステップ２４）、電子メールを復号化してクライアントへ送信する（ステップ２５，ステップ２６）。また平文のメールの場合、そのままクライアントへ転送すればよい（ステップ２６）。メールのダウンロード以外のコマンドの場合、クライアントの要求するコマンドに沿った処理を行う（ステップ２７）。
【００３３】
実施例では以下の効果が得られる。
(1)  電子メールの暗号化や復号、電子署名やその検証は、暗号メールサーバで行えるので、クライアントではこのような能力を持つ必要がない。
(2)  送信する電子メールに施す電子署名について、複数の証明書を利用できる場合、クライアントはこれから用いる証明書を選択できる。
(3)  ローカルメールボックスに、暗号化された電子メールを復号した平文を保存することによる、リスクを軽減できる。
【図面の簡単な説明】
【００３４】
【図１】実施例の暗号メールサーバの構成と、これを用いたシステム構成とを示すブロック図
【図２】実施例で用いる証明書データベースを模式的に示す図
【図３】実施例で用いるクライアントデータベースを模式的に示す図
【図４】実施例で用いる宛先データベースを模式的に示す図
【図５】認証局の証明書を模式的に示す図
【図６】実施例での受信時のアルゴリズムを示すフローチャート
【図７】実施例でのインターネットファクシミリ装置からインターネットファクシミリ装置への送信過程を模式的に示す図
【図８】変形例での受信時のアルゴリズムを示すフローチャート
【図９】図８に続くアルゴリズムを示すフローチャート
【符号の説明】
【００３５】
２，３  暗号メールサーバ
４  メールエージェント
６       Ｗebサーバ
８       暗号化部
１０     電子署名部
１２  復号部
１４  検証部
１６     証明書データベース
１８     クライアントデータベース
２０     宛先データベース
２２     ローカルメールボックス
２３            コメント部
２４，２５ ＬＡＮ
２６，２７ インターネットファクシミリ装置
２８     パーソナルコンピュータ
３０，３１ ルータ
３２，３３     メールサーバ
４０  証明書
５０            電子メール
５１            添付ファイル
５２，５３      コメント    
【図１】
2006148658.tif 000003
【図２】
2006148658.tif 000004
【図３】
2006148658.tif 000005
【図４】
2006148658.tif 000006
【図５】
2006148658.tif 000007
【図６】
2006148658.tif 000008
【図７】
2006148658.tif 000009
【図８】
2006148658.tif 000010
【図９】
2006148658.tif 000011