JP6737910B2 - 鍵構成方法、セキュリティポリシー決定方法、及び装置 - Google Patents

Description

本出願は、通信分野に関し、特に、鍵構成方法、セキュリティポリシー決定方法、及び装置に関する。

将来の（例えば、第５世代）モバイル通信アーキテクチャでは、セッション管理ネットワーク要素が、ユーザ機器のサービス要件に基づいて、ユーザ機器とゲートウェイ（又はＤＮサーバ又は別のユーザ機器）の間でセッションをセットアップする。

既存のセッションセキュリティアルゴリズムのいずれも、将来のモバイル通信アーキテクチャに適用可能でない。従って、将来のモバイル通信アーキテクチャに基づいてセキュリティ機構をどのようにセットアップするかは、現在解決されるべき差し迫った問題になっている。

本出願は、将来のモバイル通信アーキテクチャに基づいてセキュリティ機構をどのようにセットアップするかという問題を解決する、鍵構成方法、セキュリティポリシー決定方法、及び装置を提供する。

本出願の第１の態様は、以下のステップを含む鍵構成方法を提供する。セッション管理ネットワーク要素が、エンドツーエンド通信のための要求を受信し、このエンドツーエンド通信のための要求は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別を含む。セッション管理ネットワーク要素が、セキュリティポリシーを取得し、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される。セッション管理ネットワーク要素が、保護鍵を取得し、この保護鍵は、エンドツーエンド通信を保護するために使用され、この保護鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される。セッション管理ネットワーク要素が、セキュリティポリシー及び／又は保護鍵をユーザ機器に送信する。そして、セッション管理ネットワーク要素が、セキュリティポリシー及び／又は保護鍵をエンドツーエンド通信の他方のエンド上のデバイスに送信する。セッション管理ネットワーク要素は、エンドツーエンド通信のセキュリティを改善するように、エンドツーエンド通信の２つのエンド上のデバイスのためのセッション保護鍵を構成することができることが前述のプロセスから学習されうる。加えて、既存のセグメントベースの暗号化方式と比較して、より高いセキュリティが実施される。

本出願の第２の態様は、通信構成要素とプロセッサとを含むセッション管理ネットワーク要素を開示する。具体的には、通信構成要素は、エンドツーエンド通信のための要求を受信することを行うように構成され、このエンドツーエンド通信のための要求は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別を含む。プロセッサは、セキュリティポリシーを取得することであって、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される、ことと、保護鍵を取得することであって、この保護鍵は、エンドツーエンド通信を保護するために使用され、この保護鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される、こととを行うように構成される。通信構成要素は、セキュリティポリシー及び／又は保護鍵をユーザ機器に送信することと、セキュリティポリシー及び／又は保護鍵をエンドツーエンド通信の他方のエンド上のデバイスに送信することとを行うようにさらに構成される。

実装形態では、エンドツーエンド通信のための要求は、ネットワーク識別及びサービスパラメータのうちの少なくとも１つをさらに含む。ネットワーク識別及びサービスパラメータのうちの少なくとも１つは、その後の鍵を生成するために使用され得る。

実装形態では、保護鍵を取得することは、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得することであって、このパラメータは、ユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含む、ことを含む。

実装形態では、セッション管理ネットワーク要素が、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得する前に、以下のこと、すなわち、セッション管理ネットワーク要素が、セキュリティポリシー要求をキャリアのポリシー制御ネットワーク要素に送信し、このセキュリティポリシー要求は、ユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含み、このユーザ機器の識別、ネットワーク識別、及びサービスパラメータのうちの少なくとも１つは、セキュリティポリシーを識別するためにポリシー制御ネットワーク要素によって使用されること、そして、セッション管理ネットワーク要素が、キャリアのポリシー制御ネットワーク要素によって送信されたセキュリティポリシーを受信すること、がさらに含まれる。

実装形態では、セキュリティポリシー要求は、前もってセッション管理ネットワーク要素によって取得されるセキュリティ要件セットをさらに含み、このセキュリティ要件セットは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つを含む。

実装形態では、セッション管理ネットワーク要素が、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得する前に、以下のこと、すなわち、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つを取得することと、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの取得された少なくとも１つに基づいて、セキュリティポリシーを決定すること、がさらに含まれる。

実装形態では、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を取得する特定の実装形態は、エンドツーエンド通信のための要求を受信した後、セキュリティ要件要求をキャリアネットワーク内のネットワーク要素に送信して、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を取得すること、又は、エンドツーエンド通信のための要求から、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を取得することである。

実装形態では、ユーザ機器からのサービスセキュリティ要件及びユーザ機器によってサポートされるセキュリティ能力要件を取得する特定の実装形態は、エンドツーエンド通信のための要求から、ユーザ機器からのサービスセキュリティ要件及び／又はユーザ機器によってサポートされるセキュリティ能力要件を取得することである。

実装形態では、キャリアネットワークからのセキュリティ能力要件を取得する特定の実装形態は、セキュリティ要件要求をキャリアネットワーク内のポリシー制御ネットワーク要素に送信することであって、このセキュリティ要件要求は、ユーザ機器の識別及びネットワーク識別のうちの少なくとも１つを含む、ことと、キャリアネットワーク内のポリシー制御ネットワーク要素によって送信された、キャリアネットワークからのセキュリティ能力要件を受信することであって、ユーザ機器の識別及びネットワーク識別のうちの少なくとも１つは、キャリアネットワークからのセキュリティ能力要件を識別するためにポリシー制御ネットワーク要素によって使用される、ことである。

実装形態では、エンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件を取得する特定の実装形態は、セキュリティ要件要求をキャリアネットワーク内のポリシー制御ネットワーク要素に送信することと、エンドツーエンド通信の他方のエンド上のデバイスのものであり、キャリアネットワーク内のポリシー制御ネットワーク要素によって送信されたセキュリティ要件を受信すること、又は、セキュリティ要件要求をエンドツーエンド通信の他方のエンド上のデバイスに送信し、エンドツーエンド通信の他方のエンド上のデバイスのものであり、エンドツーエンド通信の他方のエンド上のデバイスによって送信されたセキュリティ要件を受信することであって、このセキュリティ要件要求は、ユーザ機器の識別及びサービスパラメータのうちの少なくとも１つを含み、このユーザ機器の識別及びサービスパラメータのうちの少なくとも１つは、エンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件を探すためにエンドツーエンド通信の他方のエンド上のデバイスによって使用される、ことである。

実装形態では、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいてセキュリティポリシーを決定する特定の実装形態は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの１つに基づいてセキュリティポリシーを決定すること、又は、予め設定されたルールに従って、また、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの複数に基づいて、セキュリティポリシーを決定することである。

実装形態では、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいてセキュリティポリシーを決定する前に、以下のことがさらに含まれる。セッション管理ネットワーク要素が、ユーザ機器の構成情報若しくはノードポリシーに基づいて、又はローカルストレージから取得されるユーザ機器の構成情報若しくはノードポリシーに基づいて、又はサービスセキュリティ要件、サーバ側セキュリティ要件、サービスタイプ、ユーザ機器のセキュリティ能力、若しくはスライシングポリシーに基づいて、セキュリティ保護の終了点がユーザプレーンノードＵＰＦであることを決定する、又は、セッション管理ネットワーク要素が、キャリアのポリシー制御ネットワーク要素からノード構成パラメータを受信し、このノード構成パラメータは、セキュリティ保護の終了点がユーザプレーンノード（ＵＰＦ）であることを示す。

実装形態では、ＵＰＦは訪問先公衆陸上モバイル通信ネットワークＶＰＬＭＮ内のＵＰＦであり、キャリアネットワークからのセキュリティ能力要件はＶＰＬＭＮ内のゲートウェイのセキュリティ要件である、又は、ＵＰＦはホーム公衆陸上モバイル通信ネットワークＨＰＬＭＮ内のＵＰＦであり、キャリアネットワークからのセキュリティ能力要件はＨＰＬＭＮ内のゲートウェイのセキュリティ要件である。

実装形態では、セキュリティ要件の内容は、セキュリティ保護アルゴリズムを含み、このセキュリティ保護アルゴリズムは、暗号化アルゴリズム及び／又は完全性保護アルゴリズムを含む。

実装形態では、セキュリティ要件の内容は、鍵長及び／又は鍵更新時間をさらに含む。

実装形態では、セキュリティ要件のフォーマットは、複数のオクテットを含み、この複数のオクテットは、以下のもの、すなわち、セキュリティ要件の識別を示すために使用されるオクテット、セキュリティ要件の内容の長さを示すために使用されるオクテット、暗号化アルゴリズムがセキュリティ要件において必要とされるかどうかを示すために使用されるオクテット、完全性保護アルゴリズムがセキュリティ要件において必要とされるかどうかを示すために使用されるオクテット、暗号化アルゴリズムの長さを示すために使用されるオクテット、完全性保護アルゴリズムの長さを示すために使用されるオクテット、鍵が更新される必要があるかどうかを示すために使用されるオクテット、特定の暗号化アルゴリズムを示すために使用されるオクテット、及び特定の完全性保護アルゴリズムを示すために使用されるオクテット、のうちのいずれか１つを含む。

実装形態では、セッション管理ネットワーク要素が、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得する前に、以下のこと、すなわち、キャリアネットワーク内の鍵管理センターによって送信された共有鍵を受信すること、又は共有鍵をローカルに取得することがさらに含まれる。

実装形態では、保護鍵を取得することは、鍵要求をキャリアの鍵管理センターに送信することであって、この鍵要求は、ユーザ機器の識別、ネットワーク識別、サービスパラメータ、及びセキュリティポリシー、のうちの少なくとも１つを含み、ユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つは、共有鍵を決定するために鍵管理センターによって使用される、ことと、鍵管理センターによって送信された保護鍵を受信することとを含む。

実装形態では、方法は、セッション管理ネットワーク要素によって、ネットワーク識別をエンドツーエンド通信の一方のエンドに送信すること、及び／又は、セッション管理ネットワーク要素によって、ネットワーク識別をエンドツーエンド通信の他方のエンド上のデバイスに送信することをさらに含む。

本出願の第３の態様は、以下のステップを含む鍵構成方法を提供する。鍵管理センターが、鍵要求を受信し、ユーザ機器の識別に基づいてユーザ機器とキャリアネットワークの間の共有鍵を決定して、セキュリティポリシー、共有鍵、及びパラメータに基づいて、エンドツーエンド通信を保護するために使用される保護鍵を生成する。そして、鍵管理センターが、保護鍵をユーザ機器に送信し、保護鍵をエンドツーエンド通信の他方のエンド上のデバイスに送信する。鍵要求は、セキュリティポリシーと、パラメータとを含み、このパラメータは、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含み、セキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される。

本出願の第４の態様は、通信構成要素とプロセッサとを含む鍵管理センターを提供する。この通信構成要素は、鍵要求を受信することを行うように構成される。プロセッサは、ユーザ機器の識別に基づいてユーザ機器とキャリアネットワークの間の共有鍵を決定することと、セキュリティポリシー、共有鍵、及びパラメータに基づいて保護鍵を生成することとを行うように構成される。通信構成要素は、保護鍵をユーザ機器に送信することと、保護鍵をエンドツーエンド通信の他方のエンド上のデバイスに送信することとを行うようにさらに構成される。パラメータは、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含み、セキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される。

実装形態では、鍵管理ネットワーク要素が、セキュリティポリシー、共有鍵、及びパラメータに基づいて保護鍵を生成した後、以下のことがさらに含まれる。鍵管理ネットワーク要素が、保護鍵をキャリアのセッション管理ネットワーク要素に送信する。

実装形態では、共有鍵は、双方向認証がユーザ機器とキャリアネットワークの間で実行された後に取得される、ユーザ機器とキャリアネットワークの間の共有鍵である。

本出願の第５の態様は、ユーザ機器によって、ユーザ機器の識別を含む要求を送信することと、ユーザ機器によって、セキュリティポリシーを搬送する応答を受信することであって、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される、ことと、ユーザ機器によって、保護鍵を取得することであって、この保護鍵は、エンドツーエンド通信を保護するために使用され、この保護鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される、こととを含む鍵構成方法を提供する。

本出願の第６の態様は、通信構成要素とプロセッサとを含むユーザ機器を提供する。通信構成要素は、ユーザ機器の識別を含む要求を送信することと、セキュリティポリシーを搬送する応答を受信することとを行うように構成される。セキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される。プロセッサは、保護鍵を取得することを行うように構成され、この保護鍵は、エンドツーエンド通信を保護するために使用され、この保護鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される。

実装形態では、ユーザ機器によって、要求を送信する特定の実装形態は、ユーザ機器によって、サービスパラメータ及びセキュリティ要件セットを送信することであり、このセキュリティ要件セットは、ユーザ機器からのサービスセキュリティ要件及び／又はユーザ機器によってサポートされるセキュリティ能力要件を含む。

実装形態では、要求は、
ユーザ機器によって生成されるセッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤをさらに含む。

実装形態では、保護鍵を取得することは、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得することを含み、このパラメータは、ユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含む。

実装形態では、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得する前に、以下のこと、すなわち、キャリアの鍵管理センターによって送信された共有鍵を受信すること、又は、共有鍵をローカルに取得すること、又は、双方向認証がユーザ機器とキャリアネットワークの間で実行された後、ユーザ機器とキャリアネットワークの間の共有鍵を取得することがさらに含まれる。

実装形態では、セキュリティポリシー、共有鍵、及びパラメータに基づいた導出を通じて保護鍵を取得する前に、以下のこと、すなわち、キャリアネットワーク内のセッション管理ネットワーク要素によって送信されたネットワーク識別を受信することがさらに含まれる。

実装形態では、保護鍵を取得することは、ユーザ機器によって、キャリアネットワーク内の鍵管理センター又はセッション管理ネットワーク要素によって送信された保護鍵を受信することを含む。

本出願の第７の態様は、キャリアのポリシー制御ネットワーク要素によって、セキュリティポリシー要求を受信することであって、このセキュリティポリシー要求は、パラメータと、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つとを含み、パラメータは、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つとを含む、ことと、ポリシー制御ネットワーク要素によって、セキュリティ要件セットに基づいてセキュリティポリシーを生成及び送信することであって、このセキュリティ要件セットは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つを含む、こととを含むセキュリティポリシー決定方法を提供する。

本出願の第８の態様は、通信構成要素とプロセッサとを含むポリシー制御ネットワーク要素を提供する。通信構成要素は、セキュリティポリシー要求を受信することを行うように構成され、このセキュリティポリシー要求は、パラメータと、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つとを含み、パラメータは、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含む。プロセッサは、セキュリティ要件セットに基づいてセキュリティポリシーを生成することを行うように構成され、このセキュリティ要件セットは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つを含む。通信構成要素は、セキュリティポリシーを送信することを行うようにさらに構成される。

実装形態では、セキュリティ要件セットは、キャリアネットワークからのセキュリティ能力要件及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つをさらに含む。

実装形態では、キャリアネットワークのセキュリティ要件を取得することは、セキュリティポリシー要求を受信した後、キャリアネットワークの予め格納されたセキュリティ要件をローカルに取得することを含む。

実装形態では、エンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件を取得することは、エンドツーエンド通信の他方のエンド上のデバイスのものであり、セッション管理ネットワーク要素によって送信されたセキュリティ要件を受信すること、又は、セキュリティ要件要求をエンドツーエンド通信の他方のエンド上のデバイスに送信し、エンドツーエンド通信の他方のエンド上のデバイスによって送信されたセキュリティ要件を受信することであって、このセキュリティ要件要求は、ユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含み、ユーザ機器の識別、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つは、エンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件をマークするために、エンドツーエンド通信の他方のエンド上のデバイスによって使用される、ことを含む。

実装形態では、セキュリティ要件セットに基づいてセキュリティポリシーを生成することは、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの１つに基づいてセキュリティポリシーを決定することと、又は、予め設定されたルールに従って、また、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの複数に基づいて、セキュリティポリシーを決定することを含む。

