CN101237444A - 密钥处理方法、系统和设备 - Google Patents

Abstract

本发明公开了一种密钥处理方法，包括以下步骤：网络侧移动管理实体接收用户终端发送的消息；移动管理实体判断是否更新用户终端的密钥中的一组或多组；判断结果为需要更新时，移动管理实体和用户终端获取更新后的密钥。本发明还提供了一种密钥处理系统和设备。通过使用本发明，将用户终端和网络侧不同设备间的通信利用相同或不同的密钥进行了保护，并实现了不同密钥的独立更新。

Description

密钥处理方法、系统和设备

技术领域

本发明涉及网络技术领域，尤其涉及一种演进网络中密钥的处理方法、系统和设备。

背景技术

在UMTS(Universal Mobile Telecommunications System，通用移动通信系统)系统中，为了保证网络用户的安全，用户的数据和信令需要进行安全保护，安全保护包括完整性保护和机密性保护两方面。UMTS中的完整性保护操作和机密性保护操作在UE(User Equipment，用户设备)和RNC(RadioNetwork Controller，无线网络控制器)中进行，即UE和RNC对用户数据进行加/解密操作，并对信令进行完整性保护或检验信令的完整性。

用户的信令分为两层，一层是UE直接和核心网交互的NAS(Non AccessStratum，非接入层)信令，另外一层是UE和RNC交互的AS(Access Stratum，接入层)信令。其中NAS信令需要进行机密性保护和完整性保护，AS信令中的RRC(Radio Resource Control，无线资源控制)信令需要进行完整性保护，也可视需要进行机密性保护。而对于用户的数据，其和信令的保护需求不同。信令有强烈的防篡改需求，因此需要完整性保护；而用户数据最需要的保护是防窃听，因此需要进行机密性保护，当然也可视需要进行完整性保护。

在UMTS中，用户的数据在RNC上进行机密性保护，同时由于安全保护在UE和RNC上进行，因此UE仅仅需要和RNC维护一个安全关联用于对UE和RNC间的通信进行安全保护。加密密钥和完整性保护密钥是安全关联中的一个参数，UMTS中的密钥识别机制和更新机制描述如下：

密钥识别机制：为了提供安全保护，UE和RNC需要共享一个加密密钥CK和完整性保护密钥IK。CK和IK通过一个密钥标识符KSI来标识。此密钥标识符在认证过程中由网络侧生成，并发送给UE。UE在发送接入请求时，将密钥标识符发送至网络，网络根据该密钥标识符找到对应的密钥。

密钥更新机制：CK和IK只能通过重新认证的方式来更新。

目前，3GPP(3rd Generation Partnership Project，第三代移动通信标准化伙伴项目)正在进行网络演进的讨论。在演进的网络中，安全操作的执行点和UMTS系统相比有了很大的不同。图1是演进网络LTE(Long TermEvolution，长期演进)/SAE(System Architecture Evolution，系统构架演进)网络的架构示意图。其中MME(Mobility Management Entity，移动管理实体)负责控制面的移动性管理，包括用户上下文和移动状态管理，分配用户临时身份标识、安全功能等；UPE(User Plane Entity，用户面实体)负责空闲状态下为下行数据发起寻呼，管理保存IP承载参数和网络内路由信息等。

在演进网络中，用户面的安全保护被移动到核心网中的UPE上进行，NAS信令的安全保护被放在MME上进行，AS信令、主要是RRC信令的安全被放在演进RAN(Radio Access Network，无线接入网)中的一个类似基站的eNodeB(evolution Node B，演进的节点B)节点上进行。

在LTE/SAE网络中，UE需要同时和eNodeB、MME、UPE等多个实体分别维护安全关联，即UE需要同时保存几套不同的CK/IK，因此现有UMTS系统中的密钥更新机制无法用于演进网络。另外，由于几套密钥使用的频率不同，生命期也不相同，因此需要设计分别更新这几套密钥的安全机制。

发明内容

本发明的实施例提供一种密钥的处理方法、系统和设备，以完善演进网络中不同密钥的更新以及安全机制。

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

网络侧移动管理实体接收用户终端发送的消息；

所述移动管理实体判断是否更新所述用户终端的密钥中的一组或多组；

所述判断结果为需要更新时，所述移动管理实体和所述用户终端获取更新后的密钥。

本发明的另一实施例还提供一种密钥的处理系统，包括用户终端和移动管理实体，

所述用户终端，向所述移动管理实体发送密钥更新请求，并获取更新后的密钥；

