密钥配置及安全策略确定方法、装置

摘要

本申请提供了一种密钥配置方法，会话管理网元接收端到端的通信的请求并获取安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。会话管理网元获取用于对所述端到端的通信进行保护的保护密钥，所述保护密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定。会话管理网元向端到端的通信的两端的设备发送安全策略和/或保护密钥。可以看出，会话管理网元能够为端到端通信的两端设备配置会话保护密钥，从而提高端到端通信的安全性。

权利要求

1.一种安全策略确定的方法，其特征在于，包括：

会话管理网元接收移动性管理网元发送的会话请求；响应于所述会话请求，所述会话管理网元根据终端设备的安全需求以及运营商网络的安全需求确定目标安全需求；其中，所述终端设备的安全需求来自于归属用户服务器，所述运营商网络的安全需求存储于所述会话管理网元；

其中，所述会话管理网元根据终端设备的安全需求以及运营商网络的安全需求确定目标安全需求，包括：若所述终端设备的安全需求的优先级高于所述运营商网络的安全需求的优先级，则根据所述终端设备的安全需求确定所述目标安全需求；

所述会话管理网元根据所述目标安全需求确定安全策略，所述安全策略用于指示是否需要对会话进行完整性保护以及是否需要对所述会话进行加密保护；以及所述会话管理网元向接入网发送所述安全策略。

2.根据权利要求1所述的方法，其特征在于，所述目标安全需求还包括指示是否需要对所述会话进行加密以及是否需要对所述会话进行完整性保护。

3.根据权利要求1所述的方法，其特征在于，所述目标安全需求还包括密钥的长度，所述安全策略还包括所述密钥的长度。

4.根据权利要求1所述的方法，其特征在于，所述目标安全需求还包括密钥的更新时间，所述安全策略还包括所述密钥的更新时间。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述会话管理网元根据共享密钥和安全策略计算保护密钥；以及

所述会话管理网元向网关发送所述保护密钥。

6.根据权利要求1所述的方法，其特征在于，所述终端设备的安全需求中包含所述终端设备的安全需求的优先级；所述运营商网络的安全需求中包括所述运营商网络的安全需求的优先级。

7.根据权利要求1至6任一所述的方法，其特征在于，所述终端设备的安全需求中包含安全终结点选择功能，所述安全终结点选择功能用于指示用户面保护终结点在接入网节点或在核心网用户面功能节点。

8.根据权利要求1至6任一所述的方法，其特征在于，所述运营商网络的安全需求中包含安全终结点选择功能，所述安全终结点选择功能用于指示用户面保护终结点在接入网节点或在核心网用户面功能节点。

9.一种会话管理网元，其特征在于，包括通信组件和处理器；

所述通信组件，用于接收移动性管理网元发送的会话请求；

所述处理器，用于响应于所述会话请求，根据终端设备的安全需求以及运营商网络的安全需求确定目标安全需求；其中，所述终端设备的安全需求来自于归属用户服务器，所述运营商网络的安全需求存储于所述会话管理网元；

其中，根据终端设备的安全需求以及运营商网络的安全需求确定目标安全需求，包括：若所述终端设备的安全需求的优先级高于所述运营商网络的安全需求的优先级，则根据所述终端设备的安全需求确定所述目标安全需求；

根据所述目标安全需求确定安全策略，所述安全策略用于指示是否需要对会话进行完整性保护以及是否需要对所述会话进行加密保护；以及所述通信组件，还用于向接入网发送所述安全策略。

10.根据权利要求9所述的会话管理网元，其特征在于，所述目标安全需求还包括指示是否需要对所述会话进行加密以及是否需要对所述会话进行完整性保护。

11.根据权利要求9所述的会话管理网元，其特征在于，所述目标安全需求还包括密钥的长度，所述安全策略还包括所述密钥的长度。

12.根据权利要求9所述的会话管理网元，其特征在于，所述目标安全需求还包括密钥的更新时间，所述安全策略还包括所述密钥的更新时间。

13.根据权利要求9所述的会话管理网元，其特征在于，

所述处理器还用于根据共享密钥和安全策略计算保护密钥；以及

所述通信组件还用于向网关发送所述保护密钥。

14.根据权利要求9所述的会话管理网元，其特征在于，所述终端设备的安全需求中包含所述终端设备的安全需求的优先级；所述运营商网络的安全需求中包括所述运营商网络的安全需求的优先级。

15.根据权利要求9至14任一所述的会话管理网元，其特征在于，所述终端设备的安全需求中包含安全终结点选择功能，所述安全终结点选择功能用于指示用户面保护终结点在接入网节点或在核心网用户面功能节点。

16.根据权利要求9至14任一所述的会话管理网元，其特征在于，所述运营商网络的安全需求中包含安全终结点选择功能，所述安全终结点选择功能用于指示用户面保护终结点在接入网节点或在核心网用户面功能节点。

说明书

密钥配置及安全策略确定方法、装置

技术领域

[0001] 本申请涉及通信领域，尤其涉及密钥配置及安全策略确定方法、装置。

背景技术

[0002] 在未来(例如第5代)移动通信架构中，会话管理网元依据用户设备的业务需求，建立用户设备与网关(或者DN服务器，或者另一个用户设备)之间的会话。

[0003] 目前的会话安全算法均不适用于未来的移动通信架构，因此，如何建立基于未来的移动通信架构的安全机制，成为目前亟待解决的问题。

发明内容

[0004] 本申请提供了一种密钥配置及安全策略确定方法、装置，目的在于解决如何建立基于未来的移动通信架构的安全机制的问题。

[0005] 本申请的第一方面提供了一种密钥配置方法，包括以下步骤：会话管理网元接收端到端的通信的请求，所述端到端的通信的请求中包括作为所述端到端的通信的一端的用户设备的标识。会话管理网元获取安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。所述会话管理网元获取保护密钥，所述保护密钥用于对所述端到端的通信进行保护，所述保护密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定。所述会话管理网元向所述用户设备发送所述安全策略和/或所述保护密钥。所述会话管理网元向所述端到端的通信的另一端设备发送所述安全策略和/或所述保护密钥。从上述过程可以看出，会话管理网元能够为端到端通信的两端设备配置会话保护密钥，从而提高端到端通信的安全性。并且，与现有的分段加密的方式相比，具有更高的安全性。

[0006] 本申请的第二方面公开了一种会话管理网元，包括通信组件和处理器。具体地，通信组件用于接收端到端的通信的请求，所述端到端的通信的请求中包括作为所述端到端的通信的一端的用户设备的标识。处理器用于获取安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定，以及，获取保护密钥，所述保护密钥用于对所述端到端的通信进行保护，所述保护密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定。所述通信组件还用于向所述用户设备发送所述安全策略和/或所述保护密钥，以及向所述端到端的通信的另一端设备发送所述安全策略和/或所述保护密钥。

[0007] 在一个实现方式中，所述端到端的通信的请求中还包括：网络标识和业务参数的至少一项。网络标识和业务参数的至少一项可以用于后续密钥的生成。

[0008] 在一个实现方式中，所述获取保护密钥包括：依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥，所述参数包括所述用户设备的标识、所述网络标识和所述业务参数的至少一项。

[0009] 在一个实现方式中，在所述会话管理网元依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥之前，还包括：所述会话管理网元向所述运营商的策略控制网元发送安全策略请求，所述安全策略请求中包括所述用户设备的标识、所述网络标识和业务参数的至少一项，所述用户设备的标识、所述网络标识和业务参数的至少一项用于所述策略控制网元标识所述安全策略。所述会话管理网元接收所述运营商的策略控制网元发送的所述安全策略。

[0010] 在一个实现方式中，所述安全策略请求中还包括：所述会话管理网元预先获取的安全需求集合，所述安全需求集合中包括所述归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、和所述端到端的通信的另一端设备的安全需求的至少一种。

[0011] 在一个实现方式中，在所述会话管理网元依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥之前，还包括：获得所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求、和所述端到端的通信的另一端设备的安全需求的至少一种；依据获取的所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求、和所述端到端的通信的另一端设备的安全需求的至少一种，确定所述安全策略。

[0012] 在一个实现方式中，获取所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求的具体实现方式为：在接收到所述端到端通信的请求后，向所述运营商网络的网元中发送安全需求请求，以获取所述归属用户服务器中预置的所述用户设备的用户安全需求，或者，从所述端到端通信的请求中获取所述归属用户服务器中预置的所述用户设备的用户安全需求。

[0013] 在一个实现方式中，获取所述来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求的具体实现方式为：从所述端到端通信的请求中获取所述来自所述用户设备的业务安全需求和/或所述用户设备支持的安全能力需求。

[0014] 在一个实现方式中，获取所述来自运营商网络的安全能力需求的具体实现方式为：向所述运营商网络的策略控制网元发送安全需求请求，所述安全需求请求中包括所述用户设备的标识和所述网络标识的至少一项。接收所述运营商网络的策略控制网元发送的所述来自运营商网络的安全能力需求，所述用户设备的标识和所述网络标识的至少一项用于所述策略控制网元标识所述来自运营商网络的安全能力需求。

[0015] 在一个实现方式中，获取所述端到端的通信的另一端设备的安全需求的具体实现方式为：向所述运营商网络的策略控制网元发送安全需求请求。接收所述运营商网络的策略控制网元发送的所述端到端的通信的另一端设备的安全需求。或者，向所述端到端的通信的另一端设备发送安全需求请求，并接收所述端到端的通信的另一端设备发送的所述端到端的通信的另一端设备的安全需求。其中，所述安全需求请求中包括所述用户设备的标识和所述业务参数的至少一项，所述用户设备的标识和所述业务参数的至少一项用于所述端到端的通信的另一端设备查找所述端到端的通信的另一端设备的安全需求。

[0016] 在一个实现方式中，依据所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种，确定所述安全策略的具体实现方式为：根据所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求、和所述端到端的通信的另一端设备的安全需求中的一种确定安全策略。或者，根据所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求中的多种，并依据预设的规则确定安全策略。

[0017] 在一个实现方式中，在依据所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种，确定所述安全策略之前，还包括：所述会话管理网元根据所述用户设备的配置信息或节点策略，或者从本地存储中获得所述用户设备的配置信息或节点策略，或者根据业务的安全需求、服务器侧安全需求、业务类型、所述用户设备的安全能力或者切片策略，确定安全保护的终结点在用户面节点UPF；或者，所述会话管理网元从所述运营商的所述策略控制网元接收到节点配置参数，所述节点配置参数指示安全保护的终结点在用户面节点UPF。

[0018] 在一个实现方式中，所述UPF为拜访地公用陆地移动通信网VPLMN的UPF，所述来自运营商网络的安全能力需求为所述VPLMN的网关的安全需求；所述UPF为归属地公用陆地移动通信网HPLMN的UPF，所述来自运营商网络的安全能力需求为所述 HPLMN的网关的安全需求。

[0019] 在一个实现方式中，所述安全需求的内容包括：安全保护的算法，所述安全保护的算法包括加密算法和/或完整性保护算法。

[0020] 在一个实现方式中，所述安全需求的内容还包括：密钥的长度和/或密钥的更新时间。

[0021] 在一个实现方式中，所述安全需求的格式包括：多个8位字节，所述多个8位字节包括以下任意一项：用于表示安全需求的标识的8位字节、用于表示安全需求的内容的长度的8位字节、用于表示安全需求是否要求加密算法的8位字节、用于表示安全需求是否要求完整性保护算法的8位字节、用于表示加密算法的长度的8位字节、用于表示完整性保护算法的长度的8位字节、用于表示密钥是否需要更新的8位字节、用于表示具体的加密算法的8位字节、用于表示具体的完整性保护算法的8位字节。