実装形態では、セキュリティ要件セットに基づいてセキュリティポリシーを生成する前に、以下のことがさらに含まれる。キャリアのポリシー制御ネットワーク要素が、ユーザ機器の構成情報若しくはノードポリシーに基づいて、又はローカルストレージから取得されるユーザ機器の構成情報若しくはノードポリシーに基づいて、又はサービスセキュリティ要件、サーバ側セキュリティ要件、サービスタイプ、ユーザ機器のセキュリティ能力、若しくはスライシングポリシーに基づいて、セキュリティ保護の終了点がユーザプレーンノードＵＰＦであることを決定する。

実装形態では、ＵＰＦは訪問先公衆陸上モバイル通信ネットワークＶＰＬＭＮ内のＵＰＦであり、キャリアネットワークからのセキュリティ能力要件はＶＰＬＭＮ内のゲートウェイのセキュリティ要件である、又は、ＵＰＦはホーム公衆陸上モバイル通信ネットワークＨＰＬＭＮ内のＵＰＦであり、キャリアネットワークからのセキュリティ能力要件はＨＰＬＭＮ内のゲートウェイのセキュリティ要件である。

実装形態では、セキュリティ要件セットに基づいてセキュリティポリシーを生成する前に、以下のことがさらに含まれる。キャリアのポリシー制御ネットワーク要素が、セキュリティ保護の終了点は、分岐点又はアップリンクデータ分類器関数ＵＬＣＬであることを決定し、セキュリティ要件セットが、分岐点又はＵＬＣＬのセキュリティ要件をさらに含む。

実装形態では、セキュリティ要件の内容は、セキュリティ保護アルゴリズムを含み、このセキュリティ保護アルゴリズムは、暗号化アルゴリズム及び／又は完全性保護アルゴリズムを含む。

実装形態では、セキュリティ要件の内容は、鍵長及び／又は鍵更新時間をさらに含む。

本出願の第９の態様は、モビリティ管理ネットワーク要素によって、ユーザ機器の要求を受信することであって、このユーザ機器の要求は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別を含む、ことと、モビリティ管理ネットワーク要素によって、エンドツーエンド通信のための要求を送信することであって、このエンドツーエンド通信のための要求は、ユーザ機器の識別を含み、このエンドツーエンド通信のための要求は、セキュリティセッションのセットアップをトリガするために使用され、セキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、及びキャリアネットワークからのセキュリティ能力要件、のうちの少なくとも１つに基づいて決定される、こととを含むセキュリティポリシー決定方法を提供する。

本出願の第１０の態様は、通信構成要素とプロセッサとを含むモビリティ管理ネットワーク要素を提供する。通信構成要素は、ユーザ機器の要求を受信することであって、このユーザ機器の要求は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別を含む、ことと、エンドツーエンド通信のための要求を送信することであって、このエンドツーエンド通信のための要求は、ユーザ機器の識別を含み、このエンドツーエンド通信のための要求は、セキュリティセッションのセットアップをトリガするために使用され、セキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、及びキャリアネットワークからのセキュリティ能力要件、のうちの少なくとも１つに基づいて決定される、こととを行うように構成される。

実装形態では、モビリティ管理ネットワーク要素がエンドツーエンド通信のための要求を送信する前に、以下のことがさらに含まれる。モビリティ管理ネットワーク要素が、ネットワーク識別を生成する。エンドツーエンド通信のための要求は、ネットワーク識別をさらに含む。

実装形態では、以下のことがさらに含まれる。モビリティ管理ネットワーク要素が、ホーム加入者サーバから、ユーザ識別と、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を取得し、エンドツーエンド通信のための要求内のユーザ機器の識別に基づいて、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を取得する。

実装形態では、エンドツーエンド通信のための要求は、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件をさらに含む。

実装形態では、ユーザ機器の要求は、サービスパラメータ、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つをさらに含む

実装形態では、エンドツーエンド通信のための要求は、サービスパラメータ、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つをさらに含む。

本出願の第１１の態様は、ホーム加入者サーバによって、セキュリティ要件要求を受信することであって、このセキュリティ要件要求はユーザ識別を含み、ホーム加入者サーバは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を格納する、ことと、ホーム加入者サーバによって、ユーザ識別に基づいて、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を決定することと、ホーム加入者サーバによって、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を送信することであって、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件は、セキュリティポリシーを生成するために使用される、こととを含むセキュリティポリシー決定方法を提供する。

本出願の第１２の態様は、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を格納することを行うように構成されたメモリと、ユーザ識別を含むセキュリティ要件要求を受信することを行うように構成された通信構成要素と、ユーザ識別に基づいて、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を決定することを行うように構成されたプロセッサとを含むホーム加入者サーバを提供する。通信構成要素は、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件を送信することを行うようにさらに構成され、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件は、セキュリティポリシーを生成するために使用される。

本出願の第１３の態様は、セッション管理ネットワーク要素によって、エンドツーエンド通信のための要求を受信することであって、このエンドツーエンド通信のための要求は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別を含む、ことと、セッション管理ネットワーク要素によって、セキュリティポリシーを取得することであって、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される、ことと、セッション管理ネットワーク要素によって、第１の鍵を取得することであって、この第１の鍵は、エンドツーエンド通信を保護するために使用され、この第１の鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される、ことと、セッション管理ネットワーク要素によって、セキュリティポリシー及び第１の鍵に基づいて暗号化保護鍵及び／又は完全性保護鍵を生成することであって、暗号化保護鍵は、エンドツーエンド通信の秘匿性を保護するために使用され、完全性保護鍵は、エンドツーエンド通信の完全性を保護するために使用される、ことと、セッション管理ネットワーク要素によって、セキュリティポリシーをユーザ機器に送信することと、セッション管理ネットワーク要素によって、セキュリティポリシーと、暗号化保護鍵及び完全性保護鍵のうちの少なくとも１つをエンドツーエンド通信の他方のエンド上のデバイスに送信することとを含む鍵構成方法を提供する。

本出願の第１４の態様は、エンドツーエンド通信のための要求を受信することを行うように構成された通信構成要素であって、このエンドツーエンド通信のための要求は、エンドツーエンド通信の一方のエンドとして使用されるユーザ機器の識別を含む、通信構成要素と、セキュリティポリシーを取得することであって、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、エンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される、ことと、第１の鍵を取得することであって、この第１の鍵は、エンドツーエンド通信を保護するために使用され、この第１の鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される、ことと、セキュリティポリシー及び第１の鍵に基づいて暗号化保護鍵及び／又は完全性保護鍵を生成することであって、暗号化保護鍵は、エンドツーエンド通信の秘匿性を保護するために使用され、完全性保護鍵は、エンドツーエンド通信の完全性を保護するために使用される、こととを行うように構成されたプロセッサとを含むセッション管理ネットワーク要素を提供する。通信構成要素は、セキュリティポリシーをユーザ機器に送信することと、セキュリティポリシーと、暗号化保護鍵及び完全性保護鍵のうちの少なくとも１つとを、エンドツーエンド通信の他方のエンド上のデバイスに送信することとを行うようにさらに構成される。

実装形態では、セッション管理ネットワーク要素は、ユーザ機器が、セキュリティポリシー及び第１の鍵に基づいて暗号化保護鍵及び／又は完全性保護鍵を生成するように、第１の鍵をユーザ機器に送信する。

実装形態では、以下のことがさらに含まれる。セッション管理ネットワーク要素が、暗号化保護鍵及び／又は完全性保護鍵をユーザ機器に送信する。

本出願の第１５の態様は、ユーザ機器によって、ユーザ機器の識別を含む要求を送信することと、ユーザ機器によって、セキュリティポリシーを搬送する応答を受信することであって、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される、ことと、ユーザ機器によって、暗号化保護鍵及び／又は完全性保護鍵を取得することであって、暗号化保護鍵は、エンドツーエンド通信の秘匿性を保護するために使用され、完全性保護鍵は、エンドツーエンド通信の完全性を保護するために使用される、こととを含む鍵構成方法を提供する。

本出願の第１６の態様は、
ユーザ機器の識別を含む要求を送信することと、セキュリティポリシーを搬送する応答を受信することであって、このセキュリティポリシーは、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、ユーザ機器によってサポートされるセキュリティ能力要件、キャリアネットワークからのセキュリティ能力要件、及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件、のうちの少なくとも１つに基づいて決定される、こととを行うように構成された通信構成要素と、暗号化保護鍵及び／又は完全性保護鍵を取得することを行うように構成されたプロセッサとを含むユーザ機器を提供する。

実装形態では、ユーザ機器によって、暗号化保護鍵及び／又は完全性保護鍵を取得することは、ユーザ機器が、第１の鍵を取得することであって、この第１の鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される、ことと、セキュリティポリシー及び第１の鍵に基づいて、暗号化保護鍵及び／又は完全性保護鍵を生成することとを含む。

実装形態では、ユーザ機器によって、暗号化保護鍵及び／又は完全性保護鍵を取得することは、ユーザ機器が、暗号化保護鍵及び／又は完全性保護鍵を受信することを含む。

本出願の第１７の態様は、キャリアのポリシー制御ネットワーク要素又はモビリティ管理ネットワーク要素によって、セキュリティ保護の終了点を決定すること、セキュリティ保護の終了点がユーザプレーンノードＵＰＦであるとき、ポリシー制御ネットワーク要素又はモビリティ管理ネットワーク要素によって、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つと、キャリアネットワークからのセキュリティ能力要件及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件のうちの少なくとも１つに基づいて、セキュリティポリシーを生成すること、又は、セキュリティ保護の終了点が別のデバイスであるとき、ポリシー制御ネットワーク要素又はモビリティ管理ネットワーク要素によって、別のデバイスのセキュリティ要件と、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つとに基づいて、セキュリティポリシーを生成することであって、別のデバイスは、分岐点又はＵＬＣＬを備える、こととを含むセキュリティポリシー決定方法を提供する。

本出願の第１８の態様は、セキュリティ保護の終了点を決定することと、このセキュリティ保護の終了点がユーザプレーンノードＵＰＦであるとき、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つと、キャリアネットワークからのセキュリティ能力要件及びエンドツーエンド通信の他方のエンド上のデバイスのセキュリティ要件のうちの少なくとも１つとに基づいて、セキュリティポリシーを生成すること、又は、セキュリティ保護の終了点が別のデバイスであるとき、別のデバイスのセキュリティ要件と、ユーザ機器のものであり、かつホーム加入者サーバ上で予め構成されたユーザセキュリティ要件、ユーザ機器からのサービスセキュリティ要件、及びユーザ機器によってサポートされるセキュリティ能力要件、のうちの少なくとも１つとに基づいて、セキュリティポリシーを生成することであって、別のデバイスは、分岐点又はＵＬＣＬを備える、こととを行うように構成されたプロセッサを含むポリシー制御ネットワーク要素又はモビリティ管理ネットワーク要素を提供する。

実装形態では、セキュリティ保護の終了点を決定することは、キャリアネットワーク内の別の機能的ネットワーク要素から受信されたユーザ機器の構成情報若しくはノードポリシーに基づいて、又はローカルストレージから取得されたユーザ機器の構成情報若しくはノードポリシーに基づいて、又は受信されたサービスセキュリティ要件、受信されたサーバ側セキュリティ要件、受信されたサービスタイプ、若しくは受信されたスライシングポリシーに基づいて、セキュリティ保護の終了点を決定することを含む。

実装形態では、ＵＰＦは訪問先公衆陸上モバイル通信ネットワークＶＰＬＭＮ内のＵＰＦであり、キャリアネットワークからのセキュリティ能力要件はＶＰＬＭＮ内のゲートウェイのセキュリティ要件である、又はＵＰＦはホーム公衆陸上モバイル通信ネットワークＨＰＬＭＮ内のＵＰＦであり、キャリアネットワークからのセキュリティ能力要件はＨＰＬＭＮ内のゲートウェイのセキュリティ要件である。

本出願の実施形態又は従来技術における技術的解決策について、より明確に説明するために、以下は、実施形態又は従来技術について説明するために必要とされる添付の図面について簡潔に説明する。以下の説明における添付の図面は、明らかに、本出願のいくつかの実施形態を示し、当業者は、依然として、創意工夫なしに、これらの添付の図面から他の図面を導き出し得る。

将来のモバイル通信ネットワークアーキテクチャの概略図である。 本出願の実施形態によるセキュリティポリシー決定方法のフローチャートである。 本出願の実施形態による別のセキュリティポリシー決定方法のフローチャートである。 本出願の実施形態による別のセキュリティポリシー決定方法のフローチャートである。 本出願の実施形態による別のセキュリティポリシー決定方法のフローチャートである。 本出願の実施形態による別のセキュリティポリシー決定方法のフローチャートである。 本出願の実施形態による別のセキュリティポリシー決定方法のフローチャートである。 本出願の実施形態による鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 本出願の実施形態による別の鍵構成方法のフローチャートである。 分岐シナリオの概略図である。 分岐シナリオの概略図である。 セッションリンクがＵＥ−ＡＮ−ＵＰＦ（ＵＬＣＬ）−ＵＰＦ（アンカー）であるシナリオの概略図である。 ホームルーティングされたローミングシナリオの概略図である。 本出願の実施形態によるセッション管理ネットワーク要素の概略的構造図である。 本出願の実施形態によるユーザ機器の概略的構造図である。

以下は、本発明の実施形態における添付の図面を参照しながら、本発明の実施形態における技術的解決策について説明する。

図１は、将来のモバイル通信ネットワークアーキテクチャを示す。

ユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）は論理的エンティティであり、具体的には、
インテリジェントデバイス、例えば、携帯電話若しくはインテリジェント端末などの端末デバイス、サーバ、ゲートウェイ、基地局、若しくはコントローラなどの通信デバイス、又はセンサ、電力メータ、若しくは水量計などの、モノのインターネット（ＩｏＴ）デバイス
を含み得る。

ＵＥは、アクセスネットワーク（Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ、ＡＮ）を使用することによって、キャリアネットワークにアクセスする。

キャリアネットワークは、
モビリティ管理（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ、ＭＭ）ネットワーク要素と、
セッション、スライス、フロー、又はベアラをセットアップ及び管理することを行うように構成されたセッション管理（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ、ＳＭ）ネットワーク要素と、
ＵＥとの双方向認証を実行することを行うように構成された認証ユニット（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｕｎｉｔ又はＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ、ＡＵ又はＡＦ）であって、ＡＵは、独立した論理的機能的エンティティとして別個に配置されてもよいし、ＭＭ又はＳＭの内部に配置されてもよい、言い換えれば、ＭＭ又はＳＭがＡＵの役割を演じる、ＡＵと、
キャリアのＡＡＡサーバ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ， Ａｕｔｈｏｒｉｚａｔｉｏｎ， Ａｃｃｏｕｎｔｉｎｇ ｓｅｒｖｅｒ、認証、認可、アカウンティングサーバ）、ホーム加入者サーバ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ、ＨＳＳ）、認証センター（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｅｎｔｅｒ、ＡｕＣ）、又は加入者登録情報センター（ｓｕｂｓｃｒｉｂｅｒ ｒｅｐｏｓｉｔｏｒｙ）を含む、キャリアのサーバノード又はホーム加入者サーバであって、説明を簡単にするために、ＡＡＡは、以下で説明のために均一に使用され、また、ＡＡＡは、各ＵＥの認証情報及び加入者情報、例えば、認証ルート鍵、セキュリティアルゴリズム、及び加入者登録情報を格納する、ＡＡＡと、
ポリシー交渉に使用されるポリシー制御（Ｐｏｌｉｃｙ ｃｏｎｔｒｏｌ）ネットワーク要素と、
鍵生成、管理、及び交渉を担当し、合法的通信傍受をサポートする鍵管理センター（Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、ＫＭＳ）であって、ＫＭＳは、独立した論理的機能的エンティティとして別個に配置されてもよいし、ＡＵ、ＭＭ、又はＳＭの内部に配置されてもよい、言い換えれば、ＡＵ、ＭＭ、又はＳＭがＫＭＳの役割を演じる、ＫＭＳと、
ユーザプレーンゲートウェイ（Ｕｓｅｒ Ｐｌａｎｅ−Ｇａｔｅｗａｙ、ＵＰ−ＧＷ）とも称され、キャリアネットワークとデータネットワーク（Ｄａｔａ Ｎｅｔｗｏｒｋ、ＤＮ）を接続することを行うように構成されたゲートウェイであって、ＡＮは、ＧＷを使用することによってＤＮにも接続されてよい、ゲートウェイと、
アプリケーションサーバ、サービスサーバなどを含むＤＮサーバであって、ＤＮサーバは、キャリアネットワーク内に配置されてもよいし、キャリアネットワークの外部に配置されてもよい、ＤＮサーバとを含む。

