JP7456444B2 - ネットワーク装置の方法 - Google Patents

Description

本開示は、一般に、規制遵守を満たすことができるような方法で通信ネットワークにおいて提供または実行されるサービスのための、鍵情報の交換および／または再利用に関する。

3GPP SA3は、3GPP加入者認証情報（3GPP subscriber credentials）（AKMA:アプリケーションの認証および鍵管理（Authentication and Key Management for Applications））に基づくアプリケーションの認証および鍵管理に関する研究を開始した。本研究のトピックは、一方の端のアプリケーションサーバまたはアプリケーション機能と他方の端のUE（ユーザ機器）またはUE上で動作するアプリケーションとの間で共有鍵を生成するために、アプリケーションが既存の鍵マテリアルと3GPPで定義された既存の認証メカニズムとをどのように利用することができるかである。このような鍵は、UE上のアプリケーションまたはUEをアプリケーションサーバまたは機能に対して認証するために使用することができ、逆もまた同様である。このような鍵の別の使用法は、例えば、情報交換を暗号化（encrypting）および／または保護（integrity protecting）することによって、アプリケーションサーバとUEとの間の情報交換を保護することである。

AKMAに関連して、TR33.835でこのサービスを可能にするアーキテクチャが導入された。このアーキテクチャでは、既存の5Gシステムに、AAuF（AKMA認証機能）およびAApF（AKMAアプリケーション機能）の２つのノードを追加した。「AAuFは、UEの認証、UEとAApFとの間で使用される鍵マテリアル（key material）の生成、および、後続のブートストラップ要求（bootstrapping requests）に使用されるUE AKMAコンテキストの維持を担当する。」AApFは、認証サービスを消費するオペレータドメイン内またはオペレータドメイン外の、アプリケーション機能である。これを行うために、AApFは、UEがサービスを要求するたびに、AAuFと対話（interact）して、AAuFから鍵マテリアルを要求する。

図１は、２つの可能なアーキテクチャ機能（architecture functions）を示す。１つは、AAuFがUDM（Unified Data Management）に接続されているアーキテクチャ機能であり、もう１つは、AAuFがAUSF（Authentication Server Function）に接続されているアーキテクチャ機能である。

多くの点で、このサービスは、TS33.220およびTS33.163でそれぞれ規定されている、サービスGBA（Generic Bootstrapping Architecture）およびBEST（Battery Efficient Security for very low Throughput Machine Type Communication (MTC) device）に似ている。BESTおよびGBAでは、UEがホームネットワーク（HN）のノードにサービスリクエストを送信し、次に、そのノードが、（たとえば、Evolved Packet CoreのHSS（Home Subscriber System）、UMTS（Universal Mobile Telecommunications System）およびGSM（Global System for Mobile Communications）のHLR（Home Location Register)）などの）加入者データベース（subscriber data base）から、認証ベクトル（Authentication Vector）を取得して、UEとの間で認証の実行を開始する。認証に成功すると、（GBAではBSF（Bootstrapping server function）と呼ばれ、BESTではHSE（HPLMN Security Endpoint）と呼ばれる）上記のホームネットワークのノードとUEとは、サービスを提供するネットワークなど、中間にいるいずれのパーティ（parties）にも知られていない、共有鍵（shared key）を確立する。続いて、この鍵またはその派生物は、アプリケーションサーバと共有され、その後、UEとアプリケーションサーバとは、互いを認証するため、または、セキュア通信をセットアップするために、この鍵を用いることができる。

3GPP TR 33.835 V 0.2.0（2018-11） 3GPP TS 33.220 V 15.4.0（2018-12） 3GPP TS 33.163 V 15.4.0（2018-09） 3GPP TR 33.863 V 14.2.0（2017-06） 3GPP TS 33.501 V 15.3.1（2018-12） 3GPP TS 22.368 V 13.1.0（2014-12）

上記のメカニズムには、いくつかの欠点がある。第１に、UEがネットワークに対して認証されたばかりであっても、サービスが呼び出されるたびに、新しい認証の実行が必要である。これは非常に非効率的である。第２に、サービスを提供するネットワークは、UEとアプリケーションサーバとの間で交換される情報を復号化（decrypt）する、規制上の義務（regulatory obligations）を有する可能性がある。サービスを提供するネットワークが基本的に鍵マテリアルにアクセスしないという事実を考えると、サービスがブロックされなければならないか、または、鍵マテリアルを入手するために他の手段が用意されなければならない。

この問題は、図２に示すように、5Gにおける新しい鍵階層（key hierarchy）を利用することによってのみ部分的に克服することができる。第１に、ネットワークとUEとの間の認証が成功した後に確立された5Gの既存の鍵に基づいて、サービスを構築することにより、新たな認証の必要性を克服することができる。例えば、ホームネットワークの鍵であるK_AUSFを、AKMAサービスのルート鍵（root key）として利用することができる。また、サービスを提供するネットワークの鍵であるK_SEAFまたはK_AMFを、AKMA関連サービス（AKMA related services）のルート鍵として利用することもできる。しかしながら、これは、UEとネットワークとの間の認証が完了した後にその鍵が格納された場合、および、AKMAサービスを実行するノードがその鍵を利用できるようになっている場合にのみ、可能である。第２に、AKMAサービスのルート鍵としてK_SEAFを用いることで、規制遵守（regulatory compliance）を解決できる。しかしながら、このような場合には、通信が危険にさらされることになる。さらに、規制要件（regulatory requirements）では、サービスを提供するネットワーク鍵がAKMA関連サービスに用いられる必要はない。したがって、K_SEAFに基づくK_AKMAを使用することは、必ずしも必要な解決策ではない。

したがって、解決すべき問題は次のとおりである。
－ この特定の鍵がネットワークまたはUEにおいてまだ使用可能であるかどうかに関係なく、また、レガシーSEAF（Security Anchor Functionality）および／またはAMF（Access and Mobility Management Function）および／またはAUSF（Authentication Server Function）の潜在的な存在を考慮して、UEとネットワークとがどの鍵を使用するかをどのように決定するか。

本開示のいくつかの例示的な実施形態は、複数の鍵が識別されることを必要とする。TR 33.863において、ソリューション6.1は、CKおよびIKから鍵セット識別子（key set identifier）を計算し、この鍵セット識別子をその複数の鍵へのポインタとして使用することによって、認証実行（authentication run）のCK（Cipher Key：暗号鍵）およびIK（Integrity Key：整合鍵）を識別する方法を提案する。しかしながら、このソリューションは、１回の認証実行で１つの鍵セットしか識別できないという欠点がある。5Gのコンテキストでは、K_SEAFもK_AUSFも識別しない。

本実施形態のほとんどでは、AKMAの動作がBESTやGBAと同様であることを前提としている。このことは、UEとアプリケーションサーバまたは機能（AKMA Application Function - AApFと呼ばれる）との間のセキュアな通信を設定する手順は、まず、（GBAでは、ブートストラップ（bootstrapping）と呼ばれる）設定フェーズ（setup phase）に入り、この設定フェーズでは、UEとネットワーク上の認証サーバ（AKMA認証機能（AKMA Authentication Function：AAuF）と呼ばれる）とが使用する鍵マテリアルについて合意する。第２のフェーズは、実際の使用フェーズ（actual usage phase）であり、この使用フェーズでは、UEとAApFとが決定された使用のために鍵マテリアルを用いる。

したがって、AKMAのための適切な鍵の使用、つまり、K_AUSFのようなホームネットワーク鍵に基づくか、または、K_SEAFのようなサービングネットワーク鍵に基づくかのいずれか、を考慮する必要がある。

AKMAアーキテクチャでは、１つのAKMA AFが別のAKMA AF向けのトラフィックを復号化できないようにするために、異なる複数のAKMAアプリケーション機能（AKMA Application Functions）についての鍵分離（key separation）をサポートする必要がある。複数のAKMA AFの間の鍵分離を可能とするために、AKMA AFカウンタ（AKMA AF Counter）またはランダム値（Random Value）のいずれかを使用することが導入される。

以下に、主題事項（subject matter）の実施形態のいくつかの態様の基本的な理解を提供するために、主題事項の簡略化された要約を示す。この要約は、主題事項の広範な概要（extensive overview）ではない。実施形態のキーの／重要な要素（key/critical elements）を特定することまたは主題事項の範囲（scope）を描写することは意図されていない。

その唯一の目的は、後に提示されるより詳細な説明の前置きとして、主題事項のいくつかの概念を簡略化した形で提示することである。

本開示の実施形態によれば、電子デバイスのための鍵再利用（key re-usage）を可能にする方法が開示され、この方法は、電子デバイスから要求メッセージ（request message）を受信することを含み、この要求メッセージは、第１のネットワークの第１のネットワークノードに関連付けられた第１の鍵または第２のネットワークの第２のネットワークノードに関連付けられた第２の鍵のうちの１つに対する優先度（preference）を示す第１の情報を含む。この方法は、前記第１の情報に示されている優先度を決定するために前記要求メッセージを処理することと、前記第１の鍵または前記第２の鍵を再利用するために前記電子デバイスに応答メッセージを送信することとをさらに含み、前記電子デバイスは、決定された優先度に示される前記第１の鍵または前記第２の鍵に基づいて第３の鍵を導出するように構成され、前記第２のネットワークは、前記第１の鍵および前記第２の鍵にアクセスでき、前記第１のネットワークは、前記第２の鍵にアクセスできない。

さらに、本開示の実施形態によれば、前記要求メッセージは、前記第１の鍵または前記第２の鍵のうちの少なくとも１つを保持する電子デバイスを示す第２の情報、前の通信セッションの間に確立された鍵のアイデンティティ（identity of a key）を示す第３の情報、または、ローカルポリシ（local policy）を示す第４の情報を含む。

さらに、本開示の別の実施形態では、方法は、UEの優先度（preferences）に基づく第１の鍵または第２の鍵を用いて認証パターン（authentication pattern）を設定することと、前記第１の情報に基づいて前記第１のネットワークまたは前記第２のネットワークによって選択された前記第１の鍵または前記第２の鍵のうちの１つを取得することとを含む。

本開示の実施形態では、ホームネットワーク以外のネットワークにおいて電子デバイスの鍵の再利用を可能にする方法が開示され、この方法は、前記ホームネットワーク以外の前記ネットワークにサービス要求（service request）を送信することと、前記サービス要求に対するサービス応答（service response）を受信することと、前記受信したサービス応答に基づいて認証を実行することとを含む。

本開示の実施形態において、前記方法は、前記ホームネットワーク以外の前記ネットワークに関して前記サービス要求に存在する鍵を検証することと、前記鍵の検証に失敗した場合にホームネットワークを検証することと、前記ホームネットワークとの検証に失敗した場合に認証要求（authorization request）を受信することとを含む。

本開示の実施形態では、前記方法は、前記受信されたサービス応答を検証することと、前記検証に基づいて適切な鍵を計算することと、前記計算された鍵に基づいて前記サービス応答を認証することとを含む。

本開示の実施形態では、前記サービス応答は、パラメータのセット、メッセージ認証コード（message authentication code）、または、鍵インジケータ（key indicator）のうちの少なくとも１つを含む。

本開示の実施形態では、ネットワークの電子デバイスのための鍵再利用を可能にする方法が開示され、この方法は、少なくとも１つのセッション要求メッセージ（session request message）を第１のネットワークノードに送信することを含み、前記少なくとも１つのセッション要求メッセージは、第２のネットワークノードに関連付けられた認証鍵（authentication key）に基づく鍵を使用する電子デバイスの優先度（electronic device’s preference）を示すフラグを含み、前記フラグは、少なくとも１つの鍵要求（key request）の形態で第３のネットワークノードに転送され、前記第３のネットワークノードは、前記少なくとも１つの鍵要求の検証が成功した場合に、前記第１のネットワークノードに少なくとも１つの応答メッセージ（response message）を送信する。前記方法は、前記第１のネットワークノードから、開始するセッションを示すメッセージを受信することをさらに含む。

本開示の実施形態では、前記第２のネットワークノードおよび第３のネットワークノードは、同じネットワークノードである。

本開示の実施形態では、前記少なくとも１つのセッション要求メッセージは、ID、フラグ、前記サーバの認証鍵、鍵セット識別子（key set identifier）、または、メッセージ認証コード（message authentication code）のうちの少なくとも１つを含む。

本開示の実施形態では、前記少なくとも１つの鍵要求メッセージは、ID、前記サーバの認証鍵、鍵セット識別子、または、メッセージ認証コードのうちの少なくとも１つを含む。

本開示の実施形態では、前記少なくとも１つの鍵応答メッセージは、前記サーバの認証鍵、チャレンジコード（challenge code）、または、検証済み応答メッセージ（verified response message）のうちの少なくとも１つを含む。

