JP2022523936A - 端末、方法、及びプログラム - Google Patents

Abstract

本開示は、メモリと、サードパーティサービスのために、前記端末と、5Gにおけるネットワークとの間のプライマリ認証を実行し、セキュリティ鍵KAUSFを導出し、前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備える端末を提供する。【選択図】図１０

Description

本開示は、モバイル端末及びホームネットワークが、鍵を特定し、ホームネットワークと、モバイル端末との間で同期された鍵を維持する方法に関し、鍵は、端末と、ホームネットワークとの間の各認証セッションのために導出される。

5Gにおいて、ユーザ装置（UE：user equipment）及びネットワークを認証し、合意された鍵の使用を開始するには、２つの別々の手順が必要である。第１の手順は、認証と鍵合意（key agreement）である。この手順の間、UE及びネットワークは、相互に認証し、CK及びIK、CK'及びIK'、K_AUSF、K_SEAF及びK_AMF等の鍵階層（key hierarchy）において、上位にある、いつくかの鍵を導出(derive)できる。そのような手順が完了すると、UE及びネットワークの両方で、非現在の（non-current）（部分的な）セキュリティコンテキストが生成される（lead to）。

第２の手順は、NAS SMC（Non Access Stratum Secure Mode Command）手順であり、ネットワークが、UEに対して、最新の認証から得られた鍵を使用することを通知する。この手順の結果、非現在の（non-current）セキュリティコンテキストが、現在の（current）セキュリティコンテキストになり、古いセキュリティコンテキストは、メモリから削除される。

3GPP (3rd Generation Partnership Project) TS33.501 V15.3.1

しかしながら、非特許文献１において、（非現在の）セキュリティコンテキストの一部になることができる鍵は、鍵階層において、鍵K_AMF以下の鍵である。そのため、K_SEAF及びK_AUSFは、セキュリティコンテキストの一部にはならない。したがって、K_SEAF及びK_AUSFのステータスは、未定義であり、それらが使用されているのか否かは不明である。さらに、K_SEAF及びK_AUSFを処理する（handling）ネットワークエレメント（それぞれ、SEAF及びAUSF）は、NAS SMC手順が成功したことが通知されないため、鍵がアクティブであるか否かを知ることができない。逆に、UEは、NAS SMC手順に参加するため、いつ非現在のセキュリティコンテキストが、現在のセキュリティコンテキストになるのかを知っている。さらに複雑なことに、認証サーバ機能（AUSF：Authentication Server Function）は、ホームネットワーク内に存在する一方、アクセス及びモビリティ管理機能（AMF：Access and Mobility Management Function）又はセキュリティアンカー機能（SEAF：Security Anchor Function）は、サービングネットワーク内に存在するため、サービングネットワークが、セキュリティコンテキストが現在のセキュリティコンテキストになったのかを知っていたとしても、AUSFは、通知される手段がない。

本状況は、図１に示される。図１は、非特許文献１に開示された参考資料にかかる、１つのAKA及び１つのNAS SMCのみに存在する問題を示す。当初、UE、AMF、SEAF及びAUSFは、UEに関連する鍵を有していない。認証及び鍵合意（key agreement）が完了した後、UE、AMF、SEAF及びAUSFの全ては、最後の認証及び鍵合意（AKA）から得られた鍵を有している。ただし、この時点では、これらの鍵は、ネットワーク又はUEによりアクティブに使用されておらず、プライム（the primes）で示されている。その後、AMFが、NAS SMCを実行すると、UE及びAMFは、鍵を使用する。しかし、SEAF及びAUSFについては、鍵が使用されているかどうかが通知されないため、鍵に関してプライムのままである。

この問題に加えて、以下の問題も発生する可能性がある：
－5G AKAを使用する場合、AUSFは、認証及び鍵合意が正常に完了する前に、既にK_AUSFを記憶する。そのため、UEのsubscription unique permanent identifier（SUPI）にアクセスしたサービングネットワークは、認証をトリガするだけで、AUSF内の鍵を効率的に上書きできる。
－Extensible Authentication Protocol（EAP）AKA'を使用する場合、UEは、K_AUSF、K_SEAF及びK_AMFで構成される一時的なセキュリティコンテキストを生成し、EAP Successメッセージが受信されない場合、それを削除する。サービングネットワークは、認証をほぼ完了することにより、AUSF内のK_AUSFを上書きできるが、UEにEAP Successメッセージを送信することはない。

これにより、問題のさらなるセットを提起する：
－AUSF及びSEAFの場合：後続の手順において、K_SEAF又はK_AUSFのいずれかが使用される場合、SEAF及びAUSFは、UEが同じ鍵を使用したことを確認できない。
－UEの場合：手順の１つが、K_SEAF又はK_AUSFを使用し、UEが１つよりも多くのセキュリティコンテキストを有している場合、UEは、どの鍵が使用されたかを知らない。
－サービングネットワークは、AUSF内のK_AUSFを上書きし、この鍵の存在に依存するサービスを無効にできる。

図２には、非特許文献１に定義されている鍵階層が示されている。図２は、非特許文献１に定義された鍵階層を示す。認証及び鍵合意の結果として、この鍵階層は、UE及び図に示されている異なるネットワークエレメントで確立される。5Gでは、破線のボックスで示されている、5G AKA及びEAP AKA'という２つの認証プロトコルがある。

これらの鍵のうち、以下の鍵及びパラメータは、セキュリティコンテキストの一部である：
－5Gセキュリティコンテキスト：5G NASセキュリティコンテキスト、及び3GPPアクセスのための5Gアクセスストラタム（AS：Access Stratum）セキュリティコンテキスト及び／又は非3GPP(non-3GPP)アクセスのための5G ASセキュリティコンテキスト。
－3GPPアクセスのための5G ASセキュリティコンテキスト：K_gNB、NH (next hop parameter), K_RRCint、K_RRCenc、K_UPint、K_UPenc、Next Hop Chaining Counter parameter (NCC)、鍵の識別子（identifiers for keys）、UEセキュリティケーパビリティ（UE security capabilities）、UPセキュリティポリシー及びリプレイ保護（replay protection）に使用されるカウンタ。
－非3GPPアクセスのための5G ASセキュリティコンテキスト：K_N3IWF及び暗号化鍵（cryptographic keys）暗号化アルゴリズム（cryptographic algorithms）及びIPsec接続に関連付けられたトンネルセキュリティパラメータ（tunnel security parameters）。
－完全な（Full）5G NASセキュリティコンテキスト：K_AMF、K_NASint、K_NASenc、ngKSI (next generation Key Set Identifier)、UEセキュリティケーパビリティ（UE security capabilities）、アップリンク及びダウンリンクカウンタ。
－部分的な（Partial）5G NASセキュリティコンテキスト：K_AMF、ngKSI、UEセキュリティケーパビリティ（UE security capabilities）、0に設定されたアップリンク及びダウンリンクNAS COUNT値。

図３は、入力を伴う鍵導出を示す。図３は、非特許文献１に定義されている、鍵導出入力を伴う鍵階層を示す。

図４は、非特許文献１におけるNAS secure mode command手順を示す。図４において、非現在のセキュリティコンテキストを使用するNAS SMC手順が示されている。

図４は、NAS Secure Mode Commandが、K_AMFを識別し、K_AMFを導出するためにそれぞれ必要である、ngKSI及びAnti-Bidding down Between Architectures（ABBA）パラメータを含むこと示している。図４から分かるように、暗号化（ciphering）及び完全性保護（integrity protection）は、UE及びAMFにおいてそれぞれのメッセージの受信後に開始される。そのため、鍵は、この手順の間で使用される。

図５は、現在の技術（the state of the art）に従ってEAP AKA'を使用するときの部分的なセキュリティコンテキストを確立するための方法を示す。図５は、現在の技術にかかるEAP AKA'の認証及び鍵合意手順を示す。

図５は、以下のステップを含む。
１．UEは、registration requestメッセージをモバイルネットワーク内のSEAFに送信する。UEは、registration requestメッセージに、以下を含める：
－Subscription Permanent Identifier （SUPI）から計算されたSubscription Concealed Identifier （SUCI）及びUEに記憶されているホームネットワーク公開鍵、又は：
－ネットワークにより実行された以前の認証及び鍵合意の後、UEに提供された5G一時識別子。

２．（Optional）SEAFは、UEからregistration request又はinitial NASメッセージを受信すると、一時識別子を知っているかどうかを判定する。一時識別子が含まれているが、SEAFに知られていない場合、SEAFは、identification手順を開始し、identity requestメッセージをUEに送信する。

３．（Optional）UEが、identity requestメッセージを受信した場合、UEは、SUCIを含むidentity responseメッセージでSEAF／AMFに応答する。

４．identity responseメッセージを受信すると、SEAFは、SUCI及びサービングネットワーク名（Serving Network Name）を含むauthentication requestメッセージをAUSFに送信することにより、認証を開始する。5Gでは、この要求は、Nausf_UE_Authentication Authenticate Requestと呼ばれる。

５．authentication requestメッセージの受信後、AUSFは、UDMに、認証ベクトル（authentication vector）の要求を示すauthentication vector requestメッセージを送信する。AUSFは、SUCI及びサービングネットワーク名を、この要求に含める。5Gでは、この要求は、Nudm_UEAuthentication_Get Requestと呼ばれる。

６．authentication vector requestメッセージの受信後、UDMは、使用する認証方法（EAP AKA'又は5G AKA）を決定し、認証ベクトルを生成し、それをAUSFに送信する。認証ベクトルは、EAP AKA'の場合、RAND、AUTN、XRES、CK'及びIK'を含み、AUSFへの応答で、認証ベクトル及びSUPIが送信される。5Gでは、このメッセージは、Nudm_UEAuthentication_Get Responseである。

７．AUSFが認証ベクトルを受信した場合、AUSFは、EAP-Request/AKA'-ChallengeをSEAFに送信する。このメッセージは、RAND、AUTNを含む。

８．SEAFは、EAP-Request/AKA' Challengeを受信し、このメッセージをUEに送信する。SEAFには、ngKSI及びABBAパラメータも含まれているため、認証に成功した後、UEはK_AMFを導出できる。

ステップＡにおいて、UEは、AUTNを検証し、成功した場合、USIMに格納されているRES及びKを使用し、CK及びIKを計算し、CK及びIKから、CK'及びIK'、K_AUSF、K_SEAF及びK_AMFを計算する。UEは、K_AUSF、K_SEAF、K_AMF、ngKSI及びカウンタ等のセキュリティコンテキスト関連パラメータが格納された一時的なセキュリティコンテキストを生成する。

９．UEは、RES（response）をSEAFに返す。5Gでは、このメッセージは、Authentication Responseメッセージである。

１０．SEAFは、RESをAUSFに転送する。5Gでは、SEAFが使用するメッセージは、Nausf_UEAuthenticationAuthenticate Requestメッセージである。

ステップＢにおいて、AUSFは、メッセージを受信した後、応答（response）を検証し、正しい場合、K_AUSFを記憶する。

１１．応答（response）が成功した場合、AUSFは、EAP SuccessメッセージをSEAFに送信する。AUSFはまた、K_SEAF及びSUPIを同じメッセージでSEAFに送信する。