図１は、ネットワーク要素間の論理的関係を示すことが留意されるべきである。実際には、ＭＭ、ＡＵ、及びＳＭは各々、独立して配置されてもよいし、ペアワイズ統合を通じて１つのエンティティ内に配置されてもよい。例えば、ＳＭ及びＭＭが１つのエンティティ内に配置され、ＡＵが独立して配置される。又は、ＳＭ及びＡＵが１つのエンティティ内に配置され、ＭＭが独立して配置される。

図１におけるアーキテクチャに基づいて、エンド（ＵＥ１）ツーエンド（ゲートウェイ、ＤＮサーバ、又はＵＥ２）通信を保護するために、本出願では、鍵構成装置が、エンドツーエンド通信においてＵＥ１及びゲートウェイ（又はＤＮサーバ又はＵＥ２）のために保護鍵を構成するように、図１に示されるアーキテクチャに追加され、従って、ＵＥ１とゲートウェイ（又はＤＮサーバ又はＵＥ２）の両方が、保護鍵を使用して、通信を暗号化することができる。

鍵構成装置は、セキュリティポリシー決定モジュールと、鍵構成モジュールとを含む。セキュリティポリシー決定モジュールは、エンドツーエンド通信の一方のエンド（具体的に言えば、ＵＥ１）のセキュリティ要件、エンドツーエンド通信の他方のエンド（具体的に言えば、ＤＮサーバ又はＵＥ２）のセキュリティ要件、及びキャリアネットワーク（具体的に言えば、ゲートウェイ）のセキュリティ要件、のうちの少なくとも１つに基づいてセキュリティポリシーを決定することを行うように構成される。鍵構成モジュールは、セキュリティポリシーと、エンドツーエンド通信の一方のエンド（具体的に言えば、ＵＥ１）とキャリアネットワークのネットワーク要素（例えば、ＡＵ、ＫＭＳ、ＳＭ、又はＭＭ）の間の共有鍵とに基づいて、エンド（具体的に言えば、ＵＥ１）ツーエンド（ＤＮサーバ又はＵＥ２）通信を保護するために使用される保護鍵を構成することを行うように構成される。

共有鍵は、ＵＥとキャリアのネットワーク要素（例えば、ＡＵ、ＫＭＳ、ＳＭ、又はＭＭ）の間の、予め構成された共有鍵であってよい。代替として、共有鍵は、ＵＥとキャリアネットワーク内のネットワーク要素（例えば、ＡＵ、ＫＭＳ、ＳＭ、又はＭＭ）の間で双方向認証が実行された後で取得されてよく、次いで、共有鍵は別のネットワーク要素に送信される。例えば、共有鍵は、ＵＥとＡＵの間の双方向認証中に取得され、次いで、ＡＵが、共有鍵をＫＭＳ、ＳＭ、又はＭＭに送信する。又は、共有鍵は、ＵＥとＫＭＳ（又はＳＭ又はＭＭ）の間で双方向認証が実行された後で、別のネットワーク要素に送信されてよい。

例えば、ＬＴＥでは、認証後に取得される共有鍵は、限定するものではないが、ＣＫ、ＩＫ、及びＫａｓｍｅ、のうちの少なくとも１つを含む。共有鍵は、限定するものではないが、ＬＴＥにおける認証後に取得される鍵形式を含む、又は、別の認証方式で、例えば、証明書に基づいて、識別に基づいて、若しくはユーザプレーンパスワードに基づいて、認証が実行された後に取得される共有鍵を含み得る。

具体的には、エンドツーエンド通信の一方のエンド上のＵＥ１のセキュリティ要件は、ＨＳＳ内で予め構成されたＵＥ１のユーザセキュリティ要件（その後の説明を簡単にするために、本出願の実施形態では簡潔にセキュリティ要件１と称される）と、ＵＥ１からのサービスセキュリティ要件（簡潔にセキュリティ要件２と称される）と、ＵＥによってサポートされるセキュリティ能力要件（簡潔にセキュリティ要件５と称される）とを含み、例えば、ＵＥは、ＺＵＣアルゴリズムのみをサポートする。セキュリティ要件１は、ＨＳＳ内で予め構成されたユーザセキュリティ要件であり、ユーザ加入データ内に存在する。セキュリティ要件１は、パラメータとして別個に格納されてもよいし、ＨＳＳ内のユーザＱｏＳ（サービス品質、Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）の一部であってもよい。セキュリティ要件２は、ＵＥ１が通信要求を開始するとき、ＵＥによってキャリアネットワークに送信される。

キャリアネットワーク、具体的に言えばゲートウェイ、のセキュリティ要件は、キャリアネットワーク（ゲートウェイ側）からのセキュリティ能力要件（簡潔にセキュリティ要件３と称される）を含む。セキュリティ要件３は、ポリシー制御ネットワーク要素内に格納され、パラメータとして別個に格納されてもよいし、ポリシー制御ネットワーク要素におけるＱｏＳの一部であってもよいし、又は、ＳＭネットワーク要素内に格納されてもよい。

エンドツーエンド通信の他方のエンド、具体的に言えば、ＤＮサーバ（又はＵＥ２）、のセキュリティ要件（簡潔にセキュリティ要件４と称される）は、以下のとおりである。ＵＥ１が通信をセットアップする、又はＤＮサーバ（又はＵＥ２）が通信セットアップをトリガするとき、ＤＮサーバ又はＵＥ２は、いくつかのシナリオに参加する必要がある、又は、ＤＮサーバ若しくはＵＥ２は、セキュリティ保護要求、例えば、ＺＵＣセキュリティアルゴリズムを使用する要求を行う。

加えて、アプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ、ＡＦ）ネットワーク要素の要件も含まれてよい。ＡＦは、インタフェースを使用することによってＰＣＦとの通信をセットアップする、又は、ＡＦは、別のネットワーク内のオープンネットワーク機能エンティティを使用することによって、モバイル通信ネットワーク内のすべてのネットワーク機能エンティティ（例えば、ＳＭＦ（セッション管理エンティティ、Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）、ＡＭＦ（アクセス及びモビリティ管理エンティティ、Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）、又はＰＣＦ（ポリシー制御ネットワーク要素、Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ））との通信をセットアップする。

具体的には、具体的なセキュリティ要件に関係なく、セキュリティ要件の内容は、セキュリティ保護アルゴリズムを含み、任意選択で、鍵長及び／又は鍵更新時間（例えば、６時間、１２時間、１日、２日、１か月、又は１年）をさらに含んでよい。

具体的には、セキュリティ保護アルゴリズムは、暗号化アルゴリズム及び／又は完全性保護アルゴリズムを含む。例えば、暗号化アルゴリズムは、限定するものではないがヌル（暗号化が実行されないことを示すヌルアルゴリズム）、ＡＥＳ、Ｓｎｏｗ ３Ｇ、又はＺＵＣを含む、暗号化保護を実行するために使用される特定の暗号化アルゴリズムを指定するために使用される。完全性保護アルゴリズムは、限定するものではないが、ヌル（完全性保護が実行されていないことを示すヌルアルゴリズム）、ＡＥＳ、Ｓｎｏｗ ３Ｇ、ＺＵＣ、ＨＭＡＣ、及びＣＭＡＣを含む、完全性保護を実行するために使用される特定の完全性保護アルゴリズムを指定するために使用される。１つのセキュリティ要件内のセキュリティ保護アルゴリズムは、複数の暗号化アルゴリズム及び／又は複数の完全性保護アルゴリズムを含んでよい。この場合、セキュリティ要件は、アルゴリズム優先順位ランキングをさらに含む。言い換えれば、優先する特定のアルゴリズムが指定される。

例えば、保護鍵長は、６４ビット、１２８ビット、２５６ビット、５１２ビットなどを含む。第１の可能性は、以下のとおりである。セキュリティ要件は、１つの保護鍵長のみを含み、保護鍵長は、その後の暗号化及び完全性保護において同じであり、すべて、セキュリティ要件内で定義された保護鍵長である。第２の可能性は、以下のとおりである。セキュリティ要件は、２つの保護鍵長を含む。一方は、暗号化鍵長を指定するために使用され、他方は、完全性保護鍵長を指定するために使用される。

前述のセキュリティ要件のうちのいずれか１つは、具体的には、以下の情報、すなわち、暗号化アルゴリズムが必要とされるかどうか、暗号化鍵長、完全性保護アルゴリズムが必要とされるかどうか、完全性保護鍵長、鍵が更新される必要があるかどうか、及び更新サイクル、のうちの少なくとも１つを含む。

別の可能性は、以下のとおりである。セキュリティ要件又はセキュリティポリシーは、暗号化が必要とされるかどうかと、完全性保護が必要とされるかどうかとを含む、又は、鍵長若しくは鍵更新時間をさらに含んでよい。同様に、最後に決定されるセキュリティポリシーは、暗号化が必要とされるかどうかと、完全性保護が必要とされるかどうかを含んでよく、又は、鍵長若しくは鍵更新時間をさらに含んでよい。

別の可能性は、以下のとおりである。セキュリティ要件又はセキュリティポリシーは、完全性保護が必要とされるかどうかを含み、又は、暗号化が必要とされるかどうか、鍵長、若しくは鍵更新時間をさらに含んでよい。同様に、最後に決定されるセキュリティポリシーは、完全性保護が必要とされるかどうかを含んでよく、又は、暗号化が必要とされるかどうか、鍵長、若しくは鍵更新時間をさらに含んでよい。

別の可能性は、以下のとおりである。セキュリティ要件又はセキュリティポリシーは、暗号化が必要とされるかどうかを含み、又は、完全性保護が必要とされるかどうか、鍵長、若しくは鍵更新時間をさらに含んでよい。同様に、最後に決定されるセキュリティポリシーは、暗号化が必要とされるかどうかを含んでよく、又は、完全性保護が必要とされるかどうか、鍵長、若しくは鍵更新時間をさらに含んでよい。

セキュリティ要件のフォーマットに関して複数の可能性があり得る。具体的なフォーマットのいくつかの可能性が、表１から表５に示されるように、以下に提供される。

表１では、ＥＡは、暗号化アルゴリズムを示し、ＩＡは、完全性保護アルゴリズムを示し、セキュリティ要件ＩＥＩは、セキュリティ要件の識別を示し、セキュリティ要件内容の長さは、セキュリティ要件の内容の長さを示す。

表１から、セキュリティ要件が５つのオクテットを含むことが学習されうる。オクテット１は、セキュリティ要件識別を示すために使用され、オクテット２は、セキュリティ要件内容の長さを示すために使用される。

オクテット３は、暗号化アルゴリズムが必要とされるかどうかと、暗号化鍵長を示すために使用される。オクテット３における最上位ビットの値は、暗号化アルゴリズムが必要とされるかどうかを示すために使用される。０は、暗号化アルゴリズムが必要とされないことを示し、１は、暗号化アルゴリズムが必要とされることを示す。残りの７つのビットは、暗号化鍵長を別個に示すことがある。例えば、表１では、２番目に上位のビットは、暗号化鍵長が１２８であることを示し、以下のビットは、暗号化鍵長が２５６であることなどを別個に示すことがある（表１は、２つの例のみ、すなわち、１２８及び２５６を示し、他の長さは、実際の要件に基づいて設定されてよい）。暗号化鍵長を示すビットの値が０であるとき、それは、そのビットによって示される長さが使用されないことを示し、暗号化鍵長を示すビットの値が１であるとき、それは、そのビットによって示される長さが使用されることを示す。暗号化鍵長を示す複数のビットの値が１である場合、それは、セキュリティ要件が複数の長さの暗号化鍵をサポートすることを示す。

オクテット４は、完全性保護アルゴリズムが必要とされるかどうかと、完全性保護鍵長を示すために使用される。このオクテットにおける最上位ビットの値は、完全性保護アルゴリズムが必要とされるかどうかを示すために使用される。０は、完全性保護アルゴリズムが必要とされないことを示し、１は、完全性保護アルゴリズムが必要とされることを示す。残りの７つのビットは、完全性保護鍵長を別個に示すことがある。例えば、表１では、２番目に上位のビットは、完全性保護鍵長が１２８であることを示し、以下のビットは、完全性保護鍵長が２５６であることなどを別個に示すことがある（表１は、２つの例のみ、すなわち、１２８及び２５６を示し、他の長さは、実際の要件に基づいて設定されてよい）。完全性保護鍵長を示すビットの値が０であるとき、それは、そのビットによって示される長さが使用されないことを示し、完全性保護鍵長を示すビットの値が１であるとき、それは、そのビットによって示される長さが使用されることを示す。完全性保護鍵長を示す複数のビットの値が１である場合、それは、セキュリティ要件が複数の長さの完全性保護鍵をサポートすることを示す。

オクテット５は任意選択であり、鍵が更新される必要があるかどうかと、更新サイクルを示すために使用される。オクテット５における最上位ビットの値は、鍵が更新される必要があるかどうかを示すために使用される。０は、鍵は更新される必要がないことを示し、１は、鍵は更新される必要があることを示す。残りの７つのビットは、更新サイクルを別個に示すことがある。例えば、表１では、２番目に上位のビットは、更新サイクルが２４時間であることを示し、以下のビットは、更新サイクルが４８時間であることなどを別個に示すことがある（表１は、２つの例のみ、すなわち、２４時間及び４８時間を示し、他のサイクルは、実際の要件に基づいて設定されてよい）。更新サイクルを示すビットの値が０であるとき、それは、そのサイクルが使用されないことを示し、更新サイクルを示すビットの値が１であるとき、それは、そのサイクルが使用されることを示す。更新サイクルを示す複数のビットの値が１である場合、それは、セキュリティ要件が複数の更新サイクルをサポートすることを示す。

表１及び以下の表の各々において提供される特定のオクテットの特定のビットによって示される意味は例であることが留意されるべきである。この実施形態では、表における例は、限定のために使用されない。例えば、表１のオクテット３における第６のビット及び第７のビットは、暗号化鍵長を示す。加えて、暗号化鍵長は、オクテット３における別のビットによって示されてもよく、オクテット３における第７のビット及び第６のビットに限定されない。別の例では、表１のオクテット４における第７のビット及び第６のビット以外の他のビットも、完全性保護鍵長を示すために使用されることがある。

表２は、オクテット３からオクテット５の最上位ビットがすべて、ヌルによって示されているという点で、表１と異なる。最上位ビットの値が１である場合、それは、ヌルアルゴリズムを示す。言い換えれば、アルゴリズムは必要とされない。例えば、オクテット３における最上位ビットの値が１である場合、それは、暗号化計算が必要とされないことを示し、オクテット３における最上位ビットの値が０である場合、それは、暗号化計算が必要とされることを示す（代替として、値の意味は交換されてもよい）。代替として、オクテット３及びオクテット４の最上位ビットは鍵長０を表し、最上位ビットの値が１である場合、それは、暗号化が必要とされないことを示す。

表３では、ＥＥＡ０は、発展型パケットシステム（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ、ＥＰＳ）暗号化アルゴリズム０を示し、ＥＥＡは、ＥＰＳ暗号化アルゴリズムを表す。ＥＩＡ０は、ＥＰＳ完全性保護アルゴリズム０を示し、ＥＩＡは、ＥＰＳ完全性アルゴリズムを表す。

ＵＥＡ０は、ユニバーサル移動体通信システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ、ＵＭＴＳ）暗号化アルゴリズム０を示し、ＵＥＡは、ＵＭＴＳ ｅｎｃｒｙｐｔｉｏｎ ａｌｇｏｒｉｔｈｍ、すなわち、ＵＭＴＳ暗号化アルゴリズムを表す。ＵＩＡ０は、ＵＭＴＳ完全性アルゴリズム０を示し、ＵＩＡは、ＵＭＴＳ ｉｎｔｅｇｒｉｔｙ ａｌｇｏｒｉｔｈｍ、すなわち、ＵＭＴＳ完全性アルゴリズムを表す。

スペアは、アイドルビットを示し、０に設定される。

