JP2002521970A

JP2002521970A - セキュリティを施したメッセージの管理システム

Info

Publication number: JP2002521970A
Application number: JP2000563055A
Authority: JP
Inventors: カーニエリ、ラビブ
Original assignee: バンガード・セキュリティ・テクノロジーズ・リミテッド
Priority date: 1998-07-26
Filing date: 1999-07-26
Publication date: 2002-07-16
Also published as: WO2000007355A3; EP1099334A2; IL125516A0; WO2000007355A2; AU5062599A; CA2338530A1

Abstract

(57)【要約】複数のユーザマシンのなかの任意の２つの間でメッセージを転送するためのメッセージングシステム。このシステムは、セキュリティを確保したメッセージ操作を管理するためのメッセージマネージャ（１１２）を備える。メッセージマネージャ（１１２）は、各ユーザマシンとそのマネージャ（１１２）との間の各メッセージチャネルについての個別のセキュリティを確保したチャネルの特性を記憶する管理データベース（１１４）と結び付けられている。更に、ユーザマシン毎に設けられた、メッセージにセキュリティを施すローカルメッセージプロセッサ（１３０）を有する。このローカルプロセッサ（１３０）は、ローカルデータベース（１２２）と結び付けられている。ローカルデータベース（１２２）は、或るユーザマシンと、そのユーザマシンの通信の相手方であるメッセージマネージャ（１１２）を含むの他のユーザマシンのそれぞれとの間のチャネル毎に、セキュリティを確保したチャネルの特性を記憶する。

Description

【発明の詳細な説明】

【０００１】（発明の分野）本発明は、一般に電子的メッセージング管理システムに関するものであり、特
に、公的デジタルネットワークを介してのセキュリティを確保した電子メール通
信に関するものである。

【０００２】（発明の背景）電子データ通信の主な用途の１つは、電子メール、文書等や、他のあらゆる種
類の電子データの転送を含むメッセージの転送である。メッセージは、少なくと
も発信元アドレス、宛先アドレス、及びメッセージデータを含む。メッセージが
通信ネットワークを介して転送される時、そのメッセージは発信元ユーザから宛
先ユーザへ直接送られるか、或いはその転送経路上にある１又は複数のサーバの
間を中継され得る。このことによって、電子メールを含むメッセージが、複数の
位置のユーザ、他のエンティティ等に開示、即ち盗用される可能性が生ずる。

【０００３】電子メールのセキュリティは、インターネットのユーザのようなデジタルネッ
トワークのユーザにとって重要な問題である。各ユーザは、他人がそのユーザの
個人的なメッセージを盗用し得ることを懸念している。企業はその企業の取引の
秘密を含む電子メールが外部に漏れたり盗用される可能性について懸念している
。

【０００４】図１Ａは、電子メール通信のプライバシーを保護するべく設計された電子メー
ルネットワークアーキテクチャ１０の詳細を示す。

【０００５】システム１０は、ユーザである複数の電子メールクライアント、及び図面にお
いてサーバ１２Ａ、サーバ１２Ｂ等として示されている複数のインターネットサ
ーバ１２を含む。例示した状況では、ユーザ１が電子メールをユーザ２に送った
時、電子メールがインターネットを介してサーバ１２Ａからサーバ１２Ｂに送ら
れ、最終的にその電子メールがその宛先であるユーザ２に到達している。

【０００６】通常、この例でいえばユーザ２である宛先ユーザはメールボックス１３を有し
、そのメールボックスはユーザ２に対してサービスを提供するサーバ１２Ｂに位
置している。メールボックス１３は、ユーザ２がオフライン状態にある間、一時
的にユーザ２のメールを保存する。ユーザ２は、ログオンしたときに、そのユー
ザのメールをメールボックス１３から取り出す。

【０００７】そのユーザは、例えばWindows（登録商標）のようなオペレーティングシステム２８をインストールしたコンピュータ２６を手元に有している。更に、電子メールパッケージプログラム２０、セキュリティ確保チャネルデータベース（ＳＣＤＢ）２２、及びメールセキュアラ（mail securer）３０がコンピュータ２６にインストールされ、オペレーティングシステム２８上に存在している。

【０００８】電子メールがセキュリティを確保した状態で或るユーザから他のユーザに送ら
れる時、その電子メールはセキュリティを確保したチャネルを通して送られる。
任意の２つのユーザの間のセキュリティを確保したチャネルは、例えば所定のデ
ータ及び鍵を用いる暗号化アルゴリズム、鍵、鍵の長さ等のような、その２名の
ユーザのみに知られているプロパティ（特性）の組である。

【０００９】図１Ａには、ユーザ１及びユーザ２の２名のユーザのみが示されているが、電
子メールの転送は、任意の数のユーザ間で行われ得るということを了解されたい
。更に、図１においてはユーザ１のみについて詳細に示されているが、ユーザ２
を含む他の全てのユーザが同様に構成された要素を備えていることは明らかであ
る。

【００１０】電子メールパッケージプログラム２０は、例えばOutlook、Eudora、又はNetsc
ape等の市販の電子メールパッケージプログラムである。電子メールパッケージ
プログラム２０は、市販の電子メールプログラムで一般に利用されているような
通常は電子的なアドレス帳１８、受信トレイ（Inbox）２３及び送信トレイ（Out
box）２４を有する。これらの要素は、市販のこの種類の要素のために通常用い
られるメソッドにおいて用いられる。

【００１１】メールセキュアラ３０は、本出願の譲受人であるHaifa, IsraelのVanguard Se
curity Technologiesから市販されているMAILguardianのような、任意の市販の
セキュリティ確保型電子メール管理システムである。一般的に、メールセキュア
ラ３０は、以下の４つのステップを実行することによって電子メールパケットの
セキュリティを確保する。即ち、（１）デジタル署名を電子メールパケットに添付する、（２）鍵としての乱数及びData Encryption Standard （DES）又はBlowfishのよ
うな市販の暗号化アルゴリズムを用いて、電子メールパケット及びデジタル署名
を暗号化する。（３）乱数鍵を、予め定められた鍵及び上記の選択された暗号化アルゴリズムを
用いて暗号化し、暗号化されたパケットに添付する。（４）このようにしてセキュリティを確保された電子メールパケットを、移送の
ために必要な最小限の情報のみを表示する通常の電子メールメッセージにカプセ
ル化する。