[0022] 在一个实现方式中，在所述会话管理网元依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥之前，还包括：接收所述运营商网络的密钥管理中心发送的所述共享密钥。或者，从本地获取所述共享密钥。

[0023] 在一个实现方式中，获取所述保护密钥包括：向所述运营商的密钥管理中心发送密钥请求，所述密钥请求中包括所述用户设备的标识、所述网络标识、所述业务参数和安全策略的至少一项，所述用户设备的标识、所述网络标识和所述业务参数的至少一项用于所述密钥管理中心确定所述共享密钥。接收所述密钥管理中心发送的所述保护密钥。

[0024] 在一个实现方式中，所述方法还包括：所述会话管理网元向所述端到端的通信的一端发送所述网络标识；和/或，所述会话管理网元向所述端到端的通信的另一端设备发送所述网络标识。

[0025] 本申请的第三方面提供了一种密钥配置方法，包括以下步骤：密钥管理中心接收密钥请求，并依据所述用户设备的标识，确定所述用户设备与运营商网络之间的共享密钥，以及依据所述安全策略、所述共享密钥和所述参数生成用于对所述端到端的通信进行保护的保护密钥。所述密钥管理中心向所述用户设备发送所述保护密钥，向所述端到端的通信的另一端设备发送所述保护密钥。其中，所述密钥请求中包括安全策略和参数，所述参数至少包括作为端到端的通信的一端的用户设备的标识、网络标识和业务参数的至少一项。所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。

[0026] 本申请的第四方面提供了一种密钥管理中心，包括通信组件和处理器。其中，通信组件用于接收密钥请求，处理器，用于依据所述用户设备的标识，确定所述用户设备与运营商网络之间的共享密钥，以及，依据所述安全策略、所述共享密钥和所述参数生成保护密钥。通信组件还用于向所述用户设备发送所述保护密钥，以及向所述端到端的通信的另一端设备发送所述保护密钥。其中，所述参数至少包括作为端到端的通信的一端的用户设备的标识、网络标识和业务参数的至少一项；所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。

[0027] 在一种实现方式中，在所述密钥管理中心依据所述安全策略、所述共享密钥和所述参数生成保护密钥之后，还包括：所述密钥管理中心向所述运营商的会话管理网元发送所述保护密钥。

[0028] 在一种实现方式中，所述共享密钥为所述用户设备与所述运营商网络双向认证后，获得的所述用户设备与所述运营商网络之间的共享密钥。

[0029] 本申请的第五方面提供了一种密钥配置方法，包括：用户设备发送请求，所述请求中包括所述用户设备的标识。所述用户设备接收响应，所述响应中携带安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。所述用户设备获取保护密钥，所述保护密钥用于对所述端到端的通信进行保护，所述保护密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定。

[0030] 本申请的第六方面提供了一种用户设备，包括通信组件和处理器。其中，通信组件用于发送请求，所述请求中包括所述用户设备的标识。以及接收响应，所述响应中携带安全策略。所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。处理器用于获取保护密钥，所述保护密钥用于对所述端到端的通信进行保护，所述保护密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定。

[0031] 在一个实现方式中，所述用户设备发送请求的具体实现方式为：所述用户设备发送业务参数和安全需求集合，所述安全需求集合中包括所述用户设备的业务安全需求和/或所述用户设备支持的安全能力需求。

[0032] 在一个实现方式中，所述请求中还包括：

[0033] 所述用户设备生成的会话ID，承载ID，流flowID或者切片ID。

[0034] 在一个实现方式中，所述获取保护密钥包括：依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥，所述参数包括所述用户设备的标识、所述网络标识和所述业务参数的至少一项。

[0035] 在一个实现方式中，在所述依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥之前，还包括接收所述运营商的密钥管理中心发送的所述共享密钥。或者，从本地获取所述共享密钥。或者，在所述用户设备与所述运营商网络双向认证后，获得所述用户设备与所述运营商网络之间的共享密钥。

[0036] 在一个实现方式中，在所述依据所述安全策略、所述共享密钥以及参数推演得到所述保护密钥之前，还包括：接收所述运营商网络的会话管理网元发送的所述网络标识。

[0037] 在一个实现方式中，所述获取保护密钥包括：所述用户设备接收所述运营商网络的密钥管理中心或者会话管理中心发送的所述保护密钥。

[0038] 本申请的第七方面提供了一种安全策略确定方法，包括：运营商的策略控制网元接收安全策略请求，所述安全策略请求中包括归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一项以及参数，所述参数包括作为所述端到端的通信的一端的用户设备的标识、网络标识和业务参数的至少一项。所述策略控制网元依据安全需求集合生成并发送安全策略，所述安全需求集合中至少包括所述归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一种。

[0039] 本申请的第八方面提供了一种策略控制网元，包括：通信组件和处理器。通信组件用于接收安全策略请求，所述安全策略请求中包括归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一项以及参数，所述参数包括作为所述端到端的通信的一端的用户设备的标识、网络标识和业务参数的至少一项。处理器用于依据安全需求集合生成安全策略，所述安全需求集合中至少包括所述归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一种。所述通信组件还用于发送所述安全策略。

[0040] 在一个实现方式中，所述安全需求集合中还包括：来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种。

[0041] 在一个实现方式中，获取所述运营商网络的安全需求包括：在接收到所述安全策略请求后，从本地获取预先存储的所述运营商网络的安全需求。

[0042] 在一个实现方式中，获取所述端到端的通信的另一端设备的安全需求包括：接收所述会话管理网元发送的所述端到端的通信的另一端设备的安全需求。或者，向所述端到端的通信的另一端设备发送安全需求请求，并接收所述端到端的通信的另一端设备发送的安全需求。其中，所述安全需求请求中包括所述用户设备的标识、网络标识和业务参数的至少一项，所述用户设备的标识、网络标识和业务参数的至少一项用于所述端到端的通信的另一端设备标记所述端到端的通信的另一端设备的安全需求。

[0043] 在一个实现方式中，所述依据安全需求集合生成安全策略包括：根据所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求、和所述端到端的通信的另一端设备的安全需求中的一种确定安全策略。或者，根据所述归属用户服务器中预置的作为所述端到端通信的一端用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求中的多种，并依据预设的规则确定安全策略。

[0044] 在一个实现方式中，在所述依据安全需求集合生成安全策略之前，还包括：所述运营商的策略控制网元根据所述用户设备的配置信息或节点策略，或者从本地存储中获得所述用户设备的配置信息或节点策略，或者根据业务的安全需求、服务器侧安全需求、业务类型、所述用户设备的安全能力或者切片策略，确定安全保护的终结点在用户面节点UPF。

[0045] 在一个实现方式中，所述UPF为拜访地公用陆地移动通信网VPLMN的UPF，所述来自运营商网络的安全能力需求为所述VPLMN的网关的安全需求；所述UPF为归属地公用陆地移动通信网HPLMN的UPF，所述来自运营商网络的安全能力需求为所述 HPLMN的网关的安全需求。

[0046] 在一个实现方式中，在所述依据安全需求集合生成安全策略之前，还包括：所述运营商的策略控制网元确定安全保护的终结点在branchingpoint或者上行数据分类器功能 ULCL；所述安全需求集合中还包括：所述branching point或者所述ULCL的安全需求。

[0047] 在一个实现方式中，所述安全需求的内容包括：安全保护的算法，所述安全保护的算法包括加密算法和/或完整性保护算法。

[0048] 在一个实现方式中，所述安全需求的内容还包括：密钥的长度和/或密钥的更新时间。

[0049] 本申请的第九方面提供了一种安全策略确定方法，包括：移动性管理网元接收用户设备的请求，所述用户设备的请求中包括作为所述端到端的通信的一端的所述用户设备的标识。所述移动性管理网元发送端到端的通信的请求，所述端到端的通信的请求中包括所述用户设备的标识，所述端到端的通信的请求用于触发安全会话的建立，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求和来自运营商网络的安全能力需求的至少一种确定。

[0050] 本申请的第十方面提供了一种移动性管理网元，包括通信组件和处理器。其中，通信组件，用于接收用户设备的请求，所述用户设备的请求中包括作为所述端到端的通信的一端的所述用户设备的标识。以及，发送端到端的通信的请求，所述端到端的通信的请求中包括所述用户设备的标识，所述端到端的通信的请求用于触发安全会话的建立，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求和来自运营商网络的安全能力需求的至少一种确定。

[0051] 在一个实现方式中，在所述移动性管理网元发送端到端的通信的请求之前，还包括：所述移动性管理网元生成网络标识。所述端到端的通信的请求中还包括所述网络标识。

[0052] 在一个实现方式中，还包括：所述移动性管理网元从归属用户服务器获得用户标识和归属用户服务器中预置的所述用户设备的用户安全需求。依据所述端到端的通信的请求中所述用户设备的标识，获取所述归属用户服务器中预置的所述用户设备的用户安全需求。

[0053] 在一个实现方式中，所述端到端的通信的请求中还包括：所述归属用户服务器中预置的所述用户设备的用户安全需求。

[0054] 在一个实现方式中，所述用户设备的请求中还包括：业务参数、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一项。

[0055] 在一个实现方式中，所述端到端的通信的请求中还包括：业务参数、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一项。

[0056] 本申请的第十一方面提供了一种安全策略确定方法，包括：归属用户服务器接收安全需求请求，所述安全需求请求中包括用户标识，所述归属用户服务器保存有所述归属用户服务器中预置的所述用户设备的用户安全需求。所述归属用户服务器根据所述用户标识，确定所述归属用户服务器中预置的所述用户设备的用户安全需求。所述归属用户服务器发送所述归属用户服务器中预置的所述用户设备的用户安全需求，所述归属用户服务器中预置的所述用户设备的用户安全需求用于生成安全策略。

[0057] 本申请的第十二方面提供了一种归属用户服务器，包括：用于存储所述归属用户服务器中预置的所述用户设备的用户安全需求的存储器、用于接收包括用户标识的安全需求请求的通信组件以及用于根据所述用户标识，确定所述归属用户服务器中预置的所述用户设备的用户安全需求的处理器。所述通信组件还用于，发送所述归属用户服务器中预置的所述用户设备的用户安全需求，所述归属用户服务器中预置的所述用户设备的用户安全需求用于生成安全策略。

[0058] 本申请的第十三方面提供了一种密钥配置方法，包括：会话管理网元接收端到端的通信的请求，所述端到端的通信的请求中包括作为所述端到端的通信的一端的用户设备的标识；所述会话管理网元获取安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定；所述会话管理网元获取第一密钥，所述第一密钥用于对所述端到端的通信进行保护，所述第一密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定；所述会话管理网元依据所述安全策略以及所述第一密钥生成加密保护密钥和 /或完整性保护密钥，所述加密保护密钥用于对所述端到端的通信进行机密性保护，所述完整性保护密钥用于对所述端到端的通信进行完整性；所述会话管理网元向所述用户设备发送所述安全策略；所述会话管理网元向所述端到端的通信的另一端设备发送所述加密保护密钥和所示完整性保护密钥的至少一项以及所述安全策略。

[0059] 本申请的第十四方面提供了一种移动性管理网元，包括：