ＧＥＡは、汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ、ＧＰＲＳ）暗号化アルゴリズム、すなわち、ＧＰＲＳ暗号化アルゴリズムを示す。

オクテット５及び６は、任意選択である。例えば、ＵＭＴＳアクセス技術がサポートされる必要があるとき、オクテット５及びオクテット６が含まれる必要があり、ＧＰＲＳアクセス技術がサポートされる必要があるとき、オクテット７が含まれる必要がある。

表１及び表２が、暗号化が必要とされるかどうか、鍵長、及び時間長、のうちの少なくとも１つを示し、表３が特定のサポートされるセキュリティアルゴリズムを示すという点で、表３は、表１及び表２と異なる。

表４は、オクテット８から１０が表３に基づいて追加されるという点で、表３と異なる。オクテット８から１０の定義については、表１を参照されたい。オクテット３から７の定義については、表４を参照されたい。

加えて、オクテット８から１０は、表２におけるオクテット３から５の機能と置き換えられてよい。この場合、オクテット３から５の機能の説明については、表２を参照されたい。

表５は、表５には次世代通信のための暗号化アルゴリズム及び完全性保護アルゴリズムが追加されているという点で、表３と異なる。

ＮＥＡ０は、次世代通信暗号化アルゴリズム０を示し、ＮＥＡは、ｎｅｘｔ−ｇｅｎｅｒａｔｉｏｎ ｅｎｃｒｙｐｔｉｏｎ ａｌｇｏｒｉｔｈｍ、すなわち、次世代暗号化アルゴリズムを表す。ＮＩＡ０は、次世代完全性保護アルゴリズム０を示し、ＮＩＡは、ｎｅｘｔ−ｇｅｎｅｒａｔｉｏｎ ｉｎｔｅｇｒｉｔｙ ａｌｇｏｒｉｔｈｍ、すなわち、次世代完全性アルゴリズムを表す。

加えて、他の可能性は、表４におけるそれに類似した処理機構を含む。表５は、表１と組み合わされて、強化されたセキュリティ要件を反映する。又は、表５は、表２と組み合わされて、強化されたセキュリティ要件を反映する。

前述の表１から３及び表４は、以下の可能性をさらに含む。１つの鍵長のみが含まれ、この場合、暗号化鍵長は、完全性保護鍵長と同じである。

表１から表５は、セキュリティ要件のフォーマットの例にすぎないことが留意されるべきである。加えて、セキュリティ要件は、セキュリティ要件の優先順位（特定のフォーマットにおけるビット値によって示される）などの内容をさらに含むことがあり、又は、セキュリティ要件は、前述の内容のうちの少なくとも１つを含む。

加えて、セキュリティ要件は、セキュリティ終了点を選択する機能をさらに含んでよい。具体的に言えば、１バイトが追加され、１ビットは、ユーザプレーン保護終了点がアクセスネットワークノードであるか、又は、コアネットワークユーザプレーン機能ノードであるかを表す。

加えて、前述のサービスセキュリティ要件及び／又はサーバ側セキュリティ要件のための２つの要件は、暗号化がサービスの上位層で実行されるかどうかを示す特徴を反映してもよい。例えば、サービスが暗号化されるかどうかを示す特徴を実装するために、１バイトが、前述の表現方式で追加されてよい。

鍵構成装置内のセキュリティポリシー決定モジュール及び鍵生成モジュールの機能の特定の実装形態は、以下で図１のネットワーク要素を参照して詳細に別個に説明される。

本出願におけるエンドツーエンド通信の保護は、エンドツーエンドセッション保護を含み、スライス、フロー、又はベアラに基づいたエンドツーエンド保護も含むことが留意されるべきである。エンドツーエンドセッション保護が、説明のために以下で例として使用される。ＵＥ２は以下の図面に含まれないので、以下のＵＥはＵＥ１である。

セキュリティポリシー決定モジュールは、ＵＥ１内、キャリアネットワークにおけるネットワーク要素（例えば、ＡＮ、ＭＭ、ＡＵ、ＫＭＳ、ＡＡＡ、ＳＭ、又はポリシー制御ネットワーク要素）内、ゲートウェイ内、ＤＮにおけるネットワーク要素（例えば、ＤＮサーバ）内、又は、図１に示されるＵＥ２内に配置されてもよい。セキュリティポリシーは、ＵＥのネットワークアタッチメントプロセスにおいて決定されてもよいし、又は、ＵＥがネットワークにアタッチされた後に決定されてもよい。説明は、セキュリティポリシー決定モジュールがポリシー制御ネットワーク要素内に配置されている例と、セキュリティポリシー決定モジュールがＳＭ内に配置されている例を使用することによって、以下で別個に提供される。

図２は、ポリシー制御ネットワーク要素がセキュリティポリシーを決定する（言い換えれば、セキュリティポリシー決定モジュールがポリシー制御ネットワーク要素内に配置される）手順を示し、この手順は、以下のステップを含む。

１．ネットワークアタッチメントプロセスにおいて、ＵＥ１がネットワークにアクセスし、双方向認証が実行された後、ＡＵが、ＡＡＡからセキュリティ要件１を取得する。

ホーム加入者サーバが、ユーザ識別を含むＡＵのセキュリティ要件要求を受信し、ユーザ識別に基づいてセキュリティ要件１を決定して、次いで、セキュリティ要件１をＡＵに送信することが留意されるべきである。

２．ＡＵが、セキュリティ要件１をＭＭに送信する。

３．ＭＭが、ネットワーク識別（Ｉｄｅｎｔｉｔｙ、ＩＤ）、例えば、セッションＩＤを生成し、ＳＭに対するセッション要求を開始する。このセッション要求は、以下を含む。

（ａ）ＵＥ ＩＤ：ユーザを識別するためにネットワークによって使用され、限定するものではないが、ＩＭＥＩ、国際移動体加入者識別（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ、ＩＭＳＩ）、ＩＰマルチメディアプライベート識別（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ、ＩＭＰＩ）、ＴＭＳＩ、ＩＰマルチメディアパブリック識別（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｕｂｌｉｃ Ｉｄｅｎｔｉｔｙ、ＩＭＰＵ）、ユーザのアプリＩＤ、ＭＡＣアドレス、ＩＰアドレス、携帯電話番号、及びＧＵＴＩ、のうちの少なくとも１つを含む。説明を簡単にするために、ＵＥ ＩＤが、その後の実施形態における表現に均一に使用される。

（ｂ）ネットワークＩＤ（任意選択）：手順（例えば、スライス、ベアラ、セッション、又はフロー）を識別するためにユーザが位置付けられるネットワークによって使用され、限定するものではないが、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、及びＰＬＭＮ ＩＤ、のうちの少なくとも１つを含む。

（ｃ）セキュリティ要件１。

（ｄ）サービスパラメータ（任意選択）：ユーザのサービス又はアプリケーション、及び関連サービス特徴を識別するためにネットワークによって使用され、サービスＩＤ、アプリＩＤ、サーバＩＤ、サービス内のシーケンス番号ＳＮ、タイムスタンプ、及びフレッシュパラメータ（フレッシュパラメータ１）、のうちの少なくとも１つを含む。

前述のＵＥ ＩＤ及び／又はサービスパラメータは、ＵＥによってＭＭに送信されたアクセスメッセージからＭＭによって取得されてもよいし、又は、ＡＵ又はＡＡＡから直接的に取得されてもよく、この場合、ＡＵ又はＡＡＡは、ネットワークにアクセスするためにＵＥによって使用されるメッセージから、ＵＥ ＩＤ及び／又はサービスパラメータを取得することが留意されるべきである。

加えて、ＭＭは、ＡＡＡからセキュリティ要件１を直接的に取得し得る。

加えて、ＵＥがネットワークにアクセスするとき、ＵＥは、セキュリティ要件２及び／又はセキュリティ要件５をネットワークに送信してよく、この場合、ＭＭによって送信されるセッション要求も、セキュリティ要件２及び／又はセキュリティ要件５を含む。

４．セッション要求を受信した後、ＳＭが、セキュリティ要件１をポリシー制御ネットワーク要素に送信し、ＵＥ ＩＤ及びネットワークＩＤ（例えば、セッションＩＤ）をポリシー制御ネットワーク要素にさらに送信してよい。

任意選択で、ＳＭは、セキュリティ要件１をポリシー要求メッセージに追加し、このポリシー要求メッセージをポリシー制御ネットワーク要素に送信してよい。任意選択で、要求メッセージは、ＵＥ ＩＤ及びネットワークＩＤのうちの少なくとも１つをさらに含んでよい。

任意選択で、ＳＭが、ＭＭからセキュリティ要件２及び／又はセキュリティ要件５を受信した場合、ＳＭは、セキュリティ要件２及び／又はセキュリティ要件５をポリシー制御に送信する。

５．ポリシー制御ネットワーク要素が、ローカルに予め格納されたセキュリティ要件３を取得する、又は、セキュリティ要件１、セキュリティ要件２、セキュリティ要件３、及びセキュリティ要件５、のうちの少なくとも１つを取得して、セキュリティ要件１及びセキュリティ要件３に基づいて、セキュリティポリシーを決定する。

具体的には、セキュリティポリシーは、以下のルール、すなわち、１つ又は複数のセキュリティ要件の内容に基づいてセキュリティポリシーを決定することに従って決定される。セキュリティポリシーが、１つのセキュリティ要件のみの内容に基づいて決定される場合、セキュリティポリシーの内容は、セキュリティ要件の内容と同じである。セキュリティポリシーが、複数のセキュリティ要件の内容に基づいて決定される場合、以下のルールが守られてよい。

第１に、セキュリティポリシーは、より高いセキュリティのルールに従って決定される。具体的に言えば、複数のセキュリティ要件の内容の中で、より高いセキュリティを伴う内容が、セキュリティポリシーの内容として使用される。

例えば、セキュリティ要件１の内容では保護鍵長が６４であり、セキュリティ要件２の内容では保護鍵長が１２８である場合、セキュリティポリシーでは、１２８が保護鍵長として使用される。

第２に、セキュリティポリシーは、より多くリソースを節約するルールに従って決定される。具体的に言えば、複数のセキュリティ要件の内容の中で、より多くのリソースを節約する内容が、セキュリティポリシーの内容として使用される。

例えば、各セキュリティ要件の内容が暗号化アルゴリズムを含み、いくつかのセキュリティ要件の内容における完全性保護アルゴリズムがヌルである場合、セキュリティポリシーの内容は、暗号化アルゴリズムを含み、完全性保護アルゴリズムは含まない。

第３に、セキュリティポリシーは、セキュリティ要件優先順位に基づいて決定される。具体的に言えば、アルゴリズム優先順位が特定のセキュリティ要件において指定される場合、アルゴリズム優先順位は、セキュリティアルゴリズム交渉のための基礎として使用され、選択された最終的アルゴリズムは、すべてのセキュリティ要件によってサポートされるアルゴリズムであり、このアルゴリズムは、最高の優先順位を有し、セキュリティポリシーの内容として使用される。

代替として、セキュリティポリシー交渉は、主に特定のセキュリティ要件の優先順位に基づいて実行される。例えば、いくつかの暗号化アルゴリズムの優先順位がセキュリティ要件２において指定される場合、セキュリティポリシー内で使用される特定の暗号化アルゴリズムは、指定された優先順位に基づいて決定される。

代替として、アルゴリズム優先順位が複数のセキュリティ要件において指定される場合、特定のセキュリティ要件のアルゴリズム優先順位が、主要な優先順位として使用されてよい。例えば、セキュリティ要件２の優先順位が、主要な優先順位として使用される。

代替として、セキュリティポリシーを決定する前述の方式は、完全性保護が必要とされるかどうか、暗号化が必要とされるかどうか、又は完全性保護及び暗号化が必要とされるかどうかのみを含むセキュリティ要件にも適用可能である。

６．ポリシー制御ネットワーク要素が、セキュリティポリシーをＳＭにフィードバックする。任意選択で、ポリシー制御ネットワーク要素は、セキュリティポリシーをフィードバックのために応答メッセージに追加する。

図２におけるステップ１から３は一実装形態にすぎないことが留意されるべきである。任意選択で、ＳＭが、ＭＭの代わりに、セッションＩＤなどのネットワークＩＤを生成してよい。具体的に言えば、ＳＭが、ＭＭによって送信されたセッション要求を受信した後、セッションＩＤなどのネットワークＩＤを生成する。

図３は、別のセキュリティポリシー決定手順を示す。図２との違いは、以下のとおりである。ネットワークＩＤ及びセキュリティ要件１（及び、場合によっては ＵＥ ＩＤ）に加えて、セッション要求を受信した後、ＳＭは、サービスパラメータ、例えば、サービスＩＤ及びアプリＩＤのうちの少なくとも１つをポリシー制御ネットワーク要素に送信する。セキュリティ要件１を取得した後、ポリシー制御ネットワーク要素は、セキュリティ要件要求をＤＮサーバ又はＵＥ２（図３には示されていない）に送信する。セキュリティ要件要求は、ＵＥ ＩＤ及びサービスパラメータ（例えば、サービスＩＤ又はアプリＩＤ）のうちの少なくとも１つを含む。ポリシー制御ネットワーク要素は、ＤＮサーバ又はＵＥ２によってフィードバックされたセキュリティ要件４を受信する。ポリシー制御ネットワーク要素は、セキュリティ要件１、セキュリティ要件３、及びセキュリティ要件４に基づいて、セキュリティポリシーを決定する。

確かに、ＳＭが、代替として、セキュリティ要件要求をＤＮサーバ又はＵＥ２に送信し、ＤＮサーバ又はＵＥ２によってフィードバックされたセキュリティ要件４を受信してよく、次いで、ＳＭは、セキュリティ要件４をポリシー制御ネットワーク要素に送信する。好ましくは、対話手順を単純化するために、ＳＭは、最初に、セキュリティ要件４を取得し、次いで、セキュリティ要件２とセキュリティ要件４の両方をポリシー制御ネットワーク要素に送信してよい。

図２又は図３では、ステップ１及びステップ２は、ＳＭがセキュリティ要件１ならびにさまざまな識別及びパラメータを取得するプロセスである。加えて、キャリアネットワーク内のネットワーク要素は、セキュリティ要件１ならびにさまざまな識別及びパラメータを他の方式でＳＭにさらに伝送し得る。

第１の方式：

１．双方向認証プロセスにおいて、ＡＵが、ＡＡＡから、ＡＡＡ内に予め格納されたセキュリティ要件１を取得する。

２．ＡＵが、ＭＭを使用することなく直接的に、セッション要求をＳＭに送信する。セッション要求の特定の内容は、図２又は図３に示されている。本明細書では、詳細は再度説明されない。

第２の方式：

１．ＳＭが、ＡＮ、ＡＵ、又はＭＭによって送信されたセッション要求を受信する。セッション要求は、ＵＥ ＩＤ、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含む。

２．ＳＭが、ＵＥ ＩＤに基づいて、予め格納されたセキュリティ要件１をローカルに取得する。

第３の方式：

１．ＳＭが、ＡＮ、ＡＵ、又はＭＭによって送信されたセッション要求を受信する。セッション要求は、ＵＥ ＩＤ、ネットワーク識別、及びサービスパラメータ、のうちの少なくとも１つを含む。

２．ＳＭが、ＡＡＡ、ＭＭ、又はＡＵから、予め格納されたセキュリティ要件１を取得する。

言い換えれば、代替として、セキュリティ要件１は、ＳＭ及びＡＡＡに加えて、図１の別のネットワーク要素内に予め格納されてよい。ＡＡＡは、現在、加入者登録情報を格納することを行うように構成されるので、セキュリティ要件１をＡＡＡ内に予め格納することは、より高いセキュリティと、統合された管理のための利便性という利点を有する。

代替として、セキュリティ要件１が、ポリシー制御ネットワーク要素に加えて、図１の別のネットワーク要素内に予め格納されてよい。ポリシー制御ネットワーク要素は、既存の（例えば、ＬＴＥ）ネットワークアーキテクチャではＱｏＳ交渉に使用されるので、セキュリティ要件３をポリシー制御ネットワーク要素内に予め格納することは、この実施形態におけるセキュリティポリシー決定解決策と既存のポリシー決定手順の間の論理的互換性の実装を容易にする。