【００１２】ＳＣＤＢ２２はメールセキュアラ３０の上に存在し、セキュリティを確保した
電子メールの送受信のための秘密取扱許可を有するユーザのアドレスのみを含む
。通常、通信においてセキュリティを施されるこれらのユーザはメンバーと呼ば
れる。ＳＣＤＢ２２にユーザ即ちメンバーを加えるためには通常２つの方法があ
る。

【００１３】第１の方法では、ユーザ１が任意の方法（例えば電話）を用いてユーザ２と連
絡を取り、鍵を交換することによって両者の間にセキュリティを確保したチャネ
ルを生成する。秘密共有法として知られるこの手順は、ＳＣＤＢ２２に新たなユ
ーザを加えるたびに反復しなければならない。

【００１４】第２の方法では、ユーザ１がユーザ２から電子メールを受け取る場合、ユーザ
１のメールセキュアラ３０が、ユーザ２が同一のセキュリティソフトウェアを用
いていることを認識し、自動的にセキュリティを確保したチャネルを生成する。
このような方式は、ユーザ１のメールセキュアラ３０とユーザ２のメールセキュ
アラ３０との間の内部的な電子メールメッセージを用いるハンドシェークプロセ
スによって達成される。この方法によれば、方法１のようなユーザインタフェー
スの必要性がなくなるが、適切な鍵でセキュリティを確保したチャネルが両者の
間に生成される前に、１又は複数の電子メールパケットがセキュリティを確保し
ていないチャネルを通して転送されることになる。

【００１５】上述の２つの方法の何れかによって生成されたセキュリティを確保したチャネ
ルは、そのチャネルのメンバーである２名のユーザ専用のチャネルである。一例
として、ユーザ１がユーザ２に向けて、彼らのセキュリティを確保したチャネル
を通して電子メールを送る時、ユーザ１のセキュアラ３０はセキュリティを確保
したチャネルのプロパティ（特性）を用いて電子メールパケットのセキュリティ
を確保する。ユーザ２がユーザ１に電子メールを送る場合も同様である。これは
、ユーザ１−ユーザ２間のセキュリティ確保チャネルを通しての電子メール送信
として知られている。

【００１６】マルチキャストパケットとして知られる、２以上のユーザ又はアドレスに送ら
れる電子メールパケットの場合、各受信者は、その受信者と送り手との間のセキ
ュリティ確保チャネルを介してパケットを受け取る。更に、マルチキャストでは
、送り手と受け手との間にセキュリティ確保チャネルが存在するユーザメンバー
に対してだけでなく、受け手との間にセキュリティ確保チャネルが存在しない非
ユーザメンバーに対しても送られることがある。

【００１７】ここで図１Ｂを参照すると、図１Ａの電子メールネットワークシステムを介し
ての電子メールの転送の例を示す流れ図が示されている。

【００１８】ユーザ１は電子メールパッケージプログラム２０を用いて、ユーザ２宛ての電
子メールを書く（ステップ４０）。ユーザ１はアドレス帳１８を参照し、ユーザ
２のアドレスを取り出す（ステップ４２）。ユーザ１は電子メールを書き終わり
、「送信（"SEND"）」を要求する。電子メールパッケージ２０はその電子メール
を送信トレイ（Outbox）２４に置き（ステップ４４）、サーバ１２との接続を開
始する（ステップ４６）。電子メールパケットは電子メールパッケージ２０のレ
ベルからオペレーティングシステム２８の通信プロトコル層（即ちＴＣＰソケッ
ト）に渡される（ステップ４８）。インタセプタ（interceptor）（即ち階層化
ソケットプログラム）フック（hook）は、通信プロトコル層の前又はその中にお
いてパケットを監視し、そのパケットを送信されるべき電子メールのパケットし
て特定する。インタセプタフックはそのパケットをメールセキュアラ３０に供給
する（ステップ４９）。

【００１９】メールセキュアラ３０は送り手と受け手、即ちユーザ１及びユーザ２のそれぞ
れがＳＣＤＢ２２の１組のメンバーであることの確認を試みる（ステップ５０）
。一旦両者が１組のメンバーとして特定されると（ステップ５２）、両者は、セ
キュリティを確保した電子メールの送受信を行い得るものに分類される。メール
セキュアラ３０は、前に詳細に説明したように電子メールパケットのセキュリテ
ィを確保する（ステップ５４）。

【００２０】しかし、メールセキュアラ３０がユーザ１及びユーザ２をＳＣＤＢ２２の１組
のメンバーと特定しない場合（ステップ５６）、パケットはセキュリティ確保チ
ャネルを通して送られるべきものと分類されない。この時、メールセキュアラ３
０は、そのパケットがセキュリティを施さずに送信されようとしていることをユ
ーザ１に知らせる警告を送り（ステップ５７）、指示を待つ。ユーザ１は、オー
プンな（セキュリティを確保していない）インターネットチャネルを通してセキ
ュリティ無しでパケットを送信するか（ステップ５８）、或いはそのパケットを
破棄するか（ステップ５９）の何れかを選択することができる。

【００２１】セキュリティを施された電子メールパケットはオペレーティングシステム２８
に戻される（ステップ６０）。そのパケットは通信媒体（即ちインターネット）
を通して転送され（ステップ６２）、ユーザ２にサービスを提供するサーバ１２
Ｂにあるユーザ２のメールボックス１３に到達する。そのパケットは、ユーザ２
の電子メールパッケージプログラム２０によって取り出されるまでユーザ２のメ
ールボックス１３に保存される（ステップ６４）。そのメッセージは、通信プロ
トコル層においてインターセプトされ（ステップ６６）、ユーザ２のセキュアラ
３０に供給される。組をなすユーザ１及びユーザ２が共にユーザ２のＳＣＤＢ２
２のメンバーである場合、その電子メールは解読され（ステップ６７）、ユーザ
２のオペレーティングシステム２８に戻される。ユーザ２の電子メールパッケー
ジプログラム２０はプレーンテキスト形式の電子メールを受け取り（ステップ６
８）、そのメールを受信トレイ（Inbox）２３に置き、ユーザ２に知らせる。

【００２２】（本発明の要約）本発明の目的の１つは、初めにインストールされたときから、電子的メッセー
ジングシステムのためのセキュリティを自動的に提供することである。

【００２３】従って、本発明の好ましい実施形態によれば、複数のユーザマシンの任意の２
つの間でのメッセージの転送のためのメッセージングシステムが提供される。前
記システムは、セキュリティを確保したメッセージ操作を監視するためのメッセ
ージマネージャを有する。前記メッセージマネージャは、前記マネージャと前記
ユーザマシンのそれぞれとの間の各メッセージチャネルの個別のセキュリティを
確保したチャネルの特性を記憶した管理データベースと結び付けられている。