１２．EAP Successメッセージを受信すると、SEAFは、EAP Successメッセージの受信後、K_AMFを計算し、K_AMF及びSUPIをAMFに転送する。また、SEAFは、EAP SuccessメッセージをUEに送信してもよい。

ステップＣにおいて、SEAFが、EAP SuccessメッセージをUEに送信する場合、UEは、一時的なセキュリティコンテキストを、K_AUSF、K_SEAF及びK_AMFを含む現在のセキュリティコンテキストに変換し、後で使用するためにそれを記憶する。EAP Successメッセージが送信されなかったが、UEが、後でNAS SMCを受信する場合、UEは、一時的なセキュリティコンテキストを、現在のセキュリティコンテキストに変換する。

図６は、現在の技術に従って、5G AKAを使用するときの部分的なセキュリティコンテキストを確立するための方法を示す。図６は、現在の技術にかかる、5G AKAを使用するときの部分的なセキュリティコンテキストを確立するための方法を示す。

図６は、以下のステップを含む。
１．UEは、registration requestメッセージをモバイルネットワーク内のSEAFに送信する。UEは、registration requestメッセージに、以下を含める：
－Subscription Permanent Identifier （SUPI）から計算されたSubscription Concealed Identifier （SUCI）及びUEに記憶されているホームネットワーク公開鍵、又は：
－ネットワークにより実行された以前の認証及び鍵合意の後、UEに提供された5G一時識別子。

２．（Optional）SEAFは、UEからregistration request又はinitial NASメッセージを受信すると、一時識別子を知っているかどうかを判定する。一時識別子が含まれているが、SEAFに知られていない場合、SEAFは、identification手順を開始し、identity requestメッセージをUEに送信する。

３．（Optional）UEが、identity requestメッセージを受信する場合、UEは、SUCIを含むidentity responseでSEAF／AMFに応答する。

４．identity responseメッセージを受信すると、SEAFは、SUCI及びサービングネットワーク名を含むauthentication requestメッセージをAUSFに送信することにより、認証を開始する。5Gでは、この要求は、Nausf_UE_Authentication Authenticate Requestと呼ばれる。

５．authentication requestメッセージの受信後、AUSFは、UDMに、認証ベクトルの要求を示すauthentication vector requestメッセージを送信する。AUSFは、SUCI及びサービングネットワーク名を、この要求に含める。5Gでは、この要求は、Nudm_UEAuthentication_Get Requestと呼ばれる。

６．authentication vector requestメッセージの受信後、UDMは、使用する認証方法（EAP AKA'又は5G AKA）を決定し、認証ベクトルを生成し、それをAUSFに送信する。認証ベクトルは、5G AKA'の場合、RAND、AUTN、XRES*、K_AUSFを含み、XRES*は、暗号化ハッシュ関数を用いて、XRES、サービングネットワーク名、及びRANDから計算され、AUSFへの応答で、認証ベクトル及びSUPIが送信される。5Gでは、このメッセージは、Nudm_UEAuthentication_Get Responseである。

ステップＢにおいて、認証ベクトルを受信した後、AUSFは、現在の技術に従ってK_AUSFを記憶し又は上書きする。

７．認証ベクトルを受信した後、AUSFは、XRES*からHXRES*を計算し、K_AUSFからK_SEAFを計算することにより、新しい認証ベクトルを生成する。HXRES*は、ハッシュ及びXRES*を入力の１つとして使用して計算される。AUSFは、HXRES*、K_SEAF、AUTN及びRESをSEAFに送信する。5Gでは、新しい認証ベクトルは、Nausf_UEAuthentication_Authenticate Responseを使用してSEAFに返される。

８．SEAFは、認証ベクトルを受信し、RAND及びAUTNを抽出し、これらの値をメッセージでUEに送信する。SEAFには、ngKSI及びABBAパラメータも含まれているため、認証が成功した後、UEはK_AMFを導出できる。5Gでは、このメッセージは、authentication requestと呼ばれる。

ステップＡにおいて、UEは、AUTNを検証し、成功した場合、USIMに格納されたRES及びKを使用し、CK及びIKを計算し、CK及びIKから、K_AUSF、K_SEAF及びK_AMFを計算する。UEは、K_AUSF、K_SEAF、K_AMF及びngKSIが格納された、非現在のセキュリティコンテキストを生成する。UEはまた、入力として、RES、RAND、CK、IK及びサービングネットワーク名を入力として鍵導出関数（key derivation function）を使用してRES*を計算する。結果のRES*は、SEAFに返される。

９．UEは、RES*をSEAFに返す。5Gでは、このメッセージは、Authentication Responseメッセージである。

１０．RES*を受信すると、SEAFは、HRES*を計算し、HXRES*と比較する。２つの値が一致する場合、SEAFは、RES*をAUSFに転送する。5Gでは、SEAFが使用するメッセージは、Nausf_UEAuthenticationAuthenticate Requestメッセージである。

１１．応答が成功した場合、AUSFは、認証が成功したことをSEAFに示す。AUSFはまた、SUPI及びK_SEAFを同じメッセージでSEAFに送信する。5Gでは、メッセージNausf_UEAuthentication_Authenticate Responseがこのメッセージに使用される。

１２．成功指示（success indication）を受信すると、SEAFは、成功メッセージの受信後、K_AMFを計算し、K_AMF及びSUPIをAMFに転送する。

本開示は、上記の問題を考慮して、様々な問題のうちの少なくとも１つを解決するための解決策を提供することを目的としている。

以下は、主題の実施形態のいくつかの態様の基本的な理解を提供するために、主題の簡略化された要約を示す。この要約は、主題の広範な概要ではない。実施形態の重要なキー／重要な要素を特定すること、又は主題のスコープを説明することを意図したものではない。

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

本開示の第１の態様では、端末が提供され、当該端末は、メモリと、サードパーティサービスのために、前記端末と、5Gにおけるネットワークとの間のプライマリ認証（primary authentication）を実行し、セキュリティ鍵K_AUSFを導出し、前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備える。

本開示の第２の態様では、方法が提供され、当該方法は、サードパーティサービスのために、端末と、5Gにおけるネットワークとの間のプライマリ認証を実行すること、セキュリティ鍵K_AUSFを導出すること、及び前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出すること、を含む。

本開示の第３の態様では、5Gにおけるネットワークに使用されるコアネットワーク装置が提供され、当該コアネットワーク装置は、メモリと、サードパーティサービスのために、端末と、前記ネットワークとの間のプライマリ認証を実行し、セキュリティ鍵K_AUSFを導出し、前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備える。

本主題の前述及びさらなる目的、特徴及び利点は、添付の図面を参照して例示的な実施形態の以下の説明から明らかになるであろう。添付の図面は、同様の番号が、同様の要素を表すために使用される。

ただし、参照番号とともに添付の図面は、本主題の典型的な実施形態のみを示しており、したがって、その範囲を限定するものとみなされるべきではなく、本主題が、他の同様に有効な実施形態を許容し得ることに留意されたい。

図１は、非特許文献１に開示されている参考資料にかかる、１つのAKA及び1つのNAS SMCのみに存在する問題を示す。

図２は、非特許文献１に定義されている鍵階層を示す。

図３は、非特許文献１に定義されている鍵導出の入力を伴う鍵階層を示す。

図４は、非特許文献１におけるNAS secure mode command手順を示す。

図５は、現在の技術にかかるEAP AKA'のための認証及び鍵合意手順を示す。

図６は、現在の技術にかかる5G AKAのための認証及び鍵合意手順を示す。

図７は、本開示の実施形態にかかるK_SEAFの識別子を生成するためのSEAFのプロセスを示す。

図８は、本開示の実施形態にかかる、認証を完了としてマークするプロセスを示している。

図９は、本開示の実施形態にかかる、UEによる鍵のステータスを変更するプロセスを示す。

図１０は、本開示の実施形態にかかる、K_AUSFを使用するためのネットワーク開始手順（network initiated procedure）を示す。

図１１は、本開示の実施形態にかかるK_AUSFを使用するためのUE開始手順（UE initiated procedure）を示す。

図１２は、本開示にかかるユーザ装置のブロック図を示す。

図１３は、本開示にかかる(R)ANノードのブロック図を示す。

図１４は、本開示にかかるコアネットワークノードのブロック図を示す。

本開示の実施形態によれば、ホームネットワーク鍵の同期のための方法が開示され、これは、現在の、非現在の、及び一時的なセキュリティコンテキストのために、K_AUSFをK_AUSF識別子とともに、UEの内部に記憶し、K_AUSFをK_AUSF識別子とともに、ネットワークの内部に記憶し、AUSFにより、複数のK_AUSF'を記憶することを含む。

本開示の実施形態によれば、K_AUSFの使用は、どのK_AUSFが使用されるのかが分かるように、メッセージに、K_AUSFの識別子を含める。

本開示の実施形態によれば、使用に基づいて、鍵がメモリから削除されてもよい。

さらに、本開示の実施形態によれば、方法は、UEと、AUSF及び／又はSEAFとの両方において、鍵自体からK_AUSF及びK_SEAFの識別子を計算すること、及びK_AUSF及びK_SEAFとともに上記識別子を記憶することを含む。

しかし、本開示の他の実施形態では、方法は、複数の識別子及び鍵を記憶すること、及び導出された各鍵のステータスを保持することを含む。

本開示の実施形態では、どの鍵が削除されるべきかが決定される基準（criterion basis）のセットがある。

本開示の実施形態では、サービングネットワークは、UE内のK_AUSFと、AUSF内のK_AUSFとの間の同期エラーを引き起こす。

本開示の実施形態では、K_AUSFは、AUSFと、UEとの間の情報交換を保護又は暗号化する。

本開示の実施形態では、AUSF及びSEAFは、UEにより参照される鍵、例えば、特定のアプリケーションのための鍵、又はさらなる鍵を導出するために後の手順で使用されるブートストラッピング鍵（bootstrapping key）を記憶する。

本開示の実施形態では、UEが開示され、当該UEは、１つ又は複数のアンテナを介して、接続されたノードに信号を送信し、接続されたノードから信号を受信するように動作可能なトランシーバ回路を含む。

本開示の実施形態では、(R)ANノードが開示され、当該(R)ANノードは、１つ又は複数のアンテナを介して、接続されたUEに信号を送信し、接続されたUEから信号を受信し、ネットワークインタフェースを介して、（直接的に又は間接的に）他のネットワークノードに信号を送信し、他のネットワークノードから信号を受信するように動作可能なトランシーバ回路と、メモリに従って(R)ANノードの動作を制御するコントローラとを備える。

本開示の実施形態では、コアネットワークが開示され、コアネットワークノードは、ネットワークインタフェースを介して、（UEを含む）他のノードに信号を送信し、他のノードから信号を受信するように動作可能なトランシーバ回路を備える。コントローラは、メモリに格納されたソフトウェアに従って、コアネットワークノードの動作を制御する。

本開示の実施形態では、コアネットワークノードは、AMF、SMF、SEAF、AUSF、UPF、UDM、ARPF、SIDF、PCF、AF等のうちの少なくとも１つである。

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

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

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

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