前述の方式では、具体的な方式に関係なく、ＨＳＳの遂行方式については、セキュリティ要件１の取得が関係するならば、図２に示される手順を参照されたい。本明細書では、詳細は再度説明されない。

図４は、別のセキュリティポリシー決定手順を示す。図２又は図３との違いは、ＵＥ１がネットワークにアタッチされた後、ＵＥ１がセッション要求を開始することである。この場合、ＵＥ１は、ポリシー制御ネットワーク要素が、より多くのセキュリティ要件に基づいてセキュリティポリシーを決定するように、セキュリティ要件２及び／又はセキュリティ要件５を提供することがある。図４は、以下のステップを含む。

１．ネットワークにアタッチされた後、ＵＥは、ＭＭへのセッション要求を開始する。このセッション要求は、ＵＥ ＩＤと、セキュリティ要件とを含み、任意選択で、ネットワークＩＤ及び／又はサービスパラメータをさらに含んでよい。

具体的には、セキュリティ要件は、セキュリティ要件２及び／又はセキュリティ要件５を含む。ＵＥ ＩＤ、セキュリティ要件、ネットワークＩＤ、及びサービスパラメータの具体的な内容は、上記で説明されたそれと同じである。本明細書では、詳細は再度説明されない。

図２又は図３に示される双方向認証プロセスでは、ＵＥによって送信されるアクセス要求は、セキュリティ要件２及び／又はセキュリティ要件５も搬送し得ることが留意されるべきである。

２．セキュリティ要件１が、ＭＭ内に格納される。セッション要求を受信した後、ＭＭがネットワークＩＤ（例えば、セッションＩＤ）を生成し、ＭＭは、セッション要求をＳＭに送信する。このセッション要求は、セキュリティ要件１と、セキュリティ要件２及び／又はセキュリティ要件５と、ＵＥ ＩＤと、ネットワークＩＤとを含み、サービスパラメータをさらに含んでよい。

３．セッション要求を受信した後、ＳＭが、セキュリティ要件１及びセキュリティ要件２及び／又はセキュリティ要件５をポリシー制御ネットワーク要素に送信し、さらに、ＵＥ ＩＤ及びネットワークＩＤ（例えば、セッションＩＤ）をポリシー制御ネットワーク要素に送信し得る。

４．ポリシー制御ネットワーク要素が、ＳＭによって送信されたセキュリティ要件及びローカルに予め格納されたセキュリティ要件３に基づいて、セキュリティポリシーを決定する。セキュリティポリシーを決定する具体的なルールは、上記で説明されたそれと同じである。本明細書では、詳細は再度説明されない。

５．ポリシー制御ネットワーク要素が、セキュリティポリシーをＳＭに送信する。

図４におけるステップ１から３は一実装形態にすぎないことが留意されるべきである。任意選択で、ＵＥ１によって送信されるセッション要求は、ネットワークＩＤを含まなくてもよく、ＵＥ１のセッション要求を受信した後、ＭＭは、ネットワークＩＤを生成し、ネットワークＩＤをＳＭに送信する。代替として、ＳＭが、ＭＭの代わりにネットワークＩＤを生成してよい。言い換えれば、ＭＭによって送信されたセッション要求を受信した後、ＳＭが、ネットワークＩＤ、例えば、セッションＩＤを生成する。

ＵＥが、セッション要求をＳＭに直接的に送信する。この場合、ＳＭによってセキュリティ要件１を取得する方式については、前述の取得手順を参照されたい。

セキュリティポリシーを決定する具体的な方式については、図３に示されるプロセスを参照されたい。本明細書では、詳細は再度説明されない。

図５は、別のセキュリティポリシー決定手順を示す。図４との違いは、セキュリティ要件４を取得するプロセスが追加されていることである。具体的には、ＵＥ ＩＤ、ネットワークＩＤ、及びセキュリティ要件に加えて、セッション要求を受信した後、ＳＭは、サービスパラメータ、例えば、サービスＩＤ及びアプリＩＤのうちの少なくとも１つをポリシー制御ネットワーク要素に送信する。ＳＭによって送信されたセキュリティ要件を取得した後、ポリシー制御ネットワーク要素が、セキュリティ要件要求をＤＮサーバ又はＵＥ２に送信する。このセキュリティ要件要求は、ＵＥ ＩＤ及びアプリＩＤのうちの少なくとも１つを含む。ポリシー制御ネットワーク要素が、ＤＮサーバ又はＵＥ２によってフィードバックされたセキュリティ要件４を受信する。ポリシー制御ネットワーク要素が、ＳＭによって送信されたセキュリティ要件及びセキュリティ要件４に基づいて、セキュリティポリシーを決定する。

確かに、代替として、ＳＭが、セキュリティ要件要求をＤＮサーバ又はＵＥ２に送信し、ＤＮサーバ又はＵＥ２によってフィードバックされたセキュリティ要件４を受信してよく、次いで、ＳＭは、セキュリティ要件４をポリシー制御ネットワーク要素に送信する。ＳＭがセキュリティ要件４を取得して、セキュリティ要件４をポリシー制御ネットワーク要素に送信する具体的な方式については、図４を参照されたい。本明細書では、詳細は再度説明されない。

図４又は図５に示される実装形態に加えて、ＳＭによってセキュリティ要件１を取得する他の実装形態は、以下をさらに含んでよい。

第１の方式：

１．ＳＭが、ＡＮ、ＡＵ、又はＭＭによって送信されたセッション要求を受信する。このセッション要求は、図４又は図５に示されている。

２．ＳＭが、ＵＥ ＩＤに基づいて、予め格納されたセキュリティ要件１をローカルに取得する。

第２の方式：

１．ＳＭが、ＡＮ、ＡＵ、又はＭＭによって送信されたセッション要求を受信する。このセッション要求は、図４又は図５に示されている。

２．ＳＭが、ＡＡＡ、ＭＭ、又はＡＵから、予め格納されたセキュリティ要件１を取得する。

すべての前述の例は、ポリシー制御ネットワーク要素がセキュリティ要件に基づいてセキュリティポリシーを決定する手順である。セキュリティポリシー決定モジュールは、ポリシー制御ネットワーク要素に加えて、ＳＭ内に配置されてよい。

ＳＭがセキュリティ要件に基づいてセキュリティポリシーを決定するとき、ＳＭがセキュリティ要件１、セキュリティ要件２及び／又は５、ＵＥ ＩＤ、ネットワークＩＤ、ならびにサービスパラメータを取得するプロセスについては、図２から図５を参照されたい。本明細書では、詳細は再度説明されない。ＳＭは、図２から図５に示される方式でセキュリティ要件４を取得し得る。代替として、ポリシー制御ネットワーク要素が、図２から図５に示される方式でセキュリティ要件４を取得し、次いで、ＳＭが、ポリシー制御ネットワーク要素によって送信されたセキュリティ要件４を受信する。ＳＭは、ポリシー制御ネットワーク要素からセキュリティ要件３を取得するために、セキュリティ要件要求（ＵＥ ＩＤ、ネットワークＩＤ、又はサービスパラメータのうちの少なくとも１つを含む）をポリシー制御ネットワーク要素に送信してよい。図６及び図７は、ＳＭがセキュリティポリシーを決定する例にすぎない。すべてのケースが、本明細書に示されるとは限らない。

前述の例では、ポリシー制御ネットワーク要素とＳＭの両方が、少なくとも２つのセキュリティ要件に基づいてセキュリティポリシーを決定する。前述の例とは別に、セキュリティポリシーは、代替として、１つのセキュリティ要件に基づいて決定されてよい。具体的に言えば、少なくとも１つのセキュリティ要件が受信され、セキュリティポリシーが、セキュリティ要件のうちのいくつかのみを使用することによって決定される。又は、少なくとも１つのセキュリティ要件が受信され、セキュリティポリシーが、すべての受信されたセキュリティ要件を使用することによって決定される。これは、本出願のこの実施形態では限定されない。

前述の手順では、ネットワークＩＤ内のセッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤは、キャリアネットワーク内のネットワーク要素、例えば、ＡＮ、ＭＭ、ＡＵ、ＫＭＳ、ＡＡＡ、ＳＭ、又はポリシー制御ネットワーク要素によって生成される。加えて、セッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤは、代替として、ＵＥ１によって生成され、ＵＥ１によってキャリアネットワークに送信されるアタッチメント要求又はセッション要求内で搬送され、キャリアネットワーク内のネットワーク要素、例えば、ＡＮ、ＭＭ、ＡＵ、ＫＭＳ、ＡＡＡ、ＳＭ、又はポリシー制御ネットワーク要素に送信されてよい。例えば、図２では、双方向認証の前に、ＵＥ１が、セッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤを搬送するアタッチメント要求メッセージを、キャリアネットワークに送信する（これは、ＵＥ１がキャリアネットワークにアタッチされるプロセスに属する）。別の例では、図４において、ＵＥ１によってＭＭに送信されるセッション要求が、セッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤをさらに搬送する。

ＵＥ１が、セッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤを生成して、キャリアネットワークに送信するとき、キャリアネットワーク内のネットワーク要素、例えば、ＡＮ、ＭＭ、ＡＵ、ＫＭＳ、ＡＡＡ、ＳＭ、又はポリシー制御ネットワーク要素は、セッションＩＤ、ベアラＩＤ、フローＩＤ、又はスライスＩＤをもはや生成しない。

前述の説明は、例にすぎない。別のネットワーク要素がセキュリティポリシーを決定する機能をどのようにして実施するかについては、前述の図面を参照して、適応性のある調整を実行されたい。本明細書では、詳細は説明されない。

鍵構成モジュールの具体的な作業プロセスが以下で説明される。

鍵構成モジュールは、ＵＥ１、キャリアネットワーク内のネットワーク要素（例えば、ＡＮ、ＭＭ、ＡＵ、ＫＭＳ、ＡＡＡ、ＳＭ、又はポリシー制御ネットワーク要素）、ゲートウェイ、ＤＮ内のネットワーク要素（例えば、ＤＮサーバ）、又はＵＥ２のうちの１つ又は複数に配置され得る。保護鍵の生成パーティは、セキュリティポリシー及び共有鍵Ｋを取得して保護鍵を計算し、保護鍵をＵＥ及びゲートウェイ（又はＤＮサーバ又はＵＥ２）などの他のネットワーク要素に配信する必要がある。具体的には、保護鍵の生成関係者が保護鍵をＫＭＳに送信してよく、ＫＭＳが、保護鍵をＵＥ及びゲートウェイ（又はＤＮサーバ又はＵＥ２）などの他のネットワーク要素に送信する、又は、保護鍵をＵＥ及びゲートウェイ（又はＤＮサーバ又はＵＥ２）などの他のネットワーク要素に直接的に配信してよい。

鍵構成モジュールがＳＭ、ＫＭＳ、又はＵＥのうちの１つ又は複数に配置される例が、説明のために以下で使用される。

図８は、具体的には、以下のステップを含む。

１．ＳＭが、鍵要求メッセージをＫＭＳに送信する。この鍵要求メッセージは、ＵＥ ＩＤと、セキュリティポリシーとを含み、任意選択で、ネットワークＩＤ及び／又はサービスパラメータをさらに含んでよい。ＵＥ ＩＤ、セキュリティポリシー、ネットワークＩＤ、及びサービスパラメータの具体的な内容は、上記で説明されたそれと同じである。本明細書では、詳細は再度説明されない。

セキュリティポリシーを取得する方式については、図２から図７を参照されたい。セキュリティポリシーがポリシー制御ネットワーク要素によって決定される場合、ポリシー制御ネットワーク要素が、セキュリティポリシーをＳＭに送信する。

２．ＫＭＳが、セキュリティポリシー及び共有鍵Ｋに基づいて、保護鍵を計算する。この保護鍵は、ＵＥとゲートウェイ（又はＤＮサーバ又はＵＥ２）の間のセッションを保護するために使用される。

ＫＭＳとＵＥの間の共有鍵Ｋは、ＵＥがネットワークにアクセスし、ＭＭに対するコンテキストをセットアップするプロセスにおいて、ＵＥ及びＫＭＳに割り当てられてもよいし、双方向認証プロセスにおいて、又は双方向認証プロセスの後に、ＵＥ及びＫＭＳに割り当てられてもよいし、ＵＥ及びＫＭＳ上で予め構成されてもよい。

具体的には、セキュリティポリシーの内容は、暗号化アルゴリズム及び完全性保護アルゴリズムのうちの少なくとも１つを含み得るので、１つの保護鍵が、セキュリティポリシーに基づいて計算されてもよく、暗号化及び／若しくは完全性保護に使用されてもよいし、又は、暗号化保護鍵と完全性保護鍵は別個に計算されてもよい。

保護鍵は、以下のとおりである。
Ｋ_SID＝ＫＤＦ（Ｋ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ），ポリシーセット）、又は
Ｋ_SID＝ＫＤＦ（Ｋ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））、又は
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ_SID，暗号化アルゴリズムＩＤ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））、又は
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ_SID，暗号化識別，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））、又は
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ_SID，暗号化アルゴリズムＩＤ）。

ポリシーセットはセキュリティポリシーであり、ＫはＵＥとＫＭＳの間の共有鍵である。

上記で説明されたように、暗号化識別は、文字列であってよく、導出結果が暗号化鍵であることを識別するために使用されてよい。ナンスは、ランダムなパラメータであり、ＫＭＳによって選択されてもよいし、ＵＥによってセッション要求に追加されてもよい。計算に乱数を使用する目的は、鍵のセキュリティ及びランダム性を改善することである。

完全性保護鍵Ｋ_{SID_int}は、以下のとおりである。
Ｋ_{SID_int}＝ＫＤＦ（Ｋ_SID，完全性保護アルゴリズムＩＤ）、又は
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ_SID，完全性保護識別，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））、又は
Ｋ_{SID_int}＝ＫＤＦ（Ｋ_SID，完全性保護アルゴリズムＩＤ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））。

完全性保護識別は、文字列であってよく、導出結果が完全性保護鍵であることを識別するために使用されてよい。

前述のＫＤＦは鍵導出関数であり、限定するものではないが、以下の鍵導出関数、すなわち、ＨＭＡＣ（ＨＭＡＣ−ＳＨＡ２５６及びＨＭＡＣ−ＳＨＡ１など）、ＮＭＡＣ、ＣＭＡＣ、ＯＭＡＣ、ＣＢＣ−ＭＡＣ、ＰＭＡＣ、ＵＭＡＣ、ＶＭＡＣ、ハッシュアルゴリズムなどを含む。加えて、セキュリティポリシーにおける要件が異なり、例えば、セキュリティポリシー１では、保護鍵長は２５６ビットであることが必要とされ、セキュリティポリシー２では、保護鍵長が１２８ビットであることが必要とされる。従って、ＫＭＳは、異なる鍵導出アルゴリズムを使用して、異なるセキュリティポリシーにおける異なる保護鍵長の要件を満たしてよい（例えば、１２８ビットの保護鍵を生成するためにＨＭＡＣ−ＳＨＡ１が使用され、２５６ビットの保護鍵を生成するためにＨＭＡＣ−ＳＨＡ２５６が使用される）。加えて、ＫＭＳは、１つのアルゴリズムのみを使用することによって、ある保護鍵を生成し、次いで、切り捨てること（truncate）、延長することなどを通じて、別の長さの保護鍵を生成し得る。ＫＭＳが保護鍵長を処理する方式は、限定するものではないが、前述の処理方式を含む。

ベアラＩＤ、フローＩＤ、スライスＩＤ、暗号化アルゴリズムＩＤ、及びセッションＩＤなどの前述の使用されるパラメータはすべて、前述のセキュリティ要件２及び／又はセキュリティ要件５とともに、ＵＥによって送信されるセッション要求内で搬送されてよい。

３．ＫＭＳが、ＵＥ ＩＤ及び／又はネットワークＩＤをさらに含み得る保護鍵をＳＭに送信する。

４．ＳＭが、保護鍵、ネットワークＩＤ、及びＵＥ ＩＤを、ゲートウェイ（又はＤＮサーバ又はＵＥ２）及びＵＥ１に配信する。具体的には、ＳＭは、保護鍵をユーザプレーンセットアップ（Ｕｓｅｒ Ｐｌａｎｅ Ｓｅｔｕｐ）メッセージに追加して、このユーザプレーンセットアップメッセージをゲートウェイ（又はサーバ又はＵＥ２）に送信し、保護鍵をセッションセットアップ完了Ｓｅｓｓｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅメッセージに追加して、このセッションセットアップ完了メッセージをＵＥに送信してよい。