所述移动管理实体，更新所述用户终端的密钥中的一组或多组。

本发明的另一实施例还提供一种移动管理实体，包括判断单元和密钥推演单元；

所述判断单元，判断是否需要更新用户终端密钥中的一组或多组；

所述密钥推演单元，在所述判断单元判断需要更新用户终端密钥中的一组或多组时，获取所述用户终端更新后的密钥。

本发明的再一实施例还提供一种用户终端，包括终端密钥推演单元，获取密钥中新的一组或多组密钥。

本发明的实施例提供了一种演进网络中密钥的处理方法、系统和设备，实现了用户终端和网络侧设备间不同密钥的独立更新与识别，使得通信可以利用相同或不同的密钥进行保护。

附图说明

图1是现有技术中演进网络LTE/SAE的网络架构示意图；

图2是本发明第一实施例的密钥处理方法流程示意图；

图3是本发明第二实施例的UE初始接入网络时密钥的处理方法流程图；

图4是本发明第三实施例的UE通过网络侧更新密钥Kup的流程图；

图5是本发明第四实施例的UE初始接入网络时密钥的处理方法流程图；

图6是本发明第五实施例的UE通过网络侧更新密钥Kup的流程图；

图7是本发明第六实施例的UE通过网络侧更新密钥Kas的流程图；

图8是本发明第七实施例的UE利用KSI识别密钥的流程图；

图9是本发明第八实施例的UE通过网络侧更新密钥Kup的流程图；

图10是本发明第九实施例的UE通过网络侧更新全部密钥的流程图；

图11是本发明密钥处理系统的实施例的结构示意图。

具体实施方式

下面结合具体实施例和附图，对本发明在不同情况下的实施方式做进一步的说明。

在LTE/SAE网络中，用户面的保护在UPE上进行，NAS信令的保护在MME上进行，AS信令的保护在eNodeB上进行。因此本发明中使用多组不同的CK/IK对这些信令和数据进行安全保护，并可对多组密钥分别或同时进行更新。以下将保护用户面的密钥称为Kup，保护NAS信令的密钥称为Knas，保护AS信令的密钥称为Kas。这些密钥可能仅仅包括加密密钥CK，也可能仅仅包括完整性保护密钥IK，也可能既包括加密密钥CK，也包括完整性保护密钥IK。举例来说，Kup可能代表着一个密钥CKup，也可能代表两个密钥CKup和IKup。Kup和Knas可能是相同的密钥，Knas和K也可能相同，此处K为UE和MME通过认证过程后双方共享的密钥。另外，如果用户面加密在eNodeB上进行，那么Kup可以和Kas相同，也可以和Kas不同。如果密钥相同，那么密钥标识符也可以相同。

本发明的第一实施例中，一种密钥处理的方法如图2所示，包括如下步骤：

步骤s201、网络侧移动管理实体MME接收用户终端发送的消息。

步骤s202、MME判断是否需要重新认证所有密钥，或只更新密钥中的一组或多组，需要重新认证时进行步骤s203，需要更新某一或全部密钥时进行步骤s204，不要认证或更新时则进行步骤s205。在实际应用中，认证也可以被理解为是对全部密钥从无到有的一种更新。

此步骤中，UE可以通过在消息中携带更新一组或多组密钥的请求，MME在接收到该请求后，更新用户终端请求更新的密钥。另外，MME在接收到UE的请求时，也可以主动根据网络情况判断是否执行密钥认证过程或密钥更新过程。例如，即使UE不请求更新任何密钥，但MME上的设置为每次UE接入时都需要执行重新认证过程，那么这种情况下MME仍然会发起重新认证，更新用户终端的全部密钥。再例如，UE接入时从网络的MME1移动到另一个MME2，若UE不请求更新任何密钥，但在MME2无法和MME1建立连接时，MME2只能发起认证过程。再例如，UE发送更新NAS密钥的请求，但MME设置为只要更新NAS密钥就更新所有密钥，那么MME不会只更新NAS密钥，而是更新所有密钥。

步骤s203、MME和用户终端推演得到新的密钥，用户终端保存密钥标识符，进行步骤s205。

步骤s204、MME和用户终端推演得到更新后的密钥，用户终端保存密钥标识符，进行步骤s205。

步骤s205、网络侧和用户终端利用密钥标识符对应的密钥保护用户设备和网络侧间的通信。

以下对本发明在不同情况下的应用方式通过具体的实施例进行说明。