本明細書で使用される場合、単数形「a」、「an」及び「the」は、特に明記しない限り、複数形も含むことを意図している。本明細書で使用される場合、用語「含む（includes）」、「含む（comprises）」、「含む（including）」及び／又は「含む（comprising）」は、記載された特徴、整数、ステップ、動作、要素、及び／又は、コンポーネントの存在を指定するが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらのグループの存在又は追加を排除するものではないことをさらに理解すべきである。要素が他の要素に「接続されている（connected）」又は「結合されている（coupled）」と称される場合、それは、他の要素に直接接続又は結合されてもよく、あるいは介在する要素が存在してもよいことが理解されるであろう。さらに、本明細書で使用される「接続されている（connected）」又は「結合されている（coupled）」は、動作可能に接続又は結合されていることを含み得る。本明細書で使用される場合、用語「及び／又は（and/or）」は、１つ又は複数の関連する列挙された項目の任意の組み合わせ、及び全ての組み合わせ、並びに配列（配置）を含む。

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

図は、いくつかの要素及び機能的なエンティティのみを示す簡略化された構造を示している。これらは全て、示されているものとは実装が異なる可能性がある論理ユニットである。構造が、他の機能及び構造も含み得ることは、当業者には明らかである。

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

本出願のこの実施形態の中心的なアイディアは、UEと、AUSF及び／又はSEAFとの両方の鍵自体からK_AUSF及びK_SEAFの識別子を計算し、この識別子をK_AUSF及びK_SEAFとともに記憶することである。この実施形態は、以下のように機能する。

ここでのステップは図５を参照する。認証されているUEは、IMSI1に対応していると仮定する。次の手順が実行される。

ステップ１～８は、図５と同じであり、図５の説明を参照する。ステップＡにおいて、UEは、以下を実行する。
ステップＡにおいて、一時的なセキュリティコンテキストを生成することに加えて、UEは、以下のように、鍵導出関数を使用することにより、K_AUSFの識別子も生成する：
－KI_AUSF = KDF(K_AUSF, "KI")、及び
－KI_SEAF = KDF(K_SEAF, "KI")、
ここで、KIは、鍵識別子（Key Identifier）を表し、下付き文字（subscript）は、どの鍵が使用されるのかを表し、KDFは鍵導出関数を表す。「KI」入力テキストは、文字列であるが、数字の場合もある。RAND、RES、サービングネットワーク名等の追加の値も、鍵導出関数に含めることができる。UEは、このKI及び鍵のペアを別々に記憶する。この記憶において（in this storage）、UEは、これらの鍵が、まだ完了していない認証実行の結果であるとマークし得る。UEはまた、鍵が導出されたときのタイムスタンプを記憶してもよい（表１には不図示）。この時点において鍵のストレージ（storage of the keys）は、次のようになる：

ステップ９及び１０は、図５と同じである。ステップＢにおいて、AUSFは、次を実行する。
ステップＢにおいて、AUSFは、次のように鍵導出関数を使用することにより、K_AUSFの識別子を生成することから開始する：
－KI_AUSF = KDF(K_AUSF, "KI")
ここで、KIは、鍵識別子を表し、下付き文字は、どの鍵が使用されるのかを表し、KDFは鍵導出関数を表す。「KI」入力テキストは、文字列であるが、数字の場合もある。RAND、RES、サービングネットワーク名等の追加の値も、鍵導出関数に含めることができる。AUSFは、このKI及び鍵のペアを一緒にストレージに記憶する。この記憶において（in this storage）、AUSFは、これらの鍵が、後続の手順において使用されるのか又は使用されないのかをマークしてもよい。AUSFはまた、鍵が導出されたときのタイムスタンプを記憶してもよい（表２に不図示）。この時点での鍵のストレージ（storage of the keys）は次のようになる：

なお、AUSFは、IMSIの代わりにSUPIを識別子として使用できる。

ステップ１１は、図５と同じである。ステップ１１において、メッセージを受信した後、SEAFはまた、図７に示されるように、新しいステップＤにおいて、以下のように鍵のストレージ（storage of the keys）を生成してもよい。図７は、本開示の実施形態にかかる、K_SEAFの識別子を生成するためのSEAFのプロセスを示す。
ステップＤにおいて、SEAFは、次のように鍵導出関数を使用することにより、K_SEAFの識別子を生成する：
－KI_SEAF = KDF(K_SEAF, "KI")
ここで、KIは、鍵識別子を表し、下付き文字は、どの鍵が使用されるのかを表し、KDFは鍵導出関数を表す。「KI」入力テキストは、文字列であるが、数字の場合もある。RAND、RES、サービングネットワーク名等の追加の値も、鍵導出関数に含めることができる。SEAFは、このKI及び鍵のペアを一緒にストレージに記憶する。この記憶において（in this storage）、SEAFは、EAP SuccessメッセージをUEに送信することにより、認証が完了したのかどうかをマークし得る。SEAFはまた、鍵が導出されたときのタイムスタンプを記憶してもよい（表３に不図示）。この時点での鍵のストレージ（storage of the keys）は、次のようになる：

なお、SEAFは、最初に「認証完了（Authentication Completed）」フィールドを「No」に設定し、EAP Successを送信した後に、それを「Yes」に変更することもできる。また、IMSIの代わりに、SEAFは、SUPIを、UE識別子として使用できる。

ステップ１２は、図５と同じである。SEAFが、EAP Successメッセージを送信する場合、UEは、ステップＣにおいて、以下のアクションを実行する。
ステップＣにおいて、一時的なセキュリティコンテキストを、非現在のセキュリティコンテキストに変換することに加えて、UEはまた、認証結果を「完了（completed）」に変更することにより、ストレージ内の鍵のステータスを変更する。ここで、単一の認証が実行される場合、ストレージは次のようになる：

ステップは、図６のステップを参照する。認証されているUEはIMSI1に対応していると仮定する。次のステップが実行される：
ステップ１～６は同じである。ステップＢにおいて、AUSFは以下を実行する。
ステップＢにおいて、AUSFは、次のように鍵導出関数を使用することにより、K_AUSFの識別子を生成することから開始する：
－KI_AUSF = KDF（K_AUSF、 "KI"）
ここで、KIは鍵識別子を表し、下付き文字は、それが使用される鍵を示し、KDFは鍵導出関数を表す。「KI」入力テキストは、文字列であるが、数字の場合もあり得る。RAND、RES、サービングネットワーク名等の追加の値も、鍵導出関数に含めることができる。AUSFは、このKI及び鍵のペアを一緒にストレージに記憶する。この記憶において（in this storage）、AUSFはまた、認証が完了したかどうかをマークし得る。AUSFは、鍵が以前の手順で使用されたかどうかもマークし得る。また、AUSFは、鍵が導出されたときのタイムスタンプを記憶してもよい（表５には不図示）。この時点での鍵のストレージ（storage of the keys）は、次のようになる：

なお、AUSFはまた、IMSIの代わりにSUPIを識別子として使用できる。

ステップ７及び８は、図６と同じであり、図６の説明を参照する。ステップＡにおいて、UEは、以下を実行する。
ステップＡにおいて、非現在のセキュリティコンテキストを生成することに加えて、UEは、次のように、鍵導出関数を使用することにより、K_AUSFの識別子も生成する：
－KI_AUSF = KDF(K_AUSF, "KI")、及び
－KI_SEAF = KDF(K_SEAF, "KI")、
ここで、KIは鍵識別子を表し、下付き文字はそれが使用される鍵を示し、KDFは鍵導出関数を表す。「KI」入力テキストは、文字列であるが、数字の場合もあり得る。RAND、RES、サービングネットワーク名等の追加の値も、鍵導出関数に含めることができる。UEは、このKI及び鍵のペアを別々に記憶する。この記憶において（in this storage）、UEはまた、これらの鍵が非現在のセキュリティコンテキストの一部であるか、又は現在のセキュリティコンテキストの一部であるかどうかをマークしてもよい。また、UEは、鍵が導出されたときのタイムスタンプを保存してもよい（表６には不図示）。5G AKAは、UEへのauthentication resultメッセージがないため、認証結果を表に取り込む（captured）ことはできない。この時点での鍵のストレージ（storage of the keys）は、以下のようになる：

なお、5G AKAにおいて、認証を完了するために新しいメッセ－ジが導入される場合、UEは、authenticationメッセージのステータスをマークすることも出来る。

ステップ９及び１０は、図６と同じである。ステップ１０の後、図８に従って新しいステップＥが導入される。図８は、本開示の実施形態にかかる、認証を完了としてマーキングするプロセスを示す。AUSFは、このステップにおいて以下を実行する。
ステップＥにおいて、ステップ１０でメッセージを受信した後、AUSFは、認証が完了したことを認識し、したがって、AUSFは、K_AUSF認証を完了としてマークする。IMSI1に対して、認証が完了されたと仮定すると、結果テーブルは、次のように変更される：

なお、AUSFは、ステップＢをスキップして、成功した認証のみをテーブルに記録することもできる。または、K_AUSFを一時的に記憶し、認証が完了した後で、このテーブルに移動することもできる。

ステップ１１は、図６と同じである。ステップ１１でメッセージを受信した後、SEAFはまた、図７に従って新しいステップＤにおいて、以下のように鍵のストレージ（storage of the keys）を生成してもよい。
ステップＤにおいて、SEAFは、次のように、鍵導出関数を使用することにより、K_SEAFの識別子を生成する：
-KI_SEAF = KDF(K_SEAF, "KI")
ここで、KIは、鍵識別子を表し、下付き文字は、どの鍵が使用されたのかを表し、KDFは、鍵導出関数を表す。「KI」入力テキストは、文字列であるが、数字の場合もあり得る。RAND、RES、サービングネットワーク名等の追加の値も、鍵導出関数に含めることができる。SEAFは、このKI及び鍵のペアを一緒にストレージに記憶する。SEAFはまた、鍵が導出されたときのタイムスタンプを記憶してもよい（表８には不図示）。この記憶において（in this storage）、SEAFは、EAP Successメッセージが送信されないため、認証が完了したのかどうかをマークできない。ただし、SEAFがNAS SMCの送信について何らかの方法で通知された場合（例えば、AMF及びSEAFがコロケートされている等により）、鍵が使用されたかどうかをマークできる。

IMSIに代えて、SEAFはまた、UE識別子として、SUPIを使用することもできる。

5G AKAの認証及び鍵合意は、ステップ１１の後に終了する。ただし、UEが、（図９においてステップ１３として与えられる）secure mode commandメッセージを受信する場合、UEは、ステップＦを実行できる。図９は、本開示の実施形態にかかる、UEによる鍵のステータスを変更するプロセスを示す。
ステップＦにおいて、UEは、非現在のセキュリティコンテキストを、現在のセキュリティコンテキストに変換する。同時に、UEはまた、セキュリティコンテキストステータスを「current」に変更することにより、ストレージにある鍵のステータスを変更する。単一の認証実行の場合、ストレージは次のようになる。