代替として、ＫＭＳが、ネットワークＩＤ及び保護鍵をゲートウェイ（又はＤＮサーバ又はＵＥ２）に直接的に送信してもよい。送信されるメッセージは、ＵＥ ＩＤをさらに含んでよい。

ナンスが保護鍵の導出に含まれる場合、ＫＭＳはナンスもＳＭに送信し、次いで、ＳＭがナンスをＵＥに送信する、又は、ＫＭＳがナンスをＵＥに直接的に送信する。

図９は、ＵＥが、ＳＭからセキュリティポリシーを受信して、このセキュリティポリシーに基づいて保護鍵を計算するという点で、図８と異なる。ＵＥが、保護鍵を計算するときにランダムなパラメータを使用する必要がある場合、このランダムなパラメータは、ＫＭＳによってＵＥに送信されてもよいし、ＵＥによって生成されてもよい。

代替として、ＫＭＳが、保護鍵をＭＭに送信してもよい。具体的には、ＭＭは、セッション要求をＳＭに送信し、ＳＭによって送信されたセッション応答を受信した後、セッション保護鍵をＫＭＳに要求してもよい。

代替として、共有鍵Ｋは、ＳＭ上に予め格納されてよい。又は、ＫＭＳが、双方向認証がＵＥとＡＵの間で実行された後、共有鍵Ｋを取得し、次いで、ＫＭＳが共有鍵ＫをＳＭに送信する。ＵＥとＳＭの両方が保護鍵を計算する。

図１０は、本出願の実施形態による別の鍵割り当て方法を示す。この方法は、以下のステップを含む。

１．ＳＭが、鍵要求メッセージをＫＭＳに送信する。この鍵要求メッセージは、ＵＥ ＩＤと、セキュリティポリシーとを含み、任意選択で、ネットワークＩＤ及び／又はサービスパラメータをさらに含んでよい。ＵＥ ＩＤ、セキュリティ要件、ネットワークＩＤ、及びサービスパラメータの具体的な内容は、上記で説明されたそれと同じである。本明細書では、詳細は再度説明されない。

セキュリティポリシーを取得する方式については、図２から図７を参照されたい。セキュリティポリシーがポリシー制御ネットワーク要素によって決定される場合、ポリシー制御ネットワーク要素が、セキュリティポリシーをＳＭに送信する。

２．ＫＭＳが、セキュリティポリシー及び共有鍵Ｋに基づいて、第１の鍵を計算する。この第１の鍵は、ＵＥとゲートウェイ（又はサーバ（ＤＮ又はキャリアネットワーク内のサーバを含み、以下では、簡潔にサーバと称される）、又はコントローラ（ＤＮ又はキャリアネットワーク内のコントローラを含み、以下では、簡潔にコントローラと称される）、又はＵＥ２）の間のセッションを保護するために使用される。

ＫＭＳとＵＥの間の共有鍵Ｋは、ＵＥがネットワークにアクセスし、ＭＭに対するコンテキストをセットアップするプロセスにおいて、ＵＥ及びＫＭＳに割り当てられてもよいし、双方向認証プロセスにおいて、又は双方向認証プロセスの後に、ＵＥ及びＫＭＳに割り当てられてもよいし、又はＵＥ及びＫＭＳ上で予め構成されてもよい。

具体的には、セキュリティポリシーの内容は、暗号化アルゴリズム及び完全性保護アルゴリズムのうちの少なくとも１つを含み得るので、１つの第１の鍵が、セキュリティポリシーに基づいて計算されてもよいし、暗号化及び／若しくは完全性保護に使用されてもよいし、又は、暗号化保護鍵と完全性保護鍵は別個に計算されてもよい。限定するものではないが、以下の方式を含む、セキュリティポリシー及び共有鍵Ｋに基づいて第１の鍵を計算する複数の方式がある。

第１の鍵（具体的に言えば、第１の鍵は、前述の実施形態における保護鍵であり、前述の実施形態との均一性のために、以下では、均一に保護鍵と称される）は、以下のとおりである。
Ｋ_SID＝ＫＤＦ（Ｋ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ），ポリシーセット）、又は
Ｋ_SID＝ＫＤＦ（Ｋ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））。

暗号化保護鍵Ｋ _{SID_enc} は、以下のとおりである。
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ，（暗号化アルゴリズムＩＤ、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））、又は
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ，（暗号化識別、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））。

ポリシーセットはセキュリティポリシーであり、ＫはＵＥとＫＭＳの間の共有鍵である。ＵＥ ＩＤの定義は、前述の実施形態において説明されたそれと同じである。

上記で説明されたように、暗号化識別は、文字列であってよく、導出結果が暗号化鍵であることを識別するために使用されてよい。ナンスは、ランダムなパラメータであり、ＫＭＳによって選択されてもよいし、ＵＥによってセッション要求に追加されてもよい。計算に乱数を使用する目的は、鍵のセキュリティ及びランダム性を改善することである。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてよい。一方のナンスは、ＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又は、ＳＭによってＵＥに送信される）、他方のナンスは、ＵＥからである（ＵＥによってセッション要求に追加される）。

完全性保護鍵Ｋ_{SID_int}は、以下のとおりである。
Ｋ_{SID_int}＝ＫＤＦ（Ｋ，（完全性保護識別、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））、又は
Ｋ_{SID_int}＝ＫＤＦ（Ｋ，（完全性保護アルゴリズムＩＤ、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））。

完全性保護識別は、文字列であってよく、導出結果が完全性保護鍵であることを識別するために使用されてよい。ナンスは、ランダムなパラメータであり、ＫＭＳによって選択されてもよいし、ＵＥによってセッション要求に追加されてもよい。計算に乱数を使用する目的は、鍵のセキュリティ及びランダム性を改善することである。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてよい。一方のナンスは、ＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又は、ＳＭによってＵＥに送信される）、他方のナンスは、ＵＥからである（ＵＥによってセッション要求に追加される）。

ベアラＩＤ、フローＩＤ、スライスＩＤ、及びセッションＩＤなどの前述の使用されるパラメータは、前述のセキュリティ要件２及び／又はセキュリティ要件５とともに、ＵＥによって送信されるセッション要求内で搬送されてもよいし、初めてキャリアネットワークにアクセスするためのＵＥの要求内で搬送されてもよいし、鍵要求メッセージ内で搬送されてもよい。加えて、暗号化アルゴリズムＩＤ及び完全性保護アルゴリズムＩＤは、セキュリティポリシーの内容であってよい。

３．ＫＭＳが、ステップ２において取得された鍵（具体的に言えば、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵Ｋ_{SID_int}、のうちの少なくとも１つ）と、場合によってはＵＥ ＩＤ及び／又はネットワークＩＤをＳＭに送信する。

４．ＳＭが、ステップ２において取得された鍵（具体的に言えば、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵Ｋ_{SID_int}、のうちの少なくとも１つ）をゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥ１に配信する。メッセージは、ネットワークＩＤ、ＵＥ ＩＤ、及びセキュリティポリシー、のうちの少なくとも１つをさらに含んでよい。具体的には、ＳＭは、保護鍵をユーザプレーンセットアップ（Ｕｓｅｒ Ｐｌａｎｅ Ｓｅｔｕｐ）メッセージに追加し、このユーザプレーンセットアップメッセージをゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）に送信してもよい。

代替として、ステップ４では、ＳＭは、ステップ２において取得された鍵をＵＥに送信しないが、以下のステップを引き続き実行する。

５．ＳＭが、セキュリティポリシーをＵＥに送信する。メッセージは、ネットワークＩＤ及びＵＥ ＩＤのうちの少なくとも１つをさらに含んでよい。

６．ＵＥが、セキュリティポリシーをＳＭ（又はポリシー制御又はＫＭＳ）から受信し、前述の方式と同じ方式で、セキュリティポリシーに基づいて、Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵Ｋ_{SID_int}、のうちの少なくとも１つを計算する。ＵＥが、保護鍵を計算するときにランダムなパラメータを使用する必要がある場合、このランダムなパラメータは、ＵＥにＫＭＳによって送信されてもよいし、ＵＥによって生成されてもよい。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスはＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又はＳＭによってＵＥに送信される）、他方のナンスはＵＥからである（ＵＥによってセッション要求に追加される）。

ＵＥが、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵、のうちの少なくとも１つをＳＭから生成又は取得することが、上記で開示されている。加えて、ＵＥは、ＫＭＳ（又はポリシー制御ネットワーク要素）から、セキュリティポリシーと、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵、のうちの少なくとも１つを受信してよい。

図１１は、本出願の実施形態による別の鍵構成方法を示す。この方法は、以下のステップを含む。

１．ＳＭが、鍵要求メッセージをＫＭＳに送信する。この鍵要求メッセージは、ＵＥ ＩＤと、セキュリティポリシーとを含み、任意選択で、ネットワークＩＤ及び／又はサービスパラメータをさらに含んでよい。ＵＥ ＩＤ、セキュリティ要件、ネットワークＩＤ、及びサービスパラメータの具体的な内容は、上記で説明されたそれと同じである。本明細書では、詳細は再度説明されない。

セキュリティポリシーを取得する方式については、図２から図７を参照されたい。セキュリティポリシーがポリシー制御ネットワーク要素によって決定される場合、ポリシー制御ネットワーク要素が、セキュリティポリシーをＳＭに送信する。

２．ＫＭＳが、セキュリティポリシー及び共有鍵Ｋに基づいて、保護鍵を計算する。この保護鍵は、ＵＥとゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）の間のセッションを保護するために使用される。

ＫＭＳとＵＥの間の共有鍵Ｋは、ＵＥがネットワークにアクセスし、ＭＭに対するコンテキストをセットアップするプロセスにおいて、ＵＥ及びＫＭＳに割り当てられてもよいし、双方向認証プロセスにおいて、又は双方向認証プロセスの後に、ＵＥ及びＫＭＳに割り当てられてもよいし、ＵＥ及びＫＭＳ上で予め構成されてもよい。

具体的には、セキュリティポリシーの内容は、暗号化アルゴリズム及び完全性保護アルゴリズムのうちの少なくとも１つを含み得るので、１つの保護鍵が、セキュリティポリシーに基づいて計算されてもよく、暗号化及び／若しくは完全性保護に使用されてもよいし、又は、暗号化保護鍵と完全性保護鍵は別個に計算されてもよい。限定するものではないが、以下の方式を含む、セキュリティポリシー及び共有鍵Ｋに基づいて保護鍵を計算する複数の方式がある。

保護鍵は、以下のとおりである。
Ｋ_SID＝ＫＤＦ（Ｋ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ），ポリシーセット）、又は
Ｋ_SID＝ＫＤＦ（Ｋ，（ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、及びナンス、のうちの少なくとも１つ））。

ベアラＩＤ、フローＩＤ、スライスＩＤ、暗号化アルゴリズムＩＤ、及びセッションＩＤなどの前述の使用されるパラメータは、前述のセキュリティ要件２及び／又はセキュリティ要件５とともに、ＵＥによって送信されたセッション要求内で搬送されてもよいし、又は、初めてキャリアネットワークにアクセスするためのＵＥの要求内で搬送されてもよいし、又は、鍵要求メッセージ内で搬送されてもよい。加えて、暗号化アルゴリズムＩＤ及び完全性保護アルゴリズムＩＤは、セキュリティポリシーの内容であってよい。ナンスは、ランダムなパラメータであり、ＫＭＳによって選択されてもよいし、ＵＥによってセッション要求に追加されてもよい。計算に乱数を使用する目的は、鍵のセキュリティ及びランダム性を改善することである。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスはＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又はＳＭによってＵＥに送信される）、他方のナンスはＵＥからである（ＵＥによってセッション要求に追加される）。

３．ＫＭＳが、ＵＥ ＩＤ及び／又はネットワークＩＤをさらに含み得る保護鍵Ｋ_SIDをＳＭに送信する。

４．ＳＭが、セキュリティポリシー及びＫ _SID に基づいて、暗号化保護鍵及び／又は完全性保護鍵を計算する。計算方式は、限定するものではないが、以下の方式を含む。

暗号化保護鍵Ｋ_{SID_enc}は、以下のとおりである。
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ_SID，（暗号化アルゴリズムＩＤ、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））、又は
Ｋ_{SID_enc}＝ＫＤＦ（Ｋ_SID，（暗号化識別、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））。

ポリシーセットはセキュリティポリシーであり、ＫはＵＥとＫＭＳの間の共有鍵である。ＵＥ ＩＤは、上記で説明されたそれと同じである。暗号化識別は、文字列であってよく、導出結果が暗号化鍵であることを識別するために使用されてよい。ナンスは、ランダムなパラメータであり、ＫＭＳによって選択されてもよいし、ＵＥによってセッション要求に追加されてもよい。計算に乱数を使用する目的は、鍵のセキュリティ及びランダム性を改善することである。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスは、ＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又は、ＳＭによってＵＥに送信される）、他方のナンスは、ＵＥからである（ＵＥによってセッション要求に追加される）。

完全性保護鍵Ｋ_{SID_int}は、以下のとおりである。
Ｋ_{SID_int}＝ＫＤＦ（Ｋ_SID，（完全性保護識別、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））、又は
Ｋ_{SID_int}＝ＫＤＦ（Ｋ_SID，（完全性保護アルゴリズムＩＤ、ＵＥ ＩＤ、セッションＩＤ、ベアラＩＤ、フローＩＤ、スライスＩＤ、ＰＬＭＮ ＩＤ、サービスパラメータ、ナンス、及びポリシーセット、のうちの少なくとも１つ））。

完全性保護識別は、文字列であってよく、導出結果が完全性保護鍵であることを識別するために使用されてよい。ナンスは、ランダムなパラメータであり、ＫＭＳによって選択されてもよいし、ＵＥによってセッション要求に追加されてもよい。計算に乱数を使用する目的は、鍵のセキュリティ及びランダム性を改善することである。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスは、ＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又は、ＳＭによってＵＥに送信される）、他方のナンスは、ＵＥからである（ＵＥによってセッション要求に追加される）。

ベアラＩＤ、フローＩＤ、スライスＩＤ、及びセッションＩＤなどの前述の使用されるパラメータは、前述のセキュリティ要件２及び／又はセキュリティ要件５とともに、ＵＥによって送信されるセッション要求内で搬送されてもよいし、初めてキャリアネットワークにアクセスするためのＵＥの要求内で搬送されてもよいし、鍵要求メッセージ内で搬送されてもよい。加えて、暗号化アルゴリズムＩＤ及び完全性保護アルゴリズムＩＤは、セキュリティポリシーの内容であってよい。

５．ＳＭが、ステップ４において取得された鍵（具体的に言えば、暗号化保護鍵Ｋ_{SID_enc}及び完全性保護鍵Ｋ_{SID_int}のうちの少なくとも１つ）をゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥ１に配信する。メッセージは、ネットワークＩＤ、ＵＥ ＩＤ、及びセキュリティポリシー、のうちの少なくとも１つをさらに含んでよい。具体的には、ＳＭは、保護鍵をユーザプレーンセットアップ（Ｕｓｅｒ Ｐｌａｎｅ Ｓｅｔｕｐ）メッセージに追加して、このユーザプレーンセットアップメッセージをゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）に送信し、保護鍵をセッションセットアップ完了Ｓｅｓｓｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅメッセージに追加して、このセッションセットアップ完了メッセージをＵＥに送信してよい。

さらに、ステップ５では、ＳＭは、ステップ４において取得された鍵をＵＥに送信しないことがあるが、以下の２つの手順のいずれか１つを実行する。

第１の可能な手順では、ＳＭが、セキュリティポリシーをＵＥに送信する。メッセージは、ネットワークＩＤ及びＵＥ ＩＤのうちの少なくとも１つをさらに含んでよい。ＵＥが、前述の実施形態におけるそれと同じ方式で、セキュリティポリシーをＳＭ（又はポリシー制御又はＫＭＳ）から受信し、セキュリティポリシーに基づいて保護鍵を計算する。ＵＥが、保護鍵を計算するときにランダムなパラメータを使用する必要がある場合、このランダムなパラメータは、ＫＭＳによってＵＥに送信されてもよいし、ＵＥによって生成されてもよい。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスはＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又はＳＭによってＵＥに送信される）、他方のナンスはＵＥからである（ＵＥによってセッション要求に追加される）。

