メッセージの伝送方法およびシステム、ならびにそれに適した暗号鍵発生器
送信者がまずディレクトリサービスに照会し、これに基づいて前記ディレクトリサービスが、暗号鍵ディレクトリ（８）内で受信者アドレスを検索し、前記暗号鍵ディレクトリ（８）に前記受信者アドレスが含まれる限り、前記暗号鍵ディレクトリ（８）の中の前記受信者アドレスに対して割り当てられている受信者鍵（７）を読み出して、これを前記送信者に通知し、次いで前記送信者が前記受信者鍵（７）を用いてメッセージを暗号化して前記受信者アドレスに伝送することから成るメッセージの伝送方法において、前記照会に応答して、前記暗号鍵ディレクトリ（８）に前記受信者アドレスが含まれない限り、暗号鍵発生器（１２）がゲートウェイ鍵（１３）を発生し、これを前記送信者に通知し、次いで前記送信者が、前記ゲートウェイ鍵（１３）を用いて前記メッセージを暗号化して、前記メッセージを解読するメールゲートウェイ（１１）を介して最終的に前記受信者アドレスに伝送することを特徴とする方法が開示される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、請求項１および１１の上位概念（所謂おいて部分、プリアンブル部分）に係るメッセージの伝送方法ないしはシステム、ならびに適切な暗号鍵発生器に関しており、そこでは、送信者がまずディレクトリサービスに照会し、これに基づいてディレクトリサービスが暗号鍵ディレクトリ内で受信者アドレスを検索し、暗号鍵ディレクトリに受信者アドレスが含まれる限り、暗号鍵ディレクトリの中の前記受信者アドレスに対して割り当てられている受信者鍵を読み出して、これを送信者に通知し、次いで送信者がこの受信者鍵を用いてメッセージを暗号化して受信者アドレスに伝送するようになっている。
【背景技術】
【０００２】
上述の種類の方法ないしはシステムは、広く一般に知られている。ここ数年の間に「電子郵便」（いわゆる「電子メール」）の普及率の飛躍的な上昇により、この種の通信との関連で、セキュリティ問題がますます重要性を帯びてきている。特にほかにも各地に分散した多数の社員や職員を抱える大企業、官公庁、および諸団体では、電子署名の使用により認証および完全性を保証するとともに、暗号方式の導入により伝送される情報の機密性を保証するところが増えてきている。その際には、特許を持つ様々な方式とならび、特に、国際電気通信連合(ITU: International Telecommunication Union、www.itu.int)が管理する公開鍵インフラストラクチャ(PKI: Public-Key-Infrastrukture)に関するＸ．５０９標準規格に準拠して作成された階層型認証ツリーを基盤とする「エスマイム」(S/MIME: Secure Multipurpose Internet eMail Extension)、または、階層構造を持たない「信用の輪」(Web of Trust)による公開鍵方式暗号化プログラムＯｐｅｎＰＧＰのいずれかによって、証明書所有者の識別を保証する標準規格方式も導入されている。
【０００３】
これらの公知である方法ないしはシステムでは、配信とならび、内部受信者アドレスについては様々な社内データバンクから、外部通信相手についてはほかにも様々な国際ディレクトリから、暗号鍵を照会できるようにするディレクトリサービスも提供されている。その際に、たいていの場合はエイマイム証明書が、広く一般に使用される電子メール用フロントエンドからその照会が可能であるために、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP: Lightweight Directory Access Protocol)に準拠したディレクトリサービスにより提供されるようになっている。
【０００４】
これらの公知である方法ないしはシステムでは、外部受信者アドレスについては、基本的に暗号鍵の存在を想定するのは無理である（または想定できるとしても例外事例に限られる）ために、やり取りされる電子メールを強制的に暗号化する可能性が一切もたらされてはいない。暗号鍵のない受信者アドレスは、暗号化されていない電子メールだけしか処理できないために、非暗号化通信を禁止すると同時に、これらの受信者との全ての電子メール交換が途絶えることになってしまう。
【０００５】
ローカルエリアネットワークＬＡＮの内部で非暗号化通信が許可されると、パケットを仲介したネットワークに技術上原則的に付随する「公開性」のために、電子メールの機密性は、基本的に保証されていない：非暗号化電子メールは全て―たとえば人事に関する内容や戦略上の内容を含んだ「役員会の電子メール」も含めて―、技術的に僅かな手間隙をかけるだけで、そのネットに加入する者なら誰でも閲覧できてしまう。
【０００６】
さらにそれに追加して、従業員が携帯端末を利用し、いわゆるプッシュサービスを介して電子メールを受け取ったり書いたりする場合は、非暗号化社内通信により新たなセキュリティ問題が投げかけられることになる。そのようなプッシュサービスの一般に知られる実行方式においては、プッシュサーバが、あたかも内部加入者であるかのようにＬＡＮの内部に組み込まれて、このプロバイダの世界中に分散しているノード計算機および携帯電話事業者各社の様々なサービスへの独自のインターネット接続を介して、携帯端末による電子メール通信を仲介するようになっている。
【０００７】
そこでは、そのようなプッシュサーバが、ＬＡＮの内部で、その職責を果たすために必要なアクセス権に基づいて、ネットワーク内に配信された全ての電子メールにアクセスして、ノード計算機を介してこれらを転送することが、理論上は可能となっている。これらのノード計算機は、ＬＡＮ運営者の管理下にはないために、この観点から、そのセキュリティ性および機密保持性を保証し追検査するのは不可能である。それにより、少なくとも理論上は、情報が権限のない者の手にわたる怖れを生じている。
【０００８】
それに加えてさらに、ＬＡＮの内部でそれ以外にも無署名通信が許可されていると、電子メールが、偽造識別コードを使用して送信または傍受されたり、後から変更されたりしかねないために、そのような電子メールはみな、認証および識別が基本的に疑問視されることになる。無署名電子メールについては、法的効力を持つ意思表示として、これを扱うことが許されないことは、原則であるばかりではない―それに加えてさらに、無署名通信が許可されるところでは、他人の信用を落とす目的でデマを故意に流すこと（いわゆる「モビング」）を防ぐことは、基本的に不可能である。要するに、社内ＬＡＮにおいても非暗号化および／または無署名通信が許可されている場合は、技術管理コストも、また通信に関する行動規則の定義（および規則遵守の検査）に対する要求も増大するのが通例である。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、通信相手の選択に制限を課すことなく、ＬＡＮの内部で全てのメッセージの暗号化を可能とすることを課題としてなされたものである。
【課題を解決するための手段】
【００１０】
この課題は、方法については請求項１の各特徴により、また装置については請求項１１または２４の各特徴により解決される。
本出願においては、暗号鍵ディレクトリに受信者アドレスが含まれない限り、暗号鍵発生器がゲートウェイ鍵を発生して、これを送信者に通知し、次いで送信者が、このゲートウェイ鍵を用いてメッセージを暗号化して、メッセージを解読するメールゲートウェイ（１１）を介して最終的に受信者アドレスに伝送することが提案される。
【００１１】
送信者には、本出願にしたがって、ディレクトリサービスから、または暗号鍵発生器から、当該する照会に応答して、メッセージの暗号化に適した暗号鍵―具体的には受信者鍵またはゲートウェイ鍵のいずれか―が、常に通知されるようになっている。したがって、送信者のメールサーバによりＬＡＮから出て任意の受信者アドレスに仲介されるメッセージの暗号化は、内部または外部の暗号鍵ディレクトリの中に、この受信者アドレスに関する受信者鍵が存在するか否かに関係なく、行われるようになる。また、照会を受けて受信者鍵を確認することができなかった受信者アドレスについても、本発明にしたった方法により、その場合には送信者側でゲートウェイ鍵を用いた暗号化が行われるために、それにもかかわらずこの受信者アドレスとの通信は無制限で可能となる：ゲートウェイ鍵を用いて暗号化されたメッセージは、ＬＡＮから出てメールゲートウェイに到達すると、続いていったん解読され、解読された形式で（すなわちプレーンテキストで）外部受信者アドレスに転送される。電子メール通信に関する相応の行動規則と抱き合わせることによって、またはほかにもＬＡＮの内部でメッセージの非暗号化送信を禁止または不可能とする技術対策によっても、ＬＡＮの内部の全送信者からメールゲートウェイを介して仲介される全メッセージの暗号化を保証することができる。
【００１２】
本出願にしたがった方法ないしはシステムは、これと同様の形式で、ほかにも別のメッセージ・プッシュサービスと一緒に導入することもできる。そのようなサービスは、受信者との対話による受信者鍵の照会が行われない「ストア・アンド・フォワード」原理に基づいた通信により、傑出したものとなっている。この場合は「メールゲートウェイ」という概念に、そのようなプッシュサービス用のゲートウェイも含まれることになる。
【００１３】
本出願にしたがった対象の有利な展開構成例は、従属請求項の特徴により説明される。
暗号鍵を発生する前に、受信者アドレスの有効性を検査できるようにすると有利であるが、なぜなら暗号化が意味をなすのは、受信者もこれを読むことができる場合に限られるからである。そのためには、受信者が付属のプライベート鍵の提供を受けることが必要である、または誰かほかの者が受信者のために電子メールを解読することが必要である。ほかにも、電子メールアドレスが実在しており、正確に書かれることが必要である。
【００１４】
受信者アドレスの有効性検査は、受信者の電子メールサーバへの照会により行うことができるようにすると有利である。これに対し、受信者のディレクトリサービス、特に公的ディレクトリサービスが既知である場合には、そこに照会することも、それに代わる選択肢となる。送信者に受信者アドレスに関する暗号鍵が一切提供されない場合は、受信者アドレスが実在しないことが、電子メールの送信前に、送信者にわかる。したがって送信者は、送信者の電子メールクライアントのコンフィギュレーション次第では、この電子メールを全く送信しないで済む。それにより、ともすれば機密の電子メールが、配信不能を理由として、インターネット内にとどまってしまうこと、または、たとえば手作業で問題を取り除くために、アドミニストレータに転送されることが防止される。アドミニストレータは通常、内容を見る権限を持ち合わせてはいないが、非暗号化電子メールであれば、いつでもその内容を見ることができてしまう。
【００１５】
内部ディレクトリサービスへの照会は、それによってさらに受信者に関するメタ情報（実名、組織構造における地位、役職、…）を入手する可能性がもたらされるようにすると有利である。それにより、作成される証明書に、電子メールアドレスだけよりも多くの情報を含ませることが可能となる。これは、たとえばＸ．５０９標準規格においては、証明書が公開鍵インフラストラクチャ(PKI)により手作業で発行される場合の、通常のケースに相当する。それにより外部送信者は、付加的な、場合によっては大いに参考となる情報を含んだ高価値の証明書の提供を受けることになる。当然ながら望ましくないメタ情報については、公表されないようにするとよい。それ以外にも、これらのメタ情報に基づいて、作成された証明書の特性、たとえば暗号鍵の長さ、有効期限、暗号鍵の取消しや発行に関する権限などを管理できるようにすると有利である。特に中央ゲートウェイが、暗号鍵発生権限を持つ様々な認証機関(CA: Certificate Authority)と協力する場合は、これらのメタ情報から、暗号鍵発生の所轄認証機関を読み出すことができる。
【００１６】
暗号鍵発生器は、本出願にしたがった方法ないしはシステムの枠内においては、受信者アドレスに個人化されたゲートウェイ鍵を発生することが好ましい。本発明にしたがったそのような方法ないしはシステムにより、ＬＡＮの内部の送信者が、標準規格に対して機能性が制限されて個人化された証明書の使用だけが許容されている、広く普及している電子メール・フロントエンド（たとえばマイクロソフト社のアウトルック Microsoft(登録商標)Outlook(登録商標)など)を導入することも可能となる。
【００１７】
ゲートウェイ鍵は、暗号鍵ディレクトリ内で受信者アドレスに対して割り当てられるようにすると、非常に好適である。その場合ゲートウェイ鍵は、初回の照会を機にこれが発生された後には、その後の新たな照会に際して、再度の計算を不要としてＬＡＮから提供されるようになる。そのような方法ないしはシステムは、一方では、ゲートウェイ鍵を記憶しない方法と比べて必要となる計算工数が僅かとなる（記憶工数は増大するが、記憶媒体の値段を考えると、たいしたものではない）。他方では、ゲート鍵を用いて送信者側で暗号化されるメッセージは、時間的に多少遅れて初めてメールゲートウェイに入る場合にも、メールゲートウェイによりなおも解読可能であることが保証されなければならない。これについて、ゲートウェイ鍵の有効期限は、数日間、たとえば一週間に限定されることが好ましい。ゲートウェイ鍵は、特に暗号鍵発生器に対して直接配置される一つのキャッシュメモリに記憶されるようにするとよい。
【００１８】
有利な実施例において、暗号鍵発生器は、ゲートウェイ鍵と一緒に、これに対して割り当てられる解読鍵を発生して、メールゲートウェイは、この解読鍵を用いてメッセージを解読するようになっている。すなわちそのような方法ないしはシステムは、メッセージが送信者側で公開鍵を用いて（ここでは：ゲートウェイ鍵を用いて）暗号化されて、受信者側（ここでは：メールゲートウェイ）で、受信者だけに知られている秘密の「プライベート」鍵を用いて（ここでは：解読鍵を用いて）解読されるという、非対称暗号化方式を使用している。その代案として導入可能な、暗号化と解読のために同じ暗号鍵が使用される対称暗号化方式に対し、非対称暗号化方式は、解読のために必要な暗号鍵の意図せざる流布による被害を受けにくくなる。
【００１９】
ゲートウェイ鍵は、証明書の一部であると非常に好適である。特にエスマイム証明書により、これが広く普及しており、また全ての関連フロントエンドにインプレメントされていることから、たいていの場合は補助的なプログラムがなくとも、本発明にしたがった方法を実施することが可能となる。
【００２０】
メッセージは、送信者からメールサーバを介して受信者アドレスに伝送されることが好ましい。その際にこのメールサーバは―大規模企業ネットワークにおいては一般であるように―ＬＡＮの内部インフラストラクチャの一部であるとよい。この場合は、メールゲートウェイがメールサーバとインターネット間に配置されるのが通例である。あるいはその代わりに、従業員各自がＬＡＮの内部で自分の電子メールメッセージを外部のシンプルメール転送プロトコル(SMTP: Simple Mail Transfer Protocol)サーバから取り寄せる場合は、本発明にしたがった方法を、ＬＡＮの枠内で、独自のメールサーバなしで、導入することもできる。
【００２１】
外部に送られる電子メールに、それまでに存在していなかった暗号鍵を用いて署名するために、既存のメールゲートウェイが暗号鍵発生器を利用できるようにすると有利である。その他の有利な実施形態は、別の請求項の対象となっている。
【発明を実施するための最良の形態】
【００２２】
次に本出願にしたがった対象を実施例に基づき説明する。図面には、本発明にしたがった方法ないしはシステムの様々な実施の局面が図式的に示されている。
ケーブルで接続された社内ＬＡＮ１においては、図１に示されるように、従業員４の画面作業所２および携帯端末３が相互にネットワーク化されている。内部認証局５は、各従業員４に、たとえば（図示されない）ハードウェアトークンに記憶される、電子メールに署名するための個人化された暗号鍵６を提供する。この内部認証局５は、社内暗号鍵ディレクトリ８内で、従業員４宛ての電子メールを暗号化するための公開受信者鍵７を、各従業員４の付属のメタ情報と一緒に公開するようになっている。
【００２３】
従業員４の、ＬＡＮ１から出る、インターネット１０を介しての外部の相手９との通信は、メールゲートウェイ１１により管理される。この「ゲートウェイ」という（国際標準化機構の規格ＩＳＯ７４９８−１ないしはドイツ工業規格ＤＩＮ ＩＳＯ ７４９８に定められた開放型システム間相互接続(OSI: Open Systems Interconnection）階層モデルの用語集に準拠した）名称は、ここでは、―メールサーバの機能が転送専用であるのに対し―伝送されるデータの形式および内容が、この場所において、その時々の受信者の要件に対して適合化されることを明確にするものである。メールゲートウェイ１１は、ここに示されるケースにおいては（以下で説明するさらに別の構成部品と協力して）、ＬＡＮ１の内部で流布される電子メールメッセージが、―これが暗号化されて相手９に転送されたのか、それとも相手９から署名付きでまたは暗号化されて受信されたのかに関係なく―常に署名されると同時に暗号化されることを保証するようになっている。
【００２４】
従業員は、電子メールを外部の相手９宛てに書きたい場合は、自分の（図示されない）フロントエンドでまずこの相手９の受信者アドレスを選択する。フロントエンドは自動的にディレクトリサービスに照会を送り、ディレクトリサービスは、電子メールを暗号化するために、最初に暗号鍵のローカルディレクトリ８の中で、続いて様々な（図示されない）暗号鍵の外部ディレクトリの中で、受信者アドレスに基づいて受信者鍵７を確認しようと試みる。成功した場合は、確認された受信者鍵７がフロントエンドに転送される。外部ディレクトリの中の一つで初めて照会に成功した場合は、確認された受信者鍵７が今後の使用に備え、暗号鍵のローカルディレクトリ８に一時記憶される。
【００２５】
暗号鍵のローカルディレクトリ８でも、また暗号鍵の外部ディレクトリでも、照会に成功しない場合は、この照会が、メールゲートウェイ１１に接続された暗号鍵発生器１２に転送され、これが、受信者アドレスに対して公開ゲートウェイ鍵１３を発生して、フロントエンドに送信する。同時に暗号鍵発生器１２は、「プライベート」解読鍵１４を発生して、これをメールゲートウェイ１１に転送する。フロントエンドは、このゲートウェイ鍵１３を用いて電子メールを暗号化して、これをメールゲートウェイ１１に送信する。メールゲートウェイ１１は、解読鍵１４に基づきこの電子メールを解読して、これを―暗号化されない状態で―インターネット１０を介して外部の相手９に転送する。
【００２６】
メールゲートウェイ１１の使用により、内部メールサーバ１５およびこれに図２に示されるように接続されるプッシュサーバ１６を含めて、ＬＡＮ１の内部での全ての電子メール通信の署名および暗号化が可能となる。
【００２７】
図３には、スパムおよびウィルススキャナ１７のゲートウェイ・アーキテクチャへの組み込み方式が示されている。これは、内部メールゲートウェイ１１と第２の外部メールゲートウェイ１８との間に配置されている。外部メールゲートウェイ１８は（図示されない方式により）各従業員４のさらにもう一つの個人鍵１９へのアクセス権を有している。（従業員４の暗号鍵６および１９は、同一であってもよい。）この暗号鍵１９に基づき、外部メールゲートウェイ１８は、外部から従業員４に暗号化されて届けられる電子メール通信を解読し、これをスパムおよびウィルススキャナ１７に転送する。これが、届けられた電子メールについて警告を発すると、受信者に自動的に、その後の手順に関する指示を含めて通知が行われる。警告が発せられない場合は、その旨の表示を付されて、電子メールが内部メールゲートウェイ１１に転送され、これが、受信者の公開鍵を用いて電子メールを暗号化するとともに、たとえば内部メールゲートウェイ１１の解読鍵１４を用いてこれに署名するようになっている。
【００２８】
これと同様にして、署名なしで、または暗号化されずにインターネット１０から届けられる電子メールについても、相応の表示が付され、受信者の公開鍵を用いて事後に暗号化されるとともに、たとえば内部メールゲートウェイ１１の解読鍵１４を用いて署名されるようにしている。ほかにもメールサーバ１５は、非暗号化または無署名電子メールを基本的に受信者に転送しないのではなくて、むしろ送信者にエラーメッセージを返信するように構成されている。このように、内部メールゲートウェイ１１の上述の機能と組み合わせることにより、特に暗号鍵発生器１２と抱き合わせた場合は、ＬＡＮ１を介して流布する全ての電子メール通信が―プッシュサービスを介した通信を含めて―署名されると同時に暗号化されることが保証される。
【００２９】
ここで再度、受信者アドレスの有効性検査の有利な使用法について説明する。これについて付言するが、送信者およびゲートウェイないしはディレクトリサービスが自分の組織に所属しており、かつ、外に出る、すなわちインターネットまたはその類に向かって送られる電子メールが暗号化される必要がある場合に顧慮されるのは、任意の受信者である。
【００３０】
外部送信者が電子メールをゲートウェイおよびディレクトリサービスを擁する組織に送ろうとする場合に問題となるのは、組織のドメインの内部の受信者だけである。それ以外にも、電子メールアドレスについては、現実のアドレスがポストボックス内に存在しなければならない。
【００３１】
このため、暗号鍵のペアを発生する前に、照会を受けた電子メールアドレスが、自分のドメインの内部にあるか否か、および、それ用のポストボックスがあるか否かについて、検査が行われると有利である。前者については、相応の管理機構が検査を行うことにより、可能となる。後者については、内部ユーザディレクトリまたは内部メールサーバへの照会を通じて検査することができる。それにより、実在しない電子メールアドレスを持つ暗号鍵が一切流通しないことが保証される。送信者には、たとえば電子メールアドレスの書き方を誤ったことが、早めにわかるようになる。ほかにも、無意味な暗号鍵を発生する必要がなくなるために、暗号鍵発生サービスの負担が軽減される。
【００３２】
それ以外にも、暗号鍵および場合によってはプライベート鍵を、アーカイビングのために内部ディレクトリに伝送することも可能である。暗号鍵のデータ紛失に対するセキュリティ対策（バックアップ）、ならびに、電子メールの後から暗号化されたバージョンを解読できる可能性があると有利である。場合によっては、暗号鍵をいつでも使用できるように中央で準備しておくことは、組織上または法律上の義務ともなる。
【００３３】
基本的には、複数の内部ディレクトリサービスまたは電子メールサーバに照会可能であることが、強調されるべきである。
【図面の簡単な説明】
【００３４】
【図１】暗号鍵の取り扱い方式を示す図である。
【図２】プッシュサーバの組み込み方式を示す図である。
【図３】ウィルスおよびスパム防御機能の組み込み方式を示す図である。
【符号の説明】
【００３５】
１ ＬＡＮ
２ 画面作業所
３ 携帯端末
４ 従業員
５ 内部認証局
６ 個人化された暗号鍵
７ 受信者鍵
８ 暗号鍵ディレクトリ
９ 外部の相手
１０ インターネット
１１ （内部）メールゲートウェイ
１２ 暗号鍵発生器
１３ ゲートウェイ鍵
１４ 「プライベート」解読鍵
１５ メールサーバ
１６ プッシュサーバ
１７ スパムおよびウィルススキャナ
１８ 外部メールゲートウェイ
１９ 個人鍵
【技術分野】
【０００１】
本発明は、請求項１および１１の上位概念（所謂おいて部分、プリアンブル部分）に係るメッセージの伝送方法ないしはシステム、ならびに適切な暗号鍵発生器に関しており、そこでは、送信者がまずディレクトリサービスに照会し、これに基づいてディレクトリサービスが暗号鍵ディレクトリ内で受信者アドレスを検索し、暗号鍵ディレクトリに受信者アドレスが含まれる限り、暗号鍵ディレクトリの中の前記受信者アドレスに対して割り当てられている受信者鍵を読み出して、これを送信者に通知し、次いで送信者がこの受信者鍵を用いてメッセージを暗号化して受信者アドレスに伝送するようになっている。
【背景技術】
【０００２】
上述の種類の方法ないしはシステムは、広く一般に知られている。ここ数年の間に「電子郵便」（いわゆる「電子メール」）の普及率の飛躍的な上昇により、この種の通信との関連で、セキュリティ問題がますます重要性を帯びてきている。特にほかにも各地に分散した多数の社員や職員を抱える大企業、官公庁、および諸団体では、電子署名の使用により認証および完全性を保証するとともに、暗号方式の導入により伝送される情報の機密性を保証するところが増えてきている。その際には、特許を持つ様々な方式とならび、特に、国際電気通信連合(ITU: International Telecommunication Union、www.itu.int)が管理する公開鍵インフラストラクチャ(PKI: Public-Key-Infrastrukture)に関するＸ．５０９標準規格に準拠して作成された階層型認証ツリーを基盤とする「エスマイム」(S/MIME: Secure Multipurpose Internet eMail Extension)、または、階層構造を持たない「信用の輪」(Web of Trust)による公開鍵方式暗号化プログラムＯｐｅｎＰＧＰのいずれかによって、証明書所有者の識別を保証する標準規格方式も導入されている。
【０００３】
これらの公知である方法ないしはシステムでは、配信とならび、内部受信者アドレスについては様々な社内データバンクから、外部通信相手についてはほかにも様々な国際ディレクトリから、暗号鍵を照会できるようにするディレクトリサービスも提供されている。その際に、たいていの場合はエイマイム証明書が、広く一般に使用される電子メール用フロントエンドからその照会が可能であるために、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP: Lightweight Directory Access Protocol)に準拠したディレクトリサービスにより提供されるようになっている。
【０００４】
これらの公知である方法ないしはシステムでは、外部受信者アドレスについては、基本的に暗号鍵の存在を想定するのは無理である（または想定できるとしても例外事例に限られる）ために、やり取りされる電子メールを強制的に暗号化する可能性が一切もたらされてはいない。暗号鍵のない受信者アドレスは、暗号化されていない電子メールだけしか処理できないために、非暗号化通信を禁止すると同時に、これらの受信者との全ての電子メール交換が途絶えることになってしまう。
【０００５】
ローカルエリアネットワークＬＡＮの内部で非暗号化通信が許可されると、パケットを仲介したネットワークに技術上原則的に付随する「公開性」のために、電子メールの機密性は、基本的に保証されていない：非暗号化電子メールは全て―たとえば人事に関する内容や戦略上の内容を含んだ「役員会の電子メール」も含めて―、技術的に僅かな手間隙をかけるだけで、そのネットに加入する者なら誰でも閲覧できてしまう。
【０００６】
さらにそれに追加して、従業員が携帯端末を利用し、いわゆるプッシュサービスを介して電子メールを受け取ったり書いたりする場合は、非暗号化社内通信により新たなセキュリティ問題が投げかけられることになる。そのようなプッシュサービスの一般に知られる実行方式においては、プッシュサーバが、あたかも内部加入者であるかのようにＬＡＮの内部に組み込まれて、このプロバイダの世界中に分散しているノード計算機および携帯電話事業者各社の様々なサービスへの独自のインターネット接続を介して、携帯端末による電子メール通信を仲介するようになっている。
【０００７】
そこでは、そのようなプッシュサーバが、ＬＡＮの内部で、その職責を果たすために必要なアクセス権に基づいて、ネットワーク内に配信された全ての電子メールにアクセスして、ノード計算機を介してこれらを転送することが、理論上は可能となっている。これらのノード計算機は、ＬＡＮ運営者の管理下にはないために、この観点から、そのセキュリティ性および機密保持性を保証し追検査するのは不可能である。それにより、少なくとも理論上は、情報が権限のない者の手にわたる怖れを生じている。
【０００８】
それに加えてさらに、ＬＡＮの内部でそれ以外にも無署名通信が許可されていると、電子メールが、偽造識別コードを使用して送信または傍受されたり、後から変更されたりしかねないために、そのような電子メールはみな、認証および識別が基本的に疑問視されることになる。無署名電子メールについては、法的効力を持つ意思表示として、これを扱うことが許されないことは、原則であるばかりではない―それに加えてさらに、無署名通信が許可されるところでは、他人の信用を落とす目的でデマを故意に流すこと（いわゆる「モビング」）を防ぐことは、基本的に不可能である。要するに、社内ＬＡＮにおいても非暗号化および／または無署名通信が許可されている場合は、技術管理コストも、また通信に関する行動規則の定義（および規則遵守の検査）に対する要求も増大するのが通例である。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、通信相手の選択に制限を課すことなく、ＬＡＮの内部で全てのメッセージの暗号化を可能とすることを課題としてなされたものである。
【課題を解決するための手段】
【００１０】
この課題は、方法については請求項１の各特徴により、また装置については請求項１１または２４の各特徴により解決される。
本出願においては、暗号鍵ディレクトリに受信者アドレスが含まれない限り、暗号鍵発生器がゲートウェイ鍵を発生して、これを送信者に通知し、次いで送信者が、このゲートウェイ鍵を用いてメッセージを暗号化して、メッセージを解読するメールゲートウェイ（１１）を介して最終的に受信者アドレスに伝送することが提案される。
【００１１】
送信者には、本出願にしたがって、ディレクトリサービスから、または暗号鍵発生器から、当該する照会に応答して、メッセージの暗号化に適した暗号鍵―具体的には受信者鍵またはゲートウェイ鍵のいずれか―が、常に通知されるようになっている。したがって、送信者のメールサーバによりＬＡＮから出て任意の受信者アドレスに仲介されるメッセージの暗号化は、内部または外部の暗号鍵ディレクトリの中に、この受信者アドレスに関する受信者鍵が存在するか否かに関係なく、行われるようになる。また、照会を受けて受信者鍵を確認することができなかった受信者アドレスについても、本発明にしたった方法により、その場合には送信者側でゲートウェイ鍵を用いた暗号化が行われるために、それにもかかわらずこの受信者アドレスとの通信は無制限で可能となる：ゲートウェイ鍵を用いて暗号化されたメッセージは、ＬＡＮから出てメールゲートウェイに到達すると、続いていったん解読され、解読された形式で（すなわちプレーンテキストで）外部受信者アドレスに転送される。電子メール通信に関する相応の行動規則と抱き合わせることによって、またはほかにもＬＡＮの内部でメッセージの非暗号化送信を禁止または不可能とする技術対策によっても、ＬＡＮの内部の全送信者からメールゲートウェイを介して仲介される全メッセージの暗号化を保証することができる。
【００１２】
本出願にしたがった方法ないしはシステムは、これと同様の形式で、ほかにも別のメッセージ・プッシュサービスと一緒に導入することもできる。そのようなサービスは、受信者との対話による受信者鍵の照会が行われない「ストア・アンド・フォワード」原理に基づいた通信により、傑出したものとなっている。この場合は「メールゲートウェイ」という概念に、そのようなプッシュサービス用のゲートウェイも含まれることになる。
【００１３】
本出願にしたがった対象の有利な展開構成例は、従属請求項の特徴により説明される。
暗号鍵を発生する前に、受信者アドレスの有効性を検査できるようにすると有利であるが、なぜなら暗号化が意味をなすのは、受信者もこれを読むことができる場合に限られるからである。そのためには、受信者が付属のプライベート鍵の提供を受けることが必要である、または誰かほかの者が受信者のために電子メールを解読することが必要である。ほかにも、電子メールアドレスが実在しており、正確に書かれることが必要である。
【００１４】
受信者アドレスの有効性検査は、受信者の電子メールサーバへの照会により行うことができるようにすると有利である。これに対し、受信者のディレクトリサービス、特に公的ディレクトリサービスが既知である場合には、そこに照会することも、それに代わる選択肢となる。送信者に受信者アドレスに関する暗号鍵が一切提供されない場合は、受信者アドレスが実在しないことが、電子メールの送信前に、送信者にわかる。したがって送信者は、送信者の電子メールクライアントのコンフィギュレーション次第では、この電子メールを全く送信しないで済む。それにより、ともすれば機密の電子メールが、配信不能を理由として、インターネット内にとどまってしまうこと、または、たとえば手作業で問題を取り除くために、アドミニストレータに転送されることが防止される。アドミニストレータは通常、内容を見る権限を持ち合わせてはいないが、非暗号化電子メールであれば、いつでもその内容を見ることができてしまう。
【００１５】
内部ディレクトリサービスへの照会は、それによってさらに受信者に関するメタ情報（実名、組織構造における地位、役職、…）を入手する可能性がもたらされるようにすると有利である。それにより、作成される証明書に、電子メールアドレスだけよりも多くの情報を含ませることが可能となる。これは、たとえばＸ．５０９標準規格においては、証明書が公開鍵インフラストラクチャ(PKI)により手作業で発行される場合の、通常のケースに相当する。それにより外部送信者は、付加的な、場合によっては大いに参考となる情報を含んだ高価値の証明書の提供を受けることになる。当然ながら望ましくないメタ情報については、公表されないようにするとよい。それ以外にも、これらのメタ情報に基づいて、作成された証明書の特性、たとえば暗号鍵の長さ、有効期限、暗号鍵の取消しや発行に関する権限などを管理できるようにすると有利である。特に中央ゲートウェイが、暗号鍵発生権限を持つ様々な認証機関(CA: Certificate Authority)と協力する場合は、これらのメタ情報から、暗号鍵発生の所轄認証機関を読み出すことができる。
【００１６】
暗号鍵発生器は、本出願にしたがった方法ないしはシステムの枠内においては、受信者アドレスに個人化されたゲートウェイ鍵を発生することが好ましい。本発明にしたがったそのような方法ないしはシステムにより、ＬＡＮの内部の送信者が、標準規格に対して機能性が制限されて個人化された証明書の使用だけが許容されている、広く普及している電子メール・フロントエンド（たとえばマイクロソフト社のアウトルック Microsoft(登録商標)Outlook(登録商標)など)を導入することも可能となる。
【００１７】
ゲートウェイ鍵は、暗号鍵ディレクトリ内で受信者アドレスに対して割り当てられるようにすると、非常に好適である。その場合ゲートウェイ鍵は、初回の照会を機にこれが発生された後には、その後の新たな照会に際して、再度の計算を不要としてＬＡＮから提供されるようになる。そのような方法ないしはシステムは、一方では、ゲートウェイ鍵を記憶しない方法と比べて必要となる計算工数が僅かとなる（記憶工数は増大するが、記憶媒体の値段を考えると、たいしたものではない）。他方では、ゲート鍵を用いて送信者側で暗号化されるメッセージは、時間的に多少遅れて初めてメールゲートウェイに入る場合にも、メールゲートウェイによりなおも解読可能であることが保証されなければならない。これについて、ゲートウェイ鍵の有効期限は、数日間、たとえば一週間に限定されることが好ましい。ゲートウェイ鍵は、特に暗号鍵発生器に対して直接配置される一つのキャッシュメモリに記憶されるようにするとよい。
【００１８】
有利な実施例において、暗号鍵発生器は、ゲートウェイ鍵と一緒に、これに対して割り当てられる解読鍵を発生して、メールゲートウェイは、この解読鍵を用いてメッセージを解読するようになっている。すなわちそのような方法ないしはシステムは、メッセージが送信者側で公開鍵を用いて（ここでは：ゲートウェイ鍵を用いて）暗号化されて、受信者側（ここでは：メールゲートウェイ）で、受信者だけに知られている秘密の「プライベート」鍵を用いて（ここでは：解読鍵を用いて）解読されるという、非対称暗号化方式を使用している。その代案として導入可能な、暗号化と解読のために同じ暗号鍵が使用される対称暗号化方式に対し、非対称暗号化方式は、解読のために必要な暗号鍵の意図せざる流布による被害を受けにくくなる。
【００１９】
ゲートウェイ鍵は、証明書の一部であると非常に好適である。特にエスマイム証明書により、これが広く普及しており、また全ての関連フロントエンドにインプレメントされていることから、たいていの場合は補助的なプログラムがなくとも、本発明にしたがった方法を実施することが可能となる。
【００２０】
メッセージは、送信者からメールサーバを介して受信者アドレスに伝送されることが好ましい。その際にこのメールサーバは―大規模企業ネットワークにおいては一般であるように―ＬＡＮの内部インフラストラクチャの一部であるとよい。この場合は、メールゲートウェイがメールサーバとインターネット間に配置されるのが通例である。あるいはその代わりに、従業員各自がＬＡＮの内部で自分の電子メールメッセージを外部のシンプルメール転送プロトコル(SMTP: Simple Mail Transfer Protocol)サーバから取り寄せる場合は、本発明にしたがった方法を、ＬＡＮの枠内で、独自のメールサーバなしで、導入することもできる。
【００２１】
外部に送られる電子メールに、それまでに存在していなかった暗号鍵を用いて署名するために、既存のメールゲートウェイが暗号鍵発生器を利用できるようにすると有利である。その他の有利な実施形態は、別の請求項の対象となっている。
【発明を実施するための最良の形態】
【００２２】
次に本出願にしたがった対象を実施例に基づき説明する。図面には、本発明にしたがった方法ないしはシステムの様々な実施の局面が図式的に示されている。
ケーブルで接続された社内ＬＡＮ１においては、図１に示されるように、従業員４の画面作業所２および携帯端末３が相互にネットワーク化されている。内部認証局５は、各従業員４に、たとえば（図示されない）ハードウェアトークンに記憶される、電子メールに署名するための個人化された暗号鍵６を提供する。この内部認証局５は、社内暗号鍵ディレクトリ８内で、従業員４宛ての電子メールを暗号化するための公開受信者鍵７を、各従業員４の付属のメタ情報と一緒に公開するようになっている。
【００２３】
従業員４の、ＬＡＮ１から出る、インターネット１０を介しての外部の相手９との通信は、メールゲートウェイ１１により管理される。この「ゲートウェイ」という（国際標準化機構の規格ＩＳＯ７４９８−１ないしはドイツ工業規格ＤＩＮ ＩＳＯ ７４９８に定められた開放型システム間相互接続(OSI: Open Systems Interconnection）階層モデルの用語集に準拠した）名称は、ここでは、―メールサーバの機能が転送専用であるのに対し―伝送されるデータの形式および内容が、この場所において、その時々の受信者の要件に対して適合化されることを明確にするものである。メールゲートウェイ１１は、ここに示されるケースにおいては（以下で説明するさらに別の構成部品と協力して）、ＬＡＮ１の内部で流布される電子メールメッセージが、―これが暗号化されて相手９に転送されたのか、それとも相手９から署名付きでまたは暗号化されて受信されたのかに関係なく―常に署名されると同時に暗号化されることを保証するようになっている。
【００２４】
従業員は、電子メールを外部の相手９宛てに書きたい場合は、自分の（図示されない）フロントエンドでまずこの相手９の受信者アドレスを選択する。フロントエンドは自動的にディレクトリサービスに照会を送り、ディレクトリサービスは、電子メールを暗号化するために、最初に暗号鍵のローカルディレクトリ８の中で、続いて様々な（図示されない）暗号鍵の外部ディレクトリの中で、受信者アドレスに基づいて受信者鍵７を確認しようと試みる。成功した場合は、確認された受信者鍵７がフロントエンドに転送される。外部ディレクトリの中の一つで初めて照会に成功した場合は、確認された受信者鍵７が今後の使用に備え、暗号鍵のローカルディレクトリ８に一時記憶される。
【００２５】
暗号鍵のローカルディレクトリ８でも、また暗号鍵の外部ディレクトリでも、照会に成功しない場合は、この照会が、メールゲートウェイ１１に接続された暗号鍵発生器１２に転送され、これが、受信者アドレスに対して公開ゲートウェイ鍵１３を発生して、フロントエンドに送信する。同時に暗号鍵発生器１２は、「プライベート」解読鍵１４を発生して、これをメールゲートウェイ１１に転送する。フロントエンドは、このゲートウェイ鍵１３を用いて電子メールを暗号化して、これをメールゲートウェイ１１に送信する。メールゲートウェイ１１は、解読鍵１４に基づきこの電子メールを解読して、これを―暗号化されない状態で―インターネット１０を介して外部の相手９に転送する。
【００２６】
メールゲートウェイ１１の使用により、内部メールサーバ１５およびこれに図２に示されるように接続されるプッシュサーバ１６を含めて、ＬＡＮ１の内部での全ての電子メール通信の署名および暗号化が可能となる。
【００２７】
図３には、スパムおよびウィルススキャナ１７のゲートウェイ・アーキテクチャへの組み込み方式が示されている。これは、内部メールゲートウェイ１１と第２の外部メールゲートウェイ１８との間に配置されている。外部メールゲートウェイ１８は（図示されない方式により）各従業員４のさらにもう一つの個人鍵１９へのアクセス権を有している。（従業員４の暗号鍵６および１９は、同一であってもよい。）この暗号鍵１９に基づき、外部メールゲートウェイ１８は、外部から従業員４に暗号化されて届けられる電子メール通信を解読し、これをスパムおよびウィルススキャナ１７に転送する。これが、届けられた電子メールについて警告を発すると、受信者に自動的に、その後の手順に関する指示を含めて通知が行われる。警告が発せられない場合は、その旨の表示を付されて、電子メールが内部メールゲートウェイ１１に転送され、これが、受信者の公開鍵を用いて電子メールを暗号化するとともに、たとえば内部メールゲートウェイ１１の解読鍵１４を用いてこれに署名するようになっている。
【００２８】
これと同様にして、署名なしで、または暗号化されずにインターネット１０から届けられる電子メールについても、相応の表示が付され、受信者の公開鍵を用いて事後に暗号化されるとともに、たとえば内部メールゲートウェイ１１の解読鍵１４を用いて署名されるようにしている。ほかにもメールサーバ１５は、非暗号化または無署名電子メールを基本的に受信者に転送しないのではなくて、むしろ送信者にエラーメッセージを返信するように構成されている。このように、内部メールゲートウェイ１１の上述の機能と組み合わせることにより、特に暗号鍵発生器１２と抱き合わせた場合は、ＬＡＮ１を介して流布する全ての電子メール通信が―プッシュサービスを介した通信を含めて―署名されると同時に暗号化されることが保証される。
【００２９】
ここで再度、受信者アドレスの有効性検査の有利な使用法について説明する。これについて付言するが、送信者およびゲートウェイないしはディレクトリサービスが自分の組織に所属しており、かつ、外に出る、すなわちインターネットまたはその類に向かって送られる電子メールが暗号化される必要がある場合に顧慮されるのは、任意の受信者である。
【００３０】
外部送信者が電子メールをゲートウェイおよびディレクトリサービスを擁する組織に送ろうとする場合に問題となるのは、組織のドメインの内部の受信者だけである。それ以外にも、電子メールアドレスについては、現実のアドレスがポストボックス内に存在しなければならない。
【００３１】
このため、暗号鍵のペアを発生する前に、照会を受けた電子メールアドレスが、自分のドメインの内部にあるか否か、および、それ用のポストボックスがあるか否かについて、検査が行われると有利である。前者については、相応の管理機構が検査を行うことにより、可能となる。後者については、内部ユーザディレクトリまたは内部メールサーバへの照会を通じて検査することができる。それにより、実在しない電子メールアドレスを持つ暗号鍵が一切流通しないことが保証される。送信者には、たとえば電子メールアドレスの書き方を誤ったことが、早めにわかるようになる。ほかにも、無意味な暗号鍵を発生する必要がなくなるために、暗号鍵発生サービスの負担が軽減される。
【００３２】
それ以外にも、暗号鍵および場合によってはプライベート鍵を、アーカイビングのために内部ディレクトリに伝送することも可能である。暗号鍵のデータ紛失に対するセキュリティ対策（バックアップ）、ならびに、電子メールの後から暗号化されたバージョンを解読できる可能性があると有利である。場合によっては、暗号鍵をいつでも使用できるように中央で準備しておくことは、組織上または法律上の義務ともなる。
【００３３】
基本的には、複数の内部ディレクトリサービスまたは電子メールサーバに照会可能であることが、強調されるべきである。
【図面の簡単な説明】
【００３４】
【図１】暗号鍵の取り扱い方式を示す図である。
【図２】プッシュサーバの組み込み方式を示す図である。
【図３】ウィルスおよびスパム防御機能の組み込み方式を示す図である。
【符号の説明】
【００３５】
１ ＬＡＮ
２ 画面作業所
３ 携帯端末
４ 従業員
５ 内部認証局
６ 個人化された暗号鍵
７ 受信者鍵
８ 暗号鍵ディレクトリ
９ 外部の相手
１０ インターネット
１１ （内部）メールゲートウェイ
１２ 暗号鍵発生器
１３ ゲートウェイ鍵
１４ 「プライベート」解読鍵
１５ メールサーバ
１６ プッシュサーバ
１７ スパムおよびウィルススキャナ
１８ 外部メールゲートウェイ
１９ 個人鍵
【特許請求の範囲】
【請求項１】
メッセージの伝送方法であって、送信者がまずディレクトリサービスに照会し、前記ディレクトリサービスが前記照会に基づいて暗号鍵ディレクトリ（８）にて受信者アドレスを検索し、前記暗号鍵ディレクトリ（８）に前記受信者アドレスが含まれている限り、前記暗号鍵ディレクトリ（８）中の前記受信者アドレスに対して割り当てられている受信者鍵（７）を読み出して、当該受信者鍵を前記送信者に通知し、次いで前記送信者が前記受信者鍵（７）を用いて前記メッセージを暗号化して前記受信者アドレスに転送する各工程からなる方法において、
前記照会に応答して、前記暗号鍵ディレクトリ（８）に前記受信者アドレスが含まれていない限り、暗号鍵発生器（１２）によりゲートウェイ鍵（１３）を発生して、これを前記送信者に通知し、次いで前記送信者が前記ゲートウェイ鍵（１３）を用いて前記メッセージを暗号化して、前記メッセージを解読するメールゲートウェイ（１１）を介して最終的に前記受信者アドレスに伝送することを特徴とする、方法。
【請求項２】
前記受信者アドレスの有効性が検査される、請求項１に記載の方法。
【請求項３】
前記受信者アドレスの有効性検査が、受信者の電子メールサーバーにより行われる、請求項２に記載の方法。
【請求項４】
前記受信者アドレスの有効性検査が、前記受信者のディレクトリサービス、好ましくは公的ディレクトリサービスにより行われる、請求項２に記載の方法。
【請求項５】
前記受信者アドレスの有効性の検査結果が好調であった後に、追加メタ情報が提供される、請求項２〜４のいずれか一項に記載の方法。
【請求項６】
請求項１〜５のいずれか一項に記載の方法において、前記暗号鍵発生器（１２）が、前記受信者アドレスに個人化されたゲートウェイ鍵（１３）を発生することを特徴とする、方法。
【請求項７】
請求項１〜６のいずれか一項に記載の方法において、前記ゲートウェイ鍵（１３）を、前記暗号鍵ディレクトリ（８）内で前記受信者アドレスに対し割り当てることを特徴とする、方法。
【請求項８】
請求項１〜７のいずれか一項に記載の方法において、前記暗号鍵発生器（１２）が、前記ゲートウェイ鍵（１３）と共に、これに対して割り当てられる解読鍵（１４）を発生し、前記メールゲートウェイ（１１）が前記解読鍵（１４）を用いて前記メッセージを解読することを特徴とする、方法。
【請求項９】
請求項１〜８のいずれか一項に記載の方法において、前記ゲートウェイ鍵（１３）が証明書の一部であることを特徴とする、方法。
【請求項１０】
請求項１〜９のいずれか一項に記載の方法において、前記メッセージを、前記送信者からメールサーバを介して前記受信者アドレスに伝送することを特徴とする、方法。
【請求項１１】
特に請求項１〜１０のいずれか一項に記載の方法を実施するための、メッセージ伝送システムであって、送信者からの照会を受信するディレクトリサービス用の手段を備えており、前記ディレクトリサービス用の手段が、暗号鍵ディレクトリ用の手段（８）にて受信者アドレスを検索するようになっている、システムにおいて、
前記照会に基づいて、前記暗号鍵ディレクトリに前記受信者アドレスが含まれない場合にゲートウェイ鍵を発生する、暗号鍵発生器が備えられることを特徴とする、システム。
【請求項１２】
前記受信者アドレスの有効性を検査する手段が備えられる、請求項１１に記載のシステム。
【請求項１３】
前記受信者アドレスの有効性が、前記受信者の電子メールサーバで検査される、請求項１２に記載のシステム。
【請求項１４】
前記受信者アドレスの有効性が、前記受信者の公的ディレクトリサーバーで検査される、請求項１２に記載のシステム。
【請求項１５】
前記受信者アドレスの有効性の検査結果が好調であった後に、追加メタ情報が提供される、請求項１２〜１４のいずれか一項に記載のシステム。
【請求項１６】
請求項１１〜１５のいずれか一項に記載のシステムにおいて、前記ゲートウェイ鍵を用いて前記メッセージを暗号化する手段が備えられることを特徴とする、システム。
【請求項１７】
請求項１１または１６に記載のシステムにおいて、前記ゲートウェイ鍵を用いて前記メッセージに署名する手段が備えられることを特徴とする、システム。
【請求項１８】
請求項１１〜１７のいずれか一項に記載のシステムにおいて、前記署名のためのメールゲートウェイが備えられることを特徴とする、システム。
【請求項１９】
請求項１１〜１８のいずれか一項に記載のシステムにおいて、前記メッセージを解読するためのメールゲートウェイが備えられることを特徴とする、システム。
【請求項２０】
請求項１１〜１９のいずれか一項に記載のシステムにおいて、前記暗号鍵発生器（１２）が、前記受信者アドレスに個人化されたゲートウェイ鍵（１３）を発生していたことを特徴とする、システム。
【請求項２１】
請求項１１〜２０のいずれか一項に記載のシステムにおいて、前記ゲートウェイ鍵（１３）が、前記暗号鍵ディレクトリ内で前記受信者アドレスに対して割り当てられることを特徴とする、システム。
【請求項２２】
請求項１１〜２１のいずれか一項に記載のシステムにおいて、前記暗号鍵発生器（１２）が、前記ゲートウェイ鍵（１３）と共に、これに対して割り当てられる解読鍵（１４）を発生し、前記メールゲートウェイ（１１）が前記解読鍵（１４）を用いて前記メッセージを解読することを特徴とする、システム。
【請求項２３】
請求項１１〜２２のいずれか一項に記載のシステムにおいて、前記ゲートウェイ鍵（１３）が証明書の一部であることを特徴とする、システム。
【請求項２４】
特に請求項１〜１０のいずれか一項に記載の方法において使用するための、または請求項１１〜２３のいずれか一項に記載のシステム内で使用するための、送信者によるディレクトリサービスへの照会に基づいてゲートウェイ鍵を発生する、暗号鍵発生器。
【請求項２５】
暗号鍵ディレクトリに、前記送信者から照会された受信者アドレスが含まれない場合に、前記ゲートウェイ鍵を発生する、請求項２４に記載の暗号鍵発生器。
【請求項１】
メッセージの伝送方法であって、送信者がまずディレクトリサービスに照会し、前記ディレクトリサービスが前記照会に基づいて暗号鍵ディレクトリ（８）にて受信者アドレスを検索し、前記暗号鍵ディレクトリ（８）に前記受信者アドレスが含まれている限り、前記暗号鍵ディレクトリ（８）中の前記受信者アドレスに対して割り当てられている受信者鍵（７）を読み出して、当該受信者鍵を前記送信者に通知し、次いで前記送信者が前記受信者鍵（７）を用いて前記メッセージを暗号化して前記受信者アドレスに転送する各工程からなる方法において、
前記照会に応答して、前記暗号鍵ディレクトリ（８）に前記受信者アドレスが含まれていない限り、暗号鍵発生器（１２）によりゲートウェイ鍵（１３）を発生して、これを前記送信者に通知し、次いで前記送信者が前記ゲートウェイ鍵（１３）を用いて前記メッセージを暗号化して、前記メッセージを解読するメールゲートウェイ（１１）を介して最終的に前記受信者アドレスに伝送することを特徴とする、方法。
【請求項２】
前記受信者アドレスの有効性が検査される、請求項１に記載の方法。
【請求項３】
前記受信者アドレスの有効性検査が、受信者の電子メールサーバーにより行われる、請求項２に記載の方法。
【請求項４】
前記受信者アドレスの有効性検査が、前記受信者のディレクトリサービス、好ましくは公的ディレクトリサービスにより行われる、請求項２に記載の方法。
【請求項５】
前記受信者アドレスの有効性の検査結果が好調であった後に、追加メタ情報が提供される、請求項２〜４のいずれか一項に記載の方法。
【請求項６】
請求項１〜５のいずれか一項に記載の方法において、前記暗号鍵発生器（１２）が、前記受信者アドレスに個人化されたゲートウェイ鍵（１３）を発生することを特徴とする、方法。
【請求項７】
請求項１〜６のいずれか一項に記載の方法において、前記ゲートウェイ鍵（１３）を、前記暗号鍵ディレクトリ（８）内で前記受信者アドレスに対し割り当てることを特徴とする、方法。
【請求項８】
請求項１〜７のいずれか一項に記載の方法において、前記暗号鍵発生器（１２）が、前記ゲートウェイ鍵（１３）と共に、これに対して割り当てられる解読鍵（１４）を発生し、前記メールゲートウェイ（１１）が前記解読鍵（１４）を用いて前記メッセージを解読することを特徴とする、方法。
【請求項９】
請求項１〜８のいずれか一項に記載の方法において、前記ゲートウェイ鍵（１３）が証明書の一部であることを特徴とする、方法。
【請求項１０】
請求項１〜９のいずれか一項に記載の方法において、前記メッセージを、前記送信者からメールサーバを介して前記受信者アドレスに伝送することを特徴とする、方法。
【請求項１１】
特に請求項１〜１０のいずれか一項に記載の方法を実施するための、メッセージ伝送システムであって、送信者からの照会を受信するディレクトリサービス用の手段を備えており、前記ディレクトリサービス用の手段が、暗号鍵ディレクトリ用の手段（８）にて受信者アドレスを検索するようになっている、システムにおいて、
前記照会に基づいて、前記暗号鍵ディレクトリに前記受信者アドレスが含まれない場合にゲートウェイ鍵を発生する、暗号鍵発生器が備えられることを特徴とする、システム。
【請求項１２】
前記受信者アドレスの有効性を検査する手段が備えられる、請求項１１に記載のシステム。
【請求項１３】
前記受信者アドレスの有効性が、前記受信者の電子メールサーバで検査される、請求項１２に記載のシステム。
【請求項１４】
前記受信者アドレスの有効性が、前記受信者の公的ディレクトリサーバーで検査される、請求項１２に記載のシステム。
【請求項１５】
前記受信者アドレスの有効性の検査結果が好調であった後に、追加メタ情報が提供される、請求項１２〜１４のいずれか一項に記載のシステム。
【請求項１６】
請求項１１〜１５のいずれか一項に記載のシステムにおいて、前記ゲートウェイ鍵を用いて前記メッセージを暗号化する手段が備えられることを特徴とする、システム。
【請求項１７】
請求項１１または１６に記載のシステムにおいて、前記ゲートウェイ鍵を用いて前記メッセージに署名する手段が備えられることを特徴とする、システム。
【請求項１８】
請求項１１〜１７のいずれか一項に記載のシステムにおいて、前記署名のためのメールゲートウェイが備えられることを特徴とする、システム。
【請求項１９】
請求項１１〜１８のいずれか一項に記載のシステムにおいて、前記メッセージを解読するためのメールゲートウェイが備えられることを特徴とする、システム。
【請求項２０】
請求項１１〜１９のいずれか一項に記載のシステムにおいて、前記暗号鍵発生器（１２）が、前記受信者アドレスに個人化されたゲートウェイ鍵（１３）を発生していたことを特徴とする、システム。
【請求項２１】
請求項１１〜２０のいずれか一項に記載のシステムにおいて、前記ゲートウェイ鍵（１３）が、前記暗号鍵ディレクトリ内で前記受信者アドレスに対して割り当てられることを特徴とする、システム。
【請求項２２】
請求項１１〜２１のいずれか一項に記載のシステムにおいて、前記暗号鍵発生器（１２）が、前記ゲートウェイ鍵（１３）と共に、これに対して割り当てられる解読鍵（１４）を発生し、前記メールゲートウェイ（１１）が前記解読鍵（１４）を用いて前記メッセージを解読することを特徴とする、システム。
【請求項２３】
請求項１１〜２２のいずれか一項に記載のシステムにおいて、前記ゲートウェイ鍵（１３）が証明書の一部であることを特徴とする、システム。
【請求項２４】
特に請求項１〜１０のいずれか一項に記載の方法において使用するための、または請求項１１〜２３のいずれか一項に記載のシステム内で使用するための、送信者によるディレクトリサービスへの照会に基づいてゲートウェイ鍵を発生する、暗号鍵発生器。
【請求項２５】
暗号鍵ディレクトリに、前記送信者から照会された受信者アドレスが含まれない場合に、前記ゲートウェイ鍵を発生する、請求項２４に記載の暗号鍵発生器。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００９−５０３９６３（Ｐ２００９−５０３９６３Ａ）
【公表日】平成２１年１月２９日（２００９．１．２９）
【国際特許分類】
【出願番号】特願２００８−５２３２４０（Ｐ２００８−５２３２４０）
【出願日】平成１８年７月２６日（２００６．７．２６）
【国際出願番号】ＰＣＴ／ＥＰ２００６／００７４０４
【国際公開番号】ＷＯ２００７／０１２４８３
【国際公開日】平成１９年２月１日（２００７．２．１）
【出願人】（５０６１００１６３）ウーティマコ セーフウエア アーゲー (3)
【Ｆターム（参考）】
【公表日】平成２１年１月２９日（２００９．１．２９）
【国際特許分類】
【出願日】平成１８年７月２６日（２００６．７．２６）
【国際出願番号】ＰＣＴ／ＥＰ２００６／００７４０４
【国際公開番号】ＷＯ２００７／０１２４８３
【国際公開日】平成１９年２月１日（２００７．２．１）
【出願人】（５０６１００１６３）ウーティマコ セーフウエア アーゲー (3)
【Ｆターム（参考）】
[ Back to top ]