本開示の実施形態では、チャレンジコードまたは認証鍵特定カウンタ（authentication key specific counter）のいずれかが、複数の前記認証サーバの場合の鍵分離（key separation）のために用いられる。

本開示の実施形態において、電子デバイスと通信するためのネットワークノードは、コントローラと、前記コントローラに動作可能に結合されたメモリとを含み、前記コントローラは、前記電子デバイスから要求メッセージを受信し、パラメータ群のセットに基づく認証を実装するための結果を得るために前記要求メッセージを処理し、その結果を、認証鍵のセットを導出するために電子デバイスに送信する。

本開示の実施形態では、ネットワークとの鍵を再利用するための電子デバイスは、コントローラと、前記コントローラに動作可能に結合されたメモリとを含み、前記コントローラは、サービス要求を前記ネットワークに送信し、前記サービス要求に関するサービス応答を受信し、前記受信したサービス応答に基づいて認証を実行する。

本開示のこれらおよび他の目的、実施形態および利点は、添付図面を参照する実施形態の以下の詳細な説明から当業者には容易に明らかになるであろうが、本開示は開示された特定の実施形態に限定されない。

本主題の上記および更なる目的、特徴および利点は、添付の図面を参照した例示的な実施形態の以下の説明から明らかになるであろう。ここで、類似する要素を表すために類似の番号が用いられている。
しかしながら、参照番号を付した添付図面は、本主題の典型的な実施形態のみを示すものであり、したがって、本主題が他の同等に有効な実施形態を許容し得るため、その範囲を限定するために考慮されないことに留意されたい。
図１は、AAuFがUDMまたはAUSFに接続されるアーキテクチャを示す。 図２は、本開示の実施形態による5G技術における鍵階層を示す。 図３は、本開示によるホームネットワークにおいてのみAAuFを有するアーキテクチャを示す。 図４は、本開示による5Gコアネットワークアーキテクチャのサービスベースの表現を示す。 図５は、本開示によるUEとH-AAuFとの間のメッセージ交換を示す。 図６は、本開示による、AUSFからの鍵取得のための手順を示す図である。 図７は、本開示によるホームネットワーク鍵に基づくK_AKMAを使用するための鍵階層を示す。 図８は、本開示による、K_SEAFおよびH-AAuFからのK_AKMAを使用する場合の鍵階層を示す。 図９は、本開示による新規の認証を使用する場合の鍵階層を示す。 図１０は、本開示によるホームネットワークおよび訪問先ネットワーク（visited network）の両方におけるAAuFを有するアーキテクチャオプションを示す。 図１１は、本開示によるUEとV-AAuFとの間のメッセージ交換を示す。 図１２は、本開示によるAUSFからの鍵検索のプロセスを示す。 図１３は、本開示によるサービングネットワーク鍵に基づくK_AKMAを使用するための鍵階層を示す。 図１４は、本開示によるK_SEAFが存在しない鍵階層を示す。 図１５は、本開示による、K_SEAFおよびH-AAuFからのK_AKMAを使用する場合の鍵階層を示す。 図１６は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図１７は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図１８は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図１９は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図２０は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図２１は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図２２は、本開示による、BEST技術についてのEMSDPセッション設定手順を示す図である。 図２３は、本開示による、SEAFまたはAUSFによるAF鍵の計算を示す。 図２４は、本開示による、ユーザ装置（UE）のブロック図を示す。 図２５は、本開示による、（R）ANノードのブロック図を示す。 図２６は、本開示による、コアネットワークノードのブロック図を示す。

以下、図面を参照して実施の形態を説明する。しかしながら、本開示は、多くの異なる形態で実施されてもよく、ここに記載された実施形態に限定されるものと解釈されるべきではない。むしろ、これらの実施形態は、本開示が完全かつ完成しており、その範囲を当業者に十分に伝えるように提供される。添付の図面に示される特定の例示的な実施形態の詳細な説明において使用される用語は、限定を意図するものではない。図面において、同じ番号は、同じ要素を指す。

しかしながら、特許請求の範囲における参照符号は、本主題の典型的な実施形態のみを示しており、したがって、本主題が他の同等に有効な実施形態を許容し得るため、その範囲を限定するために考慮されるべきではないことに留意されたい。

本明細書は、いくつかの場所で「１つの（an）」、「１つの（one）」または「いくつかの（some）」実施形態（s）を参照することができる。これは必ずしも、そのような参照の各々が同一の実施形態（s）に対するものであること、又は、その特徴が単一の実施形態にのみ適用されること、を意味するものではない。異なる実施形態の単一の特徴を組み合わせて、他の実施形態を提供することもできる。

本明細書で使用される場合、単数形「a」、「an」および「the」は、特に明記しない限り、複数形も含むことが意図される。本明細書で使用される場合、用語「含む（includes）」、「含む（comprises）」、「含む（including）」、および／または「含む（comprising）」は、記載された特徴（features）、整数（integers）、ステップ（steps）、操作（operations）、要素（elements）、および／または構成要素（components）の存在を明記するが、１つ以上の他の特徴、整数、ステップ、操作、要素、構成要素、および／またはそれらのグループの存在または追加を排除しないことがさらに理解される。要素が別の要素に「接続されている（connected）」または「結合されている（coupled）」と称される場合、それは、他の要素に直接接続または結合されてもよく、または介在要素が存在してもよいことが理解されよう。さらに、本明細書で使用される「接続された（connected）」または「結合された（coupled）」は、動作可能に接続されたまたは結合されたことを含み得る。本明細書中で使用される場合、用語「および／または」は、１つまたは複数の関連するリストされた項目の任意のおよび全ての組み合わせおよび配列を含む。

別段の定義がない限り、本明細書で使用される全ての用語(技術用語、科学用語を含む)は、本開示が関係する当業者によって一般に理解されるものと同じ意味を有する。さらに、慣用的に使用されている辞書で定義されているような用語は、関連技術の文脈におけるそれらの意味と一致する意味を有すると解釈されるべきであり、本明細書で明示的に定義されていない限り、理想化された意味または過度に形式的な意味で解釈されないことが理解されるであろう。

図では、一部の要素と機能エンティティのみを示す簡略化された構造が示される。これらはすべて、示されているものとは実装が異なる可能性がある論理ユニットである。表示されている接続は論理接続であり、実際の物理接続は異なる場合がある。構造が他の機能および構造も含み得ることは、当業者には明らかである。

また、図面に記載および図示されたすべての論理ユニットは、ユニットが機能するために必要なソフトウェアおよび／またはハードウェアのコンポーネントを含む。さらに、各ユニットは、それ自体の中に、暗黙的に理解される１つ以上の構成要素を含んでもよい。これらの構成要素は、互いに動作可能に結合され、上記のユニットの機能を実行するために互いに通信するように構成されてもよい。

5Gシステムアーキテクチャでは、認証サーバ機能（AUSF：authentication server function）、認証クレデンシャルリポジトリおよび処理機能（ARPF：authentication Credential Repository and processing function）、アクセスおよびモビリティ管理機能（AMF：Access and Mobility Management Function）、セッション管理機能（SMF：Session Management Function）、ポリシー制御機能（PCF：Policy Control Function）、アプリケーション機能（AF：Application Function）、統合データ管理（UDM：Integrated Data Management）、データネットワーク（DN：Data Network）、ユーザプレーン機能（UPF：User Plane Functions）、無線アクセスネットワーク（RAN：Radio Access Network）、ユーザ機器（UE：User Equipment）など、さまざまな構成要素（configurations of elements）、つまり、ネットワーク機能（NF：network function ）が含まれてもよい。

さらに、本開示で使用されるプロトコルは、RRC（Radio Resource Control：無線リソース制御）プロトコル、N2シグナリングプロトコル、NAS（Non-Access Stratum：非アクセス層）プロトコル、または、アクセス端末とセキュリティアンカー機能（SEAF：Security Anchor Function）エンティティとの間のシグナリングプロトコルのうちの少なくとも１つを含み得る。ネットワークノードは、SEAFエンティティ、認証管理フィールド（AMF： Authentication Management Field）エンティティ、または、認証サーバ機能（AUSF：Authentication Server Function）エンティティの少なくとも１つである。ネットワークは、5Gコアネットワーク（5GC）、NG Radio Access Network（NG-RAN）、Evolved Packet Core（EPC）、Long Term Evolution（LTE）システム、または、次世代ネットワークシステムのうちの少なくとも１つである。さらに、ホーム加入者サーバ（HSS：home subscriber server ）は、ユーザ機器（UE）を使用するユーザのプレセキュリティ要件（pre security requirements）を記憶する。ユーザ識別子に応じた、ホームサブスクライバサーバは、UEの予め設定されたセキュリティ要件を決定する。

＜第１実施形態＞
図３は、AAuFがホームネットワークに存在するアーキテクチャを示す。このアーキテクチャは、訪問先ネットワークにAAuFが配置されていない場合、または、ホームネットワークにあるAAuFに接続するようにUEが設定（構成）されている場合に適用される。

図３のアーキテクチャは、一般的な5Gのアーキテクチャを簡略化して示したものである。（SNで示される）サービングネットワークには、ネットワーク機能であるAMFおよびSEAFが示されている。UEは、サービングネットワークに接続されており、このことは、UEとAMFとの間の線によって示されている。この線は、UEがAMFと持つNASコネクション（NAS connection）およびNASセキュリティコンテキスト（NAS security context）を表す。このアーキテクチャでは、SEAFはAMFと一緒に配置されるものとして示されているが、将来、同じ機能をスタンドアロンにすることもできる。図中の線は、各素子が有線、無線、光等の通信手段を介して接続されていることを示している。その接続は、例えばUEとAMFとの間の線など、論理的であり得る。

AMF／SEAFは、AUSFと通信可能に接続されている。この線は、例えばUEがサービングネットワークに接続するときにUEを認証するために、AMF／SEAFがAUSFから鍵マテリアルを取得できることを示している。AUSFはホームネットワークに存在しているが、将来的には、AUSF機能の一部がサービングネットワークまたは訪問先ネットワークに存在する可能性もある。UEを認証する必要があるときにUDMから認証データを取得する（fetch）ために、AUSFは、UDMに接続される。

図３において、UEは、（インターフェースa1として示される）図１でも示されるように、（H-AAuFで示される）ホームネットワークのAAuFに接続されている。簡単にするために、H-AAuFは、AUSFおよびUDMと通信可能に接続されていることが示されている。図１から、H-AAuFは要素の１つだけに接続されてもよい、ことが明らかになる。一部の実施形態は、エラー状態から回復するために、UDMおよびAUSFへの接続の両方を必要とする場合がある。H-AAuFをUDMおよびAUSFの両方に接続する利点は、例えばAUSFが鍵を紛失したために又は最初から鍵を保存していなかったために、AUSFがH-AAuFに鍵を配信できない場合に、新しい鍵マテリアルを生成するために、H-AAuFがUDMから認証ベクトルを取得し且つUEを認証できる、ことである。このようなセットアップは、AAuFが、AUSFにおけるエラーから回復することを可能にするだけでなく、UEが5Gネットワークに接続されておらず、4G、3G、またはその他のタイプのアクセスネットワークから接続されている場合にも用いられることを可能にする。

図４は、図３にも示されているコアネットワークの別のアーキテクチャ表現を示している。この表現は、サービスベースであり、5Gのアーキテクチャオプションのなかの１つである。サービスベースアーキテクチャでは、さまざまなネットワーク要素が、サービスバス上でサービスを提供する。通常、これらのサービスは、何らかのHTTPフロントエンドを通じて提供され、サービス利用者は、HTTPリクエストをこのフロントエンドに送信する。したがって、AUSFまたはUDMに接続されているとされるH-AAuFは、AUSFおよびUDMの両方へのインターフェイスコールをサポートするとも言える。AUSFにのみ接続されているとされるH-AAuFは、AUSFへのインターフェイスコールのみをサポートするとも言える。図４から、サービス間のメッセージ交換は、当該技術分野で公知のHTTP要求／応答ペア（HTTP Request ／ Response pairs）またはパブリッシュ／サブスクライブメカニズム（Publish ／ Subscribe mechanisms）と見なすこともできると結論付けることができる。

このようなサービスベースのアーキテクチャの利点は、サービスをシステムに簡単に追加したり、システムから削除したりできることである。例えば、ネットワークオペレータがAAuFがAUSFから鍵を取得できるようにしたい場合、オペレータは、AAuFが呼び出すことができるサービスベースのインターフェイスを公開する、新しいサービス（例えば、鍵保存サービス（Key Repository Service））を立ち上げるであろう。AAuFがサービスを呼び出すと、Key Repository Serviceは、適切な鍵マテリアルで応答する。このサービスを実行する論理的な場所は、AUSFであるが、このサービスは、スタンドアロン機能であってもよいし、ネットワークにおける他のネットワーク機能と統合されていてもよい。同様のKey Repository Serviceは、SEAFなどの異なるネットワーク要素から取得された鍵について実行されてもよい。さらに、このKey Repository Serviceは、AUSFまたはSEAFから提供されるが、Key Repositoryのスタンドアロンサービスの使用を排除するものではない。

