JP5983785B2 - Ｍ２ｍにおけるグループ・ベースド・フィーチャのためのセキュリティアップデート - Google Patents

Description

本発明は、非特許文献１にて新たに提案されるアーキテクチャを用いたグループベース(ｇｒｏｕｐ ｂａｓｅｄ)のＭＴＣ(Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)のためのセキュリティソリューションに関する。このソリューションは、ＭＴＣ−ＩＷＦ(ＭＴＣ−Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ)をサポートして、グループメッセージがＳＣＳ(Ｓｅｒｖｉｃｅｓ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ)から送信された場合に、ＳＣＳに対する適切な承認を実行することが可能である。また、本発明は、グループメッセージをセキュアに配信及びブロードキャストするためのメカニズムにも関連する。

グループ・ベースド・フィーチャ(ｇｒｏｕｐ ｂａｓｅｄ ｆｅａｔｕｒｅ)の検討が、３ＧＰＰにおいてＲｅｌｅａｓｅ １２のために開始され(例えば、非特許文献２を参照)、非特許文献１において新たなアーキテクチャが検討されている。本願の発明者らが特許文献１において提案したグループＧＷ(ｇａｔｅｗａｙ)の概念を用い、本発明はこれを新たなアーキテクチャにおいて拡張する。

ＳＣＳが、グループメッセージをＭＴＣ−ＩＷＦのネットワークノードへ送信し、ＭＴＣ−ＩＷＦは、グループメッセージをターゲットのＭＴＣデバイス・グループへ転送するであろう。メッセージは、２以上のＭＴＣデバイスをターゲットとし、これらのデバイスをトリガしてネットワークと通信させ得る。

国際公開第２０１２／０１８１３０号

３ＧＰＰ ＴＳ ２３．６８２、"Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ ｆａｃｉｌｉｔａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｗｉｔｈ ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋｓ ａｎｄ ａｐｐｌｉｃａｔｉｏｎｓ (Ｒｅｌｅａｓｅ １１)"、ｖ１１．１．０、２０１２年６月 ３ＧＰＰ ＴＲ ２３．８ｘｙ、"Ｍａｃｈｉｎｅ−Ｔｙｐｅ ａｎｄ ｏｔｈｅｒ Ｍｏｂｉｌｅ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｈａｎｃｅｍｅｎｔｓ； (Ｒｅｌｅａｓｅ １２)"、ｖ０．１．０、２０１２年５月 ３ＧＰＰ ＴＲ ３３．８６８、"Ｓｅｃｕｒｉｔｙ ａｓｐｅｃｔｓ ｏｆ Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ； (Ｒｅｌｅａｓｅ １１)"、ｖ０．８．０

しかしながら、本願の発明者らは、虚偽のグループメッセージがネットワークに対するＤｏＳ(Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ)アタックを引き起こし得るという課題を見出した。なお、非特許文献３に記載されるＭＴＣデバイスへのアタックもこれに当てはまる。

よって、ＭＴＣ−ＩＷＦは、ＳＣＳ承認を実行して、特にメッセージがトリガを含む場合に、ＳＣＳがグループメッセージを送信可能か否か発見すべきである。

上記の課題を解決するため、本発明の第１の態様に係るネットワークノードは、コアネットワーク内に設置される。このネットワークノードは、前記コアネットワーク外に設置される送信元から、メッセージが前記コアネットワークへアタッチする１以上のＭＴＣデバイスのグループ宛てであるか否かを示すインジケータを含む前記メッセージを、受信する受信手段と、前記インジケータが、前記メッセージが前記グループ宛てである旨を示す場合、前記送信元を承認すると判定する判定手段と、を含む。

また、本発明の第２の態様に係る方法は、コアネットワーク内に設置されるネットワークノードを制御する方法を提供する。この方法は、前記コアネットワーク外に設置される送信元から、メッセージが前記コアネットワークへアタッチする１以上のＭＴＣデバイスのグループ宛てであるか否かを示すインジケータを含む前記メッセージを、受信し、前記インジケータが、前記メッセージが前記グループ宛てである旨を示す場合、前記送信元を承認すると判定する、ことを含む。

また、本発明の第３の態様に係るＭＴＣデバイスは、前記コアネットワークから、メッセージが１以上のＭＴＣデバイスのグループ宛てであるか否かを特定するためのＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を含む前記メッセージを、受信する受信手段と、前記ＩＤが自ＭＴＣデバイスに対して割り当てられたＩＤと一致しない場合に、前記メッセージを廃棄すると判定する判定手段と、を含む。