これに従って、UE、AUSF及びSEAFは、それぞれ、ステップＡ、Ｂ及びＤで鍵の識別子を計算する。（EAP AKA'及び5G AKAの両方に対して）異なるバリエーションが可能である。このバリエーションでは、KIの計算は、省略され、ステップ８において、SEAFが既にUEに送信した、既存のngKSIを使用することにより置き換えられる。これは、上述したステップに対して以下の変更が必要である。
－ステップＡ：UEは、KIの計算を省略し、代わりに、UEは、K_SEAF及びK_AUSFの両方に対して、ngKSIをKIとして使用し、K_AUSF及びK_SEAFと一緒にngKSIを記憶する。K_SEAFを計算するとき、UEは、計算にngKSIも含める。つまり、K_SEAFは、ngKSI及び他のパラメータにバインド（bound）される。例えば次のようになる：
K_SEAF = KDF(serving network name, ngKSI, K_AUSF, …)、
ここで、KDFは、暗号化ハッシュであり、K_AUSFは、入力鍵として使用される。他のパラメータは、数値又はテキスト等の定数値が含まれる。
5G AKAの場合、UEは、RES*をngKSIにバインドする（bind）ために、RES*計算において、ngKSIを含めることもできる。
－5G AKA：ステップＢ：AUSFは、KIを計算しない。
－ステップ１０：SEAFは、追加的に、AUSFへのメッセージに、UEに既に送信したngKSIを含める。
－5G AKA：ステップＥ：AUSFは、ngKSIを受信し、次を行う。
AUSFは、受信したngKSIを使用してXRES*を計算し、それが一致するかどうかを検証する。それが一致する場合、AUSFは、UEがRES*に同一のngKSIを含めたことを知る。
AUSFは、対応するngKSIが既にあるのかどうかを確認する。そうである場合、ngKSIが複製されると、UEは、それを受け入れないため、その鍵に削除のマークを付けることができる。
AUSFは、K_SEAFを計算するときに使用されるUEと同じ鍵導出関数及び入力を使用して、ngKSIを含むK_SEAFを計算する。つまり：
K_SEAF = KDF(serving network name, ngKSI, K_AUSF, …)、
ここで、KDFは、暗号化ハッシュであり、K_AUSFは、入力鍵として使用される。他のパラメータは、数値又はテキスト等の定数値を含む。
次に、AUSFは、ステップＢで行ったように、ngKSIをKIとして記憶する。
－EAP AKA'：ステップＢ：AUSFは、ngKSIを受信し、以下を行う。
AUSFは、KIの計算を省略する。代わりに、AUSFは、KIを、受信されたngKSIと等しく設定し、説明したステップＢに従って記憶する。
AUSFは、K_SEAFを計算するときに使用されたUEと同じ鍵導出関数及び入力を使用して、ngKSIを含むK_SEAFを計算する。つまり：
K_SEAF = KDF(serving network name, ngKSI, K_AUSF, …)、
ここで、KDFは、暗号化ハッシュであり、K_AUSFは、入力鍵である。他のパラメータは、数値又はテキスト等の定数値を含む。
このK_SEAFは、ステップ１１において、SEAFに返される。
－ステップＤ：SEAFは、KIを、ngKSIと等しく設定し、説明したように、ストレージに、KI及びK_SEAFを記憶する。

このバリエーションの利点は、KIを計算する必要がないことである。また、ngKSIを使用することにより、K_SEAF及びK_AUSFは、セキュリティコンテキストで使用されるものと同じ識別子を使用できる。これにより、どの鍵が、どのセキュリティコンテキストに対応するのかが常に明確になる。

第２の実施形態によれば、複数の識別子及び鍵が記憶され、導出された各鍵のステータスが保持される。

ステップは、図５におけるステップを参照する。この実施形態では、前述した実施形態が既に実行され、AUSF、SEAF及びUEが、前述した実施形態に従って、鍵及び鍵識別子のストレージ（storage）を生成していると仮定する。この実施形態では、IMSI1を有するUEは、認証されているUEであると仮定する。

この場合、ステップ１～８は、図５と同じであり、図５の説明を参照する。ステップＡにおいて、UEは、さらに以下を行う。
ステップＡにおいて、一時的なセキュリティコンテキストを生成することに加えて、UEは、前述した実施形態で説明したように使用することによりK_AUSFの識別子も生成する。UEは、このKI及び鍵のペアを鍵のストレージ（storage of the keys）に加えて、前述した実施形態に従って、それらの認証結果でそれらをマークする。この時点での鍵のストレージ（storage of the keys）は次のようになる。この場合、下付き文字２の鍵がストレージに追加される。

ステップ９及び１０は、図５と同じである。ステップＢにおいて、AUSFは、以下を行う。
ステップＢにおいて、AUSFは、前述した実施形態に従って、鍵導出関数を使用することにより、K_AUSFの識別子を生成することから開始する。AUSFは、このKI及び鍵のペアをストレージに一緒に追加し、それらが使用されたか否かをマークしてもよい。この時点での鍵のストレージ（storage of the keys）は次のようになる。表１１に示されるように、IMSI1のための新しい行が追加される。

なお、AUSFはまた、識別子として、IMSIの代わりにSUPIを使用することができる。

ステップ１１は、図５と同じである。ステップ１１でメッセージの受信後、SEAFはまた、図７に示すように、ステップＤにおいて、鍵及びKIのペアを鍵のストレージ（storage of the keys）に追加してもよい。
ステップＤにおいて、SEAFは、前述した実施形態にしたがってK_SEAFの識別子を生成する。SEAFは、このKI及び鍵のペアをストレージに一緒に追加し、UEにEAP Successメッセージを送信することにより、認証が完了したかどうかをマークしてもよい。この時点での鍵のストレージ（storage of the keys）は次のようになる。表１２に示されるように、IMSI1のための新しい行が追加される。

なお、SEAFは、最初に、認証完了（Authentication Completed）フィールドに「No」を設定し、EAP Successを送信した後、「Yes」に変更してもよい。IMSIの代わりに、SEAFは、UE識別子として、SUPIを使用することもできる。

ステップ１２は、図５と同じである。SEAFが、EAP Successメッセージを送信する場合、UEは、ステップＣにおいて、以下のアクションを行う。
ステップＣにおいて、一時的なセキュリティコンテキストを、非現在のセキュリティコンテキストに変換することに加えて、UEはまた、認証結果を「完了（completed）」に変更することにより、この認証実行においてストレージにある鍵のステータスを変更する。この認証実行の後、ストレージは次のようになる。

ステップは、図６におけるステップを参照する。この実施形態では、前述した実施形態が既に実行されており、AUSF、SEAF及びUEが、前述した実施形態に従った、鍵及び鍵識別子のストレージ（storage）を生成していると仮定する。IMSI1を有するUEは、認証されているUEであると仮定する。

ステップ１～６は、図６と同じである。ステップＢにおいて、AUSFは以下を行う。
ステップＢにおいて、AUSFは、前述した実施形態に従って、K_AUSFの識別子を生成することから開始する。AUSFは、このKI及び鍵のペアをストレージに追加し、認証が完了したかどうか、及び／又は、前の手順において鍵が使用されたかどうかをマークしてもよい。鍵のストレージ（storage of the keys）は次のようになる。表１４に示されるように、IMSI1の行が追加される。

AUSFは、識別子として、IMSIの代わりにSUPIを使用することもできる。

ステップ７及び８は、図６と同じであり、図６の説明を参照する。ステップＡにおいて、UEは以下を行う。
ステップＡにおいて、前述した実施形態に従って、UEは、K_SEAF及びK_AUSFのそれぞれに対して、１つのKIを生成し、これをストレージに追加する。UEはまた、これらの鍵が、非現在のセキュリティコンテキストの一部であること、又はそれらが、現在のセキュリティコンテキストの一部であるのかどうかをマークしてもよい。5G AKAは、UEへのauthentication resultメッセージがないため、認証結果を表に取り込む（captured）ことはできない。この時点での鍵のストレージ（storage of the keys）は、次のようになる。表１５に示されるように、２つの行が追加される。前述した実施形態と比較して、前の鍵が使用されたと仮定する。

5G AKAにおいて、認証を完了するために、新しいメッセージが導入される場合、UEは、authenticationメッセージのステータスをマークすることもできる。

ステップ９及び１０は、図６と同じである。ステップ１０の後、図８に従って新しいステップＥが導入される。
ステップＥにおいて、ステップ１０でメッセージの受信後、AUSFは、認証が完了したことを認識し、したがって、AUSFは、K_AUSF認証を完了としてマークする。IMSI1に対して、認証が実行されたと仮定すると、結果テーブルは以下のように変更される。

なお、AUSFは、ステップＢをスキップし、成功した認証のみを表に記録することもできる。または、K_AUSFを一時的に保存し、認証が成功した後で、この表に移動する。

ステップ１１は、図６と同じである。ステップ１１でメッセージの受信後、SEAFはまた、図７に従って、新しいステップＤにおいて、以下のように、鍵のストレージ（storage of the keys）を生成してもよい。
ステップＤにおいて、SEAFは、前述した実施形態に従ってK_SEAFの識別子を生成し、KI及びK_SEAFのこの新しいペアをストレージに追加する。この記憶では（in this storage）、SEAFは、EAP Successメッセージが送信されないため、認証を完了したのかどうかをマークできない。ただし、SEAFが何らかの方法でNAS SMCの送信について通知された場合(例えば、AMF及びSEAFがコロケートされている等により)、鍵が使用されたかどうかをマークできる。新しいテーブルは次のようになる。表１７に示されるように、IMSI1のための行が追加される。

IMSIの代わりに、SEAFは、UE識別子として、SUPIを使用することもできる。

5G AKAのための認証及び鍵合意は、ステップ１１の後、終了する。ただし、UEが、（図９においてステップ１３として与えられる）secure mode commandメッセージを受信する場合、UEは、ステップＦを実行できる。
ステップＦにおいて、UEは、非現在のセキュリティコンテキストを、現在のセキュリティコンテキストに変換する。同時に、UEはまた、セキュリティコンテキストのステータスを「current」に変更することにより、ストレージ内の鍵のステータスを変更する。単一の認証実行の場合、ストレージは次のようになる。

鍵が削除されない場合、多くの鍵が記憶されることに留意すべきである。しかし、削除する鍵を決定するためには、いくつかの決定を行う必要がある。決定のリストは以下の通りである。

EAP AKA'では、（5Gでの認証から生成される（resulting））ネイティブセキュリティコンテキスト（native security context）は、次のステータスを有することができる。
－Current：セキュリティコンテキストが使用されている。
－Non-current：セキュリティコンテキストは、まだ使用されていない。
－Temporary：認証が完了していない。

各セキュリティコンテキストについて、UEは、対応するK_AUSF及びK_SEAFを有している。良好な状態を維持するために、UEは、以下のように鍵の削除を処理できる（handle）。
－（図９のステップＦのように）一時的なセキュリティコンテキストを使用するNAS SMCメッセージの受信時、又はEAP Successメッセージの受信時（図５のステップＣ）、UEは、認証が完了したことを認識する。UEは、現在のセキュリティコンテキストに対応するものを含む、任意の古い鍵を削除できる。
－UEが、タイムアウトにより一時的なセキュリティコンテキストを削除する場合、UEは、K_AUSF及びK_SEAFを削除せずに、メモリに保持する。他の認証実行が新しい一時的なセキュリティコンテキストをもたらす場合、UEは、前述した実施形態で説明したように、削除された一時的なセキュリティコンテキストに対応するK_AUSF及びK_SEAFを削除し、新しいK_AUSF及びK_SEAFを記憶する。

AUSFにおいて、以下のように決定される。
－AUSFは、UE毎に少なくとも２つの鍵、すなわち、次の２つを記憶する。
－authenticate resultメッセージ（ステップＢ）により示される、認証の成功から生じた最新のもの。
－認証の成功から生じた２番目に新しいもの。
－任意の古い鍵がメモリから削除される。