【００２４】更に、このシステムは、ユーザマシン毎に設けられた、メッセージのセキュリ
ティを確保するためのローカルセキュリティメッセージプロセッサを有する。前
記プロセッサは、ローカルデータベースと結び付けられている。前記ローカルデ
ータベースは、前記ユーザマシンと、前記ユーザマシンの通信の相手方である、
前記マネージャを含む他のユーザマシンのそれぞれとの間のチャネル毎の、セキ
ュリティを確保したチャネルの特性を記憶する。

【００２５】更に、前記ユーザマシンの少なくとも１つの上に前記ローカルセキュリティメ
ッセージプロセッサをインストールし、少なくとも前記マネージャと前記ユーザ
マシンとの間のチャネルのセキュリティを確保したチャネルの特性を含む前記ロ
ーカルデータベースを供給し、それによってインストールの瞬間からセキュリテ
ィを確保したメッセージの操作を確実に行えるようにする手段を有するメッセー
ジマネージャが提供される。このローカルセキュリティメッセージプロセッサは
、通信を行う相手方のユーザのセキュリティを確保したチャネルの特性が未知で
ある時、又は前記ローカルセキュリティメッセージプロセッサが他のユーザマシ
ンから受信したメッセージを解読できない時に、前記メッセージマネージャにメ
ッセージを送るための手段を有する。

【００２６】従って、本発明の好ましい実施形態による、数のユーザマシンの中の任意の２
つの間のセキュリティを確保したメッセージの転送を確実に行えるようにするた
めの方法であって、メッセージマネージャと前記複数のユーザマシンのそれぞれとの間のセキュリ
ティを確保したチャネルの特性を生成する過程と、前記メッセージマネージャと前記複数のユーザマシンとのそれぞれとの間の各
セキュリティを確保したチャネルの前記特性を管理データベースに記憶させる過
程と、前記複数のユーザマシンの少なくとも１つの上にローカルセキュリティメッセ
ージプロセッサをインストールし、かつ前記プロセッサに結び付けられるローカ
ルデータベースを供給する過程と、前記複数のユーザマシンの少なくとも１つと少なくとも前記マネージャとの間
のセキュリティを確保したチャネルの特性、及び前記複数のユーザマシンのそれ
ぞれと他のユーザマシンのそれぞれとの間の前記セキュリティを確保した各チャ
ネル毎のチャネルの特性を、前記ローカルデータベースに記憶させる過程と、インストールの瞬間から、前記複数のユーザマシンの何れかの間のメッセージ
ングのセキュリティを確保する過程とを含むことを特徴とする方法が提供される
。

【００２７】更に、前記複数のユーザマシンの２つ以上においてログオンをする過程と、メ
ッセージを前記メッセージマネージャに送ることによってセキュリティを確保し
たメッセージを転送する過程とを含む方法が提供される。

【００２８】更に、セキュリティを確保したチャネルの特性を生成する前記過程が、自動的
に鍵を生成し、自動的な認証を行う過程、及び／又は認証コードを利用する過程
を含むことを特徴とする方法が提供される。

【００２９】前記方法は、更に、通信しようとする相手方のユーザのセキュリティを確保し
たチャネルの特性が未知である時、又は前記ローカルセキュリティメッセージプ
ロセッサが他のユーザマシンから受信したメッセージパケットを解読できない時
に、前記メッセージマネージャにメッセージを送信する過程を含む。

【００３０】前記方法は、更に、ユーザの通信フローに割り込みを入れることなく前記複数
のユーザマシンの任意の２つの間の前記セキュリティを確保したチャネルのため
の前記セキュリティを確保したチャネルの特性を再生成する過程を含む。或いは
、前記セキュリティを確保したチャネルの特性を再生成する前記過程が、所定の
周期毎に前記セキュリティを確保したチャネルの特性を再生成する過程、及び／
又は前記ローカルセキュリティメッセージプロセッサが他のユーザマシンから受
信したメッセージパケットを解読できない時に、前記セキュリティを確保したチ
ャネルの特性を再生成する過程を含む。

【００３１】本発明は、以下の詳細な説明を添付の図面と共に参照することによりより完全
に理解されよう。

【００３２】（好ましい実施形態の詳細な説明）図２には、本発明の好ましい実施形態に従って構築され動作する、セキュリテ
ィ確保型電子メール管理システム１００のアーキテクチャの模式図が示されてい
る。

【００３３】ユーザのデスクトップにエージェント（agent）をインストールした瞬間から
、本発明は、終端間のセキュリティを確保した電子メール通信チャネルを提供す
る。従来型のシステムと異なり、システム１００は名目上のユーザに対してトラ
ンスペアレントである。

【００３４】システム１０と同様に、システム１００は、オペレーティングシステム１２８
をインストールしたコンピュータ２６を手元に有する複数のユーザを含む。その
複数のユーザはサーバ１２を介してインターネット上で電子メールのやり取りを
する。各ユーザは、電子メールパッケージプログラム２０、電子的アドレス帳１
８、受信トレイ（Inbox）２３、送信トレイ（Outbox）２４、及びメールボック
ス１３を有する。

【００３５】オペレーティングシステム１２８は、例えばUNIX（登録商標）、MAC、Windows のような任意のオペレーティングシステムである。

【００３６】システム１００は更に、メールセキュリティエージェント１３０、ユーザにト
ランスペアレントなローカルのセキュリティを確保したチャネルのデータベース
であるローカルセキュリティチャネルデータベース（ＬＳＣＤＢ）１２２、及び
グローバル管理用のセキュリティを確保したチャネルのデータベースであるグロ
ーバル管理セキュリティチャネルデータベース（ＭＳＣＤＢ）１１４を備えたメ
ールセキュリティマネージャ１１２を有する。

【００３７】各メールセキュリティエージェント１３０の基本的な機能は、メールセキュア
ラ３０の機能に類似している。更に、後に詳細に説明するように、各エージェン
ト１３０は、マネージャ１１２と共に各ＬＳＣＤＢ１２２にメンバーを自動的に
インストールする。

【００３８】従来の場合と同様に、各ＬＳＣＤＢ１２２は、ユーザ毎にローカルに配置され
ており、ローカルユーザが通信する相手である他のメンバーのアドレス及び鍵を
有する。本発明の好ましい実施形態では、ユーザ１がＬＳＣＤＢ１２２に更にセ
キュリティを確保するユーザを入力する必要がない場合には、ローカルのセキュ
リティを確保したチャネルのデータベースがユーザに対してトランスペアレント
である。別の実施形態では、ＬＳＣＤＢ１２２が、従来技術の場合と同様にイン
タフェースされ得る。即ち、目で見ることが可能かつ／又は編集が可能なオプシ
ョン付きでＬＳＣＤＢを利用することができる。