図5は、UEとH-AAuFとの間の例示的なメッセージ交換を示す。この図では、UEがネットワークに接続されており、サービングネットワークとUEとの間で認証と鍵の合意（key agreement）とが行われていると仮定している。TS 33.501で規定されているように、この認証および鍵合意が5Gネットワーク上で行われている場合、サービングネットワークは、K_SEAF、K_AMF、および、階層の下位の鍵（keys lower in the hierarchy）を取得しており、ホームネットワークは、CK、IK、およびK_AUSFを計算している。認証がLTE、UMTS、GSMなどの他のネットワークで行われた場合、鍵階層は、異なり、そのようなネットワークの異なるノードによって異なる鍵が取得されるであろう。明確にするために、認証は、5Gネットワークで行われたと考えられる。

ステップ１で、UEは、H-AAuFにサービスを要求するメッセージを送信する。サービス要求メッセージは、UEの識別子と、UEがホームネットワーク鍵又はサービングネットワーク鍵のどちらを使用したいかを示すフラグと、鍵セット識別子（KSI：key set identifier）と、オプションとしてネットワークへの以前の認証で得られた複数の鍵の１つ（例えば、5Gの場合のK_AUSF又はK_SEAF）を用いて計算されるMACとを含む。

サービス要求メッセージ内のUE識別子は、パーマネント識別子であるSUPI（SUbscription Permanent Identifier）またはIMSI（International Mobile Subscriber Identity）、一時識別子である5G-GUTI（5G Globally Unique Temporary Identity）、または、TS 33.501で定義されるSUCI（Subscription Concealed Identifier）のような識別子の暗号化バージョン（encrypted version of the identifier）であり得る。H-AAuFが、その識別子を加入者に関連付け、そのサービスの適切な識別子を回復できる限り、その識別子は、MSISDN（Mobile Subscriber Integrated Services Digital Network Number)、SIP（Session Initiation Protocol）アドレス、電子メールアドレスなどであってもよい。

UEが含めた上記フラグは、バイナリビットであってもよく、例えば、「1」は、UEがホームネットワーク鍵を使用したいことを示し、「0」は、UEがホームネットワーク鍵を使用したくないことを示す。また、このフラグは、それぞれUEがホームネットワーク鍵またはサービングネットワーク鍵を使用したいことを示す、「Home」および「Visited」または「AUSF」および「SEAF」という語を示す、テキストフィールドであってもよい。また、このフラグは、暗示的であってもよく、UEがV-AAuFではなくH-AAuFにコンタクトしている事実から推定されてもよい。また、そのフラグは、UEが呼び出すサービスのサービス名において示されてもよいし、このフラグは、サービスの様々なオプションを示し且つ同じメッセージで送られる、複数のフラグの集合の一部であってもよい。さらに別の代替案として、そのフラグは、例えば「SEAF／AUSF」をフラグとして提供するか、「ALL」を提供するか、または、これらの値のバイナリ表現を提供することによって、UEにてサポートされる複数の鍵の組み合わせであってもよい。

KSIは、5Gの鍵階層における複数の鍵のうちの１つを指す、鍵セット識別子である。例えば、その鍵セット識別子は、K_AUSF、K_SEAF、K_AMFなどを指す。重要なのは、UEと関係するネットワーク要素とが、同じ複数の鍵を参照するために、同じ鍵セット識別子を使用することである。このような共通参照を確立する１つの方法は、各要素からUEに鍵識別子を送信することである。例えば、AUSFは、AMFが鍵セット識別子を送信する方法と同様に、認証後にUEにKSIを送信できる。もう１つの方法は、入力として、KSIおよびその他の値を計算することである。このアプローチは、新しいメッセージが不要であり、また、鍵が確立された後の任意の時点でKSIを計算できる、という利点を有している。KSIは以下のように計算されると仮定する。
KSI＝KDF（Input Key, Free text field）
ここで、Input Key（入力鍵）は、参照したい鍵に設定されてもよく、Free text field（フリーテキストフィールド）は、KSIがAKMAに固有のものである場合には「AKMA」のようにすることができ、KSIがより広い5Gコンテキスト（wider 5G context）において使用される場合には「5G」のようにすることができる。テキストフィールドの他の値も可能であり、鍵の反復（key repetition）および鍵の分離（key separation）を回避するために、追加のフィールドが追加されてもよい。KDFは、（暗号）ハッシュ関数（（cryptographic） hash function）である、鍵導出関数（key derivation function）である。暗号ハッシュ関数は、攻撃者がKSIを取得した場合に、元のコンテンツとそれゆえKSIの計算に用いられる複数の鍵とを取得することが困難になることを回避するために、使用される。

したがって、UEがAKMAサービスについてK_AUSFに基づく鍵を使用したいことを示す場合、UEは、K_AUSFを参照するKSIを、計算するかまたはストレージから取得する。UEがK_SEAFに基づく鍵を使用したいことを示したい場合、UEは、K_SEAFについてKSIを使用する。図では、これは、KSI_SEAFと表示されている。

そのメッセージに含まれるMACは、メッセージ認証コード（message authentication code）である。このようなコードは、受信側がUEのアイデンティティが本物であることを確認できるようにするために、必要である。MACは、次のように計算できる。
MAC＝KDF（Input Key, message, counter）
これは、TS 33.501のSteering of Roamingで規定されている手順に似ている。TS 33.501のメカニズムでは、K_AUSFが常に入力鍵として使用されており、これは、AUSFのみがMACの正確さ（correctness）を検証できる、ことを意味する。我々のケースでは、メッセージが送信される場所（ホームネットワークまたは訪問先ネットワーク）、どの鍵が存在すると想定されているか、および、どの鍵が要求されるかによって、入力鍵は、K_AUSF、K_SEAF、さらにはK_AMFの間で変化する、可能性がある。しかしながら、本実施形態では、UEは、AUSFからの鍵マテリアルを要求するH-AAuFにメッセージを送信するため、K_AUSFを使用する。このため、AUSFがそのメッセージを検証することができる。上記のカウンタは、AAuFまたはAUSFに、および、UEに保持される。

図５のステップ２では、H-AAuFがそのメッセージを受信する。AAuFは、そのメッセージを受信すると、図６に示すように鍵を要求するメッセージを、AUSFに送信する。AUSFは、最初に、鍵（本実施形態ではK_AUSF）を探すことを試み、次にMACを確認してから、適切な鍵で並びにオプションでチャレンジ（challenge）及び応答（response）で、応答する。UEがAUSFの信頼性（authenticity）を確認できるように、AUSFからの応答は、MACを含んでいてもよい。

AUSFでのUEメッセージの確認は、次のように動作する。まず、AUSFは、UE ID（例えば、SUPI）を取得し、メモリからK_AUSFを取得する。AUSFは、KSIを用いて、正しい鍵を取得したことを確認する。次に、AUSFは、上記のMACの計算を用いてMACを確認し、一致した場合、AUSFは、UEを識別し、続けることができる。ここでは、AUSFは、K_AKMAを取得（derive）して、AAuFに転送する。オプションで、UEがAAuFによって認証されることを可能にするために、上記のメッセージは、RAND、RES、およびMACを含んでいてもよい。

代替として、AUSFは、UEメッセージからKSIを取り出し、KSIを用いてK_AUSFを検索することも可能である。後者は、メッセージにUE IDを含める必要がなく、認証実行ごとに変化するKSIのみを一時UE識別子（temporary UE identifier）として用いることができるため、有利である。KSIを使用するもう１つの利点は、（もしそれが両方によって計算されるなら）UEおよびAUSFだけがKSIを認識しており、したがってAUSFに対する認証トークンとして機能できることであり、このことは、メッセージからMACを除外できる可能性がある、ことを意味する。欠点は、UEが再認証されるまでKSIが変わらない、ことである。

後者を避ける方法の１つは、KSIにカウンタを含めることである。この場合、UEを識別するためにKSIが成功裏に用いられて新しいKSIが計算される度に、そのカウンタは増やされ得る。このことは、UE側およびAUSF側の両方にカウンタを格納すること、並びに、新しい認証の実行が必要になる度にカウンタをゼロに戻すこと、を必要とする。考えられる欠点は、複数のUEの複数のKSIが衝突する可能性があることである。この可能性は、図５のサービス要求メッセージ（service request message）にカウント値を含めること、及び、図６の鍵要求メッセージ（key request message）においてこのカウンタを転送することによって、さらに低くされ得る。カウンタとKSIとの組み合わせも一意でない場合、AUSFは、エラーを送り返す必要があり、UEとAAuFとの間の完全な認証が必要となるであろう。

前の段落の前提条件は、AUSFとUEとが、認証完了後にK_AUSFを保存する、ことである。また、AUSFがUE ID若しくはKSIまたはその両方とともにK_AUSFを格納する、ことが必要とされる。また、AUSFは、UE認証の完了後に、KSIを計算する必要がある。

別の方法として、UEメッセージは、KSIを省略できる。この場合、AUSFは、鍵が正しいかどうかを確認できない。AUSFは、メッセージのMACだけを確認できる。この方法の利点は、追加のストレージが不要であることと、UE側でKSIの計算が不要であることである。さらに別の方法として、UE IDだけをメッセージに含めることもできる。このような場合、AUSFは、UEを認証するために、RAND、RES、およびMACで応答し、認証の成功後にのみAAuFに鍵を提供する。認証が必要なのは、AUSFがKSIまたはMACなしでUEのアイデンティティを確認できないため、鍵を間違った相手（wrong party）に渡す可能性があるためである。

AUSFがAAuFに渡す鍵は、K_AUSFまたはその派生鍵のいずれかである。K_AUSFを引き渡すことは、鍵階層全体がK_AUSFに従うということ、および、それ故AAuFがすべてのセキュアな通信へのアクセスを得ること、という欠点を有している。K_AUSFの派生物を引き渡すことは、さらに鍵導出を行わなければならないこと、および、この鍵導出を行うことができるようにAUSFをアップグレードしなければならないこと、を意味する。この実施形態において、我々は、両方のオプションが可能であると仮定する。AKMA鍵を導出する１つの方法は、次のとおりである。
K_AKMA＝KDF（K_AUSF, “AKMA”, RAND）
ここで、K_AUSFは、鍵導出関数への入力である鍵であり、文字列「AKMA」は、静的文字列（static string）であり、RANDは、AUSFから送信されたものである。RANDの代わりに、カウンタを使用してもよい。鍵が導出されない場合、次のようになる。
K_AKMA＝K_AUSF

AUSFがUEのアイデンティティを確認してその鍵を送信した後、H-AAuFは、UEに次のメッセージを送信する（図５のステップ３）。すべてが上手くいった場合、つまり、鍵が発見されてK_AKMAが導出された場合、このメッセージは、H-AAuFがK_AKMAを取得したことおよびそれがどの鍵から導出されたかという、UEについての確認（confirmation for the UE）を運ぶ。さらに、そのメッセージは、RESなどの、UEを認証するための情報を含んでいてもよく、また、そのメッセージは、MACなどの、UEが鍵の正しさ（correctness）を検証できるようにする情報（material）を含んでいてもよい。そのMACは、UEがAAuFとUEとが同じ鍵を持っていることを確認できるように、新しい鍵を用いて計算される。例えば、KDFに基づく別のMACが用いられ得る。
MAC＝KDF（K_AKMA, MSG）

あるいは、MACは、AUSFから含められてもよく、この結果、UEはメッセージがAUSFから送信されたことを認識し、AAuFになりすまそうとする攻撃者は居なくなる。このようなMACは、RANDとK_AUSFと他の値とで計算され得る。
MAC＝KDF（K_AUSF, RAND, Values）

また、両方のMACが、そのメッセージに含められてもよい。

あるいは、複数のシグナリング鍵は、K_AKMAから導出されてもよく、このK_AKMAは、UEとAAuFとの間のシグナリングについての暗号化（encryption）および／または完全性保護（integrity protection）のいずれかのために、使用され得る。

UEが図５のステップ４でそのメッセージを受信すると、同じ方法で同じ複数の鍵を導出し、メッセージの完全性を検証し（複数のMACが含まれている場合、メッセージ内のすべてのMACを検証し)、必要に応じて、認証チャレンジ（authentication challenge）に応答する。これで、UEとH-AauFとは、同じルート鍵に基づいて同じK_AKMAを共有する。

