(57)【特許請求の範囲】
【請求項１】
ピアツーピア様式で第１のコンピューティングデバイスから第２のコンピューティングデバイスに、通信システム内で転送される少なくとも１つのメッセージをセキュアにするための方法であって、
第１のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションを、ピア認証者として動作する第３のコンピューティングデバイスと確立するステップであり、識別情報ベースの認証された鍵交換セッションが、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有する、確立するステップと、
第１のコンピューティングデバイスで、第２のコンピューティングデバイスのランダム鍵構成要素を第３のコンピューティングデバイスから取得するステップであり、第２のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスに第２のコンピューティングデバイスのランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第３のコンピューティングデバイスにより暗号化される、取得するステップと、
ピアツーピアメッセージング鍵を、第２のコンピューティングデバイスのランダム鍵構成要素を使用して第１のコンピューティングデバイスで計算するステップと、
少なくとも１つのメッセージを、メッセージングサーバとして動作する第４のコンピューティングデバイスを介して、第２のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出するステップであり、少なくとも１つのメッセージが、送出の前にピアツーピアメッセージング鍵を使用して暗号化される、送出するステップと
を含む、方法。
【請求項２】
確立するステップ、取得するステップ、計算するステップ、および送出するステップが、第２のコンピューティングデバイスが通信システムからオフラインである間に、第１のコンピューティングデバイスにより遂行される、請求項１に記載の方法。
【請求項３】
第２のコンピューティングデバイスが、通信システムにオンラインに戻った後に、メッセージを取得し、メッセージを解読する、請求項２に記載の方法。
【請求項４】
第３のコンピューティングデバイスが鍵管理エージェントである、請求項１に記載の方法。
【請求項５】
第１のコンピューティングデバイスが、第３のコンピューティングデバイス、または鍵管理サーバとして動作する第５のコンピューティングデバイスに、少なくとも１つのランダム鍵構成要素を計算して寄託するステップであり、第１のコンピューティングデバイスのランダム鍵構成要素が、第２のコンピューティングデバイスにより取得され、第１のコンピューティングデバイスが計算した同じピアツーピアメッセージング鍵を計算するために使用される、計算して寄託するステップをさらに含む、請求項１に記載の方法。
【請求項６】
第１のコンピューティングデバイスが、第３のコンピューティングデバイスまたは第５のコンピューティングデバイスに、複数のランダム鍵構成要素を計算して寄託し、複数のランダム鍵構成要素の各々が所与の時間期間に対応する、請求項５に記載の方法。
【請求項７】
第３のコンピューティングデバイスおよび第５のコンピューティングデバイスが、単一のサーバ上に併置される、請求項５に記載の方法。
【請求項８】
第３のコンピューティングデバイスおよび第５のコンピューティングデバイスが、別個のサーバ上に配置される、請求項５に記載の方法。
【請求項９】
第１のコンピューティングデバイスが、第１のコンピューティングデバイスに関連する公開識別情報に基づいて、第５のコンピューティングデバイスから少なくとも１つの秘密鍵を取得するステップをさらに含む、請求項５に記載の方法。
【請求項１０】
ランダム鍵構成要素がディフィ−ヘルマン鍵構成要素である、請求項１に記載の方法。
【請求項１１】
第１のコンピューティングデバイスに関連するプロセッサにより実行されるときに、請求項１に記載の方法のステップを遂行する、１つまたは複数のソフトウェアプログラムを記憶するプロセッサ可読記憶媒体。
【請求項１２】
第１のコンピューティングデバイスから第２のコンピューティングデバイスおよび少なくとも第３のコンピューティングデバイスに、通信システム内で転送される少なくとも１つのメッセージをセキュアにするための方法であって、第１、第２、および第３のコンピューティングデバイスが、あらかじめ定められたグループを形成し、方法が、
第１のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションを、グループ認証者として動作する第４のコンピューティングデバイスと確立するステップであり、識別情報ベースの認証された鍵交換セッションが、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有する、確立するステップと、
第１のコンピューティングデバイスで、第２のコンピューティングデバイスのランダム鍵構成要素および第３のコンピューティングデバイスのランダム鍵構成要素を第４のコンピューティングデバイスから取得するステップであり、第２および第３のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスにランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第４のコンピューティングデバイスにより暗号化される、取得するステップと、
第１のコンピューティングデバイスで、グループ鍵構成要素を、第２および第３のコンピューティングデバイスのランダム鍵構成要素を使用して、第１のコンピューティングデバイスに対して計算するステップと、
第１のコンピューティングデバイスに対するグループ鍵構成要素を、第４のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出するステップと、
それぞれのグループ鍵構成要素を、第４のコンピューティングデバイスから第２および第３のコンピューティングデバイスに対して取得するステップと、
グループメッセージング鍵を、第１、第２、および第３のコンピューティングデバイスのグループ鍵構成要素を使用して第１のコンピューティングデバイスで計算するステップと、
少なくとも１つのメッセージを、メッセージングサーバとして動作する第５のコンピューティングデバイスを介して、第２および第３のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出するステップであり、少なくとも１つのメッセージが、送出の前にグループメッセージング鍵を使用して暗号化される、送出するステップと
を含む、方法。
【請求項１３】
確立するステップ、取得するステップ、計算するステップ、および送出するステップが、第２のコンピューティングデバイスおよび第３のコンピューティングデバイスのうちの少なくとも１つが通信システムからオフラインである間に、第１のコンピューティングデバイスにより遂行される、請求項１２に記載の方法。
【請求項１４】
第２のコンピューティングデバイスおよび第３のコンピューティングデバイスが、通信システムにオンラインに戻った後に、メッセージを取得し、メッセージを解読する、請求項１３に記載の方法。
【請求項１５】
第４のコンピューティングデバイスが鍵管理エージェントである、請求項１２に記載の方法。
【請求項１６】
第１のコンピューティングデバイスが、第４のコンピューティングデバイス、または鍵管理サーバとして動作する第５のコンピューティングデバイスに、少なくとも１つのランダム鍵構成要素を計算して寄託するステップであり、第１のコンピューティングデバイスのランダム鍵構成要素が、第２および第３のコンピューティングデバイスにより取得され、第１のコンピューティングデバイスが計算した同じグループメッセージング鍵を計算するために使用される、計算して寄託するステップをさらに含む、請求項１２に記載の方法。
【請求項１７】
第１のコンピューティングデバイスが、第４のコンピューティングデバイスまたは第５のコンピューティングデバイスに、複数のランダム鍵構成要素を計算して寄託し、複数のランダム鍵構成要素の各々が所与の時間期間に対応する、請求項１６に記載の方法。
【請求項１８】
第４のコンピューティングデバイスおよび第５のコンピューティングデバイスが、単一のサーバ上に併置される、請求項１６に記載の方法。
【請求項１９】
第４のコンピューティングデバイスおよび第５のコンピューティングデバイスが、別個のサーバ上に配置される、請求項１６に記載の方法。
【請求項２０】
第１のコンピューティングデバイスが、第１のコンピューティングデバイスに関連する公開識別情報に基づいて、第５のコンピューティングデバイスから少なくとも１つの秘密鍵を取得するステップをさらに含む、請求項１６に記載の方法。
【請求項２１】
第２および第３のコンピューティングデバイスのランダム鍵構成要素の各々がディフィ−ヘルマン鍵構成要素である、請求項１２に記載の方法。
【請求項２２】
第１のコンピューティングデバイスが、第２のコンピューティングデバイスおよび第３のコンピューティングデバイスのうちの１つのランダム鍵構成要素を使用して、ピアツーピアメッセージング鍵を計算することにより、第２のコンピューティングデバイスおよび第３のコンピューティングデバイスのうちの１つとピアツーピアセッションを確立するステップをさらに含む、請求項１２に記載の方法。
【請求項２３】
第１のコンピューティングデバイスに関連するプロセッサにより実行されるときに、請求項１２に記載の方法のステップを遂行する、１つまたは複数のソフトウェアプログラムを記憶するプロセッサ可読記憶媒体。
【請求項２４】
ピアツーピア様式で第１のコンピューティングデバイスから第２のコンピューティングデバイスに転送される少なくとも１つのメッセージをセキュアにするための、通信システムの第１のコンピューティングデバイス内の装置であって、メモリに動作可能に結合されるプロセッサデバイスを備え、
第１のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションを、ピア認証者として動作する第３のコンピューティングデバイスと確立し、識別情報ベースの認証された鍵交換セッションが、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有し、
第１のコンピューティングデバイスで、第２のコンピューティングデバイスのランダム鍵構成要素を第３のコンピューティングデバイスから取得し、第２のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスに第２のコンピューティングデバイスのランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第３のコンピューティングデバイスにより暗号化され、
ピアツーピアメッセージング鍵を、第２のコンピューティングデバイスのランダム鍵構成要素を使用して第１のコンピューティングデバイスで計算し、
少なくとも１つのメッセージを、メッセージングサーバとして動作する第４のコンピューティングデバイスを介して、第２のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出し、少なくとも１つのメッセージが、送出の前にピアツーピアメッセージング鍵を使用して暗号化される
ように構成される、装置。
【請求項２５】
第１のコンピューティングデバイスから第２のコンピューティングデバイスおよび少なくとも第３のコンピューティングデバイスに転送される少なくとも１つのメッセージをセキュアにするための、通信システムの第１のコンピューティングデバイス内の装置であって、第１、第２、および第３のコンピューティングデバイスが、あらかじめ定められたグループを形成し、装置が、メモリに動作可能に結合されるプロセッサデバイスを備え、
第１のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションを、グループ認証者として動作する第４のコンピューティングデバイスと確立し、識別情報ベースの認証された鍵交換セッションが、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有し、
第１のコンピューティングデバイスで、第２のコンピューティングデバイスのランダム鍵構成要素および第３のコンピューティングデバイスのランダム鍵構成要素を第４のコンピューティングデバイスから取得し、第２および第３のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスにランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第４のコンピューティングデバイスにより暗号化され、
第１のコンピューティングデバイスで、グループ鍵構成要素を、第２および第３のコンピューティングデバイスのランダム鍵構成要素を使用して、第１のコンピューティングデバイスに対して計算し、
第１のコンピューティングデバイスに対するグループ鍵構成要素を、第４のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出し、
それぞれのグループ鍵構成要素を、第４のコンピューティングデバイスから第２および第３のコンピューティングデバイスに対して取得し、
グループメッセージング鍵を、第１、第２、および第３のコンピューティングデバイスのグループ鍵構成要素を使用して第１のコンピューティングデバイスで計算し、
少なくとも１つのメッセージを、メッセージングサーバとして動作する第５のコンピューティングデバイスを介して、第２および第３のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出し、少なくとも１つのメッセージが、送出の前にグループメッセージング鍵を使用して暗号化される
ように構成される、装置。
【請求項２６】
ピアツーピア様式で第１のコンピューティングデバイスから第２のコンピューティングデバイスに、通信システム内で転送される少なくとも１つのメッセージをセキュアにするための方法であって、
ピア認証者として動作する第３のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションを、第１のコンピューティングデバイスと確立するステップであり、識別情報ベースの認証された鍵交換セッションが、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有する、確立するステップと、
第２のコンピューティングデバイスのランダム鍵構成要素を、第３のコンピューティングデバイスから第１のコンピューティングデバイスに送出するステップであり、第２のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスに第２のコンピューティングデバイスのランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第３のコンピューティングデバイスにより暗号化される、送出するステップと
を含み、
次いで第１のコンピューティングデバイスが、第２のコンピューティングデバイスのランダム鍵構成要素を使用してピアツーピアメッセージング鍵を計算すること、および、少なくとも１つのメッセージを、メッセージングサーバとして動作する第４のコンピューティングデバイスを介して、第２のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出することが可能であり、少なくとも１つのメッセージが、送出の前にピアツーピアメッセージング鍵を使用して暗号化される、方法。
【請求項２７】
第１のコンピューティングデバイスから第２のコンピューティングデバイスおよび少なくとも第３のコンピューティングデバイスに、通信システム内で転送される少なくとも１つのメッセージをセキュアにするための方法であって、第１、第２、および第３のコンピューティングデバイスが、あらかじめ定められたグループを形成し、方法が、
グループ認証者として動作する第４のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションを、第１のコンピューティングデバイスと確立するステップであり、識別情報ベースの認証された鍵交換セッションが、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有する、確立するステップと、
第２のコンピューティングデバイスのランダム鍵構成要素および第３のコンピューティングデバイスのランダム鍵構成要素を、第４のコンピューティングデバイスから第１のコンピューティングデバイスに送出するステップであり、第１のコンピューティングデバイスが、第２および第３のコンピューティングデバイスのランダム鍵構成要素を使用して、第１のコンピューティングデバイスに対するグループ鍵構成要素を計算することが可能であるように、第２および第３のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスにランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第４のコンピューティングデバイスにより暗号化される、送出するステップと、
第４のコンピューティングデバイスで、第１のコンピューティングデバイスに対するグループ鍵構成要素を第１のコンピューティングデバイスから取得するステップと、
第１のコンピューティングデバイスが、第１、第２、および第３のコンピューティングデバイスのグループ鍵構成要素を使用してグループメッセージング鍵を計算すること、および、少なくとも１つのメッセージを、メッセージングサーバとして動作する第５のコンピューティングデバイスを介して、第２および第３のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出することが可能であるように、第２および第３のコンピューティングデバイスに対するそれぞれのグループ鍵構成要素を、第４のコンピューティングデバイスから第１のコンピューティングデバイスに送出するステップであり、少なくとも１つのメッセージが、送出の前にグループメッセージング鍵を使用して暗号化される、送出するステップと
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、（１）２０１１年７月１５日に出願された、「Ｓｅｃｕｒｅ  Ｇｒｏｕｐ  Ｍｅｓｓａｇｉｎｇ」という名称の第６１／５０８，１６８号、および（２）２０１１年７月２６日に出願された、「Ｓｅｃｕｒｅ  Ｇｒｏｕｐ  Ｍｅｓｓａｇｉｎｇ」という名称の第６１／５１１，８４５号として識別される米国仮出願の優先権を主張するものであり、それらの仮出願の開示は両方とも、それらの全体が本明細書に引用により組み込まれている。
【０００２】
本出願は、一般には通信セキュリティに関し、より詳細には、通信システムにおけるセキュアグループメッセージングに関する。
【背景技術】
【０００３】
今日知られているようなメッセージングサービスは、ワールドワイドウェブの出現より前に始まったインスタントメッセージング（ＩＭ）がその起源である。その時からメッセージングの概念は、多くの通信システムにわたる非常に広く普及したアプリケーションプログラムとしてのその地位を維持しながら、健全かつ継続的な進化を経てきた。より最近の拡張は、ソーシャルネットワークの態様を伴うチャットルームおよびマイクロブログ（例えばＴｗｉｔｔｅｒ）を含む。これらのメッセージングサービスの拡張は、企業環境の内部でも採用されている。モバイルネットワークについては、従来のメッセージングサービスは、ショートメッセージサービス（ＳＭＳ）およびマルチメディアメッセージサービス（ＭＭＳ）を含む。同時にメッセージングサービスは、着信音および壁紙のダウンロードなどの様々な付加価値サービスを供与するためのプラットフォームとしても働いてきた。スマートフォンの前例のない発展および採用を考慮に入れると、モバイルメッセージングサービスもまた、マイクロブログ、企業モバイルメッセージングサービス、およびグループメッセージングサービスのモバイル版を含む、急速な進化を経つつある。
【０００４】
すべての上記の例では、参加者およびメッセージングプロバイダ（通信ネットワーク基盤のプロバイダとは異なる場合がある、すなわち、その内部でメッセージングサービスがホストされるネットワークプロバイダ）が存在する。その上すべてのメッセージは、メッセージが配送前に様々なサーバに格納される場合でも、セキュリティに関するサポートをほとんど、または全く伴わずにネットワークを往来する。特に、メッセージは暗号化または認証されることがほとんどない。利用可能であり得るセキュリティの唯一の形式は、（モバイルワイヤレスなどの）アクセスリンクを介した暗号化および／または完全性保護である。これらの限定された設定においてでさえ、アクセスネットワークプロバイダは、計算能力を浪費しないためにセキュリティの特徴的機能を「オフにする」ことが多い。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Ｄａｎ  Ｂｏｎｅｈ、Ｍａｔｔｈｅｗ  Ｋ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  ｆｒｏｍ  ｔｈｅ  Ｗｅｉｌ  Ｐａｉｒｉｎｇ」Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＣＲＹＰＴＯ２００１（２００１）
【非特許文献２】Ｘ．Ｂｏｙｅｎら、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｔａｎｄａｒｄ（ＩＢＣＳ）＃１：Ｓｕｐｅｒｓｉｎｇｕｌａｒ  Ｃｕｒｖｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＢＦ  ａｎｄ  ＢＢ１  Ｃｒｙｐｔｏｓｙｓｔｅｍｓ」、２００７年１２月、ＩＥＴＦ  ＲＦＣ５０９１
【非特許文献３】Ｇ．Ａｐｐｅｎｚｅｌｌｅｒら、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ａｎｄ  Ｓｕｐｐｏｒｔｉｎｇ  Ｄａｔａ  Ｓｔｒｕｃｔｕｒｅｓ」、２００９年１月、ＩＥＴＦ  ＲＦＣ５４０８
【非特許文献４】Ｖ．Ｃａｋｕｌｅｖら、「ＩＢＡＫＥ：Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ」、２０１１年４月２０日、ＩＥＴＦインターネットドラフト
【非特許文献５】Ｖ．Ｃａｋｕｌｅｖら、「ＭＩＫＥＹ−ＩＢＡＫＥ：Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＢＡＫＥ）  Ｍｏｄｅ  ｏｆ  Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  ｉｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｎｅｔ  ＫＥＹｉｎｇ（ＭＩＫＥＹ）」、２０１１年６月、ＩＥＴＦ  ＲＦＣ６２６７
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の実施形態は、通信システムにおいて使用するための識別情報ベースの（ｉｄｅｎｔｉｔｙ  ｂａｓｅｄ）暗号化を用いるセキュアグループメッセージング技法を提供する。
【課題を解決するための手段】
【０００７】
例えば第１の実施形態では、方法は以下のステップを含む。方法は、ピアツーピア様式で第１のコンピューティングデバイスから第２のコンピューティングデバイスに、通信システム内で転送される少なくとも１つのメッセージをセキュアにするためのものである。第１のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションが、ピア認証者として動作する第３のコンピューティングデバイスと確立される。識別情報ベースの認証された鍵交換セッションは、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有する。第１のコンピューティングデバイスは、第２のコンピューティングデバイスのランダム鍵構成要素を第３のコンピューティングデバイスから取得し、第２のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスに第２のコンピューティングデバイスのランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第３のコンピューティングデバイスにより暗号化される。ピアツーピアメッセージング鍵が、第２のコンピューティングデバイスのランダム鍵構成要素を使用して第１のコンピューティングデバイスで計算される。少なくとも１つのメッセージが、メッセージングサーバとして動作する第４のコンピューティングデバイスを介して、第２のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出され、少なくとも１つのメッセージが、送出の前にピアツーピアメッセージング鍵を使用して暗号化される。
【０００８】
第２の実施形態では、方法は以下のステップを含む。方法は、第１のコンピューティングデバイスから第２のコンピューティングデバイスおよび少なくとも第３のコンピューティングデバイスに、通信システム内で転送される少なくとも１つのメッセージをセキュアにするためのものであり、第１、第２、および第３のコンピューティングデバイスが、あらかじめ定められたグループを形成する。第１のコンピューティングデバイスで、識別情報ベースの認証された鍵交換セッションが、グループ認証者として動作する第４のコンピューティングデバイスと確立される。識別情報ベースの認証された鍵交換セッションは、識別情報ベースの認証された鍵交換セッションに関連する識別情報ベースの認証されたセッション鍵を有する。第１のコンピューティングデバイスは、第２のコンピューティングデバイスのランダム鍵構成要素および第３のコンピューティングデバイスのランダム鍵構成要素を第４のコンピューティングデバイスから取得し、第２および第３のコンピューティングデバイスのランダム鍵構成要素が、第１のコンピューティングデバイスにランダム鍵構成要素を送出する前に、識別情報ベースの認証されたセッション鍵を使用して第４のコンピューティングデバイスにより暗号化される。第１のコンピューティングデバイスで、グループ鍵構成要素が、第２および第３のコンピューティングデバイスのランダム鍵構成要素を使用して、第１のコンピューティングデバイスに対して計算される。第１のコンピューティングデバイスに対するグループ鍵構成要素が、第４のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出される。それぞれのグループ鍵構成要素が、第４のコンピューティングデバイスから第２および第３のコンピューティングデバイスに対して取得される。グループメッセージング鍵が、第１、第２、および第３のコンピューティングデバイスのグループ鍵構成要素を使用して第１のコンピューティングデバイスで計算される。少なくとも１つのメッセージが、メッセージングサーバとして動作する第５のコンピューティングデバイスを介して、第２および第３のコンピューティングデバイスに向けて第１のコンピューティングデバイスから送出され、少なくとも１つのメッセージが、送出の前にグループメッセージング鍵を使用して暗号化される。
【０００９】
有利には、ピアツーピア関係にあるコンピューティングデバイス、またはあらかじめ定められたグループ内のコンピューティングデバイスのみが、少なくとも１つのメッセージを解読可能である。さらにセキュアメッセージは、受信者のうちの１人または複数が通信システムからオフラインである場合でも生成かつ送出され得る。
【００１０】
本発明のこれらおよび他の、目的、特徴的機能、および利点は、添付する図面とともに読まれることになる、本発明の例示的な実施形態の以下の詳細な説明から明らかとなろう。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態によるセキュアグループメッセージングを実装する通信システムを例示する図である。
【図２】本発明の実施形態による識別情報ベースの暗号化を用いるセキュアグループメッセージング方法論を例示する図である。
【図３】本発明の別の実施形態による識別情報ベースの暗号化を用いるセキュアグループメッセージング方法論を例示する図である。
【図４】本発明の実施形態によるプロトコルのうちの１つまたは複数を実装するのに適した、データネットワークおよび通信（コンピューティング）デバイスの一般化されたハードウェアアーキテクチャを例示する図である。
【発明を実施するための形態】
【００１２】
語句「通信システム」は、本明細書では一般に、テキストベースのデータ、グラフィックベースのデータ、ボイスベースのデータ、およびビデオベースのデータを含む、ただしそれらに限定されない、１つまたは複数のタイプのメディアを移送可能な、任意の通信システムまたはネットワークと定義される。
【００１３】
用語「鍵」は、本明細書では一般に、エンティティ認証、プライバシー、メッセージ完全性、暗号化／解読等のような、ただしそれらに限定されない目的での、暗号プリミティブおよび／またはプロトコルに対する入力と定義される。
【００１４】
さらに語句「セキュリティアソシエーション」は、本明細書では一般に、通信システムに対してエンティティを認証する目的で生成される暗号またはセキュリティのデータ（例えば１つまたは複数の鍵）と定義される。
【００１５】
さらに本明細書では、「サーバ」は一般に、通信ネットワーク、クライアント、および／または別のサーバからの要求によって、１つまたは複数の機能（例えばサービス）を遂行する、１つもしくは複数のコンピューティングデバイス、および／または、それらのコンピューティングデバイス上のソフトウェアプログラムと定義される。「ノード」が、通信システム内の専用コンピューティングデバイスを指す場合があり、または「ノード」が、１つもしくは複数の他の機能を遂行するコンピューティングデバイスの機能部分を指す場合があることをさらに理解されたい。
【００１６】
「クライアント」は、本明細書では一般に、通信ネットワーク、サーバ、および／または別のクライアントに、１つまたは複数の機能（例えばサービス）を要求する、１つもしくは複数のコンピューティングデバイス、および／または、それらのコンピューティングデバイス上のソフトウェアプログラムと定義される。クライアントデバイスの例は、セルラー電話、スマートフォン、卓上電話、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータ等を含み得るが、それらに限定されない。さらにコンピューティングデバイスは、ある目的ではサーバであり、別の目的ではクライアントである場合がある。
【００１７】
用語「メッセージ」は、本明細書では一般に、ある当事者が別の当事者に伝達することを望む任意の形式のデータまたは情報と定義される。データまたは情報は、テキストベースのデータ、グラフィックベースのデータ、ボイスベースのデータ、およびビデオベースのデータを含む、ただしそれらに限定されない、１つまたは複数のタイプのメディアを含み得る。他の形式のデータもまた、メッセージの一部であり得る。メッセージの文脈は、個人の、業務の、それらの組み合わせの、または何か他の文脈であり得る。
【００１８】
用語「オフライン」は、コンピューティングデバイスに関して本明細書では一般に、通信システムに接続されていない、および／または、通信システムにアクセスしていないと定義される。したがって用語「オンライン」は、コンピューティングデバイスに関して本明細書では一般に、通信システムに接続されている、および／または、通信システムにアクセスしていると定義される。
【００１９】
参照を容易にするために、詳細な説明が以下のように分けられている。セクションＩでは、識別情報ベースの暗号化（ＩＢＥ）および識別情報ベースの認証された鍵交換（ＩＢＡＫＥ）動作の一般原理を説明する。セクションＩＩでは、本発明の例示的な実施形態によるセキュアグループメッセージング解決策を説明する。セクションＩＩＩでは、本発明による１つまたは複数のセキュアグループメッセージングプロトコルを実装するための例示的なコンピューティングシステムを説明する。
【００２０】
Ｉ．識別情報ベースの暗号化（ＩＢＥ）および識別情報ベースの認証された鍵交換（ＩＢＡＫＥ）
本発明のセキュアグループメッセージング技法の例示的な実施形態の解説の前に、ＩＢＥおよびＩＢＡＫＥの一般原理が説明される。
【００２１】
Ａ．識別情報ベースの暗号化
識別情報ベースの暗号化（ＩＢＥ）プロトコルは、ＢｏｎｅｈおよびＦｒａｎｋｌｉｎにより提示されたものであり、Ｄａｎ  Ｂｏｎｅｈ、Ｍａｔｔｈｅｗ  Ｋ．Ｆｒａｎｋｌｉｎ、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  ｆｒｏｍ  ｔｈｅ  Ｗｅｉｌ  Ｐａｉｒｉｎｇ」Ａｄｖａｎｃｅｓ  ｉｎ  Ｃｒｙｐｔｏｌｏｇｙ−Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＣＲＹＰＴＯ２００１（２００１）を参照されたい、なお、その文献の開示は、本明細書に引用により組み込まれている。この非対称暗号の暗号化プロトコルによって、参加者が公開鍵として「ＩＤ」（例：電子メールｉｄ、またはドメイン名）を使用することが可能になり、ＲＳＡ（リベスト、シャミア、およびエーデルマン）などの公開鍵暗号化法に関連することが多い大規模な公開鍵基盤に対する必要性がなくなる。この問題に対するＢｏｎｅｈおよびＦｒａｎｋｌｉｎの手法は、有限体上の楕円曲線上の双線形写像を使用し、双線形判定ディフィ−ヘルマン問題に依拠する。
【００２２】
ＩＢＥは、以下の数学的なツールおよびパラメータを必然的に含む：
Ｅを有限体Ｆ上の楕円曲線とし、Ｐを大きな素数位数の点とする。
【００２３】
ｅ：Ｅ×Ｅ−→ＧをＥ上の双線形写像とする。典型的な例がヴェイユペアリングであり、したがってＧは１のｎ乗根の群となり、ただしｎはＦ上のＥ上の点の数の関数である。
【００２４】
ｓを非ゼロの正の整数とし、鍵生成関数（ＫＧＦ）に格納された秘密とする。これはシステム全体の秘密であり、ＫＧＦの外部では明らかにされない。
【００２５】
Ｐｐｕｂ＝ｓＰを、すべての参加者に知られているシステムの公開鍵とする。Ｅは群であるので、ｓＰはＥ内の点を示すことを想起されたい。
【００２６】
Ｈ１を、文字列をとり、その文字列を楕円曲線上の点に割り当てる、知られているハッシュ関数とする、すなわち、Ｈ１（Ａ）＝Ｅ上のＱＡであり、ただしＡは通常は識別情報であり、Ｈ１（Ａ）はさらにＡの公開鍵である。
【００２７】
ｄＡ＝ｓＱＡを、ＫＧＦにより計算され、Ａにのみ配送される秘密鍵とする。
【００２８】
Ｈ２を、Ｇの要素をとり、その要素を文字列に割り当てる、知られているハッシュ関数とする。
【００２９】
ｍを、暗号化されＡに送出されなければならないメッセージとする。ＢｏｎｅｈおよびＦｒａｎｋｌｉｎにより説明されている暗号化関数は、以下の通りである：
ｇＡ＝ｅ（ＱＡ，Ｐｐｕｂ）とし、ｒを乱数とする。
【００３０】
暗号化Ａ（ｍ）＝（ｒＰ，ｍ  ｘｏｒ  Ｈ２（ｇＡｒ））であり、換言すれば、ｍの暗号化出力は２つの座標ｕおよびｖを有し、ただしｕ＝ｒＰ、およびｖ＝ｍ  ｘｏｒ  Ｈ２（ｇＡｒ）である。「ｘｏｒ」が排他的ＯＲ論理関数を指すことに留意されたい。
【００３１】
（ｕ，ｖ）を解読するために、Ａは、以下の式を使用してｍを復元する：
ｍ＝ｖ  ｘｏｒ  Ｈ２（ｅ（ｄＡ，ｕ））。
【００３２】
この式の証明は、双線形写像、および、Ａが秘密ｄＡ（Ａにのみ知られているが他の参加者には知られていない秘密鍵）を有するという事実においての複雑ではない演習である。さらに、そもそもｄＡを計算したＫＧＦはメッセージを解読することも可能であり、結果としてＫＧＦが事実上の鍵供託サーバとなる場合があることに注意されたい。
【００３３】
ＩＢＥプロトコルのさらなる詳細は、Ｘ．Ｂｏｙｅｎらにより著わされた、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｔａｎｄａｒｄ（ＩＢＣＳ）＃１：Ｓｕｐｅｒｓｉｎｇｕｌａｒ  Ｃｕｒｖｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＢＦ  ａｎｄ  ＢＢ１  Ｃｒｙｐｔｏｓｙｓｔｅｍｓ」という名称の２００７年１２月のインターネットエンジニアリングタスクフォース（ＩＥＴＦ）リクエストフォーコメント（ＲＦＣ）５０９１、および、Ｇ．Ａｐｐｅｎｚｅｌｌｅｒらにより著わされた、「Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ａｎｄ  Ｓｕｐｐｏｒｔｉｎｇ  Ｄａｔａ  Ｓｔｒｕｃｔｕｒｅｓ」という名称の２００９年１月のＩＥＴＦ  ＲＦＣ５４０８において説明されており、それらの文献の開示は両方とも、それらの全体が本明細書に引用により組み込まれている。
【００３４】
Ｂ．識別情報ベースの認証された鍵交換
識別情報ベースの認証された鍵交換（ＩＢＡＫＥ）は、２００９年２月１７日に出願された、第１２／３７２，２４２号により識別される米国特許出願において説明されており、その出願の開示は、その全体が本明細書に引用により組み込まれている。ＩＢＡＫＥプロトコルによってデバイスが、互いに相互認証し、完全な順方向および逆方向の秘密性を提供する鍵を導出することが可能になる。
【００３５】
ここで説明されるＩＢＡＫＥ実施形態では、このプロトコルに関する基本的な構図は、上記でサブセクションＡにおいて考察された数学的な構成物およびパラメータを必然的に含む。このプロトコルは非対称であるが、いかなる公開鍵基盤（ＰＫＩ）サポートも必要とせず、代わりにプロトコルは、鍵生成関数として働くオフラインサーバを用いることに留意されたい。プロトコルの詳細が下記に概説される：
Ａ、Ｂが、鍵を認証し、鍵に関して合意することを試みている２つのエンティティ（または当事者、ただしＡは第１の当事者のコンピュータシステムを表し、Ｂは第２の当事者のコンピュータシステムを表す）であるものとする。
【００３６】
ＡおよびＢを使用して、定義によりＡおよびＢの公開鍵もまた表す、ＡおよびＢの対応する識別情報を表すことにする。
【００３７】
Ｈ１（Ａ）＝ＱＡおよびＨ１（Ｂ）＝ＱＢを、公開鍵に対応する楕円曲線上のそれぞれの点であるとする。実際、識別情報と、Ｈ１を適用することにより取得される曲線上の点との間に１対１の対応関係が存在するので、ＱＡおよびＱＢを公開鍵と呼ぶことも可能である。
【００３８】
ｘをＡにより選定される乱数とし、ｙをＢにより選定される乱数とする。
【００３９】
ＡとＢとの間のプロトコル交換は、以下のステップを含む：
Ａは、第１のステップにおいて、ｘＰ（すなわち、Ｅ上の加算法則を使用して、Ｅ上の点としてｘ回それ自体に加算されたＰ）を計算し、Ｂの公開鍵を使用してｘＰを暗号化し、ＢにｘＰを送信する。このステップにおいて暗号化は、上記でサブセクションＡにおいて説明された識別情報ベースの暗号化を指す。
【００４０】
暗号化されたメッセージを受信すると、Ｂはメッセージを解読し、ｘＰを取得する。引き続きＢは、第２のステップにおいて、Ａの公開鍵を使用してペア｛ｘＰ，ｙＰ｝を暗号化し、次いでＡにそのペアを送信する。
【００４１】
このメッセージを受信すると、Ａはメッセージを解読し、ｙＰを取得する。引き続きＡは、第３のステップにおいて、Ｂの公開鍵を使用してｙＰを暗号化し、ＢにｙＰを返送する。
【００４２】
これに続いて、ＡとＢの両方がセッション鍵としてｘｙＰを計算する。
【００４３】
Ａがランダムにｘを選定し、プロトコル交換の第２のステップにおいてｙＰを受信したことに注意されたい。このことによってＡは、ｙＰをそれ自体にｘ回加算することによりｘｙＰを計算することが可能になる。逆にＢは、ランダムにｙを選定し、プロトコル交換の第１のステップにおいてｘＰを受信した。このことによってＢは、ｘＰをそれ自体にｙ回加算することによりｘｙＰを計算することが可能になる。プロトコルのいかなる適用でも、識別情報とともにヘッダデータを利用して、プロトコルを適正に機能させることを確実にすることが可能であることに留意されたい。このことは比較的標準的であり、鍵合意のためのほとんどすべてのプロトコル交換に適用可能である。
【００４４】
ｘはランダムであるが、ｘＰはｘに関する情報を提供しないことにもまた留意されたい。したがってｘＰは、Ａにより選定されたランダムな秘密に基づく鍵の構成要素である。同様にｙはランダムであるが、ｙＰはｙに関する情報を提供しない。したがってｙＰは、Ｂにのみ知られているランダムな秘密に基づく鍵の構成要素である。
【００４５】
ｘｙＰがセッション鍵として働き得ることにさらに留意されたい。さらにセッション鍵は、ｘｙＰの任意の知られている関数であり得る。すなわち、セッション鍵はｆ（ｘｙＰ）と等しくあり得るものであり、ただしｆは、両方の当事者に知られており、秘密であることは求められていない（すなわち世界に知られている）。ｆに関する１つの実際的な要件は、ｆ（ｘｙＰ）が、ｘまたはｙを知ることなしに計算するのが難しく、出力が、例えばおよそ１２８ビット以上の、暗号の観点から申し分のない長さのものであるということであるべきである。
【００４６】
ＩＢＡＫＥプロトコルの特性のいくつかには、以下のものがある：
−  鍵供託の免除：プロトコル交換においてのすべてのステップがＩＢＥを使用して暗号化されることに注意されたい。そのため明らかにＫＧＦは、すべての交換を解読することが可能である。しかしながらＫＧＦは、セッション鍵を計算することは可能でない。これは、楕円曲線ディフィ−ヘルマン問題の困難性のためである。換言すればｘＰおよびｙＰを与えられても、ｘｙＰを計算することは計算論的に困難である。
【００４７】
−  相互認証された鍵合意：プロトコル交換においてのすべてのステップがＩＢＥを使用して暗号化されることに注意されたい。詳細には、Ｂのみが、第１および第３のステップにおいてＡにより送出されるメッセージの内容を解読することが可能であり、同様にＡのみが、第２のステップにおいてＢにより送出されるメッセージの内容を解読することが可能である。その上第２のステップの最後では、Ａは、Ｂによる第１のステップにおいての内容の解読の後にのみ、ｘＰが第２のステップにおいて送出されている場合があるので、Ｂの真正を確認することが可能である。同様に第３のステップの最後では、Ｂは、第２のステップの内容を正しく解読することの後にのみ、ｙＰが第３のステップにおいて返送されている場合があり、このことはＡによってのみ可能であるので、Ａの真正を確認することが可能である。最終的にＡとＢの両方は、同じセッション鍵に関して合意することが可能である。換言すればプロトコルは、ＩＢＥに基づく相互認証された鍵合意プロトコルである。上記の説明がプロトコルのセキュリティに関する動機をもたらす一方で、セキュリティの暗号の証明が容易にもたらされる場合がある。プロトコルの困難性は、楕円曲線ディフィ−ヘルマン問題の困難性に依拠し、そのことは、楕円曲線を選定したことの影響を受けている。
【００４８】
−  完全な順方向および逆方向の秘密性：ｘおよびｙはランダムであるので、ｘｙＰは常に新規であり、ＡとＢとの間のいかなる過去または未来のセッションとも無関係である。
【００４９】
−  パスワードがない：ＩＢＡＫＥプロトコルは、ＡとＢとの間のパスワードも秘密鍵の何らかのオフライン交換も必要としない。実際この方法は、任意の通信ネットワークを介して初めて通信する任意の２人の当事者に明らかに適用可能である。唯一の要件は、ＡとＢの両方が、例えばディレクトリサービスによって互いの公開鍵を認識していることを確実にすることである。
【００５０】
ＩＢＡＫＥプロトコルのさらなる詳細は、Ｖ．Ｃａｋｕｌｅｖらにより著わされた、「ＩＢＡＫＥ：Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ」という名称の２０１１年４月２０日のＩＥＴＦインターネットドラフト、および、Ｖ．Ｃａｋｕｌｅｖらにより著わされた、「ＭＩＫＥＹ−ＩＢＡＫＥ：Ｉｄｅｎｔｉｔｙ−Ｂａｓｅｄ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＢＡＫＥ）  Ｍｏｄｅ  ｏｆ  Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  ｉｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｎｅｔ  ＫＥＹｉｎｇ（ＭＩＫＥＹ）」という名称の２０１１年６月のＩＥＴＦ  ＲＦＣ６２６７において説明されており、それらの文献の開示は両方とも、それらの全体が本明細書に引用により組み込まれている。
【００５１】
ＩＩ．セキュアグループメッセージング
本明細書で詳細に解説されるように、本発明の実施形態は、参加者がエンドツーエンドでメッセージを暗号化することを可能にし、一方で同時に、中間のネットワークが鍵材料にアクセスできないことを確実にする、識別情報ベースの暗号化を利用するエンドツーエンドの鍵管理解決策を提供する。例えば上記で説明されたＩＢＡＫＥプロトコルが、本明細書において以下で説明される例示的な実施形態において使用される。
【００５２】
本明細書で提供される解決策は、ネットワーク内で必要とされる計算リソースの環境においてきわめて最適でもあり、具体的にはメッセージングプロバイダは、メッセージごとの単位でのセキュリティサービスをサポートするために、ネットワーク内で何らかの暗号処理を行う要件を伴わない、控え目に使用されることになる（したがって自動的にきわめて利用可能となる）鍵管理サーバ（ＫＭＳ）を設ける。ＫＭＳは中でも、上記でセクションＩにおいて説明されたＫＧＦの動作を遂行することを理解されたい。その上この解決策は、ピアツーピア（Ｐ２Ｐ）メッセージング、グループメッセージング、メッセージボード、マルチメディアメッセージング等を含む、ただしそれらに限定されないシナリオのホストに適用される。
【００５３】
次に、本明細書で説明される例示的な実施形態に関するいくつかの想定を説明する。しかしながら、これらの想定は限定的であることは意図されておらず、したがって、代替の実施形態が１つまたは複数の代替の想定を用いて実現され得ることを理解されたい。
【００５４】
通信システム内の１組のＮ人のユーザを含む友人グループ（ＧｏＦ）を考える。ここで「友人」は、広範な含意を有する、すなわち、企業（例えば店、会社、投機的企業、団体等）または非企業環境（例えばソーシャルネットワーキング）内の個人を選択することが意図されることに留意されたい。このグループは、前もって知られているか、またはアドホックの様式で生成されるかのいずれかである。このＧｏＦの各々の構成員が、このＧｏＦの任意の他の構成員とメッセージをセキュアに交換すること、および、このＧｏＦの構成員のみが読み応答することが可能なメッセージボードにメッセージを掲示することを望むということを想定する。この例示的な説明に関するセキュリティ想定は、以下のことを含む：
・所与のグループの構成員は、自分たち自身の間でのＰ２Ｐまたはグループの通信に先立って（アウトオブバンドで）何らかの鍵材料を交換することは求められていない。「アウトオブバンド」が、Ｐ２Ｐまたはグループのメッセージングセッションの前の、ピアまたは参加者の間だけの別個の専用のセッションを意味することを理解されたい。単に例として、アリスおよびボブがピアとして、何らかの形式でパスワードを使用してメッセージを暗号化する前に、電話を介して話し合い、パスワードに関して合意することが可能である。その電話のやり取りはアウトオブバンドとなる。
【００５５】
・セキュリティを可能にするために、メッセージングプロバイダが供与する任意の基盤サポートは、既存のネットワークセキュリティ解決策と比較してスケーラブルかつ軽量である。
【００５６】
・所与のグループの任意の構成員は、誰が他にオンラインであるかに無関係にメッセージを送出または掲示することが可能である。したがって、メッセージはサーバ（またはネットワーク要素）に格納され得るが、メッセージを格納するサーバはメッセージを解読可能ではない。より一般的にはメッセージングプロバイダは、任意のグループ内の加入者間で交換されるメッセージを暗号解読することは可能でない。
【００５７】
・グループの任意の２人の構成員間のセキュリティアソシエーションおよびＰ２Ｐ鍵は、それらの２人の構成員に一意的である。このことによってグループ構成員は、グループと無関係に「セキュアプライベートメッセージング」に携わることが容易になる。
【００５８】
・グループ通信に関係するセキュリティアソシエーションおよび関係するグループ鍵は、グループが拡大または縮小する際に鍵を修正するプロビジョニングを伴って、そのグループに一意的である。実際は、鍵は、グループ構成員が変えられていない場合でも（セキュリティポリシーに基づいて、例えば日単位で）「定期的に」更新される場合がある。
【００５９】
・認証され権限を与えられた構成員のみが、メッセージを送受信することが可能である。その上メッセージの受信者は誰でも、メッセージの作成者を「確認」することが可能である。
【００６０】
Ｐ２Ｐメッセージング：グループ鍵がＰ２Ｐ鍵と同じである、２人の構成員のグループからなるグループメッセージングの特別なケースとしてＰ２Ｐメッセージングを扱う。
【００６１】
以下のユースケースは、下記の対処される問題および提案される解決策を理解するためのフレームワークを提供する。しかしながらこれらのユースケースは、決して限定的ではなく、例示的な実施形態の理解を容易にすることのみが意図される。
【００６２】
１．一般的なユースケース：友人グループが企業内で、メッセージボードにメッセージを掲示し、無関係に互いに通信することを想定する。本明細書の実施形態は、メッセージボードがメッセージの内容を知得しないように、セキュアにメッセージングをどのように行うかに対処する。その上任意の２人のグループ構成員は、他のグループ構成員がメッセージを暗号解読することが可能でないような形で、グループとは無関係に互いにメッセージを送受信することが可能である。この後者の要件は、「セキュアプライベートサイドバー」メッセージング交換に相当する。
【００６３】
２．例示的な用途：サービスプロバイダが、病院環境内でメッセージングサービスをホストする、すなわち、ナースステーションが、特定の患者に関して対応を行う１組の医師（すべての医師ではない）にグループメッセージを送出することを想定する。このメッセージは、（オンラインである）記録への「リンク」を必然的に含む場合がある。このケースでは、グループを形成する医師のグループは、個々の患者がシステムに収容されるときに構成されることになる。患者が治療される際に、看護師および医師のグループは拡大または縮小する場合がある。患者が治療され退院させられると、そのグループはもはや存在しない。
【００６４】
３．アドホックメッセージング：２人の友人が、互いにメッセージを交換し、アドホックの様式で会話に他の友人を招くことを決心する。この設定ではすべてのメッセージが、グループの拡大を受け入れるように鍵を更新する用意を伴うグループ鍵を使用してセキュアにされる。これをアドホックグループメッセージングと呼ぶ。
【００６５】
次に、本発明の例示的な実施形態によるセキュアグループメッセージングのフレームワークおよび解決策を説明する。問題の形式的な説明から始め、それに続いて、識別情報ベースの暗号フレームワーク、および、その問題に対処することに向けて行う関係する想定を説明する。引き続き、セキュアグループメッセージングのフレームワークおよび解決策を提示する。
【００６６】
「友人グループ」を形成する１組のＮ人のユーザ
【００６７】
【数１】
0005784833.tif 000002
を考える。各々のユーザＵｉは、「友人」のみとメッセージを交換することを望み、ただし友人は、Ｕｉと親しくされ、Ｕｉのメッセージング情報をセキュアに受信する権限を与えられている任意のユーザ
【００６８】
【数２】
0005784833.tif 000003
であると考えられ、Ｕｊおよび友人が友人グループ（ＧｏＦ）を形成すると考えられる。メッセージは、ＧｏＦの構成員の間でセキュリティアソシエーション確立サポートを提供するメッセージングサービス基盤を利用することにより交換される。友人は、任意の時点ではオンラインまたはオフラインであり得る。換言すれば、必ずしもＧｏＦのすべての構成員が、起こり得るグループベースのセキュリティアソシエーション確立処理手順に参加するために同時にオンラインであるとは限らない。この構図を考慮に入れて、本発明の実施形態は、ＧｏＦの構成員の間で交換されるメッセージをセキュアにする方法論／プロトコルを提供する。すなわち上記の表記でいえば、実施形態によって、Ｕｉにより共有される情報が、セキュアに交換され、認証された１組の（友人）ユーザのみにより取得されることが確実になる。さらに実施形態によって、（必要とされるならば）友人が、受信される情報が確かにＵｉにより提供されることを確認することが可能になる。
【００６９】
上記で述べられたように、例示的な実施形態によるセキュアグループメッセージングプロトコルは、有利には参加者に、通信に先立って参加者自身の間で、アウトオブバンドで何らかのセキュリティ証明データを交換していることを求めず、プロバイダにより供与される鍵管理基盤サポートは、軽量かつスケーラブルである。
【００７０】
これらの利点を提供するために、例示的な実施形態は、上記でセクションＩにおいて説明された識別情報ベースの暗号プロトコルに基づく識別情報ベースの暗号フレームワークを使用する。ＩＢＥフレームワークの態様は、以下のことを含む：
１．あらゆる参加者（すなわち、発明者らのケースでのクライアント）は、公開鍵および対応する秘密鍵を有する。
【００７１】
２．すべての公開鍵は、識別情報（電話番号、ログイン識別子、セッション開始プロトコル（ＳＩＰ）ハンドルなど）に基づき、そのことにより、費用のかかる登録局（ＲＡ）および認証局（ＣＡ）に対する必要性がなくなる。
【００７２】
３．秘密鍵は、典型的にはプロバイダにより所有かつ運用される鍵管理サーバ（ＫＭＳ）により計算される。ＫＭＳは、セキュア管理サービスを提供する第三者プロバイダにより所有される場合もある。その上ＫＭＳは、暗号演算において使用され、プロバイダとの結び付きを生成する公開パラメータを発行する。
【００７３】
４．公開鍵は、公開鍵（および対応する秘密鍵）が自動的に期限切れで無効になることを可能にする「日付」をさらに含む。このことによって、失効および関係する基盤に対する必要性が実際的になくなる。例えば公開鍵は、規定によりその日の終わりで、期限切れで無効になる「ＩＤ｜本日の日付」と同様に単純である場合がある。
【００７４】
５．あらゆる参加者は、周期的に（例えばひと月に１回）ＫＭＳと連絡し、延長された期間（例えば次の３０日、または加入の継続期間）に対する１組の鍵を取得する。
【００７５】
６．参加者は誰でも、その日付に対する受信者の公開鍵、および受信者のＫＭＳの公開パラメータを使用することにより、他の誰に対しても情報を暗号化することが可能である。逆に受信者は、その日付に対する秘密鍵に基づいて情報を解読する。送出者は、受信者のみが、送出された情報を暗号解読することが可能であることが保証される。この識別情報ベースの暗号化フレームワークでは、受信者およびＫＭＳのみが解読可能である。
【００７６】
７．上記のＩＢＥフレームワークは、スケーラブルかつ軽量な公開鍵暗号化を考えに入れたものであるが、短所には、クライアント間の相互認証がないこと、および、ＫＭＳがあらゆる暗号化されたメッセージを解読可能である（すなわち、ＫＭＳが本来的な未処置の供託点である）という事実がある。
【００７７】
８．これらの短所は、相互認証、および受動的な鍵供託からの保護を提供する、上記で説明されたＩＢＡＫＥプロトコルにおいて対処される。
【００７８】
本発明の実施形態は、次に説明するセキュアグループメッセージングプロトコルにおいてＩＢＡＫＥプロトコルを採用する。この実施形態では、発明者らが対処することを望む問題の記述に関係する以下の想定を行う：
１．すべてのＮ人のユーザは、特定のユーザ識別情報に対応する鍵のペア（ＩＢＥ秘密鍵およびＩＢＥ公開鍵）を有することが想定される。ユーザＵｉのＩＢＥ秘密鍵ＫＰＲｉは、Ｕｉにより秘密に保たれ、一方で対応する公開鍵ＫＰＵＢｉは、すべてのＮ人のユーザに利用可能にされる。
【００７９】
２．それによってＧｏＦが形成されるオフライン機構が存在すると想定する。
【００８０】
３．メッセージングネットワーク事業者は、ＧｏＦ形成（複数可）を認識している。一般的なケースにおいて、システム内のすべてのユーザを必然的に含む単一のＧｏＦのみが存在する場合があることに留意されたい。
【００８１】
４．ＧｏＦ構成員は、メッセージングネットワーク事業者が、交換されるメッセージ内部に包含される情報を取得可能であることを所望しない。
【００８２】
５．ＧｏＦ構成員は、メッセージングネットワーク事業者を信頼し、ＩＢＥ秘密鍵を含むプライベートのユーザ情報を開示しないと確信されるメッセージングプロバイダにより供与されるＫＭＳを使用する。
【００８３】
セキュアグループメッセージングフレームワークのこの実施形態では、まず第１に、ＧｏＦが２人の構成員アリスおよびボブ（ただしアリスは、当事者Ａのコンピューティングデバイスまたはクライアントデバイスを指し、ボブは、当事者Ｂのコンピューティングデバイスまたはクライアントデバイスを指す）を含むケースを説明する。引き続き、３人以上のユーザがＧｏＦを構成するシナリオを含むように説明を拡大する。
【００８４】
下記では、Ｅ（ｋ，Ａ）は、情報Ａが公開鍵ｋを用いて暗号化されることを示し、ｓ｜｜ｔは、文字列ｓおよびｔの連結を示す。
【００８５】
Ａ．ＧｏＦが２人の構成員を含むケース（Ｐ２Ｐメッセージングのケース）
図１は、本発明の実施形態によるセキュアグループメッセージングを実装する通信システム１００を例示する。示されるようにシステム１００は、第１のコンピューティングデバイス（アリス）１０２、第２のコンピューティングデバイス（ボブ）１０４、鍵管理サーバ（ＫＭＳ）１０６、鍵管理エージェント（ＫＭＡ）１０８、およびメッセージングサーバ１１４を示す。
【００８６】
ＫＭＳ１０６およびＫＭＡ１０８は別個のサーバとして示されるが、それらは、同じサーバ上に、または３つ以上のサーバ上に実装される場合がある。例えばＫＭＳおよびＫＭＡの機能性は、同じサーバ複合体で、ただし地理的に分散された方式で実装される場合がある。例えばクライアントは、月単位の秘密鍵に関して（クライアントの請求先住所のために）ニューヨークにおいてＫＭＳ機能性に接続される場合がある。しかし所与の日付に、クライアントは移動しており、したがってカリフォルニアにおいてＫＭＡ機能性に接続される場合がある。本明細書の詳細な説明を考慮に入れると、様々な他の実装形態が実現されることになる。
【００８７】
さらに、ただ１つのメッセージングサーバがシステム１００に示されているが、１つまたは複数のメッセージングプロバイダにより運用される２つ以上のメッセージングサーバが存在し得ることを理解されたい。その上さらに、図１は２人の参加者／構成員（アリスおよびボブ）のみを示すが、システム１００は、典型的には多数の参加者／構成員を含むことになる。したがって本明細書で述べられるように、Ｐ２ＰメッセージングのシナリオはＧｏＦ内の２人の構成員だけを含み、一方でグループメッセージングのシナリオはＧｏＦ内の２人以上の構成員を含む。
【００８８】
この実施形態では、楕円曲線暗号化（ＥＣＣ）が、１つまたは複数のＧｏＦの構成員の間でセキュリティアソシエーションを確立するための機構として用いられる。その限りで、各々のユーザＵｉは、ＩＢＥ公開鍵を使用して１つの情報の識別情報ベースの暗号化を遂行することが可能であり、対応するＩＢＥ秘密鍵を使用して、Ｕｉに向けられたＩＢＥで暗号化されたメッセージを解読することが可能であると考える。これらの算出は、有限体上の知られている超特異楕円曲線上で遂行される演算を必然的に含む。加えてこの構図は、鍵合意を遂行するために使用される、超特異でない、知られている楕円曲線Ｅ上の知られている点Ｐの使用を含む。
【００８９】
図１に示されるように、ＧｏＦがアリス１０２およびボブ１０４を含む、すなわち、アリスおよびボブが、セキュアメッセージングサービスに加入したユーザの組であることが想定されている。
【００９０】
ＫＭＳ１０６は、特定の公開識別情報が与えられると、エンドユーザに対するＩＢＥ秘密鍵をセキュアに算出かつ配布するサーバである（例えば上記で組み込まれたＲＦＣ２６７を参照）。システム内のすべての参加者が、ＫＭＳ１０６の公開パラメータを認識していることもまた想定されている。一例としての方法は、（認証局の公開鍵と同様に）クライアントにそのようなパラメータをプリロードするための、または、公開データベースからそれらのパラメータを取得するためのものであり得る。その上ＫＭＳ１０６は、下記でさらに解説されるように、異なるユーザ識別情報および日付に関係がある様々な鍵構成要素を保存するリポジトリとしても働く。この構図を考慮に入れると、（セキュアメッセージングの環境での）クライアント（アリス１０２またはボブ１０４）とＫＭＳ１０６との間の基本的な対話は、以下の通りである。
【００９１】
クライアント（アリス１０２またはボブ１０４）は、周期的に（例えばひと月に１回、または加入継続期間ごとに１回）ＫＭＳ１０６に秘密鍵を要求し取得する。そのような秘密鍵の数は、所与のセキュリティポリシーによって決まり、失効に対する必要性を実際的になくすことを確実にするために、有用な例は、１日ごとに１つの鍵（例えば、１つのトランザクションにおいてひと月の間にすべてが取得される３０個の鍵）を使用することである。しかしながら本発明の実施形態は、いかなるそのような周期性にも限定されない。線１１０−Ａは、アリス１０２に対するＩＢＥ秘密鍵プロビジョニングを示し、線１１０−Ｂは、ボブ１０４に対するＩＢＥ秘密鍵プロビジョニングを示す。
【００９２】
加えてあらゆるクライアントは、暗号法的にセキュアな擬似乱数「ｘ」を（例えば１日ごとに１つ）生成し、知られている非超特異楕円曲線Ｅ上で（上記でセクションＩにおいて説明されたように）ｘＰの値を計算し、それらをＫＭＳ１０６に寄託する。この値ｘＰは、その日に対するそのユーザの鍵構成要素として働く。例えば、セキュリティポリシーが、セッション鍵が１日ごとに１回リフレッシュされることを必然的に含み、ＫＭＳとのクライアントの対話がひと月ごとに１回であるとき、クライアントはｘＰの３０個の値を算出し、それらをＫＭＳに寄託する。ＫＭＳがｘＰおよびＰを有する場合でも、楕円曲線離散対数は解くのが困難であるので、ｘを計算することは計算論的に困難であることに留意されたい。ｘＰは、所与のクライアントのディフィ−ヘルマン鍵構成要素であることにも留意されたい。さらに、ｘＰの値はセキュアな様式でＫＭＳと共有されなければならないことに留意されたい。このことは、すべての参加者がプロキシベースの相互認証を遂行可能であることを確実にするために必要とされる。１つのＫＭＳが図１に示されているが、各々のクライアント（アリス１０２およびボブ１０４）は異なるＫＭＳと通信可能であり、２つのＫＭＳが、必要とされるならば互いにセキュアな様式で通信可能であることを理解されたい。
【００９３】
１つまたは複数の実施形態においてＫＭＡ１０８は、すべての鍵合意トランザクションに対するプロキシである、論理ネットワーク要素（またはサーバ内で現実化されるソフトウェアコンポーネント）である。具体的にはこのプロキシエージェントは、ＩＢＡＫＥトランザクション（上記のセクションＩＢを参照）において「レスポンダ」の役割を遂行し、レスポンダが必ずしもオンラインでない場合でも、エンドツーエンドの鍵の確立を可能にする。この機能性は、以下のように達成される。
【００９４】
このエージェント１０８は、個々の日に対してＧｏＦ内のすべての構成員のすべての「ｘＰ」値を取得する（ただしＰは、ＮＩＳＴ楕円曲線Ｅ上の共通に合意された点であり、一方で「ｘ」は大きな乱数である（例えば上記で組み込まれたＲＦＣ５０９１を参照））。所与のクライアントに対して、ｘＰの同じ値が、所与の日付に対して（Ｐ２Ｐメッセージングのケースではアドレス帳であり得る）ＧｏＦのすべての構成員にわたって使用されることに留意されたい。さらに、このことは例にすぎず、一般にはｘＰの所与の値の効力の継続期間は、セキュリティポリシーであり、メッセージングプロバイダにより決定される。
【００９５】
ＫＭＡ１０８は、すでに形成されたＧｏＦを認識していることが想定される。換言すればＫＭＡ１０８は、ユーザ、およびそれらのユーザの様々なグループの構成員数を認識しており、それらのユーザは、セキュアメッセージサービスに加入しており、そのことにより、他のＧｏＦ構成員とセキュリティアソシエーションを確立するために使用される暗号材料を受信する権限を与えられている。
【００９６】
ＫＭＡ１０８は、ＧｏＦ内の各々の構成員とともにＩＢＡＫＥプロトコルを遂行する、ＩＢＡＫＥレスポンダクライアントの機能性を遂行する。具体的にはＧｏＦの各々の構成員は、１日に１回ＫＭＡ１０８とセキュアに通信し、所与のイニシエータクライアントが構成員であるすべてのグループにわたって特定の日付に対するすべての他のＧｏＦ構成員の「ｘＰ」値を取得する。Ｐ２Ｐメッセージングの環境では、所与のイニシエータクライアントがＫＭＡ１０８から誰の「ｘＰ」の値を取得すべきかを決定するための機構として「アドレス帳」を使用することが可能である。
【００９７】
図１に図示されるシナリオでは、アリス１０２およびボブ１０４は、ＫＭＡ１０８とともにＩＢＡＫＥを別個に遂行する。線１１２−Ａは、アリス１０２に対するＩＢＡＫＥ認証を示し、線１１２−Ｂは、ボブ１０４に対するＩＢＡＫＥ認証を示す。確立されたセキュリティアソシエーションによって、特定の日（例えば「本日」）に対して、アリスはボブの「ｂＰ」値を取得し、同様にボブはアリスの「ａＰ」値をセキュアに取得する。「ｘＰ」値（図１ではｘ＝｛ａ，ｂ｝）が１日の持続期間に対して有効であることを考慮に入れると、各々のＧｏＦ構成員は、多くても１日ごとに１回ＫＭＡ１０８とセキュアに連絡する必要がある。アリス１０２およびボブ１０４は、同時にオンラインである必要はなく、ＫＭＡ１０８とのアリス１０２およびボブ１０４のそれぞれのトランザクションは、時間の異なる段階で起こる場合があることに留意されたい。
【００９８】
上記で解説されたように、アリス１０２およびボブ１０４は各々、（例えば上記で組み込まれたＲＦＣ６２６７にしたがって）２つの別個のＩＢＡＫＥ処理手順を使用して確立される、ＫＭＡ１０８との個別のセキュアな接続によって、ＫＭＡ１０８から互いの「ｘＰ」値を取得する。さらには、アリス１０２は値「ａｂＰ」を計算し、一方でボブ１０４は（ａｂＰと同一である）「ｂａＰ」を計算し、それらの値は、特定の日付に対する（以下でＧｏＦ鍵とも呼ばれる）「セッション」鍵である。結果としてアリス１０２およびボブ１０４は、アリス１０２およびボブ１０４にのみ知られているＧｏＦ鍵を最終的に導出することになる。図１に示される他のどのエンティティも、アリスおよびボブが各々計算するＧｏＦ鍵の値を取得することは可能でない。セッション鍵は、上記でセクションＩＢにおいて解説されたように、ａｂＰ（ｂａＰ）の関数として導出される場合もあることを理解されたい。
【００９９】
アリス１０２は、ボブ１０４とともにＩＢＡＫＥを遂行しないことに留意されたい。アリスおよびボブの各々は、１日（またはあらかじめ定められた期間であるものすべて）ごとに１回、ＫＭＡ１０８のみとともにＩＢＡＫＥを遂行する。このことを考慮に入れると、アリス１０２およびボブ１０４は、信頼されるエージェント（ＫＭＡ１０８）によって互いに相互認証される。エージェントに対する信頼は、（識別情報ベースの暗号化のすべてに対する基礎である）ＫＭＳ１０６によって実際に確立されることに留意されたい。アリス１０２はＫＭＡ１０８を信頼して、対応するＩＢＡＫＥ処理手順によってボブ１０４を認証する。同様にボブ１０４は、アリス１０２がＩＢＡＫＥを介してＫＭＡ１０８により認証されていることを想定する。１つのＫＭＡが図１に示されているが、各々のクライアント（アリス１０２およびボブ１０４）が異なるＫＭＡと通信可能であり、２つのＫＭＡが互いにセキュアな様式で通信可能であることを理解されたい。
【０１００】
アリス１０２およびボブ１０４により共通に計算されるＧｏＦ鍵（「ａｂＰ」）は、１つまたは複数のメッセージングサーバ（図１での１１４）を介してアリスとボブとの間で転送されるメッセージをさらに保護するために使用される。ボブが、共通ＧｏＦ鍵を使用してアリスにより暗号化されているメッセージを何とか解読するならば、（再び、ＫＭＡ１０８が信頼されるエンティティであることを考慮に入れると）アリスはＧｏＦ鍵を所有していることになっている唯一のものであるので、ボブはアリスのアイデンティティを（暗黙に）確認する。特に、イブ（図１に示されない、別のコンピューティングデバイス）が、所与のＧｏＦの一員でないならば、イブは、グループ構成員のいずれに対してのものでもあるＥＣＤＨ（楕円曲線ディフィヘルマン）鍵構成要素の値を取得することはできない。
【０１０１】
有利には、この解決策によってユーザは、絶えずオンラインである必要なしに、共有ＧｏＦ鍵導出処理に携わる。確かにアリス１０２およびボブ１０４は、１日に１回、ＫＭＡ１０８と連絡しＧｏＦ鍵を計算する。その後アリス１０２およびボブ１０４は、それらの都合でオフラインに移行し、オンラインに復帰することが可能である。一実装形態では、クライアントとＫＭＡとの間のＩＢＡＫＥセッションは、ユーザがトランザクションに介在することなく「１日に１回」走らされる（またはセキュリティ要件を満たすように適合される）場合があり、自動化される場合がある。ボブ１０４がオンラインになるときはいつでも、ボブ１０４は、ボブ１０４がオフラインであった間のアリス１０２からの受信されたメッセージがあればそれらを解読するために、個々の日付に対する計算されたＧｏＦ鍵を使用することが可能である。ボブは、場合によっては多くの日の間オフラインに移行することを決心する場合があることにも留意されたい。ボブがオンラインになると直ちに、ボブは、すべてのＧｏＦ構成員（または、Ｐ２Ｐメッセージングのための自分のアドレス帳内の人々）に対してＫＭＡ１０８に「ｘＰ」値を要求し、対応するＧｏＦ鍵を算出し、引き続きすべての入来するメッセージを解読することが可能である。アリス１０２が、自分のアドレス帳内にないデイビッド（示されない、さらに別のコンピューティングデバイス）と連絡することを所望するとき、アリスは、ネットワークによって、必要性に基づいてＫＭＡ１０８と連絡することにより、デイビッドが格納したｘＰの値を取得しに行くことが可能であることに注意されたい。解決策は、デイビッドがブラックリストを生成可能であり、ブラックリスト内の誰も、その日付に対するデイビッドの鍵構成要素ｘＰを取得することが可能でない場合があるユースケースをサポートするように拡張される場合がある。
【０１０２】
この解決策は、受動的な鍵供託の問題に対処する。換言すればこの解決策によって、メッセージングネットワーク事業者は、（事業者が場合によってはＫＭＳ１０６およびＫＭＡ１０８を所有するために）事業者がユーザのＩＢＥプライベート／公開鍵をたとえ知っても、ＧｏＦ構成員の間で交換される個別のメッセージに包含される情報を解読することは可能でない。アリス１０２およびボブ１０４が互いにメッセージを送っているとき、アリス１０２およびボブ１０４はセッション鍵ａｂＰを使用することに注意されたい。本明細書で解説されているように、ＫＭＳ１０６およびＫＭＡ１０８は、ａＰおよびｂＰを認識しているが、Ｅ上のディフィ−ヘルマン問題に鑑みると、いずれのエンティティもａｂＰを計算することは可能でない。
【０１０３】
Ｂ．ＧｏＦが３人以上の構成員を含むケース
ＧｏＦが３人以上の構成員から構成されるケースは、２人の構成員のみの上記のケースと非常に類似している。主な違いは、ＫＭＡ１０８と各々のＧｏＦ構成員との間で交換される情報のタイプに、および、ＧｏＦ鍵の導出にある。グループメッセージングによって、すべてのＧｏＦ構成員は同じ鍵を導出し、したがって、グループ構成員（例えばアリス１０２）により暗号化されるメッセージは、あらゆる他のグループ構成員により解読され得ることに留意されたい。公開鍵は、日付との連結の前に、クライアント識別情報に加えてグループ識別情報を含み得る。
【０１０４】
より具体的には、ＧｏＦ構成員がＫＭＳ１０６およびＫＭＡ１０８と通信するときはいつでも、以下の情報が取得される：
・各々のグループ構成員は、Ｐ２ＰメッセージングのケースでのようにＺｉ＝ｘｉＰの値を計算し、ただしＰは、上記で説明されたようなＮＩＳＴ楕円曲線Ｅ上の共通に一致された点である。Ｐ、Ｅ、および他の公開パラメータは自由に利用可能であり、一方でｘｉは、その日付に対する特定のＧｏＦ構成員に対応する乱数であることを想起されたい。Ｐ２Ｐメッセージングの状況でのように、あらゆるグループ構成員が、（例では１日ごとに１つ）これらのＤＨ鍵構成要素の複数の値を寄託する。このことによっていずれの構成員も、ＫＭＡ１０８と連絡し、すべてのＧｏＦ構成員のＤＨ鍵構成要素値を取得することが可能になる。このステップは、Ｐ２Ｐメッセージングのケースにおいて説明されたケースと同一である。
【０１０５】
・Ｚｉ＝ｘｉＰ（ただし下付き文字は第ｉのユーザを表す）に加えて、各々の構成員はさらに、ＫＭＳ１０６からｘｉ＋１Ｐおよびｘｉ−１Ｐの値を取得した後、Ｘｉ＝ｘｉ（ｘｉ＋１Ｐ−ｘｉ−１Ｐ）の値を算出し、その値を（一般には、１日ごとに１つ、または複数の値を）ＫＭＳ１０６に格納することになる。あるいはこれらのトランザクションは、クライアントが１日に１回ＫＭＡ１０８に「ログインする」とき、直接ＫＭＡ１０８によって遂行される場合があり、クライアントとＫＭＡとの間のセキュリティアソシエーションは、（Ｐ２Ｐメッセージングの構図でのように）ＩＢＡＫＥトランザクションを含むことになる。
【０１０６】
・Ｘｉの１つまたは複数の値が、ＫＭＡ１０８では新しくないときの状況が存在し得ることに留意されたい。そのような事例においては、（更新値が提供されるまでは）より古い値が使用される。しかしながら、すべての参加者が、自分の個人識別情報とともに「グループ識別情報」を使用することを考慮に入れると、Ｘｉの１つまたは複数の値が古くなっている確率は、（所与のグループ内の）あらゆるグループ構成員に強制的に、ＫＭＳ１０６と通信させ、すべての関連性があるトランザクションをおおよそ同時くらいに（例えば、お互いの１日または２日以内に、および新規の秘密鍵の使用に十分先立って）遂行させることにより劇的に最小限に抑えられる場合がある。あるいは追加的なグループ構成員が、誰でもオンラインである者によって、オンラインの構成員と新しい構成員との間に存在するＰ２Ｐ鍵を使用して、現在のグループ鍵を新しい構成員と共有することにより、ＧｏＦ内に一時的に参加が許される場合がある。
【０１０７】
・日単位（または、セキュリティ要件により指示されたような周期単位）で、ＫＭＡ１０８は、各々のＧｏＦ構成員に、あらゆる他の構成員のＺｉおよびＸｉの格納された値を提供する。より具体的には、アリス１０２がＫＭＡ１０８と連絡するときはいつでも、アリス１０２は、あらゆる他のＧｏＦ構成員のＺｉおよびＸｉの両方の値をセキュアに取得する。
【０１０８】
このことを考慮に入れると、ＧｏＦ構成員Ｕ１は、以下の式にしたがって導出される鍵Ｋ１を使用してメッセージＤ１を暗号化する（ただしＮはグループ内のユーザの数、すなわちＧｏＦの濃度である）：
Ｋ１＝Ｎｘ１（ＺＮ）＋（Ｎ−１）Ｘ１＋（Ｎ−２）Ｘ２＋…＋ＸＮ−１。
【０１０９】
そのような暗号化のために、任意の対称暗号（高度暗号化標準、すなわちＡＥＳなど）が使用され得ることに留意されたい。Ｄ１を暗号化することにより、Ｕ１は暗号テキストＣＤ１を生成し、（例えば図１でのメッセージングサーバ１１４を介して）アクセスネットワークによってすべての他のＧｏＦ構成員に暗号テキストＣＤ１を送出する。ＧｏＦに属するユーザＵ２、…、ＵＮは、それらのユーザの各々によりローカルに算出される鍵を使用することによりＣＤ１を解読することが可能である。具体的には、Ｎ−１人のユーザからの各々のユーザＵｉが、次式のように同じ鍵Ｋｉを算出する：
Ｋｉ＝Ｎｘｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋…＋Ｘｉ−２。
【０１１０】
この鍵は、暗号化のために使用されたものと同じ暗号を使用してメッセージを解読するために、対応するＧｏＦ構成員によりさらに使用される。
【０１１１】
次に図２に目を向けると、識別情報ベースの暗号化を用いるセキュアグループメッセージング方法論（プロトコル）２００が、本発明の実施形態によって例示されている。方法論は、１つのクライアント２０２（例えばアリス１０２またはボブ１０４）、ＫＭＳ２０４、およびＫＭＡ２０６の観点から例示されている（ＫＭＳ２０４がＫＭＳ１０６に関して上記で説明されたように機能し、一方でＫＭＡ２０６がＫＭＡ１０８と同じに動作することに留意されたい）。図２は、（３人以上のＧｏＦ構成員を伴う）グループメッセージングのシナリオを例示する。
【０１１２】
まず第１に、ＧｏＦが生成または規定されていることが想定される。ＧｏＦの各々の構成員は、自分たちの一意的な識別情報およびグループ識別情報（生成されたＧｏＦの識別情報）を日付とともに（すべてが連結された状態で）使用して、公開鍵を導出する。したがってグループ構成員の公開鍵（公開ｉｄ）は、グループｉｄ｜ユーザｉｄ｜日付のように算出され得る。
【０１１３】
ステップ２１０において、クライアント２０２は、ＫＭＳ２０４にクライアント２０２の公開鍵を送出し、ＫＭＳ２０４から１つまたは複数の秘密鍵を取得する。このステップは、図１において線１１０−Ａまたは１１０−Ｂによって図示される秘密鍵プロビジョニングに対応する。一実施形態では秘密鍵は、トランスポート層セキュリティ（ＴＬＳ）セッションによってＫＭＳ２０４からクライアントにより取得され得る。
【０１１４】
ステップ２１２において、クライアント２０２は、ＫＭＳ２０４にＤＨ鍵構成要素（Ｚ）を寄託する。これらの構成要素は、クライアントが上記で説明されたように計算するｘＰ（または上記で述べられたａＰもしくはｂＰ）値である。それらの値は、（周期性に応じて）ひと月の中のすべての日に対して計算され寄託される場合がある。すなわちユーザ「ｉ」は、（１日ごとに１つ）ｊ＝１から３０に対してのＺｉｊ＝ａｉｊＰを寄託することになる。
【０１１５】
次いでステップ２１４において、クライアント２０２は、ＫＭＡ２０６と（その日付に対するＺ値を用いて）ＩＢＡＫＥセッションを確立する。
【０１１６】
ＫＭＡ２０６から、ステップ２１６において、クライアント２０２は、ＧｏＦ内の他の構成員に対するその日付に対するＺ値を取得する。すなわちＫＭＡ２０６は、すべての日付「ｊ」に対して、ユーザ「ｉ」にＺｉ−１，ｊおよびＺｉ＋１，ｊを返送する。
【０１１７】
ステップ２１８において、クライアント２０２は、その日付に対してクライアント２０２のＸ値（クライアント２０２のセッション鍵寄与またはグループ鍵構成要素）を計算し、ＫＭＡ２０６にその値を寄託する（このことはＫＭＳ２０４によって代替的に行われる場合があることに留意されたい）。すなわちユーザ「ｉ」は、ＫＭＡ２０６にＸｉｊ＝ａｉ（Ｚｉ＋１−Ｚｉ−１）を返送する。
【０１１８】
ステップ２２０において、クライアント２０２は、他のユーザに対するその日付に対するＸ値をＫＭＡ２０６から受信する（すなわちクライアント２０２は、各々の他のユーザのセッション鍵寄与またはグループ鍵構成要素を受信する）。
【０１１９】
次いでクライアント２０２は、ステップ２２２において、各々の他の参加ユーザが行うように、グループセッション鍵を計算し（例えば、グループ鍵＝Ｎｘｉ（Ｚｉ−１）＋（Ｎ−１）Ｘｉ＋（Ｎ−２）Ｘｉ＋１＋…＋Ｘｉ−２）、次いでグループセッション鍵を使用して他のユーザに対するメッセージを暗号化することが可能である。このように例えば、グループ構成員間のＳＭＳ／ＭＭＳメッセージが、グループセッション鍵を使用してＡＥＳを用いて暗号化される。これらのメッセージは、メッセージングサーバ１１４（図１）を介して構成員間で伝達される。グループセッション鍵はＫＭＡ２０６またはＫＭＳ２０４に知られていない、すなわち、権限を与えられたグループ構成員のみがグループ鍵を算出可能であることに留意されたい。さらにグループ構成員は、他者がオンラインになるのを待つことなく、任意の所与の日に、暗号化されたメッセージを送出することが可能である。このシナリオにおいて導出されるグループセッション鍵（ＧｏＦ鍵としても知られている）は、「グループメッセージング鍵」とみなされ得ることに留意されたい。
【０１２０】
図２に示される非限定的な例では、ＫＭＳ２０４のトランザクションはひと月に１回遂行され得る。ＫＭＡ２０６のトランザクションは１日に１回であり得るものであり、そのことにより、グループ構成員数が毎日更新されることを確実にする。さらにステップ２１６からステップ２２０に関して、この実施形態では、転送されるメッセージはＩＢＡＫＥセッション鍵を使用してＡＥＳで暗号化されることを理解されたい。その上さらにステップ２２０は、ステップ２１６および２１８よりはるかに遅い時間に起こる場合がある。最適化が実装される場合がある。単に例として、ＫＭＡのトランザクションは、それらの最適化を現実に使用する前の日に遂行される場合がある。
【０１２１】
図３は、本発明の別の実施形態による識別情報ベースの暗号化を用いるセキュアグループメッセージング方法論（プロトコル）３００を例示する。図３は、Ｐ２Ｐメッセージング（ＧｏＦ内の２人の構成員）を例示することを十分認識されたい。したがって方法論３００は、方法論２００の特別なケースとみなされ得る。図２と同じように方法論３００は、１つのクライアント３０２（例えばアリス１０２またはボブ１０４）、ＫＭＳ３０４、およびＫＭＡ３０６の観点から例示されている（ＫＭＳ３０４がＫＭＳ１０６に関して上記で説明されたように機能し、一方でＫＭＡ３０６がＫＭＡ１０８と同じに動作することに留意されたい）。
【０１２２】
ステップ３１０、３１２、および３１４は、図２でのステップ２１０、２１２、および２１４と同じに動作し、したがってさらには説明されないことに留意されたい。
【０１２３】
Ｐ２ＰのケースではＧｏＦ内に唯一の他の構成員が存在するので、クライアント３０２、および他の構成員すなわちピアは、所与のピアツーピアセッションにおいて、他の当事者のＺ値（ｘＰ値）からセッション鍵（ＧｏＦ鍵）を計算する。この計算は、上記でセクションＩＢにおいて解説されているものと同じであり、すなわち、各々のピアがｘｙＰを計算し、このｘｙＰがセッション鍵として使用される（または上記で解説されたように、関数への入力として、セッション鍵を導出するために使用される）。
【０１２４】
したがって図３のプロトコル３００では、ＩＢＡＫＥセッションがクライアント３０２とＫＭＡ３０４との間で確立された後、クライアント３０２は、ステップ３１４において、クライアント３０２のアドレス帳内のユーザに対してその日付に対してＫＭＡ３０４からＺ値を取得することが可能である。おそらくは、クライアント３０２がメッセージを送ることを望むピア（例えばボブ）は、クライアント３０２のデバイスに格納されているクライアント３０２のアドレス帳に記載されている。そうでないならばステップ３１８において、クライアント３０２は、クライアント３０２のアドレス帳内にないユーザに対してその日付に対してＫＭＡ３０４から値を取得することが可能である。
【０１２５】
次いでステップ３２０において、クライアント３０２は、他のピアとのＰ２Ｐセッションのためのセッション鍵（ＧｏＦ鍵）、すなわちこのケースではｘｙＰを計算する。他のピアは、同じことを行うことになる。次いで、クライアント３０２と他のピアとの間のＳＭＳ／ＭＭＳメッセージが、Ｐ２Ｐセッション鍵を使用してＡＥＳなどの暗号化アルゴリズムを用いて暗号化される。これらのメッセージは、メッセージングサーバ１１４（図１）を介して構成員間で伝達される。Ｐ２Ｐセッション鍵はＫＭＡ３０６またはＫＭＳ３０４に知られていない、すなわち、クライアント３０２および他のピアのみがセッション鍵を算出可能であることに留意されたい。さらにクライアント３０２および他のピアは、他者がオンラインになるのを待つことなく、任意の所与の日に、暗号化されたメッセージを送出することが可能である。このシナリオにおいて導出されるＧｏＦ鍵は、「Ｐ２Ｐメッセージング鍵」とみなされ得ることに留意されたい。
【０１２６】
一例としてのユースケースは以下の通りである。任意の所与の日に、アリスは何人かの人々にメッセージを送出していることになる。メッセージを送出することは連絡情報を必要とし、最適化の事情としてアドレス帳は重要性をもつので、アリスの電話が１日の中で初めてウェイクアップするとき、セキュアメッセージングクライアントは容易に、ＫＭＡに登録し、アリスのアドレス帳内のすべての構成員に対してｘＰのすべての値を取得することが可能である。それらの値の一部は、人は常に毎日自分のアドレス帳内のすべての人にメッセージを送出するとは限らないので、所与の日には使用されない場合がある。逆に人は確かに、自分のアドレス帳内にない人々にもメッセージを送出する。ＩＢＡＫＥベースのセキュアにされたメッセージングを用いると、このことは、アドレス帳内にない人に対するｘＰ値を必要とすることになる。これに対して、メッセージングサービスのすべてのユーザが、自分のＺ値を（それらのＺ値をＫＭＡに提供する）ＫＭＳに寄託することが想定されているので、その後所与のクライアントは、サービスのユーザの誰ともセキュアに通信することが可能である。
【０１２７】
有利には詳細に上記で説明されたように、本発明の例示的な実施形態は、以下の解決策および特徴的機能を提供する：
（ｉ）何らかのメッセージング交換の前にアウトオブバンドで互いに何らかのセキュリティ証明データを交換することなく、２人以上のユーザがセキュアにメッセージを交換することを可能にする、アクセス技術に関して不可知である、２人以上のエンドユーザの間でのエンドツーエンドのセキュアグループメッセージングに対する軽量の識別情報ベースの暗号解決策。
【０１２８】
（ｉｉ）ＳＭＳ、ＭＭＳ、およびＩＭなどの標準的なＰ２Ｐメッセージング環境に加えて、上記で説明された解決策は、グループ鍵を使用して、ソーシャルネットワーキング環境において、および企業メッセージング環境において、グループメッセージング用途に適用される。
【０１２９】
（ｉｉｉ）とりわけ、（Ｐ２Ｐおよびグループのメッセージング用途に対する）セッション鍵の算出は、メッセージ（複数可）の受信者に、メッセージが創始されているときにオンラインであることを求めない。
【０１３０】
（ｉｖ）上記で説明された解決策は、メッセージングプロバイダのネットワークに内在する鍵管理エージェント（ＫＭＡ）であって、エージェントがメッセージング通信を漏れ聞くことが可能でないような形で、ユーザから鍵材料を取得し、ユーザに鍵材料を広める、鍵管理エージェント（ＫＭＡ）の概念を導入する。より一般的には、メッセージングプロバイダは、（鍵管理のサーバおよびエージェント、ならびに、他のバックエンドのデータベースおよびサーバの組み合わせによって）鍵管理のためのプラットフォームを提供するが、任意のメッセージを暗号化するために使用される鍵を知得する立場にはない。
【０１３１】
（ｖ）加えて上記で説明された解決策は、完全な順方向および逆方向の秘密性を達成し、ＫＭＡは、エンドツーエンドでプライバシーを保ちながら認証プロキシとして働く。
【０１３２】
ＩＩＩ．例示的なコンピューティングシステム
図４は、本発明の実施形態による２つ以上のエンティティ（当事者）間のセキュアグループメッセージング方法論（プロトコル）を実装するのに適した、ネットワーク環境、およびコンピューティングデバイスの形式での通信デバイスの一般化されたハードウェアアーキテクチャ４００を例示する。図４は２つのエンティティのみを示すが、他のエンティティが同じ構成を有し得ることを理解されたい。したがって上記で説明されたセキュアグループメッセージングプロトコルでいえば、２つのエンティティは、アリス１０２（第１の当事者またはＡ）およびボブ１０４（第２の当事者またはＢ）であり得る。これに対してＫＭＡ、ＫＭＳ、メッセージングサーバ、機能要素、追加的なクライアントデバイス（当事者）、および追加的なサーバは、図４のコンピューティングデバイスにおいて示されるのと同じアーキテクチャによって実装され得るものであり、したがって図４でのコンピューティングデバイスは、これらのシステム要素のうちの１つを表し得る。したがって簡単のために、本発明のプロトコルに参加し得るすべてのコンピューティングデバイス（通信デバイス）が図４に示されるわけではない。
【０１３３】
示されるように、４０２と指定されたＡのコンピューティングデバイス、および４０４と指定されたＢのコンピューティングデバイスは、ネットワーク４０６を介して結合される。ネットワークは、例えば上記で説明された実施形態でのように、その両端でデバイスが通信可能である任意のネットワークであってよく、ネットワーク４０６は、ネットワーク事業者（例えばＶｅｒｉｚｏｎ、ＡＴ＆Ｔ、Ｓｐｒｉｎｔ）により運営されるセルラー通信ネットワークなどの公衆アクセス可能な広域通信ネットワークを含み得る。しかしながら本発明の実施形態は、個々のタイプのネットワークに限定されない。典型的には、デバイスはクライアントマシンであり得る。本明細書で説明されるプロトコルに参加するために当事者により用いられ得るクライアントデバイスの例は、セルラー電話、スマートフォン、卓上電話、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータ等を含み得るが、それらに限定されない。これに対して、デバイスのうちの１つまたは複数はサーバであり得る。したがって、本発明の実施形態の通信プロトコルは、コンピューティングシステムがそれぞれクライアントおよびサーバであるケースに限定されるのではなく、代わりに、２つのネットワーク要素を備える任意のコンピューティングデバイスに適用可能であることを理解されたい。
【０１３４】
当業者には容易に明白となるように、サーバおよびクライアントは、コンピュータプログラムコードの制御のもとで動作する、プログラムされたコンピュータとして実装され得る。コンピュータプログラムコードは、コンピュータ可読記憶媒体（例えばメモリ）に記憶されることになり、コードは、コンピュータのプロセッサにより実行されることになる。そのようなコンピュータ可読記憶媒体は、非一時的なコンピュータ可読媒体とみなされる場合もある。本明細書の本開示を考慮に入れれば、当業者は、本明細書で説明されたプロトコルを実装するために、適切なコンピュータプログラムコードを容易に生み出すことが可能である。
【０１３５】
それでも図４は、ネットワークを介して通信する各々のコンピュータシステムに対する一例としてのアーキテクチャを一般的に例示する。示されるようにデバイス４０２は、Ｉ／Ｏデバイス４０８−Ａ、プロセッサ４１０−Ａ、およびメモリ４１２−Ａを備える。デバイス４０４は、Ｉ／Ｏデバイス４０８−Ｂ、プロセッサ４１０−Ｂ、およびメモリ４１２−Ｂを備える。用語「プロセッサ」は、本明細書では、１つまたは複数の信号プロセッサ、１つまたは複数の集積回路等々を含むがそれらに限定されない、中央処理装置（ＣＰＵ）または他の処理回路網を含む、１つまたは複数の処理デバイスを含むことが意図されることを理解されたい。さらに用語「メモリ」は、本明細書では、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えばハードドライブ）、またはリムーバブルメモリデバイス（例えばディスケットまたはＣＤＲＯＭ）などの、プロセッサまたはＣＰＵに関連するメモリを含むことが意図される。加えて用語「Ｉ／Ｏデバイス」は、本明細書では、処理装置にデータを入力するための１つまたは複数の入力デバイス（例えばキーボード、マウス）、および、処理装置に関連する結果を提供するための１つまたは複数の出力デバイス（例えばＣＲＴディスプレイ）を含むことが意図される。
【０１３６】
したがって、本明細書で説明された、本発明の方法論を遂行するためのソフトウェア命令またはコードは、関連するメモリデバイス、例えばＲＯＭ、固定メモリ、またはリムーバブルメモリのうちの１つまたは複数に記憶され得るとともに、利用される準備ができたときに、ＲＡＭにロードされ、ＣＰＵにより実行され得る。
【０１３７】
本発明の例示的な実施形態が、付随する図面を参照して本明細書で説明されたが、本発明はそれらの精密な実施形態に限定されないこと、ならびに、様々な他の変更および修正が、本発明の範囲または趣旨から逸脱することなく、当業者により行われ得ることを理解されたい。
【図１】
0005784833.tif 000004
【図２】
0005784833.tif 000005
【図３】
0005784833.tif 000006
【図４】
0005784833.tif 000007