【００３９】マネージャ１１２は、システム１００におけるユーザの１つであり、サーバ１
２の１つからサービスを提供される。マネージャ１１２はＭＳＣＤＢ１１４を有
しており、このＭＳＣＤＢ１１４は、後に詳細に説明するようにセットアップの
際及び更新の際に生成され、メンバーをインポートされる。ＭＳＣＤＢ１１４は
システム１００における全てのユーザに対するチャネルプロパティ（特性）及び
鍵を有している。従って、マネージャ１１２が（ＭＳＣＤＢ１１４を介して）シ
ステム１００における全てのユーザに対するチャネルプロパティ及び鍵を有して
いる限り、マネージャ１１２はシステム１００の全てのユーザと通信できる。し
かし、ＭＳＣＤＢ１１４は任意の２つのユーザ間のセキュリティを確保したチャ
ネルのプロパティ（特性）を記憶しておらず、これらのプロパティ（特性）は２
つのユーザに関連するＬＳＣＤＢにのみ記憶されている。

【００４０】ＭＳＣＤＢ１１４のユーザ、即ちメンバーは、インストールされたシステム１
００を有する会社によって決定される。システム１００は、ユーザの物理的位置
又は所属（affiliation）とは無関係に、その会社がセキュリティを確保された
電子メールの受け手／送り手として含めることを望む任意のユーザにサービスを
提供する。一例として、ＭＳＣＤＢ１１４のメンバーは、その会社と同じ物理的
位置にいる、又は同じ物理的位置にいない関係会社の従業員であり得る。或いは
、メンバーのリストは、その会社の顧客又は共同事業者、或いはその会社がセキ
ュリティを確保したチャネル上での通信を行うことを望む任意の他のユーザを含
み得る。

【００４１】マネージャ１１２がシステム１００のユーザの１つであり、サーバ１２によっ
てサービスを提供されることから、マネージャ１１２はインターネットネットワ
ーク上の何れのユーザとも通信を行うことができる。ユーザの名称及びアドレス
がＭＳＣＤＢ１１４のメンバーとして一旦加えられると、そのユーザに送られる
メッセージは、インターネット上のユーザの位置とは無関係にセキュリティが確
保される。

【００４２】マネージャ１１２は、マネージャからエージェントへ及びエージェントからマ
ネージャへの両方向に送信され得るコントロールメッセージを介して各エージェ
ント１３０との通信を行う追加のタスクを有する。コントロールメッセージは、
（後に詳細に説明するが）「鍵リフレッシュ（refresh key）」、「インストー
ル終了（installation complete）」、「鍵再生（recovered key）」、「メッセ
ージ再生（message recoverd）」等のようなコマンドを含む。更に、参加してい
る会社は、会社方針データベース１２９を生成することができる。会社方針デー
タベース１２９は、マネージャ１１２のコンピュータ２６に配置されており、各
ユーザのコンピュータ２６に自動的に分散され、規則違反の操作又はセキュリテ
ィを確保していない電子メールの転送を規制する。

【００４３】通常の場合、マネージャ１１２は、２つのユーザ間のメッセージ転送に関与し
ない。マネージャ１１２はその転送がそのユーザ間の第１回目の通信である場合
、又はその転送に問題がある場合にユーザ間のメッセージ転送に関与する。

【００４４】図３Ａ及び図３Ｂには、２種類の電子メールの転送方式が示されている。図３
Ａは、マネージャ１１２が関与しない電子メールの転送を示したものである。図
３Ｂは、マネージャ１１２が関与する電子メールの転送を示したものである。従
来技術に関連して上述したものに類似したこの実施形態の各ステップは、類似し
た参照符号を付して図示されており、以下詳細に説明する。

【００４５】図３Ａに示すように、ユーザ１からユーザ２への電子メールの転送では、図１
Ｂの従来技術の場合と概ね類似したことが行われている。但し、図１Ｂのセキュ
アラ３０によって行われた全てのステップ（ステップ４９、５０、５２、５４、
６０、６６、及び６７）は、ここでは図３Ａのエージェント１３０によって行わ
れる（ステップ１４９、１５０、１５２、１５４、１６０、１６６、及び１６８
）。更に、図１Ｂのステップ４９においてはＳＣＤＢ２２を参照しているが、本
発明では、図３Ａのステップ１４９においてＬＳＣＤＢ１２２を参照する。

【００４６】図３Ｂには、マネージャ１１２の関与する電子メールの転送が示されている。
ユーザ１は電子メールパッケージプログラム２０を用いて、ユーザ２宛ての電子
メールを書く（ステップ４０）。ユーザ１はアドレス帳１８０を参照して、ユー
ザ２のアドレスを取り出す（ステップ４２）。ユーザ１が電子メールを書き終え
る。電子メールパッケージプログラム２０は送信トレイ（Outbox）２４にその電
子メールを置き（ステップ４４）、サーバ１２との接続を開始する（ステップ４
６）。

【００４７】電子メールパケットが、オペレーティングシステム２８のレベルにある通信プ
ロトコル層に渡される（ステップ４８）。インタセプタフックは、そのパケット
が通信プロトコル層にあることを監視し、そのパケットをメールセキュリティエ
ージェント１３０に供給する（ステップ１４９）。

【００４８】メールセキュリティエージェント１３０は、送り手及び受け手、即ちユーザ１
及びユーザ２のそれぞれがＬＳＣＤＢ１２２のメンバーであることの確認を試み
る（ステップ１５０）。エージェント１３０がユーザ１及びユーザ２をＬＳＣＤ
Ｂ１２２にある１組のメンバーとして認識しない（ステップ１５５）。エージェ
ント１３０は、ユーザ１とマネージャ１１２との間のセキュリティを確保したチ
ャネルのための所定のプロパティ（特性）の組で電子メールパケットのセキュリ
ティを確保し（ステップ１５６）、そのパケットをマネージャ１１２に送る。マ
ネージャ１１２はＬＳＣＤＢ１１４に照会して（ステップ１５７）、ユーザ２の
特定を試みる。