場合によっては、AUSFは、要求された鍵を、持っていなかったり、または、提供できなかったりすることがある。これらが図６のエラーケースである。この問題を解決するには、次の２つのオプションがある。
－ AUSFは、認証要求メッセージをUDMに送信し、TS 33.501で規定されているように認証を開始する。これには、AUSFとUEとの間のメッセージのラウンドトリップが含まれ、UEが認証されると、AAuFとの間で鍵が共有され得る。
－ AUSFは、AAuFにエラーを通知する。AAuFは、このエラーに応答して、UDMに認証要求メッセージを送信し、認証ベクトルを取得した後、UEとの認証を実行する。認証が完了すると、UEとAAuFとは、AKMAサービスに使用できる鍵を共有する。

例１:
上記の複数の図を参照すると、上記の複数のステップは、以下の通りである。図５の第１ステップでは、UEは、H-AAuFへ、「AUSF」にフラグを設定したサービス要求を送信する。UEは、そのメッセージに、そのSUPI、KSI_AUSF、および、MACも含める。第２ステップでは、H-AAuFは、そのメッセージを受信する。AAuFは、UEがローミングしているか否かをチェックし、ローミングパートナーがホームネットワーク鍵の使用を許可しているか否かをチェックし、UEがそのサービスの使用を許可されているか否かをチェックする。サービスが許可されていない場合、AAuFは、ここでストップする。UEがローミングしておらず且つホームネットワーク鍵が許可されている場合、または、UEがローミングしていて且つホームネットワーク鍵が許可されている場合、H-AAuFは、次に進み、メッセージをAUSFに送信する。AUSFは、K_AUSFを取得し、KSIをチェックし、そのメッセージのMACを検証し、すべて問題がなければ、K_AUSFおよび新しいランダム値RANDからK_AKMAを計算する。AUSFは、確認メッセージ（confirmation message）で、K_AKMAおよびRANDをH-AAuFに転送する。H-AAuFは、鍵がK_AUSFから導出されたことを示す応答メッセージを生成し、RANDを追加し、新たに取得した鍵またはそのシグナリング派生物（a signalling derivative thereof）を用いて応答メッセージに署名し、それをUEに送信する。UEは、RANDおよびK_AUSFを用いてK_AKMAを計算し、そのメッセージを検証し、鍵が正常に導出されたことを示す確認メッセージを送信する。UEは、H-AAuFと同じ鍵で確認メッセージを保護する。

例２:
上記の複数の図を参照すると、上記の複数のステップは以下の通りである。図５の第１ステップでは、UEは、フラグを「SEAF」に設定したサービス要求を、H-AAuFに送信する。UEは、SUPI、KSI_SEAF、およびMACも、そのメッセージに含める。第２ステップでは、H-AAuFが、そのメッセージを受信する。AAuFは、UEがローミングしているかどうかをチェックし、ローミングパートナーがホームネットワーク鍵の使用を許可しているかどうか、ホームネットワークがAKMAについてK_SEAFの使用を許可しているかどうかをチェックし、UEがサービスの使用を許可されているかどうかをチェックする。サービスが許可されていない場合、AAuFは、ここでストップする。UEがローミング中でなく且つK_SEAFがホームネットワークで許可されている場合、または、UEがローミング中で且つK_SEAFが許可されている場合、H-AAuFは、処理を進め、そのメッセージをAUSFに送信する。AUSFは、K_AUSFを取得し、KSIをチェックし、そのメッセージのMACを検証し、すべてが正常である場合、まずK_AUSFからK_SEAFを計算し、次にK_SEAFおよび新しいランダム値RANDからK_AKMAを計算する。AUSFは、確認メッセージでK_AKMAおよびRANDをH-AAuFに転送する。H-AAuFは、鍵がK_SEAFから導出されたことを示す応答メッセージを生成し、RANDを付加し、新たに取得した鍵またはそのシグナリング派生物を用いて応答メッセージに署名し、それをUEに送信する。UEは、RANDおよびK_SEAFを用いてK_AKMAを計算し、そのメッセージを検証し、鍵が正常に導出されたことを示す確認メッセージを送信する。UEは、H-AAuFと同じ鍵で確認メッセージを保護する。

例３:
上記の複数の図を参照すると、上記の複数のステップは以下の通りである。図５の第１ステップでは、UEは、フラグを「AUSF」に設定したサービス要求を、H-AAuFに送信する。UEは、SUPI、KSI_AUSF、およびMACも、そのメッセージに含める。第２ステップでは、H-AAuFが、そのメッセージを受信する。AAuFは、UEがローミングをしているかどうかをチェックし、ローミングパートナーがホームネットワーク鍵の使用を許可しているかどうかをチェックし、ホームネットワークがAKMAについてK_SEAFの使用を許可しているかどうかをチェックし、UEがサービスの使用を許可されているかどうかをチェックする。この例では、UEはローミング中であり、ローミングパートナーは、K_AKMAについてのルートとしてK_AUSFの使用を許可していない。H-AAuFは、処理を進め、ローミングパートナーがK_AUSFの使用を許可していないインジケータを含むメッセージを、AUSFに送信する。AUSFは、K_AUSFを取得し、KSIをチェックし、そのメッセージのMACを検証し、すべて正常であれば、まずK_AUSFからK_SEAFを計算し、次にK_SEAFおよび新しいランダム値RANDからK_AKMAを計算する。AUSFは、確認メッセージでK_AKMAおよびRANDをH-AAuFに転送する。H-AAuFは、鍵がK_SEAFから導出されたことを示す応答メッセージを生成し、RANDを付加し、新たに取得した鍵またはそのシグナリング派生物を用いて応答メッセージに署名し、それをUEに送信する。UEは、RANDおよびK_SEAFを用いてK_AKMAを計算し、そのメッセージを検証し、鍵が正常に導出されたことを示す確認メッセージを送信する。UEは、H-AAuFと同じ鍵で確認メッセージを保護する。

鍵階層オプション（Key Hierarchy Options）
図7は、UEがK_AUSFに基づいて鍵を要求し且つそのような鍵の使用を許可される場合（例１）の鍵階層の例を示す。鍵階層の複数の鍵は次のとおりである。
－ K : UEとネットワークとの間で共有される秘密鍵である。この鍵は、モバイルデバイスとネットワーク側の加入者データベースとに格納される。5Gの場合、この鍵は、UE側のUSIMとネットワーク側のARPF（Authentication credential Repository and Processing Function）とに格納される。4G、3G、2Gでは、ネットワーク側のストレージは、AuCと呼ばれ、それぞれHSS／HLRの一部である。
－ CK、IK : 認証後に、USIMとネットワークノードとによって導出される複数の鍵のセットである。5Gでは、これらの鍵は、ARPF内で導出され、UDMに送信される。4Gでは、HSS内のこれらの鍵、3Gでは、これらの鍵は、UEとネットワークとの間のユーザおよびシグナリングプレーン上のデータの整合性（integrity）および機密保護（confidentiality protection）に使用される鍵である。こららの鍵は、UMTS鍵としても知られている。4Gおよび5Gでは、これらの鍵は、一時的なものであり、つまり、後で使用するために保存されず、使用後にメモリから削除される。
－ CK’とIK’ : EAP AKA’が用いられる場合、これらの中間鍵は、CKおよびIKからも導出される。5Gでは、これらの鍵は、K_AUSFを導出するために用いられる。2G、3G、4Gには、K_AUSFに相当するものはない。4Gと5Gでは、これらの鍵は、一時的なものである。
－ K_AUSF : この鍵は、CKおよびIKから、または、CK’およびIK’から導出され、AUSFに存在する。5Gセキュリティアーキテクチャでは、AUSFは、後続の鍵K_SEAFを導出し、このK_SEAFは、サービスネットワークに送信される。この鍵階層では、この鍵と（Kを除く）上記の鍵は、UEとネットワークとにおける認証および鍵アグリーメントが正常に実行された結果である。
－ HN鍵（HN Key） : この鍵は、既存の鍵階層の一部ではない。この文書では、H-AAuFが使用するために、AUSFによってK_AUSFから導出される鍵である。HN鍵は、H-AAuFに存在する。以前のテキストと比較すると、HN鍵についての記述は無かった。その鍵階層にそれを導入する理由は、システムの柔軟性を高めるためである。例えば、この鍵を使用する１つの方法は、AUSFが認証の直後にその鍵をAAuFにプッシュすることである。これにより、AUSFはK_AUSFを維持する必要がなくなり、設計が容易になる。別の有利なアプローチは、サービスが最初に使用されたときにAAuFがこの鍵を取得し、それから、AAuFがその鍵を失ったとき、または、UEがそのサービスを終了したいことを通知したときにのみ、新しい鍵を取得する、ことである。いずれの場合でも、それが使用される場合、K_AKMAは、HN鍵から導出され得る。
－ K_AKMAは、AKMAサービスについて使用される鍵である。この鍵は、K_AUSFから直接導出されることも、新しく導入されたHN鍵から導出されることも可能である。K_AKMAは、AKMAについてのルート鍵としても機能し得る。その場合、AAuFとUEとの間のAKMAについてのシグナリングを保護するために、１つ以上の個別の制御鍵が導出され、データ転送用に、アプリケーション固有の鍵が導出される。

UEがK_AKMAの基礎（basis）としてK_AUSFの使用を指示している場合、鍵階層および鍵導出は、図７のとおりである。

場合によっては、AUSFが鍵を紛失している可能性がある。このような場合でも、（従来技術で説明されているようにAAuFを通過させて）UEとAUSFとの間で認証を実行することにより、図７の鍵階層を得ることができる。この場合、そのAKMAサービスに対してだけ、鍵階層内の（オプションでCK’とIK’をスキップする）すべての鍵が確立される。

図８は、H-AAuFが存在する場合（例２および例３）に、K_AKMAがK_SEAFから導出されるケースの鍵階層を示す。この鍵階層の鍵は、次の点を除いて同じである。
－ K_SEAF ： この鍵は、5G認証の実行結果であり、AUSFによってサービングネットワークのSEAFに送信される。この鍵は、AUSFによってK_AUSFから導出される。
－ HN Key ： 図7とは異なり、この鍵はK_SEAFから導出されるか、又は、新しい派生物（derivation）が必要ない場合にはK_SEAFと同じである。
－ K_AKMA ： この鍵は、HN KeyまたはK_SEAFから導出される。

鍵階層にK_SEAFが存在することは、HN鍵またはK_AKMAが、K_SEAFを介してK_AUSFから導出されたことを示す。別の言い方をすれば、K_SEAFは、K_AKMAが導出されるよりも前に、AUSFによって導出される。

図９は、AUSFにおいてエラーが発生した場合、または、AUSFにH-AAuFが接続されていない場合の、鍵階層を示す。その場合には、新たな認証処理が必要となり、図９のＡ、Ｂに示すように、鍵を導出できる。図９のＡ、Ｂでは、鍵階層のK_AUSFの代わりに、K_AKMA、HN Keyがそれぞれ代入されている。この２つの図の違いは、H-AAuFに保持され且つAMKA鍵のさらなる導出に用いられる、別個の鍵であるHN鍵が導出されることである。

鍵の導出に関して、K_AUSFは、通常、ネットワークに依存することに留意されたい。そのために、AUSFは、サービスを提供するネットワークIDをUDMに送信し、UDMは、その鍵を導出する。
－ 5G AKAの場合 ： K_AUSF＝KDF（Input key, Serving network name, SQN XOR AK）
ここで、入力鍵（Input key）は、CKとIKとを連結したもの（concatenation）である。
－ EAP AKA’ ： CK’IK’＝KDF（Input key, serving network name, SQN XOR AK）
ここで、入力鍵（Input key）は、CKとIKとを連結したもの（concatenation）である。K_AUSFは、その後、CK’とIK’とから導出される。

ただし、AKMAの場合、サービスネットワーク名（serving network name）の値も設定されるべきである。5Gでは、サービスネットワーク名は、「5G:MCC MNC」であり、MCCは、モバイル国コード（mobile country code）であり、MNCは、モバイルネットワークコード（mobile network code）である。AKMAの場合、入力されるサービスネットワーク名には、いくつかのオプションがある。
－ 「AKMA」：この場合、鍵は、AKMAについて明確（specific）であるが、H-AAuF、V-AAuF、または特定のネットワークについてであるか明確ではない。
－ 「AKMA:MCC MNC」：この場合、鍵は、AKMAおよび特定のネットワークについて明確である。MCC MNCの選択は、UEがどのサービスネットワークにアタッチされているか、または、AAuFが属するサービスネットワークに基づく。したがって、H-AAuFがUDMに接続する場合、H-AAuFは、ホームネットワークMCCおよびMNCを、鍵の導出に用いるためにUDMに提供する。V-AAuFがUDMに接触する場合（例２を参照）、V-AAuFは、そのネットワークのMNC MCCを提供し、V-AAuFがH-AAuFに接触してH-AAuFがUDMを尋ねた場合、V-AAuFのMNC MCCのいずれかが用いられ得る。このようなアプローチの利点は、複数のAKMAセキュリティコンテキストを作成できることであり、例えば、UEが存在するサービスネットワークに固有のものと、ネットワークのホームネットワークに固有のものとである。利点は、或るサービスがホームネットワークでのみ利用できる場合、それらのサービスはUEとH-AAuFとの間で保護され、訪問先ネットワークで利用できるサービスは、訪問先ネットワークセキュリティコンテキストを用いることができる。