また、本発明の第４の態様に係る方法は、コアネットワークへアタッチするＭＴＣデバイスを制御する方法を提供する。この方法は、前記コアネットワークから、メッセージが１以上のＭＴＣデバイスのグループ宛てであるか否かを特定するためのＩＤを含む前記メッセージを、受信し、前記ＩＤが自ＭＴＣデバイスに対して割り当てられたＩＤと一致しない場合に、前記メッセージを廃棄すると判定する、ことを含む。

また、本発明の第５の態様に係るゲートウェイは、メッセージを、コアネットワーク外に設置される前記メッセージの送信元から、前記コアネットワークへアタッチする１以上のＭＴＣデバイスのグループへ中継する。このゲートウェイは、前記ＭＴＣデバイスのグループが前記送信元とセキュアに通信するための一対のグループキーを、取得する取得手段と、前記グループキーを用いて、前記メッセージを中継する中継手段と、を含む。

また、本発明の第６の態様に係るＭＴＣデバイスは、前記コアネットワーク外に設置され且つ１以上のＭＴＣデバイスのグループ宛てのメッセージを送信する送信元とセキュアに通信するための一対のグループキーを、取得する取得手段と、前記グループキーを用いて、前記送信元と通信する通信手段と、を含む。

また、本発明の第７の態様に係る方法は、メッセージを、コアネットワーク外に設置される前記メッセージの送信元から、前記コアネットワークへアタッチする１以上のＭＴＣデバイスのグループへ中継するゲートウェイ、を制御する方法を提供する。この方法は、前記ＭＴＣデバイスのグループが前記送信元とセキュアに通信するための一対のグループキーを、取得し、前記グループキーを用いて、前記メッセージを中継する、ことを含む。

さらに、本発明の第８の態様に係る方法は、コアネットワークへアタッチするＭＴＣデバイスを制御する方法を提供する。この方法は、前記コアネットワーク外に設置され且つ１以上のＭＴＣデバイスのグループ宛てのメッセージを送信する送信元とセキュアに通信するための一対のグループキーを、取得し、前記グループキーを用いて、前記送信元と通信する、ことを含む。

本発明によれば、ＳＣＳ承認を実行して、特にメッセージがトリガを含む場合に、ＳＣＳがグループメッセージを送信可能か否か発見することができる。

本発明の実施の形態に係るシステムアーキテクチャの例を示したブロック図である。 本発明の実施の形態に係るシステムにおいて、ＭＴＣデバイスで終端されるグループメッセージの例を示したシーケンス図である。 本発明の実施の形態に係る、設置されるネットワークノードの構成例を示したブロック図である。 本発明の実施の形態に係るＭＴＣデバイスの構成例を示したブロック図である。 本発明の実施の形態に係るゲートウェイの構成例を示したブロック図である。

１．ディスカッション
ＳＡ２は、３ＧＰＰ ＴＲ ２３．８ｘｙ “Ｍａｃｈｉｎｅ−Ｔｙｐｅ ａｎｄ ｏｔｈｅｒ Ｍｏｂｉｌｅ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｈａｎｃｅｍｅｎｔｓ (Ｒｅｌｅａｓｅ １２)”において、グループ・ベースド・フィーチャに関する検討を開始している。ＳＡ３は、ＳＡ２が提供したアーキテクチャ要件に従って、Ｒｅｌｅａｓｅ １２のためのセキュリティ問題を検討すべきである。

ＳＡ２からのグループ・ベースド・メッセージング(ｇｒｏｕｐ ｂａｓｅｄ ｍｅｓｓａｇｉｎｇ)に対するアーキテクチャ要件は、次の通りである。
−ネットワークは、グループメッセージをＳＣＳから特定の地理的エリアに位置するＭＴＣグループのメンバへ分配するためのメカニズムを、提供すべきである。
−グループ・ベースド・メッセージング・フィーチャは、このフィーチャを使用しないＵＥに対して、追加的な新機能を要求すべきで無い。
−システムは、グループ・ベースド・メッセージング・フィーチャを使用するＵＥが当該ＵＥ宛てに分配されたグループメッセージを効率的に認識可能なメカニズムを、サポートすべきである。
−システムは、ＳＣＳがグループメッセージを送信するためのインタフェースを提供すべきである。このインタフェースは、下記の情報を搬送可能なべきである。
−グループメッセージのアプリケーションレイヤコンテンツ
−グループメッセージの対象であるグループ識別子、及び
−グループメッセージが分配されるべき地理的エリア及びＲＡＴ(ｓ)
−システムは、分配されたグループメッセージへ応答するデバイスがもたらす過負荷に対して保護されるべきである。
−グループ・ベースド・メッセージングは、ＧＥＲＡＮ、ＵＴＲＡＮ及びＥ−ＵＴＲＡＮアクセスにおいてサポートされるべきである。