第２の可能な手順では、ＳＭが、ＫＳＩＤ及びセキュリティポリシーをＵＥに送信し、前述の実施形態におけるそれと同じ方式で、ＵＥが、ＫＳＩＤ及びセキュリティポリシーをＳＭ（又はポリシー制御又はＫＭＳ）から受信し、セキュリティポリシーに基づいて保護鍵を計算する。ＵＥが、保護鍵を計算するときにランダムなパラメータを使用する必要がある場合、このランダムなパラメータは、ＫＭＳによってＵＥに送信されてもよいし、ＵＥによって生成されてもよい。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスはＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又はＳＭによってＵＥに送信される）、他方のナンスはＵＥからである（ＵＥによってセッション要求に追加される）。

ＵＥが、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵Ｋ_{SID_int}、のうちの少なくとも１つをＳＭから生成又は取得することが、上記で開示されている。加えて、ＵＥは、ＫＭＳ（又はポリシー制御ネットワーク要素）から、セキュリティポリシーと、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵、のうちの少なくとも１つとを受信してよい。

前述のプロセスから、図１１は、導出を通じてＫ_SIDを取得した後、ＫＭＳがＫ_SIDをＳＭに送信し、次いで、ＳＭが、Ｋ_SIDに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得し、暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}をエンドツーエンド通信の２つのエンドに送信するという点で、図８から図１０と異なることが学習されうる。言い換えれば、２つの異なるネットワーク要素デバイスは各々、１つの鍵導出を実行する。

図１２は、導出を通じてＫ_SIDを取得した後、ＫＭＳが、Ｋ_SIDをＳＭに送信し、次いで、ＳＭが、Ｋ_SIDをゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥに送信し、ゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥ１が、Ｋ_SIDに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得するという点で、図１１と異なる。

代替として、ＳＭは、Ｋ_SIDに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得し、Ｋ_{SID_enc}及びＫ_{SID_int}をＵＥに送信してよい。

代替として、ＳＭはセキュリティポリシーのみをＵＥに送信してよく、ＵＥは、セキュリティポリシーに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得する。

メッセージ内の別のパラメータの伝達式及び導出式については、図１１に対応する実施形態を参照されたい。前述のメッセージは、セキュリティポリシー、ネットワークＩＤ、及びＵＥ ＩＤのうちの少なくとも１つを含んでよい。

図１３は、ＳＭが共有鍵を格納し、導出を通じてＫ_SIDを取得して、次いで、Ｋ_SIDに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得し、暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}をゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥに送信するという点で、図１１と異なる。

代替として、ＳＭはＫ_SID及びセキュリティポリシーをＵＥに送信してもよく、ＵＥは、導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得する。

代替として、ＳＭはセキュリティポリシーのみをＵＥに送信してもよく、ＵＥは、セキュリティポリシーに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得する。

メッセージ内の別のパラメータの伝達式及び導出式については、図１１を参照されたい。前述のメッセージは、セキュリティポリシー、ネットワークＩＤ、及びＵＥ ＩＤ、のうちの少なくとも１つを含む。

図１４は、導出を通じてＫ_SIDを取得した後、ＳＭが、Ｋ_SIDをゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥに送信し、次いで、ゲートウェイ（又はサーバ、又はコントローラ、又はＵＥ２）及びＵＥが、Ｋ_SIDに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得するという点で、図１１と異なる。

代替として、ＳＭは、Ｋ_SIDに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得してもよく、Ｋ_{SID_enc}及びＫ_{SID_int}をＵＥに送信する。

代替として、ＳＭはセキュリティポリシーのみをＵＥに送信してもよく、ＵＥは、セキュリティポリシーに基づいた導出を通じて暗号化保護鍵Ｋ_{SID_enc}及び／又は完全性保護鍵Ｋ_{SID_int}を取得する。

メッセージ内の別のパラメータの伝達式及び導出式については、図１１に対応する実施形態を参照されたい。前述のメッセージは、セキュリティポリシー、ネットワークＩＤ、及びＵＥ ＩＤ、のうちの少なくとも１つを含んでよい。

前述の実施形態は、主に、ＫＭＳ又はＳＭが鍵導出を実行する例を使用することによって示されていることが留意されるべきである。加えて、保護鍵は、導出を通じて、ＵＥ、ＡＮ、ＭＭ、ＡＵ、ＫＭＳ、ＡＡＡ、ＳＭ、又はポリシー制御ネットワーク要素によって取得されてよい。

ＭＭが導出を通じて保護鍵を生成するプロセスについては、前述の実施形態においてＳＭが導出を通じて保護鍵を生成するプロセスを参照されたい。

ポリシー制御ネットワーク要素は、ＫＭＳの前述の手順と同じである、具体的に言えば、鍵要求を受信した後に鍵導出を実行する手順を使用することによって、鍵導出を実行し得る。代替として、ポリシー制御ネットワーク要素は、セキュリティポリシーを決定した直後にセキュリティ鍵導出を実行してよい。手順は、図１５に示されている。

図１５は、ポリシー制御ネットワーク要素が導出を通じて保護鍵を生成するプロセスを示す。このプロセスは、以下のステップを含む。

１．ポリシー制御ネットワーク要素が、セキュリティポリシーを決定した後、又はセキュリティポリシーをＳＭから受信した後、導出を通じて鍵を生成する。具体的には、ポリシー制御ネットワーク要素は、Ｋ_SID、Ｋ_{SID_enc}、及びＫ_{SID_int}、のうちの少なくとも１つを直接的に計算してもよいし、最初にＫ_SIDを計算し、次いで、Ｋ_SIDに基づいてＫ_{SID_enc}及びＫ_{SID_int}のうちの少なくとも１つを計算してもよい。ポリシー制御ネットワーク要素は、端末が認証を実行した後、別のネットワーク要素（ＫＭＳ、ＡＵ、ＳＭ、ＭＭ、又はＡＡＡ）から共有鍵を受信してもよいし、又は、共有鍵を取得するために、鍵要求であって、ＵＥ ＩＤを保護する要求を開始してもよい。

導出を通じて鍵を生成する具体的な方式については、前述の実施形態を参照されたい。

２．ポリシー制御ネットワーク要素が、生成された鍵（と、場合によってはセキュリティポリシー）をＳＭに送信し、次いで、ＳＭが、鍵をエンドツーエンド通信の２つのエンドに送信する。

代替として、ポリシー制御ネットワーク要素が、生成された鍵（と、場合によってはセキュリティポリシー）を、ＳＭを使用することによってＵＥに送信し、次いで、生成された鍵をエンドツーエンド通信の他のエンドに直接的に送信する。

代替として、ポリシー制御ネットワーク要素は、保護鍵（と、場合によってはセキュリティポリシー）をＵＥに直接的に送信する。

代替として、ポリシー制御ネットワーク要素がＫ_SIDをＳＭに送信し、次いで、ＳＭが導出を実行し、Ｋ_{SID_enc}及びＫ_{SID_int}を２つのエンドに送信する。

ＵＥが導出を通じて保護鍵を生成するとき、ＵＥは、前述の実施形態におけるそれと同じ方式で、ＳＭ（又はポリシー制御又はＫＭＳ）からセキュリティポリシーを受信して、セキュリティポリシーに基づいて保護鍵を計算する。ＵＥが、保護鍵を計算するときにランダムなパラメータを使用する必要がある場合、このランダムなパラメータは、ＫＭＳによってＵＥに送信されてもよいし、ＵＥによって生成されてもよい。代替として、２つのナンスのうちの少なくとも１つが、鍵導出に含まれてもよい。一方のナンスは、ＫＭＳからであり（ＫＭＳによって選択され、ＵＥに直接的に送信される、又は、ＳＭによってＵＥに送信される）、他方のナンスは、ＵＥからである（ＵＥによってセッション要求に追加される）。

代替として、ＵＥは、保護鍵Ｋ_SID、暗号化保護鍵Ｋ_{SID_enc}、及び完全性保護鍵Ｋ_{SID_int}のうちの少なくとも１つをＳＭ（又はポリシー制御又はＫＭＳ）から受信する、又は、Ｋ_SIDを受信した後、ＵＥは、Ｋ_SIDに基づいた計算を通じて、Ｋ_{SID_enc}及びＫ_{SID_int}を取得する。

導出においてＵＥによって使用されるベアラＩＤ、フローＩＤ、スライスＩＤ、及びセッションＩＤなどの前述のパラメータは、ＵＥ内に存在してもよいし、ネットワーク要素（ＫＭＳ、ＭＭ、ＳＭ、ポリシー制御、ＡＵ、ゲートウェイ、ＡＡＡなど）によってＵＥに送信されてもよい、例えば、セッション応答メッセージを使用することによってＵＥに送信されてもよい。

前述のセキュリティポリシーが、完全性保護が必要とされるかどうか、暗号化が必要とされるかどうか、又は完全性保護及び暗号化が必要とされるかどうかを示すセキュリティ要件のみを含むことを考慮すると、ＳＭＦがセキュリティポリシーを取得した（ＰＣＦから取得されてもよいし、交渉を通じてＳＭＦによって取得されてもよい）後、その後の処理のための以下の３つの可能性がある。

可能性１：セキュリティポリシーを取得した後、ＳＭＦが、ＵＥのセキュリティ能力と、ＳＭＦ上に格納されるＵＰＦアルゴリズム優先順位に基づいて、セキュリティアルゴリズム（暗号化アルゴリズム、又は完全性保護アルゴリズム、又は暗号化アルゴリズムと完全性保護アルゴリズムの両方を含む）を決定し、次いで、セキュリティ鍵（暗号化鍵、又は完全性保護鍵、又は暗号化鍵と完全性保護鍵の両方を含む）を生成して、決定されたセキュリティアルゴリズム及び生成された鍵をＵＰＦに送信する。加えて、ＳＭＦは、ＵＥが、セキュリティアルゴリズムに対応するセキュリティ鍵を生成するように、決定されたセキュリティアルゴリズムをＵＥにも送信することがある。ＳＭＦは、セキュリティポリシーもＵＥに送信することがある。

可能性２：ＳＭＦが、鍵Ｋ＿ＳＩＤを計算し、セキュリティポリシー及びＫ＿ＳＩＤをＵＰＦに送信する。同様に、ＵＰＦは、ＳＭＦを使用することによって、ＵＥのセキュリティ能力も受信し得る。ＵＰＦは、ＵＥのセキュリティ能力及びアルゴリズム優先順位に基づいて、セキュリティアルゴリズム（暗号化アルゴリズム、又は完全性保護アルゴリズム、又は暗号化アルゴリズムと完全性保護アルゴリズムの両方を含む）を決定し、次いで、セキュリティ鍵（暗号化鍵、又は完全性保護鍵、又は暗号化鍵と完全性保護鍵の両方を含む）を生成する。ＵＰＦがセキュリティアルゴリズムをＳＭＦに送信し、ＳＭＦがセキュリティアルゴリズムをＵＥに送信し、従って、ＵＥが、セキュリティアルゴリズムに対応するセキュリティ鍵を生成する。代替として、ＵＰＦは、ＵＥが、セキュリティアルゴリズムに対応するセキュリティ鍵を生成するように、セキュリティアルゴリズムをＵＥに直接的に送信してもよい。

可能性３：セキュリティポリシーを取得した後、ＳＭＦは、セキュリティポリシーをＡＮに送信し、従って、ＡＮは、セキュリティポリシー、ＵＥのセキュリティ能力、及びＡＮのアルゴリズム優先順位リストに基づいてＵＥとＡＮの間のセキュリティ保護アルゴリズムを決定し、次いで、ＡＮは、セキュリティ保護アルゴリズムをＵＥに送信し、従って、ＵＥが、セキュリティアルゴリズムに対応するセキュリティ鍵を生成する。

上記で説明されたように、前述のものは、ＵＥとＵＰＦの間のデータ保護のためのセキュリティポリシー交渉及び配信手順を示す。ＵＥとＡＮの間のデータ保護のためのセキュリティポリシー交渉及び配信手順は、ＵＥとＵＰＦの間のものに類似しており、違いは以下のとおりである。ＡＮのセキュリティ能力又はＡＮのアルゴリズム優先順位リストは、セキュリティポリシーの決定において考慮される必要がある。加えて、セキュリティポリシーは、決定されたセキュリティアルゴリズムであってもよいし、完全性保護が必要とされるかどうか、又は暗号化が必要とされるかどうか、又は暗号化と完全性保護の両方が必要とされるかどうか、であってもよい。

上記で説明されたように、最後に決定されるセキュリティポリシーは、暗号化アルゴリズムの優先順位リスト、又は完全性保護アルゴリズムの優先順位リスト、又は暗号化及び完全性保護アルゴリズムの優先順位リストを含む、セキュリティアルゴリズムの優先順位リストであってよい。次いで、ＵＰＦは、ＵＥのセキュリティ能力、セキュリティアルゴリズムの優先順位リスト、及びＵＰＦのセキュリティ能力に基づいて、ＵＰＦのセキュリティ保護アルゴリズムを決定し得る。他のその後の手順は、前述の実施形態における手順と同じである。

上記で説明されたように、最後に決定されるセキュリティポリシーは、暗号化アルゴリズムの優先順位リスト、又は完全性保護アルゴリズムの優先順位リスト、又は暗号化及び完全性保護アルゴリズムの優先順位リストを含む、セキュリティアルゴリズムの優先順位リストであってよい。次いで、ＡＮは、ＵＥのセキュリティ能力、セキュリティアルゴリズムの優先順位リスト、及びＡＮのセキュリティ能力に基づいて、ＡＮのセキュリティ保護アルゴリズムを決定し得る。他のその後の手順は、前述の実施形態における手順と同じである。

上記で説明されたように、前述の図面は、エンドツーエンドセッション保護を例として使用することによって説明されているにすぎない。ベアラ、フロー、又はスライスのエンドツーエンド保護については、手順は、前述の図面におけるそれと類似しているが、前述の図面におけるセッションパラメータは、対応するパラメータと置き換えられる必要があることが強調されるべきである。具体的には、セッションＩＤは、それに対応して、ベアラＩＤ、フローＩＤ、又はスライスＩＤと置き換えられ、ユーザプレーンセットアップメッセージは、それと対応して、ベアラセットアップメッセージ、フローセットアップメッセージ、又はスライスセットアップメッセージと置き換えられる。

鍵交渉手順とセキュリティポリシー交渉手順の間の特定のシーケンスはない。例えば、鍵Ｋ_SIDは、セッション（ベアラ、フロー、又はスライス）セットアップの前に生成されてもよいし、その間に生成されてもよいし、その後に生成されてもよい。暗号化及び／又は完全性保護鍵は、Ｋ_SIDが生成された後の任意の時点で生成されてよい。

ＵＥ１が、セッション要求、ベアラ要求、フロー要求、又はスライス要求をキャリアネットワークに送信し、キャリアネットワークが要求を受け入れるとき、図４、図５、及び図７に示されるすべての手順は、セキュリティポリシー決定プロセス又は鍵構成プロセスである。キャリアネットワークがＵＥ１のセッション要求、ベアラ要求、フロー要求、又はスライス要求を拒否する場合、キャリアネットワークは拒否メッセージをＵＥ１に送信することが留意されるべきである。

図２から図９に示される手順では、使用されるセキュリティ要件は、セキュリティ保護の終了点がユーザプレーンノード（Ｕｓｅｒ ｐｌａｎｅ ｆｕｎｃｔｉｏｎ、ＵＰＦ）であるケースに基づいている。しかしながら、セキュリティ保護の終了点は、代替として、分岐点又はＵＬＣＬであってよい。

