(57)【要約】安全な電子メッセージングシステムは、鍵サーバ（２４０）の支援による、登録されたユーザ間の通信を許す。システムは鍵サーバ（２４０）に鍵検索情報を提出するよう受け手（２２０）に要求し、復号化鍵情報を得る。復号化鍵情報は送り手（２１０）により暗号化されたメッセージを読むのに使用される復号化鍵を受け手（２２０）が形成するのに必要である。復号化鍵情報は復号化鍵の暗号化バージョン、またはその一部、とりわけ復号化鍵の非暗号化バージョンの一部とすることができる。典型的に、鍵検索情報は送り手（２１０）により受け手（２２０）へ送られるか、送り手（２１０）により送られる情報に基づいて、受け手（２２０）により発生される。
2005517348.tif 000002
【特許請求の範囲】
【請求項１】
鍵サーバの支援による、送り手および受け手間のメッセージＭの安全な通信方法であって、前記方法は、
メッセージまたは暗号化メッセージが鍵サーバに送られることなく、
送り手がメッセージＭを対称鍵Ｋｓにより暗号化して暗号化メッセージを形成するステップと、
受け手の公開暗号化鍵Ｋｅを使用して、送り手が対称鍵Ｋｓから得られた第１の情報を暗号化するステップと、
暗号化メッセージを復号するのに適切な復号化鍵を形成するために受け手が必要とする復号化鍵情報を鍵サーバが格納するステップと、
復号化鍵情報を索引する鍵検索情報Ｋｒを送り手が受信するステップと、
少なくとも暗号化メッセージおよび鍵検索情報Ｋｒを送り手が受け手に送るステップと、
受け手が鍵検索情報Ｋｒを鍵サーバに送りそれに応答して復号化鍵情報を受信するステップと、
受け手が少なくとも復号化鍵情報および受け手の秘密復号化鍵Ｋｄから対称鍵Ｋｓを形成するステップと、
受け手が対称鍵Ｋｓにより暗号化メッセージを復号するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法であって、
第１の情報は対称鍵Ｋｓであり、
送り手は受け手の公開暗号化鍵Ｋｅにより対称鍵Ｋｓを暗号化して暗号化対称鍵Ｋｓｅを形成し、
暗号化メッセージを復号する前に、受け手は受け手の秘密復号化鍵Ｋｄにより暗号化対称鍵Ｋｓｅを復号して対称鍵Ｋｓを形成する方法。
【請求項３】
請求項２に記載の方法であって、
送り手は暗号化対称鍵Ｋｓｅを、それぞれ、第１および第２の分割鍵フラグメントＫｓｅ１およびＫｓｅ２に分割し、
送り手は第２の分割鍵フラグメントＫｓｅ２を鍵サーバに送り、
鍵サーバは第２の分割鍵フラグメントＫｓｅ２を復号化鍵情報として格納し、
送り手は、暗号化メッセージおよび鍵検索情報Ｋｒの他に、第１の分割鍵フラグメントＫｓｅ１を受け手に送り、
鍵サーバへの鍵検索情報Ｋｒの送出に応答して、受け手は第２の分割鍵フラグメントＫｓｅ２を受信し、
受け手は、それぞれ、第１および第２の分割鍵フラグメントＫｓｅ１およびＫｓｅ２から暗号化対称鍵Ｋｓｅを形成する方法。
【請求項４】
請求項２に記載の方法であって、
送り手は暗号化対称鍵Ｋｓｅを鍵サーバに送り、
鍵サーバは暗号化対称鍵Ｋｓｅを復号化鍵情報として格納し、
鍵サーバへの鍵検索情報Ｋｒの送出に応答して、受け手は暗号化対称鍵Ｋｓｅを受信する方法。
【請求項５】
請求項２に記載の方法であって、鍵サーバは鍵検索情報Ｋｒを発生し送り手は対称鍵Ｋｓを発生する方法。
【請求項６】
請求項１に記載の方法であって、
鍵サーバは対称鍵Ｋｓを、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２に分割して第２の分割鍵フラグメントＫｓ２を復号化鍵情報として格納し、
送り手は、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を得、
第１の分割鍵フラグメントＫｓ１は第１の情報であって、受け手の公開暗号化鍵Ｋｅを使用して送り手により暗号化されて暗号化された第１の分割鍵フラグメントＫｓｅ１を形成し、
送り手は、暗号化メッセージおよび検索情報Ｋｒと共に、暗号化された第１の分割鍵フラグメントＫｓｅ１を受け手に送り、
受け手は受け手の秘密復号化鍵Ｋｄにより暗号化された第１の分割鍵フラグメントＫｓｅ１を復号して第１の分割鍵フラグメントＫｓ１を形成し、
鍵サーバへの鍵検索情報Ｋｒの送出に応答して、受け手は第２の分割鍵フラグメントＫｓ２を受信し、
暗号化メッセージを復号する前に、受け手はそれぞれ第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２から対称鍵Ｋｓを形成する方法。
【請求項７】
請求項６に記載の方法であって、
鍵サーバは、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を送り手に送って、送り手がＫｓ１およびＫｓ２を得るようにし、
送り手は、メッセージＭを暗号化する前に、鍵サーバから受信したＫｓ１およびＫｓ２を結合して対称鍵Ｋｓを形成する方法。
【請求項８】
請求項６に記載の方法であって、
鍵サーバは、送り手がメッセージＭを暗号化する前に、対称鍵Ｋｓを送り手に送り、
送り手は対称鍵Ｋｓを、それぞれ、前記第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２へ分割する方法。
【請求項９】
請求項６に記載の方法であって、鍵サーバは鍵検索情報Ｋｒを発生し対称鍵Ｋｓも発生する方法。
【請求項１０】
鍵サーバの支援による、送り手および受け手間のメッセージＭの安全な通信方法であって、前記方法は、
送り手が対称鍵Ｋｓを得てメッセージＭを前記対称鍵Ｋｓにより暗号化して暗号化メッセージＭｅを形成するステップと、
送り手が対称鍵Ｋｓを含む第１の情報を受け手に関連付けられた公開暗号化鍵Ｋｅにより暗号化して暗号化対称鍵Ｋｓｅを形成するステップと、
送り手が前記暗号化対称鍵Ｋｓｅから、それぞれ、第１および第２の分割鍵フラグメントＫｓｅ１およびＫｓｅ２を形成するステップと、
送り手が第２の分割鍵フラグメントＫｓｅ２を鍵サーバに送るステップと、
暗号化メッセージを復号するのに適切な復号化鍵を形成するために受け手が必要とする復号化鍵情報を鍵サーバが格納するステップであって、復号化鍵情報は第２の分割鍵フラグメントＫｓｅ２から形成されるステップと、
復号化鍵情報を索引する鍵検索情報Ｋｒを鍵サーバが送り手に送信するステップと、
送り手が暗号化メッセージＭｅ、第１の分割鍵フラグメントＫｓｅ１および鍵検索情報Ｋｒを受け手に送信するステップと、
受け手が鍵検索情報Ｋｒを鍵サーバへ送りそれに応答して前記復号化鍵情報を受信するステップと、
受け手が第１および第２の分割鍵フラグメントＫｓｅ１およびＫｓｅ２から暗号化対称鍵Ｋｓｅを形成するステップであって、Ｋｓｅ２は復号化鍵情報から引き出されるステップと、
受け手が受け手の秘密復号化鍵Ｋｄにより暗号化対称鍵Ｋｓｅを復号して対称鍵Ｋｓを形成するステップと、
受け手が対称鍵Ｋｓにより暗号化メッセージＭｅを復号してオリジナルメッセージＭを読み取るステップと、
を含む方法。
【請求項１１】
請求項１０に記載の方法であって、前記対称鍵Ｋｓによりメッセージを暗号化する前に署名データおよびタイムスタンプデータの少なくとも一つを付加する付加ステップを含む方法。
【請求項１２】
請求項１０に記載の方法であって、復号化鍵情報は第２の分割鍵フラグメントＫｓｅ２を含む方法。
【請求項１３】
請求項１０に記載の方法であって、送り手は対称鍵Ｋｓを発生する方法。
【請求項１４】
鍵サーバの支援による、送り手および受け手間のメッセージＭの安全な通信方法であって、前記方法は、
送り手が対称鍵Ｋｓを得てメッセージＭを前記対称鍵Ｋｓにより暗号化して暗号化メッセージＭｅを形成するステップと、
送り手が対称鍵Ｋｓを含む第１の情報を受け手に関連付けられた公開暗号化鍵Ｋｅにより暗号化して暗号化対称鍵Ｋｓｅを形成するステップと、
送り手が暗号化対称鍵Ｋｓｅを鍵サーバに送るステップと、
暗号化メッセージを復号するのに適切な復号化鍵を形成するために受け手が必要とする復号化鍵情報を鍵サーバが格納するステップであって、復号化鍵情報は暗号化対称鍵Ｋｓｅから形成されるステップと、
復号化鍵情報を索引する鍵検索情報Ｋｒを鍵サーバが送り手に送信するステップと、
送り手が暗号化メッセージおよび鍵検索情報Ｋｒを受け手に送信するステップと、
受け手が鍵検索情報Ｋｒを鍵サーバへ送りそれに応答して前記復号化鍵情報を受信するステップと、
受け手が前記復号化鍵情報から暗号化対称鍵Ｋｓｅを得るステップと、
受け手が受け手の秘密復号化鍵Ｋｄにより暗号化対称鍵Ｋｓｅを復号して対称鍵Ｋｓを形成するステップと、
受け手が対称鍵Ｋｓにより暗号化メッセージＭｅを復号してオリジナルメッセージＭを読み取るステップと、
を含む方法。
【請求項１５】
請求項１４に記載の方法であって、前記対称鍵Ｋｓによりメッセージを暗号化する前に署名データおよびタイムスタンプデータの少なくとも一つを付加する付加ステップを含む方法。
【請求項１６】
請求項１４に記載の方法であって、復号化鍵情報は暗号化対称鍵Ｋｓｅを含む方法。
【請求項１７】
請求項１４に記載の方法であって、鍵サーバは対称鍵Ｋｓを発生する方法。
【請求項１８】
鍵サーバの支援による、送り手および受け手間のメッセージＭの安全な通信方法であって、前記方法は、
鍵サーバが対称鍵Ｋｓに対応する、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を得るステップと、
暗号化メッセージを復号するのに適切な復号化鍵を形成するために受け手が必要とする復号化鍵情報を鍵サーバが格納するステップであって、復号化鍵情報は第２の分割鍵フラグメントＫｓ２から形成されるステップと、
鍵サーバが受け手に関連付けられた公開暗号化鍵Ｋｅ、Ｋｓを形成するのに十分な対称鍵情報、および復号化鍵情報を索引する鍵検索情報Ｋｒを送り手へ送信するステップと、
送り手がメッセージＭをＫｓにより暗号化して暗号化メッセージＭｅを形成するステップであって、送り手はまた第１の分割鍵フラグメントＫｓ１を含む第１の情報を受け手の公開暗号化鍵Ｋｅにより暗号化して暗号化された第１の分割鍵フラグメントＫｓｅ１を形成するステップと、
送り手が暗号化メッセージＭｅ、鍵検索情報Ｋｒ、および暗号化された第１の分割鍵フラグメントＫｓｅ１を受け手に送信するステップと、
受け手が鍵検索情報Ｋｒを鍵サーバへ送信しそれに応答して前記復号化鍵情報を受信するステップと、
受け手が受け手の秘密復号化鍵Ｋｄにより暗号化された第１の分割鍵フラグメントＫｓｅ１を復号して第１の分割鍵フラグメントＫｓ１を形成するステップと、
受け手が、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２からＫｓを形成するステップであって、Ｋｓ２は復号化鍵情報から得られるステップと、
受け手が対称鍵Ｋｓにより暗号化メッセージＭｅを復号してオリジナルメッセージＭを読み取るステップと、
を含む方法。
【請求項１９】
請求項１８に記載の方法であって、Ｋｓによりメッセージを暗号化する前に署名データおよびタイムスタンプデータの少なくとも一つを付加する付加ステップを含む方法。
【請求項２０】
請求項１８に記載の方法であって、復号化鍵情報は第２の分割鍵フラグメントＫｓ２を含む方法。
【請求項２１】
請求項１８に記載の方法であって、
復号化鍵情報は第２の分割鍵フラグメントＫｓ２を受け手の公開暗号化鍵Ｋｅにより暗号化して形成された暗号化第２分割鍵フラグメントＫｓｅ２を含み、
受け手はＫｓｅ２を受け手の秘密復号化鍵Ｋｄにより復号してＫｓ２を形成する方法。
【請求項２２】
請求項１８に記載の方法であって、対称鍵情報は対称鍵Ｋｓを含み、送り手は鍵サーバから受信した対称鍵Ｋｓから第１の分割鍵フラグメントＫｓ１を形成する方法。
【請求項２３】
請求項１８に記載の方法であって、対称鍵情報は、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を含む方法。
【請求項２４】
請求項１８に記載の方法であって、
対称鍵情報は、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を含み、
復号化鍵情報は第２の分割鍵フラグメントＫｓ２を含む方法。
【請求項２５】
第１のエンティティおよび第２のエンティティ間のメッセージＭの安全な伝送を促進する安全な通信システムにおける鍵サーバ操作方法であって、前記方法は、メッセージまたはその暗号化バージョンを受信することなく、
第１の交換シーケンス中に、
第１のエンティティにより指定された第２のエンティティに対応する公開暗号化鍵Ｋｅを提供する要求を第１のエンティティから受信するステップと、
前記公開暗号化鍵Ｋｅを第１のエンティティに送信するステップと、
メッセージＭの暗号化バージョンを復号するのに適切な復号化鍵を形成するために第２のエンティティが必要とする復号化鍵情報を格納するステップと、
前記復号化鍵情報を索引する鍵検索情報Ｋｒを第１のエンティティに送信するステップとを含み、かつ、
第２の交換シーケンス中に、
鍵検索情報Ｋｒを第２のエンティティから受信するステップと、
前記復号化鍵情報を第２のエンティティに送信するステップとを含む方法。
【請求項２６】
請求項２５に記載の方法であって、復号化鍵情報を格納するステップの前に、第１のエンティティから復号化鍵情報を受信するステップを含む方法。
【請求項２７】
請求項２６に記載の方法であって、復号化鍵情報は前記公開暗号化鍵Ｋｅにより暗号化された対称鍵の分割鍵フラグメントを含む方法。
【請求項２８】
請求項２６に記載の方法であって、復号化鍵情報は前記公開暗号化鍵Ｋｅにより暗号化された対称鍵を含む方法。
【請求項２９】
請求項２５に記載の方法であって、さらに、第１の交換シーケンス中に、
対称鍵Ｋｅに関連付けられた、それぞれ、第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を提供するステップと、
公開暗号化鍵Ｋｅおよび鍵検索情報Ｋｒの他に前記第１および第２の分割鍵フラグメントＫｓ１およびＫｓ２を第１のエンティティに送信するステップと、
を含む方法。
【請求項３０】
請求項２９に記載の方法であって、復号化鍵情報は第２の分割鍵フラグメントＫｓ２を含む方法。
【請求項３１】
請求項２５に記載の方法であって、さらに、第１の交換シーケンス中に、
第２のエンティティが安全な通信システムの登録されたユーザであるかどうかを鍵サーバがチェックするステップと、
第２のエンティティが登録されたユーザではなければ、
鍵サーバが第２のエンティティに対する暗号化鍵および復号化鍵を発生するステップと、
鍵サーバが、第２のエンティティは登録されたユーザではないという通知と共に、暗号化鍵を第１のエンティティに送るステップと、を含む方法。
【請求項３２】
請求項３１に記載の方法であって、さらに、第２の交換シーケンス中に、
第２のエンティティが登録されたユーザではなければ、
第２のエンティティをレジスタに招待し、
第２のエンティティに復号化鍵を送るステップを含む方法。
【請求項３３】
送り手および受け手間のメッセージＭの安全な伝送を促進するように構成された安全な通信システムにおける鍵サーバコンピュータであって、前記鍵サーバコンピュータは、メッセージまたはその暗号化バージョンを受信することなく、
第１の交換シーケンス中に、
第１のエンティティにより指定された第２のエンティティに対応する公開暗号化鍵Ｋｅを提供する要求を第１のエンティティから受信し、
前記公開暗号化鍵Ｋｅを第１のエンティティに送信し、
メッセージＭの暗号化バージョンを復号するのに適切な復号化鍵を形成するために第２のエンティティが必要とする復号化鍵情報を格納し、
前記復号化鍵情報を索引する鍵検索情報Ｋｒを第１のエンティティに送信し、
第２の交換シーケンス中に、
鍵検索情報Ｋｒを第２のエンティティから受信し、
前記復号化鍵情報を第２のエンティティに送信する、
ようにプログラムされている鍵サーバコンピュータ。
【請求項３４】
その上に実行可能なコードが格納されているコンピュータ読取可能メモリであって、前記コードは、
第１のエンティティにより指定された第２のエンティティに対応する公開暗号化鍵Ｋｅを提供する要求を第１のエンティティから受信するコード、
前記公開暗号化鍵Ｋｅを第１のエンティティに送信するコード、
メッセージＭの暗号化バージョンを復号するのに適切な復号化鍵を形成するために第２のエンティティが必要とする復号化鍵情報を格納するコード、
前記復号化鍵情報を索引する鍵検索情報Ｋｒを第１のエンティティに送信するコード、
を含む第１のコードセットと、
鍵検索情報Ｋｒを第２のエンティティから受信するコード、および、
前記復号化鍵情報を第２のエンティティに送信するコード、
を含む第１のコードセットと、を含むコンピュータ読取可能メモリ。
【請求項３５】
鍵サーバの支援による、送り手および受け手間のメッセージＭの安全な通信方法であって、前記方法は、
メッセージまたは暗号化メッセージが鍵サーバに送られることなく、
送り手がメッセージＭをメッセージ暗号化鍵Ｋｍｅにより暗号化して暗号化メッセージを形成するステップと、
受け手の公開暗号化鍵Ｋｅを使用して、送り手がメッセージ暗号化鍵Ｋｍｅに対応するメッセージ復号化鍵Ｋｍｄから引き出された第１の情報を暗号化するステップと、
暗号化メッセージを復号するのに適切な前記メッセージ復号化鍵Ｋｍｄを形成するために受け手が必要とする復号化鍵情報を鍵サーバが格納するステップと、
復号化鍵情報を索引する鍵検索情報Ｋｒを送り手が受信するステップと、
少なくとも暗号化メッセージおよび鍵検索情報Ｋｒを送り手が受け手に送るステップと、
受け手が鍵検索情報Ｋｒを鍵サーバに送り、それに応答して復号化鍵情報を受信するステップと、
受け手が少なくとも復号化鍵情報および受け手の秘密復号化鍵Ｋｄからメッセージ復号化鍵Ｋｍｄを形成するステップと、
受け手がメッセージ復号化鍵Ｋｍｄにより暗号化メッセージを復号するステップと、
を含む方法。
【請求項３６】
請求項３５に記載の方法であって、メッセージ暗号化鍵Ｋｍｅおよびメッセージ復号化鍵Ｋｍｄは非対称鍵対を形成する方法。
【請求項３７】
請求項３５に記載の方法であって、メッセージ暗号化鍵Ｋｍｅおよびメッセージ復号化鍵Ｋｍｄは同一でありかつ対称鍵Ｋｓである方法。
【請求項３８】
鍵サーバの支援による、送り手および受け手間のメッセージＭの安全な通信方法であって、前記方法は、
メッセージまたは暗号化メッセージが鍵サーバに送られることなく、
送り手がメッセージＭをメッセージ暗号化鍵Ｋｍｅにより暗号化して暗号化メッセージを形成するステップと、
受け手の公開暗号化鍵Ｋｅを使用して、送り手がメッセージ暗号化鍵Ｋｍｅに対応するメッセージ復号化鍵Ｋｍｄから得られた第１の情報を暗号化するステップと、
暗号化メッセージを復号するのに適切な前記メッセージ復号化鍵Ｋｍｄを形成するために受け手が必要とする復号化鍵情報を鍵サーバが格納するステップと、
少なくとも暗号化メッセージを送り手が受け手に送るステップと、
受け手が復号化鍵情報を索引する鍵検索情報Ｋｒを鍵サーバに送り、それに応答して復号化鍵情報を受信するステップと、
受け手が少なくとも復号化鍵情報および受け手の秘密復号化鍵Ｋｄからメッセージ復号化鍵Ｋｍｄを形成するステップと、
受け手がメッセージ復号化鍵Ｋｍｄにより暗号化メッセージを復号するステップと、
を含む方法。
【請求項３９】
請求項３８に記載の方法であって、メッセージ暗号化鍵Ｋｍｅおよびメッセージ復号化鍵Ｋｍｄは非対称鍵対を形成する方法。
【請求項４０】
請求項３８に記載の方法であって、メッセージ暗号化鍵Ｋｍｅおよびメッセージ復号化鍵Ｋｍｄは同一でありかつ対称鍵Ｋｓである方法。
【請求項４１】
請求項３８に記載の方法であって、受け手は送り手から受信した情報に基づいて鍵検索情報Ｋｒを生成する方法。
【請求項４２】
請求項１，１０，１４または１８のいずれか一項に記載の方法であって、さらに、復号化鍵情報の検索を支配する少なくとも一つのポリシーを送り手が確立するステップを含む方法。
【請求項４３】
請求項１，１０，１４，１８または２５のいずれか一項に記載の方法であって、さらに、復号化鍵情報の検索を支配する少なくとも一つのポリシーを鍵サーバが確立するステップを含む方法。
【請求項４４】
請求項１，１０，１４または１８のいずれか一項に記載の方法であって、さらに、
復号化鍵情報の格納および受け手への復号化鍵情報の送出の少なくとも一方を反映するように第１の監査ログを鍵サーバにおいて更新するステップと、
送り手から受け手へのメッセージの送信を反映するように第２の監査ログを送り手において更新するステップと、を含む方法。
【請求項４５】
請求項４４に記載の方法であって、さらに、
送り手により送られたメッセージに対応する第１の監査ログ内のエントリと第２の監査ログ内のエントリ間の対応を検証するステップを含む方法。
【請求項４６】
請求項１，１０，１４または１８のいずれか一項に記載の方法であって、さらに、受け手が送り手のアイデンティティを認証することを送り手が要求するステップを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（技術分野）
本発明は秘密／公開鍵対の監査可能な使用を介したユーザのコミュニティに対する安全な電子メッセージングシステムに向けられている。
【背景技術】
【０００２】
（発明の背景）
電子メールやインスタントメッセージ等の電子メッセージをユーザが安全に交換できるようにするさまざまなシステムがある。インターネット電子メールを送るために、送り手はメッセージコンテンツを集め、所望する受け手のインターネット電子メールアドレスをメッセージに付け加え、恐らくはメッセージが送り手により作られ中継時に修正されていないことを証明する署名方式を用い、恐らくはメッセージのコンテンツに受け手しかアクセスしないことを保証する暗号化方式を用い、インターネット電子メールインフラストラクチュアを使用してメッセージを送信する。
【０００３】
インスタントメッセージ（ＩＭ）システムで情報を交換するために、ユーザは自分自身をＩＭシステムに対して認証し、利用可能なユーザのコミュニティの中から受け手を選択し、メッセージコンテンツを準備し、ＩＭインフラストラクチュアを介してメッセージを送信する。暗号化サービスは認証されたユーザの証明書に基づいてＩＭサービスにより提供することができる。
【０００４】
図１は送り手１１０および受け手１２０がネットワーク１３０を介して暗号化されたメッセージＭｅを交換することができる従来技術の通信アーキテクチュア１００を示す。ここでは、送り手１１０および受け手１２０は電子署名および通信の暗号化の目的で公開／秘密鍵対を使用するユーザのコミュニティの一部である。鍵サーバ１４０は送り手１１０および受け手１２０が他のユーザの公開鍵を得て定められたメッセージングセションに対する対称鍵フラグメントの発生および／または制御されたアクセスに参加できるようにする。鍵サーバ１４０に関連付けられたデータベース１４２が送り手および受け手および使用された鍵に関する情報を維持する。ネットワーク１３０はローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット、またはいくつかの他のタイプの通信インフラストラクチュアのいずれかとすることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
（発明の概要）
本発明は、認証および暗号化の目的で秘密／公開鍵を使用することが記録されかつ監査できるような、ユーザのコミュニティの中での電子メッセージおよび電子データストリームの安全な通信システムおよび方法に向けられている。
【課題を解決するための手段】
【０００６】
本発明において、主要なエンティティは送り手、受け手および鍵サーバである。送り手は暗号化されたメッセージを受け手に送ることを望み、それは鍵サーバにより促進される。鍵サーバは送り手に鍵検索情報を送る。鍵検索情報には暗号化メッセージを復号するのに必要な復号情報が載せられている。送り手は暗号化メッセージおよび鍵検索情報を受け手に送る。暗号化メッセージ自体は鍵サーバへ送られない。次に、受け手は鍵検索情報を鍵サーバへ送りそれに応答して復号情報を受信する。次に、受け手は復号情報を使用して暗号化メッセージを復号する。
【０００７】
本発明の一側面において、データメッセージの送り手は鍵サーバにアクセスしてデータメッセージの所期の受け手に関する公開鍵情報を得る。鍵サーバまたは送り手、あるいは両方が協同して、対称暗号化鍵または非対称暗号化鍵対を発生する。送り手は適切な暗号化鍵を使用してデータメッセージコンテンツを暗号化する。復号化鍵（対称鍵であるかあるいは非対称鍵対の復号部である）は第１の部分および第２の部分に分割される。第２の部分は鍵サーバにより格納される。送り手は暗号化データメッセージ、復号化鍵の第１の部分、および受け手が復号化鍵の第２の部分を得るための鍵検索情報を含む送信パッケージを形成する。随意、送信パッケージ内で、復号化鍵の第１の部分および／または鍵検索情報はそれ自体を受け手の公開暗号化鍵により暗号化することができる。いずれにせよ、次に、送信パッケージは受け手に送られる。受け手は送信パッケージを開き、必要であれば、復号化鍵の第１の部分および／または鍵検索情報を復号する。次に、受け手は受け手の識別情報および鍵検索情報を含む鍵検索要求を生成して鍵サーバに送る。適切な鍵検索要求に応答して、鍵サーバは復号化鍵の第２の相補部分を受け手に戻す。次に、受け手は復号化鍵の第１および第２の部分を結合して暗号化データメッセージを復号しオリジナルデータメッセージにアクセスする。
【０００８】
本発明のもう一つの側面において、送り手は復号化鍵を第１および第２の部分に分割しない。送り手は全体復号化鍵を鍵サーバに送り、鍵サーバは格納された復号化鍵に対応する鍵検索情報を送り手へ戻す。この場合、送り手は受け手に暗号化データメッセージおよび鍵検索情報しか送らず、受け手は次に鍵検索情報をサーバに送って全体復号化鍵を得る。
【０００９】
本発明のさらにもう一つの側面において、鍵サーバは暗号化鍵を生成し、復号化鍵を格納し、鍵検索情報と共に暗号化鍵を送り手へ送る。送り手は暗号化データメッセージおよび鍵検索情報を受け手に送り、次に、受け手は鍵検索情報をサーバに送って復号化鍵を得る。
【００１０】
本発明はメッセージ監査システムにも向けられている。鍵サーバは各鍵に関連付けられた全てのトランザクションのデータベースを維持する。送り手、または他の認可されたエンティティ、はその送り手の鍵に関するトランザクション情報にアクセスすることを許される。それにより、送り手はその送り手により使用されたさまざまな鍵の状態を示す鍵トランザクションログを見ることができる。このようにして、鍵トランザクションログは受け手が復号化鍵情報を得るための鍵検索要求を提出したか、したがって、受け手がメッセージを読んでいるかどうかを示すことができる。送信パッケージに対応する復号化鍵情報がまだ検索されていないことを鍵トランザクションログが示す場合、送り手は対応する鍵検索要求をもはや尊重しないことを鍵サーバに知らせる鍵キャンセル要求を提出することにより、随意有効にメッセージを有効にキャンセルすることができる。それにより、受け手が復号化鍵情報を得ることは防止され、受け手は暗号化メッセージを持っていてもそれを読むのに必要な復号化鍵情報を得ることができないためそれを読むことはできず、暗号化メッセージの読み出しから締め出される。
【実施例】
【００１１】
（発明の詳細な説明）
次に、下記の詳細な説明および図面を用いて本発明を説明する。本説明において、‘送り手’という用語は人間またはメッセージを送信するクライアントプログラムのことであり、‘受け手’という用語は人間または送り手により送信されたメッセージを受信するクライアントプログラムのことである。専門用語の‘鍵サーバ’はプラットホームおよびその上に常駐するサーバエンドコンピュータプログラムのことであり、それはこのようなエンティティに関連付けられたデューティを実施するようにプログラムされている。鍵サーバ、送り手および受け手を含む実行可能なソフトウェアコードが各々汎用その他のコンピュータ、さらには特殊化されたコンピュータのコンピュータ読取可能メモリ内に常駐できることが理解される。さらに、ソフトウェアはウェブサイト、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、テープ、等のサーバからの任意数の形式のコンピュータ読取可能メモリ内に分散させることができる。
【００１２】
本開示の目的のために、送り手および受け手自体は各々がそれを介して外部世界と通信する一つ以上のノードを有する個別の（または、共通の）ネットワーク上とすることができる。このようなネットワークは、とりわけ、インターネットゲートウェイ、ストアアンドフォワード電子メールサーバ、その他既知のアセットを有することができる。
【００１３】
以下の検討において、送り手がインターネット電子メールインフラストラクチュアを介して受け手と通信しかつＨＴＴＰメッセージングプロトコルを介して鍵サーバと通信するメッセージングセションのさまざまな実施例が提示される。しかしながら、以下に説明するシステムはインフラストラクチュアには依存せず任意他のデータキャリヤの他に、またはデータキャリヤと共に、ワイヤレス網を介して動作できることを忘れてはならない。しかしながら、他の通信チャネル（インスタントメッセージング）および他の通信プロトコル（たとえば、ftp,TCP-IP）も同様に使用することができ、本発明の範囲内に入ると考えられることも忘れてはならない。
【００１４】
電子メールの場合、送り手および受け手はメールユーザエージェント（ＭＵＡ）と呼ばれるソフトウェアプログラムとインタラクトしてインターネット電子メールメッセージを構成して送信する人間により使用される。したがって、このようなユーザに関連付けられたコンピュータ（便宜上“送り手コンピュータ”および“受け手コンピュータ”と呼ばれる）には典型的にインターネット電子メールインフラストラクチュアとコンタクトするために必要な手段と共にＭＵＡプログラムが提供される。さらに、これらのコンピュータには揮発性および非揮発性メモリと共にキーボード、マウス等の一つ以上の入力装置が通常提供され、全てが当業者には既知である。しかしながら、送り手および受け手は通常ユーザにより操作されずに管理されていない“サーバ”モードで動作するソフトウェアプログラムであることもある。
【００１５】
（第１の実施例）
図２は送り手２１０、受け手２２０およびデータベース２４２を含む関連付けられたメモリを有する鍵サーバ２４０に関する本発明の第１の実施例に従ったメッセージフロー２００を示す。データベース２４２は電子メールアドレスおよび優先公開暗号化鍵を含むシステムの登録されたユーザに関する情報を格納しており、鍵使用情報、検索情報（後述する）により索引される復号化鍵情報等も格納している。
【００１６】
図２に示す任意のアクションの前に、送り手２１０および鍵サーバ２４０間で認証プロセスが行われて両者間の接続を開く。そのために、送り手は認証要求メッセージを鍵サーバに送り後者はいくつかのランダムビット列で応答し、鍵サーバに送られる各メッセージに対してこのような列が一つ使用される。次に、送り手はメッセージが送られると各ランダムビット列に電子署名を行い、鍵サーバはそのメッセージが送り手により送られたことを確認することができる。送り手は、たとえば、ＲＳＡ鍵対により整理し暗号化することにより秘密署名鍵を使用して任意の確立した標準署名技術を使用することができる。鍵サーバは送り手の公開署名鍵を使用して送り手の署名を検証することができる。したがって、このタイプの認証情報には好ましくは送り手から鍵サーバへ送られた各メッセージが含まれる。
【００１７】
図５ａは第１の実施例において送り手２００により経験される主要なステップを示すフロー図５００である。
【００１８】
ステップ５０２において、送り手および鍵サーバは通信リンクを確立し送り手は認証される。認証は、たとえば、送り手の電子メールアドレス等の送り手の識別情報をチェックして送り手がシステムに登録されていることを確認することを伴うことができる。
【００１９】
ステップ５０４において、送り手２１０は受け手公開鍵要求２５１を鍵サーバ２４０へ送り、それはサーバにより受信される。好ましくは、受け手公開鍵要求は認証情報、送り手の識別情報、および所期の受け手の識別情報（好ましくは、受け手の電子メールアドレスの形）の指示を含むデータフィールドを含んでいる。このメッセージ２５１は受け手の公開暗号化鍵を要求する。電子メールメッセージが２つ以上の受け手に行く場合には、受け手フィールドはデータフィールド内に指示された各受け手の電子メールアドレスを含んでいる。
【００２０】
ステップ５０６において、鍵サーバはデータベース２４２をチェックして送り手２１０のアカウントが現行のものであることを確認する。送り手のアカウントが現行のものでなければ、ステップ５０８において鍵サーバは送り手にそう知らせる。
【００２１】
ステップ５１０において、送り手のアカウントが現行のものであれば、鍵サーバ２４０は次にデータベースを調べて受け手公開鍵要求において識別された受け手２２０に関する情報を検索する。次に、鍵サーバ２４０は好ましくはメッセージを追跡するメッセージ識別子、受け手２２０の優先公開暗号化鍵Ｋｅを含むデータフィールド、および関連する監査情報を含む受け手公開鍵応答２５２を準備する。受け手公開鍵要求２５１に２つ以上の受け手が記載されている場合、データフィールドは各受け手に対して一つずつの鍵アレイを含んでいる。しかしながら、メッセージ識別子は送り手により受け手に送られるこのメッセージに一意的に割当てられる。また、鍵サーバ２４０はイベント、送り手２１０が受け手２２０の公開暗号化鍵を要求した時間、を追跡し続ける。最後に、鍵サーバ２４０は受け手公開鍵応答２５２を送り手２１０へ送る。
【００２２】
送り手により指示された受け手がシステムを使用するように登録されていないことも考えられる。未登録受け手がいるこのシナリオについては後述する。
【００２３】
ステップ５１２において、送り手２１０は対称鍵Ｋｓを発生する。しかしながら、Ｋｓは送り手が受け手公開鍵要求を鍵サーバ２４０に送る前に発生されていることもある。次に、送り手は受け手の公開暗号化鍵Ｋｅ（受け手公開鍵応答内に提供される）を使用して対称鍵Ｋｓを暗号化してＫｓｅを形成し、それは受け手の公開暗号化鍵Ｋｅに対応する受け手の秘密暗号化鍵Ｋｄを使用して受け手２２０しか復号することができない。次に、送り手はＫｓｅを暗号学的に第１の分割鍵フラグメントＫｓｅ１および第２の分割鍵フラグメントＫｓｅ２に分割し、Ｋｓｅを生成するのにその両方が必要である。これは、たとえば、確立した技術を使用して２つのフラグメントＫｓｅ１，Ｋｓｅ２を形成することによってなされ、それらは一緒にＸＯＲされると暗号化された対称鍵Ｋｅとなる。２つ以上の受け手が指示されておれば、このプロセスはこのような各受け手に対してその受け手の対応する公開暗号化鍵を使用して行われる。
【００２４】
ステップ５１４において、次に、送り手２１０は鍵フラグメント格納要求２５３を鍵サーバ２４０に送る。好ましくは、鍵フラグメント格納要求は認証情報、メッセージ識別子、送り手の識別情報、受け手の識別情報を含む第１のデータフィールド、その受け手に対する第２の分割鍵フラグメントＫｓｅ２を含む第２のデータフィールド、および恐らくは関連する監査情報を含んでいる。２つ以上の受け手が含まれる場合、第１および第２のデータフィールドは各受け手をその受け手の第２の分割鍵フラグメントへマッピングするアレイを有効に含む。
【００２５】
ステップ５１６において、鍵サーバ２４０はアーカイバルメッセージ２５４をデータベース２４２へ送って受け手の電子メールアドレスおよびメッセージ識別子により相互参照されるＫｓｅ２を含む復号化鍵情報を格納する。好ましくは、復号化鍵情報も送り手の識別情報により相互参照される。鍵サーバ２４０は鍵検索情報Ｋｒも発生する。鍵検索情報Ｋｒはユニバーサルリソースロケータ（ＵＲＬ）フォーマットとすることができ、あるいは少なくともＫｓｅ２を含むレコードを索引する他の識別子とすることができる。２つ以上の受け手が指示される場合には、このプロセスは各々に対して実施される。
【００２６】
ステップ５１８において、アーカイバル格納およびＫｒの発生に成功すると、鍵サーバ２４０は好ましくはメッセージ識別子およびＫｓｅ２を検索する鍵検索情報Ｋｒを含む鍵格納応答２５５を送る。アーカイバル格納およびＫｒ発生のいずれかが不成功であれば、ステップ５２０においてエラーメッセージが送り手に送られる。
【００２７】
ステップ５２２において、送り手２１０は鍵格納応答を受信し、オリジナルメッセージＭに随意署名し（送り手自身の秘密署名鍵により）かつ随意安全にタイムスタンプし、適用で可能であれば、これら２つのプロセスにより発生された署名データＳおよびタイムスタンプデータＴを添付する。安全なタイムスタンピングは米国特許第5,136,646号および第5,136,647号に開示されているような任意数の方法で実施することができる。送り手の署名データＳおよびタイムスタンプデータＴは、存在する場合、オリジナルメッセージに添付され、次に、対称鍵Ｋｓを使用して一緒に暗号化されて暗号化メッセージＭｅを形成する。次に、送り手は第１の分割鍵フラグメントＫｓｅ１および鍵検索情報Ｋｒを暗号化メッセージＭｅに添付する。メッセージ識別子および付加監査情報も添付することができる。このプロセスはコンポジットメッセージＣ１を生成する。しかしながら、暗号化ステップは鍵Ｋｓｅが分割される前または後であって、Ｋｓが発生されメッセージが随意署名されかつ／または安全にタイムスタンプされている後の任意の時間に行うことができる。
【００２８】
最後に、ステップ５２４において、送り手２１０は次に典型的なＭＵＡ機能を使用してコンポジットメッセージ２５６を受け手２２０に送信する。あるいは、セキュリティの理由から、暗号化メッセージＭｅは残りのデータとは別個に送ることができる。
【００２９】
図５ｂは第１の実施例において受け手２２０により経験される主要なステップを示すフロー図５５０である。
【００３０】
ステップ５５２において受け手２２０はコンポジットメッセージＣ１を受信し、ステップ５５４において少なくとも暗号化メッセージＭｅ、第１の分割鍵フラグメントＫｓｅ１および鍵検索情報Ｋｒを‘アンパックする’。
【００３１】
ステップ５５６において、受け手２２０および鍵サーバ２４０は通信リンクを確立し受け手は認証される。認証は、たとえば、受け手の電子メールアドレス等の受け手の識別情報をチェックして受け手がシステムに登録されていることを確認することを伴うことができる。
【００３２】
ステップ５５８において、認証の後で、受け手２２０は鍵フラグメント検索要求２５７を送り鍵サーバ２４０が受信する。鍵フラグメント検索要求はいくつかのフィールドを有しかつ好ましくは受け手の認証情報、メッセージ識別子（コンポジットメッセージＣ１内で送り手から受信した場合）、受け手の識別情報（受け手の電子メールアドレス等）、鍵検索情報Ｋｒ、および恐らくは付加監査情報も含んでいる。ここで、メッセージ識別子および鍵検索情報は同一であることがあり、このような場合一つのフィールドしか使用できない。２つ以上の受け手が初めに指示された場合、各受け手は暗号化情報を読むことができるようにこのような鍵フラグメント検索要求を独立に送らなければならない。鍵フラグメント検索要求を受信すると、鍵サーバ２４０は最初に受け手のアカウント２２０が現行のものであるかどうか、また受け手に復号化鍵情報を受信する権利があるかどうかを調べる。受け手のアカウントが現行のものでなければ、ステップ５６０において受け手はそのように報告される。
【００３３】
ステップ５６２において、受け手のアカウントが現行のものであると仮定すると、鍵サーバ２４０はＫｒにより参照されるアーカイブされた第２の分割鍵フラグメントＫｓｅ２を検索する。Ｋｓｅ２の検索に成功すると、ステップ５６０において鍵サーバ２４０は鍵フラグメント検索応答２５８を受け手２２０へ送り返す。好ましくは、鍵フラグメント検索応答はメッセージ識別子、第２の分割鍵フラグメント、および恐らくは監査情報も含んでいる。また、鍵サーバ２４０は受け手が鍵検索情報Ｋｒを提出しておりかつ第２の分割鍵フラグメントＫｓｅ２が送られている事実を反映するようにデータベース２４２を更新する。送り手は鍵サーバ２４０上にロギングすることにより受け手がＫｓｅ２を検索した（したがって、恐らくメッセージを読むことができた）かどうかを決定することができる。あるいは、鍵サーバは送り手にファックスや電子メールを自動的に送り、送り手の一つ以上の発信暗号化メッセージに対応する鍵検索情報が受け手により提示されていることを送り手に知らせるように設定することができる。
【００３４】
ステップ５６４において、Ｋｓｅ２（鍵フラグメント検索応答内で鍵サーバにより送られた）を受信すると、受け手２２０は暗号学的にＫｓｅ１（コンポジットメッセージＣ１内にあった）をＫｓｅ２と結合してＫｓｅを再生成する。次に、受け手はそれ自体の秘密復号化鍵Ｋｄを使用してＫｓｅを復号して対称鍵Ｋｓを作り出す。
【００３５】
ステップ５６６において、次に、受け手は対称鍵Ｋｓを使用して送り手から送られた暗号化メッセージＭｅを復号する。送り手が初めに署名データＳおよび／またはタイムスタンプデータＴを添付している場合には、それらを既知の方法で受け手が検証することができ、それには鍵サーバへの付加要求（送り手の公開署名鍵を得る等の）またはタイムスタンプデータＴの検証に対する安全なタイムスタンプサーバの要求を伴うことができる。
【００３６】
前記した第１の実施例では、鍵サーバ２４０は両方の分割鍵フラグメントＫｓｅ１およびＫｓｅ２を有することは決してない。したがって、第１の実施例では、鍵サーバ２４０はたとえどうにか暗号化メッセージＭｅを手に入れても、２つの分割鍵フラグメントの一方しかないため、そのメッセージを復号することができない。
【００３７】
（第２の実施例）
図３は送り手３１０、受け手３２０およびデータベース３４２を含む関連付けられたメモリを有する鍵サーバ３４０に関する本発明の第２の実施例に従ったメッセージフロー３００を示す。この実施例におけるメッセージのシーケンスは実質的に第１の実施例のそれと同じであり、主要な違いはいくつかのメッセージフローのコンテンツである。
【００３８】
図６ａは第２の実施例において送り手３１０により経験される主要なステップを示すフロー図６００である。
【００３９】
ステップ６０２において、送り手３１０および鍵サーバ３４０は通信リンクを確立し送り手は認証される。認証は、たとえば、送り手の電子メールアドレス等の送り手の識別情報をチェックして送り手がシステムに登録されていることを確認することを伴うことができる。
【００４０】
ステップ６０４において、送り手３１０は受け手公開鍵要求３５１を鍵サーバ３４０へ送り、それは鍵サーバにより受信される。好ましくは、受け手公開鍵要求は認証情報、送り手の識別情報、および所期の受け手の識別情報（好ましくは、受け手の電子メールアドレスの形）の指示を含むデータフィールドを含んでいる。このメッセージ３５１は受け手の公開暗号化鍵を要求する。電子メールメッセージが２つ以上の受け手に行く場合には、受け手フィールドはデータフィールド内に指示された各受け手の電子メールアドレスを含んでいる。
【００４１】
ステップ６０６において、鍵サーバ３４０はデータベース２４２をチェックして送り手３１０のアカウントが現行のものであることを確認する。送り手のアカウントが現行のものでなければ、ステップ６０８において鍵サーバは送り手にそう知らせる。
【００４２】
ステップ６１０において、送り手のアカウントが現行のものであれば、鍵サーバ３４０は次にデータベースを調べて受け手公開鍵要求において識別された受け手３２０に関する情報を検索する。次に、鍵サーバ３４０は好ましくは新たに生成されたメッセージ識別子、受け手３２０の優先公開暗号化鍵Ｋｅ、および関連する監査情報を含む受け手公開鍵応答３５２を準備する。また、鍵サーバ３４０は受け手公開鍵要求イベントを含むようにデータベース３４２を更新する。
【００４３】
ステップ６１２において、送り手３１０は受け手公開鍵応答を受信し、対称鍵Ｋｓを発生しかつＫｅを使用して対称鍵Ｋｓを暗号化し、暗号化された対称鍵Ｋｓｅを作り出す。
【００４４】
ステップ６１４において、次に、送り手３１０は鍵格納要求３５３を鍵サーバに送る。しかしながら、この鍵格納要求は暗号化された対称鍵の分割鍵フラグメントだけでなく全体暗号化対称鍵Ｋｓｅを含んでいる。
【００４５】
ステップ６１６において、鍵サーバ３４０はアーカイバルメッセージ３５４をデータベース２４２へ送ってＫｓｅを含む復号化鍵情報を格納し、適切な鍵検索情報Ｋｒを発生する。このプロセスが成功しない場合には、ステップ６１８においてエラーメッセージが送り手に送られる。しかしながら、アーカイバルメッセージおよびＫｒの発生に成功すると、ステップ６２０において鍵サーバ３４０は次に鍵格納応答３５５を送る。鍵格納応答はメッセージ識別子および送り手３１０への鍵検索情報Ｋｒを含んでいる。
【００４６】
ステップ６２２において、送り手３１０はオリジナルメッセージに随意署名しかつ／または安全にタイムスタンプし、使用された場合、これら２つのプロセスにより発生された署名データおよび／またはタイムスタンプデータをオリジナルメッセージに添付する。次に、送り手は対称鍵Ｋｓを使用してオリジナルメッセージを（存在する場合、署名および／またはタイムスタンプデータと一緒に）暗号化して暗号化メッセージＭｅを形成する。次に、送り手は鍵検索情報Ｋｒを暗号化メッセージＭｅに添付する。付加監査情報も添付することができる。このプロセスはコンポジットメッセージＣ２を生成する。
【００４７】
最後に、ステップ６２４において、送り手３１０は次に典型的なＭＵＡ機能を使用してコンポジットメッセージ３５６を受け手３２０に送信する。あるいは、セキュリティの理由から、暗号化メッセージＭｅは残りの情報とは別個に送ることができる。
【００４８】
図６ｂは第２の実施例において受け手３２０により経験される主要なステップを示すフロー図６５０である。
【００４９】
ステップ６５２において受け手３２０はコンポジットメッセージＣ２を受信し、ステップ６５４においてそれを少なくとも暗号化メッセージＭｅおよび鍵検索情報Ｋｒへ‘アンパックする’。
【００５０】
ステップ６５６において、受け手３２０および鍵サーバ３４０は通信リンクを確立し受け手は認証される。認証は、たとえば、受け手の電子メールアドレス等の受け手の識別情報をチェックして受け手がシステムに登録されていることを確認することを伴うことができる。
【００５１】
ステップ６５８において、認証の後で、受け手３２０は鍵フラグメント検索要求３５７を送り鍵サーバ３４０が受信する。鍵検索要求は好ましくは認証情報、メッセージ識別子（送り手から送られた場合）、受け手の識別情報（受け手の電子メールアドレス等）、鍵検索情報Ｋｒ、および恐らくは付加監査情報も含んでいる。鍵サーバ３４０は受け手３２０のアカウントが現行のものであり有効であるかどうかをを調べる。そうでなければ、ステップ６６０において受け手３２０にエラーメッセージが送られる。
【００５２】
ステップ６６２において、受け手のアカウントが現行のものでありかつ有効であると仮定すると、鍵サーバ３４０はＫｒにより参照されるアーカイブされた暗号化対称鍵Ｋｓｅを検索し、鍵検索応答３５８を受け手３２０へ送り返す。好ましくは、鍵検索応答はメッセージ識別子、暗号化対称鍵Ｋｓｅ、および恐らくは関連する監査情報も含んでいる。また、鍵サーバ３４０は受け手が鍵検索情報Ｋｒを提出しておりかつ暗号化対称鍵Ｋｓｅが送られている事実を反映するようにデータベース３４２を更新する。送り手は鍵サーバ３４０上にロギングすることにより受け手がＫｓｅを検索した（したがって、恐らくメッセージを読んだ）かどうかを決定することができる。
【００５３】
ステップ６６４において、鍵サーバからＫｓｅを受信すると、受け手３２０はそれ自体の秘密復号化鍵Ｋｄを使用して対称鍵Ｋｓを作り出す。
【００５４】
最後に、ステップ６６６において、次に、受け手は対称鍵Ｋｓを使用して送り手から送られた暗号化メッセージＭｅを復号する。Ｍｅの暗号後に、もし存在すれば、受け手は署名データＳおよびタイムスタンプＴを検証することができる。
【００５５】
（第３の実施例）
図４は送り手４１０、受け手４２０およびデータベース４４２を含む関連付けられたメモリを有する鍵サーバ４４０に関する本発明の第３の実施例に対するメッセージフロー４００を示す。この実施例におけるメッセージのシーケンスは第１および第２の実施例の対応するシーケンスとは幾分異なる。
【００５６】
図７ａは第３の実施例において送り手４１０により経験される主要なステップを示すフロー図７００である。
【００５７】
ステップ７０２において、送り手４１０および鍵サーバ４４０は通信リンクを確立し送り手は前記した実施例と同様に認証される。
【００５８】
ステップ７０４において、第１および第２の実施例と同様に、送り手４１０は所期の受け手４２０に対する受け手公開鍵要求を送り、鍵サーバ４４０が受信する。
【００５９】
ステップ７０６において、鍵サーバ４４０は送り手４１０のアカウントが現行のものであるかどうか調べる。送り手のアカウントが現行のものでなければ、ステップ７０８において鍵サーバ４４０それを送り手４１０に知らせる。
【００６０】
ステップ７１０において、送り手のアカウントが現行のものであると仮定すると、鍵サーバ４４０は対称鍵Ｋｓを発生しそれを２つの分割鍵フラグメントＫｓ１およびＫｓ２へ暗号学的に分割する。次に、鍵サーバ４４０はアーカイバルメッセージ４５２をデータベース４４２へ送ってＫｓ２（または、受け手の公開暗号化鍵Ｋｅにより形成されたその暗号化バージョンＫｓｅ２）を含む復号化鍵情報を格納し適切な鍵検索情報Ｋｒを発生する。次に、鍵サーバ４４０は鍵格納応答４５３を送り手に送り返す。好ましくは、鍵格納応答はメッセージ識別子、受け手の優先公開暗号化鍵Ｋｅ、Ｋｓ２を形成するのに十分な対称鍵情報、および鍵検索情報Ｋｒを、関連する付加監査情報と共に含んでいる。対称鍵情報は単純にＫｓ２自体とすることができるが、好ましくは、両方の分割鍵フラグメントＫｓ１およびＫｓ２を含んでいる。
【００６１】
ステップ７１２において、送り手３１０はＫｓ１およびＫｓ２を結合してＫｓを発生する。（あるいは、鍵サーバ４４０が対称鍵情報としてＫｓ１およびＫｓ２ではなくＫｓを送る場合、送り手は鍵サーバと厳密に同じ方法でＫｓを分割する）。次に、送り手４１０は随意オリジナルメッセージに署名しかつ／または安全にタイムスタンプし、使用される場合、これら２つのプロセスにより発生される署名データＳおよび／またはタイムスタンプデータＴをオリジナルメッセージに添付する。次に、送り手は対称鍵Ｋｓを使用してオリジナルメッセージＭを暗号化して（使用される場合、署名および／またはタイムスタンプデータと共に）暗号化メッセージＭｅを形成する。また、送り手は受け手の公開暗号化鍵Ｋｅを使用して分割鍵フラグメントＫｓ１を暗号化して暗号化分割鍵フラグメントＫｓｅ１を作り出す。次に、送り手はＫｓｅ１および鍵検索情報Ｋｒを暗号化メッセージＭｅに添付する。メッセージ識別子および付加監査情報も添付することができる。このプロセスはコンポジットメッセージＣ３を生成する。
【００６２】
最後に、ステップ７１４において、送り手４１０は次に典型的なＭＵＡ機能を使用してコンポジットメッセージ４５４を受け手４２０に送信する。あるいは、セキュリティの理由から、暗号化メッセージＭｅは残りの情報とは別個に送ることができる。
【００６３】
図７ｂは第３の実施例において受け手４２０により経験される主要なステップを示すフロー図７５０である。
【００６４】
ステップ７５２において受け手４２０はコンポジットメッセージＣ３を受信し、ステップ７５４においてそれを暗号化メッセージＭｅ、暗号化分割鍵フラグメントＫｓｅ１、および鍵検索情報Ｋｒへ‘アンパックする’。
【００６５】
ステップ７５６において、受け手４２０および鍵サーバ４４０は通信リンクを確立し受け手は認証される。認証は、たとえば、受け手の電子メールアドレス等の受け手の識別情報をチェックして受け手がシステムに登録されていることを確認することを伴うことができる。
【００６６】
ステップ７５８において、認証の後で、受け手４２０は鍵検索要求４５５を送り鍵サーバ４４０が受信する。鍵検索要求は好ましくは受け手の認証情報、メッセージ識別子（送り手から送られた場合）、受け手の識別情報、鍵検索情報Ｋｒ、および恐らくは付加監査情報も含んでいる。鍵検索要求を受信すると、鍵サーバ４４０は受け手４２０のアカウントが現行のものであり有効であるかどうかを調べる。そうでなければ、ステップ７６０において受け手４２０にメッセージが送られる。
【００６７】
ステップ７６２において、受け手のアカウントが現行のものであり有効であると仮定すると、鍵サーバ４４０はＫｒにより参照されるアーカイブされた分割鍵フラグメントＫｓ２（またはＫｓｅ２）を検索する。次に、鍵サーバ４４０は鍵検索応答４５６を受け手４２０へ送り返す。好ましくは、鍵検索応答はメッセージ識別子、分割鍵フラグメントＫｓ２（またはＫｓｅ２）、および恐らくは監査情報も含んでいる。また、鍵サーバ４４０は受け手が鍵検索情報Ｋｒを提出しておりかつ分割鍵フラグメントＫｓ２（またはＫｓｅ２）が送られている事実を反映するようにデータベース４４２を更新する。送り手４１０は鍵サーバ４４０上にロギングすることにより受け手がＫｓ２（またはＫｓｅ２）を検索した（したがって、恐らくメッセージを読んだ）かどうかを決定することができる。
【００６８】
ステップ７６４において、鍵サーバからＫｓ２（またはＫｓｅ２）を受信すると、受け手４２０はそれ自体の秘密復号化鍵Ｋｄを使用してＫｓｅ１を復号し、Ｋｓ１とＫｓ２（恐らくは、鍵サーバ４４０により送られたＫｓｅ２を最初に復号して得られた）を結合して対称鍵Ｋｓを作り出す。最後に、ステップ７６６において、受け手４４０はＫｓを使用して暗号化メッセージＭｓを復号する。また、前記したように、受け手は次に署名データおよびタイムスタンプを検証することができる。
【００６９】
（実施例の比較）
前記した各実施例において、鍵サーバの調停が準備された暗号化メッセージにより鍵サーバは受け手が暗号化メッセージを復号するために手に入れなければならないある情報をアーカイブする。しかしながら、鍵サーバがメッセージ自体（暗号化されているかどうかにかかわらず）を受信することは決してない。それにより鍵サーバにおける帯域幅および格納スペースが節減されるだけでなく、メッセージ自体はメッセージを復号するのに必要な任意の部分を有するエンティティには提供されないため、送り手および受け手にはある程度のセキュリティが提供される。
【００７０】
さらに、前記した各実施例において、送り手は対称鍵Ｋｓから引き出されるある情報を暗号化するのに受け手の公開暗号化鍵Ｋｅを使用しなければならない。これらの目的のために、対称鍵Ｋｓから引き出される情報はＫｓ自体、または分割鍵フラグメントＫｓ１および／またはＫｓ２とすることができる。さらに、受け手は鍵サーバから得られるある情報と共に自分の秘密復号化鍵Ｋｄを使用して対称鍵Ｋｓを得た後でなければ、暗号化メッセージＭｅを読むことができない。
【００７１】
前記した各実施例において、送り手および受け手がどのように接続されても違いはない。そのため、それらは異なるインターネットサービスプロバイダを使用することができかつ異なる国にあってもよい。必要なのは送り手および受け手が電子メールアドレスを有し、鍵サーバを運営する鍵サーバ機関に登録されていることだけである。
【００７２】
また、鍵サーバの主要な役割は暗号化および鍵検索プロセスを調停することであるが、鍵サーバはユーザの選択や他のポリシーに基づいて鍵アクセスを制約することができる。たとえば、ユーザは鍵（または鍵フラグメント）を将来のある時間まで解放できない、または即座にあるいは将来のある時間に利用できなくなると明示することができる。他のポリシーは送り手または受け手のアカウント履歴または現行のものアカウント状態、どちらかのパーティが鍵へのアクセスを試みる場所または装置、またはトランザクションを取り巻く他の要因に基づいて鍵を解放することができる。さらに、他のポリシーにより鍵サーバはそのアーカイバルエリアから復号化鍵（または鍵フラグメント）を永久に削除してメッセージを実質的に復号不能とすることができる。
【００７３】
オリジナルメッセージが送り手により署名される場合、署名は鍵サーバから送り手の公開署名鍵を要求することにより受け手により検証することができる。オリジナルメッセージが安全にタイムスタンプされる場合、受け手は適切なアクションをとってタイムスタンプ受領が安全にタイムスタンプされデータと一致することを検証することができる。もちろん、受け手がとるアクションは使用したタイムスタンピングプロトコルのタイプによって決まる。
【００７４】
本発明の第１の実施例は送り手および受け手間のメッセージ通信において最高度のセキュリティを提供する。鍵サーバ２４０は決して暗号化された分割鍵フラグメントＫｓｅ１にアクセスしない。さらに、暗号化メッセージの復号には、
（１）鍵サーバにより格納された暗号化分割鍵Ｋｓｅ２、
（２）メッセージのコンテンツおよびその添付された暗号化分割鍵Ｋｓｅ１、および
（３）受け手の秘密復号化鍵Ｋｄ、が必要である。
【００７５】
本発明の第２の実施例はかなり強度のセキュリティを提供する。鍵サーバ３４０は決してＫｓｅの暗号化されないバージョンにアクセスしない。さらに、メッセージの復号には、
（１）鍵サーバにより格納された暗号化対称鍵Ｋｓｅ（鍵サーバは復号できない）、
（２）メッセージのコンテンツ、および、
（３）受け手の秘密復号化鍵Ｋｄ、が必要である。
【００７６】
第３の実施例はかなり強度のセキュリティを提供する。この実施例では、鍵サーバは対称鍵Ｋｓを発生し、エンティティはこの情報へのアクセスを有し暗号化メッセージを復号することができる。メッセージの復号には、
（１）鍵サーバにより格納された分割鍵Ｋｓ２（Ｋｓ１へのアクセスも有するため鍵サーバはそれを使用できる）、
（２）メッセージのコンテンツおよびその添付された暗号化分割鍵Ｋｓｅ１、および
（３）受け手の秘密復号化鍵Ｋｄ、が必要である。
【００７７】
インスタントメッセージングアプリケーションでは、ユーザが鍵サーバとインタラクトして対称鍵Ｋｓを確立すると、少しでも可能であればピアツーピアで、確立された鍵を使用して鍵サーバに無関係に互いに通信して安全なメッセージング接続を維持することができる。それにより、チャネルトラフィック上の負荷およびインスタントメッセージングセションを処理する鍵サーバ、またはその指令下の他のサーバ、になされる要求上の負荷が低減される。
【００７８】
（鍵検索戦略）
前記した実施例では、鍵検索情報が鍵サーバから送り手へ送られて受け手に送信される。しかしながら、鍵検索情報は送り手が生成して受け手は他の方法で得ることもできる。
【００７９】
一組のシナリオにおいて、鍵検索情報は送り手により生成される。一例では、送り手がハッシュ関数を使用して暗号化メッセージから鍵検索情報を発生し、得られるハッシュを復号化鍵情報のインデクスとして使用されるよう鍵サーバへ送る。受け手は鍵検索情報を送り手から直接得るか、あるいは送り手から受信した暗号化メッセージに同じハッシュ関数を実行することにより鍵検索情報を独立に生成することができる。もう一つの例として、送り手は平分メッセージから鍵検索情報を生成し得られるハッシュを鍵サーバおよび受け手に送ることができる。さらにもう一つの例では、送り手はインデクスとして使用される乱数を生成し、それを鍵検索情報として使用するために鍵サーバおよび受け手に送る。この方法に異なるメッセージが同一乱数を作り出す非常に小さな機会があるというリスクを伴う。
【００８０】
もう一組のシナリオでは、メッセージＩＤを他の情報と組み合わせて使用して復号化鍵情報を索引することができる。たとえば、メッセージＩＤを受け手の電子メールアドレスと組み合わせれば鍵検索情報として使用するのに十分である。このような場合、鍵サーバはメッセージＩＤを確立して受け手が誰かを知ると、鍵検索インデクスを作り出す。送り手は、鍵サーバから受信した一つのメッセージ内で、メッセージＩＤを受信し鍵検索情報を定式化することができる。メッセージＩＤがコンポジットメッセージ内で受け手に送られる場合、受け手は明らかにそれ自体の電子メールアドレスを知っているため、鍵検索情報を有効に再生成することができる。各エンティティはそれ自体がメッセージＩＤと受け手の電子メールアドレスしか知らないで鍵検索情報を生成することができるため、完全な鍵検索情報を鍵サーバから送り手へ、または送り手から受け手へ送る必要がない。
【００８１】
全てのシナリオにおいて重要なのは、受け手がある鍵検索情報を鍵サーバへ送り、引き換えに、復号化鍵情報を受信することである。
【００８２】
（登録）
本発明は鍵サーバまたは他の関連するエンティティに登録されたユーザしか受け手に暗号化メッセージを送れないものと考えている。登録プロセスは好ましくは鍵サーバに関連付けられたウェブサイト上に掲示された登録用紙をユーザに埋めさせて遂行される。しかしながら、電話および郵便配達を含む、さまざまな他の通信形式を使用して登録に必要な情報を提供することができる。ウェブベース登録用紙はアカウントを開設するようある個人識別情報をシステムに提示することをユーザに要求する。好ましくは、最小限、個人識別情報はユーザ名およびパスワードを含んでいる。簡単にするために、ユーザ名はユーザの電子メールアドレスとすることができるが、それは要求条件ではない。加入料その他のユーザ手数料が要求される場合、登録プロセスはクレジットカード等の支払情報も要求することができる。
【００８３】
一実施例では、登録されたユーザの真のアイデンティティは検証されない。電子メールアドレス自体は常に個人のアイデンティティを示すものではないため、本発明は電子メールアドレスが既知の受け手に暗号化された電子メールを偽名で送れるようにする。しかしながら、登録プロセスの一部として、本システムはユーザが指示した電子メールアドレスに電子メールを送ることによりユーザを“認証”することができる。登録プロセスを完了させるためにＵＲＬ上をクリックするかまたはウェブページに行って将来の識別の目的で付加質問に答えることにより、ユーザは電子メールに含まれる命令に従わなければならない。
【００８４】
しかしながら、別の実施例では、個人識別情報を検証することができる。このような場合、登録するとユーザは公開鍵証明書、ＩＴＵ Ｘ.５０９証明書、等の付加証明書の提供を求められことがある。次に、このような証明書はもしあればシステムのどの機能にユーザがアクセスできるかを決定するのに将来使用することができる。
【００８５】
識別情報が提供されると、クライアント側ソフトウェアがユーザのコンピュータへ配信されインストールされる。インスタレーションプロセスの一部として、ユーザは新しい鍵対Ｋｅ，Ｋｄを確立し、それに対してユーザだけが秘密鍵Ｋｄを所持し続けＫｅはそのユーザに関連付けられるものとして鍵サーバにより格納される。ユーザはシステムで使用する新しい鍵対（Ｋｅ，Ｋｄ）を発生しいつでも鍵サーバに登録された優先公開暗号化鍵Ｋｅを更新することができる。好ましくは、古い鍵対はローカルに格納され現存しない公開鍵を暗号化に使用したメッセージを復号するのに使用することができる。
【００８６】
登録プロセス中に、ユーザは鍵サーバとどのようにインタラクトしたいかに関するある好みを選択する機会も提供される。それには、（１）ユーザ−送り手がメッセージの受け手による鍵サーバアクセスをどのように知らされるか（たとえば、電子メールまたはウェブサイト上のユーザロギングおよびさまざまなアクティビティの状態ルックアップ）、（２）ユーザが好む特権（たとえば、メッセージ送信、メッセージ受信、または両方）、および（３）デバイス関連または他のポリシー関連制約（たとえば、月曜から金曜までの午前８時から午後６時の間だけワークコンピュータから暗号化メッセージを送ることができる）が含まれている。
【００８７】
図８はユーザを登録するステップのフロー図８００である。ステップ８０２において、ユーザは登録プロセスとコンタクトする。ステップ８０４において、ユーザはユーザを一意的に識別するいくつかのデータアイテム（たとえば、ユーザ名、ユーザのフルネーム、電話番号、または電子メールアドレス）を登録プロセスに提示する。ステップ８０６において、ユーザはクライアントソフトウェアをダウンロードしインストールする。ステップ８０８において、ユーザはそのローカルマシン上に鍵対（Ｋｅ，Ｋｄ）を発生する、あるいは、ＩＴＵ Ｘ.５０９証明書やPretty Good Privacy (PGP)証明書等の自分が所持する公開鍵証明書を使用する。ステップ８１０において、ユーザは公開暗号化鍵Ｋｅを鍵サーバに提出する。ステップ８１２において、ユーザは付加オプションを選択する。最後に、ステップ８１４において、鍵サーバは新しいユーザ情報および対応する証明書でデータベースを更新する。その後、鍵サーバは証明書情報を使用して登録されたどのユーザが特定の暗号化または復号化鍵を要求しているか、およびそのユーザがどのサービスを要求しているかを決定することができる。
【００８８】
（クライアント側ソフトウェア）
クライアント側ソフトウェアはフロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ，ＰＣＭＣＩＡカード、等の任意数の従来の非揮発性メモリ記憶装置からインストールすることができる。しかしながら、大概の場合、クライアント側ソフトウェアは鍵サーバに関連付けられたウェブサイトから得られるものと思われる。
【００８９】
クライアント側ソフトウェアはユーザの既存の電子メールシステムと協働するプラグインを含むことができる。インストールされたソフトウェアは既存のMail User Agent (MUA)の拡張として作用したり独立ＭＵＡとすることができ、また、ＭＵＡやウェブベース電子メールソフトウェアと共に使用することができるあるソフトウェアとすることができる。同様に、インスタントメッセージングコンテキストにおいて、ソフトウェアは既存のInstant Messaging Agent (IMA)にプラグインしたり、独立ＩＭＡまたはＩＭＡと共に使用することができるあるソフトウェアとすることができる。
【００９０】
ダウンロードされたソフトウェアをユーザのコンピュータ上にインストールするプロセスにより、オペレーティングシステム環境内に新しい設定が規定されるだけでなく、ユーザのＭＵＡクライアント（たとえば、Microsoft Outlook, Qualcomm Eudora、その他同様なプログラム）またはInstant Messagingクライアント内にプラグインモジュールがインストールされる。ユーザの選択に応じて、ソフトウェアは自給自足ＭＵＡクライアントまたはＩＭクライアントをインストールすることができる。
【００９１】
本発明のもう一つのソフトウェアインプリメンテーションにより、ソフトウェアはＭＴＡ（mail transfer agent）、たとえば、Microsoft Exchange, Lotus Notes, その他類似のプログラム内に拡張またはプラグインモジュールとしてインストールされる。このような場合、ＭＵＡクライアントとインストールされたソフトウェア間のインタラクションはＭＴＡアドミニストレータにより支配され、送り手および受け手の役割はＭＴＡプラグインモジュールにより実施される。
【００９２】
ＭＵＡ拡張またはメールを見るのに使用される他のアプリケーションとして動作するクライアント側ソフトウェアはセキュリティ要求条件に応じていくつかの方法で構成することができる。それゆえ、たとえば、ＭＵＡ拡張は復号されディスプレイされているメッセージをユーザがコピーするのを制約する‘ワンタイムリード’機能を内蔵することができる。このような場合、ユーザはメッセージを保全したりバッファすることを許されず、メッセージはディスプレイされるのを中止すると復号不能となり潜在的に削除される。
【００９３】
（登録されない受け手）
送り手により指示された受け手がユーザのコミュニティの会員ではない、すなわち、登録されていなければ、鍵サーバはその指示された受け手に対する公開暗号化鍵Ｋｅを持っていない。この状況は受け手に対する一時的鍵対をサーバに生成させる、または受け手に対する一時的鍵対を送り手に生成させることで処理することができる。
【００９４】
鍵サーバが鍵対を生成する場合、それは送り手および受け手とのインタラクションにおいていくつかの付加ステップを実施する、（１）鍵サーバは非会員受け手のために一時的鍵対（Ｋｅｔ，Ｋｄｔ）を発生し、この対は送り手の受け手公開鍵要求内で指示された受け手の電子メールアドレスに割当てられる、（２）鍵サーバは所期の受け手がサービスに登録されていないことを示す適切な情報と共に一時的公開暗号化鍵Ｋｅｔを送り手へ返し、その暗号化鍵Ｋｅｔは受け手により発生されたのではなく自分のために発生されている。送り手にはトランザクションを続けるまたはキャンセルするオプションが与えられる。続ける場合、送り手は鍵（または、鍵フラグメント）格納要求を鍵サーバに送り鍵サーバは、いつものように、鍵検索情報Ｋｒで送り手に応答する。
【００９５】
鍵サーバに受け手の一時的鍵対を発生させる替わりに、送り手がそのコンピュータ上に常駐するクライアントソフトウェアを使用してそれを行うことができる。次に、送り手は一時的鍵対が対応する受け手の電子メールアドレスと共に一時的鍵対Ｋｅｔ，Ｋｄｔを鍵サーバに送ることができる。鍵サーバは一時的鍵対を保全して受け手がサービスに登録される時にそれを受け手に送信する。
【００９６】
付加機能として、非暗号化メッセージを受け手に送ってこの暗号化サービスの性質について受け手にアドバイスすることができる。この非暗号化メッセージは送り手から到来することができ、非登録受け手に対して、暗号化メッセージを自動的に含むことができる。非暗号化メッセージは受け手がクリックオンして登録プロセスを開始することができるリンクを含むことができる。あるいは、非暗号化メッセージは鍵サーバから電子メールの形で到来して、初回受け手に送り手から暗号化メッセージを受信することをアドバイスすることができ、また、メッセージを読むために初回受け手は鍵サーバ機関に関連付けられたウェブサイトにログオンしてユーザとして登録しなければならない。
【００９７】
受け手の視点から、非暗号化メッセージ（送り手または鍵サーバからの）はクライアントソフトウェアをダウンロードまたは入手できる適切な場所にコンタクトするよう受け手を指令する。受け手が登録プロセスを完了すると、送り手からの第１の受信メッセージの暗号化に使用された一時的鍵対（Ｋｅｔ，Ｋｄｔ）が受け手に送付され、受信メッセージの復号化が前記したように行われる。このようにして、前記した第１の実施例では、初期メッセージに対して一時的鍵対Ｋｅｔ，Ｋｄｔがダウンロードされ、初回受け手が送り手からＫｓｅ１を受信し鍵サーバからＫｓｅ２を検索した後でＫｓｅを復号するのに使用される。その後、受け手はユーザのコミュニティの会員となり将来暗号化メッセージを送受信するための新しい鍵対（Ｋｅ，Ｋｄ）を生成することができる。登録されたユーザは新たに発生された秘密復号化鍵Ｋｄの完全所有権を保持し、公開暗号化鍵Ｋｅがこのユーザに対する優先公開鍵として鍵サーバに提出される。
【００９８】
鍵サーバは一時的鍵対を再使用して受け手の一時的公開暗号化鍵Ｋｅｔをこの受け手がサービスに登録する前に同じ受け手に電子メールを送ろうとするサービスの他の登録されたユーザに提供して、それらが一時的公開鍵を受信していることを同時にそれらに知らせることができる。あるいは、受け手がまだ登録およびそれ自体の鍵を発生していない限り、異なる送り手が暗号化メッセージを同じ受け手に送りたい度に新しい一時的鍵対を生成することができる。しかしながら、この場合、受け手は最後にシステムに登録する時に、全ての受信暗号化メッセージを読むことができる前に、多数の鍵対をダウンロードしなければならない。
【００９９】
送り手および非登録受け手間の初期通信に対して対称鍵が暗号化されることがそれほど重要ではないより安全ではないシステムでは、鍵対の発生を全く省くことができる。対称鍵Ｋｓは前と同様にメッセージ暗号化に使用することができ、暗号化鍵Ｋｅや復号化鍵Ｋｄを使用することなく、全てが前と同様に進行する。このようにして、前記した第１の実施例では送り手がＫｓを生成し受け手は送り手からのＫｓ１および鍵サーバからのＫｓ２を得、第２の実施例では受け手は鍵サーバからＫｓを得、第３の実施例では鍵サーバがＫｓを発生する後で送り手は受け手にＫｓ１を送り鍵サーバは受け手にＫｓ２を提供する。これら全ての実施例において、受け手は鍵Ｋｓを得るのに何も復号する必要がない。
【０１００】
非登録受け手に送られた暗号化メッセージを処理する前記した方法は安全なメッセージを送る汎用方法としてそれ自体で使用することもできる。しかしながら、それは本発明の実施例で記述した方法ほど安全ではない。
【０１０１】
（ユーザ証明書）
単純なユーザ名およびパスワードの代りに、またはそれに加えて、本システムはユーザからの多様な証明書を受け入れる。このようにして、システムは登録中に多数の証明書（ＩＴＵ Ｘ.５０９証明書、電子メールアドレス、インスタントメッセージングＩＤ、クレジットカード番号、その他のコンタクト情報）を指定する機会をユーザに提供することができ、所望により、ユーザはこれらの証明書を後で変えることができる。証明書管理も提供される。このようにして、ユーザは定められた証明書の承認を要求した正確な時間およびその要求を中止した正確な時間を安全にタイムスタンプすることができる。次に、この情報を監査プロセスの一部として使用してユーザの証明書の信憑性をさらに確認することができる。さらに、ユーザは自分のローカル証明書（鍵対またはＩＴＵ Ｘ.５０９証明書）および設定をエクスポートし、次に別のマシン上で実行しているクライアントソフトウェア内にインポートすることができる。
【０１０２】
システムにより提供される証明サービスはユーザのより広いコミュニティが各ユーザのアイデンティティを信頼するコンテキストの一部である。ユーザの証明書への他のユーザによるアクセスはさまざまなポリシーおよびユーザの好みにより制御される。たとえば、会員の証明書のいくつかまたは全ての詳細を常に隠したり、コミュニティの特定の会員だけに明らかにしたり、全員に周知させることができる。
【０１０３】
会員が自分の証明書のいずれかを変更する時は、他の会員にはこの変更を変更時にプロアクティブにあるいは将来の他の時点に知らせることができる。たとえば、登録された受け手に予めメッセージを送っている送り手は、最後にメッセージを送って以来いつ受け手の（非一時的）鍵対が変更されているかを知らされる。それにより受け手はサービスから離れたが新しい会員が現在同じ電子メールアドレス内に存在している、あるいは受け手は変わっていないがセキュリティの理由から新しい鍵対を発生していることが会員に知らされる。このようにして、ユーザのコミュニティの会員に他の会員の証明書の変更を受動的または能動的に知らせることができる。さらに、会員は証明書がセキュリティのあるレベルよりも上または下であるもう一人の会員に対してメッセージを送信または受信する時にインタラクティブに警告されることを指定することができる。
【０１０４】
しかしながら、一般的に、会員は鍵署名（ＰＧＰの“Web of Trust”参照）またはeBay,Inc.オンラインオークションコミュニティにより使用される自己評価システム等のユーザがより好評を博すことのできる他のアクティビティ等のさまざまな手段を介してそれらの証明書の信憑性および強さを証明するのを許されるようにすることができる。また、コミュニティ会員には他の手段を介したユーザのアイデンティティのフィードバックを行うオプションを与えることもできる。
【０１０５】
好ましい実施例では、本システムは会員が他の会員から暗号化された電子メールを受信する時に他の会員の証明書の信憑性を証明するのを許すことができる。たとえば、送り手は受け手がメッセージを読んだ後で送り手のアイデンティティを特定的に証明することを要求するクライアントソフトウェア内のオプションを活性化させることができる。受け手には送り手のアイデンティティを受け入れる、それを拒絶する、あるいは要求を無視するオプションが与えられる。肯定的証明は送り手の評価を高めることができるが拒絶はそれを下げる。送り手の評価の高低は証明を行う受け手の評価によって決まることがある。
【０１０６】
たとえば、会員のアリスがユーザのコミュニティ内で自分の評価を高めたい場合、彼女は良い地位のもう一人の会員であるボブへのメッセージを作り上げることができる。メッセージを送る前に、アリスはボブに彼女のアイデンティティを証明させるオプションを活性化させる。アリスは彼女のＥＳＰ暗号化メッセージをボブに送る。ボブはメッセージを得、それを復号し、それを読む。彼はメッセージを閉じると、“アリスはあなたがこのメッセージの信憑性を証明することを要求している。このメッセージがアリスから到来していることを信じるならば、Ｙｅｓをクリックしてください。このメッセージはアリスからではないことにかなり確信があれば、Ｎｏをクリックしてください。応答したくなければ、無視をクリックしてください。”ことを彼にアドバイスするダイアログにより喚起される。クライアントソフトウェアはボブが“Ｙｅｓ”，“Ｎｏ”または“無視”をクリックすることをサーバに報告する。会員が“Ｙｅｓ”クリックを蓄積すると、証明に対する要求に応答する会員の評価によって決まることがあるあるルールに従って彼女の評価は高まる。会員が“Ｎｏ”を蓄積すると、鍵サーバ機関は会員のアカウントをより厳密に監視し、会員の証明書を調べ直し、会員とコンタクトして質問し、あるいはアカウントをディセーブルして過去の受け手に知らせることさえある。各会員に対するベースラインとしてデフオルト、フォーマルポリシーをインプリメントすることができるが、任意の定められた会員にどれだけアグレッシブに行われるかはケースバイケースベースで再検討することができる。
【０１０７】
さらなる機能として、会員は好ましくはスパムを報告することもできる。これは単純にスパムをフォワーディングするか、さらには“スパム警告ボタン”をクライアントソフトウェアに組み込むことにより、会員が詳細を提供できるウェブページを提供するような方策により行うことができる。この報告の目的は会員のアイデンティティに挑戦することではなく会員によるシステムの不適切な使用を報告することである。
【０１０８】
（鍵アクセスポリシー）
本システムは復号化鍵または鍵フラグメントへのアクセスを支配するポリシーが確立されるのを許すことができる。これらのポリシーは鍵サーバ機関または個別のコミュニティ会員が規定することができる。たとえば、コミュニティ会員は鍵（または、鍵フラグメント）を将来のある時間まで解放できない、または即座にあるいは将来のある時間に利用できなくなることを指定することができる。他のポリシーもとることができる。たとえば、これらのポリシーは送り手または受け手のアカウント履歴または現行のものアカウント状態、どちらかのパーティが鍵へアクセスしようとする方法、場所またはデバイスの側面、またはトランザクションを取り巻く他の要因に基づいて鍵を解放することができる。
【０１０９】
（鍵タイプ）
前記実施例で採用された鍵対（Ｋｅ，Ｋｄ）は、好ましくは、ＲＳＡアルゴリズム、楕円曲線アルゴリズム、El Gamalアルゴリズム、およびＤＳＡアルゴリズム等の非対称暗号化アルゴリズムを使用して生成される。前記実施例で採用された対称鍵Ｋｓは、好ましくは、ＡＥＳ，ＤＥＳ，３ＤＥＳ等の対称暗号化アルゴリズムを使用して生成される。これらは全て暗号学システムの当業者には既知である。
【０１１０】
前記したシステムでは、コミュニティの各会員が鍵の暗号化／復号化および署名の両方に使用される単一鍵対を有することができ、あるいは鍵の暗号化／復号化に使用される第１の対と署名に使用される第２の対との２つの鍵対を有することができる。
【０１１１】
メッセージの暗号化および復号については、対称暗号化／復号化鍵Ｋｓが使用されることが好ましい。当業者ならばご存知のように、対称鍵は明らかな計算効率の利点を有する。しかしながら、メッセージ暗号化鍵Ｋｍｅと対応するメッセージ復号化鍵Ｋｍｄの非対称鍵対をメッセージに対して使用することもできる。鍵サーバまたは送り手、または両方が協働して、非対称暗号化鍵対を発生することができる。このような場合、鍵サーバにより格納されかつ／または受け手に送られるのは復号化鍵Ｋｍｄの暗号化バージョンＫｍｄｅのＫｍｄｅ２部分（第１の実施例）、または復号化鍵Ｋｍｄの全体暗号化バージョンＫｍｄｅ（第２の実施例）または復号化鍵Ｋｍｄの非暗号化部分Ｋｍｄ２（第３の実施例）である。
【０１１２】
（通信プロトコル）
前記全ての実施例において、鍵サーバは好ましくはＴＬＳ １.０またはＳＳＬｖ３、または他の適切な暗号学的プロトコル等の暗号化された通信を使用して送り手および受け手と通信する。たとえば、恐らくはＸ.５０９証明書を使用する鍵サーバの公開暗号化鍵を使用して鍵サーバに安全に情報を送りながら（送り手または受け手により）完全ＳＳＬ−タイプインプリメンテーションを回避することができる。同様に、鍵サーバは既知の公開暗号化鍵を使用して鍵等の情報を送り手または受け手に送ることができる。
【０１１３】
（監査ログ）
前記した実施例では、鍵サーバはアクセスしているコンピュータおよびアクションに関与しているユーザを識別する（後者は恐らくは電子メールアドレスにより）十分なデータと共に鍵に関連する全てのトランザクション（発生、アーカイバル、アクセス）をログする。さらに、送り手および受け手の両方のマシン上のクライアントソフトウェアがそのマシンが鍵サーバとインタラクトする時は常に同様な情報をログして、ユーザがローカルに格納されたログと鍵サーバにより格納されたアクションのログとをクロスチェックできるように構成される。これらの監査証跡(audit trail)はマニュアルモード（ユーザがチェックを特定的に要求する）または自動モード（クライアントコンピュータおよび鍵サーバが特定のオペレータアクション無しで互いに話す）で調べて鍵対使用および誤使用の検出を助けることができ、配布後の定められた鍵対に関連付けられた機関を強化する。これらの追跡控えのユーザ検査の頻度および徹底度を測定してユーザの鍵対の信憑性およびセキュリティの付加証拠として使用することができる。さらに、鍵サーバおよびクライアントソフトウェアは監査ログ自体の全てまたは関連部に安全にタイムスタンプして任意のタンパリングを防止かつ検出することができる。
【０１１４】
例として、鍵サーバは暗号化鍵Ｋｅの送信、復号化鍵情報の格納、および受け手への復号化鍵情報の送出の一つ以上を反映するように第１の監査ログを更新することができる。同様に、送り手は暗号化鍵の要求および／または受信、格納するための鍵または鍵フラグメントの鍵サーバへの送出、鍵検索情報の受信、および受け手への暗号化メッセージ（および／または鍵検索情報）の送出等のアクションを反映するように第２の監査ログを更新することができる。続いて、マニュアルモードまたは自動モードで、送り手は自分が送ったメッセージに対応する第１の監査ログ内の鍵サーバにより発生されたエンティティを送り手により発生された第２の監査ログ内の対応するエンティティと比較することによりメッセージ追跡控えを検証することができる。
【０１１５】
ユーザは自分の監査ログを調べることができ監査可能情報は、電子メールで送る、認可されたビューアがウェブサイト上で情報にアクセスできるようにする、もう一つのアプリケーションを介して情報を提供する、自動検証のために情報を直接サーバからＭＵＡへ送る、または他のアプリケーション手段を介する等のいくつかの方法で通信することができる。
【０１１６】
本発明のいかなる実施例もメッセージを送受信するためにユーザにより使用されるデバイスに関連付けられた準一意的デバイス識別子を発生する。これらの一意的識別子は付加監査可能情報またはある時間中あるデバイスに対する鍵対使用を制約するポリシーの一部として使用することができる。
【０１１７】
ある好ましい実施例について本発明を説明してきたが、本発明はこれらに限定されないことを忘れてならない。そのバリエーションも本発明の範囲内に入り、その範囲は特許請求の範囲により示される。特許請求された発明を実施しても前記した利点および利益の全てまたはいずれかは必ずしも生じないことも忘れてならない。
【図面の簡単な説明】
【０１１８】
【図１】鍵サーバの支援による、ネットワークを介した送り手および受け手間の一般的な従来技術通信システムのアーキテクチュアを示す図である。
【図２】本発明の第１の実施例に従ったメッセージフローを示す図である。
【図３】本発明の第２の実施例に従ったメッセージフローを示す図である。
【図４】本発明の第３の実施例に従ったメッセージフローを示す図である。
【図５ａ】本発明の第１の実施例に従って送り手のアクションを説明するフロー図である。
【図５ｂ】本発明の第１の実施例に従って受け手のアクションを説明するフロー図である。
【図６ａ】本発明の第２の実施例に従って送り手のアクションを説明するフロー図である。
【図６ｂ】本発明の第２の実施例に従って受け手のアクションを説明するフロー図である。
【図７ａ】本発明の第３の実施例に従って送り手のアクションを説明するフロー図である。
【図７ｂ】本発明の第３の実施例に従って受け手のアクションを説明するフロー図である。
【図８】システムに登録したい新しい登録者に対する登録プロセスを示す図である。
【図１】
2005517348.tif 000003
【図２】
2005517348.tif 000004
【図３】
2005517348.tif 000005
【図４】
2005517348.tif 000006
【図５ａ】
2005517348.tif 000007
【図５ｂ】
2005517348.tif 000008
【図６ａ】
2005517348.tif 000009
【図６ｂ】
2005517348.tif 000010
【図７ａ】
2005517348.tif 000011
【図７ｂ】
2005517348.tif 000012
【図８】
2005517348.tif 000013
【国際調査報告】
2005517348.tif 000014