【００４９】ユーザ２がＭＳＣＤＢ１１４内に見出され（ステップ１５８）、特定された場
合、マネージャ１１２はユーザ２とマネージャ１１２との間のセキュリティを確
保したチャネルの予め定められたプロパティ（特性）の組で電子メールパケット
のセキュリティを確保する（ステップ１５９）。並行して、マネージャ１１２は
、ユーザ１−ユーザ２のセキュリティを確保したチャネルの鍵を生成し（ステッ
プ１６０）、それをユーザ１及びユーザ２の両方に送る。鍵を生成し交換するこ
とによって、次回のユーザ１とユーザ２（又はユーザ２とユーザ１）との間の電
子メールの転送において、マネージャ１１２による補助を不要にすることができ
る。

【００５０】マネージャ１１２はパケットをユーザ２に送り（ステップ１６１、６２、６４
、１６６、及び１６７）、ユーザ２においてそのパケットは解読される。プレー
ンテキスト形式の電子メールパケットがユーザ２の受信トレイ（Inbox）２３に
受信され（ステップ１６８）、その存在がユーザ２に通知される。プレーンテキ
スト形式のメッセージは、マネージャの介入を示すものを何ら含んでいない。図
３Ａについて以前に説明したように、あたかもユーザ１からユーザ２にメッセー
ジが直接送られたように見える。

【００５１】ユーザ２がＭＳＣＤＢに見出されない場合（ステップ１７０）、マネージャ１
１２はデータベース１２９にリストされた会社の方針に従う（ステップ１７２）
。そのような会社の方針としては、セキュリティを確保していないメッセージの
送信、そのようなセキュリティを確保したチャネルが生成されるまでの転送の遅
延、メッセージの破棄、又はユーザ１にエラーメッセージを戻すこと等を挙げる
ことができる。

【００５２】ここで、図４Ａには、本発明の好ましい実施形態によるシステム１０のユーザ
のための自動認証インストール手順の流れ図が示されている。

【００５３】システム１００は、少なくともマネージャ１１２とシステム１００の各ユーザ
との間のセキュリティを確保したチャネルを生成する。以下に詳細に説明するよ
うに、ＭＳＣＤＢ１１４は、少なくとも、システム１１０の各ユーザ及びマネー
ジャ１１２のためのセキュリティを確保したチャネルのプロパティ（特性）をイ
ンポートされ更新される。以下に更に詳細に説明するように、各ユーザのＬＳＣ
ＤＢ１１２には、少なくとも前記ユーザ及びマネージャ１１２のセキュリティを
確保したチャネルのプロパティ（特性）が自動的にインストールされる。

【００５４】インストールの手順は、システム１００上へのマネージャ１１２のインストー
ルで開始される（ステップ２０２）。システム１００を有する会社は、システム
１００のメンバー／ユーザを選択し、それらの名前をＭＳＣＤＢ１１４にインポ
ートする（ステップ２０４）。後日、その会社がシステム１００に追加のユーザ
を含めることを選択する場合は、このステップを任意の新たなユーザに対して反
復することができる。

【００５５】次にマネージャ１１２は、そのマネージャのオペレータが通信のセキュリティ
を確保することを決めた各ユーザ毎に、メンバーに対するセキュリティを確保す
るプロセスを開始する。このプロセスは、各ユーザメンバー毎のDiffie Hellmen
（ＤＨ）方式の秘密鍵及び公開鍵を生成すること（ステップ２０６）によって開
始される。図４の流れ図に、１人のメンバー、即ちユーザ１についてプログラム
の配布及び生成の詳細が示されているが、ステップ２０４においてインポートさ
れた全てのユーザについてマネージャ１１２がこの手順を反復することは明らか
である。

【００５６】マネージャ１１２はＤＨの秘密鍵をセーブし、エージェント１３０のインスト
ールプログラムと共に、ＤＨの公開鍵をユーザ１に送る（ステップ１０８）。イ
ンストールソフトウェアは、電子メールメッセージへの添付等を含む様々な方法
で配布することができる。ユーザ１は、添付ファイルを起動（即ち添付ファイル
をダブルクリック）することによってインストールプログラムを開始させ、エー
ジェント１３０のインストールを開始する（ステップ２１０）。エージェント１
３０は、それ自身のＤＨ公開鍵及び秘密鍵を生成する（ステップ２１２）。次に
エージェント１３０が、それ自身の秘密鍵及び受け取った公開鍵から全ＤＨ鍵を
生成し（ステップ２１４）、それを用いてセキュリティを確保したチャネルを生
成する。エージェント１３０は、この新たにセキュリティを確保されたチャネル
を通して（ユーザ１から）マネージャ１１２へセキュリティを確保した状態で「
インストール終了」メッセージを、そのＤＨ公開鍵（平文の形式で送られる）を
前に置いた形で送る（ステップ２１６）。マネージャ１１２は、ユーザ１のＤＨ
公開鍵を取り出し（ステップ２１８）、取り出された鍵及びセーブされたＤＨ秘
密鍵から同じ全ＤＨ鍵を生成する（ステップ２２０）。これによって、マネージ
ャ１１２がセキュリティを確保した状態で送られた「インストール終了」メッセ
ージを読み出し解読する（ステップ２２２）ことが可能となる。「インストール
終了」メッセージが正しく解読された場合には、マネージャ１１２はユーザ１が
インストールのされたものとしてマークを付ける（ステップ２２４）。

【００５７】ここで図４Ｂを参照すると、本発明の好ましい実施例によるシステム１００の
ためのユーザ認証インストール手順の流れ図が示されている。

【００５８】図４Ａに示すように、Diffie Hellmen（ＤＨ）の秘密鍵及び公開鍵を生成する
代わりに、システム１００を有する企業が利用可能な選択として、１又は複数の
インポートされたメンバーに任意の文字列であり得る認証コードを供給すること
によって、それらのメンバーのセキュリティを確保することができる。これは、
マネージャ１１２を介して行われる。

【００５９】図４Ａのステップ２０２及び２０４は、それらのステップが早い時期に既に実
行されており実行しなくても済む場合でも、この実施例については反復される。
しかし、Diffie Hellmen（ＤＨ）の秘密鍵及び公開鍵を生成する代わりに、マネ
ージャ１１２は、ランダムな認証コードを生成し（ステップ２５０）、それをユ
ーザ１に供給する（ステップ２５２）。次にマネージャ１１２は、その認証コー
ドを使用し、マネージャとユーザ１とのセキュリティを確保したチャネルのため
の鍵を生成する（ステップ２５４）。マネージャ１１２は、ユーザ１とマネージ
ャ１１２との間の送信のためのセキュリティを確保したチャネルのプロパティ（
特性）をＭＳＣＤＢ１１４に記録し（ステップ２５６）、例えばユーザ１への電
子メールメッセージに添付する形で、エージェント１３０ソフトウェアインスト
ールプログラムを送る（ステップ２５８）。