セキュリティ保護の終了点は、モビリティ管理（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ、ＭＭ）ネットワーク要素、セッション管理（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ、ＳＭ）ネットワーク要素、認証サービスコントローラ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ、ＡＵＳＦ）、セキュリティアンカー機能（Ｓｅｃｕｒｉｔｙ Ａｎｃｈｏｒ Ｆｕｎｃｔｉｏｎ、ＳＥＡＦ）ネットワーク要素、モビリティ管理エンティティ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ）、ホーム加入者サーバ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ、ＨＳＳ）、認証センター（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｅｎｔｅｒ、ＡｕＣ）、認証クレデンシャルリポジトリ及び処理機能（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｒｅｄｅｎｔｉａｌ Ｒｅｐｏｓｉｔｏｒｙ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ Ｆｕｎｃｔｉｏｎ、ＡＲＰＦ）ネットワーク要素、セキュリティコンテキスト管理機能（Ｓｅｃｕｒｉｔｙ Ｃｏｎｔｅｘｔ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＳＣＭＦ）ネットワーク要素、アクセス及びモビリティ管理機能（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＡＭＦ）ネットワーク要素、アクセスノード（Ａｃｃｅｓｓ ｎｅｔｗｏｒｋ、ＡＮ）、ユーザプレーンノード（Ｕｓｅｒ ｐｌａｎｅ ｆｕｎｃｔｉｏｎ、ＵＰＦ）、ネットワーク内の認証ユニット（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｕｎｉｔ、略してＣＰ−ＡＵ）、又はセキュリティポリシー決定モジュールによって決定されてよい。

以下は、セキュリティポリシー決定モジュールがセキュリティ保護の終了点を決定する例を単に使用することによって、例示を提供する。

図２から図９に示される手順では、ＵＥ１がアタッチメント要求を送信した後、又は双方向認証が成功した後、又はＵＥ１がセッションをセットアップするプロセスにおいて（ＵＥ１がセッション要求を送信する前、又はＵＥ１がセッション要求を送信した後）、セキュリティポリシー決定モジュールが、以下のステップ、すなわち、セキュリティ保護の終了点を決定することと、セキュリティ保護の終了点がＵＰＦである場合、図２から図９に示される手順において双方向認証後又はＵＥ１がセッション要求を送信した後、ステップを実行すること、又は、セキュリティ保護の終了点がＡＮである場合、図２から図９に示される手順におけるセキュリティ要件３若しくはＵＥ２のセキュリティ要件（セキュリティ要件４のケース）をＡＮのセキュリティ要件と置き換えること、をさらに実行し得る。ＡＮのセキュリティ要件を取得する方式は、以下の通りであってよい。前述の実施形態に基づいて、ＵＥ１の要求メッセージを受信した後、ＡＮが、ＵＥ１の要求メッセージとＡＮのセキュリティ要件の両方をネットワークに送信する。

図１６（ａ）及び図１６（ｂ）は、分岐シナリオである。これらのシナリオでは、セキュリティポリシー決定モジュールは、セキュリティ保護の終了点が分岐点であるかＵＰＦであるかを決定する必要がある。セキュリティ保護の終了点がＵＰＦである場合、図２から図９に示される手順において双方向認証後又はＵＥ１がセッション要求を送信した後のステップが実行される。セキュリティ保護の終了点が分岐点である場合、図２から図９に示される手順におけるセキュリティ要件３又はＵＥ２のセキュリティ要件（セキュリティ要件４のケース）は、分岐点のセキュリティ要件と置き換えられる。

図１７は、セッションリンクがＵＥ−ＡＮ−ＵＰＦ（アップリンクデータ分類器関数、ｕｐｌｉｎｋ ｃｌａｓｓｉｆｉｅｒ ｆｕｎｃｔｉｏｎａｌｉｔｙ、ＵＬＣＬ）−ＵＰＦ（アンカー）であるシナリオを示す。このシナリオでは、セキュリティポリシー決定モジュールは、セキュリティ保護の終了点がＵＰＦ（ＵＬＣＬ）であるかＵＰＦ（アンカー）であるかを決定する必要がある。セキュリティ保護の終了点がＵＰＦ（アンカー）である場合、図２から図９に示される手順において双方向認証後又はＵＥ１がセッション要求を送信した後のステップが実行される。セキュリティ保護の終了点がＵＬＣＬである場合、図２から図９に示される手順におけるセキュリティ要件３又はＵＥ２のセキュリティ要件（セキュリティ要件４のケース）は、ＵＬＣＬのセキュリティ要件と置き換えられる。

図１８に示されるホームにルーティングされるローミングシナリオでは、ユーザプレーンパスはＵＥ−ＡＮ−ＵＰＦ（ＶＰＬＭＮ）−ＵＰＦ（ＨＰＬＭＮ）である。このケースでは、エンドツーエンドセキュリティ保護の終了点は、ＵＰＦ（訪問先公衆陸上モバイル通信ネットワーク、ｖｉｓｉｔｅｄ ｐｕｂｌｉｃ ｌａｎｄ ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ、ＶＰＬＭＮ）であってもよいし、ＵＰＦ（ホーム公衆陸上モバイル通信ネットワーク、ｈｏｍｅ ｐｕｂｌｉｃ ｌａｎｄ ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ、ＨＰＬＭＮ）であってもよい。このシナリオにおいて、セキュリティポリシー決定では、セキュリティ保護の終了点がＵＰＦ（ＶＰＬＭＮ）であるかＵＰＦ（ＨＰＬＭＮ）であるかが決定されることが必要である。セキュリティ保護の終了点がＵＰＦ（ＶＰＬＭＮ）である場合、セキュリティ要件３は、ＶＰＬＭＮ内のゲートウェイのセキュリティ要件である。セキュリティ保護の終了点がＵＰＦ（ＨＰＬＭＮ）である場合、セキュリティ要件３は、ＨＰＬＭＮ内のゲートウェイのセキュリティ要件である。

セキュリティポリシー決定モジュールは、ＨＳＳ、ＡＵＳＦ、ＡＲＰＦ、ＡＭＦ、ＳＥＡＦ、ＳＣＭＦ、ＳＭ、若しくはＡｕＣなどの別の機能ネットワーク要素から受信されたＵＥ１の構成情報若しくはノードポリシーに基づいて、又はローカルストレージから取得されるＵＥ若しくはセッション（又はフロー、ベアラ、又はスライス）の構成情報若しくはノードポリシーに基づいて、及びＵＥ若しくはセッション（又はフロー、ベアラ、又はスライス）の構成情報に基づいて、セキュリティ保護の終了点がＡＮであるか、分岐点であるか、ＵＬＣＬであるか、又はＵＰＦであるかを決定し得る。ノードポリシーは、各ＵＥのノードポリシーであってもよいし、このタイプのサービスのためのノードポリシーであってもよいし、又は、このタイプのスライスのためのノードポリシーであってもよいし、このタイプのデータのためのノードポリシーであってもよい。加えて、代替として、セキュリティポリシー決定モジュールは、サービスセキュリティ要件、サーバ側セキュリティ要件、サービスタイプ、スライスタイプ、又はスライシングポリシーに基づいて、セキュリティ保護の終了点を決定してよい。

前述の例はすべて、セッションごとに実行される、セキュリティポリシー交渉プロセスならびにセッションデータ保護鍵生成及び配信プロセスである。前述の方法は、スライスごとに実行される、セキュリティポリシー交渉ならびにスライスデータ保護鍵生成及び配信にも適用可能であることが留意されるべきである。具体的な実装形態は、セッションごとに実行されるそれに類似している。違いは、以下のとおりである。セッションＩＤはスライスＩＤであり、スライス内のＵＥの保護鍵が決定され、保護ノードは、スライス内の機能ネットワーク要素、例えば、ＵＰＦであってよい。

スライスセキュリティポリシー決定モジュールは、モビリティ管理（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ、ＭＭ）ネットワーク要素、セッション管理（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ、ＳＭ）ネットワーク要素、認証サービスコントローラ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ、ＡＵＳＦ）、セキュリティアンカー機能（Ｓｅｃｕｒｉｔｙ Ａｎｃｈｏｒ Ｆｕｎｃｔｉｏｎ、ＳＥＡＦ）ネットワーク要素、モビリティ管理エンティティ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ）、ホーム加入者サーバ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ、ＨＳＳ）、認証センター（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｅｎｔｅｒ、ＡｕＣ）、認証クレデンシャルリポジトリ及び処理機能（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｒｅｄｅｎｔｉａｌ Ｒｅｐｏｓｉｔｏｒｙ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ Ｆｕｎｃｔｉｏｎ、ＡＲＰＦ）ネットワーク要素、セキュリティコンテキスト管理（Ｓｅｃｕｒｉｔｙ Ｃｏｎｔｅｘｔ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＳＣＭＦ）ネットワーク要素、アクセス及びモビリティ管理機能（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＡＭＦ）ネットワーク要素、ＡＮノード、ＵＰＦノード、ネットワーク内の認証ユニット（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｕｎｉｔ、ＣＰ−ＡＵ）、又はセキュリティポリシー決定モジュール上に配置されてよい。

具体的なセキュリティポリシー決定手順は、以下の３つのケースに分類され得る。

セッションセットアップの前、及び認証が完了した後、スライスセキュリティポリシー決定モジュール（例えば、前述のセキュリティポリシー決定モジュールに等しくてよい）は、前述の実施形態におけるそれと同じ方式で、具体的に言えば、ＵＥ１のセキュリティ能力、サービスセキュリティ要件、スライス内の機能ネットワーク要素のセキュリティ能力、ネットワーク内の予め設定されたＵＥ１のセキュリティ能力、及びアプリケーションサーバ側のセキュリティ要件、のうちの少なくとも１つに基づいて、スライスセキュリティポリシーを決定する。スライス内の機能ネットワーク要素のセキュリティ能力は、ＨＳＳ、ＡＵＳＦ、ＡＲＰＦ、ＡＭＦ、ＳＥＡＦ、ＳＣＭＦ、ＳＭ、ＡｕＣなどから取得され得る。

セッションセットアップ中に、スライスセキュリティポリシーが、上記で使用されたそれに類似した方式で決定される。

セッションセットアップ後、スライスセキュリティポリシーが、セッションセットアップ後に決定される。セキュリティポリシー交渉及び鍵交渉は、セッションセットアッププロセスに含まれない。

スライスセキュリティポリシーを決定した後、セキュリティポリシー決定モジュールが、スライスセキュリティポリシーをＵＥに送信する。鍵配信手順は、セッション手順におけるそれに類似している。最後に、ＵＥ及びスライス内の機能ネットワーク要素が、セキュリティ保護鍵及びセキュリティ保護ポリシーを取得する。

本出願のこの実施形態における鍵構成手順では、セッション保護鍵は、ＵＥ及びゲートウェイ（又はＤＮサーバ又はＵＥ２）のために構成され得る。このようにして、エンドツーエンドセッション保護は、５Ｇモバイル通信アーキテクチャに基づいて実施される。既存のセグメントベースの暗号化方式と比較して、より高いセキュリティが実施される。

加えて、セキュリティポリシーは、ＵＥ、キャリアネットワーク、及びデータネットワークのセキュリティ要件に基づいて決定され得る。従って、セッション保護鍵は、異なるパーティのセキュリティ要件に基づいて決定され得る。これは、すべてのサービスデータが基地局側で同じ保護鍵を使用することによって暗号化される従来技術と比較して、差別化されたセキュリティ保護を実施することができる。

図１９は、本出願の実施形態によるＳＭネットワーク要素を示す。ＳＭネットワーク要素は、通信構成要素と、プロセッサとを含み、メモリをさらに含んでよい。通信構成要素は、エンドツーエンド通信のための要求を受信することを行うように構成される。プロセッサは、セキュリティポリシーを取得することを行うように構成される。通信構成要素は、セキュリティポリシー及び／又は保護鍵をユーザ機器に送信することと、セキュリティポリシー及び／又は保護鍵をエンドツーエンド通信の他方のエンド上のデバイスに送信することとを行うようにさらに構成される。通信構成要素及びプロセッサの機能の具体的な実装形態については、図２から図１５を参照されたい。本明細書では、詳細は再度説明されない。

本出願の実施形態は、ＫＭＳ、ＭＭ、ＨＳＳ、及びポリシー制御ネットワーク要素をさらに開示する。特定の構造に含まれる通信構成要素及びプロセッサの機能の具体的な実装形態については、図２から図１５を参照されたい。本明細書では、詳細は再度説明されない。

図２０は、本出願の実施形態によるユーザ機器である。このユーザ機器は、通信構成要素と、プロセッサとを含む。この通信構成要素とプロセッサは、バスを使用することによって互いと通信し得る。

通信構成要素は、要求を送信することと、応答を受信することとを行うように構成される。要求は、ユーザ機器の識別を含む。応答は、セキュリティポリシーを搬送する。

プロセッサは、保護鍵を取得することを行うように構成され、この保護鍵は、エンドツーエンド通信を保護するために使用され、この保護鍵は、セキュリティポリシーと、ユーザ機器とキャリアネットワークの間の共有鍵とに基づいて決定される。

通信構成要素及びプロセッサの機能の具体的な実装形態については、図２から図１５を参照されたい。本明細書では、詳細は再度説明されない。

前述のデバイスは、セキュリティポリシーを決定し、相互協力を通じてエンドツーエンド保護鍵を生成し得る。このようにして、エンドツーエンドセッション保護は、５Ｇモバイル通信アーキテクチャに基づいて実施される。

本明細書における実施形態はすべて、漸進的な方式で説明されている。各実施形態は、他の実施形態との違いを重視している。実施形態における同じ又は類似の部分については、これらの実施形態を参照されたい。

Claims (10)

1. セキュリティポリシーを決定するための方法であって、
   モビリティ管理ネットワーク要素（ＭＭ）によって、セッション要求をセッション管理ネットワーク要素へ送信するステップと、
   前記セッション管理ネットワーク要素によって、前記セッション要求を受信するステップと、
   前記セッション要求に応答して、前記セッション管理ネットワーク要素によって、認証・認可・アカウンティングサーバ（ＡＡＡ）からセキュリティ要件を取得するステップであって、前記セキュリティ要件は、完全性保護が要求されるかどうかを示すように構成される、ステップと、
   前記セッション管理ネットワーク要素によって、前記セキュリティ要件に基づいてセキュリティポリシーを決定するステップであって、前記セキュリティポリシーは、完全性保護が要求されるかどうかを示すように構成される、ステップと、
   を含む、方法。
2. 前記セキュリティ要件は、暗号化が要求されるかどうかを示すようにさらに構成される
   請求項１に記載の方法。
3. 前記セキュリティポリシーは、暗号化が要求されるかどうかを示すようにさらに構成される
   請求項２に記載の方法。
4. 前記ＡＡＡは、各ユーザ機器（ＵＥ）の認証情報及び加入者情報を記憶する
   請求項１〜３のいずれか１項に記載の方法。
5. 前記セッション管理ネットワーク要素によって、前記セキュリティ要件に基づいてセキュリティポリシーを決定する前記ステップは、
   前記セッション管理ネットワーク要素によって、前記セキュリティ要件の優先順位レベルに基づいて前記セキュリティポリシーを決定することを含む、
   請求項１〜４のいずれか１項に記載の方法。
6. 通信構成要素及びプロセッサを含むセッション管理ネットワーク要素であって、
   前記通信構成要素は、モビリティ管理ネットワーク要素（ＭＭ）によって送信されたセッション要求を受信し、且つ認証・認可・アカウンティングサーバ（ＡＡＡ）からセキュリティ要件を取得するように構成され、前記セキュリティ要件は、完全性保護が要求されるかどうかを示すように構成され、
   前記プロセッサは、前記セキュリティ要件に基づいてセキュリティポリシーを決定するように構成され、前記セキュリティポリシーは、完全性保護が要求されるかどうかを示すように構成される、
   セッション管理ネットワーク要素。
7. 前記セキュリティ要件は、暗号化が要求されるかどうかを示すようにさらに構成される
   請求項６に記載のセッション管理ネットワーク要素。
8. 前記セキュリティポリシーは、暗号化が要求されるかどうかを示すようにさらに構成される
   請求項７に記載のセッション管理ネットワーク要素。
9. 前記ＡＡＡは、各ユーザ機器（ＵＥ）の認証情報及び加入者情報を記憶する、
   請求項６〜８のいずれか１項に記載のセッション管理ネットワーク要素。
10. 前記プロセッサは、前記セキュリティ要件の優先度レベルに基づいてセキュリティポリシーを決定するように構成される
    請求項６〜９のいずれか１項に記載のセッション管理ネットワーク要素。

Images