現行のアーキテクチャによれば、ＭＴＣ−ＩＷＦがＳＣＳからグループメッセージを受信して、ターゲットのＭＴＣデバイス・グループへ転送することが想定され得る。

グループメッセージにより、複数のＭＴＣデバイスが応答することをトリガされ得る。このため、未承認のグループメッセージは、単一のＭＴＣデバイスに対するトリガが引き起こし得るものと比して、遥かに深刻な問題を引き起こす虞がある。ここで、非グループメッセージに対し検討されていたＭｉｔＭアタック及びリプレイ(ｒｅｐｌａｙ)アタックといった他の脅威も増幅された影響で適用される。このため、
−ネットワークは、ＳＣＳがグループメッセージをターゲットグループへ送信可能か否かについての承認を実行すべきである。これを実行するため、ＭＴＣ−ＩＷＦは、グループメッセージを他のメッセージと区別可能なべきである。
−グループメッセージは、その機密性(ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ)及び完全性(ｉｎｔｅｇｒｉｔｙ)が保護されるべきであり、メッセージを受信するＭＴＣデバイスは、これを検証可能なべきである。
−ネットワークは、３ＧＰＰネットワークの外部に位置するＳＣＳがターゲットグループと通信するための手段を提供すべきである。ＳＣＳがグループメッセージを送信する場合、グループ識別子が用いられる。ＵＥ識別子と同様、３ＧＰＰネットワークにおいて使用されるグループ識別子は、外部インタフェース上で送信されるべきで無く、且つ３ＧＰＰネットワーク外部のノードに知られるべきでは無い。このことは、３ＧＰＰネットワークの外部に位置するＳＣＳに適用される。

上記の分析により、ＭＴＣグループ・ベースド・フィーチャに対するセキュリティ要件は、次の通りに結論付けられる。
−ＭＴＣ−ＩＷＦは、ＳＣＳがグループメッセージを特定のＭＴＣグループへ送信することを承認されているかどうか検証すべきである。
−ＭＴＣ−ＩＷＦは、グループ(トリガ)メッセージを他のメッセージと区別可能なべきである。
−ＭＴＣデバイスのグループへ分配されるグループメッセージは、その機密性、完全性が保護され、リプレイによる保護も成されるべきである。
−グループメッセージを受信するＭＴＣデバイスは、グループメッセージが承認されたＳＣＳから送信されたかどうかを検証可能なべきである。
−グループＩＤは、３ＧＰＰネットワークの外部に位置するノードへ露呈されるべきでは無い。これには、３ＧＰＰネットワーク外部のＳＣＳも含まれる。

２．提案
ＳＡ３に対し、次の１）、２）のことを提案する。
１）グループ・ベースド・フィーチャに対する脅威及びセキュリティ要件を検討せよ
２）次の通りの独立したｐＣＲを前提として、上記の分析及びセキュリティ要件を、Ｒｅｌｅａｓｅ １２のためにＴＲ ３３．８６８に含めよ

５．ｘ 主要問題(Ｋｅｙ Ｉｓｓｕｅ)−グループ・ベースド・メッセージング
５．ｘ．１ 問題詳細
ＳＡ２は、ＴＲ ２３．８ｘｙ(Ｒｅｌｅａｓｅ １２)において、グループ・ベースド・フィーチャに対する検討を開始している。現行のアーキテクチャによれば、ＭＴＣ−ＩＷＦがＳＣＳからグループメッセージを受信して、ターゲットのＭＴＣデバイス・グループへ転送することが想定され得る。

５．ｘ．２ 脅威
グループメッセージにより、複数のＭＴＣデバイスが応答することをトリガされ得る。このため、未承認のグループメッセージは、単一のＭＴＣデバイスに対するトリガが引き起こし得るものと比して、遥かに深刻な問題を引き起こす虞がある。ここで、非グループメッセージに対し検討されていたＭｉｔＭアタック及びリプレイアタックといった他の脅威も増幅された影響で適用される。

５．ｘ．３ セキィリティ要件
−ＭＴＣ−ＩＷＦは、ＳＣＳがグループメッセージを特定のＭＴＣグループへ送信することを承認されているかどうか検証すべきである。
−ＭＴＣ−ＩＷＦは、グループ(トリガ)メッセージを他のメッセージと区別可能なべきである。
−ＭＴＣデバイスのグループへ分配されるグループメッセージは、その機密性、完全性が保護され、リプレイによる保護も成されるべきである。
−グループメッセージを受信するＭＴＣデバイスは、グループメッセージが承認されたＳＣＳから送信されたかどうかを検証可能なべきである。
−グループＩＤは、３ＧＰＰネットワークの外部に位置するノードへ露呈されるべきでは無い。これには、３ＧＰＰネットワーク外部のＳＣＳも含まれる。