あるいは、UDMは、CKおよびIK、または、CK’およびIK’を、AAuFに直接提供し、AAuFは、AKMA鍵を導出することができる。

＜第２実施形態＞
図１０は、AAuFがホームネットワークおよび訪問先ネットワークに存在するアーキテクチャを示す。

図10のアーキテクチャは、簡略化された一般的な5Gのアーキテクチャを示す。サービングネットワーク（SNで示される）では、ネットワーク機能である、AMFおよびSEAFが示されている。図４と同様に、UEがサービングネットワークに接続されており、このことは、UEとAMFとの間の線によって示されている。この線は、UEがAMFと共に持つ、NASコネクションおよびNASセキュリティコンテキスト（NAS security context）を表す。このアーキテクチャでは、SEAFはAMFと一緒に配置されるものとして示されているが、将来、同じ機能をスタンドアロンにすることもできる。図中の線は、各素子が有線、無線、光等の通信手段を介して接続されていることを示している。その接続は、例えばUEとAMFとの間の線など、論理的であり得る。

AMF／SEAFは、AUSFと通信可能に接続されている。この線は、例えばサービスネットワークに接続するときにUEを認証するために、AMF/SEAFが、AUSFから鍵マテリアルを取得できることを示している。AUSFは、ホームネットワーク内に存在しているが、将来、AUSF機能の一部が、サービングネットワークまたは訪問先ネットワーク内に存在する可能性もある。UEが認証される必要があるときにUDMから認証データをフェッチするために、AUSFは、UDMに接続されている。

図１０において、UEは、サービングネットワーク又は訪問先ネットワークにおけるAAuF（V-AAuFで示される）にも接続されている。V‐AAuFは、AMF／SEAF及びホームネットワークのH‐AAuFと通信可能に接続されているように示されている。図１から、V-AAuFは、UDM又はAUSFにも接続されていてもよいことがわかる。本実施形態では、V-AAuFは、H-AAuFに接続されているものとし、このH-AAuFが、UDMおよびAUSFとの通信を行う。H-AAuFが欠落している場合には、ホームネットワークが許す限り、V-AAAuFが、H-AAuFの役割を果たすことができる。

図１０の線は、図４に示されるようなアーキテクチャにおけるサービスベースのインターフェースを示すこともできる。

図１１は、UEとV-AAuFとの間の例示的なメッセージ交換を示す。図５で説明したように、UEはネットワークに接続されており、サービングネットワークとUEとの間で、認証と鍵の合意とが行われていると仮定する。TS 33.501で規定されているように、この認証および鍵合意が5Gネットワーク上で行われていれば、サービングネットワークは、K_SEAF、K_AMF、および階層の下位の鍵を取得しており、ホームネットワークは、CK、IK、およびK_AUSFを計算している。認証がLTE、UMTS、GSMなどの他のネットワークで行われた場合、鍵階層は、異なり、そのようなネットワークの異なるノードによって異なる鍵が取得されるであろう。わかりやすくするために、このドキュメントでは、5Gネットワークで認証が行われていることを前提とする。

ステップ１で、UEは、サービスを要求するメッセージをV-AAuFに送信する。そのサービス要求メッセージは、UEの識別子と、UEがホームネットワーク鍵又はサービングネットワーク鍵のどちらを使用したいかを示すフラグと、鍵セット識別子（KSI：key set identifier）と、オプションとしてネットワークへの以前の認証で得られた鍵の１つ（例えば、5Gの場合のK_AUSF又はK_SEAF）を用いて計算されるMACとを含む。

サービス要求メッセージ中のそのUE識別子は、パーマネント識別子であるSUPIまたはIMSI、一時識別子である5G-GUTI、または、TS 33.501で定義されるSUCIのような識別子の暗号化バージョン（encrypted version of the identifier）であり得る。V-AAuFまたはH-AAuFが、その識別子を加入者に関連付け、そのサービスの適切な識別子を回復できる限り、その識別子は、MSISDN、SIPアドレス、電子メールアドレスなどであってもよい。

そのフラグは、実施形態１で説明した通りである。KSIも、実施形態１で説明されている。K_SEAFを参照する場合、UEは、AMF／SEAFが認証後にeKSIの値を既に格納しているため、eKSIを用いることもできる。eKSIは、ホームネットワークではなく、サービスネットワークでのみ使用できる。メッセージに含まれるMACは、実施形態１で説明されている。しかし、本実施形態では、SEAFからの鍵マテリアルを要求するV-AAuFに対してUEがそのメッセージを送信するため、UEは、K_SEAFを使用する。そのように、SEAFは、メッセージを検証することができる。そのカウンタは、AAuFまたはSEAFとUEとに保持される。別々のカウンタがネットワーク要素ごとに保持されるか、または、ホームネットワークに少なくとも１つ、訪問先ネットワークに少なくとも１つのカウンタが保持される、必要がある。

図１１のステップ２において、V-AAuFは、そのメッセージを受信する。UEがK_SEAFに基づく鍵を要求した場合、AAuFは、SEAFに対して図１２に示すような鍵要求メッセージを送信する。SEAFは、最初に鍵（本実施形態ではK_SEAF）を見つけようとし、次にMACを検証し、次に、適切な鍵で並びに必要に応じてチャレンジおよび応答で、応答する。SEAFからの応答は、UEがSEAFの信頼性を確認できるように、MACを含んでいてもよい。

SEAFにおけるUEメッセージの検証は、以下のように動作する。まず、SEAFは、SUPIなどのUE IDを取得し、メモリからK_SEAFを取得する。AUSFは、KSIを使用して、正しい鍵を取得したことを確認する。次に、SEAFは、上記のMACの計算を用いてMACを確認し、一致する場合、SEAFは、UEを識別し、続行できる。ここで、SEAFは、K_AKMAを取得（derive）して、AAuFに転送する。オプションで、UEがAAuFによって認証されることを可能にするために、上記のメッセージは、RAND、RES、およびMACを含んでいてもよい。

代替として、SEAFは、UEメッセージからKSIを取得し、KSIが計算される場合はKSIを使用して、K_AUSFを検索することもできる。KSIがeKSIに等しく設定されている場合、eKSIはUEを識別するには短すぎるため、これは不可能である。

別の選択肢として、UEメッセージは、KSIを省略できる。この場合、SEAFは、鍵が正しいかどうかを確認できない。SEAFは、メッセージのMACだけを確認できる。この方法の利点は、追加のストレージが不要であることと、UE側でKSIの計算が不要であることである。さらに別の方法として、UE IDだけをメッセージに含めることもできる。このような場合、SEAFは、UEを認証するために、RAND、RES、およびMACで応答し、認証が成功した後にだけAAuFに鍵を提供する。認証が必要なのは、SEAFがKSIまたはMACがないとUEのアイデンティティを確認できないため、鍵を間違った相手に渡す可能性があるためである。また、カウンタは、KSIに含まれ得る。

K_AKMAの計算は、鍵導出関数および他の複数のパラメータを用いて、K_SEAFから直接為されうる。

AUSFがUEのアイデンティティを確認してその鍵を送信した後、V-AAuFは、UEに次のメッセージを送信する（図１１のステップ３）。すべてが上手くいった場合、つまり、鍵が発見されてK_AKMAが導出された場合、このメッセージは、V-AAuFがK_AKMAを取得したことおよびそれがどの鍵から導出されたかという、UEについての確認（confirmation for the UE）を運ぶ。さらに、そのメッセージは、RESなどの、UEを認証するための情報を含んでいてもよく、また、そのメッセージは、MACなどの、UEが鍵の正しさ（correctness）を検証できるようにする情報（material）を含んでいてもよい。そのMACは、UEがAAuFとUEとが同じ鍵を持っていることを確認できるように、新しい鍵を用いて計算されまる。例えば、KDFに基づく別のMACが用いられ得る。
MAC＝KDF（K_AKMA, MSG）

あるいは、シグナリング鍵は、K_AKMAから導出され得、このK_AKMAは、UEとAAuFとの間のシグナリングについての、暗号化および／または完全性保護のいずれかに使用され得る。

図１１のステップ４で、UEがメッセージを受信すると、UEは、同じ方法で同じ鍵を導出し、そのメッセージの完全性（integrity）を検証し、必要に応じて認証チャレンジに応答する。これで、UEとV-AauFとは、同じルート鍵に基づく同じK_AKMAを共有する。

例１：
上記の複数の図を参照すると、上記の複数のステップは以下の通りである。図１１の第１ステップでは、UEは、V-AAuFへ、「SEAF」にフラグを設定したサービス要求を送信する。UEは、そのメッセージに、そのSUPI、KSI_SEAFまたはeKSI、およびMACも含める。第２ステップでは、V-AAuFは、そのメッセージを受信する。V-AAuFは、UEがそのサービスの利用を許可されているかどうかを確認する。サービスが許可されていない場合、V-AAuFはここでストップする。それ以外の場合、V-AAuFは、処理を続行し、SEAFにそのメッセージを送信する。SEAFはK_SEAFを取得し、KSIをチェックし、メッセージのMACを確認し、問題がなければ、K_SEAFおよび新しいランダム値RANDからK_AKMAを計算する。SEAFは、確認メッセージ（confirmation message）で、K_AKMAおよびRANDをV-AAuFに転送する。V-AAuFは、鍵がK_SEAFから導出されたことを示す応答メッセージを生成し、RANDを追加し、新たに取得した鍵またはそのシグナリング派生物（a signalling derivative thereof）を用いて応答メッセージに署名し、それをUEに送信する。UEは、RANDおよびK_SEAFを用いてK_AKMAを計算し、そのメッセージを検証し、鍵が正常に導出されたことを示す確認メッセージを送信する。UEは、V-AAuFと同じ鍵で確認メッセージを保護する。

K_SEAFがSEAFで利用できない場合、K_SEAFを再度取得するために追加の手順が必要になる。このステップを取得する１つの方法は、V-AAuFからAUSFに、K_SEAFから導出されたK_AKMAを求めるメッセージを送信することである。そして、AUSFは、まず、K_SEAFを導出し、次にK_AKMAを導出して、これをV-AAuFに戻す。代替的には、AUSFが直接K_SEAFをV-AAuFに提供し、このV-AAuFがその計算を行うことができる。もう一つの選択肢は、V-AAuFが、H-AAuFに、K_SEAFまたはK_SEAFに基づくK_AKMAの提供を求めること、である。

例２：
上記の複数の図を参照すると、上記の複数のステップは以下の通りである。図１１の第１ステップでは、UEは、V-AAuFへ、フラグを「AUSF」に設定したサービス要求を送信する。UEは、SUPI、KSI_AUSF、および、MACも、そのメッセージに含める。第２ステップでは、V-AAuFは、そのメッセージを受信する。V-AAuFは、UEがローミングしているかどうかをチェックし、また、ローミングパートナー（つまり、それ自身）がホームネットワーク鍵の使用を許可しているか否かをチェックし、また、UEがサービスの使用を許可されているか否かをチェックする。サービスが許可されていない場合、V-AAuFはここでストップする。UEがローミング中で、且つ、訪問先のオペレータによってK_AUSFが許可されている場合、V-AAuFは、処理を進め、AUSFにメッセージを送信する。AUSFは、K_AUSFを取得し、KSIをチェックし、メッセージのMACを検証し、すべてに問題がなければ、まずK_AUSFおよび新しいランダム値RANDからK_AKMAを計算する。AUSFは、確認メッセージで、K_AKMAおよびRANDを、V-AAuFに転送する。V-AAuFは、鍵がK_AUSFから導出されたことを示す応答メッセージを生成し、RANDを追加し、その新たに取得した鍵またはそのシグナリング派生物（signaling derivative thereof）を用いて応答メッセージに署名し、それをUEに送信する。UEは、RANDおよびK_AUSFを用いてK_AKMAを計算し、そのメッセージを検証し、鍵が正常に導出されたことを示す確認メッセージを送信する。UEは、V-AAuFと同じ鍵でその確認メッセージを保護する。