[0060] 通信组件，用于接收端到端的通信的请求，所述端到端的通信的请求中包括作为所述端到端的通信的一端的用户设备的标识。处理器，用于获取安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定；以及，获取第一密钥，所述第一密钥用于对所述端到端的通信进行保护，所述第一密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定；以及，依据所述安全策略以及所述第一密钥生成加密保护密钥和/或完整性保护密钥，所述加密保护密钥用于对所述端到端的通信进行机密性保护，所述完整性保护密钥用于对所述端到端的通信进行完整性。所述通信组件还用于：向所述用户设备发送所述安全策略，以及，向所述端到端的通信的另一端设备发送所述加密保护密钥和所示完整性保护密钥的至少一项以及所述安全策略。

[0061] 在一个实现方式中，所述会话管理网元向所述用户设备发送所述第一密钥，以使所述用户设备根据所述安全策略和所述第一密钥，生成所述加密保护密钥和/或所述完整性保护密钥。

[0062] 在一个实现方式中，还包括：所述会话管理网元向所述用户设备发送所述加密保护密钥和/或所述完整性保护密钥。

[0063] 本申请的第十五方面提供了密钥配置方法，包括：用户设备发送请求，所述请求中包括所述用户设备的标识；所述用户设备接收响应，所述响应中携带安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定；所述用户设备获取加密保护密钥和 /或完整性保护密钥，所述加密保护密钥用于对所述端到端的通信进行机密性保护，所述完整性保护密钥用于对所述端到端的通信进行完整性。

[0064] 本申请的第十六方面提供了用户设备，包括：

[0065] 通信组件，用于发送请求，所述请求中包括所述用户设备的标识；以及，接收响应，所述响应中携带安全策略，所述安全策略依据归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求、所述用户设备支持的安全能力需求、来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种确定。以及，处理器，用于获取加密保护密钥和/或完整性保护密钥。

[0066] 在一个实现方式中，所述用户设备获取加密保护密钥和/或完整性保护密钥包括：所述用户设备获取第一密钥，所述第一密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定，依据所述安全策略以及所述第一密钥生成加密保护密钥和/ 或完整性保护密钥。

[0067] 在一个实现方式中，所述用户设备获取加密保护密钥和/或完整性保护密钥包括：所述用户设备接收加密保护密钥和/或完整性保护密钥。

[0068] 本申请的第十七方面提供了一种安全策略确定方法，包括：运营商的策略控制网元或者移动性管理网元确定安全保护的终结点；在所述安全保护的终结点为用户面节点UPF 的情况下，所述策略控制网元或者移动性管理网元依据所述归属用户服务器中预置的用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一种、以及来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种生成安全策略；在所述安全保护的终结点为其它设备的情况下，所述策略控制网元或者移动性管理网元依据所述归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一种、以及所述其它设备的安全需求生成安全策略，所述其它设备包括branching point 或者ULCL。

[0069] 本申请的第十八方面提供了一种策略控制网元或者移动性管理网元，包括：处理器，用于确定安全保护的终结点，在所述安全保护的终结点为用户面节点UPF的情况下，依据所述归属用户服务器中预置的用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一种、以及来自运营商网络的安全能力需求和所述端到端的通信的另一端设备的安全需求的至少一种生成安全策略；在所述安全保护的终结点为其它设备的情况下，依据所述归属用户服务器中预置的所述用户设备的用户安全需求、来自所述用户设备的业务安全需求和所述用户设备支持的安全能力需求的至少一种、以及所述其它设备的安全需求生成安全策略，所述其它设备包括branching point或者ULCL。

[0070] 在一个实现方式中，所述确定安全保护的终结点包括：根据从所述运营商的网络的其它功能网元接收到的所述用户设备的配置信息或节点策略，或者从本地存储获得所述用户设备的配置信息或节点策略，或者根据接收到的业务的安全需求，或者服务器侧的安全需求、业务类型或者切片策略，确定安全保护的终结点。

[0071] 在一个实现方式中，所述UPF为拜访地公用陆地移动通信网VPLMN的UPF，所述来自运营商网络的安全能力需求为所述VPLMN的网关的安全需求；所述UPF为归属地公用陆地移动通信网HPLMN的UPF，所述来自运营商网络的安全能力需求为所述 HPLMN的网关的安全需求。

附图说明

[0072] 为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

[0073] 图1为未来的移动通信的网络架构的示意图；

[0074] 图2为本申请实施例公开的安全策略确定方法的流程图；

[0075] 图3为本申请实施例公开的又一种安全策略确定方法的流程图；

[0076] 图4为本申请实施例公开的又一种安全策略确定方法的流程图；

[0077] 图5为本申请实施例公开的又一种安全策略确定方法的流程图；

[0078] 图6为本申请实施例公开的又一种安全策略确定方法的流程图；

[0079] 图7为本申请实施例公开的又一种安全策略确定方法的流程图；

[0080] 图8为本申请实施例公开的一种密钥配置方法的流程图；

[0081] 图9为本申请实施例公开的又一种密钥配置方法的流程图；

[0082] 图10为本申请实施例公开的又一种密钥配置方法的流程图；

[0083] 图11为本申请实施例公开的又一种密钥配置方法的流程图；

[0084] 图12为本申请实施例公开的又一种密钥配置方法的流程图；

[0085] 图13为本申请实施例公开的又一种密钥配置方法的流程图；

[0086] 图14为本申请实施例公开的又一种密钥配置方法的流程图；

[0087] 图15为本申请实施例公开的又一种密钥配置方法的流程图；

[0088] 图16(a)和图16(b)为branching的场景的示意图；

[0089] 图17为会话链路为UE-AN-UPF(ULCL)-UPF(anchor)的场景的示意图；

[0090] 图18为Home-routed漫游场景的示意图；

[0091] 图19为本申请实施例公开的会话管理网元的结构示意图；

[0092] 图20为本申请实施例公开的用户设备的结构示意图。

具体实施方式

[0093] 下面将结合附图，对本申请中的技术方案进行描述。

[0094] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案描述。

[0095] 图1为未来的移动通信的网络架构。其中：

[0096] 用户设备(英文：User Equipment，UE)为逻辑实体，具体可以包括：

[0097] 智能设备，如手机，智能终端等终端设备，或者服务器，网关，基站，控制器等通信设备，或者物联网(英文：Internet of thing，IoT)设备，如传感器，电表，水表等。

[0098] UE通过接入网(英文：Access Network，AN)接入运营商网络。

[0099] 运营商网络中包括：

[0100] 移动性管理(英文：Mobility Management，MM)网元。

[0101] 会话管理网元(英文：Session Management，SM)，用于执行会话、切片、流flow 或者承载bearer的建立和管理。

[0102] 认证单元(英文：Authentication Unit，或Authentication Function，AU或AF)，用于与UE之间执行双向认证。AU可以作为一个独立的逻辑功能实体单独部署，也可以部署在MM或者SM的内部，即MM或者SM扮演AU的角色。

[0103] 运营商的服务器节点，或者归属用户服务器，包括运营商的AAA服务器(英文： Authentication、Authorization、Accounting server，验证、授权和记账服务器)，或者归属用户服务器(Home Subscriber Server，HSS)、或者认证中心(英文：Authentication Centre， AuC)服务器、或者用户注册信息中心(英文：subscriber repository)。为了便于说明，以下统一采用AAA进行表示。AAA中保存有每个UE的认证信息和用户信息，如认证根密钥，安全算法，用户的注册信息等等。

[0104] 策略控制(Policy control)网元，用于策略的协商。

[0105] 密钥管理中心(英文：Key Management System，KMS)，负责密钥的生成、管理和协商，支持合法监听。KMS可以作为一个独立的逻辑功能实体单独部署，也可以部署在 AU、MM或者SM的内部，即AU、MM或者SM扮演KMS的角色。

[0106] 网关，又称为用户面网关(英文：User Plane-Gateway，UP-GW)，用于连接运营商网络和数据网络(英文：Data Network，DN)。AN也可通过GW与DN相连。

[0107] DN服务器，包括应用服务器或者业务服务器等。可部署在运营商网络内部，也可部署在运营商网络外部。

[0108] 需要说明的是，图1中体现的是各个网元之间的逻辑关系，在实际中，MM、 AU以及SM可以单独部署，也可以至少两两集成部署在一个实体中。例如，SM和MM部署在一个实体中， AU单独部署；或者SM与AU部署在一个实体中，MM单独部署。

[0109] 基于图1的架构，为了实现对于端(UE1)到端(网关、DN服务器，或者UE2)的通信的保护，本申请中，在图1所示的架构中加入密钥配置装置，目的在于为端到端的通信的UE1和网关(或者DN服务器，或者UE2)双方配置保护密钥，以使得双方可以使用保护密钥，对通信进行加密。

[0110] 密钥配置装置包括：安全策略确定模块和密钥配置模块。其中，安全策略确定模块用于依据端到端的通信的一端(即UE1)的安全需求、端到端的通信的另一端(即DN服务器或者UE2)的安全需求、运营商网络(即网关)的安全需求的至少一种，确定安全策略。密钥配置模块用于依据端到端的通信的一端(即UE1)与运营商网络的网元(例如AU、KMS、 SM或MM)之间的共享密钥以及安全策略，配置用于保护端(即UE1)到端(即DN服务器或者UE2)的通信的保护密钥。

[0111] 所述共享密钥可以为：UE与运营商的网元(例如AU、KMS、SM或MM)之间预置的共享密钥；也可能为UE与运营商网络的网元(例如AU、KMS、SM或MM)之间双向认证后，获得共享密钥，再将共享密钥发送至其他网元。例如，UE与AU之间双向认证中，获得共享密钥；AU再将共享密钥发送至KMS，SM或者MM；也可能UE与KMS(SM或者MM)做认证后，将共享密钥发送至其他网元。

[0112] 以LTE为例，认证后获得的共享密钥包括但不限于CK，IK，Kasme的至少一个。共享密钥包括但不限于LTE中认证后的密钥形式，也包括其他的认证方式，如基于证书，基于身份，基于用户面口令等等；基于这些认证后获得共享密钥。

[0113] 具体地，端到端的通信的一端UE1的安全需求包括HSS中预置的UE1的用户安全需求 (为了便于后续说明，本申请的实施例中，简称为安全需求1)、来自UE1的业务安全需求(简称为安全需求2)以及UE支持的安全能力需求(简称为安全需求5)，如UE仅支持ZUC算法。其中，安全需求1为HSS内预置的用户安全需求，存在于用户的签约数据中，可单独为一个参数存储，也可能为HSS内用户QoS(服务质量，英文：Quality of Service) 的一部分。安全需求2在UE1发起通信请求时，由UE发送至运营商网络。

[0114] 运营商网络即网关的安全需求包括来自运营商网络(网关侧)的安全能力需求(简称为安全需求3)，其存储在Policy control网元中，可以单独为一个参数存储，也可能为Policy control内QoS的一部分，也可能存储在SM网元中。

[0115] 端到端的通信的另一端即DN服务器(或者UE2)的安全需求(简称为安全需求4)为： UE1在建立通信或者DN服务器(或者UE2)触发通信建立时，部分场景需要DN服务器或者UE2的参与，DN服务器或者UE2会提出安全保护需求，如要求使用ZUC安全算法。

[0116] 另外，也可能包括应用功能网元(Application function，AF)的需求，AF与PCF 有接口，或通过其他网络开放网络功能实体，与移动通信网络的所有网络功能实体(例如 SMF(会话管理实体，英文：Session Management Function),或者AMF(接入和移动管理网元,英文：Access and Mobility Management Function),或者PCF(策略控制网元，应为Policy Control Function))建立通信。