以下、本発明の実施の形態を、図１〜図５を参照して説明する。

図１に示すように、本実施の形態に係るシステムは、コアネットワーク(３ＧＰＰネットワーク)と、ＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を介してコアネットワークへ接続する複数のＭＴＣデバイス１０と、コアネットワーク外に設置されて、グループメッセージ又はグループトリガのソースとして機能するＳＣＳ ３０及びＳＭＥ(Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｅｎｔｉｔｙ) ４０と、を含む。なお、ＲＡＮは、複数の基地局(すなわち、ｅＮＢｓ(ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂｓ))によって形成される。

この内、各ＭＴＣデバイス１０は、Ｕｍ／Ｕｕ／ＬＴＥ−Ｕｕインタフェースを介してコアネットワークへ接続するＭＴＣ用のＵＥである。ＵＥは、１又は複数のＭＴＣアプリケーションをホスト(ｈｏｓｔ)することが可能である。対応する外部ネットワークにおけるＭＴＣアプリケーションは、１又は複数のＡＳｓ(Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒｓ)によりホストされる。

また、ＳＣＳ ３０及びＳＭＥ ４０は、コアネットワークへ接続して、ＭＴＣデバイス１０と通信する。

さらに、コアネットワークは、ＨＰＬＭＮ(Ｈｏｍｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ)において、ＭＴＣ−ＩＷＦ ２１と、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ) ２２とを含む。コアネットワークにおいては、ＭＴＣ−ＩＷＦ ２１が、グループメッセージ又はグループトリガをその送信元から受信するネットワークノードとして機能する。大略、ＭＴＣ−ＩＷＦ ２１は、グループトリガでもあり得るグループメッセージを、Ｔｓｐインタフェースを介してＳＣＳ ３０から、又はＴｓｍｓインタフェースを介してＳＭＥ ４０から受信する。また、ＭＴＣ−ＩＷＦ ２１は、グループメッセージを、Ｔ５ｂ／Ｔ５ａ／Ｔ５ｃインタフェースを介して、ＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)、ＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ(Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ) Ｓｕｐｐｏｒｔ Ｎｏｄｅ)又はＭＳＣ(Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ)へ転送する。ＭＭＥ、ＳＧＳＮ、ＭＳＣは、グループメッセージをＭＴＣデバイス１０へ転送するネットワーク構成要素として機能する。この結果、グループメッセージ又はグループトリガを、ＭＴＣデバイス１０へルーティングすることが可能である。ＨＳＳ ２２又はＭＴＣ−ＩＷＦ ２１は、外部グループＩＤ及び内部グループＩＤのマッピングを作成して記憶することが可能であり、ＨＳＳ ２２は、(後述する)一対のグループキーを生成する。グループキーの一つは、暗号化及び復号化のために生成され、他の一つは、完全性保護のために生成される。

次に、本実施の形態の動作例を、図２を参照して詳細に説明する。図２は、ＭＴＣデバイスのグループへのグループメッセージ送信のメッセージシーケンスを示している。ＭＴＣデバイス・グループには、２以上のデバイスが存在する。

本実施の形態においては、(後述する)グループＧＷとネットワークの間、並びにグループＧＷとＭＴＣデバイス１０の間で相互認証が行われるものとする。なお、ゲートウェイは、特許文献１の独立した発明において提案されたものであり、グループメッセージを受信してＭＴＣデバイスへ送信する役割を担い、ネットワーク又はＳＣＳと通信するＭＴＣデバイスに対して、連結されたメッセージを送信する。本実施の形態は、このゲートウェイに対する幾つかの新たな機能を提案するものである。ゲートウェイは、ネットワークノード内に配置されるか、或いは独立したノードであり得る。

（１）グループメッセージ送受信
（Ａ）ＳＣＳ ３０は、グループメッセージを、Ｔｓｐインタフェース上でＭＴＣ−ＩＷＦ ２１へ送信する(ステップＳ８)。グループメッセージは、グループＩＤ、及び地理的エリア情報(これは非特許文献２に記載されている)を包含する。加えて、メッセージは、メッセージがグループメッセージ又は非グループメッセージであるかを示すインジケータを含む。このため、ＭＴＣ−ＩＷＦ ２１は、グループメッセージを非グループメッセージと区別でき、以て下記（Ｂ）に説明する如く、ＳＣＳ ３０に対する適切な承認を実行することが可能である。また、インジケータは、グループメッセージがトリガを包含するか否かを示しても良い。この場合、ＭＴＣ−ＩＷＦ ２１は、グループトリガを、グループメッセージ又は非グループメッセージと区別することも可能である。

