JP2006148660A - 暗号メールサーバとそのプログラム - Google Patents

Abstract

【課題】暗号化あるいは電子署名に対応している宛先に対して、全て暗号化おるいは電子署名を施して通信すると、メールサーバの負担が著しくなる。
【解決手段】暗号化あるいは電子署名の要否を送信先テーブルで判断し、その上位のクライアントテーブルで個別に暗号化あるいは電子署名の要否を指定できるようにして、要否の指定に従って暗号化あるいは電子署名を行うことで、メールサーバの負担を抑制しながら、セキュリティを確保する。
【選択図】図６

Description

この発明は電子メールを暗号化しあるいは電子署名して通信できるサーバに関し、特に暗号化や電子署名の要否の管理に関する。

電子メールを暗号化して安全に配送することや、電子メールに電子署名を施して、送信者を確認できかつ通信路で改ざんされていないことを確認できるようにすることが提案されている（特許文献１，２）。

暗号化の要否を自動的に決定するため、例えば宛先（送信先）毎の暗号化の要否を記憶しておくことが考えられる。しかしながら送信先が暗号化に対応しているからといって、無条件に送信メールを暗号化すると、メールサーバの負担が増加する。同様に電子署名に対応している送信先に、無条件に電子メールに電子署名すると、メールサーバの負担が増加する。
特開２００２−３６８８２３ 特開２００３−１９８６３２

この発明の基本的課題は、クライアントが暗号化もしくは電子署名を行う必要性を解消し、かつ暗号化もしくは電子署名のためのメールサーバの負荷を抑制しながら、セキュリティを確保できるようにすることにある（請求項１〜４）。
請求項２，３の発明での追加の課題は、暗号化もしくは電子署名の要否を更に柔軟に決定できるようにすることにある。

この発明の暗号メールサーバは、暗号化手段と復号手段、もしくは電子署名手段とその検証手段とを備えた暗号メールサーバにおいて、送信先が暗号化に対応しているかどうか、もしくは送信先が電子署名に対応しているかどうかのデータを記憶するための送信先データの記憶手段と、送信先に対する暗号化もしくは電子署名の要否を記憶するための要否記憶手段とを設けて、暗号化に対応もしくは電子署名に対応した送信先に対して、要否記憶手段でのデータに従って、暗号化もしくは電子署名を施すようにしたことを特徴とする。

好ましくは、前記要否記憶手段を、暗号メールサーバのクライアント別に設ける。
特に好ましくは、前記要否記憶手段に優先する管理者データを記憶する管理者手段を設けて、管理者手段が暗号化もしくは電子署名の要否を記憶している場合はそれに従い、記憶していない場合は、少なくとも要否記憶手段のデータに従って、暗号化もしくは電子署名の要否を決定する。例えば要否記憶手段にデータが無い場合、送信先データの記憶手段のデータなどに従って、暗号化もしくは電子署名の要否を決定すると良い。
なお、暗号化もしくは電子署名の要否が、電子メール毎にクライアントにより個別に指定されている場合、その指定には例えば要否記憶手段と管理者手段との間の優先度を与える。
実施例では暗号化と電子署名の双方を管理する例を示すが、この発明を暗号化のみの管理に適用しても、あるいは電子署名のみの管理に適用しても良い。

この発明の暗号メールサーバ用のプログラムは、暗号化手段と復号手段、もしくは電子署名手段とその検証手段とを備えた暗号メールサーバ用のプログラムにおいて、送信先が暗号化に対応しているかどうか、もしくは送信先が電子署名に対応しているかどうかのデータを記憶するための送信先データの記憶命令と、送信先に対する暗号化もしくは電子署名の要否を記憶するための要否記憶命令とを設けて、暗号化に対応もしくは電子署名に対応した送信先に対して、要否記憶命令に基づくデータに従って、暗号化もしくは電子署名を施すようにしたことを特徴とする。

この発明では、暗号化あるいは電子署名を暗号メールサーバが行うので、クライアントは暗号化もしくは電子署名に資源を割り当てる必要がない。また送信先データの記憶手段で、送信先が暗号化もしくは電子署名に対応しているかどうかを記憶し、かつ要否記憶手段で暗号化などに対応している送信先でも、暗号化などを不要と指定できるので、不要な暗号化あるいは不要な電子署名を減らし、セキュリティを確保しながら、暗号メールサーバの負荷を軽減できる（請求項１〜４）。

請求項２の発明では、要否記憶手段のデータはクライアント別に定めることができるので、暗号化もしくは電子署名の要否を更に柔軟に決定できる。
請求項３の発明では、管理者手段により、暗号化もしくは電子署名の要否を決定できるので、管理者方針に基づいて暗号化もしくは電子署名の要否を管理できる。

以下に本発明を実施するための最適実施例を示す。