[0117] 具体地，无论是哪种安全需求，安全需求的内容包括：安全保护的算法，可选地，还可以包括密钥长度和密钥更新时间(例如6小时、12小时、1天、2天、1月、1年等)。

[0118] 具体地，安全保护的算法包括加密算法和/或完整性保护算法。举例说明，加密算法用于规定采用包括但不限于null(空算法，表示不进行加密)、AES、Snow 3G或ZUC中的哪种加密算法进行加密保护。完整性保护算法用于规定采用包括但不限于null(空算法，指不进行完整性保护)、AES、Snow 3G、ZUC、HMAC、CMAC中的哪种完整性保护算法进行完整性保护。可能一个安全需求中安全保护的算法包括多个加密算法和/或多个完整性保护算法；在此情况下，安全需求中，还包含算法的优先级排序，即指明优先使用哪一个算法。

[0119] 举例说明，保护密钥的长度包括64、128、256，或者512比特等。第一个可能性为：安全需求中仅包含一个保护密钥长度，则之后的加密和完整性保护的保护密钥长度相同，都为安全需求中定义的保护密钥长度。第二个可能性为：安全需求中包括两个保护密钥长度，一个用于规定加密密钥的长度，一个用于规定完整性保护密钥的长度。

[0120] 上述任意一种安全需求具体包括以下信息：是否需要加密算法、加密密钥的长度、是否需要完整性保护算法、完整性保护密钥的长度、是否需要更新密钥以及更新的周期的至少一项。

[0121] 安全需求或者安全策略的另一种可能性为包括是否加密，是否完整性保护；还可能包括密钥长度，或者密钥的更新时间。类似地，最终确定的安全策略也包括是否加密，是否完整性保护；还可能包括密钥长度，或者密钥的更新时间。

[0122] 安全需求或者安全策略的另一种可能性为包括是否完整性保护；还可能包括是否加密，密钥长度，或者密钥的更新时间。类似地，最终确定的安全策略也包括是否完整性保护；还可能包括是否加密，密钥长度，或者密钥的更新时间。

[0123] 安全需求或者安全策略的另一种可能性为包括是否加密；还可能包括是否完整性保护，密钥长度，或者密钥的更新时间。类似地，最终确定的安全策略也包括是否加密；还可能包括是否完整性保护，密钥长度，或者密钥的更新时间。

[0124] 安全需求的格式有多种可能性。下面给出一些具体格式的可能性，如表1-表5所示：

[0125] 表1

[0126]

[0127] 表1中，EA表示加密算法encryptionalgorithm。IA表示完整性保护算法integrity algorithm。security requirement IEI表示安全需求的标识。Length of security requirement contents表示安全需求内容的长度。

[0128] 从表1可以看出，安全需求由5个8位字节组成，8位字节1用于指示安全需求的标识，8位字节2用于指示该安全需求的内容的长度。

[0129] 8位字节3用于表示是否需要加密算法以及加密密钥的长度，其中，8位字节3的最高位的值用于指示是否需要加密算法，0表示不需要加密算法，1表示需要加密算法。剩下的7位可以分别表示加密密钥的长度，例如表1中，次高位表示加密密钥的长度为128，后面的比特位可以分别表示加密密钥的长度为256等(表1中仅给出128和256两个例子，其它长度可以依据实际需求设定)。表示加密密钥的长度的比特位的值为0表示不采用此比特位表示的长度，为1表示采用此比特位表示的长度。如果有多个表示加密密钥的长度的比特位的值均为1，则说明该安全需求支持多种长度的加密密钥。

[0130] 8位字节4用于表示是否需要完整性保护算法以及完整性保护密钥的长度，其中，8 位字节的最高位的值用于指示是否需要完整性保护算法，0表示不需要完整性保护算法，1表示需要完整性保护算法。剩下的7位可以分别表示完整性保护密钥的长度，例如表1 中，次高位表示完整性保护密钥的长度为128，后面的比特位可以分别表示完整性保护密钥的长度为256等(表1中仅给出128和256两个例子，其它长度可以依据实际需求设定)。表示完整性保护密钥的长度的比特位的值为0表示不采用此比特位表示的长度，为1表示采用此比特位表示的长度。如果有多个表示完整性保护密钥的长度的比特位的值均为1，则说明该安全需求支持多种长度的完整性保护密钥。

[0131] 8位字节5为可选，用于表示是否需要更新密钥以及更新的周期。其中，8位字节5 的最高位的值用于指示是否需要更新，0表示不需要更新，1表示需要更新。剩下的7位可以分别表示更新的周期，例如表1中，次高位表示更新的周期为24小时，后面的比特位可以分别表示更新的周期为48小时等(表1中仅给出24小时和48小时两个例子，其它周期可以依据实际需求设定)。表示更新的周期的比特位的值为0表示不采用此周期，为1表示采用此周期。如果有多个表示更新的周期的比特位的值均为1，则说明该安全需求支持多种更新周期。

[0132] 需要说明的是，对于表1以及以下各个表，表中给出的哪个8位字节的哪一位表示什么含义，均为举例，本实施例中，不以各表中的举例作为限定。例如，表1中的第3个8 位字节的第6位和第7为表示加密密钥的长度，除此之外，加密密钥的长度也可以使用第 3个8位字节中的其它比特位表示，而不仅仅限于第3个8位字节中的第7和第6位。又例如，表1中的第4个8位字节中除第7和第6位之外的其它字节，也可以用于表示完整性保护密钥的长度。

[0133] 表2

[0134]

[0135] 表2与表1的区别在于，8位字节3至8位字节5的最高位均使用空表示，如值为1，表示空算法，即不需要。例如，8位字节3的最高位的值为1表示不需要加密计算，为0 表示需要加密计算(或者数值的含义相反)。也可能8位字节3和8位字节4的最高位代表长度为0的密钥长度，若值为1，则代表不需要加密。

[0136] 表3

[0137]

[0138]

[0139] 表3中，EEA0表示演进的分组系统(Evolved Packet System，EPS)加密算法0，其中EEA代表EPS加密算法，即EPS encryptionalgorithm，EIA0表示EPS完整性保护算法0，其中EIA代表EPS完整性算法，即EPS integrity algorithm。

[0140] UEA0表示通用移动通信系统(UniversalMobile Telecommunication System，UMTS) 加密算法0，其中UEA代表UMTS加密算法，即UMTS encryption algorithm。UIA0表示 UMTS完整性算法0，其中UIA代表UMTS完整性算法，即UMTS integrity algorithm。

[0141] spare表示空闲位，被置位为0。

[0142] GEA表示通信分组无线服务(General Packet Radio Service，GPRS)加密算法，即 GPRS encryption algor ithm。

[0143] 其中字节5-6为可选。例如需要支持UMTS接入技术时，需包括8位字节5和8位6。需要支持GPRS接入技术时，需包括8位字节7。

[0144] 表3与表1和表2的区别在于，表1和表2展示出了是否加密、密钥长度和时间长度的至少一项。表3中给出了具体支持的安全算法。

[0145] 表4

[0146]

[0147]

[0148] 表4与表3的区别在于，在表3的基础上新增8位字节8-10。8位字节8-10的定义可以参考表1。8位字节3-7的定义可以参考表4。

[0149] 另外8位字节8-10可以替换为表2中8位字节3-5的功能，此时8位字节3-5的功能描述见表2。

[0150] 表5

[0151]

[0152] 表5与表3的不同点在于，表5中新增下一代通信的加密算法和完整性保护算法。

[0153] NEA0表示下一代通信加密算法0，其中NEA代表Next generat ion加密算法，即Next generation encryption algorithm，NIA0表示下一代完整性保护算法0，其中NIA代表 Next generation完整性算法，即Next generation integrity algorithm。

[0154] 另外，其他可能性包括类似于表4的处理机制，将表5与表1结合在一起，体现增强的安全需求；或者表5与表2结合在一起，体现增强的安全需求。

[0155] 上述表1-3和表4中，还包括以下可能性，即仅包含一个密钥长度，此时加密密钥长度与完整性保护密钥长度相同。

[0156] 需要说明的是，表1至表5仅为安全需求格式的举例，除此以外，安全需求中还可以包括该安全需求的优先级(具体格式中以比特位的值表示)等内容，或者，安全需求中包括以上内容的至少一项。

[0157] 另外，安全需求中还可能包括安全终结点选择功能。即新增一个字节，其中一个比特代表用户面保护终结点在接入网节点，还是核心网用户面功能节点。

[0158] 另外，针对上述业务安全需求和/或服务器侧的安全需求的两个需求也可以体现业务上层是否加密的特性。例如，可以通过新增一个字节采用上述的表示形式，完成是否加密的特征。

[0159] 下面将结合图1中的各个网元，对于密钥配置装置中的安全策略确定模块和密钥生成模块的功能的具体实现，分别进行详细说明。

[0160] 需要说明的是，本申请中所述端到端的通信的保护包括会话的端到端的保护，也包括基于切片、流flow或者承载bearer的端到端的保护。下文中，将以端到端会话的保护为例进行描述。因为以下图例中均没有包括UE2，所以以下所述UE均为UE1。

[0161] 安全策略确定模块可以设置在图1所示的UE1、运营商网络的网元(例如AN、MM、AU、 KMS、AAA、SM、Policy control网元)、网关、DN的网元(例如DN服务器)、或者UE2 中。安全策略的确定可以在UE附着网络过程中执行，也可以在UE附着到网络之后进行。下面以安全策略确定模块设置在Policy contro l网元以及安全策略确定模块设置在SM分别进行举例说明。

[0162] 图2为Policy control网元确定安全策略(即安全策略确定模块设置在Policy control网元)的流程，包括以下步骤：

[0163] 1、在附着网络的过程中，UE1接入网络，执行双向认证后，AU 从AAA获取安全需求1。

[0164] 需要说明的是，归属用户服务器接收AU的安全需求请求，其中包括用户标识，根据所述用户标识，确定安全需求1，再将安全需求1发给AU。

[0165] 2、AU将安全需求1发给MM。

[0166] 3、MM生成网络标识(Identity，ID)，例如会话ID，并向SM发起会话请求，会话请求中包括：

[0167] a)UEID：用于网络识别用户，包括但不限于IMEI、国际移动用户识别码(International Mobile Subscriber Identity,IMSI)、IP多媒体私有标识(IPMultimedia Private Identity、IMPI)、TMSI、 IP多媒体公共标识(IP Multimedia Public Identity，IMPU)、用户的App ID、MAC地址、IP地址、手机号码和GUTI的至少一项。为了便于说明，后续实施例中统一用UEID来表示。

[0168] b)网络ID(可选)：用于网络识别用户所在的流程(例如切片，承载，会话或流flow)，包括但不限于会话ID，承载ID，流flow ID，切片ID，PLMN ID的至少一个。

[0169] c)安全需求1。

[0170] d)业务参数(可选)：用于网络识别用户的业务或应用，及相关业务特征，包括：业务ID、APP ID、服务器server  ID、业务中的序列号SN、时间戳和新鲜参数(Fresh parameter1)的至少一个。

[0171] 需要说明的是，上述UE ID和/或业务参数可以为MM从UE发送到MM的接入消息中获得；或者直接从AU或AAA处获得，此时AU或AAA是从UE接入到网络中的消息中获得。

[0172] 另外，MM也可能从AAA处直接获得安全需求1。

