一种active状态下的密钥更新方法和设备

摘要

本发明公开了一种active状态下的密钥更新方法，包括以下步骤：处于active状态下的用户终端或网络侧在满足预设条件时，发起密钥更新；所述网络侧和用户终端更新密钥并协商新密钥的启动时间。本发明还公开了一种active状态下的密钥更新设备。通过使用本发明，实现了不同情况下，处于active状态的用户终端和网络侧主动发起密钥更新流程，解决了处于active状态的会话中的密钥更新问题。

说明书

技术领域

本发明涉及通信技术领域，尤其涉及一种active状态下的密钥更新方法和设备。

背景技术

为了保证未来3GPP(3^rd Generation Partnership Project，第三代)系统的竞争力，一个接入技术演进的工作正在3GPP组织内部进行。特别是为了加强3GPP系统处理快速增长的IP数据业务的能力，在3GPP系统内使用分组技术需要进一步的增强。这类技术演进中最重要的几个部分包括：减少时延和反应时间，更高速的用户数据速率，增强的系统容量和覆盖范围以及运营商整体成本的降低。并且，演进的网络结构对于现有网络的后向兼容性也是一个重要的指标，其中在安全方面，要求演进网络中的用户安全流程必须确保提供至少和目前2G和3G系统相同级别的安全机制。

如图1所示，无线演进网络的核心网主要包含MME(Mobility ManagementEntity移动管理实体)、SAE Gateway(System Architecture Evolution Gateway，系统架构演进网关)等逻辑功能体，其中的MME负责控制面的移动性管理，包括用户上下文和移动状态管理，分配用户临时身份标识、安全功能等；SAEGateway负责空闲状态下为下行数据发起寻呼，管理保存IP承载参数和网络内路由信息等，充当不同接入系统间的用户面锚点。在无线演进网络中，用户面的安全被终结在接入网，其中接入网BS(Base Station，基站)称为eNB(evolved NodeB，演进基站)，信令面的安全分为接入层信令RRC(RadioResource Control无线资源控制)信令和非接入层信令NAS(Non AccessStratum，非接入层)信令两个部分，分别终结在接入网和核心网。信令保护和数据保护所需密钥由AKA(Authentication and Key Agreement，密钥认证)过程产生的密钥CK，IK进行各种衍生而来，衍生关系如图2所示。

其中K_eNB-RRC-INI是RRC信令完整性保护密钥，K_eNB-RRC-ENC是RRC信令加密保护密钥，K_eNB-RRC-UP是用户面数据加密保护密钥。而K_NAS-ENC是NAS信令加密保护密钥，K_NAS-INI是NAS信令完整性保护密钥。

目前，在SAE/LTE系统中，已经有相关讨论涉及在密钥协商后如何立即应用到正在激活的会话中的方法进行了讨论。其中所有的方法都是以密钥已经成功更新为新密钥为前提，但都没有涉及如何获得该新密钥的过程。因此需要提出一种方法解决如何在active状态下协商新密钥。另外active状态密钥更新要求网络侧也有发起密钥协商的能力。现有技术中，网络侧并不会在通信中主动地发起密钥更新流程，而是只有当用户从非active状态到active状态转换，向网络侧发起的初始NAS消息后，如附着请求，paging(寻呼)响应，位置更新请求等，才会判断是否需要更新某种密钥。

发明内容

本发明的实施例提供一种active状态下的密钥更新方法和设备，用以在active状态下实现密钥的更新。

为达到上述目的，本发明的实施例提供一种active状态下的密钥更新方法，包括以下步骤：

处于active状态下的用户终端或网络侧在满足预设条件时，发起密钥更新；

所述网络侧和用户终端更新密钥并协商所述新密钥的启动时间。

本发明的实施例还提供一种用户终端，用于在active状态下进行密钥更新，包括：

终端密钥更新检测单元，用于根据预设条件判断是否需要发起密钥更新；

终端密钥更新发起单元，用于在所述终端密钥更新检测单元判断为需要进行密钥更新时，向网络侧发送密钥更新请求消息。

本发明的实施例还提供一种网络侧实体，用于在active状态下进行密钥更新，包括：

密钥更新检测单元，用于根据预设条件判断是否需要发起密钥更新；

密钥更新发起单元，用于在所述密钥更新检测单元判断为需要进行密钥更新时发送请求消息，用于指示密钥更新；