【００６０】ユーザ１はインストールプログラムを起動し（ステップ２６２）、そのインス
トールプログラムはエージェント１３０のインストールを開始する（ステップ２
６４）。エージェント１３０は、認証コードを要求し（ステップ２６６）、それ
を用いて、セキュリティを確保したチャネルのための鍵を生成する（ステップ２
６８）。エージェント１３０は、新たにセキュリティを確保したチャネルを通し
て、セキュリティを確保した「インストール終了」メッセージを（ユーザ１から
）マネージャ１１２に自動的に送信する（ステップ２７０）。

【００６１】マネージャ１１２はステップ２５４においてセーブされた鍵を用いて、セキュ
リティを確保した状態で送られた「インストール終了」メッセージを読み出し解
読する（ステップ２７２）。「インストール終了」メッセージが正しく解読され
た場合には、マネージャ１１２がユーザ１にインストールされたものとしてマー
クを付ける（ステップ２７４）。

【００６２】本発明の好ましい実施形態では、電子メールパケットが、少なくとも以下のス
テップを実行することによってセキュリティを確保される。（１）デジタル署名を電子メールパケットに添付する。（２）電子メールパケット及びデジタル署名を、鍵としての乱数、及び例えばDa
ta Encryption Standard（DES）又はBlowfishのような任意の市販の暗号化アル
ゴリズム等のセキュリティを確保したチャネルのデータ暗号化アルゴリズムを用
いて暗号化する。（３）乱数鍵を、セキュリティを確保したチャネルの予め定められた鍵、及び例
えばData Encryption Standard（DES）又はBlowfishのような市販の暗号化アル
ゴリズム等のセキュリティを確保したチャネルの鍵の暗号化アルゴリズムを用い
て暗号化し、暗号化されたパケットに添付する。（４）ユーザ１とマネージャとのセキュリティを確保したチャネルの鍵及び上で
選択されたデータ暗号化アルゴリズムを用いて乱数鍵も暗号化し、暗号化された
パケットに添付する。（５）ここでセキュリティを確保された電子メールパケットを、転送のために必
要な最小限の情報のみを表示する標準的な電子メールメッセージにカプセル化す
る。

【００６３】システム１００は、マネージャ１１２に電子メール乱数鍵を解読する能力を付
与することから、システム１００は以下のような別のオプションが可能な柔軟性
を提供する。（１）ユーザが複数の位置においてセキュリティを確保されたメールを受信でき
る。（２）損傷鍵を自動的に修復できる。（３）古い鍵を自動的にリフレッシュできる。これらの３つのオプションについて以下に詳細に説明する。

【００６４】複数の位置図５Ａは、１又は複数のユーザが複数の位置にセットアップされているシステ
ム１００の模式図である。時折起こり得ることであるが、１又は複数のユーザが
１又は複数の位置においてログオンすることがある。図５Ａに例示する状況のよ
うに、ユーザ２が位置Ａ及び位置Ｂの２つの異なる位置に登録されている。しか
し、ユーザ２の２つの位置は、同じサーバ１２及び同じメールボックス１３を使
用している。

【００６５】システム１００はユーザ２が２つの異なるログオンの場所を有していることを
認識しているが、システムはユーザ２が次にどの場所からログオンするかは認識
していない。また、マネージャ１３０がユーザ２が使用している各場所毎にＬＳ
ＣＤＢ１２２を更新するのは実際的でない。

【００６６】システム１００が、新たな即ち第２のコンピュータＩＤでユーザ２から「イン
ストール終了」メッセージを受け取ると、マネージャ１１２はそのユーザを複数
位置ユーザとして宣言する。マネージャ１１２は、ユーザ２−マネージャ間のセ
キュリティを確保したチャネル用の同一の鍵を両方の位置においてユーザ２に供
給する。更にマネージャ１１２は、ユーザ２と他のメンバーユーザとのセキュリ
ティを確保したチャネルを生成するのを止める。更にマネージャ１１２は、ユー
ザ２に対して、それと他のユーザとの全てのセキュリティを確保したチャネルを
クリアすると共に、マネージャ１１２とのセキュリティを確保したチャネルのみ
を有効な状態に残すことを要求することも試みる。このようにして、ユーザ２は
、それとマネージャ１１２との間のセキュリティを確保したチャネルを通してセ
キュリティを施した電子メールを常に受け取ることができることになる。

【００６７】ここで図５Ｂを参照すると、複数の位置を有するユーザのための電子メールプ
ロセスを示す流れ図が示されている。図３Ａに示したものと類似しているこの実
施例の各ステップについては以前に詳細に説明されており、ここでの詳しい説明
はしない。

【００６８】例示した状況では、ユーザ１がユーザ２に電子メールを書く（ステップ３０２
）。その電子メールパケットはユーザ２に送るべく暗号化される（ステップ３０
４）。しかし、ユーザ１とユーザ２との間のセキュリティを確保したチャネルは
存在せず、その電子メールは迂回されて（ステップ３０６）、マネージャ１１２
に送られる。

【００６９】マネージャ１１２はユーザ１からの電子メールパケットを受け取る（ステップ
３１４）。次にマネージャ１１２はユーザ１−マネージャ１１２の鍵を用いてそ
の電子メールパケットを解読する（ステップ３１６）。

【００７０】次にマネージャ１１２は、ユーザ２−マネージャのセキュリティを確保したチ
ャネルのプロパティ（特性）で開かれた電子メールパケットを再度暗号化し（ス
テップ３１８）、この暗号化された電子メールパケットをユーザ２に送る（ステ
ップ３２０）。マネージャ１１２に対する鍵を有するユーザ２は、そのパケット
を受け取り（３２２）、それを解読する。

【００７１】損傷鍵の修復ここで図６を参照すると、損傷鍵の修復におけるステップを示す流れ図が示さ
れている。

【００７２】ユーザ１はセキュリティを確保された電子メールパケットをユーザ２に送る（
ステップ３５０）。その電子メールパケットはユーザ２に送るべく暗号化される
（ステップ３５２）。ユーザ２はその電子メールを受け取る（ステップ３５４）
が、ユーザ２はそのパケットを開くことができない（ステップ３５６）。ユーザ
１が保持している鍵の何れかが損なわれているか、ユーザ２が保持している鍵が
損なわれているからである。