SEAFにおいて、以下のように決定される。
－SEAFは、UE毎に少なくとも２つの鍵を削除し、記憶する。すなわち、以下の通りである：
－認証の成功の結果である最新の２つの鍵（ステップＤ）。
－SEAFがEAP Successメッセージを送信する場合、任意の古い鍵を削除する。
－任意の古い鍵は、メモリから削除される。

5G AKAでは、（5Gでの認証から生成される（resulting））ネイティブセキュリティコンテキスト（native security context）は、次のステータスを有することができる。
－Current：セキュリティコンテキストが使用されている。
－Non-current：セキュリティコンテキストは、まだ使用されていない。

各セキュリティコンテキストに対して、UEは、対応するK_AUSF及びK_SEAFを有している。良好な状態を維持するために、UEは、以下のように鍵の削除を処理できる（handle）。
－非現在のセキュリティコンテキストを使用するNAS SMCメッセージの受信時（図９のステップＦ）、UEは、認証が成功したことを認識する。UEは、置き換えられる現在のセキュリティコンテキストに対応するものを含む、任意の古い鍵を削除できる。
－UEが、新しい認証により非現在のセキュリティコンテキストを上書きする場合、前の非現在のセキュリティコンテキストに関連するK_AUSF及びK_SEAFを削除する。

AUSFにおいて、次のように決定される。
－AUSFは、UE毎に少なくとも２つの鍵、すなわち、以下の２つを記憶する。
－authenticate resultメッセージ（ステップＥ）により示される、認証の成功から生じた最新のもの。
－認証の成功から生じた２番目に新しいもの。
－任意の古い鍵はメモリから削除される。

SEAFにおいて、以下のように決定される。
－SEAFは、UE毎に少なくとも２つの鍵、すなわち、以下のものを削除し、記憶する。
－認証の成功の結果である最新の２つ（ステップＤ）。
－又は、SEAFが、NAS SMCメッセージの送信について認識している場合、使用された最新のものも記憶する。
－任意の古い鍵はメモリから削除される。

前述した実施形態で行われたアクションに関わらず、サービングネットワークは、UE内のK_AUSFと、AUSF内のK_AUSFとの間の同期エラーを依然として引き起こす可能性がある。同様に、K_AUSF及びAUSFが使用される場合、SEAF及びK_SEAFも読み取ることができる。同じ問題が発生し、SEAF及びUEで、K_SEAFに関して同期外れ（out of sync）が発生する。

例えば、EAP-AKA'を使用する場合、サービングネットワークは以下の手順を実行できる。
１．完全なEAP AKA'を完了し、セキュリティコンテキスト（sc1）を使用する。AUSF及びUEの両方は、sc1に対応するK_AUSFを有する。
２．図５のステップ４において、SUCIの代わりにSUPIを含むメッセージを送信して新しいEAP AKA'手順を開始し、ステップ１１まで実行する。ステップ１１の後、SEAFは、authentication failedメッセージをUEに送信し、UEは、ステップＡで生成した一時的なセキュリティコンテキスト（sc2）を削除する。現在の状況は以下の通りである。
－AUSFは、sc1に対応するK_AUSF、及びsc2に対応するK_AUSFを有する。
－UEは、sc1に対応するK_AUSFを有する。
３．前のステップに従って、新しいEAP AKA'手順を開始し、ステップ１１まで実行する。ステップ１１の後、authentication failedメッセージをUEに送信し、UEは、ステップＡで生成した一時的なセキュリティコンテキスト（sc3）を削除する。現在の状況は以下の通りである。
－AUSFは、現在、sc1に対応するK_AUSFを削除し、sc2に対応する１つのK_AUSF及びsc3に対応する１つのK_AUSFを保持する。
－UEは、他の２つの認証が失敗したため、sc1に対応するK_AUSFを有する。

結果として、AUSF及びUEは、K_AUSFに関して同期外れ（out of sync）となる。

5G AKAを使用する場合、サービングネットワークは、以下のように、同じ状況を実現できる。
１．完全な5G AKAを完了し、セキュリティコンテキスト（sc1）を使用する。AUSF及びUEの両方は、現在、sc1に対応するK_AUSFを有する。
２．SUCIの代わりにSUPIを含む、図６のメッセージ４を送信することにより、新しい5G AKA手順を開始し、ステップ１１まで実行する。ステップ１１の後、SEAFは、authentication failedをUEに送信する。
－AUSFは、sc1に対応するK_AUSF、及びsc2に対応する１つのK_AUSFを有する。
－UEは、sc1に対応するK_AUSFを有する。
３．前の手順に従って新しい5G AKAを開始し、ステップ１１まで実行する。ステップ１１の後、SEAFは、authentication failedメッセージをUEに送信し、UEは、ステップＡで生成した一時的なセキュリティコンテキスト（sc3）を削除する。現在の状況は以下の通りである。
－AUSFは、現在、sc1に対応するK_AUSFを削除し、sc2に対応する１つのK_AUSF及びsc3に対応する１つのK_AUSFを保持する。
－UEは、他の２つの認証が失敗したため、sc1に対応するK_AUSFを有する。

結果として、AUSF及びUEは、K_AUSFに関して同期外れ（out of sync）となる。同様に、K_AUSF及びAUSFが使用される場合、SEAF及びK_SEAFも読み取ることができる。同じ問題が発生し、SEAF及びUEで、K_SEAFに関して同期外れ（out of sync）が発生する。

この新たな問題は、いくつかの変更を加えて前述した実施形態を使用することにより対処できる。このメカニズムを機能させるために、ネットワークへの各初期認証（initial authentication）がSUCIを使用して行われるという事実を使用する。UEは、図５及び図６のステップ１におけるメッセージ、又は図５及び図６のステップ３におけるメッセージのいずれかにSUCIを含める。SUCIは、特にSUPIを含むが、暗号化されたSubscription Concealed Identifierである。そのため、サービングネットワークは、ステップ１１でのみSUPIを学習する。これは、SUPIを含むホームネットワークにauthentication requestを送信することにより、サービングネットワークが任意の時点で認証を開始できるため、後続の認証とは異なる。

この事実を使用して、UE及びAUSFのストレージを以下のように変更する。
－UEは、SUCIが、この認証実行に使用されたかどうかを示すフラグを追加することにより、SUCIを使用する認証が成功した後に、K_AUSFが取得されたかどうかを追加で記憶する。これは次のようになる。

UEが同じネットワークに接続されている限り、UEは、SUCIを使用した認証から生じた、この鍵を削除しない。UEは、ステップＡ又はステップＦにおいて、このフラグを追加する。どちらのオプションでも同じテーブルになる。認証にSUCIを使用せずに、追加される新しい鍵の場合、UEはフラグをnoに設定する。フラグがyesに設定されている鍵は、SUCIを使用した新しい認証が実行されるか、又はUEが新しいネットワークにアタッチする場合にのみ削除される。

－AUSFは、UEと同様に、SUCIを使用した認証の成功後にK_AUSFが得られたかどうかを記憶する。ステップ４において、AUSFは、SUPI又はSUCIが認証に使用されたかどうかを学習するため、AUSFは、これがネットワークに対する最初の認証であるかどうかを認識する。あるいは、AUSFは、テーブルにPLMN IDを追加し、UEが現在新しいネットワークに対して認証されているかどうかを確認してもよい。

新しいauthentication requestsが同じネットワークから送信され続ける限り、AUSFは、SUCIを使用した認証に関連するK_AUSFを保持する。新しいSUCIが使用されるか、又はUEが（authentication requestメッセージ４が異なるネットワークから送信されるため観察される）新しいネットワークにアタッチすると、AUSFは、ネットワークに対する最初の認証に関連付けられたK_AUSFを削除できる。

この実施形態では、K_AUSFのKIは、認証実行で使用されたSUCIと等しく設定することもでき、又はKIの導出にK_AUSFに加えてSUCIを含めることもできる。同様に、K_SEAFのKIは、SUCIと等しく設定することもでき、又はSUCI及び／又はK_SEAFから導出することもできる。これは、UE、SEAF及びAUSFのストレージに、参照するそれぞれの鍵からのみ導出されるKIではなく、SUCIである（SUCIから導出された）KIが含まれることを意味する。

非特許文献１では、AUSFとUEとの間の情報交換を完全に保護又は暗号化するために、K_AUSFを使用する２つの手順がある。これらの手順は以下の通りである：
－６．１４．２．１項及び６．１４．２．２項によるローミングのステアリング（Steering of Roaming）。
－６．１５．２．１項に従うUEパラメータ更新。
これらの手順は両方ともネットワークで開始される。

現在の技術では、これらの手順の両方が同じ方法を使用して、それぞれのカウンタ及びそれぞれの鍵を、使用のために初期化する。すなわち、サービスに関連付けられたカウンタは、K_AUSFが導出されるたびに０に設定される。そのため、各サービスで使用できるカウンタは１つだけであり、このカウンタはK_AUSFではなくサービスに関連付けられている。

本開示で開示される方法を使用するために、カウンタは、（サービスに関連付けられたカウンタの代わりに）使用されるK_AUSFに関連付けられる。図５及び図６を参照すると、以下は、図５及び図６の様々なステップで起こる（例えば、ローミングのステアリング（Steering of Roaming）の場合）。

ステップＢにおいて、AUSFは、新しいK_AUSFを導出し、この時点でローミングのステアリングのカウンタも設定する。このカウンタは、0に初期化される。さらに、AUSFは、このカウンタをK_AUSFと一緒に記憶する。したがって、ストレージは、鍵識別子及び鍵に加えてカウンタも含む。

ステップＡにおいて、UEは、新しいK_AUSFを導出し、この時点でローミングのステアリングのカウンタも設定する。このカウンタは、０に初期化される。さらに、UEは、このカウンタをK_AUSFと一緒に記憶する。したがって、ストレージは、鍵識別子及び鍵に加えてカウンタも含む。

同じステップにおけるUEパラメータ更新（UE Parameters Update）の場合、UEパラメータ更新に関連付けられるカウンタも初期化され、カウンタと一緒に記憶される。

UE又はAUSFにおいて、K_AUSFがストレージから削除されるたびに、UE又はAUSFは、このK_AUSFに関連付けられたカウンタも削除する。

鍵が使用される場合、図１０に示されるように以下の手順に従う。図１０は、本開示の実施形態にかかるK_AUSFを使用するネットワーク開始手順を示す。
ステップ２１において、AUSFは、K_AUSFを使用してセキュリティ保護されるメッセージを受信する。AUSFは、最初に、UEに関連付けられたK_AUSFの１つを、関連付けられたカウンタとともにメモリから取得する（retrieve）。そして、AUSFは、非特許文献１に規定された手順に従う。AUSFは、K_AUSF、手順に関連付けられたカウンタ、及びメッセージの平文の内容（plain text content）を使用して暗号化ハッシュを計算する。さらに、AUSFはまた、UEがどの鍵が使用されたかを特定できるようにメッセージにKIを含める。AUSFは、保護される平文（plain text）、カウンタ値、KI、並びに平文、カウンタ、KI及びK_AUSFから導出された暗号化ハッシュを含むメッセージを構成する。

ステップ２２において、平文（plain text）、KI、カウンタ及び暗号化ハッシュを含むメッセージが、例えば、NAS DLトランスポートを使用して、UEに転送される。