（Ｂ）ＭＴＣ−ＩＷＦ ２１は、ＳＣＳ ３０に対する承認を実行して、ＳＣＳ ３０がグループメッセージをターゲットグループへ送信可能かどうか発見する(ステップＳ９)。この手順は、ＭＴＣ−ＩＷＦ ２１が非グループメッセージを送信する際の承認手順と同様である。承認は、ＳＣＳ ３０から受信したグループＩＤのグループ情報、地理的エリア情報、並びにＭＴＣ−ＩＷＦ ２１がＨＳＳ ２２から検索した承認データに基づく。

（Ｃ）ＭＴＣ−ＩＷＦ ２１は、グループメッセージを、グループＧＷ ５０へ転送する(ステップＳ１０)。グループＧＷ ５０は、２以上のグループを所有可能である。グループＧＷ ５０は、ｅＮＢ／ＭＭＥ／ＭＴＣ−ＩＷＦ等の任意のノード上に配置される仮想的な機能であるか、或いは独立したノードであり得る。

（Ｄ）グループＧＷ ５０は、グループメッセージを、ターゲットのＭＴＣデバイス・グループへブロードキャストする(ステップＳ１２)。グループＧＷ ５０がｅＮＢ上に配置される場合、グループメッセージは、ｅＮＢとＭＴＣデバイスの間でのみブロードキャストされる。このため、コアネットワークの輻輳を回避することが可能である。一方、グループＧＷ ５０が、１以上の基地局へ接続されるネットワーク構成要素の一つとして機能するＭＭＥ上に配置される場合、コアネットワークの輻輳を部分的に低減しつつ、複数のエリアに跨ってグループメッセージをブロードキャストすることが可能である。

（２）グループＩＤ、グループキー管理、並びにグループメッセージセキュリティ
ＨＳＳ ２２は、ＭＴＣデバイスのグループのために、ユニークなグループＩＤを生成する(ステップＳ１及びＳ３)。ステップＳ３において、ＨＳＳ ２２は、グループキーを生成可能である。コアネットワーク(３ＧＰＰネットワークドメイン)の外部に位置するＳＣＳ ３０に対しては、グループＩＤが露呈されるべきでは無い。よって、ＨＳＳ ２２は、これらのグループＩＤと、外部的に使用するグループＩＤとのマッピングを有するであろう。内部的に使用するグループＩＤは、既存のＮＡＳ又はＡＳメッセージ内で、ＭＴＣデバイス１０、グループＧＷ ５０へ送信され得る(ステップＳ４)。

外部グループＩＤを生成する２つの方法が存在し得る。外部グループＩＤは、ＨＳＳ ２２により生成されて、ＳＣＳ ３０へ提供される。或いは、外部グループＩＤは、ＳＣＳ ３０により生成されて、ＨＳＳ ２２へ提供される(ステップＳ２)。いずれの方法でも、ＨＳＳが、両グループＩＤのマッピングを作成するであろう。

ＭＴＣ−ＩＷＦ ２１は、マッピングを、ＨＳＳ ２２からダウンロードして(ステップＳ５)、ローカルに記憶する(ステップＳ６)。また、上記のステップＳ１０でグループメッセージをグループＧＷ ５０へ転送するに際して、ＭＴＣ−ＩＷＦ ２１は、マッピングを参照し、以てグループメッセージ中において、外部グループＩＤを対応する内部グループＩＤへマッピングする。

このように、本実施の形態においては、内部グループＩＤがコアネットワークの外部から隠蔽されるであろう。このため、虚偽のグループメッセージがコアネットワークに対するアタックを引き起こすことを防止可能である。また、外部グループＩＤは、ソース承認の後にのみ有効となる。このため、外部グループＩＤがアタッカへ漏洩した場合であっても、アタックを防止可能である。

グループメッセージをＭＴＣデバイスのグループへブロードキャストするに際して、セキュリティが必要である。本実施の形態は、グループメッセージの機密性及び完全性保護のために、一対のグループキーを用いることを提案する。

ＭＴＣデバイス及びグループＧＷがネットワークを用いて相互認証された後、グループキーの管理及びセキュリティのアクティブ化が行われるべきである(ステップＳ４)。グループキーは、ＭＴＣグループ内の全てのＭＴＣデバイスがグループキーを所持するためのものである。このグループキーは、グループ内の全てのＭＴＣデバイスに対して同一のものであり、これらのＭＴＣデバイスにより、グループＧＷ ５０と共有され、オプションとして、グループメッセージが送信される他の相手と共有される。

どのネットワークノードが同一のグループキーを所持するか、及びグループメッセージを如何にして送信するかについては幾つかのオプションがある。
（Ａ）ＭＴＣデバイス−グループＧＷ
グループＧＷ ５０とＳＣＳ ３０の間を転送するグループメッセージは、ＩＰｓｅｃ又は他の既存のネットワークセキュリティソリューションによって保護することが可能である。グループＧＷ ５０は、グループキーを用いてグループメッセージを保護し、グループメッセージをターゲットグループのＭＴＣデバイスへブロードキャストする。ステップＳ４において、ＭＴＣデバイス及びグループＧＷ ５０は、グループキーをＨＳＳ ２２から取得し、以てグループキーがＭＴＣデバイスとグループＧＷ ５０の間で共有される。

（Ｂ）ＭＴＣデバイス−ＳＣＳ(ステップＳ７)
このケースでは、グループＧＷ ５０が、グループメッセージを転送し、そのままブロードキャストするであろう。一方、ＭＴＣデバイスは、グループキーを上記（Ａ）と同様にして取得する。また、承認の後、ＳＣＳ ３０は、グループキーを、ＭＴＣ−ＩＷＦ ２１を介してＨＳＳ ２２から取得し、以てグループキーがＭＴＣデバイスとＳＣＳ ３０の間で共有される。このため、ＭＴＣデバイスとＳＣＳ ３０の間でエンド・トゥ・エンド(ｅｎｄ−ｔｏ−ｅｎｄ)なセキュリティを提供可能である。ＭＴＣデバイスは、ＳＣＳ ３０に対する承認を実行可能である。

（Ｃ）ＭＴＣデバイス−グループＧＷ−ＳＣＳ(ステップＳ１１)
このケースでは、グループＧＷ ５０とＳＣＳ ３０の間の通信を、グループキーにより保護することが可能である。グループＧＷ ５０は、グループキーを用いて、ＳＣＳ ３０に対する承認を実行可能であり、ＭＴＣデバイスは、承認を行う必要が無い。上記（Ａ）及び（Ｂ）と同様にして、グループキーが、ＭＴＣデバイス、グループＧＷ ５０及びＳＣＳ ３０の間で共有される。また、グループＧＷは、共有されたグループキーを用いて、グループメッセージを検証し(復号化及び完全性チェック)、以て検証に失敗した際にはグループメッセージを廃棄する。この場合、ブロードキャスト自体を回避することが可能である。

（３）グループＩＤを伴って或いは伴わずにブロードキャストされ得るグループメッセージ
グループＩＤがグループメッセージに含まれる場合、ＭＴＣデバイスは、メッセージを試聴するが、自ＭＴＣデバイスが所持するものと同一のグループＩＤを包含するメッセージを受信するのみであろう。そして、ＭＴＣデバイスは、共有されたグループキーを用いて、メッセージの完全性チェック及び復号化を行うであろう(ステップＳ１３及びＳ１４)。グループＩＤが、自ＭＴＣデバイスに対して割り当てられたグループＩＤと一致しない場合、ＭＴＣデバイスは、グループメッセージを廃棄する。この場合、ＭＴＣデバイスは、グループメッセージを検証する必要が無い。このため、ＭＴＣデバイスに掛る処理負荷を低減することが可能である。

一方、グループＩＤが含まれない場合、ＭＴＣデバイスは、全てのブロードキャストを試聴すると共に、完全性チェック及び復号化を行い、検証可能なものに対して応答するのみである。

図３に示すように、ＭＴＣ−ＩＷＦ ２１は、少なくとも、受信部２１１及び判定部２１２を含む。受信部２１１は、ＳＣＳ ３０又はＳＭＥ ４０から、上記のインジケータを含むグループメッセージ又はグループトリガを受信する。判定部２１２は、インジケータがグループメッセージ又はグループトリガを示す場合に、ＳＣＳ ３０又はＳＭＥ ４０を承認すると判定する。これらのユニット２１１及び２１２に加えて、ＭＴＣ−ＩＷＦ ２１は、記憶部２１３と、マッピング部２１４と、転送部２１５とを含むことが可能である。記憶部２１３は、上記のマッピングを記憶する。マッピング部２１４は、マッピングを用い、グループメッセージ又はグループトリガ中で、外部グループＩＤを対応する内部グループＩＤへマッピングする。転送部２１５は、グループメッセージ又はグループトリガをＭＭＥ／ＳＧＳＮ／ＭＳＣの一つへ転送し、以てグループメッセージ又はグループトリガが、ＭＴＣデバイスへブロードキャストされる。なお、これらのユニット２１１〜２１５は、バス等を介して相互接続される。

こられのユニット２１１〜２１５は、例えば、ＨＳＳ ２２、ＭＭＥ／ＳＧＳＮ／ＭＳＣ、ＳＣＳ ３０及びＳＭＥ ４０とそれぞれ通信するトランシーバと、これらのトランシーバを制御して、図２のステップＳ５、Ｓ６及びＳ８〜Ｓ１０に示した処理或いはこれと同等の処理を実行するコントローラと、で構成することが可能である。

また、図４に示すように、各ＭＴＣデバイス１０は、少なくとも、受信部１０１及び判定部１０２を含む。受信部１０１は、コアネットワークから、上記のグループＩＤを含むグループメッセージ又はグループトリガを受信する。判定部１０２は、グループＩＤが各ＭＴＣデバイス１０自身のためのグループＩＤと一致しない場合に、グループメッセージ又はグループトリガを廃棄すると判定する。これらのユニット１０１及び１０２に代えて或いは加えて、各ＭＴＣデバイス１０は、取得部１０３と、通信部１０４とを含むことが可能である。取得部１０３は、グループキーを、例えばＨＳＳ ２０から取得する。通信部１０４は、グループキーを用いて、ＳＣＳ ３０又はＳＭＥ ４０と通信する。なお、これらのユニット１０１〜１０４は、バス等を介して相互接続される。

これらのユニット１０１〜１０４は、例えば、ＲＡＮを介してコアネットワークと無線通信するトランシーバと、このトランシーバを制御して、図２のステップＳ４及びＳ１２〜Ｓ１４に示した処理或いはこれと同等の処理を実行するコントローラと、で構成することが可能である。

さらに、図５に示すように、グループＧＷ ５０を独立したノードとして配置する場合、グループＧＷ ５０は、少なくとも、取得部５０１及び中継部５０２を含む。取得部５０１は、グループキーを、例えばＨＳＳ ２０から取得する。中継部５０２は、グループキーを用いて、グループメッセージ又はグループトリガを中継する。なお、これらのユニット５０１及び５０２は、バス等を介して相互接続される。

これらのユニット５０１及び５０２は、例えば、ＭＴＣ−ＩＷＦ ２１、ＨＳＳ ２２及びＭＭＥ／ＳＧＳＮ／ＭＳＣ／ＲＡＮとそれぞれ通信するトランシーバと、これらのトランシーバを制御して、図２のステップＳ４及びＳ１０〜Ｓ１２に示した処理或いはこれと同等の処理を実行するコントローラと、で構成することが可能である。

図示を省略するが、ＳＣＳ ３０及びＳＭＥ ４０の各々は、一般的なＳＣＳ及びＳＭＥ各々に実装される機能に加えて、上記のインジケータをグループメッセージ又はグループトリガへ含める機能、上記のグループＩＤをグループメッセージ又はグループトリガへ含める機能、並びに上記のグループキーを用いてＭＴＣデバイスのグループと通信する機能、の少なくとも一つを含む。

なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。

上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

(付記１)
ＨＳＳ等のネットワークノードが、グループ毎に、ユニークな内部的に使用するグループＩＤを作成する。

(付記２)
ＨＨＳは、グループＩＤを、全てのグループメンバのＭＴＣデバイス及びグループＧＷへ送信する。グループＧＷは、ネットワークノード中に配置される機能であるか、或いは独立したノードであり得る。

(付記３)
外部グループＩＤと、そのユニークな内部的に使用するグループＩＤへのマッピング：
ＨＳＳは、外部グループＩＤと、ネットワーク内で使用されるのみであるユニークなグループＩＤとのマッピングを保持する。外部グループＩＤは、ＨＳＳにより、或いはグループが契約するＳＣＳにより割り当てられ得る。

(付記４)
ＭＴＣ−ＩＷＦは、グループＩＤマッピングを、Ｓ６ｍインタフェースを介してダウンロードし、ローカルに記憶する。新規な事項は、インタフェースの改修である。

(付記５)
符号化及び完全性保護のために、一対のグループキーが生成される。一対のグループキーは、グループ内の全てのＭＴＣデバイスに対して同一のものである。グループＧＷ及び／又はＳＣＳが、同一のグループキーを有し得る。