図１〜図７に、実施例の暗号メールサーバ２と暗号メールサーバ用のプログラム２４とを示す。図１において、４はメールエージェントで、ＬＡＮの内外に対して電子メールの送受信を行い、ＰＯＰやＳＭＴＰ，ＩＭＡＰなどのプロトコルを利用する。６はWebサーバで、ＨＴＴＰサーバとしてWebメールとしての電子メールの送受信を行う。Webサーバ６はさらに、管理者の端末やクライアントの端末に対して、自己の設定データやその他のテーブルなどをＨＴＭＬ文書として送信し、管理者やユーザなどがこれらのデータを編集できるようにする。編集済みのＨＴＭＬ文書を管理者やユーザなどから受信すると、暗号メールサーバ２は、受信したＨＴＭＬ文書に従い、自己の設定データを更新する。

暗号化部８は電子メールの暗号化を行い、例えば電子メールの本文と添付ファイルとを暗号化する。なおこの明細書において電子メールは、ＳＭＴＰなどのプロトコルに従ったものに限らず、WebメールやＬＡＮ内のメールなども含むものとする。電子署名部１０は、電子メールに電子署名を施し、署名対象のデータが暗号化された電子署名でも、署名対象のデータが平文のクリア電子署名でも良い。復号部１２は受信した電子メールを暗号文から平文に復号し、検証部１４は受信した電子メール中の電子署名を検証し、検証に成功すると送信者の氏名などを出力し、検証に失敗するとその旨を出力する。

送信先テーブル１６は、送信先が暗号化や電子署名に対応しているかどうかと、それに用いる証明書やその有効期限などを記憶する。クライアントテーブル１８は、個々のもしくは複数のクライアント別のテーブルで、どの送信先に対して暗号化や電子署名が必要で、電子署名を行う場合クリア電子署名とするか否かなどを記憶する。管理者テーブル２０は、暗号メールサーバ２の管理者が管理するテーブルで、クライアントテーブル１８と同様に、どの送信先に対して暗号化が必要で、またどの送信先に対して電子署名を行い、その場合の電子署名はクリア電子署名か否かなどを記憶する。メールボックス２２は、送信メールや受信メールをクライアント毎に記憶するボックスである。

図２に暗号メールサーバ用のプログラム２４の構成を示すと、送信先テーブル作成命令２５は、図１の送信先テーブル１６を作成するための命令で、クライアントテーブル作成命令２６は、図１のクライアントテーブル１８を作成するための命令である。管理者テーブル作成命令２７は、図１の管理者テーブル２０を作成するための命令である。判別命令２８は、図１のテーブル１６，１８，２０のデータを重ね合わせて、暗号化の要否や電子署名の要否及びその形態を決定するための命令である。テーブル１６，１８，２０間の優先順位は、管理者テーブル２０が最上位で、クライアントテーブル１８がこれに次ぎ、送信先テーブル１６が最下位のテーブルである。上位のテーブルに下位のテーブルと異なる記述（データ）がある場合、上位のテーブルのデータに従い、上位のテーブルに記述が無い場合や、上位と下位とでテーブルのデータが一致する場合、下位のテーブルのデータが有効となる。実施例での暗号化メールサーバ２に関する記載は、特に断らない限りそのまま暗号化メール用のプログラム２４にも当てはまり、また暗号化メール用のプログラム２４に関する記載は、暗号化メールサーバ２にも当てはまる。

図３に送信先テーブル１６を模式的に示すと、送信先はそのドメイン名やメールアドレスなどで特定され、各送信先に対して、暗号化の要否と署名の要否や、暗号化や電子署名に用いる公開鍵、及びこれらに関する証明書のＩＤとその有効期限、などが記載されている。オプションの欄には、暗号化や署名の欄の記載を適宜に変更あるいは制限するためのデータを記載し、また電子署名の形式がクリア署名か否かなどの電子署名の形式も指定できる。送信先テーブル１６のデータは、暗号メールサーバ２が電子メールを受信した際に、暗号化が施されている、あるいは電子署名が付与されている場合などに追加する。即ち暗号文で電子メールを受信すると、その送信元のドメイン名あるいはメールアドレスなどを送信先テーブル１６に追加し、暗号化を要とする。また電子署名された電子メールを受信すると、その送信元を送信先テーブル１６に追加して、電子署名を要とする。これらの電子メールを受信した際に入手した、認証局の証明書の情報を、送信先テーブル１６に記載する。このようにして、送信先テーブル１６に記載された送信先に対して、暗号化や電子署名などを行えるようにする。