ステップ２３において、UEはメッセージを受信する。メッセージに含まれるKIに基づいて、UEは、鍵ストレージ（key storage）にあるKIに関連付けられたK_AUSFを検索する。UEが、一致するKIを見つける場合、UEは、メモリから、K_AUSF及びそれぞれのカウンタを取得する。次に、UEは、取得したK_AUSFを使用して、平文のメッセージ内容（plain text message content）、メッセージ内のカウンタ、KI及びK_AUSFを使用する暗号化ハッシュを検証する。次に、UEは、メッセージ内のカウンタ値が、ストレージからのカウンタ値以上であるかを比較する。そうであれば、UEは、ストレージ内のカウンタ値を、メッセージからのカウンタ値に置き換える。手順がここで終了する場合、UEは、ステップ２３において、新しいカウンタ値を記憶する。

応答が必要である場合、UEは、同じ鍵を使用して応答を計算し、同様に応答を保護する：K_AUSF、KI、平文（plain text）、及び１インクリメントされたカウンタ値を使用して暗号化ハッシュを計算する。UEは、ストレージに新しいカウンタ値を記憶する。必要であれば、平文のメッセージ（plain text message）、KI、カウンタ値及び暗号化ハッシュを含むメッセージが、ステップ２４において、AUSFに送信される。メッセージが受信されると、AUSFは、暗号化ハッシュの値を確認する。暗号化ハッシュの値が正しい場合、AUSFは、メッセージの内容を認識する。

UEが、ステップ２２のメッセージから抽出されたKIに対応するK_AUSFを見つけることができない場合、UEは、メモリから、関連するKI及びカウンタ値を有する他のK_AUSFをメモリから取得する。UEは、カウンタを１インクリメントし、エラーインジケーション、KI、カウンタ値、並びにメッセージ内容及びK_AUSFから導出された暗号化ハッシュを含むメッセージを構成する。UEは、ステップ２４においてメッセージを送信する。UEは、新しいカウンタをストレージに記憶する。

AUSFは、エラーコードを含むメッセージ２４を受信すると、AUSFは、以下を行う：
－メッセージからKIを抽出する。
－ストレージ内のKIに対応するK_AUSFの存在を確認する。
－存在する場合：
（１）AUSFは、関連するK_AUSF及びカウンタをストレージから取得する。
（２）メッセージ内容、メッセージ内のカウンタ、KI及びストレージから取得したK_AUSFから暗号化ハッシュを計算することにより、暗号化ハッシュが正しいことを検証する；正しい場合、AUSFは、次のステップに進む。
（３）AUSFは、ストレージからのカウンタを１インクリメントし、UEからのメッセージに含まれるカウンタが、このK_AUSFに関連付けられたカウンタ以上であるかを確認する。UEからのメッセージに含まれるカウンタが、このK_AUSFに関連付けられたカウンタ以上である場合、AUSFは、ストレージから取得したカウンタ値を、UEからのメッセージに含まれるカウンタ値と等しく設定し、次のステップに進む。UEメッセージ内のカウンタ値が、このK_AUSFに関連付けられたカウンタよりも小さい場合、AUSFは、手順を中止する。
（４）ここで、AUSFは、ステップ２１に従ってメッセージを再構成するが、UEにより示されたKIに基づいてメモリから取得されたK_AUSF、１インクリメントされた後のカウンタ値、ステップ２１と同じ平文（plain text）及び使用されるK_AUSFに対応するKIを使用する。
（５）AUSFは、ステップ２２における第２のメッセージをUEに送信する。
（６）このメッセージがUEにより正常に受信され、UEが、ステップ２４において新しいメッセージの正しい受信を肯定応答する（acknowledge）場合、AUSFは、ステップ２２における第１のメッセージに使用されたKI及びK_AUSFをメモリから削除してもよい。
－存在しない場合：
（１）AUSFは、同じIMSIに関連付けられた次のKIを選択し、この新しく選択されたKI及び関連する鍵及びカウンタを使用することにより、ステップ２１から手順を再開する。どの鍵がUEで使用されたのかのレジスタを保持することにより、又はUEがステップ２４のメッセージで報告されるエラーコードの一部としてKI値を報告するため、AUSFは、どのKIが使用されたかを知ってもよい。エラーケースを経ることにより、AUSFは、ストレージ内の全てのKI値が正常に使用されていないことを検出（find）してもよい。このような場合、AUSFは、全てのKI、K_AUSF及び関連するカウンタをストレージから削除してもよい。

AUSFにより使用される鍵の選択は以下の通りである。
－最初のステップ２１において、AUSFは、常に、ストレージから最新の鍵を選択する。ステップ２２におけるメッセージに、この鍵を使用した後、AUSFは、ステップ２４のメッセージで肯定応答（acknowledgement）を受信し、AUSFは、任意の古い鍵をストレージから削除できる。
－ステップ２２において、第１のメッセージが正常では無い場合、これは、AUSFが応答においてエラーメッセージを受信し、エラーメッセージに対応するKIを有していないことを意味し、AUSFは、利用可能なものがあれば、次の鍵をストレージから選択する。

UEにより使用される選択メカニズムは、AUSFにより使用されるメカニズムに従うため、最初に、最新のものが選択され、それが失敗した場合、リストが無くなるまで次のものが選択される。

UE及びAUSFが、SUCIが使用された最新の認証手順に関連付けられたK_AUSFを常に保持するように構成されている場合、異なる選択メカニズムを使用できる。この場合、選択される最初の鍵は、最新の認証手順に関連付けられる鍵である。それが失敗した場合、UE及びAUSFは、ここに示されている方式に基づいて、他の鍵を選択できる。

上記では、AUSF及びK_AUSFについて説明している。同様の手順が、SEAFと、UEとの間で実行できる。その場合、SEAFは、上記のAUSFの代わりになり、SEAFは、K_AUSFにアクセスできないため、K_AUSFは、K_SEAFに置き換えられる。手順の残りは同じである。

ネットワーク開始手順に加えて、K_AUSFは、UE開始手順（UE initiated procedure）においても使用できる。そのような手順の一例は、サードパーティサービスのための認証及び鍵合意（authentication and key agreement）（3GPP subscriber credentialsに基づくAKMA（Authentication and Key Agreement for Applications）又はGBA（Generic Bootstrapping Architecture）とも呼ばれる）のためのK_AUSFの再利用である。この手順では、UEは、アプリケーションサーバに接続し、K_AUSFから導出された鍵を使用してこのアプリケーションサーバに対して認証する。このアプリケーションでは、鍵が同期されていることも重要である。手順の抽象的なバージョンが図１１に示される。図１１は、本開示の実施形態にかかる、K_AUSFを使用するためのUE開始手順（UE initiated procedure）を示す。

図１１に従うステップは以下の通りである。
ステップ３１の前に、UEは、手順を開始するためにトリガされる。これは、例えば、UEがサービスのためにアプリケーションサーバに要求を送信したためであり得る。アプリケーションサーバは、authentication requestをトリガし、AKMA又はGBAとの互換性（compatibility）を示す。これに応答して、UEは、K_AUSFからの鍵の導出をトリガするために、ネットワーク内の他のサーバ（これは、AUSFもしくはAKMA又はGBAサービス専用のサーバであり得る）に接続することを決定する。

UEがトリガされる他の例は、UEがパラメータを更新するために、又は異なるサービスを要求するためにAUSFと通信する必要があるためである。UEがトリガされる方法は、UEがどのようにメッセージを送信するか、つまり、メッセージがどの中間ノードを通過するのかに影響を与える可能性があるが、UEがAUSFとの情報交換を保護し、使用すべき正しいK_AUSFを選択する方法に影響を与えない可能性がある。

ステップ３１において、UEは、K_AUSFストレージの１つを、その関連するカウンタとともに取得する（retrieve）。そして、UEは、メッセージを完全に保護するために、UEのコマンド又は要求、カウンタ値、KI及び暗号化ハッシュを含むメッセージを構成する。暗号化ハッシュは、カウンタ値、KI、コマンド又は要求を含む平文のメッセージ（plain text message）、及びK_AUSFから計算される。メッセージはまた、UE識別子を含んでもよい。

ステップ３２において、平文（plain text）、KI、カウンタ及び暗号化ハッシュを含むメッセージが、AUSFに転送される。メッセージは、他のメッセージにカプセル化されている可能性があり、他のノードを経由する可能性がある。カプセル化されるメッセージは、UE識別子のような追加の値を含んでもよい。

ステップ３３において、AUSFは、メッセージを受信する。メッセージ内のKIに基づいて、AUSFは、鍵ストレージ内の、このKI及びUE識別子に関連付けられたK_AUSFを検索する。AUSFが、一致するKIを見つける場合、AUSFは、K_AUSF及びそれぞれのカウンタをメモリから取得する。次に、AUSFは、取得されたK_AUSFを使用して、平文のメッセージ内容（plain text message content）、メッセージに含まれるカウンタ、KI及びK_AUSFを使用する暗号化ハッシュを検証する。次に、AUSFは、メッセージ内のカウンタ値が、ストレージからのカウンタ値以上であるかを比較する。メッセージ内のカウンタ値が、ストレージからのカウンタ値以上である場合、AUSFは、ストレージのカウンタ値を、メッセージからのカウンタ値に置き換える。手順がここで終了する場合、AUSFは、ステップ３３において、新しいカウンタ値を記憶する。

応答が必要である場合、AUSFは、同じ鍵を使用して応答を計算し、同様に応答を保護する：K_AUSF、KI、平文（plain text）及び１インクリメントされたカウンタを使用して暗号化ハッシュを計算する。AUSFは、新しいカウンタ値をストレージに記憶する。必要であれば、平文のメッセージ（plain text message）、KI、カウンタ値及び暗号化ハッシュを含むメッセージが、ステップ３４においてUEに送信される。メッセージが受信されると、UEは、暗号化ハッシュの値を確認する。暗号化ハッシュの値が正しい場合、UEは、メッセージの内容を認識する。

AUSFが、ステップ３２のメッセージから抽出されたKIに対応するK_AUSFを見つけることが出来ない場合、AUSFは、このUE識別子に関連付けられた別のK_AUSFを、その関連付けられたKI及びカウンタ値とともにメモリから取得する。AUSFは、カウンタを１インクリメントし、エラーインジケーション、KI、カウンタ値、並びにメッセージ内容及びK_AUSFから導出された暗号化ハッシュを含むメッセージを構成する。AUSFは、ステップ３４においてメッセージを送信する。AUSFは、新しいカウンタをストレージに記憶する。

