CN102804826B - 用于srns重定位的增强密钥管理 - Google Patents

用于srns重定位的增强密钥管理 Download PDF

Info

Publication number
CN102804826B
CN102804826B CN201180014253.9A CN201180014253A CN102804826B CN 102804826 B CN102804826 B CN 102804826B CN 201180014253 A CN201180014253 A CN 201180014253A CN 102804826 B CN102804826 B CN 102804826B
Authority
CN
China
Prior art keywords
key
mobile terminal
rnc
radio network
network controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201180014253.9A
Other languages
English (en)
Other versions
CN102804826A (zh
Inventor
卡尔·诺曼
托马斯·黑德伯格
马茨·内斯隆德
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN102804826A publication Critical patent/CN102804826A/zh
Application granted granted Critical
Publication of CN102804826B publication Critical patent/CN102804826B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/082—Access security using revocation of authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种方法，该方法包括：在通过由至少一个第一密钥保护的连接服务于移动终端的第一节点中，保持所述第一密钥和与所述移动终端的密钥管理能力有关的信息。在将所述移动终端重定位到第二节点时，该方法包括：当且仅当所述密钥管理能力指示所述移动终端所支持的增强的密钥管理能力时，通过所述第一节点来修改所述第一密钥，由此创建第二密钥；将所述第二密钥从所述第一节点发送至所述第二节点；以及向所述第二节点发送与所述移动终端的密钥管理能力有关的信息。

Description

用于SRNS重定位的增强密钥管理
技术领域
本发明涉及一种使得节点能够保持与诸如相应节点的密钥管理能力之类的能力有关的信息(例如，服务于移动终端的节点可以保持与该移动终端的密钥管理能力有关的信息)的方法。本发明还涉及具有该能力的节点。
背景技术
已知诸如无线电通信之类的无线通信由于其相对容易受到损害而需要通过加密进行保护(这里所使用的术语“无线”旨在包括电磁波(而不是某种有线形式)通过部分或整个通信路径承载信号的任意通信。将参照无线电通信描述本发明的示例，无线电通信使用无线电频率电磁波来承载通信，并且是无线通信的一个示例，但是本发明不局限于无线电通信)。为此，通常使用基于为无线网络或在其间发送无线通信的至少始发终端和端接终端所知(或者“共享”)的一个或多个密钥的加密方法来保护无线通信的安全。在一项已知的技术中，使用两个密钥“保密密钥”和“完整性密钥”作为信息/数据机密性和完整性/可靠性的基础。
在许多情况下，在诸如无线电链路之类的无线链路上定义安全性。在移动终端(例如移动电话)与固定基站之间通信的情况下，这意味着移动终端和基站BS(或“接入点”AP)是针对安全性的端接点，因此需要访问用于保护通信安全的密钥。然而，将密钥分发给多个容易访问的节点造成威胁，因为这增大了攻击者获得密钥的机会。
这在WCDMA(宽带码分多址接入，3G移动电信网络中使用的一项标准)中已经不成问题，这是因为安全性在位于相对而言受到更好保护的位置处的无线电网络控制器(RNC)中结束。然而，在LTE(“长期演进”)移动电信标准中，无线电链路保护的末端已经下移到更加暴露的基站(在LTE中称为“eNB”)。此外，新的3G演进/HSPA(高速分组接入)架构使得RNC功能(或其部分，例如保密)移到基站(在WCDMA中称为“NodeB”)。这意味着必须保护基站中存储并使用的密钥。一种方式是改善密钥管理方式。
LTE标准包括一特征：密钥在每一个LTE内切换时改变。因此，如果“KeNB1”表示用于保护图1中的移动终端(也称为移动设备(ME))1与第一基站2(eNB1)之间的无线业务4的密钥，则在ME切换到新基站3(eNB2)之后，新基站3将不使用原始密钥KeNB1来与ME1通信。取而代之的是，在切换之后，新基站3将使用从原始密钥KeNB1推导的新密钥KeNB2，例如KeNB2＝f(KeNB1，eNB2_ID)，其中eNB2_ID是与新基站3相关联的标识符。在下文中，将函数f应用于密钥称为“调整(tweaking)”密钥。函数f是密钥推导函数，通常基于适合的加密函数，例如(假定的)单向函数或伪随机函数。如果不止一个密钥需要调整，这可以通过使用一组函数F来实现，其中，针对F中的fi，应用fi来获得第i个密钥。
密钥KeNB2是第一基站2计算的，并从第一基站2经由通信信道(例如，X2接口)发送至新基站3，该通信信道连接这两个基站。由于ME1知悉函数f，因此ME1也可以通过本地执行相同的计算来推导出新密钥KeNB2(ME仅仅需要KeNB1的知识和eNB2的标识，这二者是可得到的)。因此，在切换之后，使用新密钥KeNB2而不是使用原始密钥KeNB1来保护新基站3与ME之间的无线通信5。
这意味着，即便有人能够从新基站3提取出新密钥KeNB2，在适当选择了函数f的情况下，在无法根据通过提取密钥KeNB2所取得的信息推导出原始密钥KeNB1的意义上，原始密钥KeNB1仍然是“安全的”。因此，入侵者无法记录第一基站2与移动终端1之间的加密业务，在ME已经切换到新基站3(假设受到危害)之后无法获得密钥，并且无法使用密钥来破译至/自第一基站2的业务。
应注意，在LTE中也存在用于在重定位时改变密钥(并且结合ME的特定状态改变)的其他机制。然而，这些机制全都需要另一个网络节点(所谓的移动管理实体(MME))生成新密钥，因此不对此进行进一步的讨论。
应理解，希望在第一基站2计算新密钥KeNB2，这是因为否则的话可能至少暂时在新基站3中也暴露原始密钥KeNB1。
当前的WCDMA网络除非运行认证密钥管理(AKA)过程，否则无法改变密钥，AKA过程强加了信令延迟，并导致AuC/HLR(认证中心/归属位置寄存器)、RNC、MSC(移动交换中心)和其他节点上的负载。
当前在3GPP中有一个工作组研究UTRAN的密钥管理增强(TS33.102，3rdGenerationPartnershipProject；TechnicalSpecificationGroupServicesandSystemAspects；3GSecurity；Securityarchitecture，http://www.3gpp.org/ftp/Specs/archive/33_series/33.102/33102-910.zip)，即，针对基于WCDMA的接入网络。其目的是着眼于针对在切换时改变密钥的问题的方案。然而，到现在为止，几乎没有对解决方案进行任何讨论，并且迄今为止该研究仅仅讨论了如何在将密钥从核心网(VLR/MSC/SGSN)传送到RNC时(即，在初始附着或在路由区域更新(RAU)时)改变密钥。核心网(CN)与无线电接入网(RAN)之间的“垂直”密钥改变的问题比RAN内的“水平”密钥改变的问题简单得多，并且所具有的解决方案很大程度上独立于针对RAN内的“水平”密钥改变的解决方案。已经肯定在SRNS重定位时(即，当ME改变其服务RNC时)也应该可以改变密钥，但具体如何实现仍然是开放的(参见S3-100319，3GPPTR33.ukhV0.3.0(2010-02))。
考虑现有3GPP规范中定义的移动/切换的不同情况，对于任意完整规定的解决方案，需要考虑的三种情况的“水平”密钥推导。这些情况与导致RNC改变的移动性事件一致：SRNS(ServingRadioNetworkSubsystem)relocationwithoutMEinvolvement(参见TS23.060的6.9.2.2.1，3rdGenerationPartnershipProject；TechnicalSpecificationGroupServicesandSystemAspects；GeneralPacketRadioService(GPRS)；Servicedescription；Stage2，http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/23060-930.zip)，combinedhardhandoverandSRNSrelocation(参见TS23.060的6.9.2.2.2)和combinedcell/URAupdateandSRNSrelocation(参见6.9.2.2.3ofTS23.060)。相比较而言，在LTE标准中，存在的唯一情况是与组合的硬切换和SRNS重定位相对应的情况。换言之，无法在UTRAN中以任何直接方式采用现有的LTE解决方案，因为它不覆盖所有情况。此外，在LTE中不存在与传统终端和网络设备的互操作性的问题，因为它从一开始就被设计为支持上述密钥改变机制。下面将讨论在已经部署的、但不具有这种功能的网络中引入这种密钥改变机制的问题。
在执行没有ME参与的SRNS重定位的情况下，网络将服务RNC从源RNC(“源RNC”是当前正在提供服务的RNC)改变到目标RNC(当前正在变化的RNC)，即便ME保持连接到同一个基站(NodeB)。这在图2(a)中示出，图2(a)示出了两个RNC，连接到核心网7的6a(或RNC1)和6b(或RNC2)。每一个基站都由一个RNC控制，例如如图2(a)所示，两个基站8a(NodeB1)和8b(NodeB2)由RNC1控制，以及一个基站8c(NodeB3)由RNC2控制。在SRNC重定位之前，ME1由一个RNC(例如，RNC1)经由基站(NodeB1)服务。在SRNS重定位之后，如图中的虚线所示，ME由另一个RNC(例如，RNC2)经由与SRNS重定位之前相同的基站服务。只有在没有ME参与的SRNS重定位过程结束时，目标RNC(在本示例中，RNC2是目标RNC)才向ME通知服务RNC的改变。因此，在完成之前，ME不知道RNC的改变，并且这使得ME很难确定使用了哪些密钥来保护特定消息(稍后更详细描述)-针对UTRAN所采用的任意解决方案必须克服这个问题。
在利用SRNS重定位的组合的硬切换中，源RNC通知ME它应当改变基站，以及同时通知它要由目标RNC服务。这在图2(b)中示出，图2(b)示出了连接到核心网的两个RNC。在SRNS重定位之前，ME1由一个RNC经由基站服务，例如由RNC1经由基站NodeB1服务。在SRNS重定位之后，如虚线所示，ME由另一个RNC(例如，RNC2)经由与SRNS重定位之前不同的基站(例如，基站NodeB3)服务。
在利用SRNS重定位更新的组合的小区/URA中，ME意识到它已经移进新小区，并向源RNC发送更新消息。这在图2(c)中示出，图2(c)示出了连接到核心网的两个RNC。注意，图2(c)与图2(b)相同，除了信令顺序不同。在重定位之前，ME1由一个RNC经由基站服务，例如由RNC1经由基站NodeB1服务。在重定位之后，如虚线所示，ME1由另一个基站服务，另一个基站可以是由与重定位之前的基站相同的RNC服务的基站(例如NodeB2)或者备选地可以是由与重定位之前的基站不同的RNC服务的基站(例如，由RNC2而不是RCN1服务的NodeB3)。网络判断更新是否是可接受的，并且如果是，则将服务RNC改变为目标RNC(如果需要的话)，然后目标RNC向ME通知RNC的改变。仅在该过程结束时，再一次向ME通知RNC的改变。
在SRNS重定位期间，源和目标RNC经由核心网彼此通信，以协调重定位。在较新版本的UTRAN标准中，还存在称为增强SRNS重定位的过程，其中RNC经由Iur接口(如图2(a)至2(c)示意性示出的)彼此直接通信。
ME和网络侧独立提供密钥调整的现有方案在上面所讨论的过程中有很多问题。例如，如上面所提到的，新的3G演进/HSPA架构允许RNC与NodeB共同定位(可能在相同的硬件机壳中)。这意味着，在网络外围(无线电设备机壳可能位于黑客在物理上攻击以访问保密密钥的不友善环境中)的位置中执行保密和完整性保护。这使得必须调查HSPA中使用的密钥的增强保护。具体地，在SRNS重定位时改变RNS的情况下改变密钥是有益的。然而，与LTE标准不同的是，没有将系统设计为从一开始就考虑在重定位时改变密钥的需要。如果引入了在重定位时改变密钥的特征，则需要提供：
-在与传统设备互相作用时的后向兼容。
-与现有信令的后向兼容，尽可能不改变现有过程。
应注意，WiMAX(IEEE802.16)和WLAN(IEEE802.11)都不包括在BS间/AP间切换时改变密钥(作为切换过程的必要部分)的标准化的方式。相反，在这些无线电接入技术中，在切换时改变密钥的唯一可能性基于在终端(STA)与目标BS/AP之间执行完整的(或在WLAN的情况下优化的802.11r)认证。这在WCDMA中是不可接受的，因为期望零信令开销(从密钥管理的角度，当然会有移动信令发生)。
发明内容
本发明的第一方面提供了一种方法，包括在通过由至少一个第一密钥保护的连接服务于移动终端的第一节点中，保持所述第一密钥和与所述移动终端的密钥管理能力有关的信息。在将所述移动终端重定位到第二节点时，当且仅当所述密钥管理能力指示所述移动终端所支持的增强的密钥管理能力时，所述第一节点修改所述第一密钥，由此创建第二密钥，将所述第二密钥从所述第一节点发送至所述第二节点。向所述第二节点发送与所述移动终端的密钥管理能力有关的信息。
本发明使得节点(在这种情况下为第一节点)可以保持与相应节点(在这种情况下为移动终端)的密钥管理能力有关的信息。例如，节点可以是RNC，例如第一节点可以是被更新的源RNC，第二节点可以是目标RNC(可以被更新或者可以不被更新)。在移动终端重定位到第二节点时，当且仅当与移动终端的密钥管理能力有关的信息指示移动终端支持增强的密钥管理能力时，第一节点修改第一密钥，以创建第二密钥，否则第一节点不修改第一密钥。因此，如果第一节点从保持的信息中获悉移动终端能够调整密钥，则第一节点在重定位时调整密钥是安全的，因为第二节点和移动终端将能够在重定位之后利用所调整的密钥来进行通信。本发明因此确保(1)第一节点和移动终端均修改第一密钥；或者(2)第一节点和移动终端都不修改第一密钥，以使得在重定位之后在网络侧使用的密钥与在重定位之后在移动侧使用的密钥相同。此外，将与是否更新移动终端有关的信息发送至目标RNC，以使得目标RNC意识到移动终端是否被更新(假设目标RNC被更新；如果目标RNC没有被更新，那么将忽略从源RNC接收到的信息)。
在连接由两个或多个密钥保护的情况下，理论上可能只改变(调整)一些密钥，从而不是所有密钥都被改变。然而，实际上，通常期望以最大的安全性来改变密钥(在支持增强的密钥管理能力的情况下)。
此外，向第二节点发送与移动终端的密钥管理能力有关的信息意味着：在第二节点随后将移动终端交付给另一节点时，第二节点将意识到移动终端是否是能够在重定位时调整密钥的更新后的移动终端。第二节点由此知道它是否能够在更新移动终端的后续重定位时(再次假设目标RNC(第二节点)调整密钥；如果目标RNC不被更新，则如先前所提及的，将忽略从源RNC接收的信息)。
该方法还包括：在所述第一节点修改所述第一密钥之前，所述第一节点指示所述移动终端执行到所述第一节点的节点内重定位。
与移动终端的密钥管理能力有关的信息可以由所述移动终端或所述第一节点发送到第二节点。
该信息可以在与重定位的完成有关的一个或多个信令消息中发送。这使得本发明在不需要在重定位时交换任何附加消息就能实现。
第一节点可以在重定位准备阶段，基于所述信息来确定所述移动终端是否支持所述增强的密钥管理能力。重定位通常包括两个阶段：准备阶段和执行阶段。两个阶段都包括在源RNC与目标RNC之间的特定信令。例如，重定位“准备阶段”可以如3GPPTS25.331针对有UE参与的SRNS重定位情况、没有UE参与的SRNS重定位情况、以及组合的小区/URA更新和SRNS重定位情况所定义的。在本实施例中，当源RNC确定该将终端重定位到目标RNC时，源RNC开始准备阶段时，然后可以确定移动终端是否支持增强的密钥处理。此后，源RNC可以选择通过还运行执行阶段来完成重定位。
修改所述第一密钥可以包括：利用所述第一密钥，并且可选地但优选地也利用与所述第二节点有关的信息，来修改所述第一密钥。
该方法可以包括：在将所述移动终端从第三节点重定位至所述第一节点时，从所述第一节点向所述移动终端发送与所述第一节点的密钥管理能力有关的信息。
该特征涉及：在移动终端的较早重定位时，即，重定位到更新的目标RNC(第一节点假设为被更新)，第一节点是“目标”节点。在重定位时，向移动终端发送目标RNC(第一节点)是更新的RNC的信息，以使得移动终端意识到：在重定位之后，它正在由更新的RNC服务(假设，移动终端被更新；如果移动终端不被更新，则将忽略从目标RNC接收到的信息)。
该方法还可以包括：在将所述移动终端从所述第三节点重定位至所述第一节点之后，在所述第一节点处接收来自所述移动终端的与所述移动终端的密钥管理能力有关的信息。例如，如果移动终端被更新，则它将向目标RNC通知。在较早重定位中的目标RNC(即，第一节点)存储它接收到的与移动终端的密钥管理能力有关的任何信息。
可以在与所述移动终端从所述第三节点重定位至所述第一节点的完成有关的一个或多个信令消息中包括并发送所述信息，再次避免在重定位时交换任何附加消息的需要(与现有的系统/信令方案相比)。
由第一节点发送至移动终端的与所述第一节点的密钥管理能力有关的信息可以包括所述第一节点支持增强的密钥管理能力的信息。
本发明的第二方面提供了一种方法，该方法包括：在第一节点通过由至少一个第一密钥保护的连接所服务的移动终端中，保持所述第一密钥和与所述第一节点的密钥管理能力有关的信息。在将所述移动终端从所述第一节点重定位到第二节点时，当且仅当所述密钥管理能力指示所述第一节点所支持的增强的密钥管理能力时，所述移动终端修改所述第一密钥，由此创建第二密钥。例如，第一节点可以是RNC。移动终端(被更新的)意识到正在服务移动终端的RNC是否被更新，并因此将在重定位到目标RNC(第二节点)时调整密钥。
该方法还可以包括：在所述移动终端修改所述第一密钥之前，所述移动终端执行到所述第一节点的节点内重定位(在接收到来自第一节点的指令时进行)。
该方法还可以包括：当移动终端从第一节点切换到第二节点时，移动终端向第二节点发送与移动终端的密钥管理能力有关的信息。
该信息可以包括在与重定位的完成有关的一个或多个信令消息中。
修改所述第一密钥包括：利用所述第一密钥，并且可选地但优选地利用与所述第二节点有关的信息，修改所述第一密钥。
本发明的第三方面提供了一种用于服务移动终端的节点，所述节点包括：用于保持与由所述节点通过由至少一个第一密钥保护的连接所服务的移动终端的密钥管理能力有关的信息以及所述第一密钥的模块。该节点还包括：用于在将所述移动终端重定位到第二节点时，当且仅当所述密钥管理能力指示所述移动终端所支持的增强的密钥管理能力时，修改所述第一密钥，由此创建第二密钥的模块，并且还具有用于将所述第二密钥从所述第一节点发送至所述第二节点的模块。
该节点还可以包括：用于向所述第二节点发送与所述移动终端的密钥管理能力有关的信息的模块。
本发明的第四方面提供了一种移动终端，包括：用于保持与通过由至少一个第一密钥保护的连接服务所述移动终端的第一节点的密钥管理能力有关的信息以及所述第一密钥的模块。该移动终端还可以包括用于在将所述移动终端从所述第一节点重定位到第二节点时，当且仅当所述密钥管理能力指示所述第一节点所支持的增强的密钥管理能力时，通过所述移动终端来修改所述第一密钥，由此创建第二密钥的模块。
该移动终端还可以具有：用于从所述移动终端向所述第二节点发送与所述移动终端的密钥管理能力有关的信息的模块。
在第三方面的节点或第四方面的移动终端中，模块可以采用硬件实现为单独的硬件模块，或组合在一个硬件模块中，或者它们可以实现为在适当变成的处理器上操作的一个或多个软件模块，或者它们可以实现为硬件和软件模块的组合。
附图说明
将参照附图，作为示例描述本发明的优选实施例，在附图中：
图1示意了在至/自移动终端的通信中的“密钥调整”的原理；
图2(a)示意了没有ME参与的SRNS重定位；
图2(b)示意了利用SRNS重定位的硬切换；
图2(c)示意了利用SRNS重定位更新的组合的小区/URA；
图3示意了根据本发明的第一实施例的方法中的消息流；
图4示意了根据第一实施例的方法的主要步骤；
图5示意了根据本发明的第二实施例的方法中的消息流；
图6示意了根据第二实施例的方法的主要步骤；
图7示意了根据本发明的第三实施例的方法中的消息流；
图8示意了根据第三实施例的方法的主要步骤；
图9是示出了根据本发明的实施例的方法的主要步骤的流程框图；
图10是示出了根据本发明的另一实施例的方法的主要步骤的流程框图；
图11是示出了根据本发明的实施例的节点的主要组件的框图；
图12是示出了根据本发明的实施例的移动终端的主要组件的框图。
具体实施方式
为了讨论的简单起见，用“RNC+”表示能够知道应当在SRNS重定位时改变密钥(如果可能的话)的被更新的RNC。类似地，“ME+”表示被更新的ME，这是也意识到可能需要在SRNS重定位时改变密钥的ME。“源RNC”或“源RNC+”是在重定位之前(经由基站)服务ME/ME+的RNC或RNC+，“目标RNC”或“目标RNC+”是在重定位之后服务ME/ME+的RNC或RNC+。
要解决的问题包括：
-重定位之后在网络中(即，在目标RNC(+)中)使用的密钥始终与重定位之后在ME(+)中使用的密钥相同是至关重要的，因为否则的话安全性处理将失败，并且丢失到网络的连接。
-期望在尽可能多的情况下在重定位时改变密钥，即，如果移动终端是ME+，并且至少一个源或目标RNC是RNC+，则期望改变密钥。
-期望在源RNC中使用的密钥在尽可能大的程度上对于目标RNC保密。在实践中，这意味着应当在将密钥传送至目标RNC(可以更新或者可以不更新)之前在源RNC+中执行密钥改变(密钥调整)(可能的话)。
作为ME，源RNC和目标RNC均可以更新或者可以不更新，存在多种情形，例如：
1.如果在从RNC+到RNC+的SRNS重定位中涉及ME+，则期望密钥在ME+和源RNC+二者中都发生改变(假设密钥在源RNC+中改变，并且给目标RNC+传送新密钥)。ME+和RNC+如何(相互)获悉彼此的能力？如果ME+和RNC+均没有被适当地通知另一方的能力，则ME+和RNC+之一可以执行密钥修改，而另一方不执行，从而会导致密钥失配，这意味着例如加密失败并且因此将丢失到网络的连接。
2.如果在RNC与RNC+的任意组合(即，RNC+到RNC或RNC到RNC+)之间的SRNS重定位中涉及ME+，则网络侧必然不改变密钥，这是因为密钥不能在ME侧改变。假设源RNC是RNC+，那么它如何获悉要给目标RNC提供哪些密钥，即它如何获悉ME实际上是否是ME+和/或目标RNC是否能够处理密钥调整？
3.如果ME+执行从RNC到RNC的重定位，那么密钥必然不在ME+中改变，这是因为密钥肯定不会在RNC侧改变(当源RNC和目标RNC均为传统RNC时)。由于ME+不知道RNC是否被更新，那么ME+如何获悉是否要“调整”密钥？
4.如果ME+执行源和目标RNC为不同类型的情况下的重定位(即，RNC+→RNC或RNC→RNC+)，那么是否可以改变密钥？如果可以，则是目标RNC还是源RNC改变密钥？ME+如何获悉密钥是否在网络侧被调整，即，它是否应当调整密钥？
5.如果ME+从一个RNC(已更新或未更新)切换到RNC+，则目标RNC+如何获悉ME是ME+？
如先前所说明的，这些问题不会出现在根据当前LTE标准操作的终端和网络中，因为移动网络和终端将始终能够在重定位时调整密钥-以使得网络和移动终端始终都知道另一实体能够改变密钥。此外，在LTE标准中，如上所述，密钥改变始终与图2(b)所示的硬切换相关联，并且在LTE中不出现图2(a)和2(c)所示的切换。然而，如果将来在LTE中引入增强的密钥管理能力和/或新的重定位机制，本发明也可以应用于其中。
将参照图2(a)至2(c)所述的三种可能的重定位方案来描述本发明的实施例。如上所述，源和目标RNC可以经由核心网彼此通信，以协调重定位，或者在较新版本的UTRAN标准中，RNC可以经由Iur接口彼此直接通信。为了简单起见，以下说明描述在RNC可以彼此直接通信时如何实现本发明，但是本发明可以容易地应用于RNC经由核心网彼此通信的情况。
将参照通过两个或多个密钥(例如，保密密钥和完整性密钥)来保护RNC与ME之间的通信安全的实施例来描述本发明，并且因此本发明将涉及改变或“调整”密钥，但是本发明可以容易地应用于仅通过单个密钥来保护RNC与ME之间的通信安全的情况，这是因为可以应用相同原理。类似地，在使用多个密钥的情况下，可以将“调整”应用于所有密钥，或者仅应用于选择的密钥子集，例如分组交换(PS)域密钥，但不应用于电路交换(CS)域密钥等。
此外，下面描述的本发明将集中于决定(在ME+和源/目标RNC+中，互相地)是否修改(调整)密钥的问题。因此，假设密钥修改函数(上面指出的f)是固定的，因此仅就应用f或是不应用f进行选择。然而，在一般情况下，也存在应用哪种函数f的不同选择。具体地，本发明涉及保持与对一个或多个密钥管理能力的支持(除了对给定f函数的支持/不支持以外，通常还可以包括支持哪些f函数(如果有的话))有关的信息。另外，可以采取类似方式处理较为普遍的安全能力。
此外，本发明不涉及密钥修改函数的具体形式，并且可以使用任意适当的密钥修改函数。作为示例，密钥修改函数可以利用密钥，并且可选地但优选地，也利用与目标节点有关的信息，来修改密钥，例如可以根据KeNB2＝f(KeNB1，eNB2_ID)来修改密钥，但这仅仅是一个可能的示例，并且本发明不局限于此。
在所有实施例中，密钥修改函数f优选地基于适当的(强)密钥函数，例如SHA256、HMAC、AES等等。
在本发明的描述中，将使用以下术语：
传统实体不知道增强密钥处理的实体
被更新的实体被更新的能够处理增强密钥处理的实体
术语“源”和“目标”通常指的是在RNC改变之前/之后ME连接到的实体。
如以上所使用的，被更新的实体的名称附有+符号，例如被更新的ME写成“ME+”。如果实体是否被更新或者特定属性是否应用于被更新的实体和传统实体二者不相关，则使用符号“+”，例如使用ME(+)来表示被更新的ME(即，ME+)或传统ME中的二者/任一个。
本发明利用以下属性：被更新的节点/移动终端可以向信令消息添加信息单元(IE)，并且接收到该信令消息的传统节点/终端将简单地忽略这些IE。作为示例，3GPP网络协议是按照这种方式指定的。这意味着：
-对于被更新的节点而言，向信令消息添加新IE是安全的，即便它不知道信令消息被发送至的节点是否被更新。
-如果被更新的节点检测到信令消息中存在新IE，则它知道(或者更确切地说，它可以可靠地推断)产生信令消息的节点也是被更新的。
本发明的原理如下。
在被更新的ME(即，ME+)初始附着到网络时，被更新的ME将通知具有增强密钥管理功能的网络(没有被更新的ME自然不会进行这项操作)。存在若干个服务器选项，用于在初始附着时处理ME的增强密钥能力。一个选项是：当附着到网路的ME(+)向核心网通知其能力时，这可以经由正常注册过程来实现。对于关于核心网的现有的ME能力信令而言，所需要的只是被修改为包括与ME的增强密钥能力有关的信息(新IE)，以使得核心网获悉附着的ME是被更新的ME。然后，核心网向RNC通知ME的增强密钥能力。
另一个选项是，ME向核心网单独地通知其关于核心网和无线电接入网的增强密钥能力。RAN(RNC)于是可能需要负责独立于核心网地向ME通知其能力。一备选但较不灵活的方案是需要仅允许RNC+连接到被更新的VLR/MSC/SGSN，这是因为VLR/MSC/SGSN接着可以代表RNC向ME通知其能力。
应理解，在初始附着时使用的具体过程在本发明的范围之外。将在以下假设下对本发明进行描述：已经使用某一适当的过程(可以是上述过程之一或者可以是一些其他的过程)在RNC(+)与ME(+)之间初始(以及相互)建立能力。
一旦ME+已经附着到网络，则本发明的一项重要特征是保持ME+始终知道当前(服务的)RNC是否是被更新的RNC以及被更新的服务RNC始终知道ME是否是被更新的ME的属性。
本发明在与传统节点互相作用方面的问题在于，在ME从传统RNC进行SRNS重定位之后，这可能导致簿记(book-keeping)中的漏洞，这是因为传统RNC可能无法向服务ME的下一个RNC通知传统RNC不支持和/或理解的ME的属性。为了示意，在RNC重定位序列中：从RNC+到RNC，然后到新RNC+，即便第一个RNC+向RNC传送了ME能力，也无法确保该RNC能够将这些能力传递到序列中的最后RNC+。这需要解决，因为否则的话，只要有单个传统RNC参与到RNC改变链中，就必须在所有未来RNC改变中采取传统密钥处理(即便后续的服务RNC和ME都被更新)。本发明利用ME+与RNC+之间的通信和/或RNC之间的通信来保持该属性(ME+始终知道当前(服务的)RNC是否是被更新的RNC以及服务的被更新的RNC(即，RNC+)始终知道ME是否是被更新的ME的属性)。通过向ME通知它正在移至的RNC是否被更新、以及通过向目标RNC通知ME是否被更新来保持该属性。
本发明的一个部分涉及SRNS重定位，这发生在活动模式(例如TS23.060中所定义的)下(或者在UTRANRRC规范25.331中所定义的RRCCONNECTED状态下)。采用与初始附着类似的方式来处理如TS23.060(6.9.2.1节)所描述的IDLE(空闲)模式RAU(路由区域更新)过程。当UE在IDLE模式下移动并且出现在新RNC下时，UE建立新的RRC连接，并且这里也可以使用在初始附着时所采用的相应动作。
注意，本发明不是特地解决至/自其它无线电接入技术(例如，TS43.129的PS切换的所有方面)的IRAT(异系统切换)。这意味着，从根据GERAN(GSMEDGE无线电接入网络)或E-UTRAN标准操作的网络切换的ME将不再使用增强的密钥管理能力，即便ME和RAN二者都被更新。这是必需的，因为我们无法信任源网络能够检测到ME具有特定的增强UTRAN能力，并且因此我们无法假设GSM/LTE网络能够将该信息传送给3G/UMTS网络。从被更新的ME(即，ME+)的角度，这不成问题，因为被更新的ME(即，ME+)知道在任意IRAT切换之后网络应当将其(至少初始地)视为传统ME。
为了简单起见，说明书不就讨论PS还是CS密钥(其使用取决于所使用的服务类型)进行区分，这是因为相同的原理应用于每一种类型的密钥。此外，还应当注意控制面密钥可以不同于用户面密钥。具体地，控制面密钥始终基于最新的安全激活的域(CS/PS)，该域可以不同于当前数据面服务在其中运行的域。在这种情况下，可以将本发明应用于两组密钥。
将针对参照图2(a)到2(c)描述的所有三种SRNS重定位的情况来描述本发明如何修改密钥，以及如何在各个实体(即，ME和RNC)中保持与相应实体是否被更新有关的知识：没有ME参与的SRNS重定位(图2(a)，参见TS23.060的6.9.2.2.1)；组合的硬切换与SRNS重定位(图2(b)，参见TS23.060的6.9.2.2.2)；和组合的小区/URA更新和SRNS重定位(图2(c)，参见TS23.060的6.9.2.2.3)。由于在初始附着到系统之后，被更新的ME(即，ME+)知道它是否连接到被更新的RNC(即，RNC+)与否(反之亦然)，只需要针对每一种SRNS重定位变型考虑两种子情况：
1.系统在该过程开始之前的初始状态是ME+连接到RNC+。
2.系统在该过程开始之前的初始状态是ME+连接到RNC。
不需要考虑ME没有被更新的情况。这是因为，本发明使得所有被更新的RNC都具有关于ME是否被更新的知识，并且只能是被更新的RNC对密钥执行任意增强的改变(或调整)，本发明的方法在ME没有被更新的情况下不执行任何密钥调整。然而，在传统ME的情况下，仍然需要关于哪些实体被更新以及哪些不被更新的指示，以使得被更新的RNC确实能够知道它对应的是传统的ME。注意，只有被更新的实体传送显式信息来指示其状态。传统实体不发送与正在被更新的有关的任何信息，所以在传统实体的情况下，通过在相应节点处没有接收到信息来产生该实体没有被更新的指示。
在下表中列出这些情况，以便查看。
首先将描述本发明对于没有ME参与的SRNS重定位的应用。
图3示出了在没有ME参与的SRNS重定位时发生的信令。图3取自TS23.060的6.9.2.2.1条款，并示出了没有ME参与的SRNS重定位的PS版本。本发明只使用信令中的下列属性：
-存在从源RNC(+)到目标RNC(+)的信令路径(这是所谓的源RNC到目标RNC透明容器)
-存在从ME(+)所响应的目标RNC(+)发起的过程(针对PS，这是RAN移动信息消息交换)。
针对CS情况，使用相应的特征。
在图3所示的信令中，在1处作出关于执行SRNS重定位的决定，在2处源RNC发信号通知当前(旧)SGSN(服务GPRS支持节点)需要SRNS重定位，并且在3处当前SGSN通知目标(新的)SGSN需要SRNS重定位。
在4处目标SGSN通知目标RNC需要SRNS重定位，并且在目标SGSN与目标RNC之间建立无线电承载。在4’处目标RNC向目标SGSN返回肯定确认。在5处目标SGSN通知当前SGSN针对SRNS重定位的请求正在被处理。
在6处当前SGSN向源RNC发送重定位命令，以向源RNC通知目标RNC的标识，并且在7和8处源RNC向源RNC发送数据和重定位提交信号。目标RNC通过在9处发送重定位检测消息来向新的SGSN通知该重定位。在10处目标RNC向移动站发送RAN移动信息，并且移动站在10’处通过发送RAN移动信息确认消息来进行肯定应答。在11处，目标RNC通知目标SGSN重定位完成，在12处目标SGSN通知旧SGSN重定位完成，并在12’处旧SGSN向目标SGSN肯定应答它已经接收到重定位完成消息。
目标SGSN在13处向GGSN(网关GPRS支持节点)发送更新PDP上下文请求，并且GGSN在13’处发送响应。此外，旧SGSN在14处向源RNC发送Iu释放命令，并且在Iu释放完成时，源RNC在14’处发信号通知旧SGSN。然后在15处执行路由区域更新。
如上所述，对于每一种重定位机制有两种情况要考虑：(A)源RNC被更新的情况和(B)源RNC没有被更新的情况。将先描述情况A。
密钥调整-在源RNC被更新的情况A中，主要问题源于ME+在接收到RAN移动信息10消息之前没有意识到RNC的改变。这意味着，在ME+知道它应当改变其CK和IK之前，ME+必须接收、验证RAN移动信息消息10的完整性保护，并对消息10进行解密。不幸的是，当ME+接收到消息10时，从ME+的角度来看，ME+仅仅接收到了一个信令消息，而并不知道这是正在进行的重定位过程的一部分(因为ME+尚未参与到重定位中)。因此，ME+无法知道它接收到的消息是否是源RNC发送的(并且在由旧的、未调整的CK/IK保护的情况下)或者它是否是目标RNC+所发送的RAN移动信息消息(并且因此由调整后的CK/IK保护)。
本发明克服这一点的一种方式是，ME+初始使用当前CK/IK，然后如果利用当前CK/IK对接收到的消息进行的完整性保护失败，则尝试调整后的CK/IK。然而，这不是非常正规的，也不算最优的安全设计。取而代之地，一优选实施例是，源RNC+在这种情况下执行回到其自身的本地SRNS重定位(“RNC内SRNS重定位”)，然后立即进行针对目标RNC的真实SRNS重定位(回到其自身的本地SRNS重定位可以在上图中的步骤8之前执行)。当进行第二次SRNS重定位时，这是到目标RNC的重定位，源RNC+向目标RNC提供在第一次RNC内SRNS重定位时推导出的经调整的密钥CK/IK。这么做的结果是，在牵涉到目标RNC的情况下，只可能连累到在ME+与源RNC之间在时间上在两个SRNS重定位之间发送的业务。此外，不需要改变现有的过程。
保持关于哪些实体被更新的知识-由于源RNC+被更新，因此它知道ME+是否被更新，并且在这种情况下源RNC+向目标RNC+发送关于ME+是否被更新的指示。在优选实施例中，该指示是通过源SRNC到目标RNC透明容器从源RNC发送到目标RNC的MS能力中的新的信息单元(IE)，该容器包括在重定位所需消息(图3中的消息2)中，然后被转发给目标RNC(例如，经由消息3和4)。这意味着，在没有ME参与的SRNS重定位之后，目标RNC(+)知道ME+是否被更新(如果目标RNC自身被更新)。
当目标RNC(+)向ME+发送RAN移动信息消息10时，根据本发明，当且仅当目标RNC(+)是被更新的RNC时，它在消息10中包括目标RNC(+)是被更新的RNC的显式信息。如果ME+在消息10中接收到这样的显式信息，则它知道目标RNC被更新。如果RAN移动信息消息10中没有这种显式信息，则ME+可以断定目标RNC(+)没有被更新。备选地，可以通过“较晚的”消息来发送目标RNC(+)是否被更新的信息，但是这可能导致与下面要描述的组合的小区/URA重定位中的序列的竞争条件。例如，如果目标RNC(为了清楚起见，这在本示例中称为RNC1)没有在消息10中向移动终端通知它是否被更新，则可能出现竞争条件，并且在RNC1已经通知了移动终端它是否被更新之前存在到另一个RNC(这将称为RNC2)的另外重定位。如果发生这种情况，则移动终端可能不知道在从RNC1到RNC2的另外重定位时是否调整密钥，这是因为移动终端不知道RNC1是否是被更新的RNC。将“ME+能力指示”包括在小区/URA更新确认消息中也是有益的，这是因为移动终端可以从没有保持ME被更新的知识的“旧RNC”到达具有被更新的RNC的小区。
由于当前的UTRAN标准不能确保传统RNC应当转发ME能力信息的未知部分，所以不能假设传统RNC将转发关于ME是否被更新的信息。然而，对于这个问题的解决方案是，ME+可以在RAN移动信息确认消息(参见图3的消息流中的消息11)中包括关于它被更新的指示。如果目标RNC(+)发现消息11中没有该指示，则可以断定ME没有被更新。
现在将描述本发明在针对源RNC没有被更新的情况B的没有ME参与的SRNS重定位的应用。
密钥调整-传统源RNC完全不知道增强密钥改变，并且仅仅根据其现有行为进行操作。由于ME+知道它是连接到传统RNC或被更新的RNC，因此在ME+当前连接到传统RNC的情况下，ME+在被通知已经发生了没有ME参与的SRNS重定位时不执行任何密钥调整。
保持被更新实体的知识-传统源RNC完全不知道增强密钥改变，并且仅仅根据现有行为进行操作。
当目标RNC(+)在消息10向ME+发送RAN移动信息消息时，根据本发明，当且仅当目标RNC(+)是被更新的RNC时，该消息包括它被更新的信息。这确保ME+知道目标RNC(+)是否被更新(如果目标RNC(+)没有提供它被更新的信息)，ME+将把这个当作目标RNC(+)是传统RNC的指示。在来自ME+的响应消息(RAN移动信息完成消息10’)中，ME+包括它是否被更新的指示(传统ME不会这么做)。这确保目标RNC(如果它是被更新的RNC)知道ME(+)是否被更新。
图4是示出了在没有ME参与的SRNS重定位时如何在RNC(+)和ME+中保持知识的状态图。
图4的左边示出了ME+正在由被更新的RNC(即，RNC+)提供服务的状态。ME+知道RNC被更新，并且RNC+知道ME被更新。如果对于被更新的目标RNC发生没有ME参与的SRNS重定位，则在1处由RNC+和ME+二者调整密钥。
如果对于没有被更新的目标RNC发生没有ME参与的SRNS重定位，则在重定位时不调整密钥。然而，如上所述，源RNC可以执行内SRNS重定位，这使得在重定位到新RNC之前，在2处由源RNC+和ME+二者调整密钥。
图4的右边示出了ME+正在由没有被更新的RNC提供服务的状态。ME知道源RNC没有被更新，但是RNC不知道ME被更新。如果发生没有ME参与的SRNS重定位，则由于源RNC没有被更新，如在3和4处所示的，它无法调整这些密钥，并且ME+也不调整密钥(即便ME+能够调整密钥)。
如5处所示，关于目标RNC是否被更新的信息优选地包括在从目标RNC到ME+的RAN移动信息消息(消息10)中，并且关于ME是否被更新的信息优选地包括在到目标RNC的移动信息完成消息(消息10’)中(或者包括在源RNC到目标RNC透明容器中)。
如果在这个过程期间SGSN或MSC/VLR有改变，则在没有ME参与的SRNS重定位之后的路由/位置区域更新过程中处理关于ME(+)和/或SGSN/MSC/VLR是否被更新的信息。在核心网侧，备选方案是：在传送MS能力时，源SGSN/MSC/VLR向目标SGSN/MSC/VLR通知ME(+)的增强的密钥处理能力。如果SGSN/MSC/VLR将它不理解的MS能力中的新信息单元丢弃，则该备选方案无法运作。
接下来，将描述本发明在组合的硬切换和SRNS重定位中的应用。
图5示出了在组合的硬切换和SRNS重定位时发生的信令。图5来自TS23.060的6.9.2.2.2条款，并且示出了组合的硬切换和SRNS重定位的PS版本。本发明只使用信令中的下列属性：
-存在从源RNC(+)到目标RNC(+)的信令路径(这是源RNC到目标RNC透明容器)
-存在从目标RNC(+)到源RNC(+)的信令路径(这是目标RNC到源RNC透明容器)
-目标RNC到源RNC透明容器包含在容器中接收到时要由目标RNC(+)传递给ME(+)的消息(这是容器中包含的RRC消息)。
针对CS情况，使用相应的特征。
在图5所示的信令中，消息1至7对应于图3中的消息1至7，不再进行描述。
在8处源RNC向移动终端发送RRC(无线电资源控制)消息。在9处，源RNC将SRNS上下文转发给旧SGSN，并在9a处，旧SGSN将SRNS上下文转发给新SGSN。然后，新SGSN在9b处向旧SGSN发送肯定应答，并在9c处将SRNS上下文转发给目标RNC。在目标RNC已经检测到移动终端之后，目标RNC通过在10处发送重定位检测消息来向新SGSN通知该重定位，并且移动终端在8’处向目标RNC发送RRC消息。
图5中的消息11至15对应于图3中的消息11至15，不再进行描述。
如上所述，对于每一种重定位机制有两种情况要考虑：(A)源RNC被更新的情况和(B)源RNC没有被更新的情况。将先描述情况A。
情况A(源RNC被更新)-密钥调整-在这种情况下，密钥调整可以与实际的重定位信令结合，并且在重定位之前，源RNC(+)不需要执行单独的内SRNS重定位以调整CK/IK(如针对没有ME参与的SRNS重定位的情况一样)。由于这里所描述的重定位比没有ME参与的SRNS重定位更为时间关键，因此该组合提供了更大的益处。
由于源RNC+知道ME+被更新，因此它将在源RNC到目标RNC的透明容器中将CK/IK发送至目标RNC(+)之前调整CK/IK。该容器包括在重定位所需消息(上述流程图中的消息2)中。目标RNC(+)按照与传统系统相同的方式来使用密钥，并且因此不知道(并且不需要知道)它们是否已经被调整。
如果ME被更新，则它知道正在向其提供服务的源RNC(+)是否被更新，并且根据本发明，当(并且仅当)源RNC(+)是被更新的RNC时，ME调整CK/IK。ME+和目标RNC+开始使用来自ME+的经调整的密钥，并且包括从ME+到目标RNC+的RRC消息(图5中的上行链路消息8)。
保持被更新实体的知识-根据本发明，源RNC+通过源RNC到目标RNC透明容器向目标RNC(+)发送关于ME是否被更新的指示(备选地，该指示可以包括在MS能力IE中)。按照这种方式，目标RNC+将知道ME(+)是否被更新。
根据本发明，目标RNC+将它被更新的信息包括在目标RNC到源RNC透明容器所包括的RRC消息的新IE中。然后，由源RNC(+)在图5的下行链路消息8中将该RRC消息转发至ME。目标RNC可能不包括它是否是传统RNC的这种信息。这样，根据是否接收到该信息，通知ME(+)目标RNC(+)是否被更新。
情况B(源RNC没有被更新)-调整密钥-由于源RNC没有被更新，因此ME+或是源RNC都不执行密钥调整。
情况B(源RNC没有被更新)-保持被更新实体的知识-ME(+)按照与源RNC(+)被更新的情况完全相同的方式获悉目标RNC(+)是否被更新。
在源RNC是传统RNC的情况下，它将不向目标RNC(+)提供关于ME(+)是否被更新的任何信息。这意味着，目标RNC(+)将不知道ME+是否被更新。然而，根据本发明，被更新的ME+可以将它被更新的信息包括在上述流程图中的上行链路RRC消息编号8’中。这意味着被更新的RNC+在未来的SRNS重定位中仍然能够使用密钥调整。
图6是示出了在组合的硬切换和SRNS重定位时如何在RNC(+)和ME+中保持知识的状态图。
图6的左边示出了ME+正在由被更新的RNC(即，RNC+)提供服务的状态。ME+知道RNC被更新，并且RNC知道ME被更新。如果对于被更新的目标RNC发生组合的硬切换和SRNS重定位，则密钥在1处由源RNC+和ME+二者调整。
如果对于没有被更新的目标RNC发生组合的硬切换和SRNS重定位，则密钥在2处还由源RNC+和ME+二者调整。
图6的右边示出了ME+正在由没有被更新的RNC提供服务的状态。ME+知道RNC没有被更新，但是RNC不知道ME被更新。如果发生组合的硬切换和SRNS重定位，则如3和4处所示，源RNC由于其没有被更新而无法调整密钥，并且因此ME+也不调整密钥(即便ME+能够调整密钥)。
如5处所示，关于目标RNC是否被更新的信息优选地包括在到ME+的RRC消息中(图5中的消息8)，并且关于ME是否被更新的信息优选地包括在到目标RNC的RRC消息(消息8’)中(原则上，它也可以包括在源RNC到目标RNC透明容器中)。
接下来，将描述本发明对于组合的小区/URA更新和SRNS重定位的应用。
图7示出了在组合的小区/URA更新和SRNS重定位时发生的信令。图7来自TS23.060的6.9.2.2.3条款，并且示出了组合的小区/URA更新和SRNS重定位的PS版本。本发明只使用信令中的下列属性：
-存在从源RNC(+)到目标RNC(+)的信令路径(这是源RNC到目标RNC的透明容器)
-存在从目标RNC(+)到源RNC(+)的信令路径(这是目标RNC到源RNC的透明容器)
-目标RNC到源RNC的透明容器包含在容器中接收到时要由目标RNC(+)传递给ME(+)的消息(这是容器中包含的RRC消息)。
针对CS情况，使用相应的特征。
在图7所示的信令中，移动终端初始在1处向源RNC发送小区更新/URA更新消息或小区更新/GRA更新消息。
在图7所示的信令中，消息2至9对应于图3中的消息2至9，不再进行描述。
在10处目标RNC向移动终端发送小区更新确认/URA更新确认消息或小区更新确认/GRA更新确认消息。在10’处移动终端向目标RNC发送UTRAN移动信息消息。
在图7所示的信令中，消息11至15对应于图3中的消息11至15，不再进行描述。
如上所述，对于每一种重定位机制有两种情况要考虑：(A)源RNC被更新的情况和(B)源RNC没有被更新的情况。将先描述情况A，然后描述情况B。
情况A(源RNC被更新)-密钥调整-这种情况与参照图3所描述的没有ME参与的SRNS重定位的情况非常相似，直到重定位检测消息(消息9)(除了在不存在没有ME参与的SRNS重定位的情况下优选地在消息8之前执行的RNC内SRNS重定位以外)。然而，图7的消息10与图3相比有显著不同：使用经调整的密钥的第一消息源自网络侧(如果遵循相同的策略)。此时，ME(+)必须仍然准备接受来自源RNC(+)的信令，例如作为其他同时运行过程的一部分。
该过程中的第一消息(小区更新/URA更新消息(消息1))不加密，因为它通过公共控制信道(CCCH)发送。ME(+)将该消息发送至目标RNC(+)，目标RNC(+)在上行链路信令传送指示消息(图7中未示出)中将其路由至源RNC(+)。
根据本发明，源RNC(+)知道ME(+)是否被更新，并且当前仅当ME(+)被更新时，它在通过源RNC到目标RNC透明容器将CK/IK发送至目标RNC(+)之前调整CK/IK。该容器包括在重定位所需消息(图7中的消息2)中。目标RNC(+)按照与传统系统相同的方式使用密钥，并且因此不知道(并且不需要知道)它们是否已经被调整过。
ME+知道它所连接到的源RNC(+)是否是被更新的RNC，并且根据本发明，当(且仅当)源RNC(+)被更新时，调整CK/IK，并且该调整在发送小区更新/URA更新消息(消息1)之后进行。由于小区更新/URA更新消息没有被加密，并且被更新的源RNC(+)知道被更新的ME+在发送小区更新/URA更新消息之后始终会调整密钥，所以源RNC(+)也在验证了消息的完整性之后调整密钥。从此时起，ME+开始接受具有经调整的密钥的下行链路业务。ME(+)期望接收的来自网络的下一个下行链路消息是来自目标RNC(+)的小区更新确认/URA更新确认消息(图7中的消息10)。
情况A(源RNC被更新)-保持被更新实体的知识-根据本发明，源RNC+在源RNC到目标RNC透明容器(备选地，可以包括在MS能力IE中)中向目标RNC(+)发送关于ME是否被更新的指示。按照这种方式，如果它是更新的RNC，则目标RNC(+)知道ME(+)是否被更新。
如果目标RNC(+)没有在SIB(系统信息块)中广播其增强的密钥处理能力，则它能够在小区更新确认/URA更新确认消息中包括针对ME(+)的指示。传统的目标RNC不包括这种指示。按照这种方式，如果ME(+)是ME+，则它能够知道目标RNC(+)是否被更新。
情况B(源RNC没有被更新)-调整密钥-由于源RNC没有被更新，因此在这种情况下ME(+)和源RNC均不执行密钥调整。
情况B(源RNC没有被更新)-保持被更新实体的知识-ME(+)按照与源RNC(+)被更新的情况完全相同的方式获悉目标RNC(+)被更新。
在源RNC是传统RNC的情况下，它将不向目标RNC(+)提供关于ME(+)是否被更新的任何信息。这意味着，目标RNC(+)将不知道ME+是否被更新。然而，被更新的ME+可以将它被更新的指示包括在上行链路消息(UTRAN移动信息确认-图7中的消息10’)中。这意味着，如果目标RNC是RNC+，则目标RNC+能够使用密钥调整来进行下一个SRNS重定位，这是因为它意识到ME是被更新的ME并且也能够调整密钥。
图8是示出了在组合的小区/URA更新和SRNS重定位时如何在RNC(+)和ME+中保持知识的状态图。
图8的左边示出了ME+正在由被更新的RNC提供服务的状态。ME+知道RNC被更新，并且RNC知道ME被更新。如果针对被更新的目标RNC发生组合的小区/URA更新和SRNS重定位，则在1处由源RNC+和ME+二者调整密钥。
如果针对没有被更新的RNC发生组合的小区/URA更新和SRNS重定位，则密钥也由源RNC+和ME+二者在2处调整。
图8的右边示出了ME+正在由没有被更新的RNC提供服务的状态。ME知道源RNC没有被更新，但是RNC不知道ME被更新。如果组合的小区/URA更新和SRNS重定位发生，则由于源RNC没有被更新，如在3和4处所示的，它无法调整密钥，并且ME+也不调整密钥(即便ME+能够调整密钥)。
如5处所示，关于目标RNC是否被更新的信息优选地包括在从目标RNC到ME+小区更新确认/URA更新确认(或小区更新确认/URA确认)消息(图7中的消息10)中或者包括在SIB消息中，并且关于ME是否被更新的信息优选地包括在UTRAN移动信息确认消息中，并且在该消息中从源RNC发送至目标RNC(+)(图7中的消息10’)或者包括在源RNC到目标RNC透明容器中。
图9是示出了本发明的方法的主要步骤的流程框图。
如步骤93所示，节点(例如，通过由至少一个第一密钥保护的连接服务于移动终端的源RNC)保持所述第一密钥和与该移动终端的密钥管理能力(KMC)有关的信息。如果移动终端经历到新RNC的SRNC重定位，则在步骤95，当且仅当所存储的密钥管理能力指示该移动终端支持增强的密钥管理能力时，该节点修改第一密钥，以创建第二密钥。然后，节点在步骤96将第二密钥发送至新RNC(即，目标RNC)。(如果所存储的密钥管理能力指示移动终端不支持增强的密钥管理能力，即，移动终端是传统移动终端，则节点将不执行步骤95，并且节点将在步骤96发送未修改的第一密钥)。
在步骤97，将与移动终端的密钥管理能力有关的信息发送至目标RNC。该信息可以由节点(即，由源RNC)或者由移动终端发送。
如上所述，如果SRNS重定位是没有ME参与的SRNS重定位，则源RNC可以指示移动终端在修改第一密钥之前执行节点内重定位，这在图9的步骤94示出。
图9的步骤91和92示意了在节点通过来自第三节点(充当重定位的源节点)的SRNS重定位而变成服务于移动终端的RNC时可能发生的步骤。在步骤91处，节点可以向移动终端发送与节点的密钥管理能力有关的信息-以使得移动终端能够意识到它正在被重定位至被更新的RNC(因为传统RNC不发送该信息)。在步骤92，节点可以接收与移动终端的密钥管理能力有关的信息-该信息可以由移动终端或由第三节点发送。
如先前所说明的，如果执行步骤91和92，则步骤96和97可以利用与SRNS重定位有关的信令消息，以避免对于附加消息的需要。
图10是示意了在移动终端处执行的本发明的方法的主要步骤的流程框图。
由源RNC通过由至少一个第一密钥保护的连接所服务的移动终端保持第一密钥。在步骤101，移动终端保持第一密钥和与源RNC的密钥管理能力有关的信息。如果移动终端经历到新RNC的SRNS重定位，在步骤103，当且仅当所存储的密钥管理能力指示源RNC支持增强的密钥管理能力时，移动终端修改第一密钥，以创建第二密钥。(如果所存储的密钥管理能力指示移动终端不支持增强的密钥管理能力，即，移动终端是传统移动终端，则移动终端将不执行步骤103)。
如上所述，如果SRNS重定位是没有ME参与的SRNS重定位，则源RNC可以指示移动终端在修改第一密钥之前执行节点内重定位。节点内重定位的执行在图10的步骤103示出。
在步骤104，移动终端可以向作为SRNS重定位中的目标RNC的RNC发送与移动终端的密钥管理能力有关的信息。在重定位之后，移动终端在步骤105接收与作为SRNS重定位中的目标RNC的RNC的密钥管理能力有关的信息(假设，目标RNC是被更新的RNC-如果目标RNC是传统RNC，则移动终端将不会接收到与RNC的密钥管理能力有关的信息，并且将根据没有接收到该信息而获悉它正在由传统RNC服务)。
图11是示出了根据本发明实施例的节点1101的主要组件的框图。该节点具有输入节点1105和输出接口1103、处理器1104和存储器1102。这些组件是或者可以是传统组件，并且将不再进一步描述。
节点1101具有用于保持与由所述节点通过由至少一个第一密钥保护的连接所服务的移动终端的密钥管理能力有关的信息以及第一密钥的模块1102a。模块1102a可以是图11所述的节点中的存储器1102的一部分，或者模块1102a可以独立于节点的存储器1102。
节点1101还具有用于在将所述移动终端重定位到第二节点时，当且仅当存储在模块1102a中的移动终端的密钥管理能力指示移动终端所支持增强的密钥管理能力时，修改第一密钥以创建第二密钥的模块1104a。模块1104a可以是在图11所示的处理器1104上运行的软件模块，或者备选地模块1104a可以是独立于处理器1104的硬件模块(包括软件)。
节点1101还具有用于将第二密钥发送至第二节点的模块1103a。模块1103a可以是如图11所述的节点中的输出接口1103的一部分，或者模块1103a可以独立于节点中的输出接口1103。
节点可选地还包括用于将移动终端的密钥管理能力发送至第二节点的模块。
图12是示出了根据本发明实施例的移动终端1201的主要组件的框图。该移动终端具有无线接口1204、处理器1024和存储器1202。为了清楚起见，省略诸如显示器和数据输入设备(例如键盘)之类的其他组件(或者既充当显示器又充当数据输入设备的触摸屏之类的组件)。
移动终端1201还具有用于保持与通过由至少一个第一密钥保护的连接服务移动终端的第一节点的密钥管理能力有关的信息以及第一密钥的模块1202a。模块1202a可以是图12所述的移动终端中的存储器1202的一部分，或者模块1202a可以独立于存储器1202。
移动终端1201还具有模块1204a，用于在将移动终端从第一节点重定位到第二节点时，当且仅当存储在模块1202a中的密钥管理能力指示第一节点支持增强的密钥管理能力时，修改第一密钥以创建第二密钥。模块1204a可以是在图12所示的处理器1204上运行的软件模块，或者备选地模块1204a可以是独立于处理器1204的硬件模块(包括软件)。
移动终端1201可选地还具有模块1203a，用于将其密钥管理能力发送至第二节点。模块1203a可以是如图12所述的节点中的无线接口1203的一部分，或者模块1203a可以独立于移动终端1201中的无线接口1203。

Claims (20)

1.一种用于服务无线电网络子系统SRNS重定位的增强密钥管理方法，包括：
在通过由至少一个第一密钥保护的连接服务于移动终端的第一无线电网络控制器中，保持所述第一密钥和与所述移动终端的密钥管理能力有关的信息；以及
在将所述移动终端重定位到第二无线电网络控制器时，
当且仅当所述密钥管理能力指示所述移动终端所支持的增强的密钥管理能力时，通过所述第一无线电网络控制器来修改所述第一密钥，由此创建第二密钥；
将所述第二密钥从所述第一无线电网络控制器发送至所述第二无线电网络控制器；以及
向所述第二无线电网络控制器发送与所述移动终端的密钥管理能力有关的所述信息。
2.根据权利要求1所述的方法，还包括：
在所述第一无线电网络控制器修改所述第一密钥之前，所述第一无线电网络控制器指示所述移动终端执行到所述第一无线电网络控制器的节点内重定位。
3.根据权利要求1或2所述的方法，其中，所述发送步骤是由所述移动终端或所述第一无线电网络控制器执行的。
4.根据权利要求2所述的方法，包括：在与重定位的完成有关的一个或多个信令消息中发送所述信息。
5.根据权利要求1或2所述的方法，包括：在重定位准备阶段，基于所述信息来确定所述移动终端是否支持所述增强的密钥管理能力。
6.根据权利要求1或2所述的方法，其中，修改所述第一密钥包括：利用所述第一密钥和与所述第二无线电网络控制器有关的信息来修改所述第一密钥。
7.根据权利要求1或2所述的方法，还包括：在将所述移动终端从第三无线电网络控制器重定位至所述第一无线电网络控制器时，从所述第一无线电网络控制器向所述移动终端发送与所述第一无线电网络控制器的密钥管理能力有关的信息。
8.根据权利要求7所述的方法，还包括：在将所述移动终端从所述第三无线电网络控制器重定位之后，在所述第一无线电网络控制器处接收来自所述移动终端的与所述移动终端的密钥管理能力有关的信息。
9.根据权利要求7所述的方法，包括：将所述信息包括在与所述移动终端从所述第三无线电网络控制器至所述第一无线电网络控制器的重定位的完成有关的一个或多个信令消息中。
10.根据权利要求7所述的方法，其中，与所述第一无线电网络控制器的密钥管理能力有关的信息包括所述第一无线电网络控制器支持增强的密钥管理能力的信息。
11.一种用于服务无线电网络子系统SRNS重定位的增强密钥管理方法，包括：
在第一无线电网络控制器通过由至少一个第一密钥保护的连接所服务的移动终端中，保持所述第一密钥和与所述第一无线电网络控制器的密钥管理能力有关的信息；以及
在将所述移动终端从所述第一无线电网络控制器重定位到第二无线电网络控制器时，
当且仅当所述密钥管理能力指示所述第一无线电网络控制器所支持的增强的密钥管理能力时，通过所述移动终端来修改所述第一密钥，由此创建第二密钥。
12.根据权利要求11所述的方法，还包括：
在所述移动终端修改所述第一密钥之前，所述移动终端执行到所述第一无线电网络控制器的节点内重定位。
13.根据权利要求11或12所述的方法，还包括：从所述移动终端向所述第二无线电网络控制器发送与所述移动终端的密钥管理能力有关的信息。
14.根据权利要求11或12所述的方法，还包括：在将所述移动终端重定位至所述第二无线电网络控制器之后，在所述移动终端处接收与所述第二无线电网络控制器的密钥管理能力有关的信息。
15.根据权利要求13所述的方法，还包括：在与重定位的完成有关的一个或多个信令消息中发送所述信息。
16.根据权利要求11或12所述的方法，其中，修改所述第一密钥包括：利用所述第一密钥和与所述第二无线电网络控制器有关的信息来修改所述第一密钥。
17.一种用于服务移动终端的无线电网络控制器，所述无线电网络控制器包括：
模块，用于保持与由所述无线电网络控制器通过由至少一个第一密钥保护的连接所服务的移动终端的密钥管理能力有关的信息以及所述第一密钥；以及
模块，用于在将所述移动终端重定位到第二无线电网络控制器时，当且仅当所述密钥管理能力指示所述移动终端所支持的增强的密钥管理能力时，修改所述第一密钥，由此创建第二密钥；以及
模块，用于将所述第二密钥从所述无线电网络控制器发送至所述第二无线电网络控制器。
18.根据权利要求17所述的无线电网络控制器，还包括：用于向所述第二无线电网络控制器发送与所述移动终端的密钥管理能力有关的信息的模块。
19.一种移动终端，包括：
模块，用于保持与通过由至少一个第一密钥保护的连接服务所述移动终端的第一无线电网络控制器的密钥管理能力有关的信息以及所述第一密钥；以及
模块，用于在将所述移动终端从所述第一无线电网络控制器重定位到第二无线电网络控制器时，当且仅当所述密钥管理能力指示所述第一无线电网络控制器所支持的增强的密钥管理能力时，通过所述移动终端来修改所述第一密钥，由此创建第二密钥。
20.根据权利要求19所述的移动终端，还包括：用于从所述移动终端向所述第二无线电网络控制器发送与所述移动终端的密钥管理能力有关的信息的模块。
CN201180014253.9A 2010-03-17 2011-03-16 用于srns重定位的增强密钥管理 Active CN102804826B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US31463410P 2010-03-17 2010-03-17
US61/314,634 2010-03-17
PCT/EP2011/053999 WO2011113873A1 (en) 2010-03-17 2011-03-16 Enhanced key management for srns relocation

Publications (2)

Publication Number Publication Date
CN102804826A CN102804826A (zh) 2012-11-28
CN102804826B true CN102804826B (zh) 2016-03-02

Family

ID=44148498

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201180014253.9A Active CN102804826B (zh) 2010-03-17 2011-03-16 用于srns重定位的增强密钥管理

Country Status (5)

Country Link
US (2) US8929543B2 (zh)
EP (1) EP2548389B1 (zh)
CN (1) CN102804826B (zh)
BR (1) BR112012018268B1 (zh)
WO (1) WO2011113873A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101867924B (zh) * 2010-06-07 2016-07-06 中兴通讯股份有限公司 空中接口密钥的更新、生成方法及无线接入系统
US10433161B2 (en) * 2012-01-30 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Call handover between cellular communication system nodes that support different security contexts
CN103428690B (zh) * 2012-05-23 2016-09-07 华为技术有限公司 无线局域网络的安全建立方法及系统、设备
US9313802B2 (en) 2013-01-17 2016-04-12 Intel IP Corporation Communication of security key information
GB2509937A (en) * 2013-01-17 2014-07-23 Nec Corp Providing security information to a mobile device in which user plane data and control plane signalling are communicated via different base stations
CN105850167B (zh) 2013-12-24 2019-07-23 日本电气株式会社 Sce所用的设备、系统和方法
CN110024325B (zh) * 2016-11-26 2021-01-29 华为技术有限公司 用于设备之间mka协商的系统、方法和设备
EP3952375B1 (en) * 2017-01-30 2022-11-23 Telefonaktiebolaget LM Ericsson (publ) Security context handling in 5g during connected mode
CN107508804A (zh) * 2017-08-10 2017-12-22 山东渔翁信息技术股份有限公司 一种保护移动终端中密钥和证书的方法、装置及移动终端
US10542428B2 (en) 2017-11-20 2020-01-21 Telefonaktiebolaget Lm Ericsson (Publ) Security context handling in 5G during handover
CN110167019A (zh) * 2018-02-13 2019-08-23 华为技术有限公司 通信方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7181218B2 (en) * 2001-04-10 2007-02-20 Telefonaktiebolaget Lm Ericsson (Publ) Commanding handover between differing radio access technologies
CN101257723A (zh) * 2008-04-08 2008-09-03 中兴通讯股份有限公司 密钥生成方法、装置及系统

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6405313B1 (en) * 1997-04-25 2002-06-11 At&T Corp. Method for providing authentication assurance in a key-binding system
US6418130B1 (en) * 1999-01-08 2002-07-09 Telefonaktiebolaget L M Ericsson (Publ) Reuse of security associations for improving hand-over performance
FI107486B (fi) * 1999-06-04 2001-08-15 Nokia Networks Oy Autentikaation ja salauksen järjestäminen matkaviestinjärjestelmässä
GB2356770A (en) * 1999-11-23 2001-05-30 Ericsson Telefon Ab L M SRNS relocation in a UMTS network
US20030084287A1 (en) * 2001-10-25 2003-05-01 Wang Huayan A. System and method for upper layer roaming authentication
GB2392590B (en) * 2002-08-30 2005-02-23 Toshiba Res Europ Ltd Methods and apparatus for secure data communication links
JP3992579B2 (ja) * 2002-10-01 2007-10-17 富士通株式会社 鍵交換代理ネットワークシステム
ATE552709T1 (de) * 2003-09-26 2012-04-15 Ericsson Telefon Ab L M Verbesserter sicherheitsentwurf für die kryptographie in mobilkommunikationssystemen
EP1714418B1 (en) * 2004-02-11 2017-01-11 Telefonaktiebolaget LM Ericsson (publ) Key management for network elements
US8190124B2 (en) * 2004-10-22 2012-05-29 Broadcom Inc. Authentication in a roaming environment
GB0428084D0 (en) 2004-12-22 2005-01-26 Nokia Corp Method for producing authentication information
US7626963B2 (en) * 2005-10-25 2009-12-01 Cisco Technology, Inc. EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure
DE102006015033B4 (de) * 2005-12-16 2016-07-07 Siemens Aktiengesellschaft Mobile Station als Gateway für mobile Endgeräte zu einem Zugangsnetz sowie Verfahren zur Netzanmeldung der mobilen Station und der mobilen Endgeräte
US20070154016A1 (en) * 2006-01-05 2007-07-05 Nakhjiri Madjid F Token-based distributed generation of security keying material
US8320561B2 (en) * 2007-08-08 2012-11-27 Qualcomm Incorporated Key identifier in packet data convergence protocol header
EP2277351A4 (en) * 2008-04-30 2015-12-23 Mediatek Inc METHOD FOR LEADING A TRAFFIC ENCRYPTION KEY
US8209745B2 (en) * 2008-05-13 2012-06-26 At&T Mobility Ii Llc Automatic population of an access control list to manage femto cell coverage
KR20090126166A (ko) * 2008-06-03 2009-12-08 엘지전자 주식회사 트래픽 암호화 키 생성 방법 및 갱신 방법
DE102009032465B4 (de) * 2008-07-16 2016-10-13 Infineon Technologies Ag Sicherheit in Netzwerken
EP2351395A4 (en) * 2008-11-03 2014-07-09 Nokia Corp METHOD, DEVICES AND COMPUTER PROGRAM PRODUCT FOR MANUFACTURING SAFETY DURING TRANSMISSION BETWEEN A PACKAGED NETWORK AND A LINEAR NETWORK
KR101389611B1 (ko) * 2009-09-29 2014-04-29 노키아 코포레이션 핸드오버 장애에 이어지는 키 핸들링을 위한 소스 식별 방법과 장치 및 컴퓨터 판독가능 저장 매체
US8862878B2 (en) * 2010-11-19 2014-10-14 International Business Machines Corporation Authentication and authorization of a device by a service using broadcast encryption

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7181218B2 (en) * 2001-04-10 2007-02-20 Telefonaktiebolaget Lm Ericsson (Publ) Commanding handover between differing radio access technologies
CN101257723A (zh) * 2008-04-08 2008-09-03 中兴通讯股份有限公司 密钥生成方法、装置及系统

Also Published As

Publication number Publication date
EP2548389A1 (en) 2013-01-23
US20150140968A1 (en) 2015-05-21
CN102804826A (zh) 2012-11-28
US8929543B2 (en) 2015-01-06
EP2548389B1 (en) 2015-06-24
WO2011113873A1 (en) 2011-09-22
BR112012018268A2 (pt) 2018-08-28
US9350537B2 (en) 2016-05-24
BR112012018268B1 (pt) 2021-02-02
US20130003967A1 (en) 2013-01-03

Similar Documents

Publication Publication Date Title
CN102804826B (zh) 用于srns重定位的增强密钥管理
CN105557006B (zh) 通信系统中的用户设备及由其进行通信的方法
KR102068948B1 (ko) Dc (이중 접속성) 를 위한 장치, 시스템 및 방법
US8938071B2 (en) Method for updating air interface key, core network node and radio access system
US20080039096A1 (en) Apparatus, method and computer program product providing secure distributed HO signaling for 3.9G with secure U-plane location update from source eNB
US20170359719A1 (en) Key generation method, device, and system
JP4390842B1 (ja) 移動通信方法、無線基地局及び移動局
US20070224993A1 (en) Apparatus, method and computer program product providing unified reactive and proactive handovers
CN101983518A (zh) 用于为切换提供多跳密码分离的方法、设备和计算机程序产品
ES2807792T3 (es) Método de reubicación de red móvil y estación base
KR20100114927A (ko) 무선 통신 시스템에서 핸드오버를 실행하는 동안 키 관리를 실행하기 위한 시스템 및 방법
CN102238668A (zh) 一种通过网关进行x2切换的方法
WO2009099096A1 (ja) 移動通信方法及び無線基地局
CN101180909A (zh) 在路由区域改变期间减少服务中断的系统、设备、方法和程序
CN108370508A (zh) 在通信网络中使用的节点及操作所述节点的方法
US9386448B2 (en) Method for updating air interface key, core network node and user equipment
US7826824B2 (en) Method of protecting the integrity of messages sent in a mobile radio system
US8934868B2 (en) Method for updating and generating air interface key and radio access system
US8804962B2 (en) Method and system for establishing enhanced air interface key
JP2010045815A (ja) 移動通信方法、無線基地局及び移動局
CN102006644A (zh) 一种第三代移动通信系统重定位加密处理的方法及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant