JP7453388B2 - サービスアプリケーションとの暗号化された通信のための通信ネットワーク内のアンカキー生成および管理のための方法、デバイス、ならびにシステム - Google Patents

Description

本開示は、通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信のためのアンカキーおよびアプリケーションキー生成および管理を対象とする。

通信ネットワークでは、通信セッションおよびデータ経路が、端末デバイスとサービスアプリケーションとの間のデータフローの伝送をサポートするために確立され得る。そのようなデータフローの伝送は、暗号化／解読キーによって保護され得る。種々のレベルの暗号化／解読キーの生成および有効性管理が、端末デバイスを通信ネットワークに対して認証するための登録プロシージャの間と、端末デバイスとサービスアプリケーションとの間のアクティブ通信セッションの間とに、種々のネットワーク機能または通信ネットワーク内のネットワークノードの協働努力によって提供され得る。

本開示は、通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信のためのアンカキーおよびアプリケーションキー生成および管理に関する。

いくつかの実装では、通信ネットワークに登録されたサービスアプリケーションとの暗号化されたデータ伝送を有効にするための通信ネットワーク内の、ネットワークデバイス内でのアンカキーの生成のための方法が、開示される。本方法は、ネットワークデバイスによって実施されてもよく、通信ネットワークによって提供されるアンカキー管理サービスに対するユーザネットワークモジュールのサブスクリプションと関連付けられる、サブスクリプションデータパケットを取得するステップと、サブスクリプションデータパケットから、サービスアプリケーションに関連するサブスクリプションデータセットを抽出するステップと、ユーザネットワークモジュールを通信ネットワークに登録するための認証プロセスの完了成功に応じて、ベース認証キーを生成するステップと、ベース認証キーおよびサブスクリプションデータセットに基づいて、アンカキーを生成するステップと、アンカキーに基づいて生成されたアプリケーション暗号化キーを介して、ユーザネットワークモジュールと関連付けられるユーザ機器とサービスアプリケーションとの間の暗号化された通信を有効にするステップとを含んでもよい。

いくつかの実装では、上記のネットワークデバイスは、ユーザ機器または通信ネットワーク内の認証ネットワークノードを含んでもよい。

上記の実装のうちの任意の１つでは、サブスクリプションデータセットは、サービスアプリケーションと関連付けられる、通信ネットワーク内のアプリケーションキー管理ネットワークノードの識別子を含んでもよい。さらに、上記の実装のうちの任意の１つでは、アンカキーを生成するステップは、ベース認証キーと、アプリケーションキー管理ネットワークノードの識別子、ユーザネットワークモジュールの識別子、ユーザネットワークモジュールのタイプ、およびユーザ機器を通信ネットワークに登録するための認証プロセスの間に生成された認証データセットのうちの少なくとも１つとに基づいて、アンカキーを生成するステップを含んでもよい。

いくつかの他の実装では、ネットワークデバイスが、開示される。ネットワークデバイスは、１つまたはそれを上回るプロセッサと、１つまたはそれを上回るメモリとを含んでもよく、１つまたはそれを上回るプロセッサは、コンピュータコードを１つまたはそれを上回るメモリから読み取り、上記の方法のうちの任意の１つを実装するように構成される。

さらにいくつかの他の実装では、コンピュータプログラム製品が、開示される。コンピュータプログラム製品は、コンピュータコードがその上に記憶される、非一過性コンピュータ可読プログラム媒体を含んでもよく、コンピュータコードは、１つまたはそれを上回るプロセッサによって実行されると、１つまたはそれを上回るプロセッサに、上記の方法のうちの任意の１つを実装させる。

上記の実施形態ならびにその実装の他の側面および代替は、下記の図面、説明、および請求項においてより詳細に解説される。
本発明は、例えば、以下を提供する。
（項目１）
通信ネットワークに登録されたサービスアプリケーションとの暗号化されたデータ伝送を有効にするための通信ネットワーク内の、ネットワークデバイス内でのアンカキーの生成のための方法であって、前記方法は、前記ネットワークデバイスによって実施され、
前記通信ネットワークによって提供されるアンカキー管理サービスに対するユーザネットワークモジュールのサブスクリプションと関連付けられるサブスクリプションデータパケットを取得することと、
前記サブスクリプションデータパケットから、前記サービスアプリケーションに関連するサブスクリプションデータセットを抽出することと、
前記ユーザネットワークモジュールを前記通信ネットワークに登録するための認証プロセスの完了成功に応じて、ベース認証キーを生成することと、
前記ベース認証キーおよび前記サブスクリプションデータセットに基づいて、前記アンカキーを生成することと、
前記アンカキーに基づいて生成されたアプリケーション暗号化キーを介して、前記ユーザネットワークモジュールと関連付けられるユーザ機器と前記サービスアプリケーションとの間の暗号化された通信を有効にすることと
を含む、方法。
（項目２）
前記アンカキーのための一意の識別子を取得することをさらに含む、項目１に記載の方法。
（項目３）
前記ネットワークデバイスは、前記ユーザ機器を備える、項目２に記載の方法。
（項目４）
前記サブスクリプションデータセットは、前記アンカキー管理サービスに対する前記ユーザネットワークモジュールの前記サブスクリプションの間、前記ユーザ機器内に記憶される、項目３に記載の方法。
（項目５）
前記サブスクリプションデータセットは、前記サービスアプリケーションと関連付けられる前記通信ネットワーク内のアプリケーションキー管理ネットワークノードの識別子を備える、項目４に記載の方法。
（項目６）
前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子、前記ユーザネットワークモジュールの識別子、前記ユーザネットワークモジュールのタイプ、および前記ユーザ機器を前記通信ネットワークに登録するための認証プロセスの間に生成された認証データセットのうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、項目５に記載の方法。
（項目７）
前記認証データセットは、前記ユーザネットワークモジュールを前記通信ネットワークに登録するための認証プロセスにおいて生成された乱数を備え、
前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子および前記乱数のうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、
項目６に記載の方法。
（項目８）
前記アンカキーのための一意の識別子を生成することは、前記乱数と、前記アプリケーションキー管理ネットワークノードの識別子とを備える前記アンカキーのための一意の識別子を生成することを含む、項目７に記載の方法。
（項目９）
前記ネットワークデバイスは、前記通信ネットワーク内の認証ネットワークノードを備える、項目２に記載の方法。
（項目１０）
前記サブスクリプションデータパケットは、前記認証ネットワークノードと別個の前記通信ネットワークのユーザデータ管理ネットワークノードから取得され、
前記ユーザデータ管理ネットワークノードは、ユーザサブスクリプション情報を記憶するように構成される、
項目９に記載の方法。
（項目１１）
前記サブスクリプションデータセットは、前記サービスアプリケーションと関連付けられる前記通信ネットワーク内のアプリケーションキー管理ネットワークノードの識別子を備える、項目１０に記載の方法。
（項目１２）
前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子、前記ユーザネットワークモジュールの識別子、前記ユーザネットワークモジュールのタイプ、および前記ユーザ機器を前記通信ネットワークに登録するための認証プロセスの間に生成された認証データセットのうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、項目１１に記載の方法。
（項目１３）
前記認証データセットは、前記ユーザデータ管理ネットワークノードによって生成される、項目１２に記載の方法。
（項目１４）
前記認証データセットは、前記ユーザネットワークモジュールを前記通信ネットワークに登録するための認証プロセスにおいて、前記ユーザデータ管理ネットワークノードによって生成された乱数を備え、
前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子および前記乱数のうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、
項目１３に記載の方法。
（項目１５）
前記アンカキーのための一意の識別子は、前記乱数と、前記アプリケーションキー管理ネットワークノードの識別子とを備える、項目１４に記載の方法。
（項目１６）
前記アンカキーおよび前記乱数を前記アプリケーションキー管理ネットワークノードに伝送することをさらに含み、
前記アンカキーのための一意の識別子を取得することは、前記認証ネットワークノードからの前記乱数の受信に応じて、前記アプリケーションキー管理ネットワークノードによって生成された前記アンカキーのための一意の識別子を受信することを含む、
項目１４に記載の方法。
（項目１７）
前記アンカキーのための一意の識別子を取得することは、前記認証ネットワークノードによって、前記アンカキーのための一意の識別子を生成することを含む、項目１１に記載の方法。
（項目１８）
前記アンカキーおよび前記アンカキーのための一意の識別子を前記アプリケーションキー管理ネットワークノードに伝送することをさらに含む、項目１７に記載の方法。
（項目１９）
前記アンカキーを生成することはさらに、セキュアハッシュアルゴリズムを使用して、前記ベース認証キーおよび前記サブスクリプションデータセットを処理することに基づく、項目１に記載の方法。
（項目２０）
１つまたはそれを上回るプロセッサと、１つまたはそれを上回るメモリとを備えるデバイスであって、前記１つまたはそれを上回るプロセッサは、コンピュータコードを前記１つまたはそれを上回るメモリから読み取り、項目１－１９のいずれか１項に記載の方法を実装するように構成される、デバイス。
（項目２１）
コンピュータコードがその上に記憶される非一過性コンピュータ可読プログラム媒体を備えるコンピュータプログラム製品であって、前記コンピュータコードは、１つまたはそれを上回るプロセッサによって実行されると、前記１つまたはそれを上回るプロセッサに、項目１－１９のいずれか１項に記載の方法を実装させる、コンピュータプログラム製品。

図１は、端末デバイスと、キャリアネットワークと、データネットワークと、サービスアプリケーションとを含む、例示的通信ネットワークを示す。 図２は、通信ネットワーク内の例示的ネットワーク機能またはネットワークノードを示す。 図３は、無線通信ネットワーク内の例示的ネットワーク機能またはネットワークノードを示す。 図４は、無線通信ネットワーク内のアプリケーションアンカキーのユーザ認証および生成のための例示的実装を示す。 図５は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするための種々のレベルにおけるキーの生成のための種々のネットワークノードおよびネットワーク機能の例示的機能図を示す。 図６は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするための種々のレベルの暗号化キーの生成のための例示的論理フローを示す。 図７は、アプリケーションキー管理サービスに対するサブスクリプションと、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするための種々のレベルにおけるキーの生成とのための例示的アーキテクチャ図ならびに種々のネットワークノードおよびネットワーク機能を示す。 図８は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするためのアプリケーションキー管理サービスに対するサブスクリプション、ユーザ認証、およびアプリケーションアンカキーの生成のための例示的論理フローを示す。 図９は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするためのアプリケーションキー管理サービスに対するサブスクリプション、ユーザ認証、および種々のレベルの暗号化キーの生成のための例示的論理フローを示す。 図１０は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするためのアプリケーションキー管理サービスに対するサブスクリプション、ユーザ認証、および種々のレベルの暗号化キーの生成のための別の例示的論理フローを示す。 図１１は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするためのアプリケーションキー管理サービスに対するサブスクリプション、ユーザ認証、および種々のレベルの暗号化キーの生成のための別の例示的論理フローを示す。 図１２は、無線通信ネットワーク内の端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするためのアプリケーションキー管理サービスに対するサブスクリプション、ユーザ認証、および種々のレベルの暗号化キーの生成のためのさらに別の例示的論理フローを示す。 図１３は、無線通信ネットワーク内の無効アプリケーションアンカキーまたはアプリケーションキーを更新するための例示的論理フローを示す。 図１４は、種々のレベルにおける暗号化キーが無効になる、種々のシナリオにおける再認証／登録のための例示的論理フローを示す。

詳細な説明
図１に１００として示される例示的通信ネットワークは、端末デバイス１１０および１１２と、キャリアネットワーク１０２と、種々のサービスアプリケーション１４０と、他のデータネットワーク１５０とを含んでもよい。キャリアネットワーク１０２は、例えば、アクセスネットワーク１２０と、コアネットワーク１３０とを含んでもよい。キャリアネットワーク１０２は、端末デバイス１１０と１１２との間、端末デバイス１１０および１１２とサービスアプリケーション１４０との間、または端末デバイス１１０および１１２と他のデータネットワーク１５０との間で、音声、データ、および他の情報（集合的に、データトラフィックと称される）を伝送するように構成されてもよい。通信セッションおよび対応するデータ経路が、そのようなデータ伝送のために確立および構成されてもよい。アクセスネットワーク１２０は、端末デバイス１１０および１１２に、コアネットワーク１３０へのネットワークアクセスを提供するように構成されてもよい。コアネットワーク１３０は、通信セッションを制御し、ネットワークアクセス管理およびデータトラフィックルーティングを実施するように構成される、種々のネットワークノードまたはネットワーク機能を含んでもよい。サービスアプリケーション１４０は、キャリアネットワーク１０２のコアネットワーク１３０を通して端末デバイス１１０および１１２によってアクセス可能な種々のアプリケーションサーバによってホストされてもよい。サービスアプリケーション１４０は、コアネットワーク１３０の外側のデータネットワークとして展開されてもよい。同様に、他のデータネットワーク１５０は、コアネットワーク１３０を通して、端末デバイス１１０および１１２によってアクセス可能であってもよく、キャリアネットワーク１０２内でインスタンス化される特定の通信セッションのデータ宛先またはデータソースのいずれかとして現れてもよい。

図１のコアネットワーク１３０は、キャリアネットワーク１０２のサービス領域のネットワークカバレッジを提供するために地理的に分散および相互接続される、種々のネットワークノードまたは機能を含んでもよい。これらのネットワークノードまたは機能は、専用ハードウェアネットワーク要素として実装されてもよい。代替として、これらのネットワークノードまたは機能は、仮想機械として、またはソフトウェアエンティティとして、仮想化および実装されてもよい。ネットワークノードはそれぞれ、ネットワーク機能のうちの１つまたはそれを上回るタイプとともに構成されてもよい。これらのネットワークノードまたはネットワーク機能は、集合的に、コアネットワーク１３０のプロビジョニングおよびルーティングする機能性を提供し得る。用語「ネットワークノード」および「ネットワーク機能」は、本開示内で同義的に使用される。

図２はさらに、通信ネットワーク２００のコアネットワーク１３０内のネットワーク機能の例示的分割を示す。ネットワークノードまたは機能の単一インスタンスのみが、図２に図示されるが、当業者は、これらのネットワークノードのそれぞれが、コアネットワーク１３０全体を通して分散される、ネットワークノードの複数のインスタンスとしてインスタンス化され得ることを理解する。図２に示されるように、コアネットワーク１３０は、限定ではないが、アクセス管理ネットワークノード（ＡＭＮＮ）２３０、認証ネットワークノード（ＡＵＮＮ）２６０、ネットワークデータ管理ネットワークノード（ＮＤＭＮＮ）２７０、セッション管理ネットワークノード（ＳＭＮＮ）２４０、データルーティングネットワークノード（ＤＲＮＮ）２５０、ポリシ制御ネットワークノード（ＰＣＮＮ）２２０、およびアプリケーションデータ管理ネットワークノード（ＡＤＭＮＮ）２１０等のネットワークノードを含んでもよい。種々の通信インターフェースを通した種々のタイプのネットワークノード間の例示的シグナリングおよびデータ交換は、図２における種々の実線接続線によって示される。そのようなシグナリングおよびデータ交換は、所定のフォーマットまたはプロトコルに従って、シグナリングまたはデータメッセージによって搬送されてもよい。

上記の図１および２に説明される実装は、無線および有線通信システムの両方に適用されてもよい。図３は、図２の通信ネットワーク２００の一般的実装に基づく、例示的セルラー無線通信ネットワーク３００を図示する。図３は、無線通信ネットワーク３００が、ユーザ機器（ＵＥ）３１０（図２の端末デバイス１１０として機能する）と、無線アクセスネットワーク（ＲＡＮ）３２０（図２のアクセスネットワーク１２０として機能する）と、サービスアプリケーション１４０と、データネットワーク（ＤＮ）１５０と、アクセス管理機能（ＡＭＦ）３３０（図２のＡＭＮＮ２３０として機能する）と、セッション管理機能（ＳＭＦ）３４０（図２のＳＭＮＮ２４０として機能する）と、アプリケーション機能（ＡＦ）３９０（図２のＡＤＭＮＮ２１０として機能する）と、ユーザプレーン機能（ＵＰＦ）３５０（図２のＤＲＮＮ２５０として機能する）と、ポリシ制御機能３２２（図２のＰＣＮＮ２２０として機能する）と、認証サーバ機能（ＡＵＳＦ）３６０（図２のＡＵＮＮ２６０として機能する）と、ユニバーサルデータ管理（ＵＤＭ）機能３７０（図２のＵＤＭＮＮ２７０として機能する）とを含む、コアネットワーク１３０とを含み得ることを示す。再び、無線通信ネットワーク３００（特に、コアネットワーク１３０）のいくつかのネットワーク機能またはノードに関する単一インスタンスのみが、図３に図示されるが、当業者は、これらのネットワークノードまたは機能のそれぞれが、無線通信ネットワーク３００全体を通して分散される、複数のインスタンスを有してもよいことを理解する。

図３では、ＵＥ３１０は、ＲＡＮ３２０を介して、コアネットワーク１３０にアクセスするように構成される、種々のタイプのモバイルデバイスとして実装されてもよい。ＵＥ３１０は、限定ではないが、携帯電話、ラップトップコンピュータ、タブレット、モノのインターネット（ＩｏＴ）デバイス、分散型センサネットワークノード、ウェアラブルデバイス、および同等物を含んでもよい。ＲＡＮ３２０は、例えば、キャリアネットワークのサービスエリア全体を通して分散される、複数の無線基地局を含んでもよい。ＵＥ３１０とＲＡＮ３２０との間の通信は、図３における３１１によって示されるように、オーバーザエア（ＯＴＡ）無線インターフェースを経由して搬送されてもよい。

図３を継続すると、ＵＤＭ３７０は、ユーザがデータをコントラクトおよびサブスクリプションするための恒久的記憶装置またはデータベースを形成してもよい。ＵＤＭはさらに、ユーザ認証のための長期セキュリティ証明書の記憶のために、および下記にさらに詳細に説明されるように、そのような長期セキュリティ証明書を入力として使用して、暗号化キーの算出を実施するために、認証証明書リポジトリおよび処理機能（図３の３７０に示されるようなＡＲＰＦ）を含んでもよい。ＵＤＭ／ＡＲＰＦデータの非認可エクスポージャを防止するために、ＵＤＭ／ＡＲＰＦ３７０は、ネットワークオペレータまたは第三者のセキュアネットワーク環境内に位置してもよい。

ＡＭＦ／ＳＥＡＦ３３０は、これらのネットワークノードまたは機能に接続する種々の実線によって示される、通信インターフェースを介して、ＲＡＮ３２０、ＳＭＦ３４０、ＡＵＳＦ３６０、ＵＤＭ／ＡＲＰＦ３７０、およびＰＣＦ３２２と通信してもよい。ＡＭＦ／ＳＥＡＦ３３０は、非アクセス層（ＮＡＳ）シグナリング管理に対するＵＥと、ＵＥ３１０のコアネットワーク１３０への登録およびアクセスならびにＳＭＦ３４０の配分をプロビジョニングし、特定のＵＥの通信ニーズをサポートすることとに関与してもよい。ＡＭＦ／ＳＥＡＦ３３０は、ＵＥモビリティ管理にさらに関与してもよい。ＡＭＦはまた、下記にさらに詳細に説明されるように、セキュリティアンカ機能（図３の３３０に示されるようなＳＥＡＦ）を含み、種々のレベルの暗号化／解読キーのユーザ認証および管理のために、ＡＵＳＦ３６０およびＵＥ３１０と相互作用してもよい。ＡＵＳＦ３６０は、ＡＭＦ／ＳＥＡＦ３３０からのユーザ登録／認証／キー生成要求を終了し、そのようなユーザ登録／認証／キー生成を完了するために、ＵＤＭ／ＡＲＰＦ３７０と相互作用してもよい。

ＳＭＦ３４０は、無線通信ネットワーク３００内でインスタンス化される特定の通信セッションのために、ＡＭＦ／ＳＥＡＦ３３０によって配分されてもよい。ＳＭＦ３４０は、ＵＰＦ３５０を配分し、ユーザデータプレーンにおける通信セッションおよびその中のデータフローをサポートすることと、配分されるＵＰＦ３５０をプロビジョニング／調整すること（例えば、配分されるＵＰＦ３５０のためのパケット検出および転送ルールを規定すること）とに関与してもよい。ＳＭＦ３４０によって配分される代替として、ＵＰＦ３５０は、特定の通信セッションおよびデータフローのためにＡＭＦ／ＳＥＡＦ３３０によって配分されてもよい。ＳＭＦ３４０およびＡＭＦ／ＳＥＡＦ３３０によって配分およびプロビジョニングされるＵＰＦ３５０は、データルーティングおよび転送と、特定の通信セッションによるネットワーク使用量を報告することとに関与してもよい。例えば、ＵＰＦ３５０は、ＵＥ３１０とＤＮ１５０との間と、ＵＥ３１０とサービスアプリケーション１４０との間とのエンドツーエンドデータフローをルーティングすることに関与してもよい。ＤＮ１５０およびサービスアプリケーション１４０は、限定ではないが、無線通信ネットワーク３００のオペレータによって、または第三者データネットワークおよびサービスプロバイダによって提供される、データネットワークおよびサービスを含んでもよい。

サービスアプリケーション１４０は、例えば、コアネットワーク１３０によって提供されるネットワークエクスポージャ機能（図３に示されないが、図７に示され、これは、下記に説明される）を介して、ＡＦ３９０によって管理およびプロビジョニングされてもよい。ＳＭＦ３４０は、（例えば、ＵＥ３１０とサービスアプリケーション１４０との間に）サービスアプリケーション１４０を伴う、特定の通信セッションを管理する際、３１３によって示される通信インターフェースを介して、サービスアプリケーション１４０と関連付けられる、ＡＦ３９０と相互作用してもよい。

ＰＣＦ３２２は、ＵＥ３１０と関連付けられる、通信セッションに適用可能である、種々のレベルのポリシおよびルールを管理し、ＡＭＦ／ＳＥＡＦ３３０およびＳＭＦ３４０に提供することに関与してもよい。したがって、ＡＭＦ／ＳＥＡＦ３３０、例えば、ＵＥ３１０と関連付けられ、ＰＣＦ３２２から取得される、ポリシおよびルールに従って、通信セッションのためのＳＭＦ３４０を割り当ててもよい。同様に、ＳＭＦ３４０は、ＵＰＦ３５０を配分し、ＰＣＦ３２２から取得されるポリシおよびルールに従って、通信セッションのデータルーティングおよび転送をハンドリングしてもよい。

図２－１４および下記に説明される種々の例示的実装は、セルラー無線通信ネットワークに基づくが、本開示の範囲は、そのように限定されず、下層原理は、他のタイプの無線および有線通信ネットワークに適用可能である。

図３の無線通信ネットワーク３００内のネットワーク識別およびデータセキュリティは、ＡＭＦ／ＳＥＡＦ３３０、ＡＵＳＦ３６０、およびＵＤＭ／ＡＲＰＦ３７０によって提供される、ユーザ認証プロセスを介して管理されてもよい。特に、ＵＥ３１０は、最初に、ネットワーク登録のために、ＡＭＦ／ＳＥＡＦ３３０と通信してもよく、次いで、ＵＤＭ／ＡＲＰＦ３７０内のユーザコントラクトおよびサブスクリプションデータに従って、ＡＵＳＦ３６０によって認証されてもよい。無線通信ネットワーク３００に対するユーザ認証後のＵＥ３１０のために確立される通信セッションは、次いで、種々のレベルの暗号化／解読キーによって保護されてもよい。種々のキーの生成および管理は、ＡＵＳＦ３６０および通信ネットワーク内の他のネットワーク機能によって連携されてもよい。

無線通信ネットワーク３００に対するＵＥ３１０の認証は、ＵＥ３１０と関連付けられる、ネットワーク識別の照合に基づいてもよい。いくつかの実装では、ＵＥ３１０は、メインモバイル機器（ＭＥ）に加え、識別モジュールを含んでもよい。ＭＥは、例えば、情報処理能力（１つまたはそれを上回るプロセッサと、１つまたはそれを上回るメモリと）を有し、モバイルオペレーティングシステムおよび他のソフトウェアコンポーネントとともに、ＵＥ３１０のための通信および処理ニーズを提供するためにインストールされる、メイン端末デバイスを含んでもよい。識別モジュールは、ＵＥ３１０とともに、ユーザを通信ネットワークに対して識別および認証し、ユーザとＭＥを関連付けるために、含まれてもよい。識別モジュールは、加入者識別モジュール（ＳＩＭ）の種々の生成として実装されてもよい。例えば、識別モジュールは、ユニバーサル加入者識別モジュール（ＵＳＩＭ）またはユニバーサル集積回路カード（ＵＩＣＣ）として実装されてもよい。識別モジュールは、ユーザ識別またはその派生物を含んでもよい。ユーザ識別は、ユーザが、最初に、無線通信ネットワーク３００をサブスクライブするとき、通信ネットワークのオペレータによって割り当てられてもよい。

ユーザ識別は、例えば、無線通信ネットワークのオペレータによってユーザに割り当てられる、サブスクリプション永続識別子（ＳＵＰＩ）を含んでもよい。いくつかの実装では、ＳＵＰＩは、国際携帯機器加入者識別情報番号（ＩＭＳＩ）またはネットワークアクセス識別子（ＮＡＩ）を含んでもよい。ＳＵＰＩの代替として、ユーザ識別は、サブスクリプション秘匿化識別子（ＳＵＣＩ）等の隠蔽された識別の形態において提供されてもよい。ＳＵＣＩでは、ユーザの識別は、暗号化によって秘匿化および保護されてもよい。例えば、ＳＵＣＩは、１）、所定の数の情報ビット（例えば、値０－７のための３ビットであって、値０は、ユーザ識別がＩＭＳＩタイプであることを示し得、値１は、ユーザ識別がＮＡＩタイプであることを示し得、および他の値は、他の可能性として考えられるタイプのために留保され得る）を占有し得る、ＳＵＰＩタイプ、２）ユーザがサブスクライブし、ユーザのためのＳＵＰＩが、ＩＭＳＩタイプであるとき、無線通信ネットワーク３００のオペレータのためのモバイル国コード（ＭＣＣ）と、モバイルネットワークコード（ＭＮＣ）とを含み得、代替として、例えば、ユーザのためのＳＵＰＩがＮＡＩタイプであるとき、ＩＥＴＦ ＲＦＣ７５４２の第２．２節内に規定された、識別子を含み得る、無線ネットワークのためのホームネットワーク識別子、３）無線通信ネットワーク３００のオペレータによって割り当てられ、上記のホームネットワーク識別子とともに、ＵＥ３１０と関連付けられる、ＡＵＳＦおよびＵＤＭを判定する、ルーティングインジケータ（ＲＩＤ）、４）保護なし（ヌルスキーム）または保護あり（非ヌルスキーム）の選択肢を示すための保護スキーム識別子（ＰＳＩ）、５）ホームネットワークによってＳＵＰＩを保護するために提供される、パブリックキーのための識別子を規定するための、ホームネットワークパブリックキー識別子（本識別子値は、上記のＰＳＩがヌルスキームを示すとき、ゼロとして設定され得る）、および６）ホームネットワークパブリックキーによって、例えば、上記のＰＳＩが非ヌルスキームを示すとき、楕円曲線暗号を使用して暗号化された、ＩＭＳＩまたはＮＡＩのモバイル加入者識別番号（ＭＳＩＮ）部分を含み得、上記のＰＳＩがヌルスキームを示すとき、ＭＳＩＮまたはＮＡＩ（暗号化を伴わない）を含み得る、スキーム出力を含んでもよい。例示的ＳＵＣＩに関して、ＩＭＳＩが、２３４１５０９９９９９９９９９、すなわち、ＭＣＣ＝２３４、ＭＮＣ＝１５、およびＭＳＩＮ＝０９９９９９９９９９であるとき、ＲＩＤが、６７８であって、ホームネットワークパブリックキー識別子が、２７であると仮定すると、保護されていないＳＵＣＩは、｛０、（２３４、１５）、６７８、０、０、および０９９９９９９９９９｝を含み得、保護されるＳＵＣＩは、｛０、（２３４、１５）、６７８、１、２７、＜パブリックキー識別子２７＞によって示されるパブリックキーを使用した、０９９９９９９９９９の楕円曲線暗号｝を含み得る。

コアネットワーク１３０を介した、ＵＥ３１０と他のＵＥ、ＤＮ１５０、またはサービスアプリケーション１４０との間の通信セッションのデータ経路の部分は、例えば、コアネットワーク１３０内のセキュア通信環境の外側にあり得るものであるため、これらのデータ経路内で伝送されるユーザ識別およびユーザデータは、したがって、非セキュアネットワーク環境にエクスポーズされ得、セキュリティ侵害を受け得る。したがって、種々のレベルの暗号化／解読キーを使用して、通信セッション内で伝送されるデータをさらに保護することが好ましくあり得る。上記に示されるように、これらのキーは、無線通信ネットワーク３００に対するユーザ認証プロセスと併せて、ＡＵＳＦ３６０によって管理されてもよい。これらの暗号化／解読キーは、複数のレベルにおいて、かつ階層様式において、編成されてもよい。例えば、第１のレベルベースキーは、ＡＵＳＦ３６０によって、無線通信ネットワーク３００のサービスに対する初期サブスクリプションに応じて、ＵＥ３１０のために生成されてもよい。第２のレベルベースキーは、無線通信ネットワークに対する各登録および認証に応じて、ＵＥ３１０のために構成されてもよい。そのような第２のレベルベースキーは、ＵＥ３１０のための登録セッションの間、有効であってもよく、他のより高レベルのキーを生成するためのベースキーとして使用されてもよい。そのようなより高レベルのキーの実施例は、通信セッションにおいてデータを伝送するための実際の暗号化／解読キーとしての使用のためのさらにより高レベルのキーを導出するために使用され得る、アンカキーを含んでもよい。

そのようなマルチレベルキースキームは、特に、ＵＥ３１０およびサービスアプリケーション１４０を伴う通信セッションのために有用であり得る。特に、アプリケーションアンカキーは、ベースキーに基づいて生成され、ＵＥ３１０と複数のサービスアプリケーションとの間の通信のためのセキュリティアンカとして管理されてもよい。ＵＥ３１０のための異なるサービスアプリケーション１４０との異なる通信セッションは、異なるデータ暗号化／解読キーを使用してもよい。これらの異なるデータ暗号化／解読キーはそれぞれ、独立して、アンカキーに基づいて、生成および管理されてもよい。

いくつかの実装では、コアネットワーク１３０は、サービスアプリケーション（ＡＫＭＡ）のための認証およびキー管理のための特殊アーキテクチャを包含するように構成されてもよい。無線通信ネットワーク３００はさらに、例えば、そのコアネットワーク１３０内のＡＫＭＡアンカ機能（ＡＡｎＦ）またはネットワークノードを含んでもよい。例示的ＡＡｎＦ３８０は、図３に図示される。ＡＡｎＦ３８０は、ＡＵＳＦ３６０および種々のサービスアプリケーションと関連付けられる種々のＡＦ３９０との協働において、種々のサービスアプリケーションのためのデータ暗号化／解読キーの生成および管理に関与してもよい。ＡＡｎＦ３８０はさらに、ＵＥ３１０のためのセキュリティコンテキストの維持に関与してもよい。例えば、ＡＡｎＦ３８０の機能性は、汎用ブートストラップピングアーキテクチャ（ＧＢＡ）におけるブートストラップピングサーバ機能（ＢＳＦ）に類似し得る。複数のＡＡｎＦ３８０が、コアネットワーク１３０内で展開されてもよく、各ＡＡｎＦ３８０は、１つまたはそれを上回るサービスアプリケーションおよび対応するＡＦ３９０と関連付けられ、そのキー管理に関与してもよい。

図４および５は、上記の階層ＡＫＭＡのための例示的実装を図示する。例えば、図４は、サービスアプリケーションを伴う通信セッションのためのベースキーおよびアンカキーの生成のための実装４００を図示する。具体的には、実装４００は、ユーザ認証プロシージャ４０２と、アンカキー生成プロシージャ４０４とを含んでもよい。ユーザ認証プロシージャ４０２は、例えば、ＵＥ３１０、ＡＭＦ／ＳＥＡＦ３３０、ＡＵＳＦ３６０、およびＵＤＭ／ＡＲＰＦ３７０からのアクションを伴ってもよい。例えば、ＵＥ３１０は、無線通信ネットワークに進入することに応じて、ネットワーク登録および認証要求をＡＭＦ／ＳＥＡＦ３３０に通信してもよい。そのような要求は、ＡＭＦ／ＳＥＡＦ３３０によって、処理のために、ＡＵＳＦ３６０に転送されてもよい。認証プロセスの間、ＡＵＳＦ３６０は、ユーザコントラクトおよびサブスクリプション情報をＵＤＭ／ＡＲＰＦ３７０から取得してもよい。５Ｇ無線システムのための認証プロセスは、例えば、５Ｇ－ＡＫＡ（認証およびキー同意）プロトコルまたはＥＡＰ－ＡＫＡ（拡張認証プロトコル－ＡＫＡ）に基づいてもよい。認証成功に応じて、認証ベクトルが、ＵＤＭ／ＡＲＰＦ３７０によって生成されてもよく、そのような認証ベクトルは、ＡＵＳＦ３６０に伝送されてもよい。ユーザ認証プロシージャ４０２の成功に続いて、ベースキーは、ＵＥ３１０側およびネットワーク側におけるＡＵＳＦ３６０の両方において生成されてもよい。そのようなベースキーは、Ｋ_ＡＵＳＦと称され得る。

図４における４１０および４２０によってさらに示されるように、アンカキーは、アンカキー生成プロシージャ４０４におけるＵＥ３１０およびＡＵＳＦ３６０の両方において、ベースキーＫ_ＡＵＳＦに基づいて、導出されてもよい。そのようなアンカキーは、Ｋ_ＡＫＭＡと称され得る。図４における４１２および４２２によってさらに示されるように、アンカキーＫ_ＡＫＭＡのための識別子は、ＵＥ３１０およびＡＵＳＦ３６０において生成されてもよい。そのような識別子は、Ｋ_ＩＤと称され得る。

図５はさらに、ベースキーＫ_ＡＵＳＦ５０２と、アンカキーＫ_ＡＫＭＡ５０４との生成に加え、ＵＥとサービスアプリケーションとの間の暗号化された通信のためのアプリケーションキー５０６の生成のための例示的実装５００を図示する。図５に示されるように、Ｋ_ＡＦとして示される、アプリケーションキー５０６は、アンカキーＫ_ＡＫＭＡ５０４に基づいて、ネットワーク側およびＵＥ側の両方上で生成されてもよい。特に、ネットワーク側上では、アンカキーＫ_ＡＫＭＡ５０４は、ＡＵＳＦ３６０によって、ベースキーＫ_ＡＵＳＦ５０２に基づいて生成されてもよいが、アプリケーションキーＫ_ＡＦ５０６の生成は、ＡＡｎＦ３８０を伴ってもよい。図５のＵＥ側上では、アンカキーＫ_ＡＫＭＡ５０４およびアプリケーションキーＫ_ＡＦ５０６の生成は、ＵＥのＭＥ（モバイル機器）部分５１０によって実施されるように図示される。特に、ＵＥ側上のそのようなキー生成は、主に、ＵＥ内の識別モジュール（例えば、ＳＩＭ）を伴うユーザ認証プロシージャ４０２が完了された後、ＭＥの処理電力および能力を利用することを伴ってもよい。

図４および５に図示されるアプリケーションキー管理スキームでは、１つまたはそれを上回るＡＡｎＦ３８０は、コアネットワーク内に分散されてもよく、１つまたはそれを上回るＡＡｎＦ３８０はそれぞれ、１つまたはそれを上回るＡＦ３９０と関連付けられてもよい。したがって、１つまたはそれを上回るＡＡｎＦ３８０はそれぞれ、１つまたはそれを上回るサービスアプリケーションと関連付けられてもよく、これらのサービスアプリケーションを伴う暗号化された通信のためのアプリケーションキーの生成および管理に関与してもよい。これらのサービスアプリケーションのうちの１つのためのアプリケーションキーはそれぞれ、全て、同一アンカキーＫ_ＡＫＭＡ５０４に基づいて生成されてもよいが、これらのアプリケーションキーは、ネットワーク側上では、対応するＡＡｎＦ３８０によって、独立して生成されてもよい。

図６はさらに、ＵＥ３１０と対応するＡＦ３９０との間の暗号化された通信を有効にするために、サービスアプリケーションと関連付けられる、アプリケーションキーの生成のための例示的論理フロー６００を図示する。ステップ６０１－１では、ＵＥ３１０は、最初に、ＡＭＦ／ＳＥＡＦ３３０、ＡＵＳＦ３６０、およびＵＤＭ／ＡＲＰＦ３７０によって、正常に登録および認証され得る（図４における４０２に類似する）。ＵＥ登録および認証に続いて、ベースキーＫ_ＡＵＳＦが、生成されてもよい。ステップ６０１－２では、アンカキーＫ_ＡＫＭＡおよび対応する識別子Ｋ_ＩＤが、ＵＥ側およびネットワーク側の両方上で生成され得る（図４の４１０、４１２、４２０、および４２２に類似する）。ステップ６０２では、ＵＥ３１０は、通信要求メッセージを送信することによって、ＡＦ３９０と関連付けられる、サービスアプリケーションとの通信セッションを開始する。要求は、ステップ６０１－２において生成され、ステップ６０１－１において生成された、アンカキーＫ_ＡＫＭＡと関連付けられる、識別子Ｋ_ＩＤを含んでもよい。ステップ６０３では、ＡＦ３９０は、キー要求メッセージをＡＡｎＦ３８０に送信してもよく、キー要求メッセージは、アンカキー識別子Ｋ_ＩＤと、ＡＦ３９０の識別子ＡＦ ＩＤとを含む。ステップ６０４では、ＡＡｎＦ３８０は、アンカキー識別子Ｋ_ＩＤと関連付けられる、アンカキーＫ_ＡＫＭＡが、ＡＡｎＦ３８０内に位置し得るかどうかを判定する。Ｋ_ＡＫＭＡが、ＡＡｎＦ３８０に見出される場合、論理フロー６００は、ステップ６０７に継続する。そうでなければ、ＡＡｎＦ３８０は、ステップ６０４において、アンカキー要求を、アンカキー識別子Ｋ_ＩＤを搬送する、ＡＵＳＦ３６０に送信し、ステップ６０５において、ＡＵＳＦ３６０が、ＡＡｎＦ３８０からのアンカキー要求に応答した、アンカキー識別子Ｋ_ＩＤに従って、アンカキーＫ_ＡＫＭＡを識別後、アンカキーＫ_ＡＫＭＡをＡＵＳＦ３６０から受信してもよい。ステップ６０６では、ＡＡｎＦ３８０は、Ｋ_ＡＦが、ＡＡｎＦ３８０において以前にまだ導出されていない、またはすでに期限切れである場合、アンカキーＫ_ＡＫＭＡに基づいて、アプリケーションキーＫ_ＡＦを導出する。導出されたＫ_ＡＫＭＡは、アプリケーションキー有効期間（または満了時間）と関連付けられ得る。ステップ６０７では、ＡＡｎＦ３８０は、アプリケーションキーＫ_ＡＦおよび対応する満了時間をＡＦ３９０に送信し得る。Ｋ_ＡＫＭＡをＡＡｎＦ３８０から取得後、ＡＦは、最後に、ステップ６０２において、ＵＥ３１０から送信される通信要求に応答し得る。ステップ６０８における応答は、例えば、Ｋ_ＡＦに関する満了時間を含んでもよく、そのような満了時間は、ＵＥ３１０によって、記録および記憶されてもよい。

図７は、上記に開示される種々のネットワーク機能によるＡＫＭＡ実装のための別の例示的アーキテクチャビュー７００を図示する。ＡＭＦ／ＳＥＡＦ３３０、ＡＵＳＦ３６０、ＡＦ３９０、ＵＤＭ／ＡＲＰＦ３７０、ＵＥ３１０、およびＡＡｎＦ３８０等の種々の機能は、上記に説明される例示的実装に従って、図７に示されるように、ＡＭＦ／ＳＥＡＦ３３０のためのＮａｍｆインターフェース、ＡＵＳＦ３６０のためのＮａｕｓｆインターフェース、ＡＦ３９０からのＮａｆインターフェース、ＵＤＭ／ＡＲＰＦ３７０のためのＮｕｄｍインターフェース、およびＡＡｎＦ３８０のためのＮａａｎｆインターフェース等の、これらのネットワーク機能と関連付けられる、種々のインターフェースを介して、相互に相互作用するように図示される。図７はさらに、コアネットワークのサービスアプリケーションと関連付けられるＡＦ３９０へのエクスポージャの能力を提供するためのゲートウェイとして、ネットワークエクスポージャ機能（ＮＥＦ）７０２を示す。図７の例示的アーキテクチャ図７００では、ＵＥ３１０は、Ｕａインターフェースを介して、ＡＦ３９０と、Ｎ１インターフェースを介して、ＡＭＦ／ＳＥＡＦ３３０と通信してもよい。ＵＥ３１０からコアネットワークへの通信は、ＲＡＮ３２０によって中継される。

上記に説明される実装では、ＡＵＳＦ、ＵＤＭ、ＡＵＳＦ、およびＡＡｎＦは、ＵＥ３１０のホームネットワークに属する。それらは、オペレータまたは認可される第三者によって提供される、セキュアネットワーク環境内に位置し得、非認可ネットワークアクセスにエクスポーズされ得ない。ローミングシナリオでは、ホームＵＤＭおよびＡＵＳＦは、ＵＥに関する認証情報を提供し、ＵＥのローミング場所を維持し、サブスクリプション情報を移動先ネットワークに供給する。

サービスアプリケーションとの通信セッション内で伝送されるデータのアプリケーションキー生成および暗号化／解読は、有意なレベルのコンピューティング能力およびエネルギー消費を要求する、実質的データ処理を伴い得る。そのようなレベルの算出ことが不可能である、いくつかのよりローエンドのＵＥは、上記に説明されるデータ暗号化／解読が必須にされる場合、サービスアプリケーションと通信することが不可能である場合がある。下記に説明されるいくつかのさらなる実装では、オプションは、に提供されてもよいように、ＵＥは、その中のデータフローがアプリケーションキーによって保護されるか、または保護されていないかのいずれかの状態で、サービスアプリケーションと通信してもよい。したがって、アプリケーションキー生成およびデータ暗号化／解読をタイムリーに実施することが不可能であり得る、よりローエンドのＵＥもなお、サービスアプリケーションとの保護されていない通信セッションを要求するオプションを有し、それによって、任意の複雑なキー生成およびデータ暗号化／解読を実施する必要性を回避する。

そのようなオプションは、サービスサブスクリプション機構を介して提供されてもよい。例えば、ＡＫＭＡが、ＵＥによってサブスクライブされ得る、サービスとして提供されてもよい。例えば、ＵＥは、ＡＫＭＡサービスをサブスクライブするか、またはサブスクライブしないかのいずれかであってもよい。ＵＥが、ＡＫＭＡサービスをサブスクライブするとき、ＵＥは、サービスアプリケーションとの保護される通信セッションを要求し得る。ＵＥおよび種々のネットワーク機能（ＡＡｎＦ３８０等）は、対応して、データ暗号化／解読のための必要なアプリケーションキー生成を行ってもよい。そうでなければ、ＵＥは、ＡＫＭＡサービスに対するサブスクリプションを有していないとき、ＵＥは、サービスアプリケーションとの保護されていない通信セッションのみを要求してもよく、アプリケーションキーおよびデータ暗号化／解読は、必要とされなくてもよい。

別の実施例に関して、その全体として、ＡＫＭＡサービスをサブスクライブするのではなく、ＵＥは、利用可能であって、かつネットワークエクスポージャ機能を介して通信ネットワークに登録された、サービスアプリケーションのいずれに関しても、ＡＫＭＡサービスをサブスクライブしない、その一部をサブスクライブする、または全てをサブスクライブしてもよい。ＵＥが、特定のサービスアプリケーションのためのＡＫＭＡサービスに対するサブスクリプションを有するとき、ＵＥは、そのサービスアプリケーションとの保護された通信セッションを要求し得る。ＵＥおよび種々のネットワーク機能（ＡＡｎＦ３８０等）は、対応して、データ暗号化／解読のための必要なアプリケーションキー生成を行ってもよい。そうでなければ、ＵＥが、特定のサービスアプリケーションのためのＡＫＭＡサービスに対するサブスクリプションを有していないとき、ＵＥは、そのサービスアプリケーションとの保護されていない通信セッションのみを要求してもよく、アプリケーションキーおよびデータ暗号化／解読は、その特定のサービスアプリケーションとの通信のために必要とされなくてもよい。

サービスアプリケーションのためのＡＫＭＡサービスのＵＥサブスクリプション情報は、ネットワーク側上で、ＵＤＭ／ＡＲＰＦ３７０によって管理されてもよい。特に、ＵＤＭ／ＡＲＰＦ３７０は、ＵＥ毎に、ＡＫＭＡサービスサブスクリプション情報を記録を保ってもよい。ＵＤＭ／ＡＲＰＦ３７０は、特定のＵＥのＡＫＭＡサービスサブスクリプション情報を要求するために、ＡＵＳＦ３６０等の通信ネットワークの他のネットワーク機能のためのインターフェースを提供するように構成されてもよい。ＵＤＭ／ＡＲＰＦ３７０は、例えば、要求に応じて、図７に図示されるＮｕｄｍインターフェースを介して、ＵＥ ＡＫＭＡサービスサブスクリプション情報をＡＵＳＦ３６０に送達してもよい。これらの実装では、ＵＤＭ／ＡＲＰＦ３７０は、本質的に、他のユーザデータ管理機能性に加え、ＡＫＭＡサービスサブスクリプション情報のリポジトリとして作用するように構成される。代替として、ＵＤＭ／ＡＲＰＦ３７０と別個およびそれ以外の専用ネットワーク機能が、コアネットワーク内に含まれ、ＡＫＭＡサービスサブスクリプションを管理するように構成されてもよい。

そのようなサブスクリプション情報は、ＵＤＭ／ＡＲＰＦ３７０内に種々の形態で記録されてもよい。サブスクリプション情報は、ＵＥによって、インデックス化されてもよい。例えば、各ＡＫＭＡサービスサブスクリプションは、ＵＥ識別子と関連付けられ得る。各ＡＫＭＡサービスサブスクリプションはさらに、（１）ＵＥがＡＫＭＡサービスをサブスクライブするかどうかに関するインジケータ、（２）ＵＥのサブスクリプションと関連付けられる、１つまたはそれを上回るＡａｎＦに関する識別子、および（３）ＡＡｎＦに対応する、アンカキーＫ_ＡＫＭＡの有効期間（または満了時間）のうちの１つまたはそれを上回るものを含んでもよい。ＡＡｎＦのための識別子は、ＡａｎＦのネットワークアドレスの形態で提供されてもよい。代替として、ＡＡｎＦの識別子は、ＡａｎＦの完全修飾ドメイン名（ＦＱＤＮ）の形態で提供されてもよい。各ＵＥは、それがサブスクライブする、１つまたはそれを上回るＡＡｎＦに対応し得る。

対応して、ＵＥの識別モジュール（例えば、ユニバーサル加入者識別モジュール（ＵＳＩＭ）またはユニバーサル統合識別カード（ＵＩＣＣ））は、ＵＥに関するＡＫＭＡサービスサブスクリプション情報を含んでもよい。そのようなサブスクリプション情報は、のうちの１つまたはそれを上回るものを含んでもよい（１）ＵＥがＡＫＭＡサービスをサブスクライブするかどうかに関するインジケータ、（２）ＵＥのＡＫＭＡサービスサブスクリプションと関連付けられる、１つまたはそれを上回るＡＡｎＦの識別子、（３）ＡＡｎＦに対応する、アンカキーＫ_ＡＫＭＡの有効期間、および（４）ＵＥによってサブスクライブされるアプリケーションサービスに対応する、ＡＦの識別子。再び、ＡＡｎＦのための識別子は、ＡＡｎＦのネットワークアドレスの形態で提供されてもよい。代替として、ＡＡｎＦの識別子は、ＡＡｎＦのＦＱＤＮの形態で提供されてもよい。各ＵＥは、１つまたはそれを上回るサブスクライブされたＡＡｎＦに対応し得る。同様に、ＡＦのための識別子は、ＡＦのネットワークアドレスの形態で提供されてもよい。代替として、ＡＦの識別子は、ＡＦのＦＱＤＮの形態で提供されてもよい。各ＵＥは、１つまたはそれを上回るＡＦに対応し得る。いくつかの実装では、複数のＡＦは、同一ＡＡｎＦと関連付けられ得るが、各ＡＦは、１つのＡＡｎＦのみと関連付けられ得る。

図８は、ＵＥがＡＫＭＡサービスをサブスクライブしていることを示すときの、ユーザ認証およびアンカキーＫ_ＡＫＭＡの生成のための例示的論理フロー８００、８５０、および８６０を示す。論理フロー８００は、例示的ＵＥ登録および認証プロシージャを図示する一方、論理フロー８５０は、アンカキーＫ_ＡＫＭＡの生成のための例示的プロセスを図示し、論理フロー８６０は、論理フロー８５０の代替として、アンカキーＫ_ＡＫＭＡの生成ための別の例示的プロセスを図示する。８４０によって示されるように、ＵＥ３１０は、ＡＫＭＡサービスをサブスクライブしてもよく、ＵＥ３１０に対応する、ＡＫＭＡサービスサブスクリプション情報は、ＵＥ３１０内に記録されてもよい。そのようなサブスクリプション情報は、ＵＥ３１０がＡＫＭＡサービスをサブスクライブしているかどうかに関するインジケータ、１つまたはそれを上回るＡＡｎＦ識別子、１つまたはそれを上回るＡＦ識別子、およびＡＫＭＡアンカキー有効期間の１つまたはそれを上回る組み合わせを含んでもよい。８４２によってさらに示されるように、ＵＤＭ／ＡＲＰＦ３７０内に記録される対応するユーザサブスクリプション情報は、ＵＥ３１０がＡＫＭＡサービスをサブスクライブしているかどうかに関するインジケータ、１つまたはそれを上回るＡＡｎＦ識別子、およびＡＫＭＡアンカキー有効期間のうちの１つまたはそれを上回るものを含んでもよい。ＵＥ登録および認証プロシージャの間、ＵＤＭ／ＡＲＰＦ３７０は、ＡＫＭＡサービスサブスクリプション情報をＡＵＳＦ３６０に伝送してもよい。ＵＥ登録および認証成功に応じて、ＡＵＳＦ３６０は、ＵＤＭ／ＡＲＰＦ３７０から受信されたＡＫＭＡサービスサブスクリプション情報に基づいて、ＡＫＭＡアンカキーを導出してもよい。一方、ＵＥ３１０はまた、ＵＥ３１０内に記憶されるＡＫＭＡサービスサブスクリプション情報に基づいて、ＡＫＭＡアンカキーを導出してもよい。

ＵＥ登録／認証およびＡＫＭＡアンカキー生成のための具体的例示的ステップが、図８におけるステップ８０１－８１０によって図示される。ステップ８０１では、ＵＥ３１０は、要求メッセージをＡＭＦ／ＳＥＡＦ３３０に送信し、ＵＥ３１０のネットワークに対する登録／認証を開始する。ＡＭＦ／ＳＥＡＦ３３０は、ＵＥのホームネットワークによって、またはＵＥがローミングするシナリオでは、移動先ネットワークによって、提供されてもよい。要求メッセージは、ＳＵＣＩまたは５Ｇグローバル一意一時的ＵＥ識別（５Ｇ－ＧＵＴＩ）等のＵＥ３１０のユーザ識別子を含んでもよい。ステップ８０２では、ＡＭＦ／ＳＥＡＦ３３０は、ＡＵＳＦ認証要求をＡＵＳＦ３６０に送信する（例えば、Ｎａｕｓｆ＿ＵＥ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ＿Ａｕｔｈｅｎｔｉｃａｔｅ要求）。そのようなＡＵＳＦ要求は、ＵＥ３１０のＳＵＣＩまたはＳＵＰＩを含んでもよい。ステップ８０１における登録／認証要求が、５Ｇ－ＧＵＴＩを含む場合、ＡＭＦ／ＳＥＡＦ３３０は、最初に、ＳＵＰＩをＵＥのホームＡＭＦから取得してもよい。それが失敗する場合、ＡＭＦ／ＳＥＡＦ３３０は、ＳＵＣＩをＵＥ３１０から取得してもよい。ＡＵＳＦ要求はさらに、ＵＥ３１０のためのサービス提供ネットワーク（ＳＮ）の識別または名称を含んでもよい。ステップ８０３では、ＡＵＳＦ３６０（ＵＥのためのホームＡＵＳＦ）が、ＳＮ名が有効であることを判定後、ＡＵＳＦ３６０は、ＵＤＭ／ＡＲＰＦ３７０へのユーザ認証要求メッセージ（例えば、Ｎｕｄｍ＿ＵＥ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ＿Ｇｅｔ要求）を開始する。そのようなユーザ認証要求メッセージは、ＵＥ３１０のＳＵＣＩまたはＳＵＰＩを含んでもよい、さらに、ＳＮ名を含んでもよい。

図８を継続すると、ステップ８０４では、ＵＤＭ／ＡＲＰＦ３７０は、ステップ８０３のユーザ認証要求メッセージを受信し、メッセージ内に含有されるＳＵＣＩを解読し、ＳＵＰＩを取得してもよい。ＵＤＭ／ＡＲＰＦ３７０は、次いで、ユーザ認証のタイプ（例えば、５Ｇ－ＡＫＡまたはＥＡＰ－ＡＫＡ）を判定し、認証ベクトルを生成する。ＵＤＭ／ＡＲＰＦ３７０はさらに、そのサブスクリプションデータリポジトリにクエリし、ＵＥ３１０がＡＫＭＡサービスをサブスクライブしているかどうかを判定し、該当する場合、ＵＥ３１０に関するＡＫＭＡサービスサブスクリプション情報を取得する。ＵＤＭ／ＡＲＰＦ３７０は、次いで、ＡＵＳＦ３６０への認証ベクトル、ＳＵＣＩから解読されたＳＵＰＩ、および／またはＵＥ３１０に関するＡＫＭＡサービスサブスクリプション情報を含む、返信メッセージ（例えば、Ｎｕｄｍ＿ＵＥ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ＿Ｇｅｔ応答）によって、ステップ８０３のユーザ認証要求メッセージに応答する。ＵＤＭ／ＡＲＰＦ３７０によって生成され、返信メッセージ内に含まれる、認証ベクトルは、例えば、認証トークン（ＡＵＴＮ）、乱数（ＲＡＮＤ）、および／または種々の認証キーを含んでもよい。ＵＥに関するＡＫＭＡサービスサブスクリプション情報は、例えば、１つまたはそれを上回るＡａｎＦのための識別子および／またはＡＫＭＡアンカキーの有効期間を含んでもよい。

さらに、ステップ８０５では、ＡＵＳＦ３６０は、ステップ８０４においてＵＤＭ／ＡＲＰＦ３７０から送信される認証ベクトルを照合し、メイン認証プロシージャを開始する。そのような認証プロシージャは、例えば、５Ｇ－ＡＫＡまたはＥＡＰ－ＡＫＡに基づいてもよい。メイン認証プロシージャの完了成功後、ＵＥ３１０およびＡＵＳＦ３６０は両方とも、生成されたベースキーＫ_ＡＵＳＦを有するであろう。ＵＥ３１０およびＡＭＦ／ＳＥＡＦ３３０は、さらに生成された層と、非層アクセスキーとを有するであろう。

図８におけるステップ８０５に続く論理フロー８５０は、アンカキー生成のための例示的実装を図示する。具体的には、ステップ８０６では、ＵＥメイン認証論理フロー８５０が、成功後、ＵＥ３１０およびＡＵＳＦ３６０は、ＡＫＭＡアンカキーＫ_ＡＫＭＡ＝ＫＤＦ（Ｋ_ＡＵＳＦ、ＡＫＭＡタイプ、ＲＡＮＤ、ＳＵＰＩ、ＡＡｎＦ識別子）を生成してもよい。用語「ＫＤＦ」は、ＨＭＡＣ－ＳＨＡ－２５６（セキュアハッシュアルゴリズムのための２５６ビットハッシュベースのメッセージ認証コード）を伴う、例示的キー生成アルゴリズムを表す。Ｋ_ＡＵＳＦは、ベースキーを表す。「ＡＫＭＡタイプ」パラメータは、種々のＡＫＭＡタイプを表し、例えば、ＡＫＭＡは、ＭＥに基づいてもよい、（ＵＥのＭＥ部分は、キー生成および暗号化／解読計算に関与する）。別の実施例に関して、ＡＫＭＡは、ＵＩＣＣに基づいてもよく、ＵＥのＵＩＣＣ内の処理能力は、キー生成および暗号化／解読のために使用される。「ＲＡＮＤ」パラメータは、上記のステップ８０４においてＵＤＭ／ＡＲＰＦ３７０によって生成された認証ベクトル内の乱数を表す。ＡＡｎＦ識別子は、ＡＡｎＦのネットワークアドレスまたはＡＡｎＦのＦＱＤＮを含んでもよい。上記の例示的ＫＤＦ計算は、上記に議論される全てのパラメータを列挙するが、全てのこれらのパラメータが、計算内に含まれる必要があるわけではない。これらのパラメータのいずれかの任意の組み合わせが、ＫＤＦ計算のために、およびＫ_ＡＫＭＡの生成のために使用されてもよい。いくつかの実装では、Ｋ_ＡＵＳＦパラメータは、必須にされてもよく、他のパラメータは、随意にされてもよい。いくつかの他の実装では、Ｋ_ＡＵＳＦパラメータおよびＡＫＭＡサブスクリプション情報の少なくとも一部（例えば、ＡＫＭＡタイプ、ＡＡｎＦ識別子）は、必須にされてもよく、他のパラメータは、随意にされてもよい。

ステップ８０７では、ＵＥ３１０およびＡＵＳＦ３６０は、例えば、Ｋ_ＩＤ＝ＲＡＮＤ＠ＡＡｎＦ識別子またはＫ_ＩＤ＝ｂａｓｅ６４ｅｎｃｏｄｅ（ＲＡＮＤ）＠ＡＡｎＦ識別子として、ＡＫＭＡアンカキーのための識別子を生成してもよい。ここでは、上記のＵＤＭ／ＡＲＰＦ３７０から取得される認証ベクトル内のＲＡＮＤ乱数およびＡＡｎＦ識別子は、ＡＡｎＦネットワークアドレスまたはＦＱＤＮアドレスを含む。「ｂａｓｅ６４ｅｎｃｏｄｅ」によって定義される例示的エンコーディング方法は、例えば、ＩＥＦＴ ＲＦＣ３５４８プロトコル内に規定される。さらに、ステップ８０８では、ＡＵＳＦ３６０は、ステップ８０６において、ＡＫＭＡアンカキー、およびステップ８０７において、ＡＫＭＡアンカキー識別子を計算後、プッシュメッセージをＡＡｎＦ３８０に伝送してもよい。プッシュメッセージは、例えば、アンカキーＫ_ＡＫＭＡと、アンカキー識別子Ｋ_ＩＤとを含んでもよい。プッシュメッセージはさらに、アンカキーＫ_ＡＫＭＡに関する有効期間を含んでもよい。ＡＡｎＦ３８０は、次いで、アンカキーＫ_ＡＫＭＡおよびアンカキー識別子Ｋ_ＩＤを記憶してもよい。ＡＡｎＦ３８０はさらに、ＡＡｎＦ３８０におけるローカルキー管理方略に従って判定された、アンカキーＫ_ＡＫＭＡに関するローカル有効期間を識別してもよい。ＡＡｎＦ３８０は、アンカキーに関するローカル有効期間と、ステップ８０８においてＡＵＳＦ３６０から受信されたアンカキーに関する有効期間を比較し、より小さい値をアンカキーに関する実際の有効期間として使用してもよい。アンカキーに関する有効期間が、ステップ８０８においてＡＵＳＦ３６０からＡＡｎＦ３８０に送信されるメッセージ内にない場合、ＡＡｎＦ３８０は、ローカル有効期間をアンカキーに関する実際の有効期間として使用してもよい。アンカキーに関するローカル有効期間が、ＡＡｎＦ３８０に見出されない場合、ステップ８０８においてＡＵＳＦ３６０から受信された有効期間が、アンカキーに関する実際の有効期間として使用されてもよい。さらに、ステップ８０９では、ＡＡｎＦ３８０は、ステップ８０８におけるＡＵＳＦ３６０からＡＡｎＦ３８０へのプッシュメッセージの伝送成功に応じて、応答をＡＵＳＦ３６０に伝送する。

論理フロー８６０はさらに、上記の論理フロー８５０の代替として、アンカキー生成のための例示的実装を図示する。論理フロー８６０のステップ８０６Ａ、８０７Ａ、８０８Ａ、および８０９Ａは、それぞれ、ステップ８０６、８０７、８０８、および８０９に対応する。論理フロー８６０は、アンカキーＫ_ＡＫＭＡのための識別子Ｋ_ＩＤが、（ＡＡｎＦ３８０によって実施されるステップ８０８Ａによって示されるように）ネットワーク側上のＡＵＳＦ３６０ではなく、ＡＡｎＦ３８０によって生成されることを除き、論理フロー８５０に類似する。対応して、ＡＵＳＦ３６０からＡＡｎＦ３８０に送信されるプッシュメッセージは、パラメータＲＡＮＤを含んでもよく、これは、ステップ８０８ＡにおけるＡＡｎＦ３８０によるＫ_ＩＤの生成のためのコンポーネントのうちの１つとして使用されてもよい。論理フロー８６０内の種々の他のステップに関する詳細は、論理フロー８５０に関する上記の説明に見出され得る。

上記の論理フロー８５０または８６０に従って、アンカキーの生成成功後、ＵＥ３１０は、下記にさらに詳細に説明されるように、ＡＦ３９０との通信を開始してもよい。最後に、図８に関して、ステップ８１０によって示されるように、ＡＭＦ／ＳＥＡＦ３３０は、ステップ８０１の登録／認証要求の完了成功およびサブスクライブされたＡａｎＦに関するアンカキー生成の完了成功を示す、応答メッセージをＵＥ３１０に送信してもよい。ある他の代替実装では、ステップ８１０は、ステップ８０１の登録／認証要求の完了成功を示すために、ステップ８０６に先立って実施されてもよい。

図８に関する上記の実装では、ＡＫＭＡサービスは、必須ではなく、オプションとしてもたらされ、サブスクリプションのために、ＵＥに提供される。サブスクリプション情報は、ホームネットワーク側上で、およびＵＥ３１０内において、ＵＤＭ／ＡＲＰＦ３７０によって記憶および管理されてもよい。したがって、ＵＥ３１０は、ＡＫＭＡサービスをサブスクライブするか、またはＡＫＭＡサービスをサブスクライブしないかのいずれかのオプションを提供される。ＩｎＵＥが、ＡＫＭＡサービスをサブスクライブしない場合（例えば、ＵＥが、キー生成およびデータ暗号化をハンドリングするための能力を欠いているとき）、ＵＥは、アプリケーションアンカキーを生成するプロセスを止めてもよく、任意のアプリケーションキーを使用せずに、アプリケーションサーバと通信してもよい。ＵＥが、ＡＫＭＡをサブスクライブする場合、サブスクリプション情報は、随意に、ＡＫＭＡアンカキーおよびその識別子の生成のためのステップ８０６、８０６Ａ、８０７、および８０７Ａにおいて、随意のパラメータＡＡｎＦ ＩＤおよびＡＫＭＡタイプによって示されるように、使用されてもよい。

アプリケーションアンカキーＫ_ＡＫＭＡは、いったん上記の図８に説明されるように生成されると、次いで、ＵＥ３１０とＵＥ３１０がＡＫＭＡサービスをサブスクライブしているサービスアプリケーションとの間の暗号化された通信のためのアプリケーションキーの生成のためのベースとして使用されてもよい。上記の図８に関して図示されるように、ＵＤＭ／ＡＲＰＦ３７０によって生成された認証ベクトル内の乱数ＲＡＮＤ等のパラメータは、Ｋ_ＩＤを構築するために使用されてもよい（例えば、図８におけるステップ８０７および８０８参照）。識別子Ｋ_ＩＤは、ＵＥ３１０とサービスアプリケーションとの間の各通信の間、対応するＡＫＭＡアンカキーを識別するための検索インデックスとしてさらに使用されてもよい。コアネットワークのセキュア環境の外側のデータ経路を通したＲＡＮＤパラメータ等のこれらのパラメータの頻繁な伝送は、セキュリティ侵害またはこれらのパラメータの漏洩につながり得る。図９－１２の論理フローに図示され、下記に説明されるように、サービスアプリケーションとの暗号化された通信のためのアプリケーションキー生成の例示的実装は、これらのパラメータのセキュリティリスクを低減させるためのスキームを提供してもよい。

図９－１２では、例えば、図８に図示されるような認証およびアンカキー生成ステップ８０１－８０６に続く、ＵＥ３１０のメイン登録および認証およびアプリケーションアンカキーの生成後、ＵＥ３１０は、初期アプリケーションキーを生成し、通信のための要求をサービスアプリケーションと関連付けられるＡＦに送信してもよい。ＡＦは、初期アプリケーションキーをＡＡｎＦから取得してもよい。ＡＡｎＦは、一方、新しい乱数（ＮｅｗＲＡＮＤ）または新しいアンカキー識別子を生成し、ＡＦを介して、ＮｅｗＲＡＮＤまたは新しいアンカキー識別子をＵＥ３１０に送信してもよい。ＵＥは、次いで、ＮｅｗＲＡＮＤまたは新しいアンカキー識別子に基づいて、新しいアプリケーションキーを生成し、新しいアプリケーションキーを使用して、サービスアプリケーションとの実際の通信セッションを要求および確立してもよい。新しいアプリケーションキーを生成するために使用される、ＮｅｗＲＡＮＤおよび新しいアンカキー識別子は、新しいアプリケーションキーの生成のためのキーシードと称され得る。

図９－１２における８４０によって示されるように、ＵＥ３１０がＡＫＭＡサービスをサブスクライブしており、ＵＥ３１０内に記憶されるＡＫＭＡサービスサブスクリプション情報が、ＵＥがＡＫＭＡサービスをサブスクライブしているかどうかに関するインジケータ、１つまたはそれを上回るＡＡｎＦ識別子、１つまたはそれを上回るＡＦ識別子、およびＡＫＭＡアンカキー有効期間の１つまたはそれを上回る組み合わせを含み得ると仮定される。図９－１２における８４２によってさらに示されるように、ＵＤＭ／ＡＲＰＦ３７０内に記録される対応するユーザサブスクリプション情報は、ＵＥがＡＫＭＡサービスをサブスクライブしているかどうかに関するインジケータ、１つまたはそれを上回るＡＡｎＦ識別子、およびＡＫＭＡアンカキー有効期間のうちの１つまたはそれを上回るものを含んでもよい。ＡＡｎＦのための識別子は、ＡＡｎＦのネットワークアドレスの形態で提供されてもよい。代替として、ＡＡｎＦの識別子は、ＡＡｎＦのＦＱＤＮの形態で提供されてもよい。各ＵＥは、１つまたはそれを上回るサブスクライブされたＡＡｎＦに対応し得る。同様に、ＡＦのための識別子は、ＡＦのネットワークアドレスの形態で提供されてもよい。代替として、ＡＦの識別子は、ＡＦのＦＱＤＮの形態で提供されてもよい。各ＵＥは、１つまたはそれを上回るＡＦに対応し得る。いくつかの実装では、複数のＡＦは、同一ＡＡｎＦと関連付けられ得るが、各ＡＦは、１つのＡＡｎＦのみと関連付けられ得る。

図９の論理フロー９００に目を向けると、９０１に示されるように、ＵＥ３１０、ＡＭＦ／ＳＥＡＦ３３０、ＡＵＳＦ３６０、およびＵＤＭ／ＡＲＰＦ３７０は、最初に、図８に図示されるように、認証およびアンカキー生成ステップ８０１－８０６に続いて、ＵＥ３１０のメイン登録および認証ならびにＡＫＭＡアンカキーの生成を実施し得る。メイン認証およびＡＫＭＡアンカキー生成に関する詳細は、図８に関して上記に説明される。ステップ９０７では、ＵＥ３１０およびＡＵＳＦ３６０は、ＡＫＭＡアンカキーに関する初期識別子を、例えば、Ｋ_ＩＤ＝ＲＡＮＤ＠ＡＡｎＦ ＩＤまたはＫ_ＩＤ＝ｂａｓｅ６４ｅｎｃｏｄｅ（ＲＡＮＤ）＠ＡＡｎＦ ＩＤとして生成する。ＵＥ登録および認証成功に応じて、ステップ９０８では、ＡＭＦ／ＳＥＡＦ３３０は、応答メッセージをＵＥ３１０に通信し、登録および認証が成功したことを示す。ステップ９０８は、他の時間に実施されてもよい。例えば、ステップ９０８は、プロシージャ９０１の中のステップ８０６の前に実施されてもよい。

図９を継続すると、ステップ９０９では、ＵＥ３１０は、初期アプリケーションキーＫ_{ｉｎ－ＡＦ}＝ＫＤＦ（Ｋ_ＡＫＭＡ、ＲＡＮＤ、ＡＦ ＩＤ）を生成してもよく、ＫＤＦは、図８のステップ８０６に関して説明される例示的キー生成アルゴリズムを表す。ステップ９１０では、ＵＥ３１０は、初期通信要求をサービスアプリケーションと関連付けられるＡＦ３９０に送信する。初期通信要求は、例えば、ＡＫＭＡアンカキーのための識別子Ｋ_ＩＤを含んでもよい。さらに、ステップ９１１では、ＡＦ３９０は、初期通信要求をＵＥ３１０から受信し、Ｋ_ＩＤ内に含まれるＡＡｎＦ ＩＤに従って、初期アプリケーションキーＫ_{ｉｎ－ＡＦ}のための要求をＡＡｎＦ３８０に送信する。ＡＦ３９０からの初期アプリケーションキーＫ_{ｉｎ－ＡＦ}のための要求は、例えば、Ｋ_ＩＤと、ＡＦのための識別子ＡＦ ＩＤとを含んでもよい。ＡＡｎＦ３８０は、ステップ９１１においてＡＦ３９０から送信されるＫ_ＩＤに従って、ＡＫＭＡアンカキーＫ_ＡＫＭＡをクエリしてもよい。ＡＡｎＦ３８０が、ＡＫＭＡアンカキーＫ_ＡＫＭＡを見出す場合、論理フロー９００は、９１４に進み得る。ＡＡｎＦ３８０が、ＡＫＭＡアンカキーＫ_ＡＫＭＡを見出さない場合、ステップ９１２において、ＡＫＭＡアンカキー要求がＡＵＳＦ３６０に送信され得る。そのような要求は、Ｋ_ＩＤを含んでもよい。ステップ９１２の要求の受信に応じて、ＡＵＳＦ３６０は、ステップ９１３において、Ｋ_ＩＤに従って、要求されるＡＫＭＡアンカキーＫ_ＡＫＭＡを識別し、ＡＡｎＦ３８０に、Ｋ_ＡＫＭＡおよびその有効期間で応答してもよい。ステップ９１４では、ＡＡｎＦ３８０は、次いで、アンカキーＫ_ＡＫＭＡおよびその有効期間を記憶してもよい。ＡＡｎＦ３８０はさらに、ＡＡｎＦ３８０においてローカルキー管理方略に従って判定された、アンカキーＫ_ＡＫＭＡに関するローカル有効期間を識別してもよい。ＡＡｎＦ３８０は、アンカキーに関するローカル有効期間と、ステップ８０８においてＡＵＳＦ３６０から受信されたアンカキーに関する有効期間を比較し、より小さい値をアンカキーに関する実際の有効期間として使用してもよい。アンカキーに関する有効期間が、ステップ８０８において、ＡＵＳＦ３６０からＡＡｎＦ３８０に送信されるメッセージ内に含まれない場合、ＡＡｎＦ３８０は、ローカル有効期間をアンカキーに関する実際の有効期間として使用してもよい。アンカキーに関するローカル有効期間が、ＡＡｎＦ３８０に見出されない場合、ステップ８０８においてＡＵＳＦ３６０から受信された有効期間は、アンカキーに関する実際の有効期間として使用されてもよい。さらに、ステップ９１４では、ＡＡｎＦ３８０は、Ｋ_{ｉｎ－ＡＦ}＝ＫＤＦ（Ｋ_ＡＫＭＡ、ＲＡＮＤ、ＡＦ ＩＤ）に基づいて、Ｋ_{ｉｎ－ＡＦ}を生成してもよい。例示的キー計算ＫＤＦアルゴリズムは、図９のステップ９０９および図８におけるステップ８０６に関して前述された通りである。

図９を継続すると、ステップ９１５では、ＡＡｎＦ３８０は、ＮｅｗＲＡＮＤとして示される新しい乱数を生成してもよい。ＡＡｎＦ３８０はさらに、ＡＫＭＡアンカキーのための新しい識別子を、Ｋ_{ＩＤ－ＮＥＷ}＝ＮｅｗＲＡＮＤ＠ＡＡｎＦ ＩＤまたはＫ_{ＩＤ－ＮＥＷ}＝ｂａｓｅ６４ｅｎｃｏｄｅ（ＮｅｗＲＡＮＤ）＠ＡＡｎＦ ＩＤとして生成してもよい。ステップ９１６では、ＡＡｎＦ３０８は、ステップ９１１において、初期Ｋ_{ｉｎ－ＡＦ}のための要求に対する応答を送信する。そのような応答は、初期アプリケーションキーＫ_{ｉｎ－ＡＦ}、ＮｅｗＲＡＮＤ、Ｋ_{ＩＤ－ＮＥＷ}、および／またはＫ_{ＩＤ－ＮＥＷ}に関する有効期間を含んでもよい。いくつかの実装では、Ｋ_{ＩＤ－ＮＥＷ}に関する有効期間は、ＡＫＭＡアンカキーに関する有効期間より長くあり得ない。ステップ９１７（下記の説明参照）が、ステップ９１６に先立って実施される場合、ステップ９１６における応答はさらに、下記のステップ９１７において生成された、新しいＫ_ＡＦを含んでもよい。

ステップ９１７では、ＡＡｎＦ３８０は、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}をＫ_{ＡＦ－Ｎｅｗ}＝ＫＤＦ（Ｋ_ＡＫＭＡ、ＮｅｗＲＡＮＤ、ＡＦ ＩＤ）として生成する。ＫＤＦアルゴリズムは、すでに上記に説明されたものに類似する。ステップ９１７が、ステップ９１６に先立って、代替として実施されてもよい。ステップ９１８では、ＡＦ３９０は、対のＫ_{ＡＦ－Ｎｅｗ}およびＫ_{ＩＤ－ＮＥＷ}を記録してもよい。ＡＦ３９０はさらに、ステップ９１０の要求に応答し、応答メッセージをＵＥ３１０に送信してもよい。そのような応答メッセージは、新しい乱数ＮｅｗＲＡＮＤおよび／または新しいＡＫＭＡアンカキー識別子Ｋ_{ＩＤ－ＮＥＷ}を含んでもよい。応答メッセージはさらに、Ｋ_{ＡＦ－Ｎｅｗ}に関する有効期間を含んでもよい。いくつかの実装では、本応答メッセージの伝送は、Ｋ_{ｉｎ－ＡＦ}を使用して、暗号化されてもよい。換言すると、ステップ９１８における応答の種々の伝送されるコンポーネントは、Ｋ_{ｉｎ－ＡＦ}を使用して暗号化されてもよい。その後、ＡＦ３９０は、初期Ｋ_{ｉｎ－ＡＦ}を除去してもよい。

ステップ９１９では、ＵＥ３１０は、ステップ９１８の応答を受信する。応答が、Ｋ_{ｉｎ－ＡＦ}で暗号化される場合、ＵＥ３１０は、それがステップ９０９において導出した、Ｋ_{ｉｎ－ＡＦ}を使用して、応答を解読してもよい。応答が、ＮｅｗＲＡＮＤを含む場合、ＵＥ３１０は、解読後、応答内に含まれるＮｅｗＲＡＮＤコンポーネントを取得してもよい。ＵＥ３１０は、次いで、ＡＫＭＡアンカキーのための新しい識別子Ｋ_{ＩＤ－ＮＥＷ}をＫ_{ｉｎ－ＡＦ}＝ＮｅｗＲＡＮＤ＠ＡＡｎＦ ＩＤとして生成してもよい。暗号化されたＫ_{ＩＤ－ＮＥＷ}が、ステップ９１８の応答内にすでに含まれている場合、ＵＥ３１０は、応答を解読して、直接、Ｋ_{ＩＤ－ＮＥＷ}を取得してもよい。

ステップ９２０では、ＵＥ３１０は、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}をＫ_{ＡＦ－Ｎｅｗ}＝ＫＤＦ（Ｋ_ＡＫＭＡ、ＮｅｗＲＡＮＤ、ＡＦ ＩＤ）として生成してもよく、ＫＤＦは、図８のステップ８０６に関して上記に説明されるキー生成アルゴリズムである。ＵＥ３１０は、新しいＡＫＭＡアンカキーＩＤＫ_{ＩＤ－ＮＥＷ}および新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}を記憶してもよい。新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}に関する有効期間が、ステップ９１８の応答内に含まれる場合、ＵＥ３１０はまた、応答を解読し、Ｋ_{ＡＦ－Ｎｅｗ}に関する有効期間を取得し、それをローカルで記憶してもよい。

ステップ９２１では、ＵＥ３１０は、ＡＦ３９０への別の通信要求を開始してもよい。要求メッセージは、ＡＫＭＡアンカキーのための新しい識別子Ｋ_{ＩＤ－ＮＥＷ}を含んでもよく、要求メッセージは、ＵＥ３１０によって、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}を使用して、さらに暗号化されてもよい。ステップ９２２では、ＡＦ３９０は、ステップ９２１の通信要求を受信し、最初に、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}がローカルで存在するかどうかを判定してもよい。Ｋ_{ＡＦ－Ｎｅｗ}が、ローカルで存在する場合、ＡＦ２９０は、ステップ９２１において、そのようなＫ_{ＡＦ－Ｎｅｗ}を使用して、ＵＥ３１０からの通信要求を解読してもよい。ＡＦ３９０が、Ｋ_{ＡＦ－Ｎｅｗ}を見出すことができない場合、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}のための要求メッセージをＡＡｎＦ３８０に送信する。要求メッセージは、ＡＫＭＡアンカキーのための新しい識別子Ｋ_{ＩＤ－ＮＥＷ}と、ＡＦ ＩＤとを含んでもよい。ステップ９２３では、ＡＡｎＦ３８０は、要求メッセージをステップ９２２から受信し、Ｋ_{ＩＤ－ＮＥＷ}に基づいて、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}をクエリし、それに応答して、Ｋ_{ＡＦ－Ｎｅｗ}をＡＦ３９０に返す。ステップ９１６が、Ｋ_{ＡＦ－Ｎｅｗ}に関する任意の有効期間を含まない場合、そのような有効期間は、ステップ９２３において、ＡＦ３９０に対する応答メッセージ内に含まれてもよい。最後に、ステップ９２４では、ＡＦ３９０は、Ｋ_{ＡＦ－Ｎｅｗ}を使用して、ステップ９２１において、ＵＥ３１０との通信を確立するために、ＵＥ３１０から送信される通信要求を解読し、ＵＥ３１０に応答してもよい。そのような応答は、新しいアプリケーションキーＫ_{ＡＦ－Ｎｅｗ}に関する有効期間を含んでもよい。

図１０は、図９の代替実装としての論理フロー１０００を示す。論理フロー１０００は、（１００２によって示されるように）図９のステップ９０７が図１０から除去されることを除き、（図９および１０内に同じ標識によって示されるように）図９の論理フロー９００に類似する。したがって、図１０におけるＡＵＳＦ３６０は、ＡＫＭＡアンカキーのための初期識別子Ｋ_ＩＤを生成する必要がない場合がある。故に、図１０におけるステップ１０１２（下線付きステップとして示される）は、図９のステップ９１２に取って代わる。具体的には、初期Ｋ_ＩＤが、ＡＵＳＦ３６０において生成されないため、ＡＫＭＡアンカキー情報に関するＡＡｎＦ３８０からＡＵＳＦ３６０への要求は、Ｋ_ＩＤではなく、ＲＡＮＤ下でクエリされてもよい。ＡＡｎＦ３８０は、図１０のステップ９１１において、ＲＡＮＤパラメータを、それがＡＦ３９０から受信した、Ｋ_ＩＤから導出してもよい。

図１１は、図９および１０の論理フロー９００および１０００の代替として、別の論理フロー１１００を示す。論理フロー１１００は、（図９および１０において同じ標識によって示されるように）図９の論理フロー９００に類似し、図９との差異は、図１１において注釈が付けられている。例えば、ステップ１１０２および１１０４（図１１における下線付きステップ）が、論理フロー１１００に追加される。特に、ステップ１１０２では、ＡＫＭＡアンカキーが、図９のステップ９１２および９１３（１１０６によって示されるように、図１１の実装から除去される）において実装されたように、ＡＡｎＦ３８０によってＡＵＳＦ３６０から受動的に要求されるのではなく、いったんＡＵＳＦ３６０によって生成されると、先を見越して、ＡＵＳＦ３６０からＡＡｎＦ３８０にプッシュされる。ステップ１１０４では、ＡＡｎＦ３８０は、ＡＫＭＡアンカキーがＡＡｎＦ３８０によって正常に受信される場合、応答をＡＵＳＦ３６０に提供する。さらに、図１０における同一ステップと比較される、図１１のステップ９１４は、ＡＡｎＦ３８０が、ステップ１１０２におけるＡＵＳＦ３６０からの先を見越したプッシの結果として、ＡＫＭＡアンカキーをすでに有するであろう理由から、図１１に示されるように、修正されてもよい。

図１２は、図９、１０、および１１の論理フロー９００、１０００、および１１００の代替として、さらに別の論理フロー１２００を示す。論理フロー１２００は、図９のステップ９０７、９１２、および９１３が、１２０１および１２０６によって示されるように除去され、ステップ９１４が、図１１に示されるように、図９から修正され、プッシュステップ１２０２および１２０４が、追加されるという点で、図１０の論理フロー１０００および図１１の論理フロー１１００の両方の実装に従う。したがって、図１２の実装では、ＡＫＭＡアンカキーは、図１１における実装と全く同じように、先を見越して、ＡＵＳＦ３６０からＡＡｎＦ３８０にプッシュされる。さらに、ステップ１２０２および１２０４における情報プッシュの結果として、ＡＫＭＡアンカキーをクエリするための要求が後にＡＵＳＦ３６０にダイレクトされる必要がないため、任意の初期Ｋ_ＩＤをＡＵＳＦ３６０において生成する必要がない。

図９－１２に図示される実装では、新しい乱数が、ＡＡｎＦ３８０によって生成され、新しいアプリケーションキーおよびＡＫＭＡアンカキーのための新しい識別子の生成のために使用される。ＵＤＭ／ＡＲＰＦ３７０による認証ベクトルの一部として生成されたオリジナルＲＡＮＤは、限定される様式において、種々のネットワーク機能間でのみ伝送され得、したがって、セキュリティ侵害に殆どエクスポーズされ得ない。新しい乱数は、ＵＥ３１０とＡＦ３９０との間の通信毎に生成され得、したがって、１つの新しい乱数のセキュリティ侵害は、別個の通信セッションに関するリスクを呈し得ない。通信セキュリティは、したがって、図９－１２の実装において改良される。

上記に説明されるように、通信セキュリティをさらに改良するために、ＵＥ３１０とサービスアプリケーションとの間の暗号化された通信に関わる種々のキーは、有効期間（または満了時間）と関連付けられ得る。換言すると、これらのキーは、そのような有効期間内でのみ有効である。特に、これらのキーが無効になると、ＵＥ３１０とサービスアプリケーションとの間の通信は、暗号化によって保護され得ない。したがって、これらのキーは、それらが無効になるとき、更新される必要があり得る。下記に説明される図１３－１４は、無効である、または無効となるとき、種々のキー（を含む、例えば、ＡＫＭＡアンカキーおよびアプリケーションキー）を更新する種々の実装を示す。

図１３は、無効キーを更新するためのＵＥ開始実装１３００を図示する。ユーザ認証プロシージャ４０２およびステップ４１０、４１２、４２０、４２２は、図４に関して説明される対応するステップと同じである。上記の図４の説明は、図１３におけるこれらのステップに適用される。これらのステップに続いて、ＡＫＭＡアンカキーが、生成されてもよい。ステップ１３０１では、ＵＥ３１０は、ＡＫＭＡアンカキーまたはＡＫＭＡアプリケーションキーが、無効である、またはなることを判定する。ＵＥ３１０は、次いで、無効ＡＫＭＡアンカキーまたはアプリケーションキー、対応する有効期間、および無効ＡＫＭＡアンカキーのための識別子を削除する。

ステップ１３０２では、ＵＥが、アイドル状態にあるとき、ＵＥは、無線ネットワーク（ＡＭＦ／ＳＥＡＦ３３０またはＡＵＳＦ３６０等のネットワーク機能）への登録要求メッセージを開始してもよい。そのような登録要求メッセージは、ＳＵＣＩまたは５Ｇ－ＧＵＴＩと、例えば、７のｎｇＫＳＩ（セキュリティコンテキストインデックス）とを含み、ＵＥセキュリティコンテキストが無効であることを示してもよい。ＵＥ３１０が、非緊急サービスまたは非高優先順位サービスをハンドリングする、アクティブ状態にあって、ＵＥ３１０が、アイドル状態に入るとき、ＵＥは、ネットワークへの登録要求を開始してもよい。ＵＥ３１０が、緊急サービスまたは高優先順位サービスをハンドリングする、アクティブ状態にあるとき、ＵＥは、緊急または高優先順位サービスの完了まで待機し、次いで、アイドル状態に入り、ネットワークへの登録要求を開始してもよい。いくつかの他の実装では、ＵＥが、アクティブ状態にあるとき、ＵＥは、アクティブサービスの完了を待機し、次いで、アクティブサービスの緊急または優先順位にかかわらず、ネットワークへの登録要求を開始してもよい。

ステップ１３０３では、ＵＥは、ネットワークとのメイン認証および登録を経て、次いで、新しいＡＫＭＡアンカキーおよび／またはアプリケーションキーを生成し、これらの新しいキーのための有効期間および識別子を判定してもよい。ＵＥおよびネットワークは両方とも、これらのキー、有効期間、および識別子を記録する。

図１４は、無効ＡＫＭＡキーのネットワーク開始更新を示す。図１４では、ＵＥは、ＡＫＭＡサービスをサブスクライブしているとされ得る。図１４の８４０では、ＵＥに対応する、ＡＫＭＡサービスサブスクリプション情報は、ＵＥ内に記録されてもよい。そのようなサブスクリプション情報は、ＵＥがＡＫＭＡサービスをサブスクライブしているかどうかに関するインジケータ、１つまたはそれを上回るＡＡｎＦ識別子、１つまたはそれを上回るＡＦ識別子、およびＡＫＭＡアンカキー有効期間の１つまたはそれを上回る組み合わせを含んでもよい。図１４の８４２では、ＵＤＭ／ＡＲＰＦ３７０内に記録される対応するユーザサブスクリプション情報は、ＵＥがＡＫＭＡサービスをサブスクライブしているかどうかに関するインジケータ、１つまたはそれを上回るＡＡｎＦ識別子、およびＡＫＭＡアンカキー有効期間のうちの１つまたはそれを上回るものを含んでもよい。ＵＥ登録および認証プロシージャの間、ＵＤＭ／ＡＲＰＦ３７０は、ＡＫＭＡサービスサブスクリプション情報をＡＵＳＦ３６０に伝送してもよい。

図１４のステップ１４０１では、ＵＥおよびネットワークは、メイン認証プロシージャを完了し、ＡＫＭＡアンカキーＫ_ＡＫＭＡおよび対応する識別子Ｋ_ＩＤ、ＡＫＭＡアプリケーションキーＫ_ＡＦ、ならびにこれらのキーに関する有効期間を生成する。これらのキーは、種々の理由から無効であり得る。図１４では、論理フロー１４６０、１４７０、および１４８０は、これらのキーのうちの少なくとも１つが無効になる、種々の例示的シナリオ下のキー更新を図示する。

例示的論理フロー１４６０に関して、ＡＫＭＡアンカキーは、無効であり得る。ステップ１４０２では、ＵＥ３１０は、ＡＦ３９０への通信要求を開始してもよい。通信要求は、ＡＫＭＡアンカキーのための識別子Ｋ_ＩＤを含んでもよい。ステップ１４０３では、ＡＦ３９０は、Ｋ_ＩＤ内のＡＡｎＦ識別子に従って、Ｋ_ＩＤおよびＡＦ ＩＤを含む、初期アプリケーションキー要求メッセージをＡＡｎＦ３８０に送信してもよい。ステップ１４０４では、ＡＡｎＦ３８０は、Ｋ_ＩＤに従って、ＡＫＭＡアンカキーＫ_ＡＫＭＡをクエリしてもよい。ＡＡｎＦ３８０がＡＫＭＡアンカキーＫ_ＡＫＭＡを見出さない場合、ＡＫＭＡアンカキー要求メッセージをＡＵＳＦ３６０に送信してもよい。要求メッセージは、Ｋ_ＩＤを含んでもよい。ステップ１４０５では、ＡＵＳＦ３６０は、Ｋ_ＩＤに従って、有効ＡＫＭＡアンカキーをクエリし得るが、有効ＡＫＭＡアンカキーを見出すことが不可能である場合がある。ＡＵＳＦ３６０は、次いで、失敗メッセージでＡＡｎＦ３８０に応答し、有効ＡＫＭＡアンカキーが見出されなかったことを示してもよい。ステップ１４０６では、ＡＡｎＦ３８０は、ＡＦ３９０に、失敗メッセージで応答し、有効ＡＫＭＡアンカキーが見出されなかったことを示す。ステップ１４０７では、ＡＦ３９０は、失敗メッセージでＵＥ３１０に応答し、有効ＡＫＭＡアンカキーが見出されなかったことを示してもよい。ステップ１４０８では、ＵＥ３１０は、ネットワークへの別の登録要求を開始する。そのような登録要求メッセージは、ＵＥのＳＵＣＩまたはＵＥの５Ｇ－ＧＵＴＩと、例えば、７のｎｇＫＳＩ（セキュリティコンテキストインデックス）とを含み、ＵＥセキュリティコンテキストが無効であることを示してもよい。ステップ１４０９では、ＵＥ３１０およびネットワークが、別のメイン認証および登録を完了後、新しいＡＫＭＡアンカキーおよび／またはＡＫＭＡアプリケーションキー、その識別子、および／またはその有効期間が、生成されてもよい。ＵＥ３１０およびネットワークは、これらのキー、有効期間、および識別子を保存してもよい。

例示的論理フロー１４７０に関して、アプリケーションキーが、期限が切れている場合がある。ステップ１４１０では、ＵＥ３１０は、ＡＦ３９０への通信要求を開始してもよい。通信要求は、ＡＫＭＡアンカキーのための識別子Ｋ_ＩＤを含んでもよい。ステップ１４１１では、ＡＦ３９０は、アプリケーションキーの期限が切れていることを判定し得る。ステップ１４１２では、ＡＦ３９０は、失敗メッセージでＵＥ３１０に応答し、アプリケーションキーの期限が切れたことを示してもよい。ステップ１４１３では、ＵＥ３１０は、ネットワークへの別の登録要求を開始する。そのような登録要求メッセージは、ＵＥのＳＵＣＩ、またはＵＥの５Ｇ－ＧＵＴＩと、例えば、７のｎｇＫＳＩ（セキュリティコンテキストインデックス）とを含み、ＵＥセキュリティコンテキストが無効であることを示してもよい。ステップ１４１４では、ＵＥ３１０およびネットワークが、別のメイン認証および登録を完了後、新しいＡＫＭＡアンカキーおよび／またはＡＫＭＡアプリケーションキー、その識別子、および／またはその有効期間が、生成されてもよい。ＵＥ３１０およびネットワークは、これらのキー、有効期間、および識別子を保存してもよい。

例示的論理フロー１４８０に関して、ＡＫＭＡアンカキーは、期限が切れている場合がある。ステップ１４１５では、ＵＥ３１０は、ＡＦ３９０への通信要求を開始してもよい。通信要求は、ＡＫＭＡアンカキーのための識別子Ｋ_ＩＤを含んでもよい。ステップ１４１６では、ＡＦ３９０は、Ｋ_ＩＤ内のＡＡｎＦ識別子に従って、Ｋ_ＩＤおよびＡＦ ＩＤを含む、アプリケーションキー要求メッセージをＡＡｎＦ３８０に送信してもよい。ステップ１４１７では、ＡＡｎＦ３８０は、ＡＫＭＡアンカキーＫ_ＡＫＭＡの期限が切れていることを判定し得る。ステップ１４１８では、ＡＡｎＦ３８０は、ＡＦ３９０に失敗メッセージで応答し、ＡＫＭＡアンカキーの期限が切れていることを示してもよい。ステップ１４１９では、ＡＦ３９０は、失敗メッセージでＵＥ３１０に応答し、ＡＫＭＡアンカキーの期限が切れていることを示してもよい。ステップ１４２０では、ＵＥ３１０は、ネットワークへの別の登録要求を開始する。そのような登録要求メッセージは、ＵＥのＳＵＣＩまたはＵＥの５Ｇ－ＧＵＴＩと、例えば、７のｎｇＫＳＩ（セキュリティコンテキストインデックス）とを含み、ＵＥセキュリティコンテキストが無効であることを示してもよい。ステップ１４２１では、ＵＥ３１０およびネットワークが、別のメイン認証および登録を完了後、新しいＡＫＭＡアンカキーおよび／またはＡＫＭＡアプリケーションキー、その識別子、および／またはその有効期間が、生成されてもよい。ＵＥ３１０およびネットワークは、これらのキー、有効期間、および識別子を保存してもよい。

図１－１４に関して上記に説明される実装は、したがって、通信ネットワークが端末デバイスによってサブスクライブされ得るアプリケーションキーサービスを提案する、アーキテクチャを提供する。これらの実装はさらに、通信ネットワークを介した端末デバイスとサービスアプリケーションとの間の暗号化された通信を有効にするための種々の階層レベルのキーの生成、管理、および更新のための種々のスキームを提供する。開示される実装は、サービスアプリケーションとの通信におけるフレキシビリティを促進し、セキュリティ侵害に対するリスクを低減させる。

付随の図面および上記の説明は、具体的例示的実施形態および実装を提供する。しかしながら、説明される主題は、種々の異なる形態で具現化されてもよく、したがって、網羅または請求される主題は、本明細書に記載される任意の例示的実施形態に限定されないものとして解釈されるように意図される。請求または網羅される主題に関する合理的広範囲が、意図される。とりわけ、例えば、主題は、方法、デバイス、コンポーネント、システム、またはコンピュータコードを記憶するための非一過性コンピュータ可読媒体として具現化されてもよい。故に、実施形態は、例えば、ハードウェア、ソフトウェア、ファームウェア、記憶媒体、またはそれらの任意の組み合わせの形態をとってもよい。例えば、上記に説明される方法実施形態は、メモリ内に記憶されるコンピュータコードを実行することによって、コンポーネント、デバイス、またはメモリと、プロセッサとを含む、システムによって実装されてもよい。

明細書および請求項全体を通して、用語は、述べられた意味以外の文脈において明示的に提案または含意される、微妙な意味を有してもよい。同様に、本明細書で使用されるような語句「一実施形態／実装では」は、必ずしも、本明細書で使用されるような同一実施形態を指すわけではなく、語句「別の実施形態／実装では」は、必ずしも、異なる実施形態を指すわけではない。例えば、請求される主題は、全体または部分的に、例示的実施形態の組み合わせを含むことが意図される。

一般に、専門用語は、少なくとも部分的に、文脈における使用から理解され得る。例えば、本明細書で使用されるような「および」、「または」、または「および／または」等の用語は、少なくとも部分的に、そのような用語が使用される文脈に依存し得る、種々の意味を含んでもよい。典型的には、「または」は、Ａ、Ｂ、またはＣ等のリストを関連付けるために使用される場合、Ａ、Ｂ、およびＣ（ここでは、包含的意味で使用される）、ならびにＡ、Ｂ、またはＣ（ここでは、排他的意味でで使用される）を意味するように意図される。加えて、本明細書で使用されるような用語「１つまたはそれを上回る」は、少なくとも部分的に、文脈に応じて、単数形の意味において、任意の特徴、構造、または特性を説明するために使用されてもよい、もしくは複数の意味において、特徴、構造、または特性の組み合わせを説明するために使用されてもよい。同様に、「ａ」、「ａｎ」、または「ｔｈｅ」等の用語は、少なくとも部分的に、文脈に応じて、単数形の使用を伝達する、または複数の使用を伝達すると理解され得る。加えて、用語「～に基づいて」は、必ずしも、要因の排他的セットを伝達するように意図するものではないと理解され得、代わりに、再び、少なくとも部分的に、文脈に応じて、必ずしも、明示的に説明されない、付加的要因の存在を可能にし得る。

本明細書全体を通して、特徴、利点、または類似用語の言及は、本ソリューションを用いて実現され得る、特徴および利点の全てが、その任意の単一実装内に含まれるべきである、またはそうであることを含意するものではない。むしろ、特徴および利点を言及する用語は、ある実施形態に関連して説明される具体的特徴、利点、または特性が、本ソリューションの少なくとも一実施形態に含まれることを意味すると理解される。したがって、特徴および利点ならびに類似用語の議論は、明細書全体を通しては、同一実施形態を指し得るが、必ずしもそうであるわけではない。

さらに、本ソリューションの説明される特徴、利点、および特性は、１つまたはそれを上回る実施形態では、任意の好適な様式において組み合わせられてもよい。当業者は、本明細書の説明に照らして、本ソリューションが、特定の実施形態の具体的特徴または利点のうちの１つまたはそれを上回るものを伴わずに、実践され得ることを認識するであろう。他のインスタンスでは、付加的特徴および利点は、ある実施形態では、本ソリューションの全ての実施形態内に存在しなくてもよいことが認識され得る。

Claims (20)

1. 通信ネットワーク内のネットワークデバイス内でのアンカキーの生成のための方法であって、前記方法は、前記ネットワークデバイスによって実行され、前記方法は、
   アンカキー管理サービスに対するユーザネットワークモジュールのサブスクリプションに関連付けられているサブスクリプションデータパケットを取得することと、
   前記サブスクリプションデータパケットから、サブスクリプションデータセットを抽出することであって、前記サブスクリプションデータセットは、サービスアプリケーションに関連付けられている前記通信ネットワーク内のアプリケーションキー管理ネットワークノードの識別子を備える、ことと、
   前記ユーザネットワークモジュールを前記通信ネットワークに登録するための認証プロセスの完了成功に応じて、ベース認証キーを取得することと、
   前記ベース認証キーに基づいて、前記アンカキーを生成することと、
   前記アンカキーに基づいて生成されたアプリケーション暗号化キーを介して、前記ユーザネットワークモジュールに関連付けられているユーザ機器と前記サービスアプリケーションとの間の暗号化された通信を可能にすることと
   を含む、方法。
2. 前記方法は、前記アンカキーのための一意の識別子を取得することをさらに含む、請求項１に記載の方法。
3. 前記ネットワークデバイスは、前記ユーザ機器を備える、請求項２に記載の方法。
4. 前記サブスクリプションデータセットは、前記アンカキー管理サービスに対する前記ユーザネットワークモジュールの前記サブスクリプションの間、前記ユーザ機器内に記憶される、請求項３に記載の方法。
5. 前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子および前記ユーザネットワークモジュールの識別子および前記ユーザネットワークモジュールのタイプおよび前記ユーザ機器を前記通信ネットワークに登録するための認証プロセスの間に生成された認証データセットのうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、請求項２に記載の方法。
6. 前記認証データセットは、前記ユーザネットワークモジュールを前記通信ネットワークに登録するための認証プロセスにおいて生成された乱数を備え、
   前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子および前記乱数のうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、請求項５に記載の方法。
7. 前記アンカキーのための一意の識別子を取得することは、前記乱数と、前記アプリケーションキー管理ネットワークノードの識別子とを備える前記アンカキーのための一意の識別子を生成することを含む、請求項６に記載の方法。
8. 前記ネットワークデバイスは、前記通信ネットワーク内の認証ネットワークノードを備える、請求項２に記載の方法。
9. 前記サブスクリプションデータパケットは、前記認証ネットワークノードと別個の前記通信ネットワークのユーザデータ管理ネットワークノードから取得され、
   前記ユーザデータ管理ネットワークノードは、ユーザサブスクリプション情報を記憶するように構成されている、請求項８に記載の方法。
10. 前記サブスクリプションデータセットは、前記サービスアプリケーションに関連付けられている前記通信ネットワーク内のアプリケーションキー管理ネットワークノードの識別子を備える、請求項９に記載の方法。
11. 前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子および前記ユーザネットワークモジュールの識別子および前記ユーザネットワークモジュールのタイプおよび前記ユーザ機器を前記通信ネットワークに登録するための認証プロセスの間に生成された認証データセットのうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、請求項１０に記載の方法。
12. 前記認証データセットは、前記ユーザデータ管理ネットワークノードによって生成される、請求項１１に記載の方法。
13. 前記認証データセットは、前記ユーザネットワークモジュールを前記通信ネットワークに登録するための認証プロセスにおいて、前記ユーザデータ管理ネットワークノードによって生成された乱数を備え、
    前記アンカキーを生成することは、前記ベース認証キーと、前記アプリケーションキー管理ネットワークノードの識別子および前記乱数のうちの少なくとも１つとに基づいて、前記アンカキーを生成することを含む、請求項１２に記載の方法。
14. 前記アンカキーのための一意の識別子は、前記乱数と、前記アプリケーションキー管理ネットワークノードの識別子とを備える、請求項１３に記載の方法。
15. 前記方法は、前記アンカキーおよび前記乱数を前記アプリケーションキー管理ネットワークノードに伝送することをさらに含み、
    前記アンカキーのための一意の識別子を取得することは、前記認証ネットワークノードからの前記乱数の受信に応じて、前記アプリケーションキー管理ネットワークノードによって生成された前記アンカキーのための一意の識別子を受信することを含む、請求項１３に記載の方法。
16. 前記アンカキーのための一意の識別子を取得することは、前記認証ネットワークノードによって、前記アンカキーのための一意の識別子を生成することを含む、請求項９に記載の方法。
17. 前記方法は、前記アンカキーおよび前記アンカキーのための一意の識別子をアプリケーションキー管理ネットワークノードに伝送することをさらに含む、請求項１６に記載の方法。
18. 前記アンカキーを生成することは、セキュアハッシュアルゴリズムを使用して、前記ベース認証キーおよび前記サブスクリプションデータセットを処理することにさらに基づく、請求項１に記載の方法。
19. １つ以上のプロセッサと１つ以上のメモリとを備えるデバイスであって、前記１つ以上のプロセッサは、前記１つ以上のメモリからコンピュータコードを読み取ることにより、請求項１に記載の方法を実装するように構成されている、デバイス。
20. コンピュータコードが記憶されている非一過性のコンピュータ読み取り可能なプログラム媒体であって、前記コンピュータコードは、１つ以上のプロセッサによって実行されると、請求項１に記載の方法を実装することを前記１つ以上のプロセッサに行わせる、非一過性のコンピュータ読み取り可能なプログラム媒体。

Images