密钥更新单元，用于在用户终端或网络侧实体发起密钥更新时，进行密钥的更新。

与现有技术相比，本发明的实施例具有以下优点：

实现了不同情况下，处于active状态的用户终端和网络侧主动发起密钥更新流程，解决了处于active状态的会话中的密钥更新问题。

附图说明

图1是现有技术中无线演进网络的结构示意图；

图2是现有技术中密钥的衍生关系示意图；

图3是本发明的实施例一中active状态下的密钥更新方法流程图；

图4是本发明的实施例二中UE主动发起的active状态下的密钥更新流程图；

图5是本发明的实施例三中网络侧eNB主动发起的active状态下的密钥更新流程图；

图6是本发明的实施例五中网络侧eNB主动发起的active状态下的密钥更新流程图；

图7是本发明的实施例六中网络侧MME主动发起的active状态下的密钥更新流程图；

图8是本发明的实施例七中eNB通过空口密钥更新过程将新密钥通知UE的流程图；

图9是本发明的实施例八中eNB通过空口密钥更新过程将新密钥通知UE的流程图；

图10是本发明的实施例九中active状态下的密钥更新系统示意图。

具体实施方式

以下结合附图和实施例，对本发明的实施方式做进一步的说明。

本发明的实施例一中，一种active状态下的密钥更新方法为：由UE决定是否需要在active状态下更新密钥，该active状态下的密钥更新方法如图3所示，包括如下步骤：

步骤s301、处于active状态的用户终端或网络侧根据预先的设置，判断需要进行密钥更新并发起密钥更新。

该预先的设置可以包括：(1)用户终端发现UP(User Plane，用户面)或者RRC对应的序列号快要到达上限值；(2)用户终端进行了演进基站eNB切换、自切换或系统切换；(3)用户终端或网络侧发现K_ASME长时间没有更新。

步骤s302、网络侧执行密钥更新流程。

该密钥更新包括：通过AKA鉴权过程更新所有密钥；或不需要更新K_ASME，只更新其衍生密钥。

步骤s303、用户终端和网络侧获得更新后的密钥。

步骤s304、获得新密钥后，用户终端和网络侧协商新密钥启动时间。

以下结合不同的应用场景，对本发明的实施方式做进一步说明。

本发明的实施例二中，一种active状态下的密钥更新方法如图4所示，为UE主动发起的active状态下的密钥更新流程，包括以下步骤：

步骤s401、当UE在active状态发现密钥由于某种原因需要更新时，主动向网络侧MME触发密钥更新流程。