例３：
上記の複数の図を参照すると、上記の複数のステップは以下の通りである。図１１の第１ステップでは、UEは、V-AAuFへ、フラグを「AUSF」に設定したサービス要求を送信する。UEは、SUPI、KSI_AUSF、およびMACも、そのメッセージに含める。第２ステップでは、V-AAuFが、そのメッセージを受信する。V-AAuFは、UEがローミングしているか否かをチェックし、また、ローミングパートナー（つまり、それ自身）がホームネットワーク鍵の使用を許可しているか否かをチェックし、また、UEがサービスの使用を許可されているか否かをチェックする。サービスが許可されていない場合、V-AAuFはここでストップする。UEがローミング中で、且つ、訪問先のオペレータがK_AUSFを許可している場合、V-AAuFは、H-AAuFにメッセージを送信し、H-AAuFは、K_AUSFの使用が許可されているかどうかをチェックする。許可されていれば、H-AAuFは、処理を続行し、メッセージをAUSFに送信する。AUSFはK_AUSFを取得し、KSIをチェックし、メッセージのMACを検証し、すべて正常であれば、まず、K_AUSFおよび新しいランダム値RANDからK_AKMAを計算する。AUSFは、確認メッセージで、K_AKMAおよびRANDをH-AAuFに転送する。H-AAuFは、鍵がK_AUSFから導出されたことを示す応答メッセージを生成し、RANDを付加し、その新たに取得した鍵またはそのシグナリング派生物を用いて応答メッセージに署名し、それをV-AAuFに送信し、そして、V-AAuFはそれをUEに送信する。UEはRANDおよびK_AUSFを用いてK_AKMAを計算し、そのメッセージを検証し、鍵が正常に導出されたことを示す確認メッセージを送信する。UEは、H-AAuFと同じ鍵で確認メッセージを保護する。

鍵階層オプション（Key Hierarchy Options）
図１３は、UEがK_SEAFに基づく鍵を要求する場合の鍵階層の一例を示す。その複数の鍵は、図７と同じであるが、違いは次のとおりである。
－ K_SEAF ： この鍵は、AUSFによってK_AUSFから導出され、5G認証手順（5G authentication procedure）の一部としてSEAFに送信される。この鍵はSEAFに格納されてもよい。この鍵階層では、この鍵と（Kを除く）上記の複数の鍵は、UEとネットワークとにおける認証および鍵アグリーメントが成功した結果である。
－ SN鍵（SN Key） ： この鍵は、既存の鍵階層の一部ではない。SN鍵は、V-AAuFにあり、ホームネットワークにおける鍵HNと同様の役割を持つ。この場合、SEAFは、認証後にV-AAuFにその鍵をプッシュし、これにより、SEAFに鍵を格納する必要はなく、または、V-AAuFはSEAFから鍵を１回取得するだけで済む。いずれにしても、それが使用される場合、K_AKMAはSN鍵から導出され得る。

K_AKMAは、AKMAサービスに使用される鍵である。K_AKMAは、K_SEAFから直接導出され得るし、または、新しく導入されたSN Keyから導出され得る。K_AKMAは、AKMAのルート鍵としても機能する。その場合、AAuFとUEとの間のAKMAのシグナリングを保護するために、１つ以上の個別の制御鍵が導出され、また、データ転送用にアプリケーション固有の鍵が導出される。

UEがK_AKMAの基礎（basis）としてK_AUSFの使用を示している場合、鍵階層および鍵導出は、図１３による。

場合によっては、SEAFが鍵を紛失している可能性がある。そのような場合、図１４の鍵階層を使用することができる。このケースは、V-AAuFがH-AAuFに鍵を要求するケースを説明している。例１では、H-AAuFはK_SEAFを取得できると言われており、この鍵階層にてK_SEAFは、ホームネットワーク内でH-AAuFによって取得されるため、HN鍵に抽象化される。この場合、H-AAuFは、AUSFからHN鍵を取得する。次に、H-AAuFは、このHN鍵からSN鍵を導出するか、または、SN鍵としてHN鍵をV-AAuFに転送し、これにより、V-AAuFは、K_SEAFを取得した場合と同様に、K_AKMA鍵を導出できる。この場合、別の鍵導出が使用されることをUEにシグナルバックする必要はない。

例２は、図１５に表示される鍵階層につながり、ここでは、SN鍵が、K_AKMAに等しい（つまり、SN鍵からK_AKMAの導出（derivation）は無い）。以前の鍵階層と同様に、SN鍵を導入することにより利点があるが、例１に示すように厳密には必要ではない。

例３は、図１４に示されるように、HN鍵およびSN鍵の両方がK_AKMAに等しい、鍵階層につながる。また、K_AKMAの導出前の複数の中間鍵（intermediate keys）を用いることによって、図１４に示すような代替案を得ることもできる。これらの鍵の利点は、前の実施形態で説明した。

図９（先の実施形態）は、AUSFにエラーが発生した場合、又は、H-AAuFがAUSFに接続されていない場合の、鍵階層を示している。SEAF又はAUSFからの鍵が利用できない場合（原因としては、それらが鍵を失ったこと、又は、V-AAuFがこれらのノードに通信可能に接続されていないこと、が考えられる。）に、V-AAuFについても同様の階層が存在する。
－ V-AAuFがUDMに接続されている場合、認証を行うことで図９のケースＡまたはケースＢと同様の鍵階層を得ることができる。図９Ａとの違いは、H-AAuFをV-AAuFに置き換えることである。また、図９Ｂとの違いは、H-AAuFをV-AAuFに置き換え、HN鍵をSN鍵に置き換えることである。

V-AAuFがH-AAuFに接続されている場合、前の項目で説明した鍵階層が取得され得る。さらに、HN鍵から付加的なSN鍵が導出される鍵階層が得られ得る。

＜第３実施形態＞
AKMAの他に、BESTと呼ばれる他の技術も存在する。本実施の形態では、5Gの鍵階層を用いることができるような、拡張BEST（enhancing BEST）を扱う。

図１６は、EMSDPセッション設定手順およびBEST TS 33.163による認証を示す。このフローでは、第１ステップは、UEが、UE ID、BEST能力（BEST capabilities）、エンタープライズ情報を含む、EMSDPセッション要求を用いて、HSEに接続する。第２ステップでは、HSEは、鍵アグリーメントパラメータ（Key Agreement parameters）、要求証明（Request Validation）、およびHSE IDを含む、EMSDP Session Startを用いて応答する。第３のオプションのステップでは、UEが、認証確認メッセージ（authentication confirmation message）であるEMDSP Session Startを承認（confirm）する。

このフローでは、HSEとUEとが相互に認証を行い、これにより新しい鍵データが生成される。つまり、BESTセッションをセットアップするには、新しい認証の実行が必要とされる。

変形１：
図１７は、UEがK_AUSFに基づく鍵の使用をシグナリングすることが可能となるように、フローを拡張したものである。
このフローでは、第１ステップにおいて、EMSDP Session Requestメッセージが、UEがK_AUSFに基づく鍵を使用することを希望するフラグも含むように、拡張されている。

UEが送信するEMSDP Session Startメッセージの形式は次のとおりである。
－ CPフラグがCPに設定される。
－ RFUが0に設定される。
－ 鍵IDが000に設定される。
－ CP COUNTERが0に設定される。
－ セッションIDがすべて0に設定される。
－ EMSDPコマンドがEMSDP Session Request（10）に設定される。
－ CMDオプションは、IMSI TLV、BEST UE Configuration TLV、並びに、オプションでEnterprise Setup Information Element TLVおよびServing TLVに設定される。
－ MACが含まれず、Data lengthが0に設定され、Dataが空である。

BEST UE Configuration TLVでは、UEは、将来の使用のために予約された複数のビットのうちの１つを１に設定し、これにより、HSEに、BEST鍵の導出にK_AUSFを使用したいことを示す。HSEが5G拡張HSE（5G enhanced HSE）の場合、HSEは、そのビットを読み取り、AUSFからのBEST鍵を要求する。AUSFは、BEST鍵、RAND、およびRESで応答し、それをHSEに転送する。HSEは、UEがEMSDP Session Start messageにおける適切なBEST鍵を導出（derive）できるように、RANDをUEに転送する。

変形２：
変形１では、AUSFが、正当なUEからのメッセージであることを確認することはできなかった。この変形２では、UEは、AUSFが正当なUEからのメッセージであることを確認できるように、KSI_KAUSFおよびMACも含める。

そのために、UEは、EMSDP Session StartメッセージのCMDオプション部分に、２つの新しいTLV、つまりKSI TLVおよびMAC TLVを含める。KSI TLVには、UEはAUSFのKSIを含め、MAC TLVには、UEはMACを含める。BEST UE Configuration TLVでは、UEは、BEST鍵の導出にK_AUSFを使用したいことをHSEに対して示すために、将来使用するために予約されている複数のビットのうちの１つを１に設定する。

HSEが5G拡張HSE（5G enhanced HSE）の場合、HSEは、そのビットを読み取り、UE ID、KSI、およびMACを含むメッセージをAUSFに送信することによって、AUSFからのBEST鍵を要求する。AUSFは、MACおよびKSIを検証し、一致する場合、鍵、BEST鍵、RAND、およびRESで応答して、それをHSEに転送する。HSEは、UEにRANDを転送し、これにより、UEは、EMSDP Session Start messageにおける適切なBEST鍵を取得できる。

変形３：
変形２では、新しい複数のTLVを認識しないHSEとの下位互換性（backwards compatibility）は無かった。

この変形では、そのことは、新しいラウンドトリップを含めることによって解決される。そのために、UEは、EMSDP Session Start messageのCMDオプション部分に２つの新しいTLV（KSI TLVおよびMAC TLV）を含めず、その代わりに、BEST UE Configuration TLVにおいて将来の使用のために予約されている複数のビットのうちの１つを１に設定するだけで、BEST鍵の導出にK_AUSFを使用したいことをHSEに対して示す。

HSEが5G拡張HSE（5G enhanced HSE）の場合、HSEは、そのビットを読み取り、UEに対してKSIおよびMACの要求で応答する。UEは、KSIおよびMACで応答し、HSEは、これらを受信した後、UE ID、KSIおよびMACを含むメッセージをAUSFに送信することによって、AUSFからのBEST鍵を要求する。AUSFは、MACおよびKSIを検証し、それらが一致する場合、鍵、BEST鍵、RANDおよびRESで応答し、それをHSEに転送する。HSEは、UEがEMSDP Session Start messageにおける適切なBEST鍵を導出できるように、RANDをUEに転送する。

この方法の利点は、必要なデータのみが送信されることである。HSEが5G拡張されていない場合、UEは、KSIおよびMACを送信する必要が無く、バッテリ電力をセーブする。

変形４：
変形２では、EMSDP Session Request messageにおけるIMSI TLVのIMSI値がUEのIMSI値に設定された。この変形４では、UEは、BESTの構成ファイル（configuration file）を有し、この構成ファイルは、HSEが5G互換であることをUEに伝える。したがって、UEは、IMSIフィールドに、IMSIを含めず、KSI_AUSFを含める。ここで、UEは、KSIがIMSI TLVで既に設定されているため、KSI TLVも省略する。BEST UE Configuration TLVにおいて、UEは、将来使用するために予約されている複数のビットのうちの１つを１に設定することによって、BEST鍵の導出にK_AUSFを使用したいことをHSEに示す。

メッセージを受信すると、HSEは、ビットを読み取り、KSIおよびMACを含むメッセージをAUSFに送信することによって、AUSFからのBEST鍵を要求する。AUSFは、KSIを使用して鍵を検索し、その鍵を使用してメッセージを検証する。正しい場合、AUSFは、鍵、BEST鍵、RAND、およびRESで応答し、それをHSEに転送する。HSEは、UEがEMSDP Session Start messageにおける適切なBEST鍵を取得できるように、RANDをUEに転送する。

この方式の利点は、或るデータ（つまりIMSI）が省略され、プライバシーの影響を受けにくくし、UEでの非対称計算（asymmetric calculation）を回避できることである。また、IMSIが送信されないため、バッテリの消費電力を削減できる。

この利点は、AAuFとUEとがAKMAの適切な鍵の使用方法を一緒に決定できることである。
－ 複数のアプリケーション固有鍵（application specific keys）は、アプリケーションIDとランダムまたはカウンタとの両方で区別される。これにより、UEが同じサービスに２回接続しても、鍵が繰り返されることを回避できる。
－ AKMA鍵の導出は、次のように回避できる。
＞ 前述の実施形態では、AKMA鍵がAKMAサービスのルート鍵であると仮定した。本実施形態では、AKMA鍵を導出する必要はない。そのためには、図１２のメッセージを以下のように変更する。
＊ ステップ１:AAuFは、第１ステップでAKMAサービス要求を送信し、この要求は、UE IDフィールドと、オプションでSEAFがUEの有効性を確認するためのマテリアルとが含まれる。
＊ SEAFは、OKを返し、メモリ内にK_SEAFを有し、新しい鍵が導出され得ることを示す。
＊ AAuFは、一時識別子（temporary identifier）をUEに送り返し、そのUE識別子を格納する。
＞ その後、鍵を要求するサービスごとに、AAuFによる次の手順が続く（図２３参照）。
＊ AAuFは、一時UE IDを受信した後に格納および取得されたUE IDとAApFIDとを用いて、SEAFからの鍵をSEAFに要求する。
＊ SEAFは、鍵と使用されるCOUNTERまたはRANDとで、応答する。