本发明的第二实施例为UE初始接入网络时密钥的处理方法，在这种情况下，由于UE为第一次接入网络，因此UE上并没有有效的Kas、Knas和Kup，UE和网络侧的MME也没有预共享密钥K。该种情况下本发明的密钥的处理信令流程如图3所示，包括如下步骤：

步骤s301、UE向网络侧发起初始接入请求，不携带KSIas、Knas和Kup，或者携带三个预设的特殊KSIas、KSInas和KSIup，如111等。

步骤s302、网络侧发起认证过程，HSS(Home Subscriber Server，归属客户服务器)存储有用户相关信息的中心数据库，在认证过程中用于生成认证向量并发送认证向量给MME。认证过程中，UE和MME共享密钥K，同时K的标识符KSIK被发送给UE。共享密钥K生成过程和现有技术中的流程一致，简述为，K被包含在认证向量中从HSS发送到MME，推演K所需的参数也被包含在认证向量中发送给MME。MME将此参数发送给UE，UE利用此参数计算得到K。

步骤s303、MME生成随机数RANDas，RANDnas，RANDup，并根据密钥K推演得到密钥Kas、Knas和Kup。其中，Kas＝KDF(RANDas，K，其他参数)；Knas＝KDF(RANDnas，K，其他参数)；Kup＝KDF(RANDup，K，其他参数)。KDF为密钥推导函数，是一个密码学的单向函数，如SHA-1，SHA-256等。同时MME生成相应的密钥标识符KSIas，KSIup，KSInas。

步骤s304、MME发送KSIas、KSIup、KSInas、RANDas、RANDnas、RANDup给UE。此条消息利用Knas或利用密钥K进行完整性保护。

步骤s305、UE验证消息的完整性，验证完整性的原理为：发送方利用密钥对整条消息计算一个验证码，接收方利用同样的密钥也计算出一个验证码，通过比较两个验证码是否一致来验证消息的完整性。在步骤s304中利用Knas进行完整性保护时，UE需要先推演得到Knas，然后再验证整条消息的完整性。UE根据RANDas、RANDnas、RANDup推演得到新的密钥Kas、Knas和Kup，其推演方法和MME上的推演方法相同。推演后UE保存KSIas、KSInas和KSIup，同时保存RANDas、RANDnas和RANDup。当下次再接收到相同的RANDas、RANDnas或RANDup的密钥更新指示时，不再根据RANDas、RANDnas或RANDup更新密钥。

步骤s306、UE发送确认指示消息给MME。该消息利用密钥K或利用Knas进行完整性保护。该步骤结束后，UE和MME共享了密钥Kas、Knas和Kup。

步骤s307、MME将对应的密钥发送给相应的执行安全操作的实体。即将Kas发送给eNodeB、将Kup发送给UPE(图中未画出)。之后UE和网络侧各实体使用Kas、Knas和Kup对通信进行保护。

在上述步骤的步骤s303中，MME也可以只根据一个随机数推演得到密钥Kas、Knas和Kup，如Kas＝KDF(RAND，K，其他参数)，Kup＝KDF(RAND，K，其他参数)，Knas＝KDF(RAND，K，其他参数)。这时只需对后续步骤进行相应修改即可，仍属于本实施例的范围。

本发明的第三实施例为UE更新密钥Kup的过程，在这种情况下，UE不是第一次接入网络，UE和网络侧的MME已经预共享了密钥K，但是UE上的Kup无效。该种情况下密钥的处理信令流程如图4所示，包括如下步骤：

步骤s401、UE向网络侧发起接入请求，指示网络侧更新Kup。UE可以通过在接入请求中携带预设的特殊的KSIup如111、或者通过不携带KSIup来向网络侧发出指示；另外，在不同的密钥使用相同的密钥标识符时，UE也可以通过在接入请求携带的密钥标识符前设置一个特殊指示字段用以标识需要更新的密钥，或通过将该密钥标识符设置为特定值而要求网络侧更新全部密钥。接入请求中可能需要携带共享密钥K的标识符KSIk，同时UE将一个nonce(临时随机数)携带在接入请求中发给网络。

步骤s402、MME执行用户面密钥更新过程。如果需要执行，则MME找到与UE共享的密钥K。当然MME也可以决定执行认证过程来更新全部密钥，具体的更新流程如第二实施例所述。需要说明的时，更新全部密钥时，MME可以使用已经存在的共享密钥K来推演全部密钥，也可以重新执行共享密钥K的生成过程，从而在认证过程中使用新的共享密钥K来推演全部密钥。

