一种集群组根密钥更新方法与流程

文档序号:12630043阅读:427来源:国知局

本发明涉及集群通信领域,尤其涉及一种集群组根密钥更新方法。



背景技术:

多媒体数字集群系统主要用于行业专网,在行业专网中对业务的通信安全有比较高的要求,所以多媒体数字集群系统中对于集群组呼业务会设计空中接口加密或者端到端加密来保障用户的信息通信安全。

无论是对集群组呼进行空中接口加密还是端到端加密,目前公开的技术都是采用为集群组分配集群组根密钥的密钥管理方式,此集群组根密钥在一段时间内是不变的。集群组根密钥的更新方式有两种:网络侧定时更新、发生动态重组业务触发集群组根密钥更新。如果组成员都处于空闲态,直接发送集群组根密钥更新进行更新即可。但是如果此时该组正在组呼中,直接进行密钥更新有可能影响到现有组呼业务。

因此希望提出一种有效的集群组根密钥更新方法,使得密钥更新不能影响到现有组呼业务,并且如果是发生了动态重组业务,还希望新加入该集群组的用户仍然能够在接收到迟后进入寻呼的时候加入到组呼中。



技术实现要素:

本发明提出一种集群组根密钥更新方法,该方法包括:

网络侧触发集群组根密钥更新后,如果集群组正在组呼中,则网络侧和终端侧都记录当前根密钥和更新根密钥,本次组呼仍然使用当前根密钥,更新根密钥在本次组呼释放之后再激活。

上述方法中,如果网络侧多次触发了集群组的根密钥更新,网络侧和终端侧都只记录当前根密钥和最后一次更新根密钥。

优选的,上述方法可以具体为:

网络侧触发集群组根密钥更新后,向集群组的组成员发送点对点的集群组根密钥更新消息,所述消息中携带集群组标识和更新的根密钥信息,网络侧还判断集群组是否在组呼中:如果不在,则立即激活更根密钥;如果在,则保存 更新根密钥,在本次组呼释放之后再激活,并且在所述集群组根密钥更新消息中,还携带当前的根密钥信息;这里,所述根密钥信息可以包括根密钥和其对应的密钥标识;所述集群组根密钥更新消息可以与集群组信息更新消息合并为一条消息;

终端为每个集群组保存一个根密钥列表,列表保存两条记录,第一条用于记录当前的根密钥信息,第二条用于记录更新的根密钥信息;终端接收到集群组根密钥更新消息后,判断自己是否已经是该集群组成员:如果是,则将接收到的更新的根密钥信息保存为根密钥列表的第二条记录;如果不是,则新建该集群组的根密钥列表,并将接收到的当前的根密钥信息保存为第一条记录,将接收到的更新的根密钥信息保存为第二条记录;

终端接收到网络侧的集群组寻呼后,将集群组寻呼中的根密钥信息与该集群组的根密钥列表中的第一条记录进行比较:如果一致,则使用第一条记录中的根密钥;如果不一致,则将第一条记录从根密钥列表中删除,将第二条记录保存为第一条记录,然后再将集群组寻呼中的根密钥信息与该集群组的根密钥列表中的第一条记录进行比较:如果一致,则使用第一条记录中的根密钥,如果不一致,则终端从该集群组中退出。

采用本发明后,对于正处于集群组呼的集群组,集群组根密钥的更新不仅不会影响到现有组呼,而且可以保证新加入该集群组的用户能够在接收到迟后进入寻呼后加入到组呼中。

附图说明

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

图1为本发明实施例的集群组根密钥更新流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然, 所描述的实施例是本发明一部分实施例,而不是全部的实施例;需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

本示例以McLTE系统为例来说明集群组根密钥更新的实现过程。McLTE系统中包括HLR(用户归属位置寄存器)、TCF(集群组呼业务控制中心)和UT(集群终端)等网元。HLR保存了用户以及集群组信息,调度台在建立集群组时,HLR为每个集群组生成集群组根密钥GK,并且分配密钥标识GKID用来区分同一个集群组的不同GK。

本实施例中,网络侧触发集群组根密钥更新后,如果集群组正在组呼中,则本次组呼仍然使用当前根密钥,更新根密钥在本次组呼释放之后再激活。图1为本实施例的集群组根密钥更新流程图,具体说明如下:

步骤101、HLR根据定时器或者动态重组业务触发,对集群组GID1的根密钥进行更新,生成新的根密钥的信息,更新后的集群组根密钥记为NewGK,新的密钥标识记为NewGKID,然后HLR向该集群组的所有组成员发送点对点的集群组根密钥更新消息;

本实施例的集群组根密钥更新消息与集群组信息更新消息合并为一条消息,即HLR向该集群组的所有组成员发送Group Information Update command消息,携带集群组标识、NewGKID和NewGK,每个用户的Group Information Update command消息首先发送到TCF。

步骤102、TCF判断GID1是否在组呼中:如果不在,则直接透传Group Information Update Command消息给UT;如果在,则TCF将GID1当前所用的GKID和GK增加到Group Information Update Command消息中,然后再发送给UT。从该步骤可以看出,当集群组空闲时,由于UT不需要知道原来的密钥,那么直接发送新的密钥即可;当集群组处于呼叫中时,由于UT还需要知道原来的密钥,那么消息中将发送两组GK信息。

步骤103、终端为每个集群组都保存一个根密钥列表GKList,GKList只保存两条记录,每条记录包括GKID和GK,第一条用于记录当前组呼使用的GK;第二条用于记录更新的GK。UT接收到Group Information Update Command消息,判断自己是否已经是集群组GID1成员:如果是,则直接将NewGKID和 NewGK更新到GKList的第二条记录中;如果不是,则UT为GID1建立GKList,将消息中的NewGK和NewGKID保存为GKList的第二条记录,如果消息中还携带GKID和GK,则将GKID和GK保存为GKList的第一条记录;然后UT返回Group Information Update Response消息给TCF。

步骤104、TCF发送Group Information Update Response消息给HLR。

步骤105、HLR再发送Group Data Update Request消息给TCF;

步骤106、TCF接收到Group Data Update Request消息后,判断GID1是否在组呼中:如果在,则将NewGKID和NewGK保存为待激活根密钥,在本次组呼释放之后再激活;如果不在,则直接使用NewGKID和NewGK为激活根密钥;TCF返回Group Data Update Response消息给HLR。

上述步骤103和106,在集群组呼持续过程中如果HLR触发了多次集群组的根密钥更新,比如发生了多次动态重组业务,则TCF和UT都只记录当前组呼使用的集群组根密钥和最后一次更新的集群组根密钥。

步骤107、TCF向UT发送集群组寻呼,UT接收到TCF的集群组寻呼后,将集群组寻呼中的GKID与该集群组的GKList中的第一个GKID进行比较:如果一致,则使用第一个GKID对应的GK;如果不一致,则判断第一条根密钥信息无效,直接将第一条记录从GKList中删除,将第二条记录保存为第一条记录,然后再将集群组寻呼中的GKID与该集群组的GKList中的第一条记录进行比较:如果一致,则使用第一个GKID对应的GK,如果不一致,则终端从该集群组中退出。

本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1