(付記６)
ネットワークエンティティ、例えばＭＴＣ−ＩＷＦがグループメッセージを非グループメッセーと区別可能にする、グループメッセージ中のインジケータ。ＩＷＦがグループトリガメッセージを非グループトリガメッセージと区別するためのインジケータ。これは、ＭＴＣ−ＩＷＦが適切な承認を実行するのに役立つ。

(付記７)
グループＧＷは、グループメッセージをＭＴＣデバイスのグループへブロードキャストし、グループメッセージは、適切なＭＴＣデバイスのみが受信し且つ解読できるように、一対のグループキーによって保護される。

(付記８)
グループメッセージは、以下の２つの方法の一つでブロードキャストされ得る。
（Ａ）グループＩＤを包含させる：ＭＴＣデバイスは、ブロードキャストにおけるグループＩＤをチェックし、自ＭＴＣデバイスが所持するグループＩＤと同一である場合に、(グループＩＤに関連する)グループキーを用いて、メッセージの完全性チェック及び復号化を行うであろう。
（Ｂ）グループＩＤを包含させない：ＭＴＣデバイスは、そのグループキーを用いて、全てのブロードキャストされたメッセージをチェックするだけである。

この出願は、２０１２年６月２９日に出願された日本出願特願２０１２−１４７９８３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１０ ＭＴＣデバイス
２１ ＭＴＣ−ＩＷＦ
２２ ＨＳＳ
３０ ＳＣＳ
４０ ＳＭＥ
５０ グループＧＷ
１０１, ２１１ 受信部
１０２, ２１２ 判定部
１０３, ５０１ 取得部
１０４ 通信部
２１３ 記憶部
２１４ マッピング部
２１５ 転送部
５０２ 中継部

Claims (7)

1. コアネットワーク内に設置されるネットワークノードであって、
   前記コアネットワーク外に設置される送信元から、メッセージが前記コアネットワークへアタッチする１以上のＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスのグループ宛てであるか否かを示すインジケータ及び前記送信元が前記グループを特定するための外部ＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を含む前記メッセージを、受信する受信手段と、
   前記インジケータが、前記メッセージが前記グループ宛てである旨を示す場合、前記送信元を承認すると判定する判定手段と、
   前記外部ＩＤと、前記ＭＴＣデバイスのアドレスを特定するための内部ＩＤとのマッピングを記憶する記憶手段と、
   前記マッピングを用い、前記メッセージ中で、前記外部ＩＤを対応する内部ＩＤへマッピングするマッピング手段と、
   前記メッセージを、前記メッセージをＭＴＣデバイスへブロードキャストすることが可能なネットワーク構成要素へ転送する転送手段と、
   を備えたネットワークノード。
2. 請求項１記載のネットワークノードにおいて、
   前記インジケータは、前記メッセージが前記グループをトリガして前記送信元と通信させるか否かを、さらに示す、
   ことを特徴としたネットワークノード。
3. 請求項１又は２に記載のネットワークノードにおいて、
   ＭＴＣ−ＩＷＦ（ＭＴＣ−Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）である、
   ことを特徴としたネットワークノード。
4. コアネットワークへアタッチするＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスであって、
   請求項１〜３のいずれか一項に記載のネットワークノードにより転送されるメッセージを受信する、
   ＭＴＣデバイス。
5. コアネットワーク外に設置されるネットワークノードであって、
   メッセージを、請求項１〜３のいずれか一項に記載のネットワークノードへ送信し、
   前記インジケータを、前記メッセージに含める、
   ネットワークノード。
6. 請求項５記載のネットワークノードにおいて、
   ＳＣＳ（Ｓｅｒｖｉｃｅｓ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ）、又はＳＭＥ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｅｎｔｉｔｙ）である、
   ことを特徴としたネットワークノード。
7. コアネットワーク内に設置されるネットワークノードを制御する方法であって、
   前記コアネットワーク外に設置される送信元から、メッセージが前記コアネットワークへアタッチする１以上のＭＴＣ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイスのグループ宛てであるか否かを示すインジケータ及び前記送信元が前記グループを特定するための外部ＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を含む前記メッセージを、受信し、
   前記インジケータが、前記メッセージが前記グループ宛てである旨を示す場合、前記送信元を承認すると判定し、
   前記外部ＩＤと、前記ＭＴＣデバイスのアドレスを特定するための内部ＩＤとのマッピングを記憶し、
   前記マッピングを用い、前記メッセージ中で、前記外部ＩＤを対応する内部ＩＤへマッピングし、
   前記メッセージを、前記メッセージをＭＴＣデバイスへブロードキャストすることが可能なネットワーク構成要素へ転送する、
   ことを含む方法。

Images