步骤s403、MME生成随机数RANDup，并根据RANDup和密钥K生成密钥Kup。Kup＝KDF(RANDup，K，其他参数)。这里KDF为密钥推导函数，是一个密码学的单向函数，如SHA-1，SHA-256等。同时MME生成相应的密钥标识符KSIup。

步骤s404、MME发送RANDup和KSIup给UE。此条消息可以利用Knas或K提供完整性保护，另外此条消息中还包括MME在步骤s401中接收到的nonce。

步骤s405、UE验证接收到的消息的完整性，同时需要验证nonce是否和在步骤s401中向网络侧上报的nonce一致。验证成功后，根据K推演得到新的Kup，并保存KSIup。

步骤s406、UE发送确认指示给网络，指示密钥更新成功。这条消息利用密钥K或者利用Knas进行完整性保护。该步骤结束后，UE和MME共享了新的密钥Kup。

步骤s407、MME将Kas，Knas和Kup发送给对应的实体，即将Kup发送给UPE、将Kas发送给eNodeB(图中未画出)。UE和网络使用Kas，Knas和Kup对通信进行安全保护。

在步骤s404中，如果新的Kup和旧的Kup相同时，但KSI不发生变化，那么MME不需要将KSIup发送UE。

另外，上述步骤s401至步骤s407中，涉及到UE在发送请求时携带随机数nonce，并在从网络侧接收到相同的nonce值时才进行密钥更新的过程。该过程是出于抗重放保护的考虑。抗重放保护的必要性在于：网络中的攻击者可能向用户终端发送之前使用过的变化值、即重放变化值，使得UE错误的将密钥更新为曾经使用过的旧密钥，从而使得攻击者能够继续攻击。例如，如果攻击者知道旧的Kas，那么攻击者可以通过重放消息使得UE错误的将当前使用的Kas更新为旧的Kas，这样，攻击者可以使得UE驻留在假冒的基站上，从而进行下一步的攻击。另外，UE在接收到以前曾经接收过的随机数时，不根据该随机数进行密钥更新，也是基于抗重放的考虑，是抗重放保护的另一种形式。

在上述两个实施例中，MME在与用户终端完成密钥的认证或更新后，才将新的密钥向对应的实体发送。在具体应用中，还可以在密钥的认证或更新过程中完成新密钥的向对应实体的发送，下面结合第四实施例和第五实施例进行具体描述。

本发明的第四实施例为另一UE初始接入的过程，在这种情况下，UE是第一次接入网络。UE上并没有有效的Kas、Knas和Kup。UE和网络侧的实体MME也没有预共享密钥K。该种情况下密钥的处理信令流程如图5所示，包括如下步骤：

步骤s501、UE向网络侧发起初始接入请求，不携带KSIas、Knas和Kup，或者携带预设的特殊KSIas、KSInas和KSIup，如111等。

步骤s502、网络侧发起认证过程。认证过程中，UE和MME共享密钥K，并由MME将K的标识符KSIk发送给UE。

步骤s503、MME生成随机数RANDas、RANDnas、RANDup并根据密钥K推演得到密钥Kas、Knas和Kup。其中Kas＝KDF(RANDas，K，其他参数)；Knas＝KDF(RANDnas，K，其他参数)；Kup＝KDF(RANDup，K，其他参数)。这里KDF为密钥推导函数，是一个密码学的单向函数，如SHA-1，SHA-256等。同时MME生成相应的密钥标识符KSIas，KSIup，KSInas。

步骤s504、MME和UPE交互，将Kup发送给UPE。

步骤s505、MME对UE的接入请求进行响应并通过eNodeB进行转发，其中响应的NAS部分中包括KSIas，KSIup，KSInas，RANDas，RANDnas，RANDup。这部分利用Knas或利用密钥K进行完整性保护。另外在通过RANAP(RadioAccess Network Application Protocol，无线接入网络应用协议)协议发送给eNodeB的部分中还包含密钥Kas。

步骤s506、eNodeB保存密钥Kas。

步骤s507、eNodeB将步骤s505中接收到的NAS部分发送给UE，其中包括KSIas，KSIup，KSInas，RANDas，RANDnas，RANDup。

步骤s508、UE验证NAS部分完整性。验证成功后，UE根据RANDas，RANDnas，RANDup推演得到新的密钥Kas，Knas和Kup，推演方法和MME上的推演方法相同。UE保存KSIas，KSInas和KSIup，同时保存RANDas，RANDnas和RANDup。当下次再接收到RANDas，RANDnas或RANDup的密钥更新指示时，不根据RANDas、RANDnas或RANDup更新密钥。