図４にクライアントテーブル１８の例を示すと、テーブルにはクライアントのローカルアドレスやパスワード，ローカルアカウントなどを記載する。またクライアントがＬＡＮの外部からアクセスする場合などに備えて、グローバルアドレスやパスワード，グローバルアカウントなどを記載する。暗号メールサーバ２で共有の暗号化鍵や署名鍵とは別の鍵を、クライアントが使用する場合、その公開鍵や秘密鍵を記憶し、また鍵の証明書のＩＤや有効期限なども記憶する。従ってクライアントは、暗号メールサーバ２に共有の公開鍵や秘密鍵により暗号化や電子署名を行うのみでなく、自己の公開鍵や秘密鍵を用いて、暗号化や電子署名を行うことができる。

クライアントテーブル１８には、ドメイン名やメールアドレスなどの送信先の単位で暗号化の要否や電子署名の要否を記述でき、電子署名を行う場合、通常の電子署名かクリア電子署名かを指定できるようにしてある。またオプションの欄には、ヘッダのサブジェクトや受取人の記載、あるいは本文中の適宜のキーワードなどを記載し、これらのキーワードのある電子メールに対して、暗号化の要否と電子署名の要否並びに電子署名の種類を記述する。このためクライアントテーブル１８を用いて、送信先や受取人、サブジェクト欄の記載、その他の適宜のキーワードなどの単位で、暗号化の要否や電子署名の要否とその形式を指定できる。

管理者テーブル２０は、図４のクライアントテーブル１８と同様のテーブルで、アドレスやパスワード，アカウントは、管理者のアドレスやパスワード，アカウントで、公開鍵や秘密鍵は管理者専用の鍵である。他の点では、クライアントテーブル１８と同様で、送信先や受取人、サブジェクト欄の記載、その他の適宜のキーワードなどの単位で、暗号化の要否や電子署名の要否とその形式を指定できる。例えば管理者テーブル２０で指定された送信先には、クライアントテーブル１８の記述に係わらず、一律に暗号化を施すように強制できる。また管理者テーブル２０で指定された送信先には、一律に暗号化を不要とすることができる。これは例えば、送信先が暗号メールサーバ２と同じイントラネット内の場合通信経路は安全だからで、管理者は、暗号メールサーバ２の負荷を調整し、かつ通信経路の安全性などに応じて、暗号化の要否などを決定できると考えられるからである。

図５に、送信先テーブル１６とクライアントテーブル１８並びに管理者テーブル２０の関係を示す。送信先テーブル１６は暗号化された電子メールを受信したことや、電子署名付きの電子メールを受信したことにより編集され、暗号化や電子署名に必要なデータを記憶しているテーブルである。そして送信先テーブル１６での暗号化や電子署名の要否は、クライアントテーブル１８や管理者テーブル２０にデータが無い際のデフォールト値を与える。

クライアントテーブル１８のデータは、送信先テーブル１６のデータに優先する。暗号化の要否や電子署名の要否並びにその種類が、送信先テーブル１６とクライアントテーブル１８とで異なる場合、クライアントテーブル１８のデータが優先する。管理者テーブル２０のデータは、送信先テーブル１６やクライアントテーブル１８のデータに優先し、送信先のアドレスやキーワードなどの単位により、暗号化や電子署名の要否を一律に決定することができる。なおクライアントテーブル１８はクライアント別のテーブルなので、クライアントにより暗号化の要否や電子署名の要否などが異なっていても良い。さらに、実施例ではテーブル１６〜２０を用いるが、これに代えて適宜のデータベースや記憶手段などを用いても良い。クライアントテーブル１８や管理者テーブル２０に、暗号化が要、あるいは電子署名が要との記述のある送信先が、送信先テーブル２０に記述されていない場合、暗号化や電子署名を行わないようにしても良い。あるいはこのような送信先に対して電子メールを送信する際に、暗号メールサーバ２から送信先に暗号化用の公開鍵やその証明書データなどを問い合わせて暗号化を行い、かつ送信先テーブル１６に暗号化要、あるいは電子署名要として、追加するようにしても良い。

送信先テーブル１６は、暗号化や電子署名をなるべく広く行うように作用する。この一方で、暗号メールサーバ２の送信元のクライアントによっては、あるいは送信先や送信先内の受取人、あるいはキーワードから推測される電子メールの種類などによっては、暗号化や電子署名が不要なことがある。また電子署名を行うにしても、送信先テーブル１６に記載された種類とは異なる種類の電子署名が必要なこともある。そこでこのような修正をクライアントテーブル１８により行う。送信先が暗号化や電子署名に対応している場合でも、暗号メールサーバ２と同じイントラネット内にあるような場合、通信路は安全で、暗号化や電子署名は不要と考えられる。そこで管理者テーブル２０で、このような送信先を暗号化や電子署名が不要と指定して、暗号化や電子署名の負担を軽減する。この逆に、管理者の方針として、送信先やキーワードなどから推測される電子メールの内容に応じて、暗号化や電子署名を強制したいことがある。このような方針は、管理者テーブル２０が他のテーブル１６，１８に優先するため、暗号メールサーバ２により守られる。