【００７３】ユーザ２におけるエージェント１３０は、彼（ユーザ２）が開くことができな
いメールを有していることをマネージャに通知するメッセージと共に、開けない
パケットをマネージャ１１２に送る（ステップ３６０）。

【００７４】上述したように、全ての電子メールパケットは、ユーザ−マネージャ１１２セ
キュリティを確保されたライン用の鍵で暗号化されている。従って、マネージャ
１１２は、その電子メールパケットの元の転送ライン、即ちステップ３５２にお
けるユーザ１−マネージャ間のセキュリティを確保されたライン上の電子メール
パケットのための鍵を受け取る。従って、マネージャ１１２がユーザ２からメッ
セージ及びパケットを受け取る（ステップ３６２）と、マネージャ１１２は元の
メッセージによって運ばれたユーザ１−マネージャ１１２の鍵を用いてパケット
を解読できる（ステップ３６４）。

【００７５】マネージャ１１２は、ユーザ２−マネージャ間のセキュリティを確保されたチ
ャネルのプロパティ（特性）で開かれた電子メールパケットを再度暗号化し（ス
テップ３６６）、暗号化された電子メールパケットをユーザ２に送る。マネージ
ャ１１２に対する鍵を有するユーザ２は、そのパケットを受け取り（ステップ３
６８）、それを解読する。

【００７６】マネージャ１１２は、ユーザ１及びユーザ２に対して、「ステップ３７２」の
ための新たな乱数鍵を選択する。この置き換え用の鍵の交換によって、次回のユ
ーザ１とユーザ２との間の電子メールの転送がマネージャ１１２の助けなしに行
うことが可能となる。

【００７７】古い鍵のリフレッシュ図７を参照すると、古い鍵のリフレッシュにおけるステップの流れ図が示され
ている。その原理は、損傷鍵の修復の原理に類似している。

【００７８】マネージャ１１２は、所定の周期、例えば３週間毎に鍵を更新する。その周期
の終了時に、ユーザ１は、ユーザ２との間の彼の鍵をリフレッシュすることを要
求する。マネージャ１１２は、新たな乱数鍵を生成し、それを２つのユーザに送
ることによってユーザ１−ユーザ２の鍵を更新する（ステップ４０２）。新たな
鍵のそれぞれは、その鍵を生成するためにマネージャが計算する時間であるマネ
ージャの生成時間で決められる。ユーザ１が実際の生成時間で新たな鍵を受け取
るが、ユーザ２は、後の生成時間に受け取り、これによって２人のユーザが同時
に鍵のリフレッシュを要求し、生成が衝突する可能性を低くしている。

【００７９】ユーザ１及びユーザ２は、バックグラウンドで鍵のリフレッシュプロセスが行
われているのを知ることなく通信を続けることができる。ユーザ１が新たな鍵を
受け取り、ユーザ２が新たな鍵を受け取る前にそれを使用する場合は、マネージ
ャ１１２がそのメッセージを回復することができる。

【００８０】図７に例示する状況では、ユーザ１がその新たな鍵を受け取る（ステップ４０
３）。ユーザ１はセキュリティを施した電子メールパケットをユーザ２に送る（
ステップ４０４）。その電子メールパケットは、新たな鍵を用いて暗号化されて
（ステップ４０６）、ユーザ２に送られる。ユーザ２は、この電子メールを受け
取る（ステップ４０８）が、ユーザ２は更新された鍵を有していないので、その
パケットを開くことができない（ステップ４１０）。

【００８１】ユーザ２におけるエージェント１３０は、そのメッセージが新たな鍵を用いて
セキュリティを施されているものと認識する。ユーザ２は、彼（ユーザ２）が新
たな鍵で暗号化されているために開くことがことができないメールを有している
ことをマネージャに通知するメッセージと共に、開けないパケットをマネージャ
１１２に送る（ステップ４１４）。

【００８２】マネージャ１１２が、ユーザ１からの電子メールパケットについてのメッセー
ジをユーザ２から受け取ると（ステップ４１６）、マネージャ１１２は彼のユー
ザ１−マネージャ１１２鍵を用いてそのパケットを解読する（ステップ４１８）
。

【００８３】マネージャ１１２は、ユーザ２−マネージャのセキュリティを確保したチャネ
ルのプロパティ（特性）でパケットを再度暗号化する（ステップ４２０）。

【００８４】マネージャ１１２は、そのパケットをユーザ２に送る（ステップ４２４）。ユ
ーザ２はそのパケットを受け取り（ステップ４２６）、それを解読する。

【００８５】ユーザ２が古い鍵を用いてメッセージをユーザ１に送った場合は、ユーザ１は
依然それを解読することができる。各ユーザはその第１のメッセージが新たな鍵
で解読されるまでＬＳＣＤＢに古い鍵を保存しているのである。

【００８６】本発明は、上述した特定の実施例に限定されないことを当業者は理解されよう
。具体的には、ここで電子メールの転送に関連する本発明の実施例を説明してき
たが、本発明は通信アプリケーションのために用いられるデジタルネットワーク
を介したあらゆる種類の電子的メッセージに適用することができる。本発明の真
の範囲は特許請求の範囲の記載のみによって限定される。

【図面の簡単な説明】

【図１Ａ】従来のセキュリティを確保した電子メールネットワークのアーキテクチャを示
す模式図。

【図１Ｂ】図１Ａの電子メールネットワークを介しての電子メールの転送を示す流れ図。

【図２】本発明の好ましい実施形態に従って構築され動作するセキュリティを確保した
電子メールネットワークのアーキテクチャを示す模式図。

【図３Ａ】図２の電子メールネットワークのセキュリティを施した電子メール転送手順を
示す流れ図。

【図３Ｂ】図２のセキュリティ確保型電子メール管理システムにおける、別のセキュリテ
ィを施した電子メール転送手順を示す流れ図。

【図４Ａ】図２の電子メールネットワークの自動認証式のインストール手順を示す流れ図
。

【図４Ｂ】図２の電子メールネットワークのユーザ認証式のインストール手順を示す流れ
図。

【図５Ａ】図２のセキュリティを確保した電子メールネットワークにおいて用いられる複
数位置ユーザシステムのアーキテクチャを示す模式図。

【図５Ｂ】図２のセキュリティを確保した電子メールネットワークの複数位置ユーザ電子
メール転送手順を示す流れ図。

【図６】図２のセキュリティを確保した電子メールネットワークの損傷鍵交換手順を示
す流れ図。