步骤s509、UE发送确认指示给MME。这条消息中的AS部分利用密钥Kas进行完整性保护，NAS部分利用Knas进行完整性保护。

步骤s510、MME和UPE交互，指示UPE可以利用Kup对通信进行保护。当然也可以在这一步中才将密钥Kup发送给UPE。这样，则不需要在步骤s504中将密钥Kup发送给UPE。

在上述步骤的步骤s503中，MME也可以只根据一个随机数推演得到密钥Kas、Knas和Kup，如Kas＝KDF(RAND，K，其他参数)，Kup＝KDF(RAND，K，其他参数)，Knas＝KDF(RAND，K，其他参数)。这时只需对后续步骤进行相应修改即可，仍属于本实施例的范围。

本发明的第五实施例为另一UE更新密钥Kup的过程，在这种情况下，UE不是第一次接入网络，UE和网络侧的实体MME有预共享密钥K，但UE上Kup无效。该种情况下密钥的处理信令流程如图6所示，包括如下步骤：

步骤s601、UE向网络侧发起接入请求，指示网络侧更新Kup。UE可以通过在接入请求中携带预设的特殊KSIup如111、或者通过不携带KSIup来向网络侧发出指示。接入请求中可能需要携带共享密钥K的标识符KSIk。

步骤s602、MME判断是否执行用户面密钥更新过程。如果需要执行，则MME找到与UE共享的密钥K。

步骤s603、MME生成随机数RANDup。MME根据RANDup和密钥K生成密钥Kup，Kup＝KDF(RANDup，K，其他参数)。其中KDF为密钥推导函数，是一个密码学的单向函数，如SHA-1，SHA-256等。同时MME生成相应的密钥标识符KSIup。

步骤s604、MME在与UPE的交互中发送新的密钥Kup给UPE。

步骤s605、MME在对UE接入请求响应消息的NAS部分中包括RANDup和KSIup，此部分可以利用Knas或K提供完整性保护。另外在通过RANAP协议发送给eNodeB的部分中还包含密钥Kas。

步骤s606、eNodeB保存密钥Kas。

步骤s607、eNodeB将NAS部分发送给UE，其中包括RANDup和KSIup。

步骤s608、UE验证NAS部分的完整性，同时验证RANDup是否曾经接收到过。验证成功后，UE提据K推演得到新的Kup，并保存KSIup。

步骤s609、UE发送确认指示给网络，指示密钥更新成功。该消息利用密钥Knas或者利用K进行完整性保护。

步骤s610、MME和UPE交互，指示UPE可以利用新的密钥Kup对通信进行保护。当然也可以在这一步中才将密钥Kup发送给UPE。这样，则不需要在步骤s604中将密钥Kup发送给UPE。

本发明的第三实施例和第五实施例描述了UE和MME更新密钥Kup的过程，Kas的更新过程也与Kup的更新过程相类似。本发明的第六实施例为UE更新密钥Kas的过程，在这种情况下，UE不是第一次接入网络，UE上Kas无效。UE和网络侧的实体MME有预共享密钥K。该种情况下密钥的处理信令流程如图7所示，包括如下步骤：

步骤s701、UE向网络侧发起接入请求，指示网络更新Kas。可以通过在接入请求中携带预设的特殊KSIas如111、或者通过不携带KSIas来向网络侧发出指示。接入请求中可能需要携带共享密钥K的标识符KSIk。

步骤s702、MME判断是否执行接入层密钥更新过程。如果需要执行，则MME找到与UE共享的密钥K。

步骤s703、MME生成随机数RANDas。MME根据RANDas和密钥K生成密钥Kas，Kas＝KDF(RANDas，K，其他参数)。其中KDF为密钥推导函数是一个密码学的单向函数，如SHA-1，SHA-256等。同时MME生成相应的密钥标识符KSIas。

步骤s704、MME在对UE接入请求的响应消息的NAS部分中包括RANDas和KSIas。此部分可以利用Knas或K提供完整性保护。同时在通过RANAP协议发送给eNodeB的部分中还包含密钥Kas。

步骤s705、eNodeB保存密钥Kas。

步骤s706、eNodeB将NAS部分转发给UE，该部分中包括RANDas和KSIas。

步骤s707、UE验证NAS部分的完整性，同时验证RANDas是否曾经接收到过。验证成功后，UE根据K推演得到新的Kas，并保存KSIas。

步骤s708、UE发送确认指示给网络，指示密钥更新成功。这条消息利用密钥Knas或者利用K进行完整性保护。