図６に、暗号メールサーバ２から同種の暗号メールサーバ２’へ、電子メール３８を送信する際のシステム構成を示す。３６はＬＡＮで、３０はインターネットファクシミリ装置などのクライアントで、暗号メールサーバ２はインターネットファクシミリ装置３０と一体にしても良い。３２はパーソナルコンピュータなどのクライアントで、３４は管理者の端末である。送信側の暗号メールサーバ２は、送信先のアドレスやドメイン名，受取人，キーワードなどにより、かつ３つのテーブル１６〜２０のデータにより、暗号化の要否や電子署名の要否とその種類などを決定する。このようにして暗号化あるいは電子署名を施した電子メール３８を送信する。

図７に、暗号化や電子署名の付与に関するアルゴリズムを示す。暗号メールサーバがクライアントなどから、外部へ送信すべき電子メールを受信すると（ステップ１）、宛先テーブルから暗号対応の宛先かどうかを判断し（ステップ２）、宛先テーブルで暗号対応でも、クライアントテーブルや管理者テーブルで暗号化に非該当かどうかを判別する（ステップ３）。そして暗号化が必要な場合、ステップ４で電子メールを暗号化する。続いて電子署名の要否を３つのテーブル１６〜２０で判別し（ステップ５）、署名が必要な場合、電子署名を指定された形式で付加する（ステップ６）。次いで送信元のアドレスをＬＡＮ内のローカルアドレスからグローバルアドレスに置換し（ステップ７）、電子メールをＷＡＮ側へ送信する（ステップ８）。

実施例では以下の効果が得られる。
(1) 暗号化や電子署名が不要な宛先にはこれらの処理を行わないようにするので、暗号メールサーバの負担を軽減できる。
(2) 暗号化や電子署名に対応している宛先を送信先テーブル１６で記憶し、かつこのデータよりもクライアントテーブルや管理者テーブルのデータを優先させるので、暗号化や電子署名の要否を柔軟に決定できる。
なお管理者テーブル２０は設けなくても良い。

実施例の暗号メールサーバのブロック図 実施例の暗号メールサーバ用のプログラムのブロック図 実施例での送信先テーブルを模式的に示す図 実施例でのクライアントテーブルを模式的に示す図 実施例での、送信先テーブルとクライアントテーブルと、管理者テーブルとの関係を示す図 実施例の暗号メールサーバを用いた通信システムの構成図 実施例でのセキュリティの要否の決定アルゴリズムを示すフローチャート

符号の説明

２，２’ 暗号メールサーバ
４ メールエージェント
６ Webサーバ
８ 暗号化部
１０ 電子署名部
１２ 復号部
１４ 検証部
１６ 送信先テーブル
１８ クライアントテーブル
２０ 管理者テーブル
２２ メールボックス
２４ 暗号メールサーバ用のプログラム
２５ 送信先テーブル作成命令
２６ クライアントテーブル作成命令
２７ 管理者テーブル作成命令
２８ 判別命令
３０ インターネットファクシミリ装置
３２ クライアント
３４ 管理者の端末
３６ ＬＡＮ
３８ 電子メール

Claims (4)

1. 暗号化手段と復号手段、もしくは電子署名手段とその検証手段とを備えた暗号メールサーバにおいて、
   送信先が暗号化に対応しているかどうか、もしくは送信先が電子署名に対応しているかどうかのデータを記憶するための送信先データの記憶手段と、送信先に対する暗号化もしくは電子署名の要否を記憶するための要否記憶手段とを設けて、
   暗号化に対応もしくは電子署名に対応した送信先に対して、要否記憶手段でのデータに従って、暗号化もしくは電子署名を施すようにしたことを特徴とする、暗号メールサーバ。
2. 前記要否記憶手段を、暗号メールサーバのクライアント別に設けたことを特徴とする、請求項１の暗号メールサーバ。
3. 前記要否記憶手段に優先する管理者データを記憶する管理者手段を設けて、管理者手段が暗号化もしくは電子署名の要否を記憶している場合はそれに従い、記憶していない場合は少なくとも要否記憶手段のデータに従って、暗号化もしくは電子署名の要否を決定するようにしたことを特徴とする、請求項２の暗号メールサーバ。
4. 暗号化手段と復号手段、もしくは電子署名手段とその検証手段とを備えた暗号メールサーバ用のプログラムにおいて、
   送信先が暗号化に対応しているかどうか、もしくは送信先が電子署名に対応しているかどうかのデータを記憶するための送信先データの記憶命令と、送信先に対する暗号化もしくは電子署名の要否を記憶するための要否記憶命令とを設けて、
   暗号化に対応もしくは電子署名に対応した送信先に対して、要否記憶命令に基づくデータに従って、暗号化もしくは電子署名を施すようにしたことを特徴とする、暗号メールサーバ用のプログラム。

Images