"対称鍵の暗号技術を使用して、組織外の送信者と、組織内または前記組織の顧客である受信者との間の安全な通信をサポートする方法であって、前記送信者と前記組織との間に安全な通信チャネルを確立するステップと、前記組織において、マスター鍵から対称鍵を導出するステップと、前記組織において、乱数Nを生成するステップと、前記組織において、前記導出対称鍵および前記乱数Nに基づいて、非顧客対称メッセージ鍵を生成するステップと、前記安全な通信チャネルを通じて、前記送信者に、前記非顧客対称メッセージ鍵および前記乱数Nを提供するステップと、前記送信者において、前記受信者に対するメッセージを暗号化するために、前記非顧客対称メッセージ鍵を使用するステップとを含む、方法。前記送信者において、前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップをさらに含み、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、請求項1に記載の方法。前記送信者において前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、前記受信者において、前記非顧客メッセージ鍵を取得するために、前記乱数Nを使用するステップとをさらに含む、請求項1に記載の方法。前記組織は、サーバーを有し、前記受信者は、受信者IDを有し、前記送信者において前記メッセージを暗号化するステップは、暗号文を作成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、前記受信者において、前記サーバーから前記非顧客メッセージ鍵を取得する際に、前記乱数Nを受信して、前記受信者IDおよび前記乱数Nを使用するステップとをさらに含む、請求項1に記載の方法。前記組織は、サーバーおよび鍵生成器を有し、前記受信者は、受信者IDを有し、前記送信者において前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、前記受信者において、前記サーバーから前記非顧客メッセージ鍵を要求するために、前記乱数Nを受信して、前記受信者IDおよび前記乱数Nを使用するステップと、前記サーバーにおいて、前記鍵生成器から前記導出対称鍵を取得するために、前記受信者IDを使用して、前記鍵生成器からの前記導出対称鍵および前記受信者からの前記乱数Nを使用して、前記受信者に対する前記非顧客メッセージ鍵を計算するステップとをさらに含む、請求項1に記載の方法。前記受信者は、受信者IDを有し、前記マスター鍵から前記対称鍵を導出するステップは、前記導出対称鍵を生成するために、前記マスター鍵および受信者IDにHMAC関数を適用するステップを含む、請求項1に記載の方法。本発明の目的は、対称鍵を使用して安全な通信を容易にする、メッセージングシステムを提供することにある。対称メッセージ鍵を使用して、送信者と受信者との間で安全なメッセージを送信することができる。組織は、マスター鍵から対称メッセージ鍵を導出する、鍵生成器を有することもある。鍵生成器は、マスター鍵および受信者のアイデンティティ情報すなわち、受信者IDに、HMAC関数のような一方向性関数または他のハッシュ関数を適用することによって、導出鍵を生成することができる。得られた導出鍵は、各受信者に固有である。導出鍵に障害が生じても、マスター鍵には障害は生じず、セキュリティの確保を支える。送信者は、組織の顧客である受信者に対するメッセージを暗号化するために、導出鍵を使用することが可能である。受信者はその組織の顧客であるので、受信者と組織との間には既存の関係がある。したがって、その組織は、受信者を認証するために使用することができる、受信者の信用証明情報を有する。受信者が暗号化メッセージを受信するとき、受信者は、組織に対して認証することができ、またそのメッセージを解読するために、導出鍵のコピーを要求することができる。導出鍵の要求は、受信者IDを含む。受信者からの鍵要求が提供される受信者IDは、導出鍵の新しいコピーを導出するために、鍵生成器により使用されることが可能である。この導出鍵の新しいコピーは、次いで安全な通信チャネルを通じて、受信者に提供することが可能である。受信者は、受信した導出鍵のコピーで暗号化メッセージを解読するために、受信者の装置上の暗号解読エンジンを使用することが可能である。階層的鍵生成器のアーキテクチャは、複数の組織的ユニットを有する組織に対して使用することができる。各ユニットは、そのユニット内の送信者に対する導出対称鍵を生成する、委譲鍵生成器をそれぞれ有してもよい。組織は、スーパーマスター鍵を有する、スーパー鍵生成器を有することができる。スーパー鍵生成器は、各委譲鍵生成器に対するサブマスター鍵を導出することができる。対称鍵の機構はまた、組織の顧客ではない組織外の送信者が、その組織内の受信者にメッセージを送ることができるようにするためにも使用することができる。組織は、マスター鍵および受信者IDに基づいて、導出鍵を作成するための鍵生成器を有することができる。組織内のポリシーサーバーは、非顧客対称鍵を生成する導出するために、導出鍵および乱数Nを使用することが可能である。例えば、鍵生成器は、導出鍵を生成するために、マスター鍵および受信者IDにHMAC関数を適用することができる。ポリシーサーバーは、乱数Nを生成することが可能であり、また非顧客メッセージ鍵を生成するために、鍵生成器からの導出鍵および乱数Nに、HMAC関数を適用することが可能である。送信者が組織内の受信者にメッセージを送りたい場合は、送信者およびポリシーサーバーは、安全なリンクを確立する。ポリシーサーバーは、安全なリンクを通じて、送信者に非顧客メッセージ鍵を提供する。送信者は、非顧客メッセージ鍵を使用して、受信者に対するメッセージを暗号化する。送信者は、次いで受信者にNの値を含む暗号化メッセージを送信する。受信者において、受信者は、ポリシーサーバーから非顧客メッセージ鍵のコピーを取得するために、受信者IDおよびNの値を使用することができる。受信者は、次いで送信者からの暗号化メッセージを解読することができる。本発明の更なる特徴、性質、および様々な利点は、添付図面および以下の好適な実施態様の詳細な説明からより明らかになろう。例えば、本発明は以下の項目を提供する。項目1組織において、送信者が、通信ネットワークを通じて、前記組織の顧客である受信者にメッセージを送信するための方法であって、前記受信者は、受信者アイデンティティIDを有し、前記方法は、前記組織において、一方向関数であって、前記一方向関数の入力がマスター鍵および前記受信者IDを含む、一方向関数を使用して、前記マスター鍵から前記メッセージを暗号化するための対称鍵を導出するステップと、前記組織において、前記導出対称鍵を使用して前記メッセージを暗号化し、前記通信ネットワークを通じて、前記受信者に前記メッセージを送信するステップと、前記受信者において、前記暗号化メッセージを受信するステップと、前記受信者において、前記通信ネットワークを通じて、前記組織に導出対称鍵の要求をサブミットするステップであって、前記導出対称鍵の要求は前記受信者IDを含む、ステップと、前記通信ネットワークを通じて、前記組織に対して前記受信者を認証し、前記組織と前記受信者との間に安全な通信チャネルを確立するステップと、前記受信者の前記導出対称鍵の要求に応えて、前記受信者が前記メッセージの解読において使用する前記導出対称鍵を生成して、前記安全な通信チャネルを通じて、前記受信者に前記導出対称鍵を提供するステップと、を含む、方法。項目2前記対称鍵を導出するステップは、前記対称鍵を導出するために、ハッシュ関数を使用するステップを含む、項目1に記載の方法。項目3前記対称鍵を導出するステップは、前記対称鍵を導出するために、デジタル署名機能を使用するステップを含む、項目1に記載の方法。項目4前記組織はゲートウェイを有し、前記メッセージを暗号化するステップは、前記ゲートウェイにおいて前記メッセージを暗号化するために、前記導出対称鍵を使用するステップを含む、項目1に記載の方法。項目5前記組織はゲートウェイおよび鍵生成器を有し、前記メッセージを暗号化するステップは、前記組織において前記鍵生成器に前記受信者IDを含む導出鍵の要求を提供するために、前記組織において前記ゲートウェイを使用するステップと、前記ゲートウェイからの前記導出鍵の要求に応えて、前記一方向性関数を使用して、前記導出鍵を計算するために、前記鍵生成器を使用するステップとを含む、項目1に記載の方法。項目6前記組織は、サーバーおよび鍵生成器を有し、前記組織に対して前記受信者を認証するステップは、前記受信者を認証するために前記サーバーを使用するステップを含み、前記受信者が前記メッセージの解読において使用する前記導出対称鍵を生成するステップは、前記サーバーからの導出鍵の要求に応えて、前記受信者に対する前記導出対称鍵を生成するために、前記鍵生成器を使用するステップを含む、項目1に記載の方法。項目7前記組織は暗号解読サーバーおよび鍵生成器を有し、前記通信ネットワークを通じて、前記受信者を認証し、前記組織と前記受信者との間に安全な通信チャネルを確立するステップは、前記暗号解読サーバーに対して前記受信者を認証し、前記暗号解読サーバーと前記受信者との間にセキュアソケットレイヤーSSLリンクを確立するために、前記暗号解読サーバーを使用するステップを含み、前記受信者が前記メッセージの解読において使用する前記導出対称鍵を生成するステップは、前記暗号解読サーバーからの導出鍵の要求に応えて、前記受信者に対する前記導出対称鍵を生成するために、前記鍵生成器を使用するステップを含み、前記受信者に暗号解読鍵を提供するステップは、前記SSLリンクを通じて、前記鍵生成器から前記受信者に前記暗号解読鍵を提供するために、前記暗号解読サーバーを使用するステップを含む、項目1に記載の方法。項目8組織において、送信者が受信者にメッセージを送信するための方法であって、前記組織は、ゲートウェイと、鍵生成器と、サーバーと、前記送信者、前記ゲートウェイ、前記鍵生成器、および前記サーバーが接続されるイントラネットと、を有し、前記受信者は、前記組織外にあり、前記受信者は、前記組織の顧客であり、前記受信者は、受信者アイデンティティIDを有し、前記方法は、HMAC関数であって、前記HMAC関数の入力がマスター鍵および前記受信者IDを含む、HMAC関数を使用して、前記マスター鍵から前記メッセージを暗号化するための対称鍵メッセージを導出するために、前記鍵生成器を使用するステップと、前記イントラネットを通じて、前記鍵生成器から前記ゲートウェイに前記導出対称鍵を提供するステップと、暗号化メッセージを生成するために、前記導出対称鍵を使用して、前記ゲートウェイにおいて前記メッセージを暗号化するステップと、インターネットを通じて、前記ゲートウェイから前記組織外の前記受信者に前記暗号化メッセージを提供するステップと、前記受信者において、暗号化メッセージを受信するステップと、前記サーバーに対して前記受信者を認証し、前記サーバーと前記受信者との間にセキュアソケットレイヤーSSLリンクを確立するステップと、前記受信者から前記サーバーに導出対称鍵の要求を提供するステップであって、前記導出対称鍵の要求は前記受信者IDを含む、ステップと、前記受信者IDを使用して、前記イントラネットを通じて、前記鍵生成器から前記導出対称鍵を取得し、前記SSLリンクを通じて、前記鍵生成器から取得した前記導出対称鍵を前記受信者に提供するために、前記サーバーを使用するステップと、前記受信者において、前記暗号化メッセージを解読するために、前記SSLリンクを通じて、前記サーバーによって提供された導出対称鍵を使用するステップとを含む、方法。項目9一方向性関数を使用して、スーパーマスター鍵から前記マスター鍵を導出するステップをさらに含む、項目8に記載の方法。項目10複数のユニットを有する組織に対する安全な通信をサポートするために、階層的鍵生成器アーキテクチャを使用するための方法であって、前記組織は、スーパー鍵生成器と、複数の委譲鍵生成器と、を有し、前記方法は、スーパーマスター鍵から複数の導出サブマスター鍵を生成するために、前記スーパー鍵生成器を使用するステップであって、各導出サブマスター鍵は、前記複数のユニットのうちのそれぞれ1つにおいて、前記委譲鍵生成器のうちのそれぞれ1つに提供される、ステップと、前記ユニットのうちの所与の1つのユニットにおいて、前記所与のユニット内の送信者に、前記所与のユニットの顧客である前記組織外の受信者に安全に通信されるメッセージの作成を許可するステップであって、前記受信者は受信者アイデンティティIDを有する、ステップと、前記所与のユニットにおいて、一方向性関数であって、前記一方向性関数の入力がサブマスター鍵および前記受信者IDを含む一方向性関数を使用して、その委譲鍵生成器に提供された前記サブマスター鍵からメッセージを暗号化するための対称鍵を導出するために、その所与のユニットの前記委譲鍵生成器を使用するステップと、前記所与のユニットにおいて、前記導出対称鍵を使用して前記メッセージを暗号化し、通信ネットワークを通じて、前記受信者に前記メッセージを送信するステップと、前記受信者において、前記暗号化メッセージを受信するステップと、前記受信者において、前記通信ネットワークを通じて、前記所与のユニットに導出対称鍵の要求をサブミットするステップであって、前記導出対称鍵の要求は前記受信者IDを含む、ステップと、前記通信ネットワークを通じて、前記所与のユニットに対して前記受信者を認証し、前記所与のユニットと前記受信者との間に安全な通信チャネルを確立するステップと、前記受信者が前記メッセージの解読において使用する前記導出対称鍵を生成するために、前記所与のユニットの前記委譲鍵生成器を使用して、前記安全な通信チャネルを通じて、前記受信者に前記所与のユニットからの前記導出対称鍵を提供するステップとを含む、方法。項目11前記所与のユニットは、暗号解読サーバーを有し、前記所与のユニットに対して前記受信者を認証するステップは、予め制定した受信者信用証明書を使用して、前記暗号解読サーバーに対して前記受信者を認証するステップを含む、項目10に記載の方法。項目12前記メッセージを暗号化するステップは、前記送信者において、前記メッセージを暗号化するステップを含む、項目10に記載の方法。項目13前記導出対称鍵の要求をサブミットするステップは、前記所与のユニットの前記委譲鍵生成器の識別名を含む要求をサブミットするステップを含む、項目10に記載の方法。項目14前記スーパーマスター鍵から複数の導出サブマスター鍵を生成するステップは、前記スーパーマスター鍵および各ユニットに関連する名前を入力として使用して、HMAC関数に対する値を計算するステップを含む、項目10に記載の方法。項目15対称鍵の暗号技術を使用して、組織外の送信者と、組織内または前記組織の顧客である受信者との間の安全な通信をサポートする方法であって、前記送信者と前記組織との間に安全な通信チャネルを確立するステップと、前記組織において、マスター鍵から対称鍵を導出するステップと、前記組織において、乱数Nを生成するステップと、前記組織において、前記導出対称鍵および前記乱数Nに基づいて、非顧客対称メッセージ鍵を生成するステップと、前記安全な通信チャネルを通じて、前記送信者に、前記非顧客対称メッセージ鍵および前記乱数Nを提供するステップと、前記送信者において、前記受信者に対するメッセージを暗号化するために、前記非顧客対称メッセージ鍵を使用するステップとを含む、方法。項目16前記送信者において、前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップをさらに含み、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、項目15に記載の方法。項目17前記送信者において前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、前記受信者において、前記非顧客メッセージ鍵を取得するために、前記乱数Nを使用するステップとをさらに含む、項目15に記載の方法。項目18前記組織は、サーバーを有し、前記受信者は、受信者IDを有し、前記送信者において前記メッセージを暗号化するステップは、暗号文を作成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、前記受信者において、前記サーバーから前記非顧客メッセージ鍵を取得する際に、前記乱数Nを受信して、前記受信者IDおよび前記乱数Nを使用するステップとをさらに含む、項目15に記載の方法。項目19前記組織は、サーバーおよび鍵生成器を有し、前記受信者は、受信者IDを有し、前記送信者において前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、前記組織外の前記送信者から前記受信者に前記暗号化メッセージを送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、前記受信者において、前記サーバーから前記非顧客メッセージ鍵を要求するために、前記乱数Nを受信して、前記受信者IDおよび前記乱数Nを使用するステップと、前記サーバーにおいて、前記鍵生成器から前記導出対称鍵を取得するために、前記受信者IDを使用して、前記鍵生成器からの前記導出対称鍵および前記受信者からの前記乱数Nを使用して、前記受信者に対する前記非顧客メッセージ鍵を計算するステップとをさらに含む、項目15に記載の方法。項目20前記受信者は、受信者IDを有し、前記マスター鍵から前記対称鍵を導出するステップは、前記導出対称鍵を生成するために、前記マスター鍵および受信者IDにHMAC関数を適用するステップを含む、項目15に記載の方法。本発明は、安全なメッセージングをサポートするためのシステムのような、暗号システムに関する。本発明はまた、当該のシステムを使用する方法にも関する。図1のシステム10内に示される種類の装置は、送信者と受信者との間の安全な通信をサポートするために使用することができる。送信者は、メッセージを送信するユーザーである。受信者は、メッセージを受信するユーザーである。ユーザーは、概してメッセージの送信および受信の両方を行えるので、所与のユーザーは、ある時には送信者となり、別の時には受信者となりうる。システム10内のいくつかのユーザーは、組織18のような組織に属してもよい。他のユーザーは、異なる組織に属している場合もあれば、いかなる組織にも属していない場合がある。図1の例では、送信者AおよびユーザーBは、組織Aに属するユーザーである。受信者CおよびユーザーDは、組織Aに属さないユーザーである。システム10内のいくつかのユーザーアクティビティは、人から人へ電子メールメッセージを送信するような、人の手の介入を伴う。例えば、個人的に構成したテキストメッセージを送信したい人は、そのメッセージが暗号化され、適切な受信者に送信される前に、そのメッセージを入力しなければならない。システム10における他のユーザーアクティビティは、人の介入が概ね不要となるように、完全に自動化されてもよい。一例として、組織は、コンピュータを使用して、その顧客のそれぞれに自動的にメッセージを送信することができる。この種のシナリオでは、コンピュータは、一種のユーザーすなわちこの例では送信者としての機能を果たす。以下の説明では、人およびその装置の両方の説明に、送信者、受信者、およびユーザーという用語を使用する。一例として電子メールメッセージを使用しているが、システムによって運ばれるメッセージは、電子メールメッセージでなくてもよい。メッセージは、電子メールメッセージ、インスタントメッセージ、または他の好適な電子的に伝達されるメッセージであってよい。メッセージには、送信者と受信者との間で電子的に伝達される、あらゆるデジタル情報例、テキスト、グラフィックス、音声、ビデオ、コマンド、実行コード、データなどが含まれてもよい。システム10内のユーザーは、装置12を使用して互いに通信することができる。装置12およびシステム内の他のエンティティのための装置には、例えば、パーソナルコンピュータ、ポータブルコンピュータ、ワークステーション、メインフレームコンピュータ、ローカルエリアネットワーク内でホストコンピュータを使用してインターネットに接続されるコンピュータ端末のようなネットワークコンピュータまたは端末、ハンドヘルドコンピュータ、携帯電話、または他の好適な電子装置のような計算機器が挙げられる。図1の装置は、通信ネットワーク14およびイントラネット16内の通信経路によって相互接続することができる。ネットワーク14には、インターネットおよび他のワイドエリアネットワーク、1つ以上のイントラネット、ローカルエリアネットワーク、交換電話網、仮想プライベートネットワークのようなネットワーク、専用回線を含むネットワーク、有線または無線経路に基づくネットワーク、または他の好適なネットワーク技術を使用して形成された他のネットワークが挙げられる。イントラネット16のようなイントラネットは、特定の組織において、複数のユーザーをネットワーク化するために使用される、通信ネットワークである。例えば、図1のイントラネット16は、組織18に関連し、送信者AおよびユーザーBに対する装置12、鍵生成器20、ゲートウェイ22、および暗号解読サーバー24のような、装置を相互接続するために使用される。イントラネット16のようなイントラネットは、ローカルエリアネットワークでもワイドエリアネットワークでもよい。小企業の例示的イントラネットは、例えば、ten―seatイーサネット登録商標ネットワークとすることができる。大きな組織は、遠く離れた場所において複数のキャンパスを有するとすることができる。当該の組織のイントラネットは、インターネット上で、安全な経路によって互いにリンクされる各キャンパスにおいて、イーサネット登録商標ベースのローカルエリアネットワークから構築することができる。システム10は、鍵を生成するための、鍵生成器20のような鍵生成器を有することができる。鍵生成器20は、複数のユーザー固有の鍵をマスター鍵26から導出することができる。メッセージは、暗号化エンジンを使用して暗号化することができ、また暗号解読エンジンを使用して解読することができる。任意の好適な暗号アルゴリズムを、システム10においてメッセージの暗号化および暗号解読に使用することができる。対称鍵暗号機構であることが好ましい。好適な対称鍵アルゴリズムには、AESAdvancedEncryptionStandard;高度暗号化規格、DESDataEncryptionStandard;データ暗号化規格、トリプルDESなどが挙げられる。1つの好適な機構では、組織18の送信者からの全てのメッセージは、イントラネット16およびゲートウェイ22を介して、ネットワーク14に転送される。ゲートウェイ22は、メッセージを暗号化するための、暗号化エンジン28を有することができる。受信者は、暗号化メッセージを受信した後に、受信者Cの暗号解読エンジン34のような暗号解読エンジンを使用して、そのメッセージを解読することができる。対称鍵の暗号技術では、暗号化および暗号解読オペレーションの両方に、同じ鍵が使用される。組織18の外部の受信者Cのような受信者は、暗号化エンジン28が、組織18への鍵要求を行うことによって、暗号化に使用するゲートウェイ22において、鍵のコピーを取得することができる。受信者は、鍵を入手すると、そのメッセージを解読して、その内容にアクセスするために、暗号解読エンジン34のような暗号解読エンジンを使用することができる。暗号解読サーバー24は、鍵に対する要求を処理するために使用することができる。認証サービス30は、ユーザーに要求された鍵が提供される前に、ユーザーを認証するために使用することができる。キー配信サービス32は、認証された要求元の鍵要求を満たすために使用することができる。1つの好適なシナリオでは、ユーザーは、電子メールアプリケーション、ウェブブラウザエンジンすなわち、組み込みのウェブブラウザ機能を有する電子メールアプリケーション、ウェブブラウザアプリケーション、文書の作成および編集用アプリケーション、画像ビューア、メディアプレーヤなどのような、ソフトウェアアプリケーションクライアントソフトウェアを有する。暗号化および暗号解読エンジンの機能は、スタンドアロンの暗号化および暗号解読アプリケーションを使用して提供されても、あるいはこれらのアプリケーションと統合された暗号化および暗号解読ソフトウェアコンポーネントを使用して提供されてもよい。一例として、受信者が使用する電子メールプログラムのような電子メールプログラムは、暗号解読エンジンを有することができる。暗号化エンジンは、電子メールアプリケーション内のネイティブコードの一部として提供されても、あるいはプラグインモジュールとして組み込まれてもよい。別の例として、ゲートウェイ22のようなゲートウェイの管理に使用されるソフトウェアが組み込みの暗号化エンジンを有してもよく、あるいは暗号化エンジンを独立したソフトウェアコンポーネントとして提供してもよい。様々なコンピュータを、システム10に使用することが可能である。例えば、計算機器は、各鍵生成器20、ゲートウェイ22、および暗号解読サーバー24において、サーバーまたは他のコンピュータ機器の機能を実行するために使用することができる。サーバーはまた、認証局、メールサーバー、および他のエンティティの機能をサポートするために使用することが可能である。当該のサーバーは、送信者または送信者の組織と同じ場所に配置するか、独立した第三者のサービスとしてネットワーク14に接続するか、ネットワーク14のインフラの一部とするか、所与の受信者の組織と関連付けるか、受信者、鍵生成器、または他の装置と同じ場所に配置するか、またはこれらの場所うちの1つ以上で使用することができる。これらは、相互に排他的とする必要のない、単なる例示的機構である。サーバーは、単一のコンピュータまたは複数のコンピュータを使用して形成することができる。複数のサーバーを、1つのコンピュータ上で実行することができる。必要に応じて、単一のサーバーの機能は、複数の異なる物理的な場所を通じて分配されるコンピュータによって提供することができる。システム10内のサーバーを使用して実行される機能は、必要に応じて、概して他のコンピュータ機器の構成を使用して実行することができるが、これらの機能を実行するための計算機器は、サーバーまたはサーバー群と称することがある。送信者は、メッセージを、任意の好適なメッセージングフォーマットを使用して、システム10を通じて、所与の受信者に送信することができる。例えば、電子メールメッセージ、インスタントメッセージ例、AOLインスタントメッセージ、Yahooインスタントメッセージ、MSNメッセンジャインスタントメッセージ、および、ICQインスタントメッセージ、IBM/Lotusセームタイムインスタントメッセージなど、または他の電子メールメッセージを送信することができる。システム10のオペレーション中に、暗号解読サーバー24のような特定のエンティティは、所与のパーティが、鍵を取得するための、新しいクライアントソフトウェア例えば、暗号解読アルゴリズムを含むをダウンロードするための、特定のメッセージの内容にアクセスするための、または他の機能を実行するための許可を有することを確認する必要がある場合がある。一般に、当該の認証および承認プロセスを行うエンティティは、任意の好適な手動または自動の手法を使用することが可能である。例えば、パーティは、そのパーティの正式なレターヘッドに関して、認証エンティティにレターのファックスまたはメールを求められる場合があるが、認証エンティティにおいて、要員または自動装置により信頼性が調査される。別の例として、バイオメトリック認証技術例、指紋解析、眼球走査、手形または声紋解析、顔面の認識法、または対面による識別確認を使用することが可能である。アイデンティティを確立するために、ハードウェアベースの機構例、ハードウェアトークンに基づくものを使用してもよい。ユーザーは、予め定められたユーザー名およびパスワードの形式で、信用証明書を提供してもよい。認証局は、特定のパーティのアイデンティティの確認を助力する、デジタル証明書を作成することができる。デジタル署名例えば、認証局からの署名、または秘密鍵を使用する他のエンティティ、および公開鍵を使用して確認できる他のエンティティからの署名は、メッセージまたは他の署名された情報が特定のパーティに関連することを確認するために使用することができる。システム10における認証プロセスは、Kerberosチケットまたは他の承認の証明のようなチケットの生成を伴う場合がある。ユーザー認証オペレーションは、本願明細書において、受信者の信用証明情報や基となるユーザー名およびパスワード、またはユーザーにより入力されたその他の受信者の信用証明情報から導出されるか、またはこれに基づくチケット情報のような情報の区別を必要とせずに、一般的に記述されている。認証情報および他の情報は、パーティ間例、暗号解読サーバー24とユーザーとの間で安全に伝達されなければならない場合がある。システム10において安全に情報を伝達するために、複数の異なる手法を使用することが可能である。例えば、情報は、セキュアソケットレイヤーSSLプロトコルまたは他の好適な安全なプロトコル例えばTLSを使用する通信経路のような安全な通信経路を通じて、安全に伝達することができる。通信経路は、信頼できるパーティの制御下にある例、通信経路が完全に組織18内にあるため、物理的に信頼できるパーティの制御下にあるため、信頼できる。情報は、安全でないまたは安全なリンクを通じて送信する前に、例えばメッセージなどでその情報を暗号化することによって、安全に送信することが可能である。既存の暗号化機構とのインターフェースを容易にするため、または他の好適な理由で、メッセージの内容を暗号化するために第1の鍵を使用し、第1の鍵を暗号化するために第2の鍵を使用する、ツーステップの暗号化技術を使用することが望ましい場合がある。暗号解読中に、第1の鍵の暗号化バージョンを解読するために、第2の鍵を使用するが、第2の鍵は、次いでメッセージの内容をアンロックするために使用することができる。これらのツーステッププロセスおよび類似した高次のマルチステッププロセスは、純粋なまたはシングルステップの暗号化アルゴリズムよりも効率的な場合があり、必要に応じて使用することができる。明確にするため、本発明では、シングルステップアルゴリズムのコンテキストにおいて説明する。公開鍵の暗号技術は、安全なメッセージングシステムにおいてしばしば使用される。公開鍵の暗号技術によって、送信者は、その受信者の公開鍵を使用して、受信者に対するメッセージを暗号化することができる。受信者は、暗号解読のためにマッチング秘密鍵を使用する。公開鍵の暗号技術は、概ね満足できるものであるが、送信者と受信者との間にすでに関係が存在するような環境においては、必要以上に扱いにくくなる場合がある。組織18が銀行であるような例示的シナリオを考察する。銀行は、安全に電子預金取引明細書を配信することが求められる、既存の一組の顧客を有する。銀行と顧客には、すでに互いに信頼できる関係がある。例えば、銀行は、その顧客にすでに割り当てたアカウント名および番号を有する。顧客が自分のアカウントを開いたときに、銀行は、社会保障番号情報、電話番号、親類の名前、生年月日、出生地、電子メールアドレスなどの情報を収集している。この情報は、銀行が顧客のアイデンティティを確認するために使用できる。銀行の顧客はまた、現金自動預払機から現金を引き出すための暗証番号PIN、およびオンラインで銀行取引タスクを行う前の認証のためのユーザー名およびパスワードも有することが可能である。この種の環境では、銀行およびその顧客は、見知らぬ者同士ではない。したがって、銀行およびその顧客は、送信者および受信者を互いに見知らぬものとして扱うことができるようにデザインされた、公開鍵の暗号技術のような暗号手法にのみ依存する必要がない。本発明は、銀行とその顧客との間の先在する関係を活用することができる。公開鍵の暗号化ではなく、効率的な対称鍵の暗号化を使用することができる。銀行とその顧客との間の先在する関係はまた、認証および鍵配送のようなオペレーションを容易にするために使用することができる。以下の説明において、組織18は、企業または会社、あるいは他の好適な種類の企業体であってよい。組織のユーザーは、従業員、ボランティア、契約者、または組織またはそれらの装置の他の好適な種類のメンバーであってよい。組織内のユーザーは、イントラネット16へのアクセス、およびゲートウェイ22のようなイントラネット16を使用した組織内に互いにネットワーク化された装置によって、組織外のユーザーと区別される。組織外のユーザーの一部は、その組織とは関係のない、独立した第三者であってよい。組織外の他のユーザーは、組織の顧客であってよい。例えば、上述のように、銀行の口座名義人は、銀行の顧客である。顧客は、クライアント、契約者、その組織で働く従業員と同じアクセス権を持たない臨時従業員、または顧客としてその組織と関連しているが、その組織自体の一員ではない顧客である、他の好適なユーザーであってよい。ユーザーが、顧客として所与の組織と関連付けられた場合、ユーザーとその組織との間の関係は、本発明の安全な通信技術をサポートするために活用することができる。一般的なシナリオでは、銀行18の自動預金取引明細書の配布サーバーは、受信者Cのような顧客である受信者に、暗号化した預金取引明細書メッセージを送信する。送信者Aは、ゲートウェイ22を介して各メッセージを送信する。ゲートウェイ22は、対称鍵を使用して各メッセージを暗号化するために、暗号化エンジン28を使用する。対称鍵は、鍵生成器20によってマスター鍵26から導出されるので、導出鍵と称する。多くの異なる鍵をこのように導出することができるため、導出鍵は、各受信者に対して一意に生成することが可能である。任意のユーザーの鍵は、必要に応じてユーザーIDから再導出することができるので、決定論的な鍵導出機構を使用することによって、導出鍵は、鍵生成器によって格納する必要がない。ゲートウェイが、受信者Cの導出対称鍵を使用して、受信者Cに対するメッセージを暗号化した後、そのゲートウェイは、受信者Cに暗号化メッセージを中継することが可能である。暗号化メッセージは、通信ネットワーク14を通じて、受信者Cに送達することが可能である。受信者Cは、暗号化メッセージを受信すると、メッセージの内容を解読するために暗号解読エンジン34を使用できるように、組織Aから導出鍵のコピーを取得することが可能である。受信者Cは、鍵要求を暗号解読サーバー24に送信することによって、受信者Cの導出鍵を取得することができる。受信者Cは銀行の顧客なので、認証サービス30は、受信者Cを認証するために、受信者Cのアカウント名およびPINのような先在する受信者信用証明書を使用することが可能である。認証サービス30が、受信者Cのアイデンティティを確認し、受信者Cが導出鍵のコピーの取得を許可されたと判断すると、受信者Cに対する導出鍵は、鍵配信サービス32を使用して、受信者Cに送達することが可能である。システム10の設定、および導出鍵の要求に対する応答の際に伴われる例示的ステップを図2に示す。設定オペレーションは、ステップ36で行われる。設定中に、鍵生成器20によってマスター鍵26を生成することが可能である。マスター鍵26は、例えば、十分なエントロピすなわち、マスター鍵のサイズと同数のエントロピを有するランダムな文字列から生成することが可能である。ランダムな文字列には、任意の好適なシンボルを含むことができる。一般に、数字、文字、および他のシンボルと、情報を表すための他の当該のスキームとの間には同等性がある。これらの異なる代表的なスキーム間の固有の同等性により、文字またはシンボルの数字への変換を伴う技術、または複数の数字または文字列を単一の数字または他の当該のオペレーションとして表すための技術は、本願明細書では詳述しない。鍵生成器は、マスターシークレットに障害が生じないように、安全なサーバー上で実行されることが好ましい。マスター鍵26の生成のような設定オペレーションが行われた後で、鍵生成器20は、組織18において、他の装置からの導出鍵に対する要求に応答することができる。導出鍵は、特定の目的のため例、特定の受信者に対応するために、マスター鍵26から導出される鍵である。1つまたは複数の導出鍵に障害が生じても、他の導出鍵に依存する他のオペレーションのセキュリティには障害が生じない。さらに、マスター鍵は、任意の一群の導出鍵から都合よく導出することができず、マスター鍵を保護する。導出鍵の要求に応答するプロセスは、ステップ38、40、および42を伴う。これらのステップは、一般に、破線37で示されるように、ステップ36の設定オペレーションとは異なる時間に行われる。導出鍵の要求を生成することができる組織18のエンティティは、ゲートウェイ22、暗号解読サーバー24、およびユーザー12を含むことが可能である。鍵生成器20から直接に導出鍵を要求するユーザーは、暗号化エンジン28のようなゲートウェイ上の暗号化エンジンを使用せずに、クライアントソフトウェア内の暗号化エンジンを使用して、暗号化を行うことが可能である。したがって、ゲートウェイ22のようなゲートウェイを使用することはオプションであり、その組織のポリシーによって規定される。ゲートウェイを有するシステムでは、ゲートウェイは、暗号化エンジン28で使用する導出鍵を要求することができる。暗号解読サーバー24は、組織外のユーザーに代わって鍵を要求することが可能である。鍵要求は、イントラネット16を通じて、鍵生成器20に提供することが可能である。ステップ38で、鍵生成器20は、ゲートウェイ22、暗号解読サーバー24、または送信者Aなどの組織内のユーザーのような、組織内の信頼できるエンティティからの要求を受信する。導出鍵の要求は、これらの信頼できるエンティティによってのみ承認されることが好ましい。導出鍵は特定のユーザー例えば顧客に固有であるので、導出鍵の要求は、ユーザー識別子ユーザーIDを含むことが好ましい。例えば、受信者に対するメッセージを暗号化するために、導出鍵が要求されている場合、その鍵に対する要求は、受信者のアイデンティティに関する情報すなわち、受信者IDを含まなければならない。ステップ40で、鍵生成器20は、要求された導出鍵を計算する。要求された導出鍵は、その要求において提供された受信者IDに対して一意のものである。必要に応じて、導出鍵は、他の点において一意とするか、または受信者のID情報を含まないようにすることが可能である。例えば、導出鍵は、セキュリティを強化するために、特定の日付または日付範囲に対して一意とすることが可能である。各メッセージは、鍵生成器の負担を非常に増加させることになるが、導出鍵が、受信者およびメッセージの両方に対して一意となるように、それ自身が関連する導出鍵を有するように要求することができる。導出鍵は、電子メールアドレス一種のユーザーIDまたはドメイン名の情報に基づいて生成することができる。明確にするため、現在の説明は、主に、導出鍵がユーザーIDに基づいてマスター鍵から導出される機構に重点を置いている。しかし、これは、単なる例示的なものである。導出鍵を導出するときには、鍵生成器20は、任意の好適な入力を使用することが可能である。マスター鍵および受信者IDから導出鍵を生成するために、鍵生成器20は、任意の好適な一方向性関数を使用することができる。一例として、鍵生成器20は、式1のハッシュ関数のようなハッシュ関数を使用して、受信者AdkeyAに対する導出鍵を計算することができる。dkeyA=HMACmaster-key:recipient_ID1式1において、master-keyは、マスター鍵26であり、recipient_IDは、受信者のアイデンティティに関する情報である。値dKeyAは、導出対称鍵である。関数HMACは、周知の鍵付ハッシュメッセージ認証コード関数である。本願明細書の式1および他の式に使用される記号において、コロンの前にある関数の引数は、暗号関数ここでは、HMAC関数によって使用される鍵情報である。コロンの後の引数は、非鍵情報この場合は受信者IDを表す。式1の関数を使用して、鍵生成器20は、受信者のアイデンティティの鍵付ハッシュ値を計算することができる。ただし、式1の鍵導出関数は、単なる例示的なものである。導出鍵を受信者IDに対して一意のものにしながら、マスター鍵の秘密性を保つために、マスター鍵および受信者IDに機能することができる、任意の好適な一方向性関数を使用することが可能である。個々の導出鍵に固有のあらゆる情報の格納を鍵生成器に要求せずに、送信者および受信者の導出鍵のコピーが一致するように、好適な一方向性関数は、決定論的となる。また、一例としてユーザーXに対する要求が、ユーザーYに対して偶発的または敵対的に導出鍵を生成しないように、好適な一方向性関数は、衝突に抵抗性のあるものとなる。好適な一方向性関数には、ハッシュ関数、鍵付ハッシュ関数、デジタル署名関数などが挙げられる。導出鍵の要求に応えて導出鍵を生成した後に、ステップ42で、鍵生成器20は、要求元に導出鍵を提供することができる。鍵生成器40は、例えば、組織のイントラネット16を通じて、ゲートウェイ22、組織18内の送信者、または暗号解読サーバー24に、導出鍵を送信することができる。イントラネット16は、組織18によって制御されるため、安全であるとみなせる。導出鍵は、ゲートウェイ22、組織18内の送信者、または暗号解読サーバー24によって例えば、タイムスタンプされた導出鍵が期限切れになるまで、ローカルに格納することができる。このように、ローカルキャッシュ内に導出鍵を格納することで、鍵生成器20が処理する導出鍵の要求数を減じることができる。ローカル記憶装置を使用する場合、導出鍵の要求元は、鍵が必要なときに、導出鍵のコピーのためのローカル記憶装置を確認することができる。ローカル記憶装置において現在のバージョンの導出鍵が利用できる場合は、鍵生成器20に対する鍵要求を行う必要はない。メッセージの暗号化および組織18内から組織18の顧客である外部の受信者への送信の際に関連する例示的ステップを図3に示す。ステップ44で、送信者Aのような組織18の送信者は、組織18の顧客である受信者Cのような受信者に安全に送信される、メッセージを作成する。送信者のクライアントソフトウェアがメッセージ内容を作成してもよく、またメッセージの内容を、別の好適なソースから送信者Aが取得してもよい。ステップ46で、送信者Aは、受信者にメッセージを送信する。一例として、送信者Aの電子メールクライアントは、イントラネット16を通じて、受信者に宛てた電子メールメッセージを送信することができる。イントラネット16は安全であるとみなされるので、概してこの時点で、メッセージを暗号化する必要はない。ステップ48で、送信者からの発信メッセージをゲートウェイ22が受信することができる。ゲートウェイは、メッセージ管理ソフトウェア、または暗号化ポリシー、ウイルススキャンポリシー、アーカイブポリシー、などのようなポリシーを実行するために使用される、他の好適なソフトウェアを有することができる。ゲートウェイは、各メッセージをどのように処理するのかを判断するために、これらのポリシー、およびメッセージ内容情報、ソースおよび宛先アドレス情報、ヘッダ情報、などのようなメッセージ属性情報を使用することができる。例えば、ゲートウェイは、特定のメッセージを暗号化する必要があるかどうかを判断するために、各受信者の電子メールアドレスのドメイン名部分を調査することができる。あらゆる好適な暗号化ポリシーは、ゲートウェイ22を使用して実行することが可能である。例えば、ゲートウェイ22は、全ての発信メッセージを暗号化すること、特定の受信者またはリストの受信者すなわち、特定の顧客に送信されるメッセージを暗号化すること、その電子メールアドレスが所定のドメイン名を含むメッセージを暗号化すること、メッセージの状態または組織に関連付けられた日付に基づいて、受信者へのメッセージを暗号化すること、などが可能である。ゲートウェイ22が、そのメッセージを暗号化する必要があると判断した場合、ゲートウェイ22は、鍵生成器20から、暗号解読プロセスのための好適な導出鍵を取得することができる。適切な導出鍵がローカルに利用できる場合、ゲートウェイ22は、ローカルに格納されたバージョンの導出鍵を使用することができる。適切な導出鍵がローカルに利用できない場合、ゲートウェイは、ステップ50で、導出鍵の要求を生成し、イントラネット16を通じて、鍵生成器20に導出鍵の要求を提供する。導出鍵の要求は、受信者のアイデンティティを含む。任意の好適なフォーマットは、導出鍵の要求において、鍵生成器に受信者のアイデンティティ情報を提供するために使用することができる。例えば、受信者のアイデンティティ情報は、受信者ID例、受信者Cの電子メールアドレス、または受信者Cの電子メールアドレスに基づいた情報の形式で提供することができる。ステップ52で、鍵生成器20は、導出鍵の要求の受信および処理を行う。導出鍵は、図2のステップ38、40、および42のプロセスを使用して生成することができる。導出鍵を生成した後に、導出鍵を、イントラネット16を通じて、ゲートウェイ22に提供することができる。ステップ54で、ゲートウェイ22は、鍵生成器20から導出鍵を受信する。ゲートウェイは、次いで、暗号文を生成するために、暗号化エンジン28を使用してメッセージ内容を暗号化することができる。暗号化エンジン28は、AESのような対称鍵暗号化アルゴリズムを使用する対称鍵暗号化エンジンとするか、または他の好適な暗号化アルゴリズムを使用することができる。暗号化エンジン28への入力は、受信者および非暗号化メッセージ内容の導出鍵を含む。暗号化エンジン28の出力は、含む暗号化バージョンのメッセージ暗号文を含む。ステップ56で、ゲートウェイ22は、受信者Cに暗号化バージョンのメッセージを中継することができる。暗号化メッセージは、受信者Cが受信する前に、1つ以上のメールサーバー組織18の内部および外部のメールサーバーを含む1つ以上のメールサーバーを通過する場合がある。暗号化メッセージの受信および解読の際に関連する例示的ステップを図4に示す。ステップ58で、受信者この例では受信者Cは、通信ネットワーク14を通じて、メッセージを受信する。メッセージは、受信者の装置12上で動作している受信者のクライアントソフトウェアによって受信することができる。受信者のクライアントソフトウェアが、ローカルキャッシュ内で利用できる適切な導出鍵のコピーを有する場合、クライアントソフトウェアは、メッセージを解読するために、その導出鍵を使用することができる。導出鍵をローカルに利用できない場合、受信者は、組織18から導出鍵のコピーを取得することができる。特に、ステップ60で、受信者は、導出鍵の要求を生成し、暗号解読サーバー24に導出鍵の要求を提供することができる。導出鍵の要求を作成するために、任意の好適な機構を使用することができる。例えば、送信者Aまたはゲートウェイ22のクライアントは、発信メッセージ内にクリックできるリンク例えばウェブリンクを自動的に含むことが可能である。受信者Cがメッセージを受信するとき、メッセージ内の命令は、受信者Cに、そのリンクをクリックするように促すことができる。リンクをクリックすることで、受信者Cのウェブブラウザまたは他の好適なクライアントソフトウェアに、通信ネットワーク14を通じて、特定のウェブアドレスに特定の情報を送信するように命令することができる。送信される情報は、受信者のアイデンティティ情報を含むこと、および導出鍵の要求としての機能を果たすことが可能である。ウェブアドレスは、暗号解読サーバー24に関連付けることができる。これは、導出鍵の要求を暗号解読サーバー24に提供することが可能な1つの例示的方法である。必要に応じて、任意の好適な機構を使用することができる。ステップ62で、暗号解読サーバー24は、受信者を認証することによって導出キーの要求を処理し、サーバー24と受信者Cの装置との間に安全な通信チャネルを確立することができる。必要に応じて、任意の好適な認証技術を使用することができる。例えば、受信者のクライアントは、ユーザー名およびパスワード情報の形式で、暗号解読サーバーに受信者信用証明書を提供することができる。ユーザー名およびパスワード情報は、例えば、組織18が銀行であれば、銀行アカウント名情報およびPIN情報となりうる。認証プロセス中、暗号解読サーバーは、受信者信用証明書を確認するために、認証サービス30を使用する。受信者信用証明書が、組織に保持されている信用証明情報と一致するおよび導出鍵の要求内の受信者IDと一致する場合、暗号解読サーバー24は、導出鍵を要求している受信者が、その受信者の導出鍵のコピーの取得を許可されていると判断することができる。認証プロセス中に、サーバー24および受信者Cの装置12は、安全な通信チャネル例えば、SSLリンクを確立する。この安全な通信チャネルは、導出鍵の配信に使用することができる。ステップ64で、暗号解読サーバー24が、要求元の受信者この例では受信者Cが導出鍵のコピーの取得を許可されたと判断した後で、暗号解読サーバー24は、導出鍵を要求して鍵生成器20から取得することができる。暗号解読サーバー24によって作成される鍵要求は、イントラネット16を通じて作成し、受信者IDを含むことができる。暗号解読サーバー24は、鍵生成器20と同じ組織であるので、鍵生成器20は、暗号解読サーバーを信頼する。それに応じて、鍵生成器20は、導出鍵を生成するために、暗号解読サーバーからの受信者ID情報、およびステップ38、40、および42図2の導出鍵生成プロセスを使用することが可能である。導出鍵は、イントラネット16を通じて、暗号解読サーバーに提供することができる。ステップ64で、暗号解読サーバー24が、鍵生成器20から受信者Cに対する導出鍵を取得した後に、ステップ66で、暗号解読サーバー24は、通信ネットワーク14を通じて、受信者Cに導出鍵を提供することができる。暗号解読サーバー24は、ステップ62で確立された安全な通信チャネルを使用して例えば、SSLリンクを通じて、受信者Cに安全に導出鍵を提供することができる。ステップ68で、受信者Cは、安全な通信チャネルを通じて、暗号解読サーバー24から導出対称鍵を受信する。受信者は、次いで暗号化メッセージを解読するすなわち、暗号文を解読するために、暗号解読エンジン34を使用することができる。暗号解読エンジン34への入力は、暗号化バージョンのメッセージすなわち、暗号文、および受信者Cの導出鍵である。暗号解読エンジン34の出力は、非暗号化バージョンのメッセージ内容である。暗号解読エンジン24は、暗号化エンジン28によって使用された同じ種類の暗号アルゴリズムAESを使用した対称鍵暗号解読アルゴリズムなどを使用する。この種の対称鍵機構に関しては、受信者がメッセージを解読するために使用する導出鍵は、送信者がゲートウェイ22において暗号化エンジン28を使用してメッセージを暗号化するために使用した導出鍵と同じである。暗号解読エンジン34は、スタンドアロンのソフトウェアパッケージの一部とするか、または既存のクライアントソフトウェアに例えば、電子メールクライアントへのプラグインなどとして組み込むことが可能である。必要に応じて、受信者は、導出鍵のコピーを要求する代わりに、組織18に暗号化メッセージの解読を要求することができる。この種類の機構では、暗号解読サーバーは、暗号解読エンジン34のような暗号解読エンジンを含むことができる。受信者は、暗号解読サーバー24に導出鍵の要求を行うのではなく、暗号解読サーバー24に暗号解読の要求を行うことができる。暗号解読の要求は、受信者のIDを含むことができる。暗号化バージョンのメッセージは、暗号解読の要求とともに、または他の好適な機構を使用して、暗号解読サーバー24に提供することが可能である。受信者の認証の成功に続いて、暗号解読サーバー24は、鍵生成器20から導出鍵を取得し、メッセージの内容を解読するために、ローカルな暗号解読エンジンを使用することができる。解読されたメッセージの内容は、認証プロセス中に、SSLリンクのような安全なリンクを通じて、受信者に提供することができる。大きな組織では、組織の種々の構成要素が互いを信頼しなければならない範囲を制限するために、階層的機構を使用することが有用となりうる。例えば、組織は、北アメリカのユニットおよびヨーロッパのユニットを有することができる。北アメリカのユニットの従業員は、その組織内の1つの鍵生成器に関連付けることが可能である。ヨーロッパのユニットの従業員は、その組織内の別の鍵生成器に関連付けることが可能である。この種類の機構によって、平行および独立したセキュリティ機構を同じ組織内に保持することができるため、セキュリティが強化される。例えば、1つの鍵生成器のマスター鍵に障害が生じた場合であっても、他の鍵生成器によって保護された通信は、その安全性が保持される。階層的セキュリティ機構はまた、組織へのイントラネット16の導入をより容易にすることも可能である。例えば、ある場所において、ローカルなイーサネット登録商標に接続される全てのエンティティは、互いに信頼することができ、別の場所において、ローカルなイーサネット登録商標に接続される全てのエンティティは、互いに信頼することができる。各イーサネット登録商標ネットワークは、その関連する場所に対するローカルなイントラネットを形成することが可能であるが、一例として各ローカルなイントラネットには、それぞれの委譲された鍵生成器が提供されるので、同じレベルの信頼性およびセキュリティとともに、2つの場所をネットワーク化する必要はない。図2に関して説明した導出鍵機構は、各委譲鍵生成器に対するマスター鍵を導出するために使用することができる。スーパーマスター鍵は、これらのマスター鍵を導出するために使用することができる。導出マスター鍵のそれぞれは、組織のより小さな部分に関連付けられるので、それらをサブマスター鍵と称する場合がある。委譲鍵生成器は、組織内、または他の相異なるユニット内例えば、地理的領域、管理レベルまたは他の状態、組織系統、従業員の職務など、によって分割されるユニットの独立したビジネスユニットの制御下に配置することができる。各組織的ユニットがそれ自体の委譲鍵生成器を有すると、その委譲鍵生成器は、関連する顧客に対する導出鍵を生成するために使用することができる。例えば、組織において、北アメリカのユニットは、北アメリカのユニットの顧客に対する鍵を導出するために、北アメリカのユニットの鍵生成器を使用することができる。ヨーロッパのユニットの鍵生成器は、ヨーロッパのユニットの顧客に対する鍵を導出するために使用することが可能である。この種類のシナリオにおける顧客は、必ずしも排他的であるというわけでないが、かなり異なることになるすなわち、顧客は、北アメリカのユニットおよびヨーロッパのユニットの両方の顧客となる場合があり、その場合、顧客は、それぞれの導出鍵を使用して、各ユニットと情報をやり取りする。階層的な鍵生成器のアーキテクチャでは、スーパー鍵生成器は、スーパーマスター鍵マスター鍵と呼ぶ場合もあるを有し、各委譲鍵生成器は、導出されたマスター鍵マスター鍵またはサブマスター鍵と呼ぶこともあるを有する。単一のスーパーマスター鍵を使用することにより、ゲートウェイ22のような単一のゲートウェイは、全ての送信を暗号化するために使用することができる。階層的なアーキテクチャを鍵生成器に対して使用した、例示的システム10の図を図5に示す。スーパー鍵生成器70は、マスター鍵72を有する。スーパー鍵生成器70は、組織18図1によって運営され、組織の種々のユニットに対するサブマスター鍵を導出するために使用することができる。図5では、2つの組織的ユニットユニットEおよびユニットFが示されている。一般に、組織は、任意の適当な数のユニットを有することが可能である。1つの好適な機構によって、組織のユニットは、通信ネットワーク14を介してスーパー鍵生成器70と相互接続されるが、これはイントラネットまたは他の好適なネットワークであってよい。この種の機構によって、スーパー鍵生成器70は、ユニットに導出マスター鍵を電子的に配信することができる。必要に応じて、導出マスター鍵はまた、例えば、ディスクまたは他の媒体で手動で配信することも可能である。組織は、スーパー鍵生成器70を制御して、スーパーマスター鍵72の秘密性を確認する。各ユニットは、それ自体の委譲鍵生成器を有し、それぞれが、スーパーマスター鍵から導出されたそれ自体のサブマスター鍵を有する。図5の例では、ユニットEは、委譲鍵生成器20Eを有する。委譲鍵生成器20Eは、ユニットEの送信者および顧客に対する導出鍵を生成するために、サブマスター鍵26Eを使用する。サブマスター鍵26Eは、システム設定オペレーション中に、スーパー鍵生成器72によってスーパーマスター鍵72から導出されたものである。ユニットFは、委譲鍵生成器20Fを有する。委譲鍵生成器20Fは、導出鍵を生成するために、サブマスター鍵26Fを使用する。サブマスター鍵26Fは、スーパーマスター鍵72から導出されたものである。階層的な鍵生成器機構は、任意の適当な数の層を有することができる。例えば、それぞれが導出されたマスター鍵の更なる層を有する、鍵生成器の更なるサブ層をユニットEのサブユニットに提供することができる。明確にするため、本発明は、組織の単一のスーパー鍵生成器が、組織内の種々のユニットに対する導出サブマスター鍵を生成する、二層の機構に関して説明する。階層的な鍵生成器のアーキテクチャは、種々のシステム構成において使用することができる。例えば、システム10は、図1のゲートウェイ22のような中央ゲートウェイを有することができる。中央ゲートウェイは、全ての発信メッセージに対する情報センターとして機能することができ、メッセージを暗号化するための図1の暗号化エンジン28のような暗号化エンジンを有することができる。中央ゲートウェイ内の暗号化エンジンは、種々の受信者の導出鍵を使用して、メッセージを暗号化することができる。導出鍵は、委譲鍵生成器によって中央ゲートウェイに提供することができる。図5に示される例示的機構では、ゲートウェイを使用しない。むしろ、各送信者は、発信メッセージを暗号化するために、暗号化エンジンを有するクライアントソフトウェアを使用する。標準的なシナリオでは、その組織の特定のユニット内のユーザーは、そのユニットの顧客に、暗号化メッセージを送信するように要求する。例えば、ユニットEの送信者Xが、ユニットEの顧客である受信者Yへの暗号化メッセージの送信を要求する。送信者Xは、委譲鍵生成器20Eから、受信者Yのメッセージを暗号化するための導出鍵を取得する。暗号化メッセージは、通信ネットワーク14を通じて、受信者Yに送信される。受信者Yは、導出鍵の要求を生成する。導出鍵の要求は、組織によって処理され、要求された導出鍵は、メッセージを解読するために、受信者Yに提供される。階層的な鍵生成器のアーキテクチャに基づいて、1つ以上の暗号解読サーバーをシステム10内で使用することができる。1つの好適な機構では、中央暗号解読サーバーは、受信者からの導出鍵の要求を処理するために使用される。各受信者の導出鍵の要求は、受信者を識別する情報を含む。各受信者の導出鍵の要求はまた、どのユニットの鍵生成器が、送信者がメッセージを暗号化する際に使用した、導出鍵を生成するために使用されたのかを識別する情報を含むこともできる。中央暗号解読サーバーは、どの委譲鍵生成器が導出鍵を作成したかについて判断するために、この情報を処理することができる。中央暗号解読サーバーは、次いで組織の適切なユニット内の委譲鍵生成器に鍵要求を送ることができる。必要に応じて、暗号解読サーバーは、各ユニットに提供することが可能である。この種類の機構を図5に示す。ユニットE内の暗号解読サーバー24Eは、委譲鍵生成器20Eから導出鍵を取得するために使用される。委譲鍵生成器20Eからの導出鍵は、ユニットE内の送信者からのメッセージを解読するために、ユニットEの顧客に提供される。ユニットF内の暗号解読サーバー24Fは、委譲鍵生成器20Fから導出鍵を取得するために使用される。委譲鍵生成器20Fからの導出鍵は、ユニットFの送信者からのメッセージを解読するために、ユニットFの顧客によって使用される。送信者と受信者との間の安全なメッセージングをサポートするための、図5のシステム10のような階層的な鍵生成器機構を有するシステムの使用の際に伴われる例示的ステップを図6に示す。ステップ74で、設定オペレーションを行う。ユニットEおよびユニットFが一部である組織は、種々の委譲鍵生成器に対する導出マスター鍵を生成するために、スーパー鍵生成器70を使用する。スーパー鍵生成器70は、式2aを使用して、スーパーマスター鍵72からサブマスター鍵26Eを導出することが可能である。sub-master_key_E=HMACsuper_master_key:unitE2a式2aでは、sub-master_key_Eは、図5のサブマスター鍵26Eの値である。super_master_keyは、スーパー鍵生成器70によって保持される、スーパーマスター鍵72の値である。unitEは、鍵生成器20Eの名前である。図2に関して説明したように、鍵生成器20Eのような委譲鍵生成器に対する導出マスター鍵を生成するために、任意の好適な一方向性の鍵導出関数を使用することができる。式2aの例では、HMAC関数を使用する。サブマスター鍵の導出プロセスは、組織内の全てのユニットに対して繰り返される。例えば、スーパー鍵生成器70は、式2bを使用して、スーパーマスター鍵72から図5のサブマスター鍵26Fを導出することができる。sub-master_key_F=HMACsuper_master_key:unitF2bマスター鍵のsub-master_key_Eおよびsub-master_key_Fは、安全に配信することができ、図5に示されるように、それぞれの委譲鍵生成器20Eおよび20Fによってローカルに格納することができる。スーパー鍵生成器70は、安全なイントラネットを介して、委譲鍵生成器26Eおよび26Fとネットワーク化することが可能である。これによって、鍵は、組織内の信頼できる経路を通じて配信するか、または他の好適な通信ネットワーク14を介して安全に配信することが可能になる。式2aおよび2b、または他の好適な鍵導出関数を使用して、委譲鍵生成器のサブマスター鍵を導出することによって、委譲鍵生成器を設定した後に、メッセージは、ステップ76、78、80、82、84、および86で安全に送信することができる。ステップ76、78、80、82、84、および86は、破線75で示されるように、ステップ74の設定オペレーションとは異なる時間に行うことができる。ステップ76で、ユニットE内の送信者Xのような送信者は、ユニットEの顧客である受信者Yのような所望の受信者に対する導出鍵を取得する。送信者のクライアントソフトウェアは、ユニットE内のイントラネット16を通じて、委譲鍵生成器に対する導出鍵の要求を行うことによって、メッセージの暗号化に使用する適切な導出鍵20Eを取得することができる。送信者によって作成される鍵要求は、メッセージの対象となる受信者に関する情報を含む。この例では、対象となる受信者は受信者Yであるので、鍵要求は、受信者Yに対する受信者IDのような受信者Yを識別する情報例、recipient_Y_IDを含むことができる。委譲鍵生成器は、次いで、式3を使用するか、または図2に関して説明したように、他の好適な鍵導出関数を使用して、ローカルに導出した鍵を計算することができる。key_Y=HMACsub-master_key_E:recipient_Y_ID3式3では、sub-master_key_Eは、ユニットEのユーザーおよびそれらの関連する顧客に対する導出鍵の生成において、委譲鍵生成器20Eによって使用される。recipient_Y_IDは、メッセージの対象となる受信者を識別する情報である。Key_Yは、導出鍵である。Key_Yを計算した後に、委譲鍵生成器20Eは、要求元の送信者にkey_Yを提供する。要求元の送信者におけるクライアントソフトウェアは、受信者に対するメッセージを暗号化するためにKey_Yを使用する、図1の暗号化エンジン28のような暗号化エンジンを含む。クライアントソフトウェアは、次いで受信者に暗号化メッセージを送信する。暗号化メッセージは、メッセージ暗号文の暗号化された内容を含み、また受信者がメッセージを解読するための導出鍵Key_Yのコピーを要求したときに、受信者が交信するための適切なユニットすなわち、この例では、委譲鍵生成器20Eおよび暗号解読サーバー24Eを含むユニットEを識別する非暗号化情報を含む。委譲鍵生成器およびそのユニットを識別する情報には、任意の好適な機構を使用して、メッセージを提供することが可能である。例えば、送信者Xにおけるクライアントソフトウェアは、recipient_Y_IDを含む発信メッセージ内にウェブリンクを自動的に組み込み、また委譲鍵生成器20Eおよび/または暗号解読サーバー24Eに対する一意の名前を自動的に組み込む。ウェブリンクはまた、受信者が鍵要求によって暗号解読サーバー24Eと交信する際に使用することができる、暗号解読サーバー24Eに関連するウェブアドレス情報例、ドメイン名を含むことも可能である。受信者は、このウェブリンクをクリックして、受信者のウェブブラウザを使用して、暗号解読サーバー24Eへの鍵要求を開始することができる。ステップ78で、受信者Yが、ネットワーク14を通じて、送信者Xから暗号化メッセージを受信した後に、受信者Yは、導出鍵の要求を生成して、暗号解読サーバー24Eにこの要求を提供する。鍵要求は、受信者を識別する情報例、recipient_Y_IDを含む。鍵要求はまた、暗号解読サーバーが、適切な委譲マスター鍵サーバーに導出鍵の要求を送るのを助力する情報も含むことが可能である。例えば、鍵要求は、受信者にメッセージとともに送信された、適切な委譲マスター鍵サーバーの名前を含むことが可能である。中央暗号解読サーバーが存在する環境では、適切な委譲鍵生成器の名前に関する情報は、要求された導出鍵のコピーに対してどの委譲鍵生成器が交信するのかを判断するために使用することが可能である。委譲鍵生成器と暗号解読サーバーとの間に一対一の対応のある、図5に示される種類の機構では、受信者は、暗号解読サーバーのうちの特定の1つに導出鍵を送信するために、組み込まれたウェブリンク内の情報を使用することが可能である。これは、その要求に関連する委譲鍵生成器を暗黙に定義する役目をする。ステップ80で、暗号解読サーバー20Eは、受信者Yを認証して、暗号解読サーバー20Eと受信者Yとの間に安全なチャネル例、SSLリンクを確立する。Key_Yのコピーを取得するために受信者Yの承認が確認されると、暗号解読サーバー20Eは、key_Yに対する鍵要求を生成するために委譲鍵生成器20Eを識別する、要求内の情報を使用することが可能である。鍵要求は、Key_Yを生成するために委譲鍵生成器20Eが式3を使用できるように、recipient_Y_IDを含む。ステップ82で、委譲鍵生成器20Eは、暗号解読サーバー24Eから鍵要求を受信する。委譲鍵生成器20Eおよび暗号解読サーバー24Eは、同じイントラネット16を通じて、同じユニット内で動作するので、暗号解読サーバー24Eは、委譲鍵生成器20Eによって信頼される。したがって、委譲鍵生成器20Eは、受信者Yに対する導出鍵を生成する。特に、委譲鍵生成器20Eは、Key_Yを導出するために、受信者のアイデンティティrecipient_Y_IDおよび式3のサブマスター鍵26Eに関する要求からの情報を使用することが可能である。委譲鍵生成器20Eは、次いで、ユニットE内のイントラネット16を通じて、暗号解読サーバー24Eに安全にKey_Yを提供することが可能である。ステップ84で、暗号解読サーバーは、暗号解読サーバー24Eと受信者Yとの間の安全な通信チャネルを通じて、受信者YにKey_Yを提供する。ステップ86で、受信者Yは、暗号文を解読して、非暗号化バージョンのメッセージ内容にアクセスするために、図1の暗号解読エンジンのような暗号解読エンジン34およびKey_Yを使用する。必要に応じて、各ユニットは、そのユニット内の送信者からの発信メッセージを暗号化するためのゲートウェイを有することができる。各ユニット内の委譲鍵生成器は、暗号化に必要な導出鍵を生成することができる。複数のユニット内の送信者からの発信メッセージを暗号化するために、グローバルゲートウェイが使用される機構では、スーパー鍵生成器70は、式4aおよび4bを使用して、導出鍵を生成することができる。Unit_j_key=HMACsuper_master_key:unit_j4akeyj,k=HMACUnit_j_key:recipient_k_ID4b式4aおよび4bでは、サブマスター鍵Unit_j_keyを生成するために、スーパー鍵生成器を使用するが、これは次いで、メッセージの対象となる受信者この例では受信者kと、適切なユニットおよび鍵生成器この例ではユニットjおよび鍵生成器jとの両方に固有である、導出鍵Keyj,kを生成するために、受信者kに対する受信者アイデンティティrecipient_k_IDと組み合わせられる。必要に応じて、階層的な機構は、サブ分割受信者アイデンティティに使用することが可能である。例えば、そのIDがrecipient_k_IDであり、master_keyのマスター鍵を有する組織の顧客である受信者kに関連する、recipient_k_ID_1、recipient_k_ID_2などのような、複数のサブアイデンティティが存在する場合がある。recipient_k_IDの各サブ受信者に対する導出鍵は、式5、6a、および6bのような式を使用して計算することが可能である。Key_k=HMACmaster_key:recipient_k_ID5Key_k_1=HMACKey_k:recipient_k_ID_16aKey_k_2=HMACKey_k:recipient_k_ID_26b式5は、マスター鍵および受信者kのアイデンティティから、導出鍵Key_kを計算するために使用することができる。式6aは、受信者kに対する鍵およびrecipient_k_ID_1のアイデンティティに基づいて、受信者のサブアイデンティティrecipient_k_ID_1に対する導出鍵を計算するために使用することができる。式6bは、受信者のサブアイデンティティrecipient_k_ID_2に対する導出鍵を計算するために使用することができる。recipient_k_IDに関連する他の受信者サブアイデンティティに対する導出鍵も、同様に計算することが可能である。HMAC関数は、式5、6a、および6bの鍵を導出するために使用される。図2に関して説明したように、必要に応じて、他の好適な鍵導出関数を使用することが可能である。組織は、受信者のアイデンティティrecipient_k_IDを認識してさえいればよい。しかし、組織の外部では、各サブ受信者に対する導出鍵は、recipient_k_IDすなわちKey_kに対する導出鍵を使用して計算することができる。これによって、Key_kは、組織外の受信者kによって管理される一群のユーザーに対するマスター鍵として使用できるようになる。受信者の階層は、好適な数の層を有することができる。式5、6a、および6bの例は、二層スキームを伴う。さらに、システム10は、必要に応じて、受信者の階層および鍵生成器の階層を有することが可能である。本発明の別の側面は、認証された導出鍵に関する。特に、ゲートウェイのない環境において、導出鍵を認証できることが望ましい場合がある。ゲートウェイのないシステムでは、送信者は、発信メッセージを暗号化できるようになる前に、導出鍵を取得しなければならない。送信者が、偶発的または悪意のある送信エラーによる誤った導出鍵を取得する場合、または鍵生成器になりすました攻撃者が、送信者に偽の鍵を提供する場合には、問題が生じる可能性がある。認証された導出鍵は、要求した鍵を適切に取得した送信者および受信者を保証するために使用することができる。鍵の認証に使用することが可能な1つの好適な技術は、デジタル署名を使用するものである。この状況では、HMACベースのバージョンの式1は、式1’となる。dkeyA=signprivate-key:recipient_ID1’式1’では、式1の鍵付ハッシュ関数は、決定論的なデジタル署名関数signに置き換えられている。さらに、式1のマスター鍵は、私的な鍵秘密鍵に置き換えられている。式1’は、システム10内の式1と同じ導出鍵生成関数の役目を果たすが、それによって、エンティティは、それらが取得する導出鍵を認証することが可能になる。秘密鍵に対応する公的な鍵公開鍵と呼ぶは、公的にアクセス可能となる。公開鍵は、例えば、通信ネットワーク14を通じて、公開鍵および/または組織18にアクセス可能な組織の内部または外部の好適なサーバー上に公開鍵を配置することによって、発行することができる。公開鍵はまた、例えば、イントラネット16に接続された内部サーバー上に公開鍵を配置することによって組織内のエンティティだけにアクセス可能とすることもできる。この鍵認証プロセスを使用するシステムでは、導出鍵dkeyAは、式7の認証オペレーションを使用して確認することができる。valid=verifypublic-key:recipient_ID,dKeyA7式7では、関数verifyは、公開鍵、およびrecipient_IDおよびdKeyAの値に基づいて、パラメータvalidを計算するために使用される。dKeyAが正当な導出鍵でない場合、パラメータvalidは誤ったものとなり、送信者または他のエンティティは、その導出鍵を使用しないことがわかる。パラメータvalidが真である場合、導出鍵は正当なものである。signのようなデジタル署名関数の非偽造性により、秘密鍵に関する知識がなければ、導出鍵の計算は実行不可能である。関数signは、決定論的または確定的に作用するために適切に、デランダマイズされるであり、送信者および受信者の両方が、式1’を使用した場合に、同じ導出鍵を計算するようにする。上述のシステムによって、組織内の送信者は、組織の顧客である受信者に暗号化メッセージを送信することができる。受信者は、暗号化メッセージの解読に使用する適切な導出対称鍵のコピーを取得するために、組織と交信することができる。受信者送信者としての役割を果たすはまた、組織に対してメッセージを暗号化するために、導出対象鍵を使用することもできる例えば、受信者は、組織内の送信者に暗号化した応答メッセージを返信することができる。組織の外部の者でその組織の顧客ではない送信者は、組織内の受信者またはその組織の顧客である受信者に暗号化メッセージを送信したい場合がある。この送信者は組織に属していないので、送信者は、組織がその顧客を認証できる同じ方法でその送信者を認証できるようにする、前もって制定された関係を持たない。非顧客である送信者が、組織の受信者またはその組織の顧客である受信者に安全なメッセージを送信できるように使用することが可能な、例示的システムを図7に示す。図7のシステム10では、鍵生成器20は、導出鍵を生成するために使用されるマスター鍵26を有する。組織18の顧客である受信者Qに暗号化メッセージの送信を望む送信者Pは、メッセージを暗号化するために、鍵生成器20から導出鍵を使用することができる。メッセージは、送信者の装置12において、またはゲートウェイ22によって暗号化することができる。受信者Qが暗号化メッセージを受信するとき、受信者Qは、暗号解読サーバー24から導出鍵のコピーを要求することができる。暗号解読サーバー24は、受信者Qを認証して、鍵生成器20から導出鍵のコピーを取得することができる。暗号解読サーバー24は、次いで安全なチャネルを通じて、受信者Qに導出鍵を提供することができる。受信者Qは、送信者Pからの暗号化メッセージを解読するために、導出鍵を使用することができる。受信者Qはまた、送信者Pに対する新しいメッセージ例えば、送信者Pの元のメッセージに応答する応答メッセージを暗号化するために、導出鍵を使用することもできる。送信者Pは、導出鍵のコピーを有するまたはそれを取得することができるので、送信者Pは、受信者Qの暗号化した応答を解読することができる。受信者Qとは異なり、送信者Sは、組織18の顧客でない。送信者Sと組織18との間には先在する関係がないので、組織18は、送信者Sを認証する際に使用する信用証明書を持たない。したがって、送信者Sは、受信者Qが暗号解読サーバー24に対して認証できるのと同じ方法で導出鍵を取得するために、暗号解読サーバー24に対して認証することができない。送信者Sは組織18の一員ではないので、送信者Sに受信者Qの導出鍵を委任することは望ましくない。本発明によれば、組織18には、ポリシーサーバー88が提供される。ポリシーサーバー88は、図7の例では独立したサーバーとして示されているが、必要に応じて、ポリシーサーバー88は、ゲートウェイ22の一部として、暗号解読サーバー24の一部として、鍵生成器20の一部として、または組織18に属する他のエンティティの一部として、使用することが可能である。ポリシーサーバーは、送信者Sのような非顧客送信者に対する導出鍵の生成を処理する。送信者Sは、その組織の顧客であるか、または組織18の送信者への安全なメッセージの送信を望む場合に、当該の非顧客メッセージ鍵を取得することができる。図7の例示的受信者Rは、組織18内に位置するが、受信者Rはまた、組織の顧客である受信者Qのような受信者である場合がある。非顧客の送信者Sが、メッセージを暗号化して、受信者Rのような受信者に安全なメッセージを送信する際に伴われる例示的ステップを図8に示す。ステップ90で、送信者Sは、メッセージを受信者Rに送信するための鍵を要求するために、ポリシーサーバー88と交信する。送信者Sは、例えば、ポリシーサーバー88に関連するウェブページにアクセスするために、送信者Sの装置上で動作しているウェブブラウザを使用することが可能である。ステップ92で、送信者のウェブブラウザは、ポリシーサーバーを認証する。標準的なウェブブラウザは、例えば、ポリシーサーバーのウェブページに関連する証明書を確認することによってこの種の認証を行うために、公開鍵インフラPKI技術を使用するための組み込み機能を有する。ポリシーサーバーを認証するプロセス中に、ポリシーサーバー88と送信者Sとの間に安全な通信チャネル例、SSLリンクが確立される。送信者Sからの鍵要求は、対象となる受信者のアイデンティティrecipient_R_IDに関する情報を含む。ステップ94で、ポリシーサーバー88は、鍵生成器20から送信者Sのための導出対称鍵Der_Keyを要求して取得する。ポリシーサーバー88はまた、乱数Nを生成する。数字Nは真ランダムとする必要はないが、当該の数字のそれぞれは、各受信者に対して一度だけ使用されることが好ましい。例えば、当該の手法は、クロックまたはカウンタを保持するために、それぞれ鍵生成器を必要とするが、Nは、タイムスタンプまたはカウンタに基づくことが可能である。ポリシーサーバー88によって作成される鍵要求は、受信者のアイデンティティに関する情報すなわち、送信者Sによって提供されたrecipient_R_IDの値を含む。鍵生成器20は、式8を使用して、導出鍵Der_Keyを計算することができる。Der_Key=HMACmaster-key:recipient_R_ID8式8では、マスター鍵は、鍵生成器20のマスター鍵であり、recipient_R_IDは、受信者Rに対する固有の識別子である。式8のHMAC関数および、本願明細書における他の鍵導出式は、単なる例示的なものである。任意の好適なハッシュ関数または他の一方向性関数は、図2に関して説明したように、Der_Keyを導出するために使用することが可能である。ステップ96で、ポリシーサーバー88は、非顧客メッセージ鍵Key-Nの値を計算するために、導出鍵Der_Keyおよび乱数Nを使用する。ポリシーサーバー88は、図2に関して説明したように、任意の好適な鍵導出関数を使用することが可能である。例えば、ポリシーサーバー88は、式9を使用して、非顧客メッセージ鍵Key-Nを生成することができる。Key-N=HMACDer_Key:N9ステップ98で、ポリシーサーバー88は、安全なチャネルを通じて、送信者Sに非顧客の対称メッセージ鍵Key-Nを提供する。ステップ100で、送信者Sは、受信者Rに対するメッセージを暗号化するために、非顧客メッセージ鍵Key-Nを使用する。送信者Sは、暗号文を生成するために、送信者Sの装置上の暗号化エンジンを使用して、そのメッセージを暗号化することができる。ステップ102で、送信者Sは、組織18の受信者Rに暗号化メッセージを送信する。送信者は、ステップ100で作成した暗号文および暗号化メッセージの一部としてNの値の両方を送信するか、または暗号文および関連する送信におけるNを提供することができる。送信者Sから受信者Rに送信されるNの値は、暗号化されていない。送信者Sからのメッセージを解読する際に関連する例示的ステップを図9に示す。ステップ104で、受信者Rは、非暗号化値Nおよび暗号文を含む、暗号化メッセージを受信する。ステップ106で、受信者Rは、ポリシーサーバーから導出鍵Der_Keyのコピーを要求するか、または、可能な場合は、単純にそれを受信者のローカルキャッシュから取り出す。鍵要求は、鍵生成器がどの鍵を生成すべきかがわかるように、受信者Rのアイデンティティrecipient_R_IDを含む。ステップ106中に、受信者は、ポリシーサーバーに対して認証を行う。認証中に、受信者Rとポリシーサーバー88との間に、安全な通信チャネル例、SSLリンクが確立される。ポリシーサーバー88および受信者がどちらも組織内にある場合、受信者を認証するプロセスは暗黙的なものとなりうる例えば、ポリシーサーバー88は、鍵要求が、その組織のイントラネットを通じて、ポリシーサーバーと交信している組織のユーザーからのものであることを確認するだけでよい。必要に応じて、例えば、ポリシーサーバーによって受信者Rの信用証明書の認証を伴うより大規模な認証技術を使用することが可能である。この種類の認証手法は、例えば、受信者が、組織18のユーザーではなく、受信者Qのような組織18の顧客である場合に使用することが可能である。必要に応じて、ポリシーサーバーはまた、受信者が、信頼できるソースから要求鍵を取得していることを確認するために、例えばPKI手法を用いることによって受信者によって認証することも可能である。ステップ108で、ポリシーサーバーは、鍵生成器20から導出鍵Der_Keyを要求するために、受信者の鍵要求から受信者IDrecipient_R_IDの情報を使用する。ステップ110で、鍵生成器20は、ポリシーサーバーに対するDer_Keyを生成するために、式8または他の好適な関数を使用する。ステップ112で、ポリシーサーバー88は、安全なチャネルを通じて、受信者に導出鍵Der_Keyを提供する。ステップ114で、受信者は、例えば、式9または他の適切な一方向性関数を使用して非顧客メッセージ鍵Key-Nの値を計算するために、送信者Sから受信したNの値およびポリシーサーバー88からの導出鍵Der_Keyを使用する。ポリシーサーバーが送信者に対するKey-Nを計算するときに使用する式は、受信者がKey-Nを計算するときに使用する式と一致しなければならない。ステップ116で、受信者は、暗号文を解読してそのメッセージの内容にアクセスするために、非顧客メッセージ鍵Key-Nを使用する。上記の説明は、単に本発明の原理を例証したにすぎず、当業者は、本発明の範囲および精神から逸脱することなく、様々な変更を行うことができる。"