【図７】図２のセキュリティを確保した電子メールネットワークの古い鍵のリフレッシ
ュ手順を示す流れ図。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷＦターム(参考） 5B017 AA00 AA03 AA07 BA07 CA16 5B085 AE13 BG07 CA04 5J104 AA01 AA16 EA01 EA04 EA15 NA02 PA08

Claims

【特許請求の範囲】

【請求項１】複数のユーザマシンの任意の２つの間でメッセージを転送
するためのメッセージングシステムであって、セキュリティを確保したメッセージ操作を監視するためのメッセージマネージ
ャであって、前記マネージャと前記ユーザマシンのそれぞれとの間の各メッセー
ジチャネルの個別のセキュリティを確保したチャネルの特性を記憶した管理デー
タベースと結び付けられている、該メッセージマネージャと、ユーザマシン毎に設けられた、メッセージのセキュリティを確保するためのロ
ーカルセキュリティメッセージプロセッサであって、前記ユーザマシンと、前記
ユーザマシンの通信の相手方である、前記マネージャを含む他のユーザマシンの
それぞれとの間のチャネル毎の、セキュリティを確保したチャネルの特性を記憶
するローカルデータベースと結び付けられた、該ローカルセキュリティメッセー
ジプロセッサとを有することを特徴とするメッセージングシステム。
【請求項２】前記メッセージマネージャが、前記ユーザマシンの少なく
とも１つの上に前記ローカルセキュリティメッセージプロセッサをインストール
し、少なくとも前記マネージャと前記ユーザマシンとの間のチャネルのセキュリ
ティを確保したチャネルの特性を含む前記ローカルデータベースを供給し、それ
によってインストールの瞬間からセキュリティを確保したメッセージの操作を確
実に行えるようにしていることを特徴とする請求項１に記載のメッセージングシ
ステム。
【請求項３】前記ローカルセキュリティメッセージプロセッサが、通信
を行う相手方のユーザのセキュリティを確保したチャネルの特性が未知である時
、又は前記ローカルセキュリティメッセージプロセッサが他のユーザマシンから
受信したメッセージを解読できない時に、前記メッセージマネージャにメッセー
ジを送るための手段を有することを特徴とする請求項１に記載のメッセージング
システム。
【請求項４】複数のユーザマシンの中の任意の２つの間のセキュリティ
を確保したメッセージ操作を監視するためのメッセージマネージャ。
【請求項５】前記メッセージマネージャが、前記マネージャと前記ユー
ザマシンのそれぞれとの間の各メッセージチャネルのための個別のセキュリティ
を確保したチャネルの特性を記憶する管理データベースに結び付けられているこ
とを特徴とする請求項４に記載のメッセージマネージャ。
【請求項６】前記メッセージマネージャが、前記ユーザマシンの少なく
とも１つの上にローカルセキュリティメッセージプロセッサ及び関連するローカ
ルデータベースをインストールし、少なくとも前記マネージャと前記ユーザマシ
ンとの間のチャネルのセキュリティを確保したチャネルの特性を含む前記関連ロ
ーカルデータベースを供給し、それによってインストールの瞬間からセキュリテ
ィを確保したメッセージの操作を確実に行えるようにしていることを特徴とする
請求項４に記載のメッセージマネージャ。
【請求項７】通信を行う相手方のユーザのセキュリティを確保したチャ
ネルの特性が未知である時、又は前記ローカルセキュリティメッセージプロセッ
サが他のユーザマシンから受信したメッセージを解読できない時にメッセージを
回復することを特徴とする請求項４に記載のメッセージマネージャ。
【請求項８】複数のユーザマシンの中の任意の２つの間のセキュリティ
を確保したメッセージの転送を確実に行えるようにするための方法であって、メッセージマネージャと前記複数のユーザマシンのそれぞれとの間のセキュリ
ティを確保したチャネルの特性を生成する過程と、前記メッセージマネージャと前記複数のユーザマシンとのそれぞれとの間の各
セキュリティを確保したチャネルの前記特性を管理データベースに記憶させる過
程と、前記複数のユーザマシンの少なくとも１つの上にローカルセキュリティメッセ
ージプロセッサをインストールし、かつ前記プロセッサに結び付けられるローカ
ルデータベースを供給する過程と、前記複数のユーザマシンの少なくとも１つと少なくとも前記マネージャとの間
のセキュリティを確保したチャネルの特性、及び前記複数のユーザマシンのそれ
ぞれと他のユーザマシンのそれぞれとの間の前記セキュリティを確保した各チャ
ネル毎のチャネルの特性を、前記ローカルデータベースに記憶させる過程と、インストールの瞬間から、前記複数のユーザマシンの何れかの間のメッセージ
ングのセキュリティを確保する過程とを含むことを特徴とする方法。
【請求項９】前記複数のユーザマシンの２つ以上においてログオンを
する過程と、メッセージを前記メッセージマネージャに送ることによってセキュリティを確
保したメッセージを転送する過程とを更に含むことを特徴とする請求項８に記載
の方法。
【請求項１０】セキュリティを確保したチャネルの特性を生成する前記
過程が、自動的に鍵を生成し、自動的な認証を行う過程を含むことを特徴とする
請求項８に記載の方法。
【請求項１１】セキュリティを確保したチャネルの特性を生成する前記
過程が、認証コードを利用する過程を含むことを特徴とする請求項８に記載の方
法。
【請求項１２】通信しようとする相手方のユーザのセキュリティを確保
したチャネルの特性が未知である時、又は前記ローカルセキュリティメッセージ
プロセッサが他のユーザマシンから受信したメッセージパケットを解読できない
時に、前記メッセージマネージャにメッセージを送信する過程を更に含むことを
特徴とする請求項８に記載の方法。
【請求項１３】ユーザの通信フローに割り込みを入れることなく前記複
数のユーザマシンの任意の２つの間の前記セキュリティを確保したチャネルのた
めの前記セキュリティを確保したチャネルの特性を再生成する過程を更に含むこ
とを特徴とする請求項８に記載の方法。
【請求項１４】前記セキュリティを確保したチャネルの特性を再生成す
る前記過程が、所定の周期毎に前記セキュリティを確保したチャネルの特性を再
生成する過程を含むことを特徴とする請求項１３に記載の方法。
【請求項１５】前記セキュリティを確保したチャネルの特性を再生成す
る過程が、前記ローカルセキュリティメッセージプロセッサが他のユーザマシン
から受信したメッセージパケットを解読できない時に、前記セキュリティを確保
したチャネルの特性を再生成する過程を含むことを特徴とする請求項１３に記載
の方法。