如果用户面的加密在eNodeB上进行，那么上述的流程也可以作为更新Kup的流程。将上述流程中的Kas换为Kup，RANDas换为RANDup，KSIas换为KSIup即可。另外需要指出的是，如果用户面的加密在eNodeB上进行，那么用户面的加密密钥Kup和Kas可以相同，也可以不同。

在UE和网络侧的MME认证或更新密钥后，即可使用密钥对通信进行保护。而UE在接入时只需向网络侧提供相应的密钥标识符即可。本发明的第七实施例为UE利用KSI识别密钥的过程，在这种情况下，UE利用KSIas、KSIup、KSIas来识别密钥。该种情况下密钥的处理信令流程如图8所示，包括如下步骤：

步骤s801、UE向网络侧发起接入请求。接入请求中携带KSIas、KSInas和KSIup。接入请求中可能需要携带共享密钥K的标识符KSIk。

步骤s802、MME找到KSI对应的密钥。如果无法找到，那么MME可能发起密钥更新过程，也可能发起认证过程，更新或认证过程的具体描述见上面的实施例。

步骤s803、MME和UPE交互，将Kup发送给UPE。

步骤s804、MME发送对UE接入请求的响应消息，此条消息的NAS部分利用Knas或K提供完整性保护，另外在通过RANAP协议发送给eNodeB的部分中还包含密钥Kas。

步骤s805、eNodeB存储密钥Kas。

步骤s806、eNodeB向UE发送接入请求响应消息，其中利用Kas为响应消息提供完整性保护。

步骤s807、UE验证响应消息的完整性。

步骤s808、UE发送确认指示消息给网络。这条消息利用密钥Knas和Kas进行完整性保保护，或者利用K进行完整性保护。

步骤s809、MME发送指示给UPE，通知UPE可以利用Kup开始保护通信。

在密钥的推演算法上，除了使用随机数外也可以使用其他参数或只使用预共享的密钥K推演密钥。下面分别对这两种情况进行描述。

本发明的第八实施例为UE更新密钥Kup的过程，在本实施例中，推演Kup的算法为Kup＝KDF(UPE身份，K，其他参数)，并没有利用随机数的参数，而是将UPE身份作为变化量参与到Kup的生成中。UPE身份是UPE设备的标识号，是由UPE设备自身决定的，与UE的身份无关。此时UE仅在UPE发生变化的情况下发起更新密钥Kup。该种情况下密钥的处理信令流程如图9所示，包括如下步骤：

步骤s901、UE向网络侧发起接入请求。

步骤s902、MME判断是否需要更换UPE。如果需要更换UPE，则MME找到密钥K，并推演新的Kup＝KDF(UPE身份，K，其他参数)，MME生成新的KSIup。

步骤s903、MME和UPE交互，将新的Kup发送给UPE。

步骤s904、MME将新的KSIup包括在响应消息中发送给eNobeB。如果UE不知道UPE身份的话，那么MME将UPE身份也发送给UE。

步骤s905、eNodeB将响应消息发送给UE，其中包括KSIup和UPE身份。

步骤s906、UE验证响应消息，UE比较接收到的新的KSIup和旧的KSIup，判断新的KSIup是否在可接收的范围内。举例来说，出于抗重放的考虑，UE不接受小于或等于旧的KSIup。那么，新的KSIup只有当大于旧的KSIup时，或新的KSIup位于一个动态窗口内时才是有效的。KSIup验证通过后。UE推演得到密钥Kup。并保存新的KSIup；如果KSIup验证不通过，那么UE可能丢弃此消息；或者发送一个指示给网络。验证响应消息后，UE推演得到密钥Kup，并保存新的KSIup。

步骤s907、UE发送确认指示给MME。

步骤s908、MME发送指示给UPE，通知UPE可以利用Kup开始保护通信。

如果用户面加密在eNodeB上进行，那么只需将本实施例中的UPE换为eNodeB，并进行相应调整即可。

本发明的第九实施例为UE更新密钥Kup、Kas和Knas的过程，在本实施例中，推演算法为Kup/Kup/Knas＝KDF(K)，并没有利用随机数的参数，只根据K进行推演。根据相同的K，每次推演都得到相同的Kup、Kas和Knas，因此可以用同一个密钥标识符来识别不同密钥。该种情况下密钥的处理信令流程如图10所示，包括如下步骤：

步骤s1001、UE发起初始接入请求，接入请求中携带特殊的密钥标识符，或不携带任何密钥标识符。

步骤s1002、网络执行认证过程，认证过程结束后，UE和MME共享密钥K；密钥K的标识符KSIk被发送给UE。