[0173] 另外，UE接入网络中，也可能将安全需求2和/或安全需求5发送至网络；此时MM发送的会话请求中，也包含安全需求2和/或安全需求5。

[0174] 4、SM接收到会话请求后，将安全需求1，可能还包括UE ID和网络ID (例如会话ID)发给Policy control网元。

[0175] 可选地，SM可以将安全需求1携带在策略请求消息中发给Policy control网元。可选地，请求消息中可能还包含UEID和网络ID的至少一项。

[0176] 可选地，若SM从MM接受到安全需求2和/或安全需求5，将安全需求2和/或安全需求5发送至policy control。

[0177] 5、Policy control网元获取本地预先存储的安全需求3，或者安全需求1，安全需求 2，安全需求3和安全需求5的至少一项，并依据安全需求1和安全需求3，确定安全策略。

[0178] 具体地，依据以下预设规则确定安全策略：依据一个或多个安全需求的内容确定安全策略。如果仅根据一个安全需求的内容确定安全策略，则安全策略的内容与这一个安全需求的内容相同。如果依据多个安全需求的内容确定安全策略，则可以遵循以下原则：

[0179] 第一、遵循安全性更高的原则，确定安全策略，即：将多个安全需求的内容中安全性更高的内容，作为安全策略的内容。

[0180] 例如，安全需求1的内容中，保护密钥长度为64，而安全需求2的内容中的保护密钥长度为128，则安全策略的保护密钥长度采用128。

[0181] 第二、遵循更节省资源的原则，确定安全策略，即：将多个安全需求的内容中更节省资源的内容，作为安全策略的内容。

[0182] 例如，每一个安全需求的内容都包括加密算法，而部分安全需求的内容的完整性保护算法为null,则安全策略的内容包括加密算法，而不包括完整性保护算法。

[0183] 第三、遵循安全需求的优先级，确定安全策略。即：如果某个安全需求中规定了算法优先级，则以此算法优先级做安全算法协商的基础；选择的最终算法为所有安全需求都支持的算法，并且此算法优先级最高，以此作为安全策略的内容。

[0184] 或者，依据某个安全需求优先级为主，进行安全策略的协商，例如，根据安全需求2 中规定了几种加密算法的优先级，则按照此优先级规定，确定安全策略中采用哪种加密算法。

[0185] 或者，多个安全需求都规定了算法的优先级，此时可以某个安全需求的算法优先级为主，例如，根据安全需求2的优先级为主优先级。

[0186] 或者，针对仅包含是否完整性保护，或者是否加密，或者是否完整性保护和加密的安全需求，上面确定安全策略的方式也是适用的。

[0187] 6、Policy control网元向SM反馈安全策略，

[0188] 可选地，Policy control网元将安全策略携带在响应消息中反馈。

[0189] 需要说明的是，图2中，1～3仅为一种实现方式，可选地，也可以

[0190] 由SM而非MM生成网络ID，例如会话ID，即SM接收到MM发送的会话请求后，生成网络ID，例如会话ID。

[0191] 图3为又一种安全策略确定流程，与图2相比的区别在于：SM接收到会话请求后，除[0192] 了网络ID和安全需求1(可能还包括UEID)之外，还向Policy control网元发送业务参数，例如业务ID和APP ID的至少一项。Policy control网元获取安全需求1之后，向DN服务器，或者UE2(图3中未画出)发出安全需求请求，其中，安全需求请求中包括UE ID和业务参数(例如业务ID或者APP ID)的至少一项。Policy control网元接收DN服务器，或者UE2反馈的安全需求4。Policy control网元依据安全需求1、安全需求3和安全需求4确定安全策略。

[0193] 当然，也可以由SM向DN服务器，或者UE2发出安全需求请求；并接收DN服务器，或者UE2反馈的安全需求4，再由SM将安全需求4发给Policy control网元。优选地，为了简化交互流程，SM可以先获取安全需求4之后，再将安全需求2和安全需求4一并发给Policy control网元。

[0194] 在图2或图3中，步骤1～步骤2为SM获取安全需求1和各种标识、参数的过程，除此之外，运营商网络的网元还可以使用其它方式将安全需求1和各种标识、参数传输至 SM：

[0195] 第一种：

[0196] 1、在双向认证过程中，AU从AAA获取预先存储在AAA的安全需求1。

[0197] 2、AU不通过MM，而直接向SM发送会话请求。会话请求的具体内容如图2或图3所示，这里不再赘述。

[0198] 第二种：

[0199] 1、SM接收AN、AU或者MM发送的会话请求，会话请求中包括UEID、网络标识、业务参数的至少一种。

[0200] 2、SM根据UE ID从本地获取预先存储的安全需求1。

[0201] 第三种：

[0202] 1、SM接收AN、AU或者MM发送的会话请求，会话请求中包括UE ID、网络标识、业务参数的至少一种。

[0203] 2、SM从AAA、MM或AU获取预先存储的安全需求1。

[0204] 也就是说，除了SM和AAA之外，安全需求1也可以被预先存储在图1中的其它网元中。因为AAA目前用于存储用户的注册信息，所以，将安全需求1预先存储在AAA的优点在于安全性更高和便于统一管理。

[0205] 除了Policy control网元之外，安全需求3也可以被预先存储在图1中的其它网元中。因为Policy control网元在目前的(例如LTE)网络架构中用于QoS的协商，所以，将安全需求3预先存储在Policy control网元中，有利于将本实施例的安全策略确定方案与现有的策略确定流程实现逻辑上的兼容。

[0206] 以上几种方式中，无论哪种方式，只要涉及到安全需求1的获取，HSS的执行方式均可以参照图2所示的流程，这里不再赘述。

[0207] 图4为又一种安全策略确定流程，与图2或图3相比的区别在于，在UE附着到网络之后，UE1发起会话请求，在此情况下，UE1可以提供安全需求2和/或安全需求5，以使得Policy control网元依据更多的安全需求确定安全策略。图6包括以下步骤：

[0208] 1、UE附着到网络后，向MM发起会话请求，所述会话请求中包括：UE

[0209] ID和安全需求，可选地，还可能包括网络ID和/或业务参数。

[0210] 具体地，安全需求包括安全需求2和/或安全需求5。其中，UEID、安全需求，网络 ID和业务参数的具体内容如前所述，这里不再赘述。

[0211] 需要说明的是，在图2或图3所示的双向认证的过程中，UE发出的接入请求中也可以携带安全需求2和/或安全需求5。

[0212] 2、MM中保存有安全需求1，在接收到会话请求后，MM生成网络ID(例如会话ID)， MM发送会话请求至SM。会话请求中包括安全需求1、安全需求2和/或安全需求5、UEID、网络ID，还可能包括业务参数。

[0213] 3、SM接收到会话请求后，将安全需求1、安全需求2和/或安全需求5，可能还包括 UE ID和网络ID(例如会话ID)发给Policy control网元。

[0214] 4、Policy control网元依据SM发送的安全需求以及本地预先存储的安全需求3，确定安全策略。确定安全策略的具体规则如前所述，这里不再赘述。

[0215] 5、Policy control网元将安全策略发给SM。

[0216] 需要说明的是，图3中，1～3仅为一种实现方式，可选地，UE1发送的会话请求中可能不包括网络ID，MM接收到UE1的会话请求后，生成网络ID并发给SM。或者，也可以由SM而非MM生成网络ID，即SM接收到MM发送的会话请求后，生成网络ID，例如会话 ID。

[0217] UE直接发送会话请求至SM；此时SM获取安全需求1的方式可以参考之前的获取流程。

[0218] 安全策略的具体确定方式可以参见图3所示的过程，这里不再赘述。

[0219] 图5为又一种安全策略确定流程，与图4相比的区别在于，增加了安全

[0220] 需求4的获取过程，具体地：SM接收到会话请求后，除了UE ID、网络ID和各个安全需求之外，还向Policy control网元发送业务参数，例如业务ID、和APPID的至少一项。Policy control网元获取SM发送的安全需求之后，向DN服务器，或者UE2发出安全需求请求其中，安全需求请求中包括UE ID和APPID的至少一项。Policy control 网元接收DN服务器，或者UE2反馈的安全需求4。Policy control网元依据SM发送的安全需求和安全需求4确定安全策略。

[0221] 当然，也可以由SM向DN服务器，或者UE2发出安全需求请求，并接收DN服务器，或者UE2反馈的安全需求4，再由SM将安全需求4发给Policy control网元。SM获取以及向Policy control网元发送安全需求4的具体方式可以参见图4，这里不再赘述。

[0222] 除了图4或图5所示之外，SM获取安全需求1的其它实现方式还可以包括以下几种：

[0223] 第一种：

[0224] 1、SM接收AN、AU或者MM发送的会话请求，会话请求如图4或图5所示。

[0225] 2、SM根据UE ID从本地获取预先存储的安全需求1。

[0226] 第二种：

[0227] 1、SM接收AN、AU或者MM发送的会话请求，会话请求话请求如图4或图5所示。

[0228] 2、SM从AAA、MM或AU获取预先存储的安全需求1。

[0229] 以上举例均为Policy control网元依据各个安全需求确定安全策略的流程，除了Policy control网元之外，安全策略确定模块还可以设置在SM。

[0230] 在SM依据各个安全需求确定安全策略的情况下，SM获取安全需求1、安全需求2和/ 或5、UE ID、网络ID、业务参数的过程可以参见图2～图5，这里不再赘述。SM可以使用图2～图5的方式获取安全需求4，或者由Policy control网元以图2～图5的方式获取安全需求4后，再接收Policy control网元发送的安全需求4。SM可以向Policy control 网元发送安全需求请求(其中包括UEID、网络ID或业务参数的至少一项)，以从Policy control网元获取安全需求3。图6～图7仅为SM确定安全策略的举例，这里不再穷举所有情况。

[0231] 以上举例中，无论是Policy control网元还是SM，均依据至少两个安全需求确定安全策略。除了以上举例之外，也可以依据一个安全需求确定安全策略：即接收至少一个安全需求，但只使用其中的一部分确定安全策略，也可以接收至少一个安全策略，依据接收到的全部安全需求确定安全策略。本申请实施例中均不作限定。

[0232] 在上述流程中，网络ID中的会话ID，承载ID，流flow ID或者切片ID，均由运营商网络的网元，例如AN、MM、AU、KMS、AAA、SM或者Policy control网元生成。除此之外，会话ID，承载ID，流flow ID或者切片ID还可以由UE1生成，并携带在UE1向运营商网络发送的附着请求或者会话请求中，发给运营商网络中的网元，例如AN、MM、AU、 KMS、AAA、SM或者Policy control网元。例如图2中，在双向认证之前，UE1向运营商网络发送携带会话ID，承载ID，流flow ID或者切片ID的附着请求消息(属于UE1附着运营商网络的过程)。又例如，图4中，UE1向MM发送的回话请求中，还携带会话ID，承载ID，流flow ID或者切片ID。

[0233] 在UE1生成并向运营商网络发送会话ID，承载ID，流flow ID或者切片ID的情况下，运营商网络中的网元，例如AN、MM、AU、KMS、AAA、SM或者Policy control网元，将不再生成会话ID，承载ID，流flow ID或者切片ID。

[0234] 以上仅为举例说明，其它网元实现安全策略的确定功能，可以参见上述附图2-7的内容进行适应性调整，这里不再赘述。

[0235] 下面说明密钥配置模块的具体工作过程。

