CN102469454A - Rnc切换中的密钥设置方法及无线网络控制器、终端 - Google Patents
Rnc切换中的密钥设置方法及无线网络控制器、终端 Download PDFInfo
- Publication number
- CN102469454A CN102469454A CN2010105354254A CN201010535425A CN102469454A CN 102469454 A CN102469454 A CN 102469454A CN 2010105354254 A CN2010105354254 A CN 2010105354254A CN 201010535425 A CN201010535425 A CN 201010535425A CN 102469454 A CN102469454 A CN 102469454A
- Authority
- CN
- China
- Prior art keywords
- key
- rnc
- rrc message
- target rnc
- sends
- 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.)
- Pending
Links
Images
Abstract
本发明实施例提供一种RNC切换中的密钥设置方法及无线网络控制器、终端。该方法,在源RNC执行UE未参与的SRNS Relocation流程时,包括:目标RNC接收源RNC发送的密钥,所述密钥根据源RNC使用的密钥推衍获得;目标RNC根据源RNC发送的密钥对第一下行RRC消息进行加密,并向UE发送加密后的第一下行RRC消息,加密后的第一下行RRC消息中包含目标RNC支持UKH的信息;目标RNC接收UE发送的上行RRC消息,上行RRC消息中包含UE支持UKH的信息;目标RNC获取新密钥对第二下行RRC消息进行加密并发送至UE。本发明实施例实现了目标RNC与UE之间的信息交互,及密钥的隔离。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种RNC切换中的密钥设置方法及无线网络控制器、终端。
背景技术
在UMTS(Universal Mobile Telecommunications System,通用移动通信系统)中,随着HSPA(High Speed Packet Access,高速包接入)技术的采用,3GPP标准提出了对HSPA+也即HSPA演进的研究,3GPP安全组为了对HSPA+扁平架构演进后的系统安全性进行改进,也开始了UTRAN(UniversalTerrestrial Radio Access Network,通用陆地移动接入网)密钥增强的研究项目。该研究项目的目的是将E-UTRAN的密钥架构引入到HSPA+网络,实现HSPA+跟E-UTRAN相同的安全等级。在HSPA+网络中,增强的RNC(RadioNetwork Controller,无线网络控制器)也即RNC+,与传统的RNC相比,同样需要有相应的安全机制保证RNC本身以及所处的HSPA网络的安全,不同的是增强的RNC具有更强的功能,可以支持传统RNC所不能支持的UTRAN密钥层次(UKH)。
在现有技术UE未参与的SRNS Relocation流程中,在切换至目标RNC后UE不知采用何种密钥对第一条下行RRC消息进行解密,从而无法实现目标RNC与UE之间的信息交互。
发明内容
本发明实施例提供一种RNC切换中的密钥设置方法及无线网络控制器、终端,能够在切换后实现目标RNC与UE之间的信息交互。
为了解决上述技术问题,本发明实施例的技术方案如下:
本发明实施例提供了一种RNC切换中的密钥设置方法,在源RNC执行UE未参与的SRNS Relocation流程时,所述方法包括:
目标RNC接收源RNC发送的密钥,所述密钥根据所述源RNC使用的密钥推衍获得;
所述目标RNC根据所述源RNC发送的密钥对第一下行RRC消息进行加密,并向UE发送加密后的第一下行RRC消息,所述加密后的第一下行RRC消息中包含所述目标RNC支持通用陆地移动接入网密钥层次UKH的信息,以使得所述UE接收所述加密后的第一下行RRC消息后,向所述目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息,所述UE采用根据在所述源RNC使用的密钥推衍获得的密钥,对接收到的所述加密后的第一下行RRC消息进行解密;
所述目标RNC接收UE发送的上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
所述目标RNC获取新密钥对第二下行RRC消息进行加密并发送至所述UE。
本发明实施例还提供了另一种RNC切换中的密钥设置方法,在源RNC执行UE未参与的SRNS Relocation流程时,所述方法包括:
所述UE接收目标RNC发送的第一下行无线资源控制RRC消息,所述RRC消息采用所述源RNC发送的密钥加密获得的,所述第一下行RRC消息中包含所述目标RNC支持通用陆地移动接入网密钥层次UKH的信息;
所述UE采用根据在所述源RNC使用的密钥进行密钥推衍获得的密钥,对所述第一下行RRC消息进行解密;
所述UE向所述目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
所述UE接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密。
本发明实施例还提供了一种无线网络控制器,包括:
密钥接收单元,用于在源RNC执行UE未参与的SRNS Relocation流程时,接收源RNC发送的密钥,所述密钥根据所述源RNC使用的密钥推衍获得;
第一加密单元,用于根据所述源RNC发送的密钥对第一下行RRC消息进行加密,并向UE发送加密后的第一下行RRC消息,所述加密后的第一下行RRC消息中包含所述无线网络控制器支持通用陆地移动接入网密钥层次UKH的信息,以使得所述UE接收所述加密后的第一下行RRC消息后,向所述无线网络控制器发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息,所述UE采用根据在所述源RNC使用的密钥推衍获得的密钥,对接收到的所述加密后的第一下行RRC消息进行解密;
消息接收单元,用于接收UE发送的上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
第二加密单元,用于获取新密钥对第二下行RRC消息进行加密并发送至所述UE。
本发明实施例还提供了一种UE,包括:
消息接收模块,用于在源RNC执行所述UE未参与的SRNS Relocation流程时,接收目标RNC发送的第一下行无线资源控制RRC消息,所述RRC消息采用所述源RNC发送的密钥加密获得的,所述第一下行RRC消息中包含所述目标RNC支持通用陆地移动接入网密钥层次UKH的信息;
第一解密模块,用于采用根据在所述源RNC使用的密钥进行密钥推衍获得的密钥对所述第一下行RRC消息进行解密;
消息发送模块,用于向所述目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
第二解密模块,用于接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密。
本发明实施例首先通过在执行UE未参与RNC间切换流程时,目标RNC无论是否支持UKH均采用源RNC发送的密钥对发送至UE的下行RRC消息进行加密,UE根据约定采用自己推衍的相同的密钥对该RRC消息进行解密,实现了目标RNC与UE之间的信息交互;进而目标RNC与UE通过intra-SRNSRelocation流程等计算获得新的密钥,实现了目标RNC所采用的密钥与源RNC所采用的密钥的隔离,从而提高了UE与目标RNC信息交互的安全性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是现有技术中UE未参与的SRNS Relocation流程的示意图;
图2是现有技术中一种在RNC切换时的密钥设置方法流程图;
图3A是本发明实施例一种RNC切换中的密钥设置方法流程图;
图3B是本发明实施例另一种RNC切换中的密钥设置方法流程图;
图4是本发明实施例另一种RNC切换中的密钥设置方法流程图;
图5是本发明实施例另一种RNC切换中的密钥设置方法流程图;
图6是本发明实施例另一种RNC切换中的密钥设置方法流程图;
图7是本发明实施例另一种RNC切换中的密钥设置方法流程图;
图8是本发明实施例一种RNC的结构示意图;
图9是本发明实施例另一种RNC的结构示意图;
图10是本发明实施例另一种RNC的结构示意图;
图11是本发明实施例一种UE的结构示意图;
图12是本发明实施例另一种UE的结构示意图;
图13是本发明实施例另一种UE的结构示意图。
具体实施方式
为了使本领域技术人员能进一步了解本发明的特征及技术内容,请参阅以下有关本发明的详细说明与附图,附图仅提供参考与说明,并非用来限制本发明。
在现有技术中,当终端UE发生重定向时,也即由源RNC切换至目标RNC时,对于UE未参与的SRNS Relocation(Serving Radio Network SubsystemRelocation,服务无线网络子系统重定位)流程如图1所示,包括如下步骤:
步骤101,源RNC发起UE未参与的SRNS Relocation流程。
步骤102,源RNC基于自己使用的密钥CKu/IKu计算新的密钥CKu1/IKu1,并将重定向请求消息通过源SGSN(SERVICING GPRS SUPPORTNODE,GPRS服务支持节点)和目标SGSN转发至目标RNC。其中,该重定向请求消息中包含新的密钥CKu1/IKu1。CKu是加密密钥,IKu是完整性保护密钥。
其中CKu/IKu是基于KRNC推演得到的,KRNC是通过基于UE和核心网CN运行AKA(认证和密友协商)后得到的CK/IK推演得到的,例如,KRNC=KDF1(CK/IK,NONCE1,NONCE2),IKu=KDF2(KRNC,Parameter,int-alg-ID),CKu=KDF3(KRNC,Parameter,enc-alg-ID),其中KDF是一个密钥推演函数,NONCE1和NONCE2可以是是两个新鲜的参数例如两个随机数,Parameter可以是一个随机数也可以是目标小区的物理标识,int-alg-ID和enc-alg-ID是完整性保护算法标识和加密算法标识。当然,KRNC和CKu/IKu还可以通过其他方式推演,此处不一一列出。CKu1/IKu1是基于CKu/IKu推演的,例如,IKu1=KDF4(IKu,Parameter),CKu=KDF5(CKu,Parameter)。
步骤103,目标RNC通过目标SGSN和源SGSN向源RNC返回重定向请求确认消息,并且,如果目标RNC支持UKH,目标RNC会计算新的密钥CKu2/IKu2。
其中CKu2/IKu2可以基于如下方式推演,例如,IKu2=KDF6(IKu1,Parameter,int-alg-ID),CKu2=KDF7(CKu1,Parameter,enc-alg-ID),或者IKu2=KDF6(KRNC*,Parameter,int-alg-ID),CKu2=KDF7(KRNC*,Parameter,enc-alg-ID),KRNC*=KDF8(CK,IK,KRNC,Parameter)。
步骤104,源RNC向目标RNC进行数据转发,并发送重定向提交消息,完成源RNC向目标RNC的切换。
步骤105,目标RNC向UE发送第一条下行RRC(Radio Resource Control,无线资源控制协议)消息。其中,如果目标RNC为传统RNC,则会采用源RNC发送的密钥CKu1/IKu1对该下行RRC消息进行加密,如果目标RNC为增强的RNC,则会采用计算的密钥CKu2/IKu2对该下行RRC消息进行加密。该RRC下行消息中还携带有目标RNC是否支持UKH的信息,该信息也同样被加密。
UE接收到该第一条下行RRC消息后,需要对该消息进行解密,然后向目标RRC发送上行RRC消息。然而,由于第一条下行RRC消息被加密,UE无法获知目标RNC是否支持UKH,进而UE无法获知是采用密钥CKu1/IKu1,还是采用密钥CKu2/IKu2对下行RRC消息进行解密,进而无法实现目标RNC与UE间的信息交互。
基于此,现有技术中提出一种在RNC切换时的密钥设置方法,如图2所示,包括以下步骤:
步骤201,UE在源RNC发起传统的SRNS Relocation流程。其中,在传统的SRNS Relocation流程中源RNC会将自己使用的密钥直接发送至目标RNC。
步骤202,源RNC发送重定向请求消息至目标RNC,该消息中包括源RNC使用的密钥CKu/IKu。
步骤203,目标RNC返回重定向请求确认消息,进而完成源RNC至目标RNC的切换。
步骤204,目标RNC与UE采用密钥CKu/IKu进行信息交互。
无论UE是否参与该传统SRNS Relocation流程,UE均可以采用UE根据已知的密钥CKu/IKu实现与目标RNC之间的信息交互。
步骤205,UE在目标RNC发起UE参与的intra-SRNS Relocation(内部服务无线网络子系统重定位)流程。其中intra-SRNS Relocation流程与SRNSRelocation流程的区别仅在于,intra-SRNS Relocation流程中源RNC与目标RNC为同一个RNC。
如果UE和目标RNC均支持UKH,则目标RNC和UE会计算新的密钥CKu3/IKu3。
步骤206,目标RNC与UE采用新的密钥CKu3/IKu3进行信息交互。
由于UE参与了该intra-SRNS Relocation流程,目标RNC发送至UE的第一条下行RRC消息不会进行加密,之后,目标RNC向UE发送其它下行消息,会采用CKu3/IKu3进行加密,UE采用CKu3/IKu3对其进行解密。
虽然通过首先发起传统的SRNS Relocation流程切换至目标RNC,解决了UE不知采用何种密钥对第一条下行RRC消息进行解密的问题,实现了目标RNC与UE之间的信息交互,但是,由于后续UE与目标RNC所采用的密钥与源RNC使用的密钥之间只是进行了一次更新,使得UE与目标RNC信息交互的安全性较低。基于此,本发明实施例提供了一种新的RNC切换中的密钥设置方法,下面结合附图和实施例,对本发明的技术方案进行描述。
参见图3A,为本发明实施例一种RNC切换中的密钥设置方法流程图。
该方法可以包括:
步骤301A,在源RNC执行UE未参与的SRNS Relocation流程时,目标RNC接收源RNC发送的密钥。
源RNC发送的密钥是根据源RNC使用的密钥推衍获得的。
步骤302A,目标RNC根据源RNC发送的密钥对第一下行RRC消息进行加密。
在由源RNC执行SRNS Relocation流程,切换至目标RNC之后,目标RNC向UE下发第一条下行RRC消息,该消息中可以包含目标RNC支持UKH的信息。具体的,可以通过在该RRC消息中增加一个新的IE说明目标RNC是否支持UKH,这个IE可以是一个比特指示RNC是否支持UKH也可以是一个新的参数,这个新的IE能够被增强的UE识别但是传统的UE将忽略这个IE。
其中,目标RNC无论是否支持UKH,均直接采用源RNC发送给目标RNC的密钥对该第一条下行RRC消息进行加密,而并非另外计算新的密钥,该源RNC发送来的密钥是源RNC根据自身使用的密钥推衍获得的密钥。
UE根据预先的约定,只要接收到第一条下行RRC消息,就采用UE自己根据在源RNC使用的密钥进行推衍所获得的密钥对该消息进行解密。UE推衍获得密钥的方法与源RNC推衍获得密钥的方法相同。其中,UE自身保存的与源RNC相同的在源RNC使用的密钥,UE和源RNC具有的相同的密钥推演函数KDF,UE能够获得的与源RNC相同的推演新密钥的其它参数可能的随机数等
步骤303A,目标RNC接收UE发送的上行RRC消息。
UE对下行RRC消息解密后即可获知目标RNC支持UKH的能力,并向目标RNC发送第一条上行RRC消息,同样采用根据源RNC使用的密钥进行推衍所获得的密钥进行加密,该消息中表明了UE支持UKH的能力,以使目标RNC和UE双方均可获知对方支持UKH。具体的,可以通过在该RRC消息中增加一个新的IE说明UE是否支持UKH,这个IE可以是一个比特指示UE是否支持UKH也可以是一个新的参数,这个新的IE能够被增强的RNC识别但是传统的RNC将忽略这个IE。
步骤304A,目标RNC获取新密钥对第二下行RRC消息进行加密并发送至UE。
在目标RNC和UE均支持UKH的条件下,目标RNC和UE可以进一步执行intra-SRNS Relocation流程或RAU过程等,对目标RNC和UE之间使用的密钥进行进一步计算和更新,以获得新密钥,提高UE与目标RNC之间信息交互的安全性。在获得新密钥后,目标RNC和UE之间可采用新密钥进行信息交互,即目标RNC采用新密钥对第二下行RRC消息进行加密并发送至UE,UE采用新密钥对第二下行RRC消息进行解密,然后UE向目标RNC发送采用新密钥加密后的第二上行RRC消息。其中,第二上、下行RRC消息仅是为了区分前述步骤中的第一上、下行RRC消息,并非特指第二条上、下行RRC消息。
此处的第一RRC消息是指Relocation过程中RNC发送的第一条下行RRC消息以及UE发送的第一条上行RRC消息,除了这两条RRC消息外,其它RRC消息都可以成为第二RRC消息。
本发明实施例首先通过在执行UE未参与RNC间切换流程时,目标RNC无论是否支持UKH均采用源RNC发送的密钥对发送至UE的第一条下行RRC消息进行加密,UE根据约定采用自己推衍的相同的密钥对该RRC消息进行解密,实现了目标RNC与UE之间的信息交互;进而目标RNC与UE再次计算获得新的密钥,以采用新的密钥进行信息交互,实现了目标RNC所采用的密钥与源RNC所采用的密钥的隔离,从而提高了UE与目标RNC信息交互的安全性。
参见图3B,为本发明实施例另一种RNC切换中的密钥设置方法流程图。
该方法可以包括:
步骤301B,在源RNC执行UE未参与的SRNS Relocation流程时,UE接收目标RNC发送的采用源RNC发送的密钥加密的第一下行RRC消息。
源RNC执行UE未参与的SRNS Relocation流程,在由源RNC切换至目标RNC之后,UE接收目标RNC向其下发的第一条下行RRC消息,该消息中可以包含目标RNC支持UKH的信息,该RRC消息由目标RNC采用源RNC发送的密钥进行加密,源RNC发送的密钥是根据源RNC使用的密钥推衍获得的。
步骤302B,UE采用根据在源RNC使用的密钥进行密钥推衍获得的密钥对第一下行RRC消息进行解密。
UE在接收到该消息后,根据约定直接采用UE自己根据在源RNC使用的密钥进行推衍所获得的密钥对该消息进行解密,其中,UE推衍获得密钥的方法与源RNC推衍获得密钥的方法相同。
步骤303B,UE向目标RNC发送上行RRC消息。
该消息中可以包含UE支持UKH的信息。
步骤304B,UE接收目标RNC发送的第二下行RRC消息,并采用获取的新密钥对第二下行RRC消息进行解密。
若UE支持UKH,并根据下行RRC消息获知目标RNC也支持UKH之后,UE可以进一步发起intra-SRNS Relocation流程或RAU过程等,计算获得的新密钥,后续采用该新密钥与目标RNC进行交互信息,以提高UE与目标RNC之间信息交互的安全性。新密钥的具体计算方法请参照后续实施例的描述。
本发明实施例首先通过在执行UE未参与RNC间切换流程时,目标RNC无论是否支持UKH均采用源RNC发送的密钥对发送至UE的第一条下行RRC消息进行加密,UE根据约定采用自己推衍的相同的密钥对该RRC消息进行解密,实现了目标RNC与UE之间的信息交互;进而目标RNC与UE再次计算获得新的密钥,以采用新的密钥进行信息交互,实现了目标RNC所采用的密钥与源RNC所采用的密钥的隔离,从而提高了UE与目标RNC信息交互的安全性。
参见图4,为本发明实施例另一种RNC切换中的密钥设置方法流程图。
本实施例中,通过在UE未参与的SRNS Relocation流程中,目标RNC采用源RNC发送的密钥对第一条下行RRC进行加密,使得UE可以采用相同的密钥进行解密,实现了目标RNC与UE的信息交互,进而通过执行UE参与的intra-SRNS Relocation流程,更新了目标RNC与UE之间使用的密钥,实现了源RNC与目标RNC之间密钥的隔离。该方法可以包括:
步骤401,源RNC发起UE未参与的SRNS Relocation流程。
UE在源RNC使用密钥CKu/IKu进行加密和完整性保护。源RNC发起由源RNC切换至目标RNC的UE未参与的SRNS Relocation流程。
步骤402,源RNC发送重定向请求消息至目标RNC,该消息中包括密钥CKu’/IKu’。
其中,密钥CKu’/IKu’是源RNC基于自己使用的密钥CKu/IKu推衍获得的。具体的推衍过程与实施例一相同,可以是IKu’=KDF4(IKu,Parameter),CKu’=KDF5(CKu,Parameter)。
具体的,源RNC可以首先向源SGSN发送重定向请求消息,由源SGSN向目标SGSN转发该请求消息,然后再由目标SGSN向目标RNC转发该请求消息。上述转发过程为现有技术此处不再赘述。
步骤403,目标RNC返回重定向请求确认消息,完成源RNC到目标RNC的切换。
具体的,目标RNC可以向目标SGSN回复重定向请求确认消息,由目标SGSN向源SGSN回复重定向响应消息,源SGSN向源RNC发送重定向命令消息,源RNC向目标RNC进行数据转发,并发送重定向提交消息,从而完成源RNC到目标RNC的切换。此过程为现有技术,此处不再赘述。
步骤404,目标RNC向UE发送第一条下行RRC消息,并对该消息采用密钥CKu’/IKu’进行加密。
在本实施例中,无论目标RNC是否支持UKH,都采用源RNC发送来的密钥CKu’/IKu’对第一条RRC消息进行加密和完整性保护,加密和完整性保护时分别以CKu’和IKu’以及其它的在UE和目标RNC之间都有的相同的参数作为输入对该消息进行加密和完整性保护。
步骤405,UE采用密钥CKu’/IKu’对第一条下行RRC消息进行解密。
UE自己根据在源RNC使用的密钥进行推衍,即可获知密钥CKu’/IKu’,然后根据预先约定,只要接收到第一条下行RRC消息,就直接采用密钥CKu’/IKu’对第一条下行RRC消息进行解密,和完整性检查,解密和完整性检查时分别以CKu’和IKu’以及其它的在UE和目标RNC之间都有的相同的参数作为输入对该消息进行解密和完整性检查。
之后,UE与目标RNC可采用密钥CKu’/IKu’进行信息交互,其中第一条下行RRC消息中可以包含有目标RNC是否支持UKH的信息,UE发送的第一条上行RRC消息中也可以包含UE是否支持UKH的信息。
步骤406,UE在目标RNC发起UE参与的intra-SRNS Relocation流程。
intra-SRNS Relocation流程与SRNS Relocation流程的区别仅在于,intra-SRNS Relocation流程中源RNC与目标RNC为同一个RNC。
在该intra-SRNS Relocation流程中,如果UE和目标RNC均支持UKH,则目标RNC和UE可以计算获得新的密钥CKu”/IKu”。
其中,新密钥CKu”/IKu”可以是根据3GPP(The 3rd GenerationPartnership Project)标准下的密钥推衍框架计算获得的,例如,可以是目标RNC和UE先根据CK/IK以及CK/IK派生的密钥KRNC推衍KRNC*,然后再根据推衍的KRNC*推衍获得该密钥CKu”/IKu”;也还可以是RNC和UE直接根据密钥CKu’/IKu’再推衍获得密钥CKu”/IKu”,此处不受限制。
步骤407,UE与目标RNC采用新密钥CKu”/IKu”进行信息交互。
由于UE参与该intra-SRNS Relocation流程,所以目标RNC在该流程后向UE下发的第一条RRC消息不会进行加密,之后目标RNC可以对发送至UE的其它下行RRC消息采用新密钥进行加密,UE根据新密钥对下行RRC消息进行解密。UE对发送至目标RNC的上行RRC消息采用新密钥进行加密,目标RNC根据新密钥对上行RRC消息进行解密,实现UE与目标RNC之间的信息交互。
本发明实施例首先通过在执行UE未参与的SRNS Relocation流程时,目标RNC无论是否支持UKH均采用源RNC发送的密钥对第一条下行RRC消息进行加密,UE根据约定采用自己推衍的相同的密钥对该RRC消息进行解密,实现了目标RNC与UE之间的信息交互;进而通过执行UE参与的intra-SRNS Relocation流程,再次更新了UE与目标RNC之间的密钥,实现了源RNC所采用的密钥与目标RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
在本发明的另一实施例中,步骤406还可以是由UE在目标RNC处发起RAU过程,在该过程中计算获得新的密钥。然后在步骤407中,目标RNC采用新密钥与UE进行信息交互。其中RAU过程为现有技术,此处不再赘述。
在另一实施例中,在步骤401之前,UE在源RNC处还可以发起UE参与的intra-SRNS Relocation流程,UE和源RNC计算获得新密钥,然后源RNC将该新密钥发送至目标RNC处,UE也根据约定采用该新密钥对目标RNC下发的第一条RRC消息进行解密。
参见图5,为本发明实施例另一种RNC切换中的密钥设置方法流程图。
本实施例通过在UE未参与的SRNS Relocation流程中,目标RNC采用源RNC发送的密钥对第一条下行RRC进行加密,使得UE可以采用相同的密钥进行解密,实现了目标RNC与UE的信息交互,之后目标RNC和UE可以采用新的密钥进行信息交互,也可以首先执行一个新密钥的启用流程,然后再使用新密钥进行信息交互。该方法可以包括:
步骤501,源RNC发起UE未参与的SRNS Relocation流程。
步骤502,源RNC发送重定向请求消息至目标RNC,该消息中包括密钥CKu’/IKu’。
步骤503,目标RNC返回重定向请求确认消息,完成源RNC到目标RNC的切换。
步骤504,目标RNC向UE发送第一条下行RRC消息,并对该消息采用密钥CKu’/IKu’进行加密。
在该第一条下行RRC消息中还可以包括目标RNC是否支持UKH的信息。
步骤505,UE采用密钥CKu’/IKu’对第一条下行RRC消息进行解密。
以上步骤与前述实施例中的步骤401~405类似,此处不再赘述。
步骤506,UE向目标RNC发送第一条上行RRC消息,该消息采用密钥CKu’/IKu’进行加密。
在该第一条上行RRC消息中还可以包括UE是否支持UKH的信息。UE在获知目标RNC支持UKH之后,则可以在后续步骤中使用UE计算获得的新的密钥CKu”/IKu”。
步骤507,目标RNC对第一条上行RRC消息解密。
目标RNC采用密钥CKu’/IKu’对第一条上行RRC消息解密后,若获知UE支持UKH,则可以在后续步骤中使用目标RNC计算获得的新密钥CKu”/IKu”,该密钥的计算方法与UE计算获得CKu”/IKu”的方法相同。目标RNC计算新密钥的过程可以在接收到第一条上行RRC消息之前进行,也可以在接收该消息之后进行。
其中,目标RNC和UE对新密钥CKu”/IKu”的计算与实施例一步骤406中的计算方法相同,此处不再赘述。
步骤508,UE与目标RNC使用密钥CKu”/IKu”进行信息交互。
在第一条上、下行RRC消息之后,UE和目标RNC可以采用新的密钥CKu”/IKu”对交互信息进行加密。
在本发明的另一实施例中,在步骤507之后,还可以增加以下激活新密钥的专有流程:
目标RNC向UE发送启用新的密钥CKu”/IKu”的指示或通知,该指示或通知同样仍采用密钥CKu’/IKu’进行加密。其中,该指示或通知可以是目标RNC向UE发送一条新的消息,消息中包含一个比特或者一个参数指示UE启用新的密钥CKu”/IKu”。
UE在接收到该指示后,返回以用新密钥的响应信息,该响应信息同样采用密钥CKu’/IKu’进行加密。
在执行完上述两步骤后,再执行步骤508,UE与目标RNC采用密钥CKu”/IKu”进行信息交互。
本发明实施例首先通过在执行UE未参与的SRNS Relocation流程时,目标RNC无论是否支持UKH均采用源RNC发送的密钥对第一条下行RRC消息进行加密,UE根据约定采用自己推衍的相同的密钥对该RRC消息进行解密,实现了目标RNC与UE之间的信息交互;进而通过UE及目标RNC是否支持UKH的信息,在两者均支持UKH时,再次更新了UE与目标RNC之间的密钥,使源RNC所采用的密钥与目标RNC所采用的密钥实现了隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
参见图6,为本发明实施例另一种RNC切换中的密钥设置方法流程图。
本实施例中,通过首先发起传统的SRNS Relocation流程,目标RNC采用源RNC使用的密钥与UE进行信息交互,解决了UE不知采用何种密钥对第一条下行RRC消息进行解密的问题,实现了目标RNC与UE的信息交互,进而通过执行RAU过程,更新了目标RNC与UE之间使用的密钥,实现了源RNC与目标RNC之间密钥的隔离。该方法可以包括:
步骤601,源RNC发起传统的SRNS Relocation流程。
传统的SRNC Relocation,是指UE、RNC和SGSN都按照现有UTRAN中的行为进行操作,源RNC和目标RNC使用相同的密钥,并且这几个节点都不进行其它的密钥推衍。在传统的SRNS Relocation流程中源RNC会将自己使用的密钥直接发送至目标RNC。
当源RNC预先获知如果发起UE未参与的SRNS Relocation流程时可能无法对目标RNC下发的第一条下行RRC消息进行解密后,即可首先发起传统的SRNS Relocation流程使UE切换到目标RNC,该流程中无论UE是否参与,均可以解决UE对目标RNC下发的第一条RRC消息解密的问题。
步骤602,源RNC发送重定向请求消息至目标RNC,该消息中包括源RNC使用的密钥CKu/IKu。
步骤603,目标RNC返回重定向请求确认消息,完成源RNC至目标RNC的切换。
步骤604,目标RNC与UE采用密钥CKu/IKu进行信息交互,其中交互信息包括目标RNC与UE是否支持UKH的信息。
以上步骤601~605为现有技术,此处不再赘述。
步骤605,UE在目标RNC发起RAU过程,在RAU中获得新的密钥CKu’/IKu’。
在传统SRNS Relocation流程结束后,无论该流程中是否改变了SGSN,在流程结束后,UE都会发起RAU(Routing Area Update)路由区更新过程,如果UE和目标RNC支持UKH,则在RAU中目标RNC和UE进行UKH密钥推衍,计算获得新密钥CKu’/IKu’。该密钥CKu’/IKu’的计算可以是接收SGSN发送的根据CK/IK以及CK/IK派生的密钥KRNC推衍的KRNC*,然后再根据推衍的KRNC*推衍获得密钥CKu’/IKu’,也可以是直接接收SGSN发送的根据CK/IK推衍的密钥,再进行推衍,获得密钥CKu’/IKu’。其中,RAU过程为现有技术,此处不再赘述。
步骤606,UE与目标RNC采用新密钥CKu’/IKu’进行信息交互。
在RAU结束后,UE与目标RNC使用新的CKu’/IKu’密钥对交互信息进行加/解密。
本实施例通过首先发起传统的SRNS Relocation流程,解决了UE不知采用何种密钥对第一条下行RRC消息进行解密的问题,进而通过发起RAU过程,在RAU过程中对UE与目标RNC之间的密钥进行了更新,实现了源RNC所采用的密钥与目标RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
参见图7,为本发明实施例另一种RNC切换中的密钥设置方法流程图。
本实施例中,通过首先发起UE参与的intra-SRNS Relocation流程,对UE和源RNC采用的密钥进行了更新,然后再执行传统的SRNS Relocation流程,目标RNC采用源RNC使用的密钥与UE进行信息交互,解决了UE不知采用何种密钥对第一条下行RRC消息进行解密的问题,实现了目标RNC与UE的信息交互,进而再次执行UE参与的intra-SRNS Relocation流程,更新了目标RNC与UE之间使用的密钥,实现了源RNC与目标RNC之间密钥的隔离。该方法可以包括:
步骤701,UE在源RNC发起UE参与的intra-SRNS Relocation流程。
在该intra-SRNS Relocation流程中,如果UE和源RNC均支持UKH,则源RNC和UE可以计算获得中间密钥CKu’/IKu’。源RNC将中间密钥作为自身使用的密钥与UE进行信息交互。其中,中间密钥CKu’/IKu’的计算方法可以与前述实施例一步骤406中的方法类似,此处不再赘述。
步骤702,源RNC发起UE传统的SRNS Relocation流程。
该步骤与实施例三中的步骤601类似,此处不再赘述。
步骤703,源RNC发送重定向请求消息至目标RNC,该消息中包括源RNC使用的密钥CKu’/IKu’。
步骤704,目标RNC返回重定向请求确认消息,完成源RNC至目标RNC的切换。
步骤705,UE和目标RNC采用密钥CKu’/IKu’进行信息交互,交互信息中包含UE和目标RNC是否支持UKH的信息。
步骤706,UE在目标RNC发起UE参与的intra-SRNS Relocation流程。
在该intra-SRNS Relocation流程中,UE和目标RNC均支持UKH,目标RNC和UE可以计算获得新的密钥CKu”/IKu”。该密钥的计算方法可以与前述实施例一步骤406中的方法类似,此处不再赘述。
步骤707,UE与目标RNC采用密钥CKu”/IKu”进行信息交互。
由于UE参与该intra-SRNS Relocation流程,所以目标RNC在该流程后向UE下发的第一条RRC消息不会进行加密,之后目标RNC可以对发送至UE的下行RRC消息采用新密钥进行加密,UE根据新密钥对下行RRC消息进行解密。UE对发送至目标RNC的上行RRC消息采用新密钥进行加密,目标RNC根据新密钥对上行RRC消息进行解密,实现UE与目标RNC之间的信息交互。
本发明实施例首先通过执行UE参与的intra-SRNS Relocation流程,更新了源RNC与UE使用的密钥,然后通过执行传统的SRNS Relocation流程,解决了UE不知采用何种密钥对第一条下行RRC消息进行解密的问题,进而通过再次执行UE参与的intra-SRNS Relocation流程,再次更新了UE与目标RNC之间的密钥,对源RNC所采用的密钥与目标RNC所采用的密钥进行了隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
以上是对方法实施例的详细描述,下面对实现上述方法的系统或装置进行介绍。
参见图8,为本发明实施例一种无线网络控制器的结构示意图。
该RNC可以包括:
密钥接收单元801,用于在源RNC执行UE未参与的SRNS Relocation流程时,接收源RNC发送的密钥,所述密钥根据源RNC使用的密钥推衍获得;
第一加密单元802,用于根据源RNC发送的密钥对第一下行RRC消息进行加密,并向UE发送加密后的第一下行RRC消息,加密后的第一下行RRC消息中包含本RNC支持UKH的信息,以使得UE接收加密后的第一下行RRC消息后,向本RNC发送上行RRC消息,所述上行RRC消息中包含UE支持UKH的信息,UE采用根据在所述源RNC使用的密钥推衍获得的密钥,对接收到的加密后的第一下行RRC消息进行解密;
消息接收单元803,用于接收UE发送的上行RRC消息,上行RRC消息中包含UE支持UKH的信息;
第二加密单元804,用于获取新密钥对第二下行RRC消息进行加密并发送至UE。
源RNC发起UE不参与的SRNS Relocation流程后,密钥接收单元801接收源RNC发送的密钥。第一加密单元802向UE下发第一条下行RRC消息,该消息中包含该RNC支持UKH的信息,并且直接采用源RNC发送来的密钥对该RRC消息进行加密,而并非另外计算新的密钥。该源RNC发送来的密钥是源RNC根据自身使用的密钥推衍获得的密钥。UE根据预先的约定,只要接收到第一条下行RRC消息,就采用UE自己根据在源RNC使用的密钥进行推衍所获得的密钥对该消息进行解密。消息接收单元803接收UE发送的第一条上行RRC消息,该消息同样采用前述UE推衍的密钥进行加密,该消息中表明了UE支持UKH的能力。当本RNC和UE均支持UKH时,第二加密单元804可以采用新密钥与UE进行信息交互,该新密钥可以是通过进一步执行intra-SRNS Relocation流程等计算获得的,以对目标RNC和UE之间使用的密钥进行进一步计算和更新,提高UE与目标RNC之间信息交互的安全性。
本发明实施例的RNC通过上述各单元保证了UE可以根据已知的密钥对本RNC下发的RRC消息进行解密,进而通过计算更新UE与本RNC之间的密钥,实现了源RNC所采用的密钥与本RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与本RNC信息交互的安全性。
参见图9,为本发明实施例另一种RNC的结构示意图。
该RNC除了可以包括密钥接收单元901、第一加密单元902、消息接收单元903和第二加密单元904之外,还可以包括流程执行单元905和密钥计算单元906。
流程执行单元905,用于在第二加密单元904获取新密钥对第二下行RRC消息进行加密并发送至UE之前,执行UE参与的intra-SRNS Relocation流程;
密钥计算单元906,用于在intra-SRNS Relocation流程中,根据3GPP标准下的密钥推衍框架计算获得新密钥。
在源RNC执行UE未参与的SRNS Relocation流程,切换至本RNC后,无论本RNC是否支持UKH,均采用源RNC发送的根据自身使用的密钥推衍获得的密钥对交互信息进行加密,交互信息中包含本RNC及UE是否均支持UKH的信息。当两者均支持UKH时,流程执行单元905执行UE参与的intra-SRNS Relocation流程,在该流程中,密码计算单元906可以根据3GPP标准下的密钥推衍框架计算获得新密钥,例如,可以先根据CK/IK以及CK/IK派生的密钥KRNC推衍KRNC*,然后再根据推衍的KRNC*推衍获得新的密钥;也还可以是直接根据源RNC发送来的密钥再推衍获得新密钥,UE也可以执行相同的计算过程,获得与本RNC相同的密钥。之后,由第二加密单元904采用该新密钥与UE进行信息交互。
本发明实施例的RNC通过上述各单元先后执行UE未参与的SRNSRelocation流程,以及UE参与的intra-SRNS Relocation流程,并在第一个流程中实现了UE对本RNC下发的RRC消息的成功解密,通过两个流程实现了源RNC所采用的密钥与本RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与本RNC信息交互的安全性。
参见图10,为本发明实施例另一种RNC的结构示意图。
该RNC除了可以包括密钥接收单元1001、第一加密单元1002、消息接收单元1003和第二加密单元1004之外,还可以包括指示单元1005和响应接收单元1006。
其中,指示单元1005,用于在第二加密单元1004获取新密钥对第二下行RRC消息进行加密并发送至所述UE之前,向UE发送启用所述新密钥的指示或通知。
响应接收单元1006,用于接收UE发送的启用所述新密钥的响应。
通过指示单元1005和响应接收单元1006实现了UE与本RNC之间采用新密钥的激活流程,之后,第二信息交互单元1004即可采用新密钥与UE实现信息交互。
本发明实施例的RNC通过上述各单元实现了UE对本RNC下发的RRC消息的成功解密,而且通过指示单元1005和响应接收单元1006的新密钥激活流程,实现了源RNC所采用的密钥与本RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与本RNC信息交互的安全性。
参见图11,为本发明实施例一种UE的结构示意图。
该UE可以包括:
消息接收模块1101,用于在源RNC执行UE未参与的SRNS Relocation流程时,接收目标RNC发送的第一下行RRC消息,该RRC消息采用源RNC发送的密钥加密获得的,第一下行RRC消息中包含目标RNC支持UKH的信息;
第一解密模块1102,用于采用根据在源RNC使用的密钥进行密钥推衍获得的密钥对第一下行RRC消息进行解密;
消息发送模块1103,用于向目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
第二解密模块1104,用于接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密。
在执行完UE未参与的SRNS Relocation流程之后,消息接收模块1101接收目标RNC向本UE发送第一条下行RRC消息,该消息采用源RNC发送的密钥进行加密,该密钥是根据源RNC使用的密钥推衍获得的密钥。UE自己可以根据在源RNC使用的密钥推衍获得密钥,该获得的密钥与下行RRC消息的加密密钥相同,在接收到该第一条下行RRC消息后,第一解密模块1102即可根据约定,直接采用本UE推衍获得的密钥进行解密,进而消息发送模块1103向目标RNC发送上行RRC消息,该消息同样采用UE推衍获得的密钥进行加密。目标RNC和UE之间的交互信息中,例如在第一条上、下行消息中可以分别包含UE是否支持UKH以及目标RNC是否支持UKH的信息,当消息解密后UE获知两者均支持UKH后,第二解密模块1104即可采用在发起的intra-SRNS Relocation流程等计算获得的新密码,与目标RNC进行信息交互。
本发明实施例的UE通过上述各模块实现了UE对目标RNC下发的RRC消息的成功解密,而且实现了源RNC所采用的密钥与目标RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
参见图12,为本发明另一种UE的结构示意图。
该UE除了可以包括消息接收模块1201、第一解密模块1202、消息发送模块1203和第二解密模块1204之外,还可以包括:
流程发起模块1205,用于在第二解密模块1204接收目标RNC发送的第二下行RRC消息,并采用获取的新密钥对第二下行RRC消息进行解密之前,在目标RNC发起所述UE参与的intra-SRNS Relocation流程;
密钥计算模块,用于在intra-SRNS Relocation流程中,根据3GPP标准下的密钥推衍框架计算获得新密钥。其中具体的密钥计算过程与前述方法实施例中的相应描述相同,此处不再赘述。
本发明实施例的UE通过上述各模块实现了UE对目标RNC下发的RRC消息的成功解密,而且实现了源RNC所采用的密钥与目标RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
参见图13,为本发明另一种UE的结构示意图。
该UE除了可以包括消息接收模块1301、第一解密模块1302、消息发送模块1303和第二解密模块1304之外,还可以包括:
指示接收模块1305,用于在第二解密模块1304接收目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密之前,接收目标RNC发送的启用所述新密钥的指示或通知;
指示响应模块1306,用于向目标RNC发送启用所述新密钥的响应。
本发明实施例的UE通过上述各模块实现了UE对目标RNC下发的RRC消息的成功解密,而且实现了源RNC所采用的密钥与目标RNC所采用的密钥的隔离,使两者之间无直接联系,从而提高了UE与目标RNC信息交互的安全性。
以上装置或系统中各单元和各模块的具体实现过程请参照前述方法实施例中相应部分的描述,此处不再赘述。
以上所述的本发明实施方式,并不构成对本发明保护范围的限定。任何在本发明的精神和原则之内所作的修改、等同替换和改进等,均应包含在本发明的权利要求保护范围之内。
Claims (12)
1.一种RNC切换中的密钥设置方法,其特征在于,在源无线网络控制器RNC执行终端UE未参与的服务无线网络子系统重定位SRNS Relocation流程时,所述方法包括:
目标RNC接收源RNC发送的密钥,所述密钥根据所述源RNC使用的密钥推衍获得;
所述目标RNC根据所述源RNC发送的密钥对第一下行RRC消息进行加密,并向所述UE发送加密后的第一下行RRC消息,所述加密后的第一下行RRC消息中包含所述目标RNC支持通用陆地移动接入网密钥层次UKH的信息,以使得所述UE接收所述加密后的第一下行RRC消息后,向所述目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息,所述UE采用根据在所述源RNC使用的密钥推衍获得的密钥,对接收到的所述加密后的第一下行RRC消息进行解密;
所述目标RNC接收UE发送的上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
所述目标RNC获取新密钥对第二下行RRC消息进行加密并发送至所述UE。
2.根据权利要求1所述的方法,其特征在于,在所述目标RNC获取新密钥对第二下行RRC消息进行加密并发送至所述UE之前,还包括:
目标RNC执行所述UE参与的内部服务无线网络子系统重定位intra-SRNS Relocation流程;
在所述intra-SRNS Relocation流程中,所述目标RNC根据3GPP标准下的密钥推衍框架计算获得新密钥。
3.根据权利要求1所述的方法,其特征在于,在所述目标RNC获取新密钥对第二下行RRC消息进行加密并发送至所述UE之前,还包括:
目标RNC向所述UE发送启用所述新密钥的指示或通知;
目标RNC接收所述UE发送的启用所述新密钥的响应。
4.一种RNC切换中的密钥设置方法,其特征在于,在源RNC执行UE未参与的SRNS Relocation流程时,所述方法包括:
所述UE接收目标RNC发送的第一下行无线资源控制RRC消息,所述RRC消息采用所述源RNC发送的密钥加密获得的,所述第一下行RRC消息中包含所述目标RNC支持通用陆地移动接入网密钥层次UKH的信息;
所述UE采用根据在所述源RNC使用的密钥进行密钥推衍获得的密钥,对所述第一下行RRC消息进行解密;
所述UE向所述目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
所述UE接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密。
5.根据权利要求4所述的方法,其特征在于,在所述UE接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密之前,还包括:
所述UE在所述目标RNC发起所述UE参与的intra-SRNS Relocation流程;
在所述intra-SRNS Relocation流程中,所述UE根据3GPP标准下的密钥推衍框架计算获得新密钥。
6.根据权利要求4所述的方法,其特征在于,在所述UE接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密之前,还包括:
所述UE接收所述目标RNC发送的启用所述新密钥的指示或通知;
所述UE向所述目标RNC发送启用所述新密钥的响应。
7.一种无线网络控制器,其特征在于,包括:
密钥接收单元,用于在源RNC执行UE未参与的SRNS Relocation流程时,接收源RNC发送的密钥,所述密钥根据所述源RNC使用的密钥推衍获得;
第一加密单元,用于根据所述源RNC发送的密钥对第一下行RRC消息进行加密,并向所述UE发送加密后的第一下行RRC消息,所述加密后的第一下行RRC消息中包含所述无线网络控制器支持通用陆地移动接入网密钥层次UKH的信息,以使得所述UE接收所述加密后的第一下行RRC消息后,向所述无线网络控制器发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息,所述UE采用根据在所述源RNC使用的密钥推衍获得的密钥,对接收到的所述加密后的第一下行RRC消息进行解密;
消息接收单元,用于接收UE发送的上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
第二加密单元,用于获取新密钥对第二下行RRC消息进行加密并发送至所述UE。
8.根据权利要求7所述的无线网络控制器,其特征在于,还包括:
流程执行单元,用于在所述第二加密单元获取新密钥对第二下行RRC消息进行加密并发送至所述UE之前,执行所述UE参与的intra-SRNS Relocation流程;
密钥计算单元,用于在所述intra-SRNS Relocation流程中,根据3GPP标准下的密钥推衍框架计算获得新密钥。
9.根据权利要求7所述的无线网络控制器,其特征在于,还包括:
指示单元,用于在所述第二加密单元获取新密钥对第二下行RRC消息进行加密并发送至所述UE之前,向所述UE发送启用所述新密钥的指示或通知;
响应接收单元,用于接收所述UE发送的启用所述新密钥的响应。
10.一种UE,其特征在于,包括:
消息接收模块,用于在源RNC执行所述UE未参与的SRNS Relocation流程时,接收目标RNC发送的第一下行无线资源控制RRC消息,所述RRC消息采用所述源RNC发送的密钥加密获得的,所述第一下行RRC消息中包含所述目标RNC支持通用陆地移动接入网密钥层次UKH的信息;
第一解密模块,用于采用根据在所述源RNC使用的密钥进行密钥推衍获得的密钥对所述第一下行RRC消息进行解密;
消息发送模块,用于向所述目标RNC发送上行RRC消息,所述上行RRC消息中包含所述UE支持UKH的信息;
第二解密模块,用于接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密。
11.根据权利要求10所述的UE,其特征在于,还包括:
流程发起模块,用于在所述第二解密模块接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密之前,在所述目标RNC发起所述UE参与的intra-SRNS Relocation流程;
密钥计算模块,用于在所述intra-SRNS Relocation流程中,根据3GPP标准下的密钥推衍框架计算获得新密钥。
12.根据权利要求10所述的UE,其特征在于,还包括:
指示接收模块,用于在所述第二解密模块接收所述目标RNC发送的第二下行RRC消息,并采用获取的新密钥对所述第二下行RRC消息进行解密之前,接收所述目标RNC发送的启用所述新密钥的指示或通知;
指示响应模块,用于向所述目标RNC发送启用所述新密钥的响应。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010105354254A CN102469454A (zh) | 2010-11-08 | 2010-11-08 | Rnc切换中的密钥设置方法及无线网络控制器、终端 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010105354254A CN102469454A (zh) | 2010-11-08 | 2010-11-08 | Rnc切换中的密钥设置方法及无线网络控制器、终端 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102469454A true CN102469454A (zh) | 2012-05-23 |
Family
ID=46072487
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2010105354254A Pending CN102469454A (zh) | 2010-11-08 | 2010-11-08 | Rnc切换中的密钥设置方法及无线网络控制器、终端 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102469454A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015006980A1 (zh) * | 2013-07-19 | 2015-01-22 | 华为技术有限公司 | 加密参数处理方法和装置 |
WO2018214903A1 (en) * | 2017-05-24 | 2018-11-29 | Qualcomm Incorporated | Uplink small data transmission in inactive state |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101388829A (zh) * | 2007-09-10 | 2009-03-18 | 大唐移动通信设备有限公司 | 重定位的信令及数据加密的方法、系统及无线网络控制器 |
EP2071885A2 (en) * | 2007-12-05 | 2009-06-17 | Innovative Sonic Limited | Method of handling security key change and related communication device |
CN101820622A (zh) * | 2010-02-05 | 2010-09-01 | 中兴通讯股份有限公司 | 线通信系统中管理空口映射密钥的方法和系统 |
CN101835152A (zh) * | 2010-04-16 | 2010-09-15 | 中兴通讯股份有限公司 | 终端移动到增强utran时建立增强密钥的方法及系统 |
-
2010
- 2010-11-08 CN CN2010105354254A patent/CN102469454A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101388829A (zh) * | 2007-09-10 | 2009-03-18 | 大唐移动通信设备有限公司 | 重定位的信令及数据加密的方法、系统及无线网络控制器 |
EP2071885A2 (en) * | 2007-12-05 | 2009-06-17 | Innovative Sonic Limited | Method of handling security key change and related communication device |
CN101820622A (zh) * | 2010-02-05 | 2010-09-01 | 中兴通讯股份有限公司 | 线通信系统中管理空口映射密钥的方法和系统 |
CN101835152A (zh) * | 2010-04-16 | 2010-09-15 | 中兴通讯股份有限公司 | 终端移动到增强utran时建立增强密钥的方法及系统 |
Non-Patent Citations (2)
Title |
---|
3GPP: "Study on the Introduction of Key Hierarchy in UTRAN", 《3GPP TR 33.859 V0.5.0》 * |
ERICSSON, ST-ERICSSON: "Keeping track of updated peers", 《3GPP TSG SA WG3 SECURITY #59,S3-100498》 * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015006980A1 (zh) * | 2013-07-19 | 2015-01-22 | 华为技术有限公司 | 加密参数处理方法和装置 |
CN104584605A (zh) * | 2013-07-19 | 2015-04-29 | 华为技术有限公司 | 加密参数处理方法和装置 |
CN104584605B (zh) * | 2013-07-19 | 2018-01-23 | 华为技术有限公司 | 加密参数处理方法和装置 |
WO2018214903A1 (en) * | 2017-05-24 | 2018-11-29 | Qualcomm Incorporated | Uplink small data transmission in inactive state |
WO2018214052A1 (en) * | 2017-05-24 | 2018-11-29 | Qualcomm Incorporated | Uplink small data transmission in inactive state |
US11683681B2 (en) | 2017-05-24 | 2023-06-20 | Qualcomm Incorporated | Uplink small data transmission in inactive state |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101232731B (zh) | 用于ue从utran切换到eutran的密钥生成方法和系统 | |
CN112566112B (zh) | 用于无线通信的装置、方法和存储介质 | |
KR101270342B1 (ko) | 키 요소의 교환 | |
EP2529566B1 (en) | Efficient terminal authentication in telecommunication networks | |
CN101516089B (zh) | 一种切换方法及系统 | |
CN101304311A (zh) | 密钥生成方法和系统 | |
JP5774096B2 (ja) | エアインターフェースキーの更新方法、コアネットワークノード及び無線アクセスシステム | |
CN101257723A (zh) | 密钥生成方法、装置及系统 | |
US8666078B2 (en) | Method and system for generating cipher key during switching | |
CN101267668A (zh) | 密钥生成方法、装置及系统 | |
CN101946535A (zh) | 在无线通信系统中执行切换时执行密钥管理的系统和方法 | |
KR20090059074A (ko) | 보안 키 변경 처리 방법 및 관련 통신 기기 | |
CN102056157A (zh) | 一种确定密钥和密文的方法、系统及装置 | |
CN101552983A (zh) | 密钥生成方法、密钥生成装置、移动管理实体与用户设备 | |
JP2017098986A (ja) | Mtcのためのシステム、コアネットワーク、及び方法 | |
CN101299888A (zh) | 密钥生成方法、切换方法、移动管理实体和用户设备 | |
CN101953191A (zh) | 在无线通信系统中实施切换或在实施切换同时实施密钥管理的系统和方法 | |
WO2018083320A1 (en) | Handover of a device which uses another device as relay | |
CN101478752A (zh) | 一种密钥更替方法、系统及设备 | |
CN103139771A (zh) | 切换过程中密钥生成方法及系统 | |
WO2008152611A1 (en) | Apparatus, method and computer program product providing transparent container | |
WO2018137617A1 (zh) | 移动网络小数据的安全传输方法及装置 | |
CN102469454A (zh) | Rnc切换中的密钥设置方法及无线网络控制器、终端 | |
CN108271154B (zh) | 一种认证方法及装置 | |
CN101835151B (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 | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20120523 |