步骤s1003、MME和UE推演得到密钥Kas、Knas和Kup；这里根据相同的K，每次都推演得到相同的密钥Kas、Knas和Kup。

步骤s1004、MME和UPE交互，向UPE发送密钥Kup。

步骤s1005、MME发送响应消息给eNodeB，并可利用Knas对响应消息进行完整性保护。另外通过RANAP协议发送给eNodeB的部分中还包含密钥Kas。

步骤s1006、eNodeB保存密钥Kas。

步骤s1007、eNodeB发送响应消息给UE。

步骤s1008、UE验证消息的完整性，并可在该步骤中再推演密钥Kas、Knas和Kup。

步骤s1009、UE发送确认消息给MME。

步骤s1010、MME指示UPE可以开始利用Kup保护通信。

通过使用上述实施例提供的密钥的处理方法，实现了演进网络中用户终端和网络侧设备间不同密钥的独立更新与识别，使得通信可以利用相同或不同的密钥进行保护。

本发明的实施例还提供了一种密钥处理系统，包括多个用户终端和移动管理实体。该系统的一实施例如图11所示，包括用户终端10和移动管理实体20。其中用户终端10在需要时向移动管理实体MME发送密钥认证或更新请求，并利用密钥保护与各网络设备间的通信。移动管理实体20为用户终端认证或更新密钥中的一组或多组，并指示其他网络设备利用该密钥保护与用户终端间的通信。

其中用户终端10包括终端发送单元11、终端通信保护单元12、终端密钥推演单元13、终端存储单元14和终端接收单元15。其中，终端发送单元11用于和网络侧的设备进行消息交互，在向网络侧发送的接入消息中设置特殊的密钥标识符或不携带密钥标识符，从而接受网络侧的密钥认证或密钥更新。终端通信保护单元12用于根据目前终端保存的有效密钥对与网络设备的通信进行必要的完整性和机密性保护。终端密钥推演单元13用于根据网络侧发送的消息内容推演出需要更新的密钥中的一组或多组，并将密钥和对应的密钥标识符发送给终端通信保护单元12和终端存储单元14。终端存储单元14用于存储密钥、密钥标识符、网络侧UPE设备身份等信息。终端接收单元15用于接收网络侧设备发送的消息，并将推演密钥所需要的参数发送至终端存储单元14和终端密钥推演单元13。

移动管理实体20包括判断单元21、存储单元22、密钥推演单元23、通信保护单元24和发送单元25。其中，判断单元21用于接收各用户终端发送的接入请求，根据该请求以及网络情况判断是否需要对用户终端密钥中的一组或多组进行认证或更新。存储单元22用于存储各个用户终端的密钥和密钥标识符，以及网络侧相关设备如UPE、eNodeB等的地址。密钥推演单元23用于在判断单元21的判断结果为需要对密钥中的一组或多组进行认证或更新时，生成或获取推演密钥所需要的参数，并推演出新的密钥、生成密钥标识符。通信保护单元24用于根据目前自身保存的有效密钥对与其他网络设备和用户终端的通信进行必要的完整性和机密性保护。发送单元25用于向网络中的其他设备以及用户终端的信息交互。

通过使用上述实施例提供的密钥的处理系统，将演进网络中用户终端和网络侧不同设备间的通信利用相同或不同的密钥进行了保护，并实现了不同密钥的独立更新与识别。

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

Claims (22)

1. 一种密钥处理方法，其特征在于，包括以下步骤：

网络侧移动管理实体接收用户终端发送的消息；

所述移动管理实体判断是否更新所述用户终端的密钥中的一组或多组；

所述判断结果为需要更新时，所述移动管理实体和所述用户终端获取更新后的密钥。

2. 如权利要求1所述密钥处理方法，其特征在于，所述移动管理实体根据网络情况、和/或所述消息判断是否更新用户终端密钥中的一组或多组。

3. 如权利要求1或2所述密钥处理方法，其特征在于，所述密钥使用相同的密钥标识符或不同的密钥标识符。

4. 如权利要求3所述密钥处理方法，其特征在于，所述密钥使用不同的密钥标识符时，

所述用户终端通过将所述消息中携带的密钥标识符设置为预设值，要求所述移动管理实体更新与所述密钥标识符对应的密钥；或

所述用户终端通过在所述消息中不携带密钥标识符，要求所述移动管理实体更新与所述未携带的密钥标识符对应的密钥。

5. 如权利要求3所述密钥处理方法，其特征在于，所述密钥使用相同的密钥标识符时，

