"コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵/秘密鍵ペアを有する招待者装置を追加する方法であって、a新規コラボレータ装置を前記グループに追加する権限と公開鍵/秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するステップと、b前記議長装置から前記招待者装置へ招待メッセージを送るステップであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含む、ステップと、c前記招待者装置から前記議長装置へ受諾メッセージを送るステップであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含む、ステップと、d前記議長装置から前記グループの全コラボレータ装置へ新規メンバーメッセージを送るステップであって、前記新規メンバーメッセージは新規のコラボレータ装置間鍵を含む、ステップと、e前記議長装置から前記招待者装置へグループデータメッセージを送るステップであって、前記グループデータメッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含む、ステップとを含むことを特徴とする方法。ステップbは第1のワンタイム鍵を生成し、前記第1のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第1のワンタイム鍵を暗号化し、前記暗号化された第1のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを含むことを特徴とする請求項1に記載の方法。ステップcは第2のワンタイム鍵を生成し、前記第2のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第2のワンタイム鍵を暗号化して、前記暗号化された第2のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを含むことを特徴とする請求項1に記載の方法。ステップeは第3のワンタイム鍵を生成し、前記第3のワンタイム鍵で前記グループデータ情報を暗号化し、前記招待者装置の公開鍵で前記第3のワンタイム鍵を暗号化して、前記暗号化された第3のワンタイム鍵と前記暗号化されたグループデータ情報を前記招待メッセージに含めることを含むことを特徴とする請求項1に記載の方法。前記招待メッセージは更にへッダと前記へッダのハッシュのデジタル署名と、前記招待ナンスと、前記第1のワンタイム鍵と、前記招待情報とを含むことを特徴とする請求項1に記載の方法。前記招待メッセージは前記議長装置の名前と、前記議長装置の公開署名確認鍵と、前記議長装置の公開鍵とを含む議長装置のデジタル証明書を更に含むことを特徴とする請求項1に記載の方法。前記受諾メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記議長装置の名前と、前記招待ナンスと、前記受諾ナンスと、前記第2のワンタイム鍵と、前記受諾情報とを含むことを特徴とする請求項1に記載の方法。前記受諾メッセージは前記招待者装置の名前と前記招待者装置の公開署名確認鍵と前記招待者装置の公開鍵とを含む招待者装置のデジタル証明書を更に含むことを特徴とする請求項1に記載の方法。ステップcは前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認を含むことを特徴とする請求項1に記載の方法。前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記議長装置による前記署名済み招待ナンスの再計算と、前記再計算した署名済み招待ナンスと前記受諾メッセージで受信した前記署名済み招待ナンスとのソフトウェアによる比較とを含むことを特徴とする請求項9に記載の方法。前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記受諾メッセージの中で前記議長装置により受信された前記署名済み招待ノンスを前記議長装置の手動操作による確認のため視覚的に表示することを含むことを特徴とする請求項9に記載の方法。コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵/秘密鍵ペアを有する招待者装置を追加するための装置であって、新規コラボレータ装置を前記グループに追加する権限と公開鍵/秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するメカニズムと、前記議長装置から前記招待者装置へ招待メッセージを送る議長プロトコルエンジンであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含むことを特徴とする議長プロトコルエンジンと、前記招待者装置から前記議長装置へ受諾メッセージを送る招待者プロトコルエンジンであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含むことを特徴とする招待者プロトコルエンジンと、前記議長装置から前記グループの全コラボレータ装置へ新規メンバーメッセージを送る議長デジタルメカニズムであって、前記新規メンバーメッセージは新規のコラボレータ装置間鍵を含むことを特徴とする議長デルタメカニズムと、前記議長装置から前記招待者装置へグループデータメッセージを送る議長加入メカニズムであって、前記グループデータメッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含むことを特徴とする議長加入メカニズムと、を含むことを特徴とする装置。前記議長プロトコルエンジンは第1のワンタイム鍵を生成し、前記第1のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第1のワンタイム鍵を暗号化し、前記暗号化された第1のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを特徴とする請求項12に記載の装置。前記招待者プロトコルエンジンは第2のワンタイム鍵を生成し、前記第2のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第2のワンタイム鍵を暗号化して、前記暗号化された第2のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを特徴とする請求項12に記載の装置。前記議長加入メカニズムは第3のワンタイム鍵を生成し、前記第3のワンタイム鍵で前記グループデータ情報を暗号化し、前記招待者装置の公開鍵で前記第3のワンタイム鍵を暗号化して、前記暗号化された第3のワンタイム鍵と前記暗号化されたグループデータ情報を前記招待メッセージに含めることを特徴とする請求項12に記載の装置。前記招待メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記招待ナンスと、前記第1のワンタイム鍵と、前記招待情報とを含むことを特徴とする請求項12に記載の装置。前記招待メッセージは更に前記議長装置の名前を含む議長装置のデジタル証明書と、前記議長装置の公開署名確認鍵と、前記議長装置の公開鍵とを含むことを特徴とする請求項12に記載の装置。前記受諾メッセージは更にへッダと、前記へッダのハッシュのデジタル署名と、前記議長装置の名前と、前記招待ナンスと、前記受諾ナンスと、前記第2のワンタイム鍵と、前記受諾情報とを含むことを特徴とする請求項12に記載の装置。前記受諾メッセージは前記招待者装置の名前と前記招待者装置の公開署名確認鍵と前記招待者装置の公開鍵とを含む招待者装置のデジタル証明書を更に含むことを特徴とする請求項12に記載の装置。前記議長プロトコルエンジンは前記受諾メッセージの中にあって前記議長装置により受信された前記署名済み招待ナンスの確認を行なうことを特徴とする請求項12に記載の装置。前記受諾メッセージで前記議長装置により受信された前記署名済み招待ナンスの確認は、前記議長装置による前記署名済み招待ナンスの再計算と、前記再計算した署名済み招待ナンスと前記受諾メッセージの中にあって受信した前記署名済み招待ナンスとのソフトウェアによる比較とを含むことを特徴とする請求項20に記載の装置。前記受諾メッセージの中にあって前記議長装置により受信された前記署名済み招待ナンスの確認は、前記受諾メッセージで前記議長装置により受信された前記署名済み招待ノンスを前記議長装置の手動操作による確認のため視覚的に表示することを含むことを特徴とする請求項20に記載の装置。コンピュータに、コラボレータ装置間の鍵で保護されたメッセージで通信するコラボレータ装置のグループに公開鍵/秘密鍵ペアを有する招待者装置を追加する方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記方法は、新規コラボレータ装置を前記グループに追加する権限と公開鍵/秘密鍵ペアを持った議長装置として前記コラボレータ装置の少なくとも一つを選択するステップと、前記議長装置から前記招待者装置へ招待メッセージを送るステップであって、前記招待メッセージは署名済み招待ナンスと、前記招待者装置の公開鍵で暗号化して前記議長装置の秘密鍵で署名した招待情報とを含む、ステップと、前記招待者装置から前記議長装置へ受諾メッセージを送るステップであって、前記受諾メッセージは前記署名済み招待ナンスと、署名済み受諾ナンスと、前記議長装置の公開鍵で暗号化した受諾情報とを含む、ステップと、前記議長装置から前記グループの全コラボレータ装置へ新規メンバーメッセージを送るステップであって、前記新規メンバーメッセージは新規のコラボレータ装置間鍵を含む、ステップと、前記議長装置から前記招待者装置へグループデータメッセージを送るステップであって、前記グループデータメッセージは署名済み受諾ナンスと前記招待者装置の公開鍵で保護されたグループ情報とを含む、ステップとを含むことを特徴とするコンピュータ読み取り可能な記録媒体。前記議長装置から前記招待者装置へ招待メッセージを送るステップは、第1のワンタイム鍵を生成し、前記第1のワンタイム鍵で前記招待情報を暗号化して、前記招待者装置の公開鍵で前記第1のワンタイム鍵を暗号化し、前記暗号化された第1のワンタイム鍵と前記暗号化された招待情報を前記招待メッセージに含めることを含むことを特徴とする請求項23に記載のコンピュータ読み取り可能な記録媒体。前記招待者装置から前記議長装置へ受諾メッセージを送るステップは、第2のワンタイム鍵を生成し、前記第2のワンタイム鍵で前記受諾情報を暗号化し、前記議長装置の公開鍵で前記第2のワンタイム鍵を暗号化して、前記暗号化された第2のワンタイム鍵と前記暗号化された受諾情報を前記受諾メッセージに含めることを含むことを特徴とする請求項23に記載のコンピュータ読み取り可能な記録媒体。前記議長装置から前記招待者装置へグループデータメッセージを送るステップは、第3のワンタイム鍵を生成し、前記第3のワンタイム鍵で前記グループデータ情報を暗号化し、前記招待者装置の公開鍵で前記第3のワンタイム鍵を暗号化して、前記暗号化された第3のワンタイム鍵と前記暗号化されたグループデータ情報を前記招待メッセージに含めることを含むことを特徴とする請求項23に記載のコンピュータ読み取り可能な記録媒体。図1は代表的なコンピュータシステム100の従来のシステムアーキテクチャを示したもので、これに開示された本発明を実装することができる。ただし図1の代表的なコンピュータシステムは説明目的のみで議論するもので本発明の制限と見なすべきではない。以下の説明では特定のコンピュータシステムを記述する際に共通に使用される術語を参照することがあるが、記載される概念は図1に図示したものとは異なるアーキテクチャを有するシステムを含めた他のコンピュータシステムに等しく適用される。コンピュータシステム100は従来のマイクロプロセッサを含む中央演算処理装置CPU105、一時的な情報記憶のためのランダムアクセスメモリRAM110、及び永久的情報記憶のためのリードオンリーメモリROMを含む。メモリコントローラ120はシステムRAM110を制御するために提供される。バスコントローラ125はバス130を制御するために設けてあり、割り込みコントローラ135は他のシステム要素からの各種割り込み信号を受信し処理するために使用される。大容量記憶はディスケット142、CDROM147、またはハードディスク152によって提供される。データとソフトウェアは取り出し可能な媒体例えばディスケット142やCDROM147を介してクライアントコンピュータ100と交換できる。ディスケット142はディスケットドライブ141へ挿入でき、このディスケットドライブ141はコントローラ140によってバス130へ接続されている。同様に、CDROM147はCDROMドライブ146へ挿入でき、CDROMドライブ146はコントローラ145によってバス130へ接続されている。最後に、ハードディスク152は固定ディスクドライブ151の一部であり、これはコントローラ150を介してバス130へ接続されている。コンピュータシステム100へのユーザ入力は様々な装置から提供される。例えば、キーボード156とマウス157はキーボード及びマウスコントローラ155によってバス130へ接続される。オーディオトランスデューサ196はマイクロホンとスピーカの両方として機能するもので、オーディオコントローラ197によってバス130へ接続されている。その他の入力装置例えばペン及び/またはタブレットや音声入力用マイクロホンなどがバス130と適当なコントローラを介してクライアントコンピュータ100へ接続できることは当業者には明らかであろう。DMAコントローラ160はシステムRAM110へのダイレクトメモリアクセスを実行するために提供される。視覚表示はビデオディスプレイ170を制御するビデオコントローラ165によって生成される。コンピュータシステム100はクライアントコンピュータ100をバス191経由でネットワーク195へ相互接続できるようにするネットワークアダプタ190も含む。ネットワーク195はローカルエリアネットワークLAN、広域ネットワークWAN、またはインターネットであり、多数のネットワークデバイスを相互接続する汎用通信回線を使用する。コンピュータシステム100は一般にオペレーティングシステムソフトウェアによって制御調節される。コンピュータシステム制御機能のなかでも、オペレーティングシステムはシステム資源の割り当てを制御しプロセスのスケジュール、メモリ管理、ネットワーク及びI/Oサービスなどのタスクを実行する。図2は略ブロック図の形で代表的なコラボレーションシステムの構成を示す。図2はネットワーク216へ接続された2台のコラボレーティブワークステーション200、202を示す。ワークステーション200、202のそれぞれは図1に示したようなコンピュータシステムとすることができ、ネットワーク216はプライベートコンピュータネットワーク例えばLANやWAN、あるいは公衆コンピュータネットワーク例えばインターネットとすることができる。これ以外に、ワークステーション200、202は同一のコンピュータ図示していない上に構成することができ、この場合2つの端末間の通信はそのコンピュータに対してローカルなものとなる。好適実施態様において、端末200、202のそれぞれは共同作業を実行するデータのローカルなコピー204、210をそれぞれ保持している。それぞれのローカルなデータコピー、例えばデータコピー204はこれに対応するダイナミクスマネージャ206と呼ばれるソフトウェアプログラムによって管理される。同様に、データコピー210はこれに対応するダイナミクスマネージャ212によって管理される。特定のコラボレーション装置を説明の目的で議論するが、他のコラボレーション装置も精神と範囲において本発明の原理から逸脱することなく使用できることが当業者には明らかであろう。ダイナミクスマネージャ206はデルタと呼ばれる一つまたはそれ以上のデータ変更要求を含む自己内包型データユニットの受信に応答してこれのローカルデータコピー204を変更し更新する。データ変更要求はデータの希望通の変更に関してダイナミクスマネージャやその他のコンポーネント図示していないへの通知または催促である。デルタは例えばマネージャ206などのダイナミクスマネージャによって、ユーザとの対話に応答して作成されるもので、対応するローカルデータコピー204と、ネットワーク越しに同じコラボレーティブセッションに参加しているコラボレータに属する他のコンピュータ上のローカルデータコピーとの両方を更新するために用いられる。デルタは制御情報を提供するへッダ部分と要求が関係するデータについての情報を提供するペイロード部分とを含む特定のフォーマットを有する。個々のデルタは一つまたはそれ以上のペイロードを有することができる。多数のペイロードが使用されるような場合、以下で詳細に説明するように、それぞれが独自の装置機能またはユーザの役割を有する特定のコラボレーションメンバーを対象とすることができる。ダイナミクスマネージャ206によって生成されたデルタが他のコラボレータに送信される場合、ダイナミクスマネージャ206は通信マネージャ208と相互作用する。同様に、ダイナミクスマネージャ212は通信マネージャ214と相互作用する。通信マネージャ208は内向きと外向きのデルタを適当な宛先へ配送するメカニズムである。好適実施態様において、通信マネージャはコンピュータで実行可能なプログラムとして実装することができ、このプログラムが別のリモートパーソナルコンピュータまたは別の形のネットワーク接続可能な装置へネットワーク216上で送信するため通信マネージャ206によって開始されたデルタを配送し、またネットワーク216上で受信したリモートで生成されたデルタをダイナミクスマネージャ206へ配送する。一般に、通信マネージャ208、214はダイナミクスマネージャ206、212によって生成された全デルタがコラボレーションに参加している全ユーザによって受信されるように構成される。それぞれのデルタは内部シーケンス番号を含みそれぞれのコラボレータのダイナミクスマネージャは全部のデルタがいつ受信されたかを決定できるようにしてある。別のコラボレータからのデルタはそれぞれのコラボレータへ多数の違う経路を通って送信されることがあるので、デルタは生成された順序と同じ順序で到着するとは限らない。しかし、それぞれのコラボレータによって全デルタが受信され内部シーケンス番号を使って正しい順序でデルタを適用できる。したがって、それぞれのコラボレータによって保持されているローカルデータコピーは、全部のデルタで更新されると、コラボレーションの他のメンバーによって保持されているローカルデータコピーと一致することになる。特定のコラボレーションに参加しているコラボレータの間での機密性を維持することが望ましい。これはデルタが公衆ネットワーク例えばインターネット上に送信される場合にとくに言えることである。情報のセキュリティにとって重要な3つの基本概念が存在する。その第1は認証で、これはデータ受信者がデータ作成者datasourceの同一性を知っており信用できることを保証するものである。第2は完全性で、データが転送中に変更されなかったことを保証するものである。完全性はデータ作成者以外のものによってデータを書き込むことができないことまた既知の作成者から到着したものであることを実効的に保証する。データ完全性は不正なデータの生成またはなりすましによる第三者からの攻撃を防止する。最後のセキュリティ概念は機密性で、これは転送中のデータがデータ作成者とデータ受信者以外の第三者によって読み取ることができないことを保証するものである。機密性は第三者によるデータの読み取りまたは盗聴による攻撃を防止する。前述したように、セキュリティはコラボレータが一つまたはそれ以上のアクティビティに参加して項目を共有したり、アクティビティの結果がユーザのパーソナルコンピュータ上にあるいは他の形のネットワーク接続可能な装置上に永続的に保存されるような仮想空間に基づいている。仮想空間はテレスペースまたはグループと呼ばれるもので各ユーザの装置の中で同期が保たれる。図示したセキュリティ/モデルによると、テレスペースのセキュリティは、テレスペースを形成して、メンバーを受け入れ、更にメンバーシップが安定したあとで全体のセキュリティとしてほとんどのユーザが体験するものである。これは安定状態デルタプロトコルと呼ばれグループメンバー間に渡されるデルタに含まれる情報の認証、完全性及び機密性に関連する。図3は5人のメンバーM0、M1、M2、M3、M4302~310からなるテレスペースまたはグループ例300の模式図である。各テレスペース300内には一つまたはそれ以上のトライブまたはサブグループが存在する。図3には、3人のメンバーM2、M3、M4306、308、310からなるトライブ312が図示してある。各メンバー302~310はその内部にプロトコルエンジンそれぞれエンジン303~311を有し、これは他のメンバーへセキュリティメッセージを送信しセキュリティ情報を操作するアプリケーションプログラムである。テレスペース300とトライブ312において情報は一つまたはそれ以上の鍵により保護される。これは、Kとして示してある暗号化鍵と、Lで示したメッセージ認証/完全性コードMAC鍵である。K及びL鍵は対称暗号化symmetriccipher用の従来の鍵でありテレスペース全体への広がりスコープを有する。本発明のシステムはブロック暗号化blockciphersとストリーム暗号化streamciphersの両方を用いることができるが、メッセージ間での状態は維持されない。つまり一つのメッセージから次のメッセージへセキュリティ暗号ストリーム状態を維持するためには通信しているエンドポイントが必要とされない。この方法では、一時的な通信の中断が発生した場合にも再同期が必要とされない。ブロック暗号化はカウンターモードにおいて使用する度に必ず新しく無作為生成される初期化ベクトルを使って使用される。初期化ベクトルは暗号のブロック長と等しい長さを有し従来の方法による典型的なへッダ攻撃を妨害thwartするために使用する。ストリーム暗号化はブロックモードにおいて初期ベクトルと鍵を組み合わせる、例えば排他的論理和演算により、ついですべてのメッセージで鍵文字列を再初期化することで使用される。この場合、初期ベクトルは鍵長と等しい長さを有する。初期ベクトルは一般に機密性保護されないしまたは認証/完全性の保護もされない。更にすべての鍵がなんらかの種類の陳腐化メカニズム例えばタイムアウトを関連させるか一定数のメッセージまたはバイト数を保護すると想定する。このメカニズムはテレスペースによって決定されるローカルポリシーの一種で以下で説明するいずれのプロトコルでも送信する必要はない。KG/LGで示したグループ鍵はそれぞれ暗号化/MAC鍵で、グループ300の全メンバーによって共有される。これらの鍵は第三者グループ外の者による攻撃からデルタに含まれる情報の機密性/完全性をそれぞれ保護するために使用される。同様に、KT/LTで示したトライブ鍵は暗号化/MAC鍵で、トライブ312の全メンバーによって共有される。これらの鍵はトライブ以外のグループメンバーや第三者による攻撃からデルタの機密性/完全性をそれぞれ保護するために使用される。更にK01/L01で示してある対になった鍵はメンバーM1とM2が共有しかつ他のグループメンバーの誰も共有していない暗号化/MAC鍵それぞれM0とM1で、M0とM1の間で双方向に通信を保護するために使用される双方向鍵である。これらの鍵はグループメンバーM2、M3、M4による攻撃からデルタの機密性/完全性をそれぞれ保護するために使用される。同様に対になった鍵Kij/Lijは別のメンバーの組み合わせMiとMjの間で交換される情報を他のグループメンバーによる攻撃から保護するために使用される。テレスペース内で安定状態セキュリティは5段階のレベルの一つに組み込まれることになるが、そのレベルはテレスペース300の作成者がテレスペースを作成する時点で選択できる。5レベルには何らの鍵も使用する必要がない低レベルセキュリティを含む。このレベルは全く暗号セキュリティを提供しない。次のレベルは1対の鍵KG/LGをグループの全メンバーに対して使用する中程度レベルのセキュリティである。このレベルでは、KG/LG鍵のうちのMAC鍵LGだけを使ってデルタを保護することにより認証/完全性が提供できる。同様に、認証/完全性及び機密性はKG/LG鍵の両方を使ってデルタを保護することで提供できる。次のレベルは高レベルのセキュリティで、グループ鍵KG/LGと鍵ペアKij/Lijの組み合わせを使用する。認証/完全性だけが要求される場合にはMAC鍵のペアLijだけを使用してデルタを保護し、グループ鍵KGは使用しない。これ以外に、認証/完全性/機密性が要求される場合にはグループ暗号化鍵KGとMAC鍵ペアLijを使用してデルタを保護する。中レベルと高レベルのセキュリティレベル双方で、暗号化鍵KijとMAC鍵Lijのペアを使用してグループ鍵またはトライブ鍵KG/LGまたはKT/LTの再キーイングを行なう。以上のレベルやモードはグループテレスペース全体に適用可能であり、また全トライブサブグループにも同様に適用可能である。テレスペース内のトライブ全部がテレスペース自体と同一の全体的セキュリティを有するので、グループに対して前述したレベルやモードは、前記のグループ鍵KG/LGをトライブ鍵KT/LTで置き換えればトライブに適用できる。図4はグループメンバー間に情報を転送するのに使用するデルタの内容を示す。各デルタはメッセージへッダ400からなり、これにはセキュリティシステムの特定の実装に依存する情報を含む。この情報にはプロトコルのバージョン番号を含められるので、ここにコラボレーションシステムとセキュリティサブシステム両方のバージョン番号を含められる。メッセージへッダ400はメッセージフラグ種別またはタグIDも含み、これはメッセージの種類が異なるごとに異なる識別子である。メッセージへッダに含めることができる他の情報としては、構造化シーケンス番号がある。この番号はテレスペースのスコープを有する部分順列シーケンス番号で、そのスコープ内でメッセージの送信者とメッセージそれ自体の特定インスタンスとを論理的に同定する。へッダ400は機密を保護することができないが要求されるセキュリティレベルによっては実際にグループメンバー間に送出されるペイロードまたは情報を含むアプリケーションデータ402と全く同様に認証/完全性を保護する必要がある場合がある。例えば図4に図示してあるようなデルタが符号化される方法は希望するセキュリティレベルによって変化する。例えば、暗号としての意味でセキュリティを何も保証しない低レベルセキュリティモードでは、デルタは図4に図示したように送信され、へッダ情報400がペイロード402よりも先に送信されるのが望ましいが、へッダとペイロードの順序は本発明の動作にとって重要ではない。この場合、第三者非グループメンバーがデルタ情報402を読み取るまたは盗聴でき、またデルタを書き込んだり真似たり、またはなりすますことができる。前述の認証/完全性モードで動作する中レベルセキュリティシステムの場合、デルタ情報は図5に図示したように保護される。更に詳しく説明すると、それぞれのデルタについて、へッダ情報500が送信され、それに続けて鍵バージョン番号502、平文データ504、更に認証子506が送信される。ここでもこれらの要素の順序は重要ではない。認証子はデータ504の認証/完全性を保護しグループメンバーによって送信されたメッセージであることを保証するMACコード506とすることができるが、これはグループ認証鍵LGを知っているのはグループのメンバーだけだからである。別の実施態様において、メッセージ認証子として公開鍵署名認証子を使用することもできる。この場合、メッセージ認証子506はハッシュして連結したへッダ及びデータの公開鍵署名で構成する。好適実施態様において、鍵バージョン番号は2つの部分を有しており、これは鍵識別子KeyIdentifierと呼ばれるテレスペース全体で使われる独自の文字列と、鍵バージョンKeyVersionと呼ばれるインクリメンタルなシーケンス番号である。鍵識別子はテレスペースの別のメンバーが独自に生成する鍵同士を識別するために必要とされる。一方のメンバーが、他方のメンバーも新しい鍵を生成していることについて知らないので、鍵識別子は鍵を個別に識別できるようにする。鍵バージョンは古い鍵、現在の鍵、新しい鍵を識別するために必要とされる。安定状態では、メンバーは鍵識別子の値は異なるが鍵バージョンの値が同じ一組の鍵を使用することになる。メンバーは現在の鍵バージョンの値よりも鍵バージョンの値が小さい古い鍵を削除することができる。好適な実装において、MACコード506は、最初にデータ504と連結したへッダ500をハッシュし、次にハッシュの結果を従来のメッセージ認証アルゴリズムに沿って保護する。中間ハッシュ関数を使用して後述するような高セキュリティバージョンに沿った方法でMACコードを作成する。また従来のMACアルゴリズムを使用してグループ認証キーLGで単純にへッダとデータを保護すれば、中間ハッシュ関数を使用せずにこのモードを実装することも可能である。前述のように、認証/完全性モードにおいて動作する中レベルのセキュリティシステムは、第三者が読んだり盗聴できるがグループメンバーだけが他のグループメンバーのデルタに書き込み、真似impersonateまたは成りすましspoofできるようなセキュリティシステムを作成する。認証/完全性/機密性モードで動作する中レベルのセキュリティシステムは図6に図示してあるようにデルタのデータを保護する。更に詳しく説明すれば、デルタは鍵バージョン番号602及び初期ベクトル603の付いたへッダを、データ604及びメッセージ認証コード606とともに送信することで伝達される。しかし、この場合、データ604は暗号化されている。このプロトコルはグループ暗号化鍵KGで暗号化することでデルタデータの機密性を保護しておりグループ認証子606による完全性と認証の保護が継続する。データ604は従来の暗号化アルゴリズムを用いてグループ暗号化鍵KGで暗号化され、暗号化されたデータは初期ベクトルと連結される。ここでも認証またはMACコードは好適実施態様においてへッダと平文データの連結をハッシュ化してからグループ認証鍵LGでハッシュ情報を符号化することにより形成されている。またデータとへッダ及びデータのハッシュの連結をひとつの暗号化キーKGで暗号化してからその結果をへッダ、鍵バージョン番号、初期ベクトルと連結することでこのモードを実装することも可能である。後者の暗号化は機密性と認証/完全性を両方とも保証し、2つの鍵KGとLGの間で機密性及び認証完全性の責任を分担する別々のMAC部分を使用しなくてすむ。図6に図示した実装を実際に使用して後述する高セキュリティモードに沿った実装を行なうことができる。認証/完全性モードで動作する高レベルセキュリティシステムにおいてデルタデータは図5に図示した構成または図7に図示した構成のどちらかを用いて保護できる。このシステムで使用されるプロトコルは平文デルタ情報を送信するが、認証/完全性を保証するため、シングルターゲットの秘密鍵多重認証子か公開鍵署名認証子のいずれかを使用する。シングルターゲット秘密鍵多重認証子の場合、図5に図示した構成を使用する。更に詳しく説明すれば、へッダ情報500は鍵バージョン502、暗号化していないデータ504、メッセージ認証子506とともに送信される。しかし、この場合、鍵バージョン番号502は送信者と受信者全部との間の鍵バージョンのすべてを連結したもので構成する。同様に、メッセージ認証子506は送信者とそれぞれの受信者との間の個別のメッセージ認証子を連結したもので構成する。それぞれのメッセージ認証子は認証鍵で保護されるが、この認証鍵は送信者と受信者との間でのみ使用されるものであるLij鍵の一つ。更に、好適実施態様では、中間ハッシュをメッセージ認証コードに使用する。更に詳しく説明すると、へッダとデータは連結され、ハッシュされ、更に適当な認証鍵によって保護される。この場合、中間ハッシュは認証鍵それぞれに対してへッダとデルタ全体を再ハッシュするのを避けるために使用している。へッダとデルタをハッシュしたら、適当な認証鍵でハッシュした情報を単純に保護することでこのハッシュを複数回使用できる。別の実施態様では、公開鍵署名認証子をメッセージ認証コードとして使用する。この構成が図7に図示してある。この構成では、へッダ情報700が最初に送信され、これに暗号化されていないA/Iモードまたは暗号化されたA/I/Cモードデータ702が続く。メッセージ認証子コード704はハッシュし連結したへッダとデータの公開鍵署名から構成される。認証/完全性/機密性モードで動作する高レベルセキュリティシステムは図6と図7に図示したデルタ構成でデータを保護する。基本的にこれは図5と図7に図示してある認証/完全性モードと同じであるが、グループ暗号化鍵KGでデルタデータが暗号化され図6の場合の初期ベクトルと連結される点で異なっている。デジタル署名またはデジタル証明書を生成して使用するメカニズムが図8に図示してある。データ800のデジタル署名を生成するためには、多数の一般的に周知のハッシュアルゴリズムの一つを用いて、ステップ802に示してあるようにデータ800のハッシュ値を計算する。ハッシュしたデータはステップ804に示したように暗号化と同様の演算で公開鍵/秘密鍵ペアのうちの秘密鍵を用いて署名される。その結果がデジタル署名806である。更に、データがユーザのIDまたは公開鍵に関係する場合、署名ではなくデータはデジタル証明書と呼ばれる。デジタル署名を使用するには、図8で破線より下に示してあるように有効化手順を実行する。更に詳しく説明すると、ハッシュしたデータの確認復号に似た動作のために公開鍵/秘密鍵ペアのうちの公開鍵を使用する署名確認アルゴリズム814へ、デジタル署名が矢印812で示したように提供され、また証明書が矢印818で示したように提供される。データ800それ自体は矢印808で示したようにハッシュアルゴリズム810へ提供される。このハッシュアルゴリズムはデジタル署名を生成するために使用したハッシュアルゴリズム802と同一のものである。囲み816に示したように、データの再ハッシュが確認したハッシュデータと比較される。結果が同一であれば、確認したハッシュデータは正しい、すなわちデータは正しくauthentically署名に関連している。機密グループを形成する手順が模式的に図9に図示してありそのステップが図10に図示してある。図9に図示してあるように、グループ900は議長902とその他のN-1人のメンバーで構成され、そのうち3人がメンバー906、908、910として示してある。グループ900の形成は議長902によって管理され、議長は新しいメンバーを招待して追加する権限を与えられたメンバーである。図示した手順によれば、招待者904は初期認証の後でグループ900へ追加される。以下の議論では認証及び完全性による最高セキュリティモードに焦点を当てて説明する。その他の意図されるモードはこのモードから派生させることができる。加入手順はステップ1000から始まりステップ1002に進む。ステップ1002では、議長902が招待されることになる人904へ招待メッセージを送信する。このメッセージは図9の矢印912で模式的に示してある。このメッセージの内容は図11に示してある。メッセージはへッダ1100と、これに続く招待者の名前1102から構成され、この名前はURLやその他の識別情報とすることができる。へッダの順序は本発明の原理から逸脱することなく反転できる。招待者の名前に続くのが署名済み招待ナンスnonce1104である。署名済みナンスは議長によって生成されたタイムスタンプのハッシュ、議長902の名前/URL、招待者904の証明書入手可能な場合、テレスペースの名前/URL、署名つきナンスが発生することが考えられる別の状況を識別するために使用されるタグである招待オプコードOpcodeを含む署名データである。一般的に言って、ナンスはプリンシパルAが生成してプリンシパルBへ送信するもので時間とともに変化するパラメータであり、これは任意の状況で一回だけ使用されるものである例えば、本明細書で説明している招待プロトコルを介してAがBを招待する場合など。実際に、ナンスは状況を定義する、言い換えればプロトコル動作の同時性を保証して再生replay及びインターリーブ攻撃interleavingattackを防止するために使用される。ナンスは秘密にしなくても良く、1回限りの独自なものであれば良い。各種システムで使用されるナンスの典型的な例としては次のようなものがあげられる:衝突しない乱数、タイムスタンプ十分に信頼できるクロックを備えたシステム、特に信頼できる分散時刻同期プロトコルの存在下ではほぼ理想的である、シーケンス番号。好適実施態様ではタイムスタンプが使用されている。本明細書の状況で重要なことは、プロトコルの実行の全部において、ナンスが暗号学的な確実性の範囲で絶対にローカルポリシーで決定されるなんらかの時間的制約の中で反復できないことである。これは例えば自分が発行したナンス/招待をプロトコルの実行に関する他の情報とともに、不揮発記憶に、ローカルクロックに合わせてある程度の期間ローカルポリシーによって変化する、メンバーが記憶しておくことで実現可能で、この時刻以降はナンス情報を破棄してプロトコルの実行を中断させなければならない。署名つきナンス1104に続くのは暗号データ1106で、これはこのメッセージで使用されるセキュリティ状態情報である。この情報は議長が選択し受信者がメッセージを正しく解釈できるようにするために必要である。更に詳しくは後述するようなワンタイム鍵で情報を暗号化するのに使用したアルゴリズムの名称の文字列を含む。またメッセージ受信者がメッセージを処理するのに必要なその他なんらかの情報、例えば鍵の長さ、ラウンド数、使用したハッシュアルゴリズムの名称、鍵ジェネレータアルゴリズムの名称、なども含む。暗号データ1106に続くのは、公開鍵暗号化アルゴリズムに基づいてあらかじめなんらかの合意が得られている招待者の公開鍵で暗号化したワンタイム鍵情報1108である。ワンタイム鍵は対称暗号化用の鍵で後述するように招待情報を暗号化するために一回だけ使用される。鍵情報に続くのが招待情報1110で、これはワンタイム鍵で暗号化されている。招待情報も前述したように議長によって生成されたタイムスタンプを含み初期ベクトルと連結できる。招待情報はテレスペース名/URLを含むアプリケーションデータで招待者904に招待を発行したアクティビティの種類について通知する。これは特に、議長902によって権限を委譲mandatedされたものとしてテレスペース内で使用しなければならない暗号情報例えば前述の低/中/高レベル、A/I/Cモードを含む。このようにすると、招待者には参加するように招待されているテレスペースのセキュリティ特性が招待者に通知され、例えば招待者は参加しないと決定することができる。招待者の証明書が不明な場合、暗号化したワンタイム鍵1108を無視しタイムスタンプと招待情報1110を暗号化しないで送信する。招待情報1110に続くのはへッダ情報1100、招待ナンス1104、暗号化していないワンタイム鍵メッセージに含まれる場合、暗号データ1106、暗号化していない招待情報タイムスタンプなしのハッシュに対する議長の署名である。この署名は議長の証明書に対して示された情報の全部を結合するもので、議長の証明書は招待者のローカルな公開鍵証明書有効化ポリシーを介して議長に結び付けられている。送信される情報の最後の部分1114は議長の証明書で、議長の名称URL/ペルソナ、議長の公開署名確認鍵、及びその他の情報例えば公開鍵アルゴリズム識別子、暗号化公開鍵、などが含まれ、これらすべてが一つまたはそれ以上のなんらかの信頼できる認証局の署名を介して相互に結合されている。証明書は周知のまたは少なくとも招待者に識別可能ななんらかの証明書フォーマットにフォーマットされる。このフォーマットは公開鍵による証明書ここで証明書認証局は周知の認証局の階層の内部に組み込まれている、またはPGPやSDSIなどを使用した信頼の輪証明書web-of-trustcertificate、あるいは更に単純にこの目的のためだけにその場で構成した自己署名証明書であっても良い。招待者が証明書を頼れる信頼度は招待者のローカル公開鍵証明書有効化ポリシーに依存する。このメッセージを受信すると、招待者は図15に図示してあるフローチャートに概略してあるステップをとる。招待者の手順はステップ1500から始まってステップ1502へと進み、ここで招待者が暗号データ1106を調べてメッセージの暗号化に使用されているアルゴリズムを知る。次にステップ1504で、招待者は招待者の名前を検証してその招待が招待者に向けられたものかどうかを確認する。次に、ステップ1506で、招待者が招待者のローカルな公開鍵有効化ポリシーに従って議長の名前/URLを含む議長の証明書を有効化する。招待者は適当な証明書有効化プロバイダ招待者のローカルポリシーになっている場合にはtrivial/初期設定で自己署名証明書をすべて信頼する有効化アルゴリズムが実装することがあるを起動することにより行なう。ステップ1508で、招待者は議長の署名を確認してこの招待が本当に議長902から来たものかどうかを確かめ招待者904が本当に招待されたのかを確かめる。最後にステップ1510で、招待者は招待情報を復号して検証し招待者が議長の招待を受け入れたいかどうかを決定する。そして手順はステップ1512で終了する。図10に戻ると、招待者904が招待を受け入れることに決定した場合、ステップ1004で招待者904は議長902へ受諾メッセージを送信して応答する。このメッセージが図9では矢印914として模式的に図示してある。これ以外に、招待者が招待を受け入れないと決定した場合、エラーメッセージを招待者904から議長902へ送信する。受諾メッセージの内容が図12に図示してある。メッセージはへッダ1200と、これに続く署名付きの招待ナンス1202で構成され、ナンスは招待メッセージで議長から招待者へ送信されたものである。これを用いることで、議長はこの受諾メッセージが招待に応答したものであると認識できることになる。署名付きナンス1202には署名つき受諾ナンス1204が続く。署名付き受諾ナンスは招待者が生成したタイムスタンプ、招待者904の名前/URL、議長902の証明書、テレスペースの名前/URL、そして受諾オプコードを含む。ナンス1204には暗号データ1106と同様のセキュリティ内容暗号データ1206が続く。次に、公開鍵暗号化メカニズムを使用して、新しく生成したワンタイム鍵1208の公開鍵暗号を送信し、パラメータ、情報、公開鍵暗号化鍵が議長902から招待者904へ送信される例えば公開RSA暗号鍵。暗号化ワンタイム鍵1208に続くのはアプリケーションデータ1210で、これにはワンタイム鍵を使用して暗号化した2個のタイムスタンプと受諾データを含む。この情報1210は招待者904の受諾について議長902に通知するものである。次に、招待者904の署名を送信する。この署名はへッダ情報1200、議長の名前と招待者のナンス1202に受諾ナンス1204を連結したもの、暗号化していないワンタイム鍵、暗号データ1206と暗号化していない受諾情報タイムスタンプなしのハッシュによる。この署名は招待者の証明書にすべての示された情報を結合する証明書は更に議長の証明書公開鍵有効化ポリシーを介して招待者904に結合されている。議長902の名前がこの署名のスコープ内に含まれ招待者が署名した、議長には分かっているワンタイム鍵を議長が第三者へ送信するのを防止し、これにより招待者904を真似なければならないことに注意する。最後に、招待者の証明書1214を送信する。このメッセージの受信時に、議長902は図16のフローチャートに示してある手順を実行する。この手順はステップ1600から始まりステップ1602に進み、ここで議長902が暗号化されたワンタイム鍵を復号し、これにより鍵を取り込む。次に、ステップ1604で、議長902はワンタイム鍵を使って暗号化された受諾情報を復号する。次にステップ1606で、議長は招待者の証明書を検証して招待者の名前を取り出す。ステップ1608で、議長902は招待ナンスを再計算して再計算したナンスと受信した招待ナンスとを調べ受諾メッセージが応答している招待がどれかを決定する。本発明の一つの態様によれば招待ナンス図11の1104はステートレスつまり関連するタイミングとは無関係に解釈できることに注意する。例えば、メンバーAが装置1から招待者Bへ招待を発行したが後にBの受諾を装置2で受信したと仮定する。オリジナルの招待メッセージではナンスがデルタ経由でAの使用可能な全装置へ送信されたとしても、招待者Bからの受諾メッセージは招待ナンスを伝達するデルタより先に装置2に到着することがあり装置2でのソフトウェアによる比較ができない場合がある。この問題を回避するため、ナンスに関連した情報は装置2を含めた当該メンバーの装置の全部で視覚的に表示される。この表示の一例が図23に示してあり表示は例えばユーザインタフェースダイアログボックス2300経由で、またはその他の類似のメカニズムを介して行なわれる。図23に図示してあるように、3項目の情報がダイアログボックス2300に表示される。これは、招待者Bの題名2302、招待者Bの証明書のメッセージダイジェスト2304、及び招待メッセージ署名ナンス2305からのタイムスタンプである。送信者の証明書は重要な2項目の情報を伝達するパッケージである:これはメッセージ送信者の題名と送信者の公開鍵である。この場合、Bの題名は装置2のプロトコルエンジンによって抽出されダイアログボックス2300のテキストボックス2302に表示されている。この名前の一例としては、wtuvellgroove.netがある。Aはこれで受諾メッセージが招待に対応することを確認できる。受諾を有効化するためには、Aはすでに招待者Bの対象者名を知っているので、Aは本発明のコラボレーションシステムとは別の経路から認証のメッセージダイジェストを受け取る必要がある。例えば、この情報を受け取る代表的な方法はAがBを電話で呼び出して証明書のメッセージダイジェストがどのようなものなのかを尋ねることである。例えば、この計算したメッセージダイジェストは0a,1b,2c,3d;4e,5f,6a,7b;8c,9d,ae,cf;c1,d2,e3,f4;05,16,27,38;49,5a,6b,7cといったようなものになる。Aが受諾メッセージを介してBの証明書を受け取ったら、メッセージダイジェストまたは証明書のフィンガープリントを、受諾メッセージのBの証明書1214から、従来のメッセージダイジェストアルゴリズム例えばMD5やSHA1などを用いて図21と図22に図示してあるセキュリティサービスアーキテクチャにより、アルゴリズム的に計算する。この再計算したメッセージダイジェストがボックス2304に表示される。再計算したメッセージダイジェストがすでに分かっている正しいメッセージダイジェストと一致すれば、Aは提示された証明書が正しいものであるとして受け入れることができる。それ以外の場合には破棄される。この操作は証明書有効化と呼ばれる。署名付きナンスはメッセージの署名である。従って、メッセージのタイムスタンプと送信者の証明書を含む情報を互いに結び付ける。再生攻撃を避けるためにはすでに送信された正しいメッセージを再送することによる攻撃、受諾メッセージに含まれている招待ナンス1202のタイムスタンプが受け入れ可能な範囲内にあることを確認することも必要である。タイムスタンプ情報はナンスから抽出されてダイアログボックス2300のボックス2305に表示される。この情報は、例えば、20000407121124Zにあるnashtgirigroove.netあての招待メッセージといったものである。Aは幾らか早い時刻にタイムスタンプを生成したのであるから、おそらくAはその時刻を知っている。メンバーAはタイムスタンプを解釈して情報が受け入れられるものかどうかを決定できる。メンバーAが情報を受け入れる場合には、OKボタン2306をクリックし、そうではないなら中止ボタン2308をクリックする。同様の問題は招待者Bが受諾を送信した装置とは別の装置でテレスペースデータを受け取った場合にも発生する。この後者の問題は同じ方法で処理される。次に、ステップ1610で、議長902は議長のローカル公開鍵ポリシーにしたがって招待者の証明書を有効化する。議長がすでに招待者の証明書を先の招待メッセージの時点で持っているならこのステップは省略しても良く、その時点で行なった有効化に満足している。議長は適当な証明書有効化プロバイダを起動することによりこの有効化を行なう。次に、ステップ1612で、議長902は招待者の署名を確認し、招待者の署名は更に受諾メッセージの認証/完全性を確認し、この受諾が本当に招待者904から来たものであることを確かめる。次に、ステップ1614で、議長は復号した受諾情報を検証して招待情報と一致することを確認し、議長が招待者の受諾を認めたいかどうかを決定する。最後に、ステップ1616で、オプションで追加の署名として議長は自分自身の署名を招待者の証明書に追加することができる。この追加署名によってポリシーが有効になるのでグループメンバーは議長902の証明書を信頼している限り招待者の証明書を有効化できる。手順はステップ1618で終了し、情報が真正なものなら招待者はこれ以後テレスペースのメンバーとなる。図10に戻って、ステップ1006に記載してあるように、議長902が新規メンバー追加デルタをグループ900に存在する全メンバーに送信する。これらの新規メンバーメッセージは図9で矢印916、918、920として模式的に示してある。議長が他のそれまでに存在しているメンバーへ送信する新規メンバー追加メッセージの内容が図13に示してある。デルタメッセージはへッダ1300と、これに続けて統合鍵バージョン番号情報を含み、鍵バージョン情報はグループ鍵とすべての認証/完全性の鍵についての全部の鍵バージョン番号を連結したものである。統合鍵バージョン1302には、暗号化した新規グループ暗号鍵及び認証鍵の連結からなる再キーイング情報1304が続く。それぞれのメンバー対に対して、グループ暗号鍵及び認証鍵を連結したものがメンバー同士で対になった鍵を使って暗号化され、結果が初期ベクトルと連結される。これらの連結された鍵が更に連結されて統合再キーイング情報1304を形成する。新しいキーは古い/現在のグループ鍵KG/LGを置き換える。新規に追加されたメンバーは古い/現在のグループ鍵を知ることはない。この再キーイングは新規メンバーがそれ以前のテレスペース通信を記録したり読み取れないようにするために必要である。次に、新規グループ暗号鍵で暗号化し初期ベクトル1306と連結した参加情報を送信する。このデルタの内容は、招待者の名前に招待者の証明書と参加情報を連結したものである。参加情報は議長902が生成したアプリケーションデータで、他のグループメンバーが、メンバーマネージャ情報を含めて、知る必要のある新規メンバーについての情報に関連する。またテレスペースのメンバーやその他各種情報例えば招待者の役割などのリストを含めることができる。最後に、メッセージ多重認証コード1308を送信する。これは議長と各メンバーの間の認証子を連結したものとすることができる。各認証子は議長からメンバーへのペアになった認証鍵L0jで保護されているハッシュ情報である。ハッシュ情報はへッダ1300と、統合新規グループ鍵情報1304と、暗号化していないデルタ情報を含む。これ以外に、メッセージ認証コードは前述のハッシュ情報の議長署名とすることができる。図13に示したメッセージを受け取ると、各メンバー906~910は図17のフローチャートに示してあるステップを実行する。この手順はステップ1700で始まりステップ1702へ進み、ここでメンバーが暗号化されたグループ鍵を復号し、これによって新しいグループ鍵KG/LGを知る。しかし、各メンバーは、KG/LGで保護された古いデータが存在しないことを確認するのに必要とされる限り、古い/現在のグループ鍵KG/LGの知識を保持している必要がある。その後、各メンバーは古い鍵KG/LGを破棄しその痕跡をすべて抹消する。次に、ステップ1704で、暗号化されたデルタ情報を各メンバーが復号し、これによってデルタ内の情報を知る。ステップ1706では、メンバーが認証鍵で暗号化された多重認証子の項目を介して、メッセージの認証/完全性を確認する。次に、ステップ1708で、メンバーは議長902が議長のIDはへッダ情報として送信される議長であること、また新規メンバーを追加する権限があることを確かめる。ステップ1710では、メンバーがデルタ情報を実行する。これを行なう最中に、メンバーは招待者の名前、証明書、参加情報を含めた新規メンバーマネージャ情報に気づく。手順はステップ1712で終了する。最後に、図10に戻って、ステップ1008で、矢印922で模式的に示したように、議長902が招待者904へテレスペース情報を送信する。手順はステップ1010で終了する。テレスペース情報は図14に示したメッセージとともに招待者904へ送信される。この情報はへッダ1400で始まり、ノンス1204と同一の署名つき受諾ナンスが続く。これに、図12に示した受諾メッセージに関連して説明したように暗号データ1404と暗号化したワンタイム鍵これは新規に生成する1406が続く。暗号化したワンタイム鍵1406のあとには直前のメッセージ部分にあるワンタイム鍵で暗号化されたテレスペースTSPデータが続く。このデータはワンタイム鍵で暗号化したペイロードと連結された初期ベクトルを含む。ペイロードは招待者が生成したタイムスタンプと連結グループ暗号及び認証鍵KG/LG、及びTSPデータである。TSPデータは招待者がメンバーから受信を許可されているTSPデータのメンバーによるバージョンを含むアプリケーションデータである。暗号化されたTSPデータ1408には、へッダ1400、招待者の名前、署名付きナンス1402、連結グループ暗号及び認証鍵、暗号化していないワンタイム鍵、暗号情報1404、暗号化していないTSPデータを含むハッシュ情報に対する議長の署名1410が続く。最後に、議長の証明書1412が後続する。このメッセージを受信すると、招待者904は図18に示した手順を実行し、手順はステップ1800で始まりステップ1802へ進みここで招待者904は暗号化された1回限りの鍵以下、ワンタイム鍵を復号してワンタイム鍵を取り出す。次に、ステップ1804で、招待者はワンタイム鍵を使用して暗号化されたTSPデータを復号し、TSP情報を取り出す。次に、ステップ1806で、招待者904は署名つき受諾ナンスを再計算してこれと受信したナンスとを比較してこれが受け入れられるものであることを確認する。先に説明したように、この比較はソフトウェアでまたは視覚的検査によって行なうことができる。このノンスは議長の証明書を含んでいるので、招待者はこの証明書を再有効化する必要がない。ステップ1806では、招待者904が議長の署名を検証し、ステップ1808では、招待者が復号したTSPデータを初期の作成中テレスペースに広める。唯一残っている、なすべきことはテレスペースの他のすべてのメンバーと鍵ペアを交換することで、そのあと、招待者はテレスペースの完全なメンバーとなる。鍵ペアは再キーイング手順で交換でき、ここで再キーイング情報は他の情報を搬送するデルタにピギーバック相乗りする形になる。この再キーイングを実行するための一つのプロトコルは図13に示した新規メンバー追加デルタメッセージで前述した。再キーイング情報は他のデルタメッセージに挿入することもできる。このようなピギーバック型デルタメッセージは通常のデルタメッセージだが、鍵変更グループ/テレスペース鍵KG/LG、トライブ/サブグループ鍵トライブT1、TnについてKT1/LT1、KTn/LTn及び/または鍵ペアKij/Lijのあらゆる組み合わせに同時に関係するがデルタメッセージにピギーバックする点で異なっている。デルタそれ自体は同時にトライブTkに適した新しい鍵で暗号化される。新しい再キーイングされた鍵はこのメッセージで搬送される。鍵ペアがメッセージにピギーバックしている場合、メッセージは公開鍵署名認証子によって保護される。それ以外の場合では、メッセージは現在の鍵ペアを用いる多重認証コードによって保護される。このようなメッセージの一例が図19に示してある。デルタメッセージはへッダ1900と、これに続く統合鍵バージョン情報1902を含み、統合鍵バージョン情報は新規グループ鍵とすべての新規トライブ認証/完全性鍵についてのすべての鍵バージョン番号の連結である。統合鍵バージョン情報1902には第2のセクション1904が続き、これも統合鍵バージョン情報を含む。鍵ペア変更が送信中の場合、この情報は新しい鍵ペアについてのすべての鍵バージョン番号の連結を含む。別の場合は、グループ鍵とトライブ鍵を再キーイングしている場合情報1904は古いまたは現在の鍵ペアについての統合鍵バージョン情報を含む。統合鍵バージョン1904に続くのが統合再キーイング情報1906で、これは新しいグループ及びトライブ鍵KG/LG及びKT/LTの連結から構成される。各メンバーのペアについて、連結されたグループ暗号化及び認証鍵はメンバーのペアに対して鍵ペアを用いて暗号化され、その結果が初期化ベクトルに連結される。これらの連結された鍵はそれら自身連結されて統合再キーイング情報1906を形成する。新しい鍵は古い/現在のグループ鍵KG/LGを置換する。新しい鍵ペアが転送中の場合、統合グループ再キーイング情報には新しい鍵ペアに対する統合再キーイング情報が続く。各メンバーのK/L鍵は連結されそのメンバーの公開鍵を用いて暗号化される。これらの暗号化された鍵は連結されて統合鍵ペア再キーイング情報を形成する。次に、新しいグループ暗号化鍵で暗号化されて、新しい鍵1908に対応する初期ベクトルに連結されたデルタ情報が送信される。このデルタの内容は従来のあらゆるデルタメッセージとすることができる。最後に、メッセージ多重認証コード1910が送信される。これはメンバー間の認証子を連結したものとすることができる。それぞれの認証子は送信側メンバーから受信側メンバーへのペアになった認証鍵Lijで保護されたハッシュ情報である。ハッシュ情報はへッダ1900と、統合新規グループ鍵情報1904またこれが送信中の場合には統合新規鍵ペア情報、更に暗号化されてないデルタ情報を含む。ペアになった鍵がメッセージにピギーバックしている場合には、多重認証コードの代わりに、公開鍵署名認証子を送信する。前述のセキュリティシステムは様々な方法で実装できる。好適実施態様では、図20に模式的に示したプロバイダアーキテクチャを使用する。このようなアーキテクチャが好ましいのは、前述したセキュリティプロトコルがアルゴリズム中立であることによる、つまり特定の暗号化及び保護アルゴリズムに依存していないためである。このプロトコルはアルゴリズムに中立なインフラストラクチャ例えば図20に図示してあるそれを利用できる。図20は縦方向の次元と横方向の次元で構成される2次元構造を示す。縦方向の次元は数個の抽象層から構成され、横方向の次元は縦方向の層を含めた各種アプリケーション及びサービスで構成される。最上部の層はアプリケーション層で、アプリケーションの組を含み、そのうちのアプリケーション2000と2002が図示してある。これらのアプリケーションには、分散通信システム及びコラボレーションシステム、例えば前述のコラボレーションシステムや、保護データ記憶、可用性サービスの非拒絶、システム管理、医療情報システム、航空管制システム、原子力発電所、軍事情報作戦指令管制システムなどを含み、これだけに限定されない。アプリケーション2000及び2002は一つまたはそれ以上のセキュリティサービスにアクセスするが、そのうちサービス2004と2006を図示してある。これらのサービスには、例えば識別、認証、完全性、機密性、プライバシー、許可、権威の代理、アカウンタビリティと非拒絶、タイムスタンプ、公証notarization、監査、信頼ポリシー管理、侵入検知及び復旧サービスなどを含む。セキュリティサービスは抽象プリミティブサービス2008と2010を含む抽象またはアルゴリズムに中立なプリミティブサービスの組み合わせにより実装される。抽象プリミティブサービスは実際には具象またはアルゴリズム特異的なプリミティブサービスの組み合わせによって実装される。例えば、抽象プリミティブサービス2008は具象プリミティブサービス2012、2014、2016により実装され、一方抽象プリミティブサービス2010は具象プリミティブサービス2018、2020、2022によって実装される。これらの具象プリミティブサービスは例えば特定の暗号サービスやプロトコルなどのサービスを含む。各抽象層は高次の抽象層または層群によって消費されるサービスを作成する。好適な実装では、アプリケーション2000、2002とセキュリティサービス2004、2006の間の関連性、ならびにセキュリティサービス2004、2006と抽象プリミティブサービス2008、2010の間の関連性は従来どおりの、これらの層の間で静的なコンパイル時に決定される結合compile-timebindingsである。しかし抽象プリミティブサービス2008、2010と具象プリミティブサービス2012、2014、2016、2018、2020、2022の間の結合は、制約された方法で一つの抽象プリミティブサービスと一つまたはそれ以上の具象プリミティブサービスを関連づける動的なランタイム結合であるのが望ましい。この動的な結合はプロバイダアーキテクチャと呼ばれ、抽象またはアルゴリズム中立なプリミティブサービスをなんらかの具象またはアルゴリズム特定のそれで作成することにより実装できるメカニズムであり、実装は任意の時刻にその環境内でアクティブにすることができるようなものである。図21と図22はプロバイダアーキテクチャの特定の実装を模式的に示している。オブジェクト指向プログラミング技術をこの実装では用いているが、他の等価な技術やプログラミング言語で実装することもできることは当業者に理解されるであろう。更に詳しく説明すると、図示した実装はダイナミックリンクライブラリDLLを使用して各種サービスを提供している。DLLは図21と図22のそれぞれに図示してある。図21に図示したDLLはセキュリティサービスマネージャSSMと呼ばれるもので、図22に図示したDLLはセキュリティサービスプロバイダSSPまたは単にプロバイダと呼ばれる。セキュリティサブシステムのどのランタイムインスタンシエーションにも必ず一つだけSSMDLLがロードされる。一方でSSPDLLは何個でもロードでき、それらがすべて独立しているという制限が加えられるだけであるこれらがすべてシステムレジストリなどのファイルに記録されている通りの独立したLIBIDとファイル名を有するという意味で。SSPDLLの名称はそのデベロッパが選択する。図示したSSPDLLの例はSecProvXXX.dllというような名前がつけられていると考えられ、他のDLLはSecYYYProv.dllまたはZZZSecProv.dllというような名前をつけることができる。図21と図22のボックスはマイクロソフトコモンオブジェクトモデルMicrosoftCommonObjectModelに適合するCOMクラスを示す。これらのクラスは、エンジンクラス右側に示すと非エンジンクラス左側に示すの2種類のグループに大別される。COMエンジンクラスのそれぞれは一つだけIDLインタフェースを実装してエクスポートする。例えば、エンジンクラス2106MessageDigestはインタフェース2104IMessageDigestをエクスポートし、エンジンクラス2118KeyGeneratorはインタフェース2116IKeyGeneratorをエクスポートし、エンジンクラス2126Cipherはインタフェース2124ICipherをエクスポートする。これはインタフェース2100をエクスポートするSecurityクラス2102についても言えることである。図22に図示した具象クラスについても同じことが当てはまる。例えば、具象エンジンクラス2204XXXMessageDigestSpiはインタフェース2206IMessageDigsetSpiをエクスポートし、エンジンクラス2208XXXKeyGeneratorSpiはインタフェース2206IKeyGeneratorSpiをエクスポートし、エンジンクラス2210XXXCipherSpiはインタフェース2212ICipherSpiをエクスポートする。プロバイダ抽象クラス2122とXXXProvider具象クラス2200図22で形成されるプロバイダ/XXXプロバイダProvider/XXXProvider複合クラスについても同じことが言える。更に詳しく説明すると、Providerクラス2122はIProviderインタフェース2120をサポートし、XXXXProviderクラス2200はIProviderCtorインタフェース図22には図示していないをサポートする。しかし、Providerクラス2122はXXXProviderクラス2200の内部でのみ統合可能で、したがって独立してインスタンシエーションできない。つまり、IProvider2120インタフェースとIProviderCtorインタフェースの両方がProvider/XXXProvider複合クラス2122/2200によってエクスポートされることになる。Provider/XXXProvider複合クラスと図21に図示したエンジンクラスの全部は図22に図示してある他の一つのクラスと組み合わされるただしこれは多数のSSPを構成することができそれぞれが多数のアルゴリズムをサポートできることから多面的な関係である。SSMDLL図21のパートナーは抽象パートナーと呼ばれ、SSPDLL図22のパートナーは具象パートナーと呼ばれる。図21と図22の左側には、マスタークラスと呼ばれる2種類のCOMクラスがあり、これはSecurityクラス2102とProvider/XXXProvider複合クラス2122/2200である。Securityクラス2102がマスタークラスであるという意味は、各種スレーブProvider/XXXProviderクラスを制御できるということである。逆に、各種Provider/XXXProviderクラスがマスターであるということの意味は、これらが各種のスレーブ低レベル/具象エンジンクラスを制御すると言うことである。マスタークラスはほとんどセキュリティサブシステムの内部的なもので大半のアプリケーションからは見えない。図21と図22の右側にはエンジンクラスと呼ばれる2種類のCOMクラスがあり、これらは図21に図示した抽象エンジンクラスと図22に図示した具象エンジンクラスである。抽象エンジンクラスはm_Engineフィールドの値に0を持っていれば純粋に抽象的であると言われる。3種類のエンジンクラスMessageDigest、KeyGenerator、Cipherが説明のために図示してあるが、これらの個数は原理的に制限されない。これらのエンジンクラスは図21と図22に図示してあるように対で発生し、低レベルのクラスが高レベルのクラスの内部に内包または封入されるm_Engineメンバーを経由する。高レベルエンジンクラスの機能はセキュリティサービスの消費者が起動するアプリケーションプログラミングインタフェースAPIをエクスポートすることである。低レベルエンジンクラス名に見られる接尾辞Spiはサービスプロバイダインタフェースまたはセキュリティに関して言えばセキュリティプロバイダインタフェース、また時に他の状況下ではシステムプログラミングインタフェースを意味するもので、これの唯一の消費者は高レベルエンジンクラスである。これらの低レベルエンジンクラス内に実際のアルゴリズム特有の実装コードが存在する--これがSSPDLLの実際に提供する最終的な機能である。エンジンクラスを2つの部分に分割したことが、これらのサポートするサービスの命名構造に反映されており、完全認証サービス名は抽象/概念の接頭辞と具象/アルゴリズムの接尾辞、例えばMessageDigest.MD5というように構造化される。各具象SSPXXXProviderクラス2200は静的な情報を含み、これにはその名前s_MyName、文字列、バージョンs_MyVersion、数字、クラスIDs_MyClsid、16バイト二進数、情報s_MyInfo、文字列、DLLにバンドルされているサービスのリストs_MySvcMap[]、文字列のペアのリストを含む。s_MySvcMap[]の各エントリでは、一方の文字列がそのサービスで実装するアルゴリズムの名称、他方がそのアルゴリズムを実装する具象エンジンクラスSecProvXXX.dllにバンドルされるのCOMCLSIDクラスIDである。エンジンクラスに加えて、セキュリティサブシステムは多数の非エンジンクラスを含む。代表的な2つのクラス、KeyとKeyPairが図21に示してある。図面が示すように、このような非エンジンクラスは相対的に通常のCOMクラスで、唯一普通とは違う特徴は抽象インタフェースクラスであり具象実装クラスはSSMDLL図21とSSPDLL図22の間で分割されるされないことである。例えば、Keyクラス2110の場合だと、SSMは一般に任意のSSPの鍵がどのようなものであるべきかについての優先的なインタフェース知識を持っているが、SSPそれ自体はSSMによって例えばXXXKeyクラス2210によって定義されるインタフェースに準拠したKeyクラスの詳細な実装を供給する必要がある。しかしKeyPairクラス2114の場合、SSMはすでに実装についての詳細な知識を持っている--これはKeyそれがどのようなものであってものペアで構成される。セキュリティサブシステムをブートする場合、例えば、Securityクラス2102がランタイム時に最初にCoCreateされ、Securityクラス2102はSecurityクラスのFinalConstructメソッドで次のようなことを行なう。第1に、Securityクラス2102は例えばレジストリRegistryに保存されている構成情報を読み込む。次に、それぞれの構成された具象プロバイダXXXProviderレジストリから読み出したばかりののProgIDまたはCLSIDに基づいて、セキュリティクラスがXXXProvider2200のインスタンスをCoCreateし、XXXProviderのIProviderCtorインタフェースCtorはコンストラクタconstructorの意味へのポインタを得る。XXXProviderクラスをCoCreateするこの動作は更にXXXPrividerのFinalConstructにXXXProvider2200内部の抽象ProviderクラスのオブジェクトをCoCreateして統合する。次に、いまCoCreateしたばかりのXXXProviderのIProviderCtorインタフェースを使って、Securityクラス2102がXXXProviderのno-arg-CtorメソッドをIProviderCtorインタフェースから呼び出す。この特別なno-arg-CtorメソッドはXXXProviderの名称/バージョン/情報/clsid/サービスデータを、ハードワイヤードな静的数値変数の位置から統合Providerオブジェクト内の非静的メンバー変数へアップロードするno-arg-CtorメソッドはXXXProviderの統合Providerサブオブジェクトによってエクスポートされるなんらかのメソッドを呼び出すことでこれを完了する。第4に、Securityクラス2102は各種の構成された具象プロバイダを指すIProviderの静的内部構成リストs_ProvList[]を構築する。Securityクラス2102は、Securityクラス2102がこの時点まで使っていたXXXProviderのIProviderCtorインタフェースでQueryInterfaceを呼び出すことで各IProviderを構築する。構成されたSSPのリストs_ProvList[]はSecurityクラス2102のgetProvidersメソッドを介してクライアントが利用できるようになる。アプリケーションは次のような方法でプロバイダアーキテクチャを実際に使用する。あるアプリケーションがMessageDigestオブジェクト上でdigestメソッドを呼び出して特定メッセージバッファのダイジェストを実際に計算したいと想定する。アプリケーションはSSMで抽象エンジンクラスを知っているすなわちSecuritySvcs.dllのクラスのCLSID。これは作成中にこの情報へリンクされたためだが、現実のアルゴリズム実装が実際に存在するSSP内の具象エンジンクラスについては優先順位すなわち、SecProvXXX.dllのクラスのCLSIDを知らない。したがって、アプリケーションは抽象エンジンオブジェクトを直接CoCreateできるが、具象エンジンオブジェクトは直接CoCreateできない。しかし、好適実施態様では、抽象エンジンオブジェクトがgetInstanceと呼ばれるファクトリメソッドを有するクラスファクトリオブジェクトとして処理され、次のように、間接的に具象エンジンオブジェクトを作成している。アプリケーションはMessageDigestクラス2106から純粋な抽象MessageDigestオブジェクトをCoCreateすることから開始する。このようなオブジェクトは具象エンジンオブジェクトへ接続されないのでダイジェストを作成するためには使えない、すなわち主状態変数m_Engineは値に0を持っている副状態変数m_AlgNameとm_ProvNameも同様。いまCoCreateしたIMessageDigestインタフェース2104を使って、アプリケーションはMessageDigestのgetInstanceメソッドを呼び出し、使いたいメッセージダイジェストアルゴリズムの周知の名前を指定する。getInstanceメソッドはファクトリメソッドで、次のステップを実行する。第1に、getInstanceメソッドがSecurityオブジェクトでgetProvidersメソッドを呼び出して現在構成されているプロバイダのリストをフェッチする。次に、getInstanceメソッドはいまフェッチしたばかりのSSPのリストを使って、要求されたアルゴリズムをサポートする最初のSSPが見つかるまで、好適な順番で各SSPのgetメソッドを呼び出す。SSPのgetメソッドはSSPのm_SvcMap[]を使用し、アルゴリズム名を具象エンジンクラスProgIDにマッピングする。つまりこの例では、クラス2022のgetメソッドが要求されたアルゴリズムをサポートしているMessageDigestSpi具象エンジンクラスのProgIDを返す。次に、getInstanceメソッドはgetInstanceメソッドが呼び出されたMessageDigestとは別に新しく抽象MessageDigestオブジェクトをCoCreateする。まず、この新しいMessageDigestオブジェクトはもう一つの純粋な抽象エンジンオブジェクトだが、次のステップでgetInstanceメソッドは完全な/接続されたエンジンオブジェクトへすなわちm_Engineフィールドを介してこれの内部に含まれる/作成される具象エンジンとあわせて非純粋抽象エンジンオブジェクトに変化させる。最後に、getInstanceメソッドは新しいMessageDigestオブジェクトのconstructorメソッドを呼び出し、パラメータとして上記で呼び出したgetオブジェクトから取得したMessageDigestSpiCLSIDまたはProgIDを渡す。そのconstructorメソッドはクラス2104からMessageDigestSpiオブジェクトのインスタンスをCoCreateし、新しいMessageDigestのm_Engineフィールドへ得られたIMessageDigestSpiポインタを格納する。つまり、getInstanceメソッドはアプリケーションへ完全に完成/接続したMessageDigestエンジンオブジェクトを返す。この時点で、アプリケーションはエンジンオブジェクトのdigestメソッドを呼び出してメッセージのダイジェストを計算する。抽象エンジンオブジェクトのdigestメソッドは具象エンジンオブジェクトのengineDigestメソッドへの呼び出しを代理または転送して実際の作業を行なわせる。上記で説明した実施態様のソフトウェアによる実装は、有形の媒体例えばコンピュータで読み取り可能な媒体例えばディスケット、CDROM、ROMメモリ、または固定ディスクなどに固定されるか、モデムまたは媒体上のその他のインタフェース装置を介してコンピュータシステムへ転送可能な一連のコンピュータ命令を含む。媒体は光またはアナログ通信線を含みこれに限定されない有形の媒体としたり、マイクロ波、赤外線またはその他の電送技術を含みこれに限定されない無線技術で実装することができる。媒体はインターネットの場合もある。一連のコンピュータ命令は本発明に関して本明細書ですでに説明した機能の全部または一部を実現する。このようなコンピュータ命令は多くのコンピュータアーキテクチャまたはオペレーティングシステムで使用される多数のプログラミング言語で書けることが当業者には理解されよう。更に、このような命令は、現在または将来の、半導体、磁気、光、またはその他のメモリ装置を含みこれに限定されないなんらかのメモリ技術を用いて保存したり、あるいは現在または将来の、光、赤外線、マイクロは、またはその他の伝送技術を含みこれに限定されないなんらかの通信技術を用いて伝送される。このようなコンピュータプログラムは印刷物または電子文書を伴なう取り出し自由な媒体として、例えばシュリンクラップ包装ソフトウェアとして配布されたり、コンピュータシステムに例えばシステムROMや固定ディスク上にプリロードされていたり、またはサーバまたは電子掲示板から例えばインターネットまたはワールドワイドウェブなどのネットワーク上で配布されることがあると想定される。本発明の代表的実施態様を開示したが、本発明の利点のいくつかを実現し本発明の主旨と範囲から逸脱しない各種の変化及び変更を加えることができることは当業者に明らかであろう。例えば、説明は特定のハードウェアシステム及びオペレーティングシステムを指向したものだったが、他のハードウェアやオペレーティングシステムソフトウェアを説明したそれと同じ方法で使用できることは当業者には明らかであろう。例えば特定の関数を実現するために使用された特定の命令などのその他の態様ならびに本発明の概念に対するその他の変更も付録の請求の範囲によって包含されることを意図している。"