该密钥需要进行更新的可能原因包括：(1)UP(或者RRC对应的序列号快要到达上限值；(2)UE刚刚切换到新的eNB；(3)K_ASME过长时间没有更新。UE可以通过向MME发送一个TAU/RAU请求，或者特殊的附着请求，或者特殊的业务请求，或者一个密钥更新请求消息来触发密钥更新流程。

如果采用发送TAU/RAU消息的方式作为密钥更新请求触发密钥更新，即使UE并没有发生位置/路由区更新，也同样发送这个TAU/RAU请求，只不过TAU/RAU请求中的旧路由区标识和新路由区标识一致。为了对密钥的更新请求进行标识，可以将该TAU/RAU请求中Update type(更新类型)的值设置一个特殊值，代表密钥需要更新。这个特殊值可以只统一使用一个特殊值而不区分哪种原因，也可细分为对于不同原因(RRC/UP counter值溢出，或者发生切换，或者K_ASME过期)使用不同的值；或者UE不做任何指示，采用已有的几种取值(比如代表路由/位置区更换的取值)。另外由于周期性位置注册并不需要更新密钥，因此应该与其相区分。为了与周期性位置/路由注册区分，Update type最好不要采用代表”Periodic updating(周期更新)”的取值，如000。

注：现有UMTS中Update type的几种取值如表1所示：

表1：

步骤s402、MME收到触发密钥更新的请求(可以是步骤401所述的几种请求之一)以后，根据请求类型执行相关密钥更新。

如果K_ASME需要更新，例如从GSM/UMTS到SAE/LTE跨系统切换，或者K_ASME过期，便发起AKA鉴权过程；

如果K_ASME不需要更新，只需要更新其衍生密钥，如发生LTE系统内切换，或者由于RRC/UP的counter值溢出，需要更新密钥，那么就基于K_ASME计算新的衍生密钥。可以只更新K_eNB，也可以连同K_NAS-int，K_NAS-enc一起更新。

步骤s403、如果步骤s402中，判断需要执行K_ASME更新，那么就执行AKA过程更新密钥。此步骤可选。

步骤s404、根据步骤s402决定，更新各个密钥。如果只需更新K_ASME的各衍生密钥，那么就利用已有的K_ASME密钥计算相应的密钥。

步骤s405、MME将新密钥发给eNB。

步骤s406、eNB和UE协商新密钥启动时间。

eNB通知新密钥启用时间的方法可以为以下几种之中的一种，也可以是这几种方法以外的某种：

(1)eNB将新密钥启用时间通过一个简化的安全模式命令通知给UE，UE确认收到的安全模式命令。UE与网络侧根据新密钥启用时间来启用新密钥。如果NAS密钥需要更新，在步骤s405，可能还需要发起NAS安全模式命令，以协商新NAS密钥启动时间。

(2)eNB发起一个自切换命令，要求UE切换到eNB自己身上，以便使得UE能够使用上自己的密钥。具体实现属于现有技术。

(3)eNB在每个数据包前面加上KSI，以指示UE采用哪个解密。

除了以上方法外，还可以参见下面实施例七或实施例八的描述。

步骤s407、网络侧向用户发送响应消息，以结束所有流程。

需要指出的是新NAS密钥启动时间还可以在此响应中携带。

本发明的实施例三中，一种active状态下的密钥更新方法如图5所示，为网络侧eNB主动发起的active状态下的密钥更新流程。

本实施例是eNB发起的密钥更新过程。当UP或者RRC加密/完整性保护的序列号将要到达最大值(about to wrap around)，为了防止密钥流重复，可能需要更新相应的密钥；或者即使序列号没有达到最大值，UE处于LTE_ACTIVE状态的时间很长，有可能需要更新用户面保护密钥Kup-enc或者KeNB。这两种情况下不需要更新K_ASME和K_MME，仅需要更新K_up、K_RRC密钥。当然也可以同时更新K_ASME。

实施例三中密钥更新流程描述如下：

步骤s501、当eNB根据上述安全需求发现密钥需要更新时，向MME发送密钥更新请求消息，申请MME产生新的K_eNB；MME将从K_ASME中导出新的K_eNB；

该密钥更新请求消息可能为：(1)一种专门为eNB请求MME更新密钥的请求消息，该请求消息需要MME的响应。(2)一种通知类型消息。通知MME需要更新密钥，该通知消息不需要MME的响应。

步骤s502、MME根据情况对密钥K_eNB进行更新。其中K_eNB可以是MME通过已有的K_ASME衍生得到，也可能是MME通过AKA流程更新完K_ASME之后再计算出的。

步骤s503、MME将新的K_eNB发送给eNB。MME可以通过以下几种方式将密钥发给eNB。

(1)一种对应于步骤s501中，与eNB发送的密钥更新请求对应的密钥更新响应消息。

(2)一种MME主动发起的上下文修改消息，在修改消息里把新密钥发给eNB。

(3)一种MME主动发起的安全上下文修改消息，在修改消息里把新密钥发给eNB。

值得指出的是，除了新K_eNB，MME可能还需要将计算K_eNB所需其它参数通过以上方式发给eNB。例如当MME利用已有的K_ASME计算新密钥时，可能需要引入一个可变参数(如一个计数器，一个随机数)，那么这个可变参数可能也需要发给eNB，通过eNB发给UE，以保证UE可以采用相同参数计算这个新的K_eNB。

eNB将根据这个新的K_eNB衍生出新的K_UP和K_RRC。这个衍生过程可能需要使用到C-RNTI或一个随机数作为输入参数；如果使用C-RNTI，那么既可能使用原来的C-RNTI，也可能为该UE新产生一个C-RNTI参数。

步骤s504、空口新密钥启动过程，即如何协商新密钥更换时间的方法，除了现有方案中利用PDCP(Packet Data Convergence Protocol，分组数据会聚协议)SN、数据里携带KSI或者强制UE进行IDLE状态转换的方式，还可以参见下面实施例七或实施例八的描述。

如果步骤s503中MME采用方式(2)发送K_eNB，那么eNB可能需要在新密钥启动后，向MME响应一个(安全)上下文修改响应消息。

本发明的实施例四中，一种active状态下的密钥更新方法如图5所示，为网络侧eNB主动发起的active状态下的密钥更新流程。

本实施例是eNB发起的密钥更新过程。当UP或者RRC加密/完整性保护的序列号将要到达最大值(about to wrap around)，为了防止密钥流重复，可能需要更新相应的密钥；或者即使序列号没有达到最大值，UE处于LTE_ACTIVE状态的时间很长，有可能需要更新用户面保护密钥K_UP-enc或者K_eNB。这两种情况下不需要更新K_ASME和K_MME，仅需要更新K_up、K_RRC密钥。

与实施例三不同的是：在实施例三中K_eNB是更新的，而在本实施例中K_eNB不更新。实施例四中密钥更新流程描述如下：

(1)当eNB发现密钥需要更新时(eNB根据上述安全需求发现密钥需要更新)，便生成一个随机数或者新的C-RNTI，再利用K_eNB以及其他参数生成新的RRC/UP密钥。

(2)eNB通过空口密钥更新过程将新密钥参数通知UE。所采用的空口密钥更新过程参见以下实施例的描述。

本发明的实施例五中，一种active状态下的密钥更新方法如图6所示，为网络侧eNB主动发起的active状态下的密钥更新流程，包括以下步骤：

步骤s601、在非切换情况下，如果网络侧如eNB想更新密钥。那么就向UE发送一个自切换命令，即要求UE切换到源小区(目标小区与源小区相同)。

步骤s602、UE收到切换命令以后，重新接入eNB。

以下流程中步骤s603～步骤s609的描述请参考实施例二中的步骤s401～步骤s407，在此不进行重复介绍。

本发明的实施例六中，一种active状态下的密钥更新方法如图7所示，为网络侧MME主动发起密钥更新的流程，包括以下步骤：

步骤s701、网络侧MME发现K_ASME使用时间过长，便决定主动发起一个AKA过程。网络侧需要为每个K_ASME设一个有效时间，当有效时间到达最大值时，立即触发相应的流程

步骤s702、MME主动向UE发起一个特殊的paging消息，此步骤可选。

这个特殊的寻呼请求的Paging cause可以是NULL，或者是一个特殊的值表示执行密钥更新。

步骤s703、UE收到paging消息后，向网络发送paging响应。

步骤702和703为可选步骤。

步骤s704、当MME直接向UE发送鉴权请求消息以发起执行AKA，或者在收到paging响应以后，便会按照现有技术中收到paging消息一样，决定执行AKA，并向UE发起AKA流程。

步骤s705、MME计算出各个衍生密钥。

步骤s706、MME将K_eNB发给eNB，发送的具体方式可以为携带在NAS消息中，并指示UE新的NAS密钥启用时间，该步骤为可选。

MME可采用以下几种方式之一将密钥发给eNB：

(1)采用一个主动向eNB发送的上下文修改消息携带。这个上下文修改消息可以采用一种特殊的S1初始上下文建立消息，也可以是新定义的S1接口信令。

(2)采用一个主动向eNB发送的安全上下文修改消息携带。

当然也不排除有其它的类似消息发送。

步骤s707、eNB和UE协商新密钥启动时间。可选的需要将NAS密钥启动时间也可以在此过程协商。

步骤s708、用户与网络侧采用新密钥通信。

对于新生成的密钥，eNB需要通过空口密钥更新过程将新密钥通知UE。在密钥更新过程中空口密钥更新过程的主要目的是：(1)、将衍生密钥相关的参数发送给UE，比如新的C-RNTI或者随机数；(2)、告诉UE密钥的启动时间。

本发明的实施例七中，以SMC(Safe Mode Control，安全模式控制)过程为例，描述了eNB通过空口密钥更新过程将新密钥通知UE的流程，如图8所示，包括以下步骤：

步骤s801，eNB根据触发条件确定需要发送特殊SMC消息给UE。

该SMC消息中参数包含以下参数中的一种或多种：(1)密钥衍生需要的参数，如C-RNTI、随机数等；(2)NAS密钥的下行启动时间；(3)RRC密钥的下行启动时间；(4)用户面密钥的上下行启动时间；(5)其他的可能的参数，如确定上行数据包(包括用户面、控制面数据包)的新密钥启动时间。

另外eNB在发送下行消息时可能：(1)停止下行数据的发送，这样下行启动时间就可以从下一个数据包开始；(2)继续发送，但是为了避免发送包过快而导致的密钥启动错误，启动的PDCP SN可以向后设置一些；

当然除了SMC消息外，也可以是新定义一种安全上下文修改命令/安全重配置命令等新的命令，要求UE按照命令携带的参数，以及时间更换所使用的密钥。

步骤s802、UE收到相关消息后，给eNB返回相应的消息。

具体的，UE收到该SMC消息后，根据相关参数衍生出新密钥；可选的还可能需要确定上行数据包(包括用户面、控制面数据包)的启动时间；然后给eNB返回相应的消息。消息中带上新密钥启动的各个PDCP SN。UE可以不停止数据包的发送，而是在后台计算出新的密钥和新的密钥启动时间，然后将新的启动时间发送给eNB，如果采用这种方法，那么就需要将上行数据包的密钥启动时间设置得靠后一点。

步骤s803、空口在新的密钥保护下通讯。

本发明的实施例八中，以使用自切换过程为例，描述了eNB通过空口密钥更新过程将新密钥通知UE的流程。如图9所示，包括以下步骤：

步骤s901、eNB根据触发条件确定需要发送HO Command消息给UE。

在通常情况下，由于HO Command消息发送给UE是告诉UE切换到另一个Cell，所以在HO Command消息中会带上另一个Cell分配的空中资源和C-RNTI等；但是在实施例中HO Command消息并不是指示UE切换到其他的Cell，仅仅是告诉UE启动密钥更新，所以参数需要做一些变换：(1)原HOCommand消息中的transparent container for Target eNB to UE要去掉；(2)原消息中由target eNB分配给UE的C-RNTI需要修改成由Source eNB自己来分配新的C-RNTI；(3)增加可能需要的NAS密钥启动时间；(4)增加RRC密钥的下行启动时间；(5)增加用户面密钥的下行启动时间；(6)增加原因值，告诉UE本HO Command消息是指示UE做密钥更新的，不是做切换的。

此外，按照HO Command的一般要求，eNB在发送了HO Command消息后将不再下发任何数据包。

步骤s902、UE收到HO Command消息后：(1)根据原因值判断本次切换仅仅是为了更新密钥；所以不需要向新小区同步；(2)停止上行数据包的发送；(3)衍生出新的密钥；(4)确定上行数据包的启动时间；(5)向eNB发送消息，告知上行数据包的启动时间。

步骤s903、UE和eNB之间在新密钥保护下进行通讯。

通过使用本发明的实施例提供的方法，实现了不同情况下，处于active状态的用户终端和网络侧主动发起密钥更新流程，解决了处于active状态的会话中的密钥更新问题。另外，实现过程简单，易于实现。

本发明的实施例九还公开了一种active状态下的密钥更新系统，如图10所示，包括至少一个用户终端10和网络侧实体20，该处于active状态下的用户终端和网络侧实体在满足预设条件时，发起密钥更新并更新密钥。

具体的，用户终端10进一步包括：

终端密钥更新检测单元11，用于根据预设条件判断是否需要发起密钥更新。

终端密钥更新发起单元12，用于在终端密钥更新检测单元11判断为需要进行密钥更新时，向网络侧实体20发送密钥更新请求消息。

终端密钥更新设置单元13，用于预先设置发起密钥更新的条件并提供给终端密钥更新检测单元11。

具体的，网络侧实体20具体包括：

密钥更新检测单元21，用于根据预设条件判断是否需要发起密钥更新。

密钥更新发起单元22，用于在密钥更新检测单元21判断为需要进行密钥更新时，向用户终端10发送请求消息，用于指示密钥更新。

密钥更新单元23，用于在用户终端10或网络侧实体20发起密钥更新时，进行密钥的更新。

密钥更新设置单元24，用于预先设置发起密钥更新的条件并提供给密钥更新检测单元21。

密钥启动协商单元25，用于与所述用户终端协商所述新密钥的启动时间。

其中，上述单元的功能可以通过网络侧的MME以及eNB实现。

通过使用本发明的实施例提供的系统和设备，实现了不同情况下，处于active状态的用户终端和网络侧主动发起密钥更新流程，解决了处于active状态的会话中的密钥更新问题。另外，实现过程简单，易于实现。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台网络设备或用户终端执行本发明各个实施例所述的方法。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。