"通信ネットワークにおいて2つ以上の通信デバイスのグループを登録するための方法であって、ネットワークデバイスから2つ以上の通信デバイスのグループにグループチャレンジメッセージを送信するステップと、ネットワークデバイスにおいて、それぞれ2つ以上の通信デバイスのグループの1つまたは複数からグループチャレンジに対する1つまたは複数の応答メッセージを受信するステップであって、グループ内の各々の応答通信デバイスからの応答メッセージはグループに対応するグループ資格情報を備えるステップとを備える、方法。グループ内のすべての通信デバイスがグループとしてオーセンティケータで相互に認証されるように、ネットワークデバイスがグループ内の通信デバイスから受信された応答を集約して、集約メッセージを通信ネットワーク内のオーセンティケータに送信する、請求項1に記載の方法。オーセンティケータが通信ネットワーク内のアプリケーションサーバである、請求項2に記載の方法。ネットワークデバイスがグループ内の通信デバイスを認証する、請求項1に記載の方法。ネットワークデバイスがグループ内の2つ以上の通信デバイスのアドレス割り当てを取得するステップをさらに備える、請求項1に記載の方法。グループの各通信デバイスが認証されると、通信デバイスがアプリケーションサーバとのデータセッションを確立する、請求項1に記載の方法。通信ネットワークにおいて2つ以上の通信デバイスのグループを登録する際に使用するための装置であって、ネットワークデバイスに関連付けられたメモリと、ネットワークデバイスに関連付けられ、メモリに結合されたプロセッサであって、2つ以上の通信デバイスのグループにグループチャレンジメッセージを送信し、それぞれ2つ以上の通信デバイスのグループの1つまたは複数からグループチャレンジに対する1つまたは複数の応答メッセージを受信するように構成され、グループ内の各々の応答通信デバイスからの応答メッセージがグループに対応するグループ資格情報を備えるプロセッサとを備える、装置。通信ネットワークにおいて2つ以上の通信デバイスのグループを登録するための方法であって、グループの通信デバイスの所与の1つにおいて、ネットワークデバイスにより2つ以上の通信デバイスのグループに送信されたグループチャレンジメッセージを受信するステップと、ネットワークデバイスがそれぞれ2つ以上の通信デバイスのグループの1つまたは複数から応答メッセージを受信するように、グループの通信デバイスの所与の1つからネットワークデバイスに、グループチャレンジに対する応答メッセージを送信するステップであって、グループ内の各々の応答通信デバイスからの応答メッセージがグループに対応するグループ資格情報を備えるステップとを備える、方法。通信ネットワークにおいて2つ以上の通信デバイスのグループを登録する際に使用するための装置であって、グループの通信デバイスの所与の1つに関連付けられたメモリと、グループの通信デバイスの所与の1つに関連付けられ、メモリに結合されたプロセッサであって、ネットワークデバイスにより2つ以上の通信デバイスのグループに送信されたグループチャレンジメッセージを受信し、ネットワークデバイスがそれぞれ2つ以上の通信デバイスのグループの1つまたは複数から応答メッセージを受信するように、ネットワークデバイスに、グループチャレンジに対する応答メッセージを送信するように構成され、グループ内の各々の応答通信デバイスからの応答メッセージがグループに対応するグループ資格情報を備えるプロセッサとを備える、装置。通信ネットワークにおいて2つ以上のユーザのグループを登録するための方法であって、ネットワークデバイスから2つ以上のユーザのグループにグループチャレンジメッセージを送信するステップと、ネットワークデバイスにおいて、それぞれ2つ以上のユーザのグループの1つまたは複数からグループチャレンジに対する1つまたは複数の応答メッセージを受信するステップであって、グループ内の各々の応答ユーザからの応答メッセージがグループに対応するグループ資格情報を備えるステップとを備える、方法。しかし、既存の登録の手法のいずれも、複数のクライアントが安全かつ効率的な方法で1つのシステムにアクセスすることができるリバースシングルサインオンreversesinglesign-onを可能にするメカニズムを提供することはない。複数のクライアントが安全かつ効率的な方法で1つのシステムにアクセスできるようにする課題に対処するための技法、ひいてはリバースシングルサインオンの課題の解決策を提供することが望ましい。本発明の実施形態は、複数のクライアントが安全かつ効率的な方法で1つのシステムにアクセスできるようにする課題に対処する通信デバイスのための自動安全登録技法を提供し、ひいてはリバースシングルサインオンの課題ならびに既存の登録手法のその他の欠点に解決策を提供する。たとえば、1つの態様において、通信ネットワークにおいて2つ以上の通信デバイスのグループを登録するための方法は、以下のステップを備える。ネットワークデバイスから2つ以上の通信デバイスのグループにグループチャレンジメッセージが送信される。ネットワークデバイスは、それぞれ2つ以上の通信デバイスのグループの1つまたは複数からグループチャレンジに対する1つまたは複数の応答メッセージを受信し、グループ内の各々の応答通信デバイスからの応答メッセージはグループに対応するグループ資格情報を備える。登録方法の一環として、グループの通信デバイスは次いで、グループとして認証されてもよい。その後、登録方法の一環として、認証された通信デバイスのグループは次いで、1つまたは複数のアプリケーションについてそれぞれのデータセッションをセットアップすることができる。ネットワークデバイスが、特定の実施形態に応じて通信ネットワーク内の異なるエンティティであってもよいことを理解されたい。たとえば、1つの実施形態において、ネットワークデバイスは、認証サーバであってもよい。別の実施形態において、ネットワークデバイスは、ゲートウェイエンティティであってもよい。さらに別の実施形態において、ネットワークデバイスは、基地局であってもよい。有利なことに、本発明の登録の技法は、複数のクライアントが安全かつ効率的な方法で1つのシステムにアクセスすることができるリバースシングルサインオンを達成するためのフレームワークおよび手順を提供する。言い換えれば、クライアントのグループは、1つの登録手順を使用して同一システムに安全に登録することができる。これにより、クライアント登録プロセスに関連する信号伝達の大幅な減少が可能になる。さらに、例示的な実施形態において、本発明の技法の1つの重要な特徴は、クライアントまたはデバイスのグループを安全に認証するために1つの登録手順が使用されるが、登録の結果として生成されるセッション鍵はクライアントにわたって同一とならないよう保証されることである。これにより、各クライアントは、グループ内のプライバシーを危険にさらすことなく、サーバ/ネットワークと安全に通信することができる。本発明の上記ならびにその他の目的、特徴、および利点は、添付の図面と併せて本発明の例示的な実施形態の以下の詳細な説明を読むことで明らかとなろう。以下の説明は、本発明を、マシン通信MTC:machine-type-communicationsとしても知られている、例示的なマシン間通信M2M:machine-to-machine環境のコンテキストにおいて例示する。しかし、本発明の原理はM2MまたはMTCのような環境に特に適しているが、本発明がそのような環境で使用することに限定されないことを理解されたい。つまり、本発明の原理は一般に、単一の登録手順を使用してデバイスユーザのグループの安全な登録機能を提供することが望ましい任意の通信環境に適用可能である。本発明の原理との使用に特に適する通信デバイスの1つのタイプは、オープンデバイスopendeviceと呼ばれる。オープンデバイスという語句は一般に、ネットワーク事業者による事前の承認なしにそのネットワーク事業者以外の任意のプロバイダからアプリケーションたとえば、ファームウェアまたはソフトウェアを実行することができるネットワーク内で動作する通信デバイスとして定義されうる。それらのタイプのデバイスの例は、センサー、ロケーションタグ、マシン、モニタ、およびメータを含むが、これらに限定されることはない。そのようなデバイスが使用可能にすることができるアプリケーションのタイプは、考え得る限りでは無限である。ほんの一例として、そのようなアプリケーション固有のデバイスは、ヘルスモニター、公益事業設備管理メータ、車両管理タグ、自動販売機、およびPOSpoint-of-sale:売り場端末を含むことができる。したがって、セルラーネットワーク事業者ほんの一例として、Verizon、ATT、またはSprintにより運用されるセルラーネットワークのような、公的にアクセス可能なワイドエリア通信ネットワークを介して安全に動作する、M2Mデバイスのような、オープンデバイスの環境は、本発明の例示的な実施形態が実施されうる環境である。本発明の例示的な実施形態によれば、フレームワークおよびプロトコルは、複数のクライアントが1つのシステムにアクセスすることができるリバースシングルサインオンと考えられうるものを達成するために提供される。前述のように、クライアントのグループは、1つの登録手順を使用して同一システムに安全に登録することができる。これにより、以下において詳細に説明されるように、クライアント登録プロセスに関連する信号伝達の大幅な減少が可能になる。本発明のフレームワークおよびプロトコルの1つの重要な特徴は、クライアントまたはデバイスのグループを安全に認証するために1つの登録手順が使用されるが、登録の結果として生成されるセッション鍵はクライアントにわたって同一とならないよう保証されることである。これにより、各クライアントは、グループ内のプライバシーを危険にさらすことなく、サーバ/ネットワークと安全に通信することができる。既存の手法は、グループ認証の課題への対処を試みてきたが、それらは、以下で詳細に説明されるように、すべてのデバイスを同一の認証エンティティオーセンティケータ:authenticatorのグループとして認証するのではなく、デバイスまたはユーザがグループのメンバーであることを確認するメカニズムに重点を置いていたことに留意されたい。以下の本発明の例示的な詳細にわたる説明は、M2MまたはMTCへのアプリケーションでグループ認証および鍵合意を実行するための安全なフレームワークについて述べているが、フレームワークは、グループ登録が道理にかなうようなその他のアプリケーションに対処するために実施されてもよいことを理解されたい。一例として、MTCに適用される本発明のフレームワークにより、NOネットワーク事業者および/またはM2MOM2M事業者は、グループ化ポリシーに従ってグループ分けされるデバイスのセットを認証することができるようになる。したがって、各M2Mデバイスを個々に認証するために、M2Mデバイスごとに個別のセッションを確立する必要はない。対照的に、本発明のフレームワークは、特定のグループに属するデバイスを一度に認証し、それによりかなりの程度まで認証手順の複雑さおよび帯域幅要件を軽減する。参照を容易にするため、詳細な説明のこれ以降の部分は、以下のように分割される。セクションIでは、本発明の例示的な実施形態によるグループ登録フレームワークの概略を説明する。セクションIIでは、本発明の例示的な実施形態に関連付けられている設計の前提を説明する。セクションIIIでは、本発明の例示的な実施形態による安全なグループ登録プロトコルの詳細を説明する。セクションIVでは、本発明の例示的な実施形態による1つまたは複数の安全なグループ登録プロトコルを実施するための例示的なコンピューティングシステムを説明する。I.グループ登録フレームワークの概要N個の通信デバイスの配置、ならびに認証エンティティオーセンティケータが、それらのデバイスの1つまたは複数のサービスへのアクセスを許可する前に、それらのデバイスの各々を認証する必要があることを検討する。既存のプロトコルでは、オーセンティケータは、個々のセッションを確立して、各デバイスと固定数の認証メッセージを交換する必要がある。したがって、配置がN個のデバイスを含む場合、およびオーセンティケータと各デバイス間でk個のメッセージが交換される必要がある場合、それらのデバイスすべてが認証されるためには、合計Nk個のメッセージが無線で伝送される必要がある。一例として、N=100、000とし、オーセンティケータがAKA相互認証プロトコルそれらの開示を引用により全体として本願に援用する、3GPPTS33.102、TechnicalSpecificationGroupServicesandSystemAspects;3GSecurity;SecurityArchitectureRelease9、および3GPPTS33.401、TechnicalSpecificationGroupServicesandSystemAspects;3GPPSystemArchitectureEvolutionSAE;SecurityArchitectureRelease9において説明されるようにを使用すると仮定する。AKAプロトコルに従って、オーセンティケータはユーザ認証要求をクライアントに送信するが、このユーザ認証要求はランダムチャレンジRANDおよび認証トークンAUTNを含み、したがってこの場合k=2である。その結果、既存の手法では、200、000の個々のメッセージが全体として必要となる。この全プロセスの最後に、N個のデバイスの各々はセッション鍵を生成する、すなわち、既存の手法では、合計100、000個のセッション鍵がオーセンティケータと各デバイス間で相互に生成されることになる。1つのオーセンティケータの代わりに、異なるタイプのサービスを各々許可する複数のオーセンティケータが存在しうることに留意されたい。そのような場合、既存の手法では、すべてのデバイスは、オーセンティケータの各々と個別の認証処理を独立して保持することが必要になる。幸いなことにそのようなシナリオでは、シングルサインオンという概念が使用されてもよく、デバイスはその開示内容が引用により全体として本明細書に援用される、R.Cox、E.GrosseおよびR.Pike、SecurityinPlan9、USENIX、2002年において説明されるように資格情報の単一のセットを使用して多種多様なオーセンティケータで認証することができる。しかし、多数のクライアントが単一のオーセンティケータにより認証される必要がある場合には、個々のデバイスデータの機密性が保持される必要があるので、登録中にすべてのデバイスが異なるセキュリティ資格情報を生成する必要があり、シングルサインオンは好ましくない。上記の説明を考慮して、本発明の例示的な登録の技法は、N個のデバイスのグループが単一登録手順を使用してどのように認証されうるかの問題に対処する。具体的には、この問題に対処する解決策の目標は、リバースシングルサインオンメカニズムを設計することであり、このメカニズムにより、N個のデバイスをグループとして認証しそれによりN個の相互セッション鍵を生成し、同時に以下の事項に適合することができる:1個々のデバイスの認証の場合と同じセキュリティの強さを確保する。2デバイスデータが他のデバイスたとえ同一グループに属するものであってもから引き起こされた潜在的な攻撃に対して保護されるように、デバイスごとに個別な一意の鍵を確立する。3より少ない数の認証メッセージを使用する、好ましくは、単一認証処理の場合と同様に多くのメッセージを同じ帯域幅を使用してオーセンティケータと交換する。本明細書において説明される本発明のフレームワークおよびプロトコルは、前述の目標を達成する。この解決策の1つの実施形態において、アーキテクチャ設計の主な態様は、以下の通りである:1GWGateWayと称する新しいネットワークエンティティを導入する。GWはアグリゲータであり、グループに属するすべてのデバイス本明細書においてユーザ機器またはUEとも称されるからの認証応答を収集する。通常、GWは、グループのデバイスに比較的接近して配置される。2グループ認証の目的で、グループのすべてのデバイスは、認証メッセージをGWとのみ交換する。GWはさらに、グループ内の各デバイスの資格情報を確認するためにオーセンティケータとのネゴシエーションを実行する責任を負う。1つの実施形態において、フレームワークはまた、GWがオーセンティケータとなることを可能にする。このために、GWは、グループ内のすべてのデバイスを認証するために使用される必要な情報を受信する必要がある。この後者の実施形態が、帯域幅を節約するため、および全体として必要な信号伝達を大幅に低減するために好ましいことに留意されたい、3デバイスのグループを認証するために、登録に先立ち特にグループ鍵のグループ資格情報がプロビジョニングされ、それらはグループ内のすべてのデバイスに対して同一である。フレームワークの設計は、異なる代替のグループ認証手順を含み、手順は各々、ネットワーク事業者のプリファレンスに基づいて適用されてパラメータ化されてもよい。選択される実際の手順に応じて、グループ資格情報は、各デバイスまたはGWのいずれかに提供されてもよい。グループ認証処理は、グループチャレンジに基づき、GWはグループチャレンジメッセージをグループ内のすべてのデバイスにブロードキャストする。デバイスは、GWへのメッセージでこのチャレンジに個別に応答する。グループ資格情報はグループ認証に使用されるが、それらの資格情報および個々の資格情報は共に、以下において説明されるように、一意の暗号および完全性保護鍵素材を生成するために各デバイスによって使用される。4GWとグループ内の各デバイス間の通信は、好ましくは、無認可の帯域幅たとえば、ZigBee、WiFiなどに割り振られた帯域幅を使用する。この手法により、ネットワーク事業者に割り振られる認可帯域幅を使用するアクセスネットワークとGWとの間に必要とされる信号伝達は、はるかに少なくなる。本発明の解決策の異なる1つの実施形態において、グループ認証操作は、GWがない場合に適用される。そのような場合、グループチャレンジをブロードキャストして、各デバイスから個々の応答を受信することが、基地局の責任である。ここでは、基地局が個々の一意のチャレンジを各デバイスに送信するのではなく、単に1つのメッセージをブロードキャストする必要があるので、グループ認証が引き続き有益である。しかし、チャレンジ応答はアクセスネットワーク事業者の帯域幅でデバイスにより伝送されるので、グループ認証に起因する利点は、GWを使用する場合のように大きくはない。有利なことに、本発明のグループ認証フレームワークが先例のないネットワークパフォーマンスの利点をもたらすことができることは明らかである。このことは、多数のデバイスが1つまたは複数のネットワークエンティティに登録する必要があるようなシナリオにおいて、特に当てはまると予想される。II.設計の前提事項本明細書において説明される本発明の例示的なフレームワークは、以下の前提に基づいて設計される:1デバイスは、特定のポリシーに基づいてグループ化され、デバイスの属するグループ複数可を認識する。ポリシー作成手順およびそのようなポリシーの展開に関与するネットワークエンティティの機能は、このフレームワーク設計の範囲を超える。言い換えれば、このフレームワークは、それに基づいてクライアントデバイスのグループが形成されるポリシーに非依存である。2N個のデバイスのグループは、グループ識別子または識別情報IDによって表され、これはグループ認証処理に関与するすべてのネットワークエンティティに知られており、ネットワークエンティティは個々のデバイスを認証するために使用されるエンティティと同一のエンティティである。それらのエンティティはまた、そのようなグループに属するすべてのデバイスの識別情報を認識している。そのような情報は、ルックアップテーブルの形態ですべてのエンティティにローカルに格納されてもよい。エンティティがそれらのローカルに格納されたルックアップテーブルのコンテンツに関して同期されると仮定する。3グループに属する各通信デバイス以下の詳細な説明においてユーザ機器またはUEとも称されるは、無認可のスペクトルたとえば、ZigBeeを使用して、ローカルゲートウェイGWとのワイヤレス接続を保持する。始めに、UEが、登録の目的で3GPP対応のインターフェイスを装備していないと仮定する。したがって、グループ認証および鍵合意を目的とするUEとネットワーク間の任意の制御またはデータトラフィックは、GWを経由する。UEが3GPPもしくは3GPP2またはWIMAX対応のインターフェイスを装備している場合、基地局はGWの役割を果たす。4場合によっては、UEは特定の資格情報グループ鍵と称され、以下で説明されるを事前にプロビジョニングされており、UEはグループ認証中に認証および鍵素材を生成するために使用する。別の場合では、GWのみがグループ鍵を認識するが、UEは認識しない。5GWが接続される3GPPネットワークは、UMTSUniversalMobileTelecommunicationsSystemネットワークである。6UEグループ認証の1つの利点は、リモートアプリケーションサーバとデータセッションをさらに確立することにある。このサーバがすでに3GPPネットワークと相互に認証していると仮定する。7UEとGW間のリンクがリンク層において保護されていると仮定する。したがって、UEとGW間の任意の通信は、リンク層資格情報を使用して暗号化される可能性がある。図1は、そのような本発明によるフレームワークおよびプロトコルを提供するための1つのシステムを示す。通信ネットワーク100の一部に示されるように、グループ102を構成する複数の通信デバイスまたはユーザ機器UE101-1、101-2、...、101-Nは、ゲートウェイデバイスGW104と称されるネットワークデバイスに動作可能に結合される。グループは、これより多くのUEまたはこれより少ないUEを含むことができる。GW104は、NodeB106と称される基地局およびアプリケーションサーバ108に動作可能に結合される。知られているように、NodeBは、UMTSの用語による基地局であり、GSMGlobalSystemforMobileCommunicationsの用語で使用されるBTS送受信基地局:basetransceiverstationと等価である。したがって、ネットワーク要素106は、NodeBまたはBTS、もしくはアクセスされる通信ネットワークに応じた任意の形態の基地局であってもよい。UEが携帯電話であるアプリケーションにおいて、NodeBは、携帯電話ネットワークに接続され、通常携帯ハンドセットと直接通信するネットワークデバイスである。しかし、図1の実施形態において、GW104は、UEと直接通信する。NodeBは通常、エアインターフェイス技術としてWCDMA/TD-SCDMA広帯域符号分割多元接続/時分割同期符号分割多元接続:WidebandCodeDivisionMultipleAccess/TimeDivisionSynchronousCodeDivisionMultipleAccessを使用する。NodeB106は、サービス提供GPRSサポートノードSGSN:ServingGPRSSupportNode110に動作可能に結合される。SGSNは、汎用パケット無線サービスGPRS:GeneralPacketRadioServiceネットワークの主コンポーネントであり、通常は、たとえばモビリティ管理およびユーザの認証など、ネットワーク内のすべてのパケット交換データを処理する。しかし、以下で説明されるように、認証はGW104に従って実行される。SGSN110は、ホームロケーションレジスタHLR:HomeLocationRegisterとしても知られているホーム加入者サーバHSS:HomeSubscriberServer112に動作可能に結合される。HSS112は、移動加入者ユーザからの情報が格納されるデータベースである。HSSは通常、加入者の識別情報に関する情報、電話番号、関連サービス、および加入者の位置に関する一般情報を含む。加入者の正確な位置は、通常ビジターロケーションレジスタVLR:VisitorLocationRegister、図示せずに保持される。III.グループ認証フレームワークおよびアプリケーション本発明の1つの実施形態によれば、グループ認証フレームワークは、5つの主要ネットワークフレームワークモジュールから成る。本明細書において使用されるモジュールという用語は、図1に示されるネットワークコンポーネントすなわち、UE101、GW104、NodeB106、アプリケーションサーバ108、SGSN110、およびHSS112の1つまたは複数に従って実行される主要機能を指すことが意図されることを理解されたい。図2は、ネットワークフレームワーク200のモジュールを示す。ネットワークフレームワークモジュールの各々はさらに、以下のサブセクションAからEにおいてそれぞれ説明される。示されているように、3GPPネットワークによるGW登録、およびM2Mアプリケーションサーバによる接続確立のためのフレームワークモジュール202以下のサブセクションAにおいて説明されるが提供される。次の認証に関してUEのグループに通知するためのフレームワークモジュール204以下のサブセクションBにおいて説明されるが提供される。グループ認証プロトコル動作を実行するフレームワークモジュール206以下のサブセクションCにおいて説明されるが提供される。IPインターネットプロトコルアドレスをグループに属するUEに提供するフレームワークモジュール208以下のサブセクションDにおいて説明されるが提供される。3GPPネットワークによるグループ認証が正常に完了した後、M2Mアプリケーションサーバ図1の108にデバイスのグループを登録するためのフレームワークモジュール210以下のサブセクションEにおいて説明されるが提供される。次いで、例示的な実施形態において、図2の各フレームワークモジュールの機能の一部が、図1のネットワークコンポーネントのうちの2つまたはそれ以上において実行されることを理解されたい。このことは、各々のサブセクションAからEにおける説明から明らかとなろう。しかし、また、本発明が、以下において例示的に説明されるモジュール機能の分散に限定されることを意図するものではないことも理解されたい。むしろ、1つのコンポーネントで実行されるように示される1つの機能は、たとえばSGSN110で実行されるように示されるフレームワークモジュールの機能が代替としてGW104で実行されてもよい、というように、代替として別のコンポーネントで実行されてもよい。これ以降、例示的なグループ認証フレームワークのモジュラー設計を詳細に示す。説明を分かりやすくするため、特定数NのM2Mデバイスの配置を仮定するその開示内容が引用により全体として本明細書に援用される、3GPPTS22.368、TechnicalSpecificationGroupServicesandSystemAspects;ServiceRequirementsforMachineTypeCommunicationsMTC;Stage1Release10において説明されるように。上記の説明に沿って、NOネットワーク事業者および/またはM2MOM2M事業者は、グループ化ポリシーに従ってグループ分けされるN個のM2Mデバイスのセットを認証することができるようになる。したがって、各M2Mデバイスを個々に認証するために、M2Mデバイスごとに個別のセッションを確立する必要はない。対照的に、本発明のフレームワークは、特定のグループに属するM2Mデバイスを一度に認証し、それによりかなりの程度まで認証手順の複雑さおよび帯域幅要件を軽減する。本発明のフレームワークの5つの主要モジュールの各々について、以下のサブセクションAからEにおいてそれぞれ説明する。A.GWと3GPPネットワーク間の相互認証図2のフレームワークモジュール202UE101-1、101-2、...、101-Nを認証する前に、GW104が最初に認証される必要がある。加えて、GWは、ネットワークも信頼できることを確認する必要がある。ネットワークという用語は本明細書において、ゲートウェイがUEのアクセスポイントとしての機能を果たすUMTSネットワーク3GPPを意味するたとえば、NodeB106、アプリケーションサーバ108、SGSN110、HSS112など。この認証のために、1つの実施形態において、認証および鍵合意AKA:AuthenticationandKeyAgreement手順が採用される。たとえば、UMTSネットワークが考慮される限りは、GW104を3GPPクライアントUEとして処理して、開示を引用により全体として本願に援用する3GPPTS33.102において説明されるAKA手順が採用されてもよい。図3は、このGWおよび3GPPネットワークの相互認証手順のステップを示す。示されているように、相互認証手順300は、以下のステップを含む:1.GW104は、登録要求をSGSN110に送信するステップ302。2.SGSN110は、GW104に代わって認証要求をHSS112に送信するステップ304。3.HSS112は、1つまたは複数の認証ベクトルを含む認証応答をSGSN110に送信するステップ306。4.SGSN110は、ベクトルの1つを使用して、乱数RANDおよび認証トークンAUTNを含むチャレンジをGW104に送信するステップ308。5.GW104は、チャレンジを受信して、AUTHを確認し、成功すると応答RESをSGSN110に送信するステップ310。6.SGSN110は、RESを受信して、RESを、使用される特定の認証ベクトルに含まれているXRESと比較するステップ312。7.RES=XRESである場合、GW104はその正統性を確認され、SGSN110は、認証結果をGW104に送信し、確認の成功についてGW104に知らせるステップ314。8.GW104は、AUTNを使用して、3GPPTS33.102に従って、ネットワークを認証するステップ316。SGSN110がXRES=RESであると仮定し、GW104もまたAUTNの正統性を確認すると仮定すると、このプロセスの最後に、3GPPTS33.102に従って、相互認証が成功したと見なされ、GW104およびRANDとの両方によりサポートされる暗号化アルゴリズムを使用して、暗号鍵CKiおよび完全性鍵IKiが生成され、後続のパケット交換を暗号化および完全性保護するために使用される。加えて、GW104が正常に認証されることを所与として、PDPパケットデータプロトコル:PacketDataProtocolコンテキストはGW104とGGSN/SGSN110間で確立され、それによりGW104はリモートM2Mアプリケーションサーバ108との潜在的に安全なセッションを確立することができる。そのようなセッションが確立される1つの手段は、以下において説明される。B.次の認証に関してUEのグループを通知する図2のフレームワークモジュール204図1におけるようなM2Mデバイス101-1、101-2、...、101-Nのグループ102が認証されるために、グループのすべてのデバイスは、同時にアクティブアライブである必要がある、すなわちGW104とアクティブな接続を保持する必要がある。しかし、各デバイスのアプリケーションおよびソフトウェア構成に応じて、グループ内の一部のデバイスがスリープモードにある可能性もある。たとえば、一部のM2Mアプリケーションスマートメータアプリケーションなどでは、M2Mデバイスが所定の時間間隔でウェイクアップして、M2Mアプリケーションサーバ108への接続を確立し、それらのデータをアップロードすることを必要とする。そのようなデバイスのグループを認証するため、グループのすべてのデバイスがアライブ状態である必要がある。本発明のフレームワークは、認証のためにグループのデバイスを準備させる4つの例示的な手段を提供する。以下のサブセクションにおいて、それらの手段について説明する。GW104とUE101-1、101-2、...、101-N間を通過するメッセージが、以下で説明されるように、図1のUEとGWを接続することが示されるリンクを介して渡されることを理解されたい。B1.M2Mアプリケーションサーバ発信のウェイクアップ信号伝達この手法により、M2Mアプリケーションサーバ108またはHSS112は、特殊なウェイクアップアクティブ化メッセージをGW104に通信する。このウェイクアップメッセージは、認証されるべきグループのIDを含む。GW104は、このメッセージを受信すると直ちに、そのローカルに格納されているルックアップテーブルを使用して、特定のグループに属するUEのセットを導き出す。その後、GW104は、ブロードキャストメッセージたとえば、ZigBeeメッセージを、特定のIDを持つグループのデバイスのすべてに伝送する。本発明の原理は任意の特定の通信規格を使用することに限定されないが、本明細書において説明される一部の例示的な実施形態において、使用される通信規格はZigBee規格であることを理解されたい。知られているように、ZigBeeは、IEEE802.15.4-2003規格に基づく小型の低電力の通信デバイスを使用する高水準通信プロトコルのスイート向けの仕様である。用語は、ZigBee仕様2006年バージョンにより定義され、その開示は引用により全体として本明細書において援用する。ZigBeeAllianceは、ZigBee規格を保持し公開する企業のグループであるhttp://www.zigbee.orgを参照。UEは、このメッセージを受信すると直ちに、それが特定のグループの一部であるかどうかを決定する。グループの一部である場合、GW104との接続たとえば、ZigBee接続をさらに確立または復元する。このプロセスの最後に、グループのすべてのデバイスは認証処理に参加できる状態になり、共通暗号鍵たとえば、ZigBee鍵KZBが確立される。B2.所定の時間間隔でスケジュールされる登録ウェイクアップメッセージを使用してデバイス101-1、101-2、...、101-Nのグループに通知する代わりに、デバイスは、認証処理に参加するために特定の時間間隔で自発的にウェイクアップするようにスケジュールされてもよい。そのような手順には、デバイスとGW104との間で緩い時間同期化が必要となる。スケジュールされるウェイクアップの時間は、製造時において事前にプロビジョニングされるか、または無線によりプロビジョニングされてもよい。UEは、ウェイクアップすると直ちに、前述のサブセクションB1において説明されるように、GWとのZigBee接続を確立する。そのような手順により、グループは、UEとM2Mアプリケーションサーバ108との間にトラフィックがほとんどないか、または全くないときに認証されてもよいことに留意されたい。したがって、UEのグループが認証され、それらのIPアドレスを割り当てられる限りにおいて、UEのグループはスリープモードに戻ることができ、ウェイクアップしたとき、UEのグループはそれらの割り当てられているIPアドレスを使用してM2Mアプリケーションサーバ108へのデータ接続を確立することができる。B3.GWにおける認証素材のキャッシング上記の2つの手法は、すべてのUEが一度にウェイクアップし、GWとのZigBee接続を同時に確立することを規定する。しかし、そのような手順は、特にグループが多数のUEで構成されるような場合センサーネットワーク配置の場合など、各UE101とGW104との間のリンクに特別な制御信号伝達のオーバーヘッドを課す。同一グループに属す多数のM2MデバイスがそれらのデータをサーバGW104に送信することをM2Mサーバが要求するようなシナリオにおいて、そのようなデバイスは同時にそろってウェイクアップするようにスケジュールされるのではなく、それらのスケジュールに何らかの遅延を伴うことになることが予想される。そのため、GW104は過負荷状態にはならない。一方、グループを認証するために、グループに属するすべてのデバイスがアライブ状態である必要があることに再度言及する。このため、このフレームワークは、GW104において認証素材をキャッシュに入れるオプションを提供する。特に、グループ102からの第1のUE101がウェイクアップして、グループ認証の目的のためGW104とのZigBee接続を確立すると直ちに、GW104はコアネットワークに認証素材を要求するこの手順は以下のサブセクションCにおいて説明される。加えて、GW104は、グループ認証処理が開始されうるように、グループのすべてのUEがアライブ状態になるまでこの素材をキャッシュに入れる。キャッシュに入れられたパラメータG_AUTNおよびG_RANDならびにこれらがGW104により使用される手段は、以下のサブセクションCにおいて説明される。B4.認証素材のキャッシングおよびGWにおけるローカルなグループ認証このフレームワークはまた、GW104が意図されるデバイスのグループを認証するためのメカニズムを、GWがそのようなタスクを実行できる限りにおいて提供する。言い換えれば、GW104はこれ以降、iデバイスのグループが正統であることを確認すること、およびii認証の結果を3GPPコアネットワークエンティティNodeB106、SGSN110、HSS112など、およびM2Mアプリケーションサーバ108にレポートすることに責任を負うことになる。同様に、サブセクションB3において上記で説明されるように、GW104は、認証パラメータのセットを受信してキャッシュに入れる。しかし、ここでGW104は、認証処理をローカルに実行するために、追加のパラメータG_XRESと呼ばれるをキャッシュに入れる必要がある。そのようなプロセスがどのように実行されるのかを、以下のサブセクションにおいて説明する。C.グループ認証プロトコル図2のフレームワークモジュール206グループ認証プロトコルは、対象となるグループ内のすべてのUEがアライブ状態であり、アクティブなZigBeeセッションを確立していることをGW104が確認すると、直ちに開始される。以下において、このプロトコルの5つの例示的な実施形態を提示する。C1.SGSNがグループ内のデバイスの正統性を確認するこの手法は、図4Aに示される。プロトコル400により、GW104は、グループのすべてのデバイスから認証応答を収集して、それらの応答を確認のためにSGSN110に転送する。特に、プロトコルのステップは以下のとおりである:1.GW104は、グループ登録要求をSGSN110に送信するステップ402。2.SGSN110は、この要求をHSS112に転送するステップ404。3.HSS112は、1つまたは複数のグループベクトルVを生成して、SGSN110に送信するステップ406。そのようなベクトルは、以下のような形態をとる。V={G_AUTN,G_RAND,[XRES1,CK1,IK1],[XRES2,CK2,IK2],...,[XRESN,CKN,IKN]}これらのパラメータは、3GPPTS33.102の場合と同様に定義される。4.SGSN110は、G_RANDおよびG_AUTNを含むグループ認証応答をGW104に送信するステップ408。GW104が、上記のセクションB3およびB4で説明されるように、G_RANDおよびG_AUTNをキャッシュに入れることができることに留意されたい。5.GW104は、グループ鍵KGを使用して作成されたG_AUTNを確認するステップ410。この鍵は、UEには知られておらず、すでにGWに提供されている。6.GW104は、G_RANDを含むZigBeeブロードキャストメッセージをUEに送信するステップ412。このメッセージは、上記で言及したZigBee規格に従って、KZBで暗号化される。7.各UE101は、このメッセージを受信し、RESiを計算して、このRESiをGW104に送信するステップ414。8.GW104は、すべてのRESi応答をUE101から収集して、それらをSGSN110に送信するステップ416。ここで、GW104は、UE101からの個々の応答を転送するか、またはより少ない、より大きいメッセージにその応答を集約してSGSN110に転送することができる。9.SGSN110はグループベクトルを使用して各応答を確認し、次いでSGSN110は、グループ認証結果をGW104に送信するステップ418。このメッセージは、各UEの認証結果を含む。10.すべてのUE101が正常に認証された場合、GW104は単に成功メッセージをすべてのUEにブロードキャストする。それ以外の場合、GW104は、iどのUEが正常に認証されたかに関する情報を含む成功メッセージをブロードキャストする、およびiiどのUEが確認されなかったかに関する情報を含むエラーメッセージを、失敗の原因と共にブロードキャストするステップ420。あるいは、成功メッセージは省略されてもよく、正常に認証されたUE101は、それらのIDがエラーブロードキャストメッセージに含まれているかどうかを検査することにより、認証の成功を認識することができる。各UE101は、ブロードキャストメッセージの受信をGW104に個々に通知し、GW104は共通の確認応答メッセージをSGSN110に転送する。11.正常に認証されたUE101は、個々のKi鍵を使用して、CKiおよびIKi鍵を計算するステップ4223GPPTS33.102を参照。C2.HSSがグループ内のデバイスの正統性を確認するこの手法は、図4Bに示される。HSS112が、上記のサブセクションC1のステップ9に従って、UE101の応答を確認するために認証ベクトル複数可をSGSN110に提供する代わりに、HSS112は代替として、RESi応答の確認を実行することができる。この場合、SGSN110は、[XRES1,CK1,IK1]を認識している必要はない。この場合明らかなように、GW104は、SGSN110を通じて、UE101からHSS112にRESi応答を送信する。さらに具体的には、この場合のプロトコル430のステップは以下のとおりである:1.GW104は、グループ登録要求をSGSN110に送信するステップ432。2.SGSN110は、この要求をHSS112に転送するステップ434。3.HSS112は、グループベクトルVをSGSN110に送信するステップ436。このベクトルは、V={G_AUTN,G_RAND}の形態をとる。これらのパラメータは、3GPPTS33.102の場合と同様に定義される。4.SGSN110は、G_RANDおよびG_AUTNを含むグループ認証応答をGW104に送信するステップ438。GW104が、上記のセクションB3およびB4で説明されるように、G_RANDおよびG_AUTNをキャッシュに入れることができることに留意されたい。5.GW104は、グループ鍵KGを使用して作成されたG_AUTNを確認するステップ440。この鍵は、UEには知られておらず、すでにGWに提供されている。6.GW104は、G_RANDを含むZigBeeブロードキャストメッセージをUE101に送信するステップ442。このメッセージは、ZigBee規格に従って、KZBで暗号化される。7.各UE101は、このメッセージを受信し、RESiを計算して、このRESiをGW104に送信するステップ444。8.GW104は、すべてのRESi応答をUE101から収集して、それらをSGSN110に送信するステップ446。ここで、GW104は、UE101からの個々の応答を転送するか、またあるいはより少ない、より大きいメッセージにその応答を集約してSGSN110に転送することができる。9.SGSN110は、これらの応答をHSS112に転送するステップ448。10.HSS112は各応答を確認するために選択されたグループベクトルを使用し、次いで、HSS112はグループ認証結果をSGSN110に送信し、SGSN110はこのメッセージをさらにGW104に転送するステップ450。このメッセージは、各UE101の認証結果を含む。11.すべてのUE101が正常に認証された場合、GW104は単に成功メッセージをすべてのUE101にブロードキャストする。それ以外の場合、GW104は、iどのUEが正常に認証されたかに関する情報を含む成功メッセージをブロードキャストする、およびiiどのUEが確認されなかったかに関する情報を含むエラーメッセージを、失敗の原因と共にブロードキャストするステップ452。あるいは、成功メッセージは省略されてもよく、正常に認証されたUE101は、それらのIDがエラーブロードキャストメッセージに含まれているかどうかを検査することにより、認証の成功を認識することができる。各UE101は、ブロードキャストメッセージの受信をGW104に個々に通知し、GW104は共通の確認応答メッセージをHSS112に転送する。12.正常に認証されたUE101は、個々のKi鍵を使用して、CKiおよびIKi鍵を計算するステップ4543GPPTS33.102を参照。C3.UEはグループ鍵を認識するが、GWはグループ鍵を認識せず、SGSNはグループ内のデバイスの正統性を確認する。手順C1およびC2は、GW104が個々のRESi値をSGSN110C1によりまたはHSS112C2によりにも送信する必要があるので、オーバーヘッドが増大する。数千のデバイスがGWと通信しうる可能性もあるセンサーの場合のようにグループが多数のデバイスから成るシナリオにおいて、GWと3GPPネットワーク間のリンクは過剰に使用されることになる。代替のプロトコル460は、図4Cにおいて説明される。ここでは、すべてのUEが共通のKG鍵を認識すると仮定される。1.GW104は、グループ登録要求をSGSN110に送信するステップ462。2.SGSN110は、この要求をHSS112に転送するステップ464。3.HSS112は、1つまたは複数のグループベクトルを生成して、SGSN110に送信するステップ466。そのようなベクトルは、以下のような形態をとる:V={G_AUTN,G_RAND,G_XRES,[MTC_CK1,MTC_IK1],...,[MTC_CKN,MTC_IKN]}4.SGSN110は、G_RANDおよびG_AUTNを含むグループ認証応答をGW104に送信するステップ468。GW104が、上記のセクションB3およびB4で説明されるように、G_RANDおよびG_AUTNをキャッシュに入れることができることに留意されたい。5.GW104は、G_AUTNおよびG_RANDを含むZigBeeブロードキャストメッセージをすべてのUE101に送信するステップ470。この場合、KGを提供されていないので、GWがG_AUTNを確認できないことに留意されたい。6.各UE101は、個々にG_AUTNを確認するステップ472。7.各UE101は、G_RESを含むメッセージで応答するステップ474。G_RESの値は、提供されたKG鍵を使用して計算される。この鍵はUE101およびHSS112にのみ知られており、GW104には知られていないことを再度言及する。また、各UE101が同じG_RANDを受信し、KGを有するので、各正規のUE101はG_RESの同じ値を計算すべきであることにも留意されたい。8.GW104は、UE101からの応答をSGSN110に送信するステップ476。明らかに、このメッセージは、GW104が同じG_RES値を提供したUE識別情報をグループ化できるので、C1およびC2の場合よりもはるかに少ない帯域幅を占有するものと予想される。9.SGSN110はグループベクトルを使用して応答を確認し、すべてのG_RES値について、SGSN110は、G_RES=G_XRESであるかどうかを検査する。その後、SGSN110は、グループ認証結果をGW104に送信するステップ478。10.GW104は、認証の結果を各UE101に知らせるステップ480。すべてのUE101が正常に認証された場合、GW104は単に成功メッセージをすべてのUE101にブロードキャストする。それ以外の場合、GW104は、iどのUE101が正常に認証されたかに関する情報を含む成功メッセージをブロードキャストする、およびiiどのUE101が確認されなかったかに関する情報を含むエラーメッセージを、失敗の原因と共にブロードキャストする。あるいは、成功メッセージは省略されてもよく、正常に認証されたUE101は、それらのIDがエラーブロードキャストメッセージに含まれているかどうかを検査することにより、認証の成功を認識することができる。各UE101は、ブロードキャストメッセージの受信をGW104に個々に通知し、GW104は共通の確認応答メッセージをSGSN110に転送する。11.正常に認証された各UE101は、個々のKi鍵KGとは異なるを使用して、CKiおよびIKi鍵を計算し、加えて、MTC_CKiおよびMTC_IKiが以下のように計算されるステップ482:MTC_CKi=CKiXORCKGMTC_IKi=IKiXORIKGただし、CKG=f3KG,G_RAND,IKG=f4KG,G_RANDCKi=f3Ki,G_RAND,IKi=f4Ki,G_RANDサブセクションC2の場合と同様に、HSS112は、このタスクをSGSN110に割り当てるのではなく、UEの応答を確認することを決定することができる。この場合、G_AUTNおよびG_RANDのみが、サブセクションC2に従って、SGSN110に送信される。C4.GWがグループ内のデバイスの正統性を確認し、結果をレポートする。グループ認証プロトコルの帯域幅要件をさらに低減するため、3GPPネットワークは、グループの正統性の確認をGW104に割り当てることができる。GW104は、そのようなタスクを実行できるようにするため、UE101からの応答が正しく計算されたG_RES値を含むかどうかを検査できる必要がある。したがって、GW104は、すでにG_XRESパラメータを含む認証ベクトルを受信する必要がある。上記のC3の場合と同様に、ここでは、すべてのUE101が共通のKG鍵を認識すると仮定される。さらに具体的には、この場合のプロトコル485のステップは図4Dに示され、以下のとおりである:1.GW104は、グループ登録要求をSGSN110に送信するステップ486。2.SGSN110は、この要求をHSS112に転送するステップ488。3.HSS112は、1つまたは複数のグループベクトルを生成して、SGSN110に送信するステップ490。そのようなベクトルは、以下のような形態をとる:V={G_AUTN,G_RAND,G_XRES,[MTC_CK1,MTC_IK1],...,[MTC_CKN,MTC_IKN]}4.SGSN110は、G_RAND、G_AUTN、およびG_XRESを含むグループ認証応答をGWに送信するステップ491。GW104が、上記のセクションB3およびB4で説明されるように、それらのパラメータをキャッシュに入れることができることに留意されたい。5.GW104は、G_AUTNおよびG_RANDを含むZigBeeブロードキャストメッセージをすべてのUE101に送信するステップ492。この場合、KGをプロビジョニングされていないので、GW104がG_AUTNを確認できないことに留意されたい。6.各UE101は、個々にG_AUTNを確認するステップ493。7.各UE101は、G_RESを含むメッセージで応答するステップ494。G_RESの値は、プロビジョニングされたKG鍵を使用して計算される。この鍵はUE101およびHSS112にのみ知られており、GW110には知られていないことを再度言及する。また、各UE101が同じG_RANDを受信し、KGを有するので、各正規のUE101はG_RESの同じ値を計算すべきであることにも留意されたい。8.GW104は、すべての受信したG_RESを、ローカルに格納されているG_XRESと比較する。さらに、GW104は、正常に認証されたUE101のリスト、および正常に認証されなかったUE101のリストをコンパイルするステップ495。9.GW104は、2つのリストをSGSN110に送信するステップ496。明らかに、このメッセージは、GWによって配信された2つのリストのサイズが小さくなっているので、C1、C2、およびC3の場合よりもはるかに少ない帯域幅を占有するものと予想される。代替として、GW104は、リストの1つを送信することを省略することができる。リストのうちの1つのみを検査することにより、SGSN110は、どのUE101が正常に認証されたかについての結果を導き出すことができる。10.GW104は、認証の結果を各UE101に知らせるステップ497。すべてのUE101が正常に認証された場合、GW104は単に成功メッセージをすべてのUE101にブロードキャストする。それ以外の場合、GW104は、iどのUE101が正常に認証されたかに関する情報を含む成功メッセージをブロードキャストする、およびiiどのUE101が確認されなかったかに関する情報を含むエラーメッセージを、失敗の原因と共にブロードキャストする。あるいは、成功メッセージは省略されてもよく、正常に認証されたUE101は、それらのIDがエラーブロードキャストメッセージに含まれているかどうかを検査することにより、認証の成功を認識することができる。各UE101は、ブロードキャストメッセージの受信をGW104に個々に通知し、GW104は共通の確認応答メッセージをSGSN110に転送する。11.正常に認証された各UEi101は、個々のKi鍵KGとは異なるを使用して、CKiおよびIKiを計算し、加えて、MTC_CKiおよびMTC_IKiが以下のように計算されるステップ498:MTC_CKi=CKiXORCKGMTC_IKi=IKiXORIKGただし、CKG=f3KG,G_RAND,IKG=f4KG,G_RANDCKi=f3Ki,G_RAND,IKi=f4Ki,G_RANDC5.GWがデバイスを信頼し、デバイスをグループとして登録する。認証プロトコルの帯域幅要件は、GWが関連付けられたデバイスをすでに信頼している場合、すなわちデバイスおよびGWが共通の相互に信頼される環境内で動作する場合、いっそうさらに軽減される。たとえば、GWと各デバイス間の通信リンクは、信頼されるローカルエリアネットワークの一部である。加えて、GWはKGを認識しており、SGSN/HSSにより信頼される。したがって、この場合、GWは、G_RANDSGSN/HSSによりGWに送信されたおよびKGを使用して計算された、G_RESを含むメッセージでSGSN/HSSに応答する。G_RESを送信することにより、GWは、特定のグループに属するすべてのデバイスが正常に認証されたことをSGSN/HSSに知らせる。SGSN/HSSが<デバイスID-グループID>の形式のマッピングテーブルを保持するのであれば、SGSN/HSSは、特定のグループ内の各デバイスの認証の成功について通知される。HSSはKGおよびKiを認識しているので、MTC_CKiおよびMTC_IKiはサブセクションC4に従って生成されてもよい。SGSN/HSSは、グループ登録確認メッセージをGWに送信する。GWは、G_RANDをこのメッセージに含め、メッセージをグループのすべてのデバイスにブロードキャストする。これにより、各デバイスは、G_RAND、KG、およびKiを使用して、MTC_CKiおよびMTC_IKiをサブセクションC4に従って計算する。D.対象のグループに属するUEへの個々およびマルチキャストのIPアドレス割り当て図2のフレームワークモジュール208UE101がM2Mアプリケーションサーバ108とのトラフィックセッション複数可を確立できるようにするため、ルーティング可能IPアドレスは最初にUE101に割り当てられる必要がある。そのために、UE101は、GGSN110とのPDPパケットデータプロトコルコンテキストを確立する必要がある。非常に多数のUE101が単一のGW104に接続されうることを考慮すれば、各UE101に3GPPコアネットワークとのPDPコンテキストをネゴシエートさせることはオーバーヘッドの観点から過度な増大をまねく。したがって、このフレームワークでは、GW104は、UE101に代わってそれらのネゴシエーションを実行する責任を負う。さらに具体的には、IPアドレス割り当て手順500のステップは図5に示され、以下のとおりである:1.GW104は、PDPコンテキストアクティブ化activatePDPcontextメッセージをSGSN110に送信するステップ502。このメッセージは、グループIDおよびPDPタイプを含む。このメッセージはまた、UMTSにおいて個々の3GPPUEのPDPアクティブ化のために使用されるパラメータと同じパラメータを含む。2.SGSN110は、前述のパラメータを含むPDPコンテキスト作成createPDPcontextメッセージをゲートウェイGPRSサポートノードGGSN:GatewayGPRSSupportNodeに送信するステップ504。GGSNは図1に具体的に示されていないが、GGSNがSGSNに接続され、GPRSネットワークと、インターネットのような外部パケット交換ネットワークとの間の相互作用に責任を負うことが知られていることに留意されたい。3.GGSNはPDPコンテキストのインターフェイス識別子を選択し、アドレススペースを作成して、PDPコンテキスト作成応答createPDPcontextresponseメッセージでSGSN110に応答するステップ506。このメッセージは、aGW104に接続されるすべてのUE101のPDPアドレス、およびbグループIDに対応するグループマルチキャストアドレスを含む。4.SGSN110は、すべてのUE101の割り当てられたIPアドレス、およびグループに対応するマルチキャストアドレスを含むPDPコンテキストアクティブ化確定activatePDPcontextacceptメッセージをGW104に送信するステップ508。5.GW104は、このメッセージをすべてのUE101にブロードキャストするステップ510。このメッセージは、CKGを使用して暗号化され、IKGを使用して完全性保護される。6.各UE101は、確認メッセージでGWに個々に応答するステップ512。UE101は、GW104がそのような情報をすでに認識しているので、ルータ要請メッセージをGGSNに送信することはない。同様に、GGSNは、任意のルータアドバタイズメントをUE101のグループに送信することはない。そのようなアドバタイズメントは、後者の登録中にGGSNによりGW104に送信された。7.GW104は、すべてのUE101からの応答を収集するステップ514。その後、GW104は、単一確認応答メッセージをGGSNに送信する。E.グループ登録、認証、およびM2Mアプリケーションサーバとの鍵合意図2のフレームワークモジュール210すべてのUE101がそれらのIPアドレスを割り当てられた後、UE101は、ルーティング可能パスを介して、場合によってはインターネット経由で、M2Mアプリケーションサーバ108に到達することができる。デバイスは、M2Mアプリケーションサービスにアクセスする前に、サービスレイヤにおいてこのサーバに最初に登録する必要がある。本発明の技法の1つの目的は、デバイスのグループを、単純な方法で、すなわち各デバイスを個々に登録する必要なく、M2Mアプリケーションサーバに登録するためのメカニズムを提供することである。さまざまなネットワークおよびセキュリティプロトコルがサービスレイヤにおけるM2Mデバイスの登録に採用されてもよいがAKA、TLS-PSKなど、このフレームワークは、わずかな調整を行なうだけでそれらのプロトコルのいずれにも採用することができるか、またさらにはいかなる変更も行なわずに適用されてもよい。1つの実施形態において、サービスレイヤ登録のための本発明の技法は、aM2Mサーバ108がクライアントエンティティとしてM2Mデバイス101を認証する必要があること、およびbM2Mサーバ108が複数のM2Mアプリケーションを容易にできることを考慮すれば、M2Mデバイス101でローカルに実行し、ネットワークサービスにアクセスしようとする各アプリケーションは、他のすべてのアプリケーションとは異なるセキュリティ資格情報を使用する必要があること、という2つのサービスレイヤセキュリティ要件に動機付けられている。それらの要件を考慮すれば、本発明のフレームワークは、図6Aに示される以下の汎用ステップを使用して、グループ登録、認証、および鍵合意プロトコル600を実行する:1.手順は、UE101の正統性を確認するGW104または認証エンティティたとえば、M2Mアプリケーションサーバ108により開始されるステップ602。2.認証エンティティは、グループを構成するデバイスを識別し、UE101にチャレンジするために認証パラメータのセットをGW104に送信するステップ604。3.GW104は、チャレンジをすべてのUE101にブロードキャストし、それらの応答を受信する。さらに、GW104は、応答を認証エンティティに転送するステップ606。この場合も同様に、認証エンティティは、M2Mアプリケーションサーバ108であってもよいか、または応答を確認する別のオーセンティケータであってもよい。4.確認後、個々のセッション鍵および共通グループセッション鍵は、すべての関与するエンティティにより確立されるステップ608。5.アプリケーションレイヤ鍵素材は、それらのセッション鍵から生成されるステップ610。そのようなアプリケーションレイヤ鍵は、事前に合意された鍵の存在を必要とする、TLS-PSKによるHTTPSの場合のように、各アプリケーションに関与するデータトラフィックを安全にするために使用されてもよい開示を引用により全体として本明細書において援用する、U.BlumenthalおよびP.Goel、PresharedKeyPSKCiphersuiteswithNULLEncryptionforTransportLayerSecurityTLS、RFC4785を参照。明らかに、これらのステップは、登録/認証プロトコルに容易に組み入れられうる。1つの一般的な方式では、アクセスネットワーク登録の場合のサブセクションCと同様に、各M2MUEが一意の永久ルート鍵KR、および共通グループルート鍵KGRをすでにプロビジョニングされていると仮定する。上記で説明されるように、これらの鍵は次いで、図6Bに示される鍵階層612に従って、セッションおよびアプリケーション鍵を生成するために使用される。一例として、永久ルート鍵および共通グループルート鍵は共に、初期サービスグループ登録に先立ってM2MUEにプロビジョニングされる。すべてのサービス登録手順において、M2MUEは、それらの鍵の知識を提供することによって認証される。個々の登録中に、M2MUEを認証するためにルート鍵KRのみが使用されるが、グループ認証にはグループルート鍵KGRが使用されることに留意されたい。サービスセッション鍵KSは、KRおよびKGRの両方の使用を通じて、認証成功の結果として生成される。サービスセッション鍵は、新しく登録されるごとに更新される。そのような鍵はさらに、アプリケーション鍵KAを導き出すために使用されるが、この鍵は、アプリケーションデータトラフィックの完全性保護および暗号化のためにセキュリティ機能によって使用される。以下において、EAP-AKAが使用される場合にこのサービスレイヤグループ登録プロトコルがどのように実現されうるかの例ユースケースを示す。ここで、認証エンティティオーセンティケータが、バックエンドEAPサーバと通信する別個のエンティティであると仮定する。簡潔にするため、ここではそれらの対話については説明されない。図6Cのプロトコル620は、以下のステップを含む:1.オーセンティケータは、EAP-要求/識別情報をGW104に送信するステップ622。2.すべてのUE101がアライブ状態であり、GW104へのZigBee接続を確立していると仮定して、GW104は、グループIDを含むEAP-応答/識別情報メッセージでオーセンティケータに応答するステップ624。3.EAPサーバは、そのローカルデータベースを使用して、特定のグループに属するデバイスを識別するステップ626。続いて、EAPサーバは、a各UE101の提供された個々のルート鍵KR、およびb各UE101にも知られている共通グループルート鍵KGRに基づいて認証ベクトルを取得する。取得された各ベクトルは、V={G_AUTNS,G_RANDS,G_XRESS,[MTC_CKS1,MTC_IKS1],...,[MTC_CKSN,MTC_IKSN]}のような形態をとる。4.EAPサーバは、オーセンティケータを通じて、EAP-グループ要求メッセージをGW104に送信するステップ628。このメッセージは、G_RANDS、G_AUTNS、およびG_MACS、すなわちEAPパケットをカバーするメッセージ認証コードを含むたとえば、開示を引用により全体として本明細書において援用する、J.ArkkoおよびH.Haverinen、ExtensibleAuthenticationProtocolMethodfor3rdGenerationAuthenticationandKeyAgreementEAP-AKAを参照。5.GW104は、上記の3つのパラメータを含むZigBeeブロードキャストメッセージをグループのすべてのUE101に送信するステップ630。このメッセージは、ZigBee規格に従って、KZBで暗号化される。6.このブロードキャストメッセージを受信した後、各UE101は、G_AUTNSを個々に確認するためにAKAアルゴリズムを実行するステップ632。7.各UE101は、G_RESSを含むメッセージでGW104に応答するステップ634。G_RESSの値は、提供されたKGR鍵を使用して計算される。この鍵はUEおよびEAPサーバにのみ知られていることを再度言及する。さらに、各UE101が同じG_RANDSを受信し、KGRを有するので、各正規のUE101はG_RESSの同じ値を計算すべきである。8.GW104は、すべての応答を収集し、それらをEAP-グループ応答メッセージでオーセンティケータを通じてEAPサーバに送信するステップ636。このメッセージはまた、G_MACSも含む。9.EAPサーバは、G_RESSをG_XRESSと比較することにより、G_RESSをUE101ごとに検査する。サーバはまた、G_MACSも確認するステップ638。10.EAPサーバは、応答を認証の結果と共にGW104に送信するステップ640。11.GW104は、認証の結果を各UE101に知らせるステップ642。すべてのUEが正常に認証された場合、GWは単に成功メッセージをすべてのUEにブロードキャストする。それ以外の場合、GWは、iどのUEが正常に認証されたかに関する情報を含む成功メッセージをブロードキャストする、およびiiどのUEが確認されなかったかに関する情報を含むエラーメッセージを、失敗の原因と共にブロードキャストする。あるいは、成功メッセージは省略されてもよく、正常に認証されたUEは、それらのIDがエラーブロードキャストメッセージに含まれているかどうかを検査することにより、認証の成功を認識することができる。各UEは、ブロードキャストメッセージの受信をGWに個々に通知し、GWは共通の確認応答メッセージをオーセンティケータに転送する。12.正常に認証された各UEi101は、個々のKi鍵KGとは異なるを使用して、CKSiおよびIKSiを計算し、加えて、MTC_CKSiおよびMTC_IKSiが以下のように計算されるステップ644:MTC_CKSi=CKSiXORCKGRMTC_IKSi=IKSiXORIKGRただし、CKGR=f3KG,G_RANDS,IKGR=f4KGR,G_RANDSCKRi=f3KR,G_RANDS,IKSi=f4KR,G_RANDS13.MTC_CKSiは、グループ登録が有効を維持する限り、特定のUEiのセッション鍵KSiとして使用されてもよいステップ646。この鍵から、3GPPTS33.102に従って、UEおよびオーセンティケータの両方により、任意の数のアプリケーション鍵KAUEでローカルに実行するが導き出されてもよいたとえば図6Bを参照。新しく登録されるたびに新しいセッション鍵が導き出されるので、すべてのアプリケーションレイヤ鍵は、新しいグループ登録ごとに更新される。F.設計の前提事項7の緩和サブセクションIIにおいて、UEとGW間のリンクが暗号化される可能性があるという前提事項7を示した。この前提事項は、G_RESが、KGに加えてUEの一意の識別子たとえば、UMTSの場合IMSIを使用して各UEにより計算されると仮定することにより緩和されてもよい。これにより、G_RESの値は、UEごとに異なる。IV.例示的なコンピューティングシステム図7は、本発明による複数のエンティティM2Mデバイス101のようなオープンデバイス、およびGW104のようなゲートウェイサーバ間の安全な登録プロトコルを実施するのに適したコンピューティングシステムの形態で、ネットワーク環境および通信デバイスユーザの汎用ハードウェアアーキテクチャ700を示す。図に示されるように、M2Mデバイス通信デバイスはコンピューティングシステム702を備え、ゲートウェイサーバネットワークデバイスはコンピューティングシステム704を備える。2つのコンピューティングシステム702および704は、ネットワーク706を介して結合される。ネットワークは、M2MデバイスおよびGWサーバが通信することができる任意のネットワークであってもよく、たとえば、上記で説明される実施形態におけるように、ネットワーク706は、ネットワーク事業者たとえば、Verizon、ATT、Sprintにより運用されるセルラー通信ネットワークのような、公的にアクセス可能なワイドエリア通信ネットワークを含むことができる。しかし、本発明は、特定のタイプのネットワークに限定されることはない。通常、M2Mデバイスはクライアントマシンであってもよく、GWサーバはサーバマシンであってもよい。また、共にクライアントであってもよく、または共にサーバであってもよい。さらに、クライアントは、ユーザとインターフェイスをとることができる。したがって、本発明の通信プロトコルは、コンピューティングシステムがそれぞれクライアントおよびサーバである事例に限定されることはなく、むしろ2つのネットワーク要素を備える任意のコンピューティングデバイスに適用可能であることを理解されたい。したがって、図7のアーキテクチャが、図4Aから図6Cのプロトコルの2つの関与要素を示すことを理解されたい。類似するコンピューティングシステム通信デバイスおよびネットワークデバイスが、たとえばNodeB106、アプリケーションサーバ108、SGSN110、HSS112などのプロトコルのその他の関与要素の実施を実現するために使用されることを理解されたい。簡潔にするため、本発明のプロトコルに関与しうるすべてのコンピューティングシステム通信デバイスおよびネットワークデバイスが、図7に示されているわけではない。当業者には容易に理解されるように、サーバおよびクライアントは、プログラムコードの制御の下で動作するプログラムされたコンピューティングシステムとして実施されてもよい。プログラムコードは、コンピュータ可読ストレージ媒体たとえば、メモリに格納され、コードは、コンピューティングシステムのプロセッサにより実行される。あるいは、サーバおよびクライアントはそれぞれ、1つまたは複数の特殊用途向け集積回路ASICとして実施されてもよい。ASICはプログラムコードにアクセスしてロードすることができるか、またはプログラムコードはASICに格納されてもよい。本発明のこの開示を踏まえ、当業者は、本明細書において説明されるプロトコルを実施するために、適切なプログラムコードを容易に作成することができるであろう。しかし、図7では、ネットワークを介して通信する各コンピューティングシステムのための例示的なアーキテクチャを全体的に示す。示されているように、M2Mデバイス702は、I/Oデバイス708-A、プロセッサ710-A、およびメモリ712-Aを備える。GWサーバ704は、I/Oデバイス708-B、プロセッサ710-B、およびメモリ712-Bを備える。本明細書において使用されるプロセッサという用語は、中央処理装置CPU、または1つまたは複数の信号プロセッサ、1つまたは複数の集積回路などを含むただし、これらに限定されない、その他の処理回路を含む、1つまたは複数の処理デバイスを含むことが意図されることを理解されたい。また、本明細書において使用されるメモリという用語は、RAM、ROM、固定メモリデバイスたとえば、ハードドライブ、または取り外し可能メモリデバイスたとえば、ディスケットまたはCDROMのような、プロセッサまたはCPUに関連付けられたメモリを含むことが意図される。加えて、本明細書において使用されるI/Oデバイスという用語は、処理装置にデータを入力するための1つまたは複数の入力デバイスたとえば、キーボード、マウス、および処理装置に関連付けられた結果を提供するための1つまたは複数の出力デバイス例えばCRTディスプレイを含むことが意図される。したがって、本明細書において説明される、本発明の方法を実行するためのソフトウェア命令またはコードは、たとえばROM、固定式または取り外し可能メモリのような関連するメモリデバイスの1つまたは複数に格納されてもよく、使用される準備が整ったときにRAMにロードされ、CPUにより実行されてもよい。有利なことに、上記で例示的に説明してきたように、本発明の原理は、複数のクライアント/デバイスユーザが登録手順の1つのセットを使用して同一のサーバ/ネットワークで安全に登録できるようにするフレームワークおよび方法を提供する。要するに、リバースシングルサインオンの問題を解決するためのフレームワークおよび詳細なプロトコルを開発する。このフレームワークの1つの主要な利点は、複数のクライアントデバイスユーザがグループとしてネットワークに登録できるようにし、しかもネットワークとの個々のセッション鍵を生成することができるようにすることである。これにより、多数のデバイスユーザを認証するプロセスは、大幅に簡略化され、認証手順の複雑さおよび帯域幅要件がかなりの程度まで軽減される。解説を簡略化することを目的として、このセキュリティフレームワークが、マシンタイプ通信すなわちMTCとしても知られているマシン間通信M2Mへのアプリケーションでグループ認証および鍵合意を実行するためにどのように適用されうるかについて説明する。M2Mはアプリケーションの1つの適切な分野であるが、このフレームワークは一般的であり、グループ登録が道理にかなうようなその他のアプリケーションにも十分に対処できる。本発明の例示的な実施形態は、添付の図面を参照して、本明細書において説明されてきたが、本発明がそれらの厳密な実施形態に限定されることはなく、さまざまなその他の変更および修正が、本発明の範囲または趣旨を逸脱することなく当業者によって行なわれてもよいことを理解されたい。"