上記では、SEAFと書かれているが、これをAUSFに置き換えて、AUSFで使用するための手順を得ることができる。

アプリケーション鍵にK_AKMA鍵を用いる例（Example of using the K_AKMA key for Application Keys）：
K_AKMAの導出の後、アプリケーションは、まだ使用可能になっていない。アプリケーションサーバーはまず、アプリケーションサーバー用の鍵を取得する必要がある。複数のアプリケーションサーバー鍵についての暗号化鍵分離（cryptographic key separation）を得るためには、２つの方法がある。

変形１：
この変形では、RANDを使用して、異なる複数のAAuFの間の鍵分離（key separation）を作成する。これは次のように機能する。
－ UEは、一時識別子を持つサービス要求を、AApFに送信する。
－ AApFは、UEの一時識別子とAApFに固有の識別子とを含むアプリケーション要求を用いて、AAuFにコンタクトする。
－ AAuFは、アプリケーション固有鍵（application specific key）を次のように導出する。
K_AF＝KDF（input key, AApFID, RAND）
そして、AAuFは、RAND、鍵、および関連する有効時間を、AApFに送信する。
－ AApFは、UEにRANDを送信し、UEは、AAuFと同様のK_AFを次の方法で計算する。
K_AF＝KDF（input key, AApFID, RAND）

AApFIDがUEに知られていない場合、AApFは、RANDも含むメッセージにAApFIDも含める。

UEによって使用される一時識別子は、先の実施形態で説明したブートストラッピングまたは鍵合意手順（bootstrapping or key agreement procedure）中に、AAuFによって割り当てられる一時識別子であり得る。したがって、この識別子は、新しいブートストラップまたは鍵合意手順ごとに、異なることが期待される。

変形２：
この変形では、アプリケーション機能カウンタ（Application Function (AF) COUNTER）を使用して、異なる複数のAAuFの間の鍵分離（key separation）を作成する。UEおよび（AAuFまたはAUSFのいずれかである）AKMA認証機能（AKMA authentication function）は、5Gの3GPPクレデンシャル（3GPP credential）に基づいてUEにAKMAアンカー鍵（K_AKMA）が生成されるたびに、AFカウンタを‘０’に初期化する。AFカウンタは、新しいアプリケーション鍵（K_AF）が生成されるたびに単調にインクリメントされ、同じK_AKMAからのK_AF生成時の入力として使用される。UE固有のAFカウンタは、UEおよびAKMA認証機能の両方で管理される。これは次のように機能する。
－ UEは、一時識別子を持つサービス要求を、AApFに送信する。
－ AApFは、UEの一時識別子とAApF固有の識別子とを含むアプリケーション要求を用いて、AAuFとコンタクトする。
－ AAuFは、ローカルに保存されたAFカウンタをインクリメントし、次のようにアプリケーション固有鍵を導出する。
K_AF＝KDF（input key, AApFID, AF COUNTER）
そして、AAuFは、AFカウンタ、鍵、および関連する有効時間を、AApFに送信する。
－ AApFは、UEにAFカウンタを送信し、UEは、AAuFと同様のK_AFを次のように計算する。
K_AF＝KDF（input key, AApFID, AF COUNTER）

導出の前に、UEは、受信したAFカウンタ値が、UEに保持されているAFカウンタ値に１を加算した値と一致するかどうかを検証する。検証が成功した場合にのみ、UEは、K_AFを計算する。AApFIDがUEに知られていない場合、AApFは、AFカウンタも含むメッセージにAApFIDも含める。

AFカウンタは、AKMAサービスのための新しい鍵がUEに対して導出される度に、あるいは、UEについてAAuFによって新しい鍵が取得される度に、０にリセットされる。複数のAKMAセキュリティアソシエーションが存在する場合、そのカウンタは、鍵固有である（１つはK_AKMAについてのものであり、もう１つはK_SEAFについてのものであり、そしてもう１つはK_AUSFについてのものである。）。

十分なカウンタスペースを確保するために、１６ビットカウンタを使用することができる。

図２４は、UEの主要な構成要素を示すブロック図である。図に示すように、UEは、１つ以上のアンテナを介して接続された１つ以上のノードと信号を送受信するように動作可能な送受信回路（transceiver circuit）を含む。図２４に必ずしも示されていないが、UEは、当然、従来のモバイルデバイスのすべての通常の機能（ユーザーインターフェース等）を有し、これは、適宜、ハードウェア、ソフトウェア、およびファームウェアの任意の１つまたは任意の組み合わせによって提供され得る。ソフトウェアは、メモリに予めインストールされてもよく、および／または、例えば、電気通信ネットワークを介してまたは取り外し可能データ記憶装置（RMD：removable data storage device）からダウンロードされてもよい。

コントローラは、メモリに記憶されたソフトウェアに従ってUEの動作を制御する。例えば、コントローラは、Central Processing Unit（CPU）により実現されてもよい。ソフトウェアは、とりわけ、オペレーティングシステムと、少なくともトランシーバ制御モジュールを有する通信制御モジュールとを含む。（トランシーバー制御サブモジュールを用いる）通信制御モジュールは、UEと、他のノードとの間のシグナリングおよびアップリンク／ダウンリンクのデータパケットの処理（生成／送信／受信）を担当し、その他のノードは、基地局／（R）ANノード、MME、AMF（および他のコアネットワークノード)などである。そのようなシグナリングは、例えば、接続の確立および保守に関連する適切にフォーマットされたシグナリングメッセージ（例えば、RRCメッセージ）、定期的なロケーション更新関連メッセージ（location update related messages）（例えば、トラッキングエリアの更新、ページングエリアの更新、ロケーションエリアの更新）などのNASメッセージを含み得る。

図２５は、例示的な（R）ANノード、例えば基地局（LTEでは「eNB」、5Gでは「gNB」）の主要な構成要素を示すブロック図である。図示のように、（R）ANノードは、１つまたは複数のアンテナを介して接続されたUE（s）と信号を送受信し、ネットワークインターフェースを介して（直接的または間接的に）他のネットワークノードと信号を送受信するように動作可能な送受信回路（transceiver circuit）を含む。コントローラは、メモリに記憶されたソフトウェアに従って、（R）ANノードの動作を制御する。例えば、コントローラは、Central Processing Unit（CPU）により実現されてもよい。ソフトウェアは、メモリに予めインストールされてもよく、および／または、例えば、電気通信ネットワークを介してまたは取り外し可能データ記憶装置（RMD）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステムと、少なくともトランシーバ制御モジュール（transceiver control module）を有する通信制御モジュール（communications control module）とを含む。

（トランシーバー制御サブモジュールを用いる)通信制御モジュールは、（例えば直接的または間接的に）（R）ANノードと他のノードとの間のシグナリングの処理（生成／送信／受信）を担当し、その他のノードは、UE、MME、AMFなどである。シグナリングは、例えば、（特定のUEについての）無線接続およびロケーション手順（radio connection and location procedures）に関連する、特に、接続確立およびメンテナンスに関連する、適切にフォーマットされたシグナリングメッセージ（例:RRC接続確立および他のRRCメッセージ）、定期的なロケーション更新関連メッセージ（例えば、トラッキングエリアの更新、ページングエリアの更新、ロケーションエリアの更新）、S1 APメッセージ、および、NG APメッセージ（つまり、N2基準点（N2 reference point）によるメッセージ）などを含んでもよい。そのようなシグナリングは、例えば、送信の場合には、ブロードキャスト情報（例えば、マスター情報やシステム情報など）を含んでいてもよい。

コントローラはまた、実装されたときに、UE移動度推定（UE mobility estimate）および／または移動軌跡推定（moving trajectory estimation）などの関連タスクを処理するように（ソフトウェアまたはハードウェアによって）構成される。

図２６は、例示的なコアネットワークノード、例えば、AMF、SEAF、AUSF、UDM、ARPF、AAuF、AApF、または任意の他のコアネットワークノードの、主要な構成要素を示すブロック図である。AMFは、SEAFを構成することができる。AMFは、ネットワークにおけるモビリティ管理（mobility management）および登録管理（registration management）を提供し、モビリティ管理ノード（mobility management node）とも呼ばれる。SEAFは、セキュリティアンカー機能（security anchor function）と呼ばれ、ネットワークにおけるアンカー鍵の格納および管理（storage and management of an anchor key）を提供する。UDMは、加入者登録（ubscriber registration）であり、クレデンシャルストレージ（credential storage）としてARPFを含むこともできる。さらに、UDMは、秘匿されたパーマネント識別子の非秘匿化（deconcealing of the concealed permanent identifier）のためのサービスを提供するためのSIDF（サブスクリプション識別子非秘匿機能（Subscription Identifier De-concealing Function））も含み得る。AUSFは、認証機能であり、UDMにフロントエンドを提供する。また、AUSFは、アンカー鍵を格納するストレージを含んでもよい。UDM、および／または、UDM／ARPF／SIDFのいずれかの組み合わせ（combination of any of UDM/ARPF/SIDF）は、加入者データベースと呼ぶことができる。AAuFおよび／またはAApFは、AKMAサービスノードと呼ぶことができる。複数のコアネットワーク機能は、更なる複数の論理ユニットに分割することも、より大きな論理ユニットに結合することもできる。サービスベースのインターフェイスの性質上、このような組み合わせまたは分割は、機能に影響を与えず、ノード（node）という語は、複数のコアネットワーク機能（core network functionalities）の任意の組み合わせを指す。コアネットワークノードは、5GCに含まれる。図示のように、コアネットワークノードは、ネットワークインタフェースを介して他の複数のノード（UEを含む）と信号を送受信するトランシーバ回路を含む。コントローラは、メモリに記憶されたソフトウェアに従ってコアネットワークノードの動作を制御する。例えば、コントローラは、Central Processing Unit（CPU）により実現されてもよい。ソフトウェアは、メモリに予めインストールされてもよく、および／または、例えば、電気通信ネットワークを介してまたは取り外し可能データ記憶装置（RMD）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステムと、少なくともトランシーバ制御モジュールを有する通信制御モジュールとを含む。

（トランシーバー制御サブモジュールを用いる）通信制御モジュールは、（直接的または間接的に）コアネットワークノードと他のノードとの間のシグナリングを処理（生成／送信／受信）する役割を担い、その他のノードは、UE、基地局／（R）ANノード（例えば、「gNB」または「eNB」）などである。このようなシグナリングは、例えば、ここに記載される手順に関連する適切にフォーマットされたシグナリングメッセージを含んでもよく、例えば、NASメッセージをUE等との間で送受信するためのNG APメッセージ（つまり、N2基準点によるメッセージ）を含んでいてもよい。

本開示におけるユーザ機器（User equipemnt）（又は、「UE」、「移動局」、「モバイルデバイス」、又は「ワイヤレスデバイス」）は、無線インタフェースを介してネットワークに接続されるエンティティである。

なお、本明細書におけるUEは、専用の通信デバイスに限定されるものではなく、後述するように、本明細書に記載するUEとしての通信機能を有する任意の装置に適用することができる。

（3GPPで使われている用語としての)「ユーザ機器」または「UE」、「移動局」、「モバイルデバイス」、および「ワイヤレスデバイス」という用語は、一般に、互いに同義であることを意図しており、端末、携帯電話（cell phones）、スマートフォン、タブレット、セルラーIoTデバイス、IoTデバイス、および機械（machinery）などのスタンドアロンのモバイルステーションを含む。

「UE」および「ワイヤレスデバイス」という用語は、長期間にわたって静止したままであるデバイスも含むことが理解されるであろう。

UEは、例えば、生産または製造のための機器のアイテム、および／または、エネルギー関連機械（例えば、ボイラー;エンジン;タービン;ソーラーパネル;風力タービン;水力発電機;火力発電機;原子力発電所;電池;原子力システム及び／又は関連機器;重電機器;真空ポンプを含むポンプ;コンプレッサー;ファン;ブロワー;油圧機器;空気圧機器;金属加工機械;マニピュレータ;ロボットやその応用システム;ツール;金型（molds）又は金型（dies）;ロール;搬送機器;昇降機器;荷役機器;繊維機械;ミシン;印刷及び／又は関連機器;紙加工機械;化学機械;鉱業及び／又は建設機械、及び／又は関連設備;農林漁業のための機械及び／又は器具;安全及び／又は環境保全機器;トラクター;精密軸受;チェーン;ギア;動力伝達機器;潤滑機器;バルブ;配管継手;のような設備または機械、および／または、上記のいずれかの機器または機械等のアプリケーションシステム)のアイテムであってもよい。

