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