[0236] 密钥配置模块可以设置在UE1、运营商网络的网元(例如AN、MM、AU、KMS、AAA、SM、 Policy control网元)、网关、DN的网元(例如DN服务器)，或UE2中的一个或多个。保护密钥的生成方需要获取安全策略以及共享密钥K，以计算保护密钥，并且，将保护密钥分发给UE、网关(或者DN服务器，或者UE2)等其它网元。具体地，保护密钥的生成方可以将保护密钥发给KMS，由KMS发给UE、网关(或者DN服务器，或者UE2)等其它网元，也可以直接将保护密钥分发给UE、网关(或者DN服务器，或者UE2)等其它网元。

[0237] 下面以密钥配置模块设置在SM、KMS或者UE中的一个或多个进行举例说明。

[0238] 图8包括以下具体步骤：

[0239] 1、SM发送密钥请求消息给KMS。其中，密钥请求消息包括:UE ID 和安全策略，可选地，还可能包括网络ID和/或业务参数。其中，UEID、安全需求，网络I D和业务参数的具体内容如前所述，这里不再赘述。

[0240] 其中，安全策略的获取方式可以参见图2～图7所示。如果安全策略由Policy control 网元确定，则由Policy control网元发给SM。

[0241] 2、KMS依据安全策略以及共享密钥K计算保护密钥。保护密钥用于对UE与网关(或者DN服务器，或者UE2)之间的会话进行保护。

[0242] 其中，KMS与UE之间的共享密钥K可以在UE接入网络与MM建立上下文的过程中分配给UE和KMS，也可以在双向认证过程中或者双向认证过程之后分配给UE和KMS；也可能预置在UE与KMS内部。

[0243] 具体地，因为安全策略的内容中可能包括加密算法和完整性保护算法的至少一项，所以，可以依据安全策略计算出来一个保护密钥，可用于加密和/或完整性保护，也可能分别计算出加密保护密钥和完整性保护密钥。

[0244] 其中，保护密钥为：

[0245] KSID＝KDF(K，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce的至少一个)，policy set)。

[0246] 或者：

[0247] KSID＝KDF(K，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数， nonce的至少一个))。

[0248] 或者：

[0249] KSID_enc＝KDF(KSID，加密算法ID，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce的至少一个))。

[0250] 或者：

[0251] KSID_enc＝KDF(KSID，加密标识，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce的至少一个))。

[0252] 或者：

[0253] KSID_enc＝KDF(KSID，加密算法ID)。

[0254] 其中，policy set为安全策略，K为UE与KMS之间的共享密钥。

[0255] 如前所述，加密标识可以为一个字符串，用于标识此推衍的结果为加密密钥。nonce 为随机参数，可以由KMS选择，或者，由UE携带在会话请求中，使用随机数计算的目的在于，提高密钥的安全性和随机性。

[0256] 完整性保护密钥KSID_int为：

[0257] KSID_int＝KDF(KSID，完整性保护算法ID)。

[0258] 或者：

[0259] KSID_enc＝KDF(KSID，完整性保护标识，(UE ID，会话ID，承载ID，flow ID、切片ID， PLMN ID，业务参数，nonce的至少一个))。

[0260] 或者，

[0261] KSID_int＝KDF(KSID，完整性保护算法ID，(UE ID，会话ID，承载ID，flow ID、切片 ID，PLMN ID，业务参数，nonce的至少一个))。

[0262] 完整性保护标识可以为一个字符串，用于标识此推衍的结果为完整性保护密钥。

[0263] 上述KDF为密钥推衍函数，包括但不限于以下密码推衍函数：HMAC(如HMAC-SHA256， HMAC-SHA1)，NMAC，CMAC，OMAC，CBC-MAC，PMAC，UMAC和VMAC以及HASH算法等等。另外，由于安全策略中的需求不同，例如，安全策略1中保护密钥长度要求为256bit；而安全策略2中保护密钥长度要求为128bit；此时KMS可以采用不同的密钥推衍算法，来满足不同安全策略对于不同保护密钥长度的需求(例如，采用HMAC-SHA1来生成128bit 的保护密钥，采用HMAC-SHA256生成256bit保护密钥)；另外KMS也可能，仅采用一个算法生成保护密钥，再采用缩短(truncate)或延长等等的方式生成其他长度的保护密钥。 KMS对于保护密钥长度的处理，包括但不限于上述处理方式。

[0264] 以上使用到的参数承载ID，flow ID、切片ID、加密算法ID、session ID都可以与上述安全需求2和/或安全需求5一并携带在由UE发送的会话请求中。

[0265] 3、KMS将保护密钥发给SM，可能还包含UE ID和/或网络ID。

[0266] 4、SM将保护密钥、网络ID和UE ID分发给网关(或者DN服务器，或者UE2)以及 UE1。具体地，SM可以将保护密钥携带在用户面建立(User Plane Setup)消息中发给网关(或者服务器，或者UE2)，将保护密钥携带在会话建立完成Session Setup Complete 消息中发给UE。

[0267] 也可能，KMS直接将网络ID和保护密钥发送至网关(或者DN服务器，或者UE2)，发送的消息可能还包含UE ID。

[0268] 若保护密钥推衍中包含nonce，则KMS也会将nonce发送至SM，再由SM发送至UE；或者KMS直接将nonce发送至UE。

[0269] 图9与图8的区别在于，UE从SM处接收到安全策略，根据安全策略，计算出保护密钥。如果UE计算保护密钥是需要使用到随机参数，则随机参数可以由KMS发给UE，也可以由UE自己生成。

[0270] 还可能，KMS将保护密钥发给MM。具体地，MM可以在向SM发送会话请求并接收到SM 发送的会话响应后，向KMS请求会话保护密钥。

[0271] 还可能，SM中预先存储共享密钥K，或者，在UE与AU进行双向认证后，KMS获得共享密钥K，再由KMS发给SM共享密钥K。UE和SM均计算保护密钥。

[0272] 图10为本申请实施例公开的又一种密钥分配方法，包括以下步骤：

[0273] 1、SM发送密钥请求消息给KMS。其中，密钥请求消息包括:UE ID

[0274] 和安全策略，可选地，还可能包括网络ID和/或业务参数。其中，UEID、安全需求，网络ID和业务参数的具体内容如前所述，这里不再赘述。

[0275] 其中，安全策略的获取方式可以参见图2～图7所示。如果安全策略由Policy control 网元确定，则由Policy control网元发给SM。

[0276] 2、KMS依据安全策略以及共享密钥K计算第一密钥。第一密钥用于对UE与网关(或者服务器(包括DN或者运营商网络的服务器，以下均简称为服务器)，或者控制器(包括DN或者运营商网络的控制器，以下均简称为控制器)，或者UE2)之间的会话进行保护。

[0277] 其中，KMS与UE之间的共享密钥K可以在UE接入网络与MM建立上下文的过程中分配给UE和KMS，也可以在双向认证过程中或者双向认证过程之后分配给UE和KMS，也可能预置在UE与KMS内部。

[0278] 具体地，因为安全策略的内容中可能包括加密算法和完整性保护算法的至少一项，所以，可以依据安全策略计算出来一个第一密钥，可用于加密和/或完整性保护，也可能分别计算出加密保护密钥和完整性保护密钥。依据安全策略以及共享密钥K计算保护密钥的方式具有多种，包括但不限于以下几种方式：

[0279] 其中，第一密钥(即前述实施例中的保护密钥，为了与前述实施例统一，以下统称为保护密钥)为：

[0280] KSID＝KDF(K，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce的至少一个)，policy set)。

[0281] 或者：

[0282] KSID＝KDF(K，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数， nonce的至少一个))。

[0283] 加密保护密钥K_SID_enc为：

[0284] KSID_enc＝KDF(K，(加密算法ID，UEID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce，policy set的至少一个))。

[0285] 或者：

[0286] KSID_enc＝KDF(K，(加密标识，UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce，policy set的至少一个))。

[0287] 其中，policy set为安全策略，K为UE与KMS之间的共享密钥，

[0288] UE ID的定义如之前实施例所述。

[0289] 如前所述，加密标识可以为一个字符串，用于标识此推衍的结果为加密密钥。nonce 为随机参数，可以由KMS选择，或者，由UE携带在会话请求中，使用随机数计算的目的在于，提高密钥的安全性和随机性。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce 来自UE(由UE携带在会话请求中)。

[0290] 完整性保护密钥KSID_int为：

[0291] KSID_int＝KDF(K，(完整性保护标识，UE ID，会话ID，承载ID，flow ID、切片ID， PLMN ID，业务参数，nonce，policy set的至少一个))。

[0292] 或者，

[0293] KSID_int＝KDF(K，(完整性保护算法ID，UE ID，会话ID，承载ID，flow ID、切片 ID，PLMN ID，业务参数，nonce，policy set的至少一个))。

[0294] 完整性保护标识可以为一个字符串，用于标识此推衍的结果为完整性保护密钥。nonce 为随机参数，可以由KMS选择，或者，由UE携带在会话请求中，使用随机数计算的目的在于，提高密钥的安全性和随机性。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce 来自UE(由UE携带在会话请求中)。

[0295] 以上使用到的参数承载ID，flow ID、切片ID、session ID都可能与上述安全需求2 和/或安全需求5一并携带在由UE发送的会话请求中，或者携带在UE的首次接入运营商网络的请求中，或者携带在密钥请求消息中。另外加密算法ID和完整性保护算法ID可以为安全策略的内容。

[0296] 3、KMS将第2步中获得的密钥(即，保护密钥KSID，加密保护密钥 KSID_enc和完整性保护密钥KSID_int的至少一项)发给SM，可能还包含UE ID和/或网络ID。

[0297] 4、SM将第2步中获得的密钥(即，保护密钥KSID，加密保护密钥KSID_enc和完整性保护密钥KSID_int的至少一项)分发给网关(或者服务器，或者控制器，或者UE2)以及UE1。所述消息可能还包括网络ID，UE ID和安全策略的至少一项。具体地，SM可以将保护密钥携带在用户面建立(User Plane Setup)消息中发给网关(或者服务器，或者控制器，或者UE2)。

[0298] 也可能，第4步中，SM不向UE发送第2步中获得的密钥，而继续执行以下步骤：

[0299] 5、SM将安全策略发给UE，所述消息可能还包括网络ID和UE ID的至少一项。

[0300] 6、UE从SM(或者policy control，或者KMS)处接收到安全策略，根据安全策略，采用与上述相同的方式计算出KSID、加密保护密钥KSID_enc和完整性保护密钥KSID_int的至少一项。如果UE计算保护密钥需要使用到随机参数，则随机参数可以由KMS发给UE，也可以由UE自己生成。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS (由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce来自UE(由UE携带在会话请求中)。

[0301] 以上公开了UE自己生成或者从SM处获得保护密钥KSID、加密保护密钥KSID_enc和完整性保护密钥的至少一项，除此之外，也可能，UE从KMS(或者policy control网元)处接收到保护密钥KSID、加密保护密钥KSID_enc和完整性保护密钥的至少一项以及安全策略。

[0302] 图11为本申请实施例公开的又一种密钥配方法，包括以下步骤：

[0303] 1、SM发送密钥请求消息给KMS。其中，密钥请求消息包括:UE ID

[0304] 和安全策略，可选地，还可能包括网络ID和/或业务参数。其中，UEID、安全需求，网络ID和业务参数的具体内容如前所述，这里不再赘述。

[0305] 其中，安全策略的获取方式可以参见图2～图7所示。如果安全策略由Policy control 网元确定，则由Policy control网元发给SM。

[0306] 2、KMS依据安全策略以及共享密钥K计算保护密钥。保护密钥用于对UE与网关(或者服务器，或者控制器，或者UE2)之间的会话进行保护。

[0307] 其中，KMS与UE之间的共享密钥K可以在UE接入网络与MM建立上下文的过程中分配给UE和KMS，也可以在双向认证过程中或者双向认证过程之后分配给UE和KMS，也可能预置在UE与KMS内部。

[0308] 具体地，因为安全策略的内容中可能包括加密算法和完整性保护算法的至少一项，所以，可以依据安全策略计算出来一个保护密钥，可用于加密和/或完整性保护，也可能分别计算出加密保护密钥和完整性保护密钥。依据安全策略以及共享密钥K计算保护密钥的方式具有多种，包括但不限于以下几种方式：

[0309] 其中，保护密钥为：

[0310] KSID＝KDF(K，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce的至少一个)，policy set)。