所述用户终端通过在所述消息中携带指示字段，要求所述移动管理实体更新与所述指示字段对应的密钥；或

所述用户终端通过将所述密钥标识符设为预设值，要求所述移动管理实体更新全部密钥。

6. 如权利要求1所述密钥处理方法，其特征在于，所述消息中携带所述用户终端与所述网络侧间的共享密钥K的标识符KSI。

7. 如权利要求6所述密钥处理方法，其特征在于，所述移动管理实体更新全部密钥前，与所述用户终端设定并交互新的共享密钥K以及共享密钥K的标识符KSI，或保留原有的共享密钥K以及标识符KSI。

8. 如权利要求7所述密钥处理方法，其特征在于，所述移动管理实体和所述用户终端获取更新后的密钥的步骤具体为：

利用共享密钥K，推演得到新的密钥。

9. 如权利要求7所述密钥处理方法，其特征在于，所述移动管理实体获取更新后的密钥的步骤具体为：

所述移动管理实体利用共享密钥K和/或变化参数，推演得到新的密钥。

10. 如权利要求8或9所述密钥处理方法，其特征在于，所述移动管理实体获取更新后的密钥后，将所述新密钥发送给对应的网络侧实体。

11. 如权利要求8或9所述密钥处理方法，其特征在于，所述移动管理实体获取更新后的密钥后，在所述新密钥的密钥标识符发生变化时，将所述新密钥的密钥标识符直接发送给所述用户终端，或通过演进节点B发送给所述用户终端。

12. 如权利要求9所述密钥处理方法，其特征在于，所述移动管理实体推演不同的新的密钥时，利用的变化参数相同或不同。

13. 如权利要求12所述密钥处理方法，其特征在于，所述移动管理实体获取更新后的密钥后，在所述用户终端未获得所述变化参数时，将所述变化参数直接发送给所述用户终端，或通过演进节点B发送给所述用户终端。

14. 如权利要求13所述密钥处理方法，其特征在于，所述移动管理实体在发送所述变化参数和/或密钥标识符时，将所述变化参数和/或密钥标识符进行完整性保护和/或抗重放保护。

15. 如权利要求14所述密钥处理方法，其特征在于，所述抗重放保护具体为：

所述用户终端接收的变化参数与接收过的变化参数相同时，不进行新密钥的推演，否则利用所述变化参数和/或共享密钥K推演新的密钥；或

所述用户终端利用接收到的密钥标识符作为序列号，当接收到的密钥标识符序列号处于一个可接受的范围内时，利用所述变化参数和/或共享密钥K推演新的密钥；或

所述用户设备在发送所述消息时同时发送第一数值；所述移动管理实体向所述用户设备发送所述变化参数时同时发送第二数值；所述用户设备在接收到的所述第二数值与所述消息中的第一数值相同时，利用所述变化参数和/或共享密钥K进行新密钥的推演。

16. 如权利要求1所述密钥处理方法，其特征在于，所述移动管理实体判断结果为不需要更新时，所述移动管理实体根据所述消息找到对应的密钥，并指示网络侧相应实体使用所述密钥保护所述用户终端和网络侧的通信。

17. 如权利要求1所述密钥处理方法，其特征在于，还包括步骤：

所述移动管理实体将所述新的密钥发送至对应的网络侧实体，并指示网络侧实体利用所述密钥保护所述用户终端和网络侧的通信。

18. 一种密钥处理系统，其特征在于，包括用户终端和移动管理实体，

所述用户终端，向所述移动管理实体发送密钥更新请求，并获取更新后的密钥；

所述移动管理实体，更新所述用户终端的密钥中的一组或多组。

19. 如权利要求18所述密钥处理系统，其特征在于，所述移动管理实体包括判断单元和密钥推演单元；

所述判断单元，判断是否需要更新所述用户终端的密钥中的一组或多组；

所述密钥推演单元，在所述判断单元判断需要更新所述用户终端密钥中的一组或多组时，获取所述用户终端更新后的密钥。

20. 如权利要求18所述密钥处理系统，其特征在于，所述用户终端包括终端密钥推演单元，获取密钥中新的一组或多组密钥。

21. 一种移动管理实体，其特征在于，包括判断单元和密钥推演单元；

所述判断单元，判断是否需要更新用户终端密钥中的一组或多组；

所述密钥推演单元，在所述判断单元判断需要更新用户终端密钥中的一组或多组时，获取所述用户终端更新后的密钥。

22. 一种用户终端，其特征在于，包括终端密钥推演单元，获取密钥中新的一组或多组密钥。

Images