UEは、例えば、搬送機器（例えば、次のような輸送機器:車両（rolling stocks）;自動車;モーターサイクル;自転車;列車;バス;カート;人力車;船舶、その他の船舶;航空機;ロケット;衛星;ドローン;バルーン等。)のアイテムであってもよい。

UEは、例えば、情報通信機器（例えば、電子コンピュータ及び関連機器等の情報通信機器;通信及び関連機器;電子部品等）のアイテムであってもよい。

UEは、例えば、冷凍機、冷凍機応用製品、商品及び／又はサービス産業機器のアイテム、自動販売機、自動サービス機械、オフィス機械又は機器、民生用電子機器（例えば、次のような民生用電子機器:オーディオ機器;ビデオ機器;スピーカー;ラジオ.;テレビ;電子レンジ;炊飯器;コーヒーマシン;食器洗い機;洗濯機;乾燥機;電子ファンまたは関連機器;掃除機など)であってもよい。

UEは、例えば、電気アプリケーションシステムまたは機器（例えば、次のような電気アプリケーションシステムまたは機器:X線システム;粒子加速器;ラジオアイソトープ装置;音響機器;電磁応用機器;電子応用装置等）であってもよい。

UEは、例えば、電子ランプ、照明器具、測定器、分析器、テスタ、または、測量または感知器（例えば、次のような測量機器または感知機器:煙警報器;人間の警報センサー;運動センサー;無線タグなど）、腕時計または時計、実験装置、光学装置、医療機器および／またはシステム、武器、刃物のアイテム、手工具などであってもよい。

UEは、例えば、無線を備えた携帯情報端末または関連機器（例えば、別の電子デバイス（例えば、パーソナルコンピュータ、電気計測器）に取り付けられるように設計された、または別の電子デバイスに挿入されるように設計された、ワイヤレスカードまたはモジュールのようなもの）であってもよい。

UEは、様々な有線および／または無線通信技術を使用して、「物のインターネット（IoT）」に関して、以下に説明するアプリケーション、サービス、およびソリューションを提供するデバイスまたはシステムの一部であり得る。

物のインターネットデバイス（または「物」のインターネット）は、適切な電子機器、ソフトウェア、センサ、ネットワーク接続などを備えてもよく、これらのデバイスは、互いにおよび他の通信装置とデータを収集および交換することができる。IoTデバイスは、内部メモリに格納されたソフトウェア命令に従う自動化機器を備えることができる。IoTデバイスは、人間の監視や操作を必要とせずに動作する可能性がある。IoTデバイスは、長期間にわたって静止したり及び／又は非アクティブになったりする可能性もある。IoTデバイスは、（一般的には）固定装置の一部として実装することができる。IoTデバイスは、固定されていない機器（例えば、車両）に組み込まれていたり、監視や追跡の対象となる動物や人物に取り付けられていたりする場合もある。

IoT技術は、人間の入力によって制御されるか又はメモリに記憶されたソフトウェア命令によって制御されるかにかかわらず、データを送受信するために通信ネットワークに接続することができる任意の通信装置に実装することができることが理解されるであろう。

IoTデバイスは、マシンタイプ通信（MTC）デバイスまたはマシンツーマシン（M2M）通信デバイスまたはナローバンドIoT UE（NB-IoT UE）と呼ばれることもあることが理解されよう。UEは、１つ以上のIoTまたはMTCアプリケーションをサポートし得ることが理解されるであろう。MTCアプリケーションのいくつかの例は次のテーブルに示されている（出典:3GPP TS 22.368 V 13.1.0）。このリストは、完全なものではなく、マシンタイプ通信アプリケーションのいくつかの例を示すことを目的としている。

アプリケーション、サービス、およびソリューションは、MVNO（モバイル仮想ネットワーク事業者（Mobile Virtual Network Operator））サービス、緊急無線通信システム、PBX（プライベートブランチeXchange）システム、PHS／デジタルコードレス通信システム、POS（Point of sale）システム、広告呼び出し（advertise calling）システム、MBMS（マルチメディアブロードキャストマルチキャストサービス）、V2X（Vehicle to Everything）システム、列車無線システム、位置関連サービス、災害／緊急無線通信サービス、コミュニティサービス、ビデオストリーミングサービス、フェムトセルアプリケーションサービス、VoLTE（Voice over LTE）サービス、課金サービス、ラジオオンデマンドサービス、ローミングサービス、活動監視サービス、電気通信事業者／通信NW選択サービス、機能制限サービス、PoC（概念検証（Proof of Concept））サービス、個人情報管理サービス、アドホックネットワーク／DTN（ディレイトレラントネットワーキング）サービスなどであり得る。

また、上述したUEカテゴリは、本明細書に記載されている技術思想や実施例の応用例に過ぎない。もちろん、これらの技術思想や実施形態は、上述したUEに限定されるものではなく、種々の変形が可能である。

当業者には理解されるように、本開示は、方法および装置として実施することができる。したがって、本開示は、完全にハードウェアの実施形態、ソフトウェアの実施形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形態を取ることができる。

ブロック図の各ブロックは、コンピュータプログラム命令によって実施することができることが理解されよう。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されて、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートおよび／またはブロックダイヤグラムブロックにて規定された機能／動作を実行するための手段を生成するように、マシンを生成することができる。

図面および明細書において、開示の例示的な実施形態が開示されている。特定の用語が使用されるが、それらは、限定の目的のためではなく、一般的かつ記述的な意味でのみ使用され、開示のスコープは、特許請求の範囲によって定義される。

以上に開示された実施形態の全体または一部は、以下の付記のように説明することができるが、これに限定されるものではない。

（付記１）
電子デバイスのための鍵の再利用を可能にする方法であって、
前記電子デバイスからリクエストメッセージを受信することを含み、
前記リクエストメッセージは、第１のネットワークにおける第１のネットワークノードに関連付けられた第１の鍵、または、第２のネットワークにおける第２のネットワークノードに関連付けられた第２の鍵のうちの１つの優先度を示す第１の情報を含み、
前記方法は、
前記第１の情報において示される前記優先度を決定するために前記リクエストメッセージを処理することと、
前記第１の鍵又は前記第２の鍵の再利用のために前記電子デバイスに応答メッセージを送信することと、
を更に含み、
前記電子デバイスは、前記決定された優先度に示される前記第１の鍵または前記第２の鍵に基づいて、第３の鍵を導出するように構成され、
前記第２のネットワークは、前記第１の鍵及び前記第２の鍵にアクセスでき、前記第１のネットワークは、前記第２の鍵にアクセスできない、
方法。
（付記２）
前記リクエストメッセージは、前記第１の鍵又は前記第２の鍵のうちの少なくとも１つを保持する前記電子デバイスを示す第２の情報、前の通信セッション中に確立された鍵のアイデンティティを示す第３の情報、又は、ローカルポリシーを示す第４の情報を含む、
付記１記載の方法。
（付記３）
認証セッションにおいて、前記第１の鍵は、前記第１のネットワークと前記電子デバイスとの間で確立され、前記第２の鍵は、前記第２のネットワークと前記電子デバイスとの間で確立される、
付記１記載の方法。
（付記４）
ＵＥの前記優先度に基づく前記第１の鍵または前記第２の鍵を用いて認証パターンを設定することと、
前記第１の情報に基づいて、前記第１のネットワーク又は前記第２のネットワークによって選択された前記第１の鍵又は前記第２の鍵のうちの１つを取得することと、
を含む、付記１記載の方法。
（付記５）
ホームネットワーク以外のネットワークでの電子デバイスのための鍵の再利用を可能にする方法であって、
サービスリクエストを、前記ホームネットワーク以外の前記ネットワークに送信することと、
前記サービスリクエストに関するサービス応答を受信することと、
前記受信したサービス応答に基づいて認証を実行することと、
を含む、方法。
（付記６）
前記ホームネットワーク以外の前記ネットワークに関する前記サービスリクエストに存在する鍵を検証することと、
前記鍵の検証に失敗した場合、ホームネットワークを検証することと、
前記ホームネットワークとの検証に失敗した場合、認証リクエストを受信することと、
を含む、付記５記載の方法。
（付記７）
前記受信したサービス応答を検証することと、
前記検証に基づいて適切な鍵を計算することと、
前記計算された鍵に基づいて、前記サービス応答を認証することと、
を含む、付記５記載の方法。
（付記８）
前記サービス応答は、パラメータのセット、メッセージ認証コード、又は、鍵インジケーターのうちの少なくとも１つを含む、
付記５記載の方法。
（付記９）
ネットワークにおける電子デバイスのための鍵の再利用を可能にする方法であって、
少なくとも１つのセッションリクエストメッセージを第１のネットワークノードに送信することを含み、
前記少なくとも１つのセッションリクエストメッセージは、第２のネットワークノードに関連付けられた認証鍵に基づく鍵を使用することを前記電子デバイスが優先することを示すフラグを含み、
前記フラグは、少なくとも１つの鍵リクエストの形で第３のネットワークノードに転送され、
前記第３のネットワークノードは、前記少なくとも１つの鍵リクエストの検証に成功したときに、少なくとも１つの応答メッセージを、前記第１のネットワークノードに送信し、
前記方法は、開始するセッションを示すメッセージを、前記第１のネットワークノードから受信することを含む、
方法。
（付記１０）
前記第２のネットワークノードと前記第３のネットワークノードとは、同一のネットワークノードである、
付記９記載の方法。
（付記１１）
前記少なくとも１つのセッションリクエストメッセージは、ＩＤ、フラグ、前記サーバの認証鍵、鍵セット識別子、又は、メッセージ認証コードのうちの少なくとも１つを含む、
付記９記載の方法。
（付記１２）
前記少なくとも１つの鍵リクエストメッセージは、ID、前記サーバの認証鍵、鍵セット識別子、又は、メッセージ認証コードのうちの少なくとも１つを含む、
付記９記載の方法。
（付記１３）
前記少なくとも１つの鍵応答メッセージは、前記サーバの認証鍵、チャレンジコード、又は、検証済み応答メッセージのうちの少なくとも１つを含む
付記９記載の方法。
（付記１４）
複数のアプリケーション又は複数のアプリケーション機能の場合における鍵分離のために、チャレンジコードまたは認証鍵特定カウンタのいずれかが使用される、
付記１、５、又は９に記載の方法。
（付記１５）
複数のアプリケーション又は複数のアプリケーション機能の場合にける鍵分離のために、乱数が使用される、
付記１、５、又は９に記載の方法。
（付記１６）
電子デバイスと通信するためのネットワークノードであって、
コントローラと、
前記コントローラに動作可能に接続されたメモリと、
を含み、
前記コントローラは、
前記電子デバイスからリクエストメッセージを受信し、
パラメータのセットに基づいて認証を実装するための結果を得るために、前記リクエストメッセージを処理し、
前記結果を、認証鍵のセットを導出するために前記電子デバイスに送信する、
ネットワークノード。
（付記１７）
ネットワークと鍵を再利用するための電子デバイスであって、
コントローラと、
前記コントローラに動作可能に接続されたメモリと、
を含み、
前記コントローラは、
サービスリクエストを前記ネットワークに送信し、
前記サービスリクエストに関するサービス応答を受信し、
前記受信したサービス応答に基づいて、認証を実行する、
電子デバイス。

本出願は、2019年1月11日に出願されたインド特許出願第201911001407号に基づく優先権の利益を主張するものであり、その開示は参照によりその全体が本明細書に組み込まれる。

Claims (3)

1. ＡＵＳＦ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）から、ＫＡＵＳＦ（ＡＵＳＦ Ｋｅｙ）に基づき生成される、アプリケーションの認証に用いる鍵ＫＡＫＭＡ(ＡＫＭＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎｓ） Ａｎｃｈｏｒ Ｋｅｙ)を受信し、
   第一のネットワーク装置から、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）の一時識別子と当該第一のネットワーク装置に固有の識別子を含む前記アプリケーションに用いるメッセージを受信し、
   前記第一のネットワーク装置に固有の識別子と前記ＫＡＫＭＡとに基づいて、アプリケーション鍵ＫＡＦ（ＡＫＭＡ Ａｐｐｌｉｃａｔｉｏｎ Ｋｅｙ）を導出し、
   前記第一のネットワーク装置に前記ＫＡＦを送信する、
   ネットワーク装置の方法。
2. 前記メッセージは、前記アプリケーションに用いる鍵要求メッセージである
   請求項１に記載の方法。
3. 前記ＵＥの一時識別子は、前記ＵＥから前記第一のネットワーク装置に送信され、
   前記ＫＡＦは、前記アプリケーション毎に計算される、
   請求項１又は２に記載の方法。

Images