[0311] 或者：

[0312] KSID＝KDF(K，(UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数， nonce的至少一个))。

[0313] 以上使用到的参数承载ID，flow ID、切片ID、加密算法ID、session ID都可以与上述安全需求2和/或安全需求5一并携带在由UE发送的会话请求中，或者携带在UE的首次接入运营商网络的请求中，或者携带在密钥请求消息中。另外加密算法ID和完整性保护算法ID可以为安全策略的内容。nonce为随机参数，可以由KMS选择，或者，由UE 携带在会话请求中，使用随机数计算的目的在于，提高密钥的安全性和随机性。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce来自UE(由UE携带在会话请求中)。

[0314] 3、KMS将保护密钥KSID发给SM，可能还包含UE ID和/或网络ID。

[0315] 4、SM根据安全策略和K_SID计算出加密保护密钥和/或完整性保护密钥。计算方式包括但不限于以下方式：

[0316] 加密保护密钥KSID_enc为：

[0317] KSID_enc＝KDF(KSID，(加密算法ID，UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce，policy set的至少一个))。

[0318] 或者：

[0319] KSID_enc＝KDF(KSID，(加密标识，UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce，policy set的至少一个))。

[0320] 其中，policy set为安全策略，K为UE与KMS之间的共享密钥，UE ID

[0321] 如前所述，加密标识可以为一个字符串，用于标识此推衍的结果为加密密钥。nonce 为随机参数，可以由KMS选择，或者，由UE携带在会话请求中，使用随机数计算的目的在于，提高密钥的安全性和随机性。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce 来自UE(由UE携带在会话请求中)。

[0322] 完整性保护密钥KSID_int为：

[0323] KSID_int＝KDF(KSID，(完整性保护标识，UE ID，会话ID，承载ID，flowID、切片ID， PLMN ID，业务参数，nonce，policy set的至少一个))。

[0324] 或者，

[0325] KSID_int＝KDF(KSID，(完整性保护算法ID，UE ID，会话ID，承载ID，flow ID、切片ID，PLMN ID，业务参数，nonce，policy set的至少一个))。

[0326] 完整性保护标识可以为一个字符串，用于标识此推衍的结果为完整性保护密钥。nonce 为随机参数，可以由KMS选择，或者，由UE携带在会话请求中，使用随机数计算的目的在于，提高密钥的安全性和随机性。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce 来自UE(由UE携带在会话请求中)。

[0327] 以上使用到的参数承载ID，flow ID、切片ID、session ID都可能与上述安全需求2 和/或安全需求5一并携带在由UE发送的会话请求中，或者携带在UE的首次接入运营商网络的请求中，或者携带在密钥请求消息中。另外加密算法ID和完整性保护算法ID可以为安全策略的内容。

[0328] 5、SM将第4步中获得的密钥(即，加密保护密钥KSID_enc和完整性保护密钥KSID_int 的至少一项)分发给网关(或者服务器，或者控制器，或者UE2)以及UE1。所述消息可能还包括网络ID，UE ID和安全策略的至少一项。具体地，SM可以将保护密钥携带在用户面建立(User Plane Setup)消息中发给网关(或者服务器，或者控制器，或者UE2)，将保护密钥携带在会话建立完成Session Setup Complete消息中发给UE。

[0329] 也可能，在第5步中，SM不向UE发送第4步中获得的密钥，而执行以下两种流程中的任意一种：

[0330] 第一种可能的流程：SM将安全策略发给UE，所述消息可能还包括网络ID和UE ID的至少一项。UE从SM(或者policy control，或者KMS) 处接收到安全策略，根据安全策略，采用与上述实施例相同的方式计算出保护密钥。如果 UE计算保护密钥是需要使用到随机参数，则随机参数可以由KMS发给UE，也可以由UE自己生成。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS 选择，直接发送给UE，或通过SM发送至UE)，另一个nonce来自UE(由UE携带在会话请求中)。

[0331] 第一种可能的流程：SM将KSID和安全策略发送给UE，UE从SM(或者 policy control，或者KMS)处接收到KSID和安全策略，根据安全策略，采用与上述实施例相同的方式计算出保护密钥。如果UE计算保护密钥是需要使用到随机参数，则随机参数可以由KMS发给UE，也可以由UE自己生成。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce来自UE(由UE携带在会话请求中)。

[0332] 以上公开了UE自己生成或者从SM处获得保护密钥KSID、加密保护密钥KSID_enc和完整性保护密钥KSID_int的至少一项，除此之外，也可能，UE从KMS(或者policy control网元) 处接收到保护密钥KSID、加密保护密钥KSID_enc和完整性保护密钥的至少一项以及安全策略。

[0333] 从上述过程可以看出，图11与图8～图10的区别在于，KMS推衍得到KSID之后，将KSID发送至SM，SM再根据KSID，推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int，再将加密保护密钥KSID_enc和/或完整性保护密钥KSID_int发送至端到端通信的两端。也就是说，两个不同的网元设备各进行一次密钥推衍。

[0334] 图12与图11的区别在于，KMS推衍得到KSID之后，将KSID发送至SM，SM再将KSID发送至网关(或者服务器，或者控制器，或者UE2)以及UE；网关(或者服务器，或者控制器，或者UE2)以及UE1根据KSID，推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int。

[0335] 也可能SM根据KSID，推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int，将KSID_enc和KSID_int发送至UE。

[0336] 也可能SM仅发送安全策略至UE，UE根据安全策略推衍得到加密保护密钥KSID_enc和/ 或完整性保护密钥KSID_int。

[0337] 消息中其他参数的传递以及推衍的公式可以参考图11所对应的实施例。上述消息中，可能包含安全策略，网络ID和UE ID至少一项。

[0338] 图13与图11的区别在于，SM保存有共享密钥，推衍得到KSID，之后再基于KSID推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int，并发送加密保护密钥KSID_enc和/或完整性保护密钥KSID_int至网关(或者服务器，或者控制器，或者UE2)以及UE。

[0339] 也可能SM发送KSID和安全策略至UE，以使UE推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int。

[0340] 也可能SM仅发送安全策略至UE，UE根据安全策略推衍得到加密保护密钥KSID_enc和/ 或完整性保护密钥KSID_int。

[0341] 消息中其他参数的传递以及推衍的公式可以参考图11。上述消息中，包含安全策略，网络ID和UE ID至少一项。

[0342] 图14与图11的区别在于，SM推衍得到KSID，之后将KSID发送至网关(或者服务器，或者控制器，或者UE2)以及UE；之后网关(或者服务器，或者控制器，或者UE2)和UE，根据KSID，推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int。

[0343] 也可能SM根据KSID，推衍出加密保护密钥KSID_enc和/或完整性保护密钥KSID_int，将KSID_enc和KSID_int发送至UE。

[0344] 也可能SM仅发送安全策略至UE，UE根据安全策略推衍得到加密保护密钥KSID_enc和/ 或完整性保护密钥KSID_int。

[0345] 消息中其他参数的传递以及推衍的公式可以参考图11所对应的实施例。上述消息中，可能包含安全策略，网络ID和UE ID至少一项。

[0346] 需要说明的是，以上实施例中，主要以KMS或者SM进行密钥推衍进行举例说明，除此之外，保护密钥也可以由UE、AN、MM、AU、KMS、AAA、SM、或者Policy control网元推衍得到。

[0347] 其中，MM推衍生成保护密钥的过程可以参见上述实施例中SM推衍生成保护密钥的过程。

[0348] policy control可以采用与上述KMS相同的流程完成密钥的推衍，即接收到密钥请求之后，再推衍密钥。也可能，在policy control确定安全策略之后，立即执行安全密钥的推衍。流程如图15所示。

[0349] 如图15所示，policy control网元推衍生成保护密钥的过程，包括以下步骤：

[0350] 1、policy control网元在确定安全策略或者从SM接收到安全策略后，推衍生成密钥，具体的，可以直接计算KSID，KSID_enc和KSID_int的至少一项，也可以先计算出KSID，再根据 KSID计算出KSID_enc和KSID_int的至少一项。Policy control可以在终端认证结束后，从其他网元处(KMS，AU，SM，MM或者AAA)接收到共享密钥；或者发起密钥请求，所述请求中保护UE ID，进而获得共享密钥。

[0351] 推衍生成密钥的具体方式可以参见上述实施例。

[0352] 2、policy control网元将生成的密钥(还可能包括安全策略)发给SM，再由SM将密钥发给端到端的通信的两端。

[0353] 或者，policy control网元通过SM将生成的密钥(还可能包括安全策略)发给UE，并直接将生成的密钥发给端到端通信的另一端。

[0354] 或者，直接发送保护密钥(还可能包括安全策略)至UE。

[0355] 或者，发送KSID至SM，SM再推衍并发送KSID_enc和KSID_int至两端。

[0356] 在UE推衍生成保护密钥的情况下，UE从SM(或者policy control，或者KMS)处接收到安全策略，根据安全策略，采用与上述实施例相同的方式计算出保护密钥。如果UE 计算保护密钥需要使用到随机参数，则随机参数可以由KMS发给UE，也可以由UE自己生成。也可能密钥推衍中包含两个nonce的至少一项，其中一个nonce来自KMS(由KMS选择，直接发送给UE，或通过SM发送至UE)，另一个nonce来自UE(由UE携带在会话请求中)。

[0357] 或者，UE从SM(或者policy control，或者KMS)处接收到保护密钥KSID，加密保护密钥KSID_enc和完整性保护密钥KSID_int的至少一项，或者UE接收到KSID后，再根据KSID计算得到KSID_enc和KSID_int。

[0358] UE推衍中使用到的参数承载ID，flow ID、切片ID、session ID可能存在UE内部，或者由网络网元(如KMS，MM，SM，policy control，AU，网关，AAA等)发送至UE，如通过会话响应消息发送至UE。

[0359] 考虑上述安全策略仅包含是否完整性保护，或者是否加密，或者是否完整性保护和加密的安全需求需求的情况，SMF获得安全策略之后(可以从PCF处获得，或者自己协商得到)，后续处理包括以下两种可能性：

[0360] 可能性1：SMF获得安全策略后，根据UE的安全能力和SMF内部存储的UPF算法优先级确定安全算法(包括加密算法，或者完整性保护算法，或者加密算法和完整性保护算法)，再生成安全密钥(包括，加密密钥，或者完整性保护密钥，或者加密密钥和完整性保护密钥)；同时将已确定安全算法和已生成的密钥发送至UPF。另外SMF也将以确定的安全算法发送至UE，以使UE生成安全算法对应的安全密钥。SMF也可能将安全策略发送至UE。