ステップ３５においてメッセージを受信すると、UEは、コマンドが正常に実行されたかどうかを確認し、暗号化ハッシュを計算することにより、メッセージの整合性（integrity）を検証する。エラーが受信された場合、UEは以下を実行する：
－エラーメッセージからKIを抽出する。
－ストレージ内のKIに対応するK_AUSFの存在を確認する。
－存在する場合：
（１）UEは、関連するK_AUSF及びカウンタをストレージから取得する。
（２）UEは、メッセージ内容、メッセージ内のカウンタ、KI及びストレージから取得されたK_AUSFから暗号化ハッシュを計算することにより暗号化ハッシュが正しいことを検証する。暗号化ハッシュが正しい場合、UEは、次のステップに進む。
（３）UEは、ストレージからのカウンタを１インクリメントし、AUSFからのメッセージに含まれるカウンタが、このK_AUSFに関連付けられたカウンタ以上であるかを確認する。AUSFからのメッセージに含まれるカウンタが、このK_AUSFに関連付けられたカウンタ以上である場合、UEは、ストレージから取得されたカウンタ値を、AUSFからのメッセージに含まれるカウンタ値と等しく設定し、継続する。AUSFメッセージ内のカウンタ値が、このK_AUSFに関連付けられたカウンタよりも小さい場合、UEは手順を中止する。
（４）ここで、UEは、ステップ３１に従ってメッセージを再構成するが、AUSFから示されたKIに基づいてメモリから取得されたK_AUSF、１インクリメントした後のカウンタ値、ステップ３１と同じ平文（plain text）及び使用されるK_AUSFに対応するKIを使用する。
（５）UEは、ステップ３２において、第２のメッセージをAUSFに送信する。
（６）メッセージがAUSFにより正常に受信され、AUSFがステップ３４において新しいメッセージの正しい受信を肯定応答する（acknowledge）場合、UEは、ステップ３２の第１のメッセージに使用されたKI及びK_AUSFをメモリから削除してもよい。
－存在しない場合：
（１）UEは、次のKIを選択し、この新しく選択されたKI並びに関連する鍵及びカウンタを使用することにより、ステップ３１から手順を再開する。どの鍵が使用されたかのレジスタを保持することにより、又はAUSFがステップ３４のメッセージで報告されるエラーコードの一部としてKI値を報告するため、UEは、どのKIが使用されたかを知ってもよい。エラーケースを経ることにより、UEは、ストレージ内の全てのKI値が正常に使用されていないことを検出（find）してもよい。そのような場合、UEは、全てのKI、K_AUSF及び関連するカウンタをストレージから削除してもよい。

鍵選択メカニズムは、ネットワーク開始手順について説明したメカニズムに従うことができる。

上記では、AUSF及びK_AUSFをについて説明した。同様の手順が、SEAFとUEとの間で実行できる。その場合、SEAFは、上記のAUSFの代わりになり、SEAFは、K_AUSFにアクセスできないため、K_AUSFは、K_SEAFに置き換えられる。手順の残りは同じである。

上記では、SEAF又はAUSFは、UEにより参照される鍵を記憶すると仮定される。AUSF及びSEAFはまた、特定のアプリケーションのための鍵、又はさらなる鍵を導出するために、後の手順で使用されるブートストラッピング鍵（bootstrapping key）等、その鍵から導出された鍵を記憶できる。例えば、サービスが、「サービス１（service_1）」と呼ばれる場合、サービス１（service_1）の鍵は、K_{service_1}であり、KIは、K_SEAF又はK_AUSFの説明に従って、この鍵から導出できる。あるいは、使用されるKIは、K_SEAF又はK_AUSFから導出されるKIであり得る。これは、UEが、複数のサービス、例えば、service_1、service_2、service_3等を有する場合に有利であるが、K_AUSFから導出されたサービスの鍵の１つのKI及びK_SEAFから導出された鍵の１つのKIを記憶するだけでよい。

さらに、認証が行われたときに、AUSF及びSEAFが、サービス固有の鍵及び（オプションでサービス固有の）KIを導出し、このデータをこのサービスのキーサーバにプッシュする可能性がある。例えば、service_1が、K_{service_1}を使用する場合、AUSFは、認証が行われるときに、例えば、ステップＢ又はステップＥにおいて、以下のステップを実行する。
１．AUSFは、K_AUSFからKIを導出する。
２．AUSFは、K_AUSFからK_{service_1}を導出する、例えば、K_{service_1} = KDF (K_AUSF, "Service_1")。
３．AUSFは、K_{service_1}及びKIをサービス１のためのキーサーバに送信する。
４．AUSFは、通常通り、認証を継続する。

UEは、これらのサービスのルートキーである鍵K_AUSFにアクセスできるため、UEは、認証時に鍵を導出することも、必要に応じて鍵を導出することもできる。

UEがサービスのうちの１つ、例えば、service_1を使用したいときはいつでも、キーサーバがAUSFの代わりになって、図１１に従って、UEは、以下を行う。

ステップ３１の前に、UEは、手順を開始するためにトリガされる。これは、例えば、UEが、サービスのためにアプリケーションサーバに要求を送信したためであり得る。アプリケーションサーバは、service_1、例えば、AKMAをサポートすることを示す。これに応答して、UEは、ネットワーク内のサービス１キーサーバ（Service 1 Key Server）に接続することを決定する。

ステップ３１において、UEは、K_AUSFストレージの１つを、それに関連するカウンタとともに取得する。そして、UEは、UEのコマンド又は要求、カウンタ値、KI及びメッセージの完全性を保護するための暗号化ハッシュを含むメッセージを構成する。実装がサービス固有のKIを使用する場合、UEは、最初にサービス固有の鍵を計算し、次に対応するKIを計算する。暗号化ハッシュは、カウンタ値、KI、コマンド又は要求を含む平文のメッセージ（plain text message）、及びK_{service_1}から計算される。メッセージは、UE識別子も含んでもよい。

ステップ３２において、平文（plain text）、KI、カウンタ及び暗号化ハッシュを含むメッセージが、キーサーバに転送される。メッセージは、他のメッセージにカプセル化されている可能性があり、他のノードを経由する可能性がある。カプセル化されるメッセージは、UE識別子等の追加の値を含んでもよい。

ステップ３３において、キーサーバは、メッセージを受信する。メッセージ内のKIに基づいて、キーサーバは、鍵ストレージ内の、このKI及びUE識別子に関連付けられたK_{service_1}を検索する。キーサーバが、一致するKIを見つける場合、キーサーバは、K_{service_1}及びそれぞれのカウンタをメモリから取得する。次に、キーサーバは、取得されたK_{service_1}を使用して、平文のメッセージ内容（plain text message content）、メッセージ内のカウンタ、KI及びK_{service_1}を使用する暗号化ハッシュを検証する。次に、キーサーバは、メッセージ内のカウンタ値が、ストレージからのカウンタ値以上であるかどうかを比較する。メッセージ内のカウンタ値が、ストレージからのカウンタ値以上である場合、キーサーバは、ストレージ内のカウンタ値を、メッセージからのカウンタ値に置き換える。手順がここで終了する場合、キーサーバは、ステップ３３において新しいカウンタ値を記憶する。

エラーの場合、キーサーバは、図１１の説明に従ってエラーを処理するか、又はAUSFを参照することができる。例えば、キーサーバが、鍵を見つけることが出来ない場合、それは、新しい認証のためにAUSFを参照できる。

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

コントローラ１２０５は、メモリ１２０４に格納されたソフトウェアに従って、UE１２００の動作を制御する。例えば、コントローラ１２０５は、中央処理装置（CPU：Central Processing Unit）により実現されてもよい。ソフトウェアは、とりわけ、オペレーティングシステム１２０６、及び少なくともトランシーバ制御モジュール１２０８を有する通信制御モジュール１２０７を含む。（トランシーバ制御サブモジュールを使用する）通信制御モジュール１２０７は、UE１２００と、基地局／(R)ANノード、MME、AMF（及び他のコアネットワークノード）等の他のノードとの間のシグナリング及びアップリンク／ダウンリンクデータパケットの処理（生成／送信／受信）を担当する。そのようなシグナリングは、例えば、接続確立及び維持に関連する、適切にフォーマットされたシグナリングメッセージ（例えば、RRCメッセージ）、周期的なlocation update関連メッセージ（例えば、tracking area update、paging area update、location area update）等のNASメッセージを含み得る。

図１３は、例えば、基地局（LTEにおける'eNB'、5Gにおける'gNB'）等の例示的な(R)ANノードの主要な構成要素を示すブロック図である。図１３は、本開示にかかる(R)ANノードのブロック図を示す。示されるように、(R)ANノード１３００は、１つ又は複数のアンテナ１３０２を介して、接続されたUEに信号を送信し、接続されたUEから信号を受信し、ネットワークインタフェース１３０３を介して、他のネットワークノードに（直接的に又は間接的に）信号を送信し、他のネットワークノードから（直接的に又は間接的に）信号を受信するように動作可能なトランシーバ回路１３０１を備える。コントローラ１３０４は、メモリ１３０５に格納されたソフトウェアに従って(R)ANノード１３００の動作を制御する。例えば、コントローラ１３０４は、中央処理装置（CPU：Central Processing Unit）により実現されてもよい。ソフトウェアは、メモリ１３０５に予めインストールされてもよく、及び／又は、電気通信ネットワークを介して、又は例えば、取り外し可能なデータストレージデバイス（RMD：removable data storage device）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム１３０６、及び少なくともトランシーバ制御モジュール１３０８を有する通信制御モジュール１３０７を含む。

（トランシーバ制御サブモジュールを使用する）通信制御モジュール１３０７は、（例えば、直接的に又は間接的に）(R)ANノード１３００と、UE、MME、AMF等の他のノードとの間のシグナリングの処理（生成／送信／受信）を担当する。シグナリングは、例えば、（特定のUEのための）無線接続及びロケーション手順、特に、接続確立及び維持（例えば、RRC Connection establishment及び他のRRCメッセージ）、周期location update関連メッセージ（例えば、tracking area update、paging area update、location area update）、S1 APメッセージ、及びNG-APメッセージ（つまり、N2参照ポイントによるメッセージ）等の適切にフォーマットされたシグナリングメッセージを含み得る。そのようなシグナリングはまた、送信する場合、例えば、報知情報（broadcast information）（例えば、マスター情報及びシステム情報）を含み得る。

コントローラ１３０４はまた、実装される場合、UEモビリティ推定、及び／又は移動軌跡推定等の関連タスクを処理するように（ソフトウェア又はハードウェアにより）構成される。

図１４は、例えば、AMF、SMF、SEAF、AUSF、UPF、UDM、ARPF、SIDF、PCF、AF等の例示的なコアネットワークノードの主要な構成要素を示すブロック図である。図１４は、本開示にかかるコアネットワークノードのブロック図を示す。
コアネットワークノード１４００は、5Gコアネットワーク（5GC：5G core network）に含まれる。
示されるように、コアネットワークノード１４００は、ネットワークインタフェース１４０２を介して、（UEを含む）他のノードに信号を送信し、他のノードから信号を受信するように動作可能なトランシーバ回路１４０１を備える。コントローラ１４０３は、メモリ１４０４に格納されたソフトウェアに従ってコアネットワークノード１４００の動作を制御する。例えば、コントローラ１４０３は、中央処理装置（CPU：Central Processing Unit）により実現されてもよい。ソフトウェアは、メモリ１４０４に予めインストールされてもよく、及び／又は、電気通信ネットワークを介して、又は例えば、取り外し可能なデータストレージデバイス（RMD：removable data storage device）からダウンロードされてもよい。ソフトウェアは、とりわけ、オペレーティングシステム１４０５、及び少なくともトランシーバ制御モジュール１４０７を有する通信制御モジュール１４０６を含む。

（トランシーバ制御サブモジュールを使用する）通信制御モジュール１４０６は、（直接的に又は間接的に）コアネットワークノード１４００と、UE、基地局／(R)ANノード（例えば、「gNB」又は「eNB」）等の他のノードとの間のシグナリングの処理（生成／送信／受信）を担当する。そのようなシグナリングは、例えば、本明細書に記載の手順に関連する適切にフォーマットされたシグナリングメッセージ、例えば、UEからのNASメッセージ及びUEへのNASメッセージを伝達するNG APメッセージ（つまり、N2参照ポイントによるメッセージ）を含み得る。