[0361] 可能性2：SMF计算密钥K_SID，将安全策略和K_SID发送至UPF。同样，UPF也可以通过SMF接收UE的安全能力。UPF根据UE的安全能力和算法优先级确定安全算法(包括加密算法，或者完整性保护算法，或者加密算法和完整性保护算法)，再生成安全密钥(包括，加密密钥，或者完整性保护密钥，或者加密密钥和完整性保护密钥)；UPF将安全算法发送至SMF，SMF再将安全算法发送至UE，以使UE生成安全算法对应的安全密钥。也可能UPF直接将安全算法发送至UE，以使UE生成安全算法对应的安全密钥。

[0362] 可能性3：SMF获得安全策略之后，将安全策略发送至AN，以使AN根据安全策略， UE的安全能力，以及AN自身的算法优先级列表，确定UE与AN之间安全保护算法，之后 AN将安全保护算法发送至UE，以使UE生成安全算法对应的安全密钥。

[0363] 如前所述，上述是针对UE与UPF之间数据保护的安全策略协商以及分发的流程。针对UE与AN之间数据保护的安全策略协商和分发的流程与UE与UPF之间流程类似，不同点在于：安全策略的确定需要考虑AN的安全能力，或者AN的算法优先级列表。同时安全策略可以为确定的安全算法，也可以为是否完整性保护，或者是否加密，或者是否机密和完整性保护。

[0364] 如前所述，最终确定的安全策略可以为安全算法的优先级列表，包括加密算法的优先级列表，或者完整性保护算法的优先级列表，或者加密和完整性保护算法的优先级列表。之后UPF可以根据UE的安全能力，安全算法优先级列表，和UPF的安全能力，确定UPF 的安全保护算法。之后其他流程与前面实施例流程相同。

[0365] 如前所述，最终确定的安全策略可以为安全算法的优先级列表，包括加密算法的优先级列表，或者完整性保护算法的优先级列表，或者加密和完整性保护算法的优先级列表。之后AN可以根据UE的安全能力，安全算法优先级列表，和AN的安全能力，确定AN的安全保护算法。之后其他流程与前面实施例流程相同。

[0366] 如前所述，以上图示仅以端到端的会话保护为例进行说明，需要强调的是，对基于承载、流flow或者切片的端到端保护，流程与以上图例类似，但需要将以上图例中的会话参数替换为相应参数，具体地，将会话ID相应替换为承载ID、流flow ID或切片ID。将用户面建立消息相应替换为承载建立消息、流flow建立消息或切片建立消息。

[0367] 密钥协商流程和安全策略协商流程没有具体的先后顺序，例如KSID密钥的生成可以在会话(承载、流flow或者切片)建立之前、建立过程中或之后执行。加密和/或完整性保护密钥的生成，可以在KSID生成之后的任一节点完成。

[0368] 如图4、5即图7所示流程均为UE1向运营商网络发送会话、承载、流flow或者切片请求，且运营商网络同意请求的情况下，安全策略的确定过程或密钥配置过程。需要说明的是，如果运营商网络不同意UE1的会话、承载、流flow或者切片请求，则向UE1发送拒绝消息。

[0369] 图2-图9所示的流程中，使用到的安全需求为基于安全保护的终结点在用户面节点 (User plane function，UPF)的情况。而安全保护的终结点还可能在分支点branching point或者ULCL。

[0370] 确定安全保护的终结点，可以由移动性管理(Mobility Management，MM)网元、会话管理网元(Session Management，SM)、认证服务控制器(Authentication Server Function，AUSF)、安全锚点功能网元(Security Anchor Function，SEAF)、移动性管理实体(Mobility Management Entity，MME)、归属签约用户服务器(Home Subscriber Server，HSS)、鉴权中心(AUthentication Center，AuC)、认证信任状存储和处理功能网元(Authentication Credential Repository and Processing Function，ARPF)、安全上下文管理网元(Security Context Management Function(SCMF)、接入与移动管理功能网元(Access and Mobility management Function，AMF)、接入节点(Access network，AN)、用户面节点(User plane function，UPF)、网络中的认证单元(英文： Control Plane-Authentication Unit，简称：CP-AU)，或者安全策略确定模块执行。

[0371] 下面仅以安全策略确定模块确定安全保护的终结点为进行阐述。

[0372] 在图2-图9所示的流程中，在UE1发送附着请求之后，或者在双向认证成功后，或者在UE1的建立会话过程中(可以在UE1发送会话请求前，也可以在UE1发送会话请求后)，安全策略确定模块还可以执行步骤：确定安全保护的终结点，如果安全保护的终结点为 UPF，则执行图2-图9所示的流程中双向认证或者UE1发送会话请求之后步骤。如果安全保护的终结点为AN，则将图2-图9所示的流程中的安全需求3或者UE2的安全需求(安全需求4的一种情况)替换为AN的安全需求。AN的安全需求的获取方式可以为，在之前实施例的基础上，AN接收到UE1的请求消息之后，将AN的安全需求一起发送至网络。

[0373] 图16(a)和16(b)为分支branching的场景。在此场景下，安全策略确定模块需要判断安全保护的终结点是branching point，还是UPF。如果安全保护的终结点为UPF，则执行图2-图9所示的流程中双向认证或者UE1发送会话请求之后步骤。如果安全保护的终结点为branchingpoint，则将图2-图9所示的流程中的安全需求3或者UE2的安全需求(安全需求4的一种情况)替换为branching point的安全需求。

[0374] 图17为会话链路为UE-AN-UPF(上行数据分类器功能，uplink classifier functionality，ULCL)-UPF(anchor)的场景。在此场景下，安全策略确定模块需要判断安全保护的终结点是UPF(ULCL)还是UPF(anchor)，如果是UPF(anchor)，则执行图2-图9所示的流程中双向认证或者UE1发送会话请求之后步骤。如果安全保护的终结点为ULCL，则将图2-图9所示的流程中的安全需求3或者UE2的安全需求(安全需求 4的一种情况)替换为ULCL的安全需求。

[0375] 针对图18所示的Home-routed漫游场景中，用户面路径为UE-AN-UPF(VPLMN)-UPF (HPLMN)。此时端到端安全保护的终结点可以为UPF(拜访地公用陆地移动通信网，visited public landmobile network，VPLMN)或者UPF(归属地公用陆地移动通信网，home public land mobile network，HPLMN)。场景，安全策略确定需要判断安全保护的终结点是UPF (VPLMN)还是UPF(HPLMN)，如果是UPF(VPLMN)，则安全需求3为VPLMN的网关的安全需求，如果是UPF(HPLMN)，则安全需求3为HPLMN的网关的安全需求。

[0376] 其中，安全策略确定模块可以根据从HSS，AUSF，ARPF，AMF，SEAF，SCMF，SM或AuC 等其它功能网元处接收到UE1的配置信息或节点策略，或者从本地存储中获得UE或会话 (或者flow，承载，切片)的配置信息或节点策略，根据UE或会话(或者flow，承载，切片)的配置信息判定安全保护的终结点是AN、branching point、ULCL还是UPF。此节点策略可以为每个UE的节点策略，可以为针对此类业务的节点策略，可以为针对此类切片的节点策略，可以针对此类数据类型的节点策略。另外，安全策略确定模块也可以根据业务的安全需求或者服务器侧安全需求，业务类型，切片类型，或者切片策略，确定安全保护的终结点。

[0377] 以上举例均为针对会话粒度的安全策略协商，以及会话数据保护密钥生成和分发过程。需要说明的是，上述方法也适用于针对切片粒度的安全策略协商，以及切片中数据保护密钥的生成和分发。具体的实施方式与会话粒度类似，不同点在于，其中的会话ID为切片ID，并且，确定的是UE在此切片内的保护密钥，保护节点可以是切片内的功能网元，如UPF。

[0378] 切片的安全策略确定模块可以设置在移动性管理(Mobility Management，MM)网元、会话管理网元(Session Management，SM)、认证服务控制器(Authentication Server Function，AUSF)、安全锚点功能网元(Security Anchor Function，SEAF)、移动性管理实体(Mobility Management Entity，MME)、归属签约用户服务器(Home Subscriber Server，HSS)、鉴权中心(AUthentication Center，AuC)、认证信任状存储和处理功能网元(Authentication Credential Repository and Processing Function，ARPF)、安全上下文管理网元(Security Context Management Function，SCMF)、接入与移动管理功能网元(Access and Mobility management Function，AMF)、、AN节点、、UPF节点、网络中的认证单元(Control Plane-Authentication Unit，CP-AU)、或者安全策略确定模块。

[0379] 具体的安全策略确定流程分为以下三种情况：

[0380] 会话建立之前，切片安全策略确定模块(例如可等同于上述安全策略确定模块)，[0381] 在认证完成之后，采用与之前实施例相同的方式，根据UE1的安全能力，业务安全需求，切片内功能网元的安全能力，网络预置的UE1的安全能力和应用服务器侧安全需求的至少一项确定切片的安全策略，其中切片内功能网元的安全能力可以通过HSS，AUSF， ARPF，AMF，SEAF，SCMF，SM或AuC等处获得。

[0382] 会话建立中，采用与之前类似的方式，确定切片安全策略。

[0383] 会话建立之后，其中会话建立过程中不包含安全策略和密钥的协商，在会话建立之后，确定切片的安全策略。

[0384] 安全策略确定模块确定切片的安全策略之后，再发送切片的安全策略至UE。密钥的分发流程与会话的流程类似。最终UE与切片内功能网元获得安全保护密钥和安全保护策略。

[0385] 本申请实施例所述的密钥配置流程，能够为UE及网关(或者DN服务器，或者UE2) 配置会话保护密钥，因此，基于5G移动通信架构实现了端到端的会话保护。与现有的分段加密的方式相比，具有更好的安全性。

[0386] 并且，可以依据UE、运营商网络以及数据网络的安全需求确定安全策略，因此，可以依据不同的各方的安全需求确定会话保护密钥，与现有技术中所有业务数据均在基站侧进行同一保护密钥的加密而言，能够实现差异化的安全保护。

[0387] 图19为本申请实施例公开的一种SM网元，通信组件和处理器，还可以包括存储器。其中，通信组件用于接收端到端的通信的请求。处理器用于获取安全策略。通信组件还用于，向所述用户设备发送所述安全策略和/或所述保护密钥，以及向所述端到端的通信的另一端设备发送所述安全策略和/或所述保护密钥。通信组件和处理器的功能的实现具体方式可以参见图2～图15所示，这里不再赘述。

[0388] 本申请实施例还公开了一种KMS、MM、HSS以及Policy control网元，具体的结构包括通信组件和处理器的功能的实现具体方式可以参见图2～图15所示，这里不再赘述。

[0389] 图20为本申请实施例公开的一种用户设备，包括通信组件和处理器，通信组件和处理器可以通过总线进行通信。

[0390] 其中，通信组件用于发送请求以及接收响应。所述请求中包括所述用户设备的标识。所述响应中携带安全策略。

[0391] 处理器用于获取保护密钥，所述保护密钥用于对所述端到端的通信进行保护，所述保护密钥依据所述安全策略以及所述用户设备与所述运营商网络之间的共享密钥确定。

[0392] 通信组件和处理器的功能的实现具体方式可以参见图2～图15所示，这里不再赘述。

[0393] 以上各个设备之间通过相互协作可实现安全策略的确定和端到端保护密钥的生成，从而使得基于5G移动通信架构实现了端到端的会话保护。

[0394] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。