AMFは、Access and Mobility Management Functionである。これは、接続されたUEのレジスタを保持し、これらのUEのモビリティの側面を管理する、モバイルネットワークのネットワークエレメントである。SMFは、Session Management Functionである。これは、モバイルネットワークのネットワークエレメントであり、ネットワークに接続されたUEのセッションを管理する。

SEAFは、Security Anchor Functionである。これは、セキュリティアンカーとして機能する、モバイルネットワークのネットワークエレメントである。SEAFは、ネットワークに接続されている各UEのアンカーキーを保持する。

AUSFは、Authentication Server Functionである。これは、ネットワークに接続するUEの認証を管理する、モバイルネットワークのネットワークエレメントである。

UPFは、User Plane Functionである。これは、UEへのユーザプレーンを終端し、又はUEから他のUPFへのユーザプレーンをルーティングする、モバイルネットワークのネットワークエレメントである。

UDMは、Unified Data Managementノードである。これは、例えば、加入者に関連するデータを管理する、モバイルネットワークのネットワークエレメントである。UDMの一部は、加入者識別子及び秘密鍵を有するレジストリであり、ARPF又はAuthentication Center（AuC）とも呼ばれる。ARPFは、Authentication credentials Repository Functionである。これは、加入者識別子及び秘密鍵等の加入者クレデンシャル（subscriber credentials）を記憶し、処理する。

SIDFは、SUCI（Subscriber Concealed Identifier）Deconcealing Functionである。これは、ホームネットワークの秘密鍵を保持し、SUCIを復号化又は秘匿解除して、SUPI （Subscriber Permanent Identity）を取得する。

ネットワークエレメントは、論理機能として実装でき、単一のネットワークノードでホストできる。例えば、UDM、SIDF及びARPFは、通常、個々のネットワークエレメントの全ての機能を実行する１つのネットワークノードになる。

本開示における、ユーザ装置（User Equipment）（もしくは、「UE」、「移動局（mobile station）」、「モバイルデバイス（mobile device）」、又は無線端末（wireless device））は、無線インターフェースを介して、ネットワークに接続されたエンティティである。

本明細書におけるUEは、専用の通信装置に限定されるものではなく、次の段落以降に説明される本明細書におけるUEのような通信機能を有する任意のデバイスに提供することが可能である。

用語として「（3GPPで使われる単語としての）ユーザ装置（User Equipment、UE）」、「移動局」、「移動端末」、「モバイルデバイス」、「無線端末」のそれぞれは、一般的に互いに同義であることを意図しており、ターミナル、携帯電話、スマートフォン、タブレット、セルラIoT端末、IoTデバイス、などのスタンドアローン移動局であってもよい。

用語として「移動局」「移動端末」「モバイルデバイス」は、長期間にわたって備え付けられている装置も包含することが理解されよう。

UEは、例えば、生産設備・製造設備および／またはエネルギー関連機械のアイテム（一例として、ボイラー、機関、タービン、ソーラーパネル、風力発電機、水力発電機、火力発電機、原子力発電機、蓄電池、原子力システム、原子力関連機器、重電機器、真空ポンプなどを含むポンプ、圧縮機、ファン、送風機、油圧機器、空気圧機器、金属加工機械、マニピュレータ、ロボット、ロボット応用システム、工具、金型、ロール、搬送装置、昇降装置、貨物取扱装置、繊維機械、縫製機械、印刷機、印刷関連機械、紙工機械、化学機械、鉱山機械、鉱山関連機械、建設機械、建設関連機械、農業用機械および／または器具、林業用機械および／または器具、漁業用機械および／または器具、安全および／または環境保全器具、トラクター、軸受、精密ベアリング、チェーン、歯車（ギアー）、動力伝動装置、潤滑装置、弁、管継手、および／または上記で述べた任意の機器又は機械のアプリケーションシステムなど）であっても良い。

UEは、例えば、輸送用装置のアイテム（一例として、車両、自動車、二輪自動車、自転車、列車、バス、リヤカー、人力車、船舶（ship and other watercraft）、飛行機、ロケット、人工衛星、ドローン、気球など）であっても良い。

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, Annex B、その内容は参照により本明細書に組み込まれる）。このリストは、完全なものではなく、マシンタイプ通信アプリケーションのいくつかの例を示すことを目的としている。

アプリケーション、サービス、およびソリューションは、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に限定されるものではなく、種々の変形が可能である。

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

ブロック図の各ブロックは、コンピュータプログラム命令によって実施することができることが理解されよう。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されて、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートおよび／またはブロックダイヤグラムブロックにて規定された機能／動作を実行するための手段を生成するように、マシンを生成することができる。汎用プロセッサは、マイクロプロセッサでもよいが、代替的に、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシーンであり得る。プロセッサはまた、コンピューティングデバイスの組み合わせ、例えば、複数のマイクロプロセッサ、１つ又は複数のマイクロプロセッサ、あるいは他のそのような構成として実装されてもよい。

本明細書に開示される例に関連して説明された方法又はアルゴリズムは、ハードウェア、プロセッサにより実行されるソフトウェアモジュール、又はその２つの組み合わせで直接的に実装されてもよい。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバルディスク、CD-ROM又は当該技術分野で知られている他の記憶媒体に存在してもよい。記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合されてもよい。代替的に、記憶媒体は、プロセッサに統合されてもよい。プロセッサ及び記憶媒体は、ASICに存在してもよい。

開示された実施例の前述の説明は、当業者が本開示を作成又は使用することを可能にするために提供される。これらの実施例に対する様々な変更は、当業者には容易に明らかであり、本明細書で定義された一般的な原理が、開示の精神又は範囲から逸脱することなく他の実施例に適用され得る。したがって、本開示は、本明細書に示される実施例に限定されることを意図するものではなく、本明細書に開示される原理及び新規な特徴と一致する最も広い範囲が与えられるべきである。

例えば、上記の態様の全部又は一部は、以下の付記のように記載できるが、これに限定されるものではない。
（付記１）
端末であって、
メモリと、
サードパーティサービスのために、前記端末と、5Gにおけるネットワークとの間のプライマリ認証を実行し、
セキュリティ鍵K_AUSFを導出し、
前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備える端末。
（付記２）
前記プライマリ認証は、5G AKA又はEAP-AKA'を含む、請求項１に記載の端末。
（付記３）
前記プロセッサは、
前記セキュリティ鍵のための前記識別子を含むメッセージを送信するようにさらに構成される、付記１又は２に記載の端末。
（付記４）
前記サードパーティサービスは、AKMAサービスを含む、付記１～３のいずれか１項に記載の端末。
（付記５）
5Gにおける前記ネットワークは、Authentication Server Function（AUSF）を含む、付記１～４のいずれか１項に記載の端末。
（付記６）
前記セキュリティ鍵は、前記サードパーティサービスのために使用される、請求項１～５のいずれか１項に記載の端末。
（付記７）
サードパーティサービスのために、端末と、5Gにおけるネットワークとの間のプライマリ認証を実行すること、
セキュリティ鍵K_AUSFを導出すること、及び
前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出すること、を含む方法。
（付記８）
前記プライマリ認証は、5G AKA又はEAP-AKA'を含む、請求項７に記載の方法。
（付記９）
前記セキュリティ鍵のための前記識別子を含むメッセージを送信することをさらに含む、付記７又は８に記載の方法。
（付記１０）
前記サードパーティサービスは、AKMAサービスを含む、付記７～９のいずれか１項に記載の方法。
（付記１１）
5Gにおける前記ネットワークは、Authentication Server Function（AUSF）を含む、付記７～１０のいずれか１項に記載の方法。
（付記１２）
前記セキュリティ鍵は、前記サードパーティサービスのために使用される、付記７～１１のいずれか１項に記載の方法。
（付記１３）
5Gにおけるネットワークに使用されるコアネットワーク装置であって、
メモリと、
サードパーティサービスのために、端末と、前記ネットワークとの間のプライマリ認証を実行し、
セキュリティ鍵K_AUSFを導出し、
前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備えるコアネットワーク装置。
（付記１４）
前記コアネットワーク装置は、Authentication Server Function（AUSF）を含む、付記１３に記載のコアネットワーク装置。

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

１２００ UE
１２０１、１３０１、１４０１ トランシーバ回路
１２０２、１３０２ アンテナ
１２０３ ユーザインタフェース
１２０４、１３０５、１４０４ メモリ
１２０５、１３０４、１４０３ コントローラ
１２０６、１３０６、１４０５ オペレーティングシステム
１２０７、１３０７、１４０６ 通信制御モジュール
１２０８、１３０８、１４０７ トランシーバ制御モジュール
１３００ (R)ANノード
１３０３、１４０２ ネットワークインタフェース
１４００ コアネットワークノード

Claims (14)

1. 端末であって、
   メモリと、
   サードパーティサービスのために、前記端末と、5Gにおけるネットワークとの間のプライマリ認証を実行し、
   セキュリティ鍵K_AUSFを導出し、
   前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備える端末。
2. 前記プライマリ認証は、5G AKA又はEAP-AKA'を含む、請求項１に記載の端末。
3. 前記プロセッサは、
   前記セキュリティ鍵のための前記識別子を含むメッセージを送信するようにさらに構成される、請求項１又は２に記載の端末。
4. 前記サードパーティサービスは、AKMAサービスを含む、請求項１～３のいずれか１項に記載の端末。
5. 5Gにおける前記ネットワークは、Authentication Server Function（AUSF）を含む、請求項１～４のいずれか１項に記載の端末。
6. 前記セキュリティ鍵は、前記サードパーティサービスのために使用される、請求項１～５のいずれか１項に記載の端末。
7. サードパーティサービスのために、前記端末と、5Gにおけるネットワークとの間のプライマリ認証を実行すること、
   セキュリティ鍵K_AUSFを導出すること、及び
   前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出すること、を含む方法。
8. 前記プライマリ認証は、5G AKA又はEAP-AKA'を含む、請求項７に記載の方法。
9. 前記セキュリティ鍵のための前記識別子を含むメッセージを送信することをさらに含む、請求項７又は８に記載の方法。
10. 前記サードパーティサービスは、AKMAサービスを含む、請求項７～９のいずれか１項に記載の方法。
11. 5Gにおける前記ネットワークは、Authentication Server Function（AUSF）を含む、請求項７～１０のいずれか１項に記載の方法。
12. 前記セキュリティ鍵は、前記サードパーティサービスのために使用される、請求項７～１１のいずれか１項に記載の方法。
13. 5Gにおけるネットワークに使用されるコアネットワーク装置であって、
    メモリと、
    サードパーティサービスのために、端末と、前記ネットワークとの間のプライマリ認証を実行し、
    セキュリティ鍵K_AUSFを導出し、
    前記セキュリティ鍵から、前記セキュリティ鍵の識別子を導出するように構成され、かつハードウェアを含むプロセッサと、を備えるコアネットワーク装置。
14. 前記コアネットワーク装置は、Authentication Server Function（AUSF）を含む、請求項１３に記載のコアネットワーク装置。

Images