一种实现安全呼叫转移的方法及系统

申请号 CN201010154329.5 申请日 2010-04-21 公开(公告)号 CN102238500A 公开(公告)日 2011-11-09
申请人 中兴通讯股份有限公司; 发明人 田甜; 朱允文; 韦银星; 高峰;
摘要 本 发明 提供了一种实现安全呼叫转移的方法及系统,此方法包括:主叫方呼叫被叫方,所述被叫方触发签约的呼叫转移业务;密钥管理 服务器 通过 应用服务器 获得所述被叫方合法的被转呼方信息;所述被转呼方从所述密钥管理服务器获得媒体密钥;所述主叫方与所述被转呼方建立呼叫连接。本发明提供了一种新的密钥协商机制在IMS系统中实现安全的呼叫转移,并且本发明中基本保留了原IMS系统中的消息格式。
权利要求

1.一种实现安全呼叫转移的方法,其特征在于,
主叫方呼叫被叫方,所述被叫方触发签约的呼叫转移业务;
密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息;
所述被转呼方从所述密钥管理服务器获得媒体密钥;
所述主叫方与所述被转呼方建立呼叫连接。
2.如权利要求1所述的方法,其特征在于,触发所述被叫方签约的呼叫转移业务的情况,是以下情况之一:
无条件前转、无应答前转、寻呼不可及前转、用户忙前转、会话转移业务。
3.如权利要求1所述的方法,其特征在于,
密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:
应用服务器在呼叫请求消息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转呼方;
所述密钥管理服务器根据被转呼方发送的携带所述加密的绑定关系信息的消息,判断所述被转呼方是否为所述被叫方的合法被转呼方。
4.如权利要求2或3所述的方法,其特征在于,
当所述被叫方满足触发条件时,所述被叫方所属应用服务器向所述被转呼方发送呼叫请求消息,所述消息中携带本次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
5.如权利要求1所述的方法,其特征在于,
密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:
所述应用服务器根据所述密钥管理服务器提供的所述被叫方与被转呼方的信息,判断所述被转呼方是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器。
6.如权利要求1所述的方法,其特征在于,密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:
所述应用服务器根据所述密钥管理服务器提供的所述被叫方信息,返回所述被叫方呼叫转移用户标识列表;
所述密钥管理服务器判断所述被转呼方是否为所述被叫方的合法被转呼方。
7.一种实现安全呼叫转移的系统,所述系统包括:主叫方,被叫方,被转呼方,应用服务器,密钥管理服务器;其特征在于,
所述主叫方,用于呼叫被叫方;
所述被叫方,用于根据所述主叫方的呼叫,触发签约的呼叫转移业务;
所述密钥管理服务器,用于通过应用服务器获得所述被叫方合法的被转呼方信息;
所述被转呼方,用于从所述密钥管理服务器获得媒体密钥。
8.如权利要求7所述的系统,其特征在于,
所述应用服务器,用于在呼叫请求消息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转呼方;
所述密钥管理服务器,用于根据被转呼方发送的携带所述加密的绑定关系信息的消息,判断所述被转呼方是否为所述被叫方的合法被转呼方。
9.如权利要求8所述的系统,其特征在于,
所述应用服务器,用于向所述被转呼方发送呼叫请求消息,并在此消息中携带本次呼叫转移中所述被叫方标识与所述被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
10.如权利要求7所述的系统,其特征在于,
所述应用服务器,用于根据所述密钥管理服务器提供的所述被叫方与被转呼方的信息,判断所述被转呼方是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器;
还用于根据所述密钥管理服务器提供的所述被叫方信息,返回所述被叫方呼叫转移用户标识列表;
所述密钥管理服务器,用于判断所述被转呼方是否为所述被叫方的合法被转呼方。

说明书全文

一种实现安全呼叫转移的方法及系统

技术领域

[0001] 本发 明涉及 网络 通信安 全技 术,尤指 一种IP多 媒体 子系统(IP MultimediaSubsystem,简称IMS)中实现安全呼叫转移的方法及系统。

背景技术

[0002] 在会话发起协议(Session Initiation Protocol,简称SIP)系统中,呼叫转移(communication diversion)是一项常用及实用的服务,使得呼叫过程中启用了此呼叫转移服务的被呼方处于不可达或忙碌或者其他状态时,由被叫方的呼叫服务器将此呼叫转移到被叫方事先设置的被转呼方的用户设备上,从而提高了呼叫的灵活可配置性。
[0003] 呼叫转移包括以下几项业务类型:遇忙呼叫前转(CFB)、无应答呼叫前转(CFNA)和无条件呼叫前转(CFU)。这项业务允许用户将其所有来话转接到预先设置的另一个电话号码上或用户的语音信箱中。在激活无条件呼叫前转(CFU)时系统还可以提供许可呼叫。呼叫转移还包含特殊的多次转移呼叫场景,即用户A呼叫用户B,用户B使用呼叫转移业务,呼叫被转移给用户C,用户C也使用了呼叫转移业务,该呼叫被再次转移给用户D。
[0004] 下面简要介绍一下呼叫转移业务中呼叫服务器通过IMS网络向被转呼方发出的呼叫请求消息(协议中定义为INVITE消息,此消息基于SIP协议)。发生呼叫转移时,呼叫服务器从主叫方收到包含票据(ticket)的INVITE消息,并将此消息转发给被转呼方,而且在此消息中增加一用于表示呼叫转移的类型的CAUSE参数(CAUSE参数表示使用了呼叫转移业务及其类型)具体用法及说明参见RFC4458和TS24.604v9.2.0。
[0005] 例如,呼叫方为用户1,其标识为user1_public1@home1.net,被叫方为用户2,其标识为user2_public1@home1.net,用户2启用无条件呼叫转移服务,设置呼叫转移的目标为用户3,其标识为User-3@example.com,用户2所属呼叫服务器将用户1对用户2的呼叫转发至用户3,并在向用户3发送的INVITE消息中携带“CAUSE=302”中的状态量,取值为302的参数表示该呼叫类型为无条件前转呼叫。
[0006] 现有的3GPP TS33.328中IMS媒体面安全中使用密钥管理服务器(KeyManagement Server,简称KMS),图1为现有技术中基于KMS的IMS媒体安全解决方案架构示意图,其中:用户A(UE-A)和用户B(UE-B)分别是媒体信息的发送方和接收方;密钥管理服务器(KMS)作为可信任的第三方实现密钥的管理和分发功能;P-CSCF(代理-呼叫会话控制功能)和S-CSCF(服务-呼叫会话控制功能)为IMS网络中的网元;其它网元的功能介绍请参考相关文档。
[0007] 图2中现有技术中基于KMS的呼叫过程的示意图。在主叫方与被叫方的呼叫建立过程中,主叫方向KMS发送请求消息(REQUEST-INT)请求相关密钥及票据(ticket),KMS向主叫方返回响应消息(REQUEST-RESP),在此响应消息中携带主叫方所请求的票据,此票据基于被叫方的公共用户身份标识,且此票据中包含加密后的相关密钥以及呼叫方标识和被叫方标识,主叫方通过传输消息(TRANSFER-INIT)将此票据发送给被叫方,由于被叫方无法解密此票据,将此票据通过RESOLVE-INIT消息发送至KMS,KMS解密此票据后解密票据并将其中相关密钥返回被叫方,KMS通过票据获知被叫方标识,并比较此票据中的被叫方标识与发送此TRANSFER-INIT消息的应答方的标识是否相同,如果相同则判定此应答方即为合法的被叫方。
[0008] 在普通的呼叫过程中,向KMS发送RESOLVE-INIT的应答方即为此呼叫中的被叫方,可以顺利通过KMS对被叫用户身份的鉴定;分叉呼叫场景下,一个主叫方同时呼叫多个被叫方,但此多个被叫方均对应于同一公共用户身份标识,所以多个应答终端也可以通过用户身份鉴定;而在呼叫转移场景下,被转呼方可以由使用该服务的用户随时任意设定,最终应答方可能与原始被叫方分别拥有不同的公共用户身份标识,此情况下,上述基于被叫方的公共用户身份标识的鉴权方法将不再适用,导致无法对应答方的身份进行鉴定,从而导致呼叫失败。所以需要新的解决方案实现安全的呼叫转移。发明内容
[0009] 本发明要解决的技术问题是提供一种实现安全呼叫转移的方法,实现被转呼方身份鉴定,从而在IMS系统中实现安全呼叫转移。
[0010] 为解决上述技术问题,本发明提供了一种种实现安全呼叫转移的方法,包括:主叫方呼叫被叫方,所述被叫方触发签约的呼叫转移业务;密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息;所述被转呼方从所述密钥管理服务器获得媒体密钥;所述主叫方与所述被转呼方建立呼叫连接。
[0011] 进一步地,上述方法还具有以下特点:
[0012] 触发所述被叫方签约的呼叫转移业务的情况,是以下情况之一:无条件前转、无应答前转、寻呼不可及前转、用户忙前转、会话转移业务。
[0013] 进一步地,上述方法还具有以下特点:
[0014] 密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:应用服务器在呼叫请求消息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转呼方;所述密钥管理服务器根据被转呼方发送的携带所述加密的绑定关系信息的消息,判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0015] 进一步地,上述方法还具有以下特点:
[0016] 当所述被叫方满足触发条件时,所述被叫方所属应用服务器向所述被转呼方发送呼叫请求消息,所述消息中携带本次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
[0017] 进一步地,上述方法还具有以下特点:
[0018] 密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:所述应用服务器根据所述密钥管理服务器提供的所述被叫方与被转呼方的信息,判断所述被转呼方是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器。
[0019] 进一步地,上述方法还具有以下特点:
[0020] 密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:所述应用服务器根据所述密钥管理服务器提供的所述被叫方信息,返回所述被叫方呼叫转移用户标识列表;所述密钥管理服务器判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0021] 为了解决上述技术问题,本发明还提供了一种实现安全呼叫转移的系统,所述系统包括:主叫方,被叫方,被转呼方,应用服务器,密钥管理服务器;所述主叫方,用于呼叫被叫方;所述被叫方,用于根据所述主叫方的呼叫,触发签约的呼叫转移业务;所述密钥管理服务器,用于通过应用服务器获得所述被叫方合法的被转呼方信息;所述被转呼方,用于从所述密钥管理服务器获得媒体密钥。
[0022] 进一步地,上述系统还具有以下特点:
[0023] 所述应用服务器,用于在呼叫请求消息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转呼方;所述密钥管理服务器,用于根据被转呼方发送的携带所述加密的绑定关系信息的消息,判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0024] 进一步地,上述系统还具有以下特点:
[0025] 所述应用服务器,用于向所述被转呼方发送呼叫请求消息,并在此消息中携带本次呼叫转移中所述被叫方标识与所述被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
[0026] 进一步地,上述系统还具有以下特点:
[0027] 所述应用服务器,用于根据所述密钥管理服务器提供的所述被叫方与被转呼方的信息,判断所述被转呼方是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器;还用于根据所述密钥管理服务器提供的所述被叫方信息,返回所述被叫方呼叫转移用户标识列表;所述密钥管理服务器,用于判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0028] 本发明提供了一种新的密钥协商机制在IMS系统中实现安全的呼叫转移,并且本发明中基本保留了原IMS系统中的消息格式。附图说明
[0029] 图1为现有技术中基于KMS的IMS媒体安全解决方案架构示意图;
[0030] 图2中现有技术中基于KMS的呼叫过程的示意图;
[0031] 图3是实施例中实现安全呼叫转移的方法的示意图;
[0032] 图4是实施例一的单次呼叫转移中实现安全呼叫转移的方法示意图;
[0033] 图5是实施例二中使用第一种查询方式的单次呼叫转移中实现安全呼叫转移的方法示意图;
[0034] 图6是实施例二中使用第一种查询方式的多次呼叫转移中实现安全呼叫转移的方法示意图;
[0035] 图7是实施例二中使用第二种查询方式的单次呼叫转移中实现安全呼叫转移的方法示意图。

具体实施方式

[0036] 本发明中实现安全呼叫转移的系统包括:主叫方,被叫方,被转呼方,应用服务器,密钥管理服务器(此处是用于实现密钥的管理和分发的可信任的第三方的统称)。被叫方将被转呼方设定为呼叫转移目标,触发所述被叫方签约的呼叫转移业务的情况,是以下情况之一:无条件前转、无应答前转、寻呼不可及前转、用户忙前转、会话转移业务。应用服务器可用为呼叫转移服务器。应用服务器作为被叫方所属呼叫服务器时,用于在收到主叫方对被叫方的呼叫后向被转呼方发送呼叫请求消息。其中:
[0037] 主叫方,用于呼叫被叫方;
[0038] 被叫方,用于根据所述主叫方的呼叫,触发签约的呼叫转移业务;
[0039] 密钥管理服务器,用于通过应用服务器获得所述被叫方合法的被转呼方信息;
[0040] 所述被转呼方,用于从所述密钥管理服务器获得媒体密钥。
[0041] 本系统的第一种实现方式应用于单次呼叫转移情况时,呼叫转移过程涉及三个用户,主叫方,被叫方,被转呼方。应用服务器,用于在呼叫请求消息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转呼方;所述密钥管理服务器,用于根据被转呼方发送的携带所述加密的绑定关系信息的消息,判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0042] 具体应用中:
[0043] 所述被转呼方用于收到所述呼叫请求消息后向所述密钥管理服务器发送媒体密钥请求时携带此被转呼方的标识及所述加密绑定信息;所述密钥管理服务器,用于验证所述加密绑定消息中的被转呼方标识与所述被转呼方发送的媒体密钥请求中携带的被转呼方标识一致时,确定所述被转呼方是合法的被转呼方。
[0044] 本系统的第一种实现方式中应用于多次呼叫转移情况时,呼叫转移过程涉及多个用户包括:主叫方,被叫方,以及多个被转呼方。按照多次呼叫转移的时间先后顺序被转呼方依次为:第一被转呼方,第二被转呼方,,,次终被转呼方,最终被转呼方,其中被叫方,第一被转呼方,第二被转呼方,,,次终被转呼方分别对应一呼叫服务器。
[0045] 应用服务器作为多次呼叫转移中一次呼叫转移过程中被叫方的呼叫服务器,用于向被转呼方所属呼叫服务器发送呼叫请求消息,并在此消息中携带本次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息,以及之前历次呼叫转移过程中的被叫方标识与被转呼方标识的加密绑定信息;
[0046] 最终被转呼方,用于收到呼叫请求消息后向密钥管理服务器发送媒体密钥请求消息中携带最终被转呼标识以及历次呼叫转移中的加密绑定信息;
[0047] 所述密钥管理服务器,用于收到媒体密钥请求消息后验证所述媒体密钥请求消息中携带的最终被转呼方标识与最后一次呼叫转移的加密绑定信息中的最终被转呼方的标识一致时,按照加密绑定信息生成的时间从后至前的顺序依次验证各加密绑定信息中被转呼方的标识且均验证成功时,确定所述最终被转呼方是合法的被转呼方。
[0048] 本系统的第二种实现方式中使用第一种查询方式时,应用服务器用于根据密钥管理服务器提供的所述被叫方与被转呼方的信息,判断所述被转呼方是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器。
[0049] 本系统的第二种实现方式中使用第一种查询方式并且应用于单次呼叫转移情况,呼叫转移过程涉及三个用户,主叫方,被叫方,被转呼方。
[0050] 被转呼方,用于收到被叫方所属呼叫服务器发送的呼叫请求消息后,向所述密钥管理服务器发送媒体密钥请求消息并携带被转呼方的标识;
[0051] 所述密钥管理服务器,用于收到所述媒体密钥请求消息后向所述被叫方所属呼叫服务器发送查询消息,并在此查询消息中携带所述被叫方和所述被转呼方的标识;还用于收到所述呼叫服务器返回的成功确认消息后确定所述被转呼方是合法的被转呼方;
[0052] 所述被叫方所属呼叫服务器,用于收到所述查询消息后判断所述被转呼方是所述被叫方设置的呼叫转移目标时将成功确认消息通知至所述密钥管理服务器。
[0053] 本系统的第二种实现方式中使用第一种查询方式并且应用于多次呼叫转移情况,呼叫转移过程涉及多个用户包括:主叫方,被叫方,以及多个被转呼方。按照多次呼叫转移的时间先后顺序被转呼方依次为:第一被转呼方,第二被转呼方,,,次终被转呼方,最终被转呼方,其中被叫方,第一被转呼方,第二被转呼方,,,次终被转呼方分别对应一呼叫服务器。
[0054] 被叫方所属呼叫服务器,用于收到查询消息并判定第一被转呼方是被叫方设置的呼叫转移目标时,通过各呼叫服务器将成功确认消息通知至密钥管理服务器;
[0055] 作为多次呼叫转移的一次呼叫转移中被叫方的呼叫服务器,用于向本次呼叫转移中的被转呼方发送呼叫请求消息,并携带本次呼叫转移中被叫方标识以及之前历次呼叫转移过程中的被叫方标识;还用于从本次呼叫转移中的被转呼方所属呼叫服务器收到查询消息并判定此本次呼叫转移中被转呼方为本次呼叫转移中被叫方设置的呼叫转移目标时,向被叫方的上一被转呼方所属呼叫服务器发送查询消息,携带被叫方与本次被转呼方之间历次呼呼转移过程中所有被呼方标识;
[0056] 所述最终被转呼方,用于从次终被转呼方所属呼叫服务器收到呼叫请求消息后向密钥管理服务器发送媒体密钥请求消息并携带最终被转呼方的标识以及历次呼叫转移过程中的被叫方标识;
[0057] 所述密钥管理服务器,用于收到媒体密钥请求消息后向次终被转呼方所属呼叫服务器发送查询消息并携带历次呼叫转移过程中所有被叫方标识;还用于收到此成功确认消息后确定所述最终被转呼方是合法的被转呼方。
[0058] 本系统的第二种实现方式中使用第二种查询方式时,应用服务器用于根据所述密钥管理服务器提供的所述被叫方信息,返回所述被叫方呼叫转移用户标识列表;所述密钥管理服务器,用于判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0059] 本系统的第二种实现方式使用第二种查询方式并且应用于单次呼叫转移情况,呼叫转移过程涉及三个用户,主叫方,被叫方,被转呼方。
[0060] 所述被转呼方,用于收到所述被叫方所属呼叫服务器发送的呼叫请求消息后,向所述密钥管理服务器发送媒体密钥请求消息并携带被转呼方的标识;
[0061] 所述密钥管理服务器,用于从所述被转呼方收到媒体密钥请求消息后,向所述被叫方所属呼叫服务器发送查询消息,并在此查询消息中携带所述被叫方标识;还用于从呼叫服务器收到所述被叫方设置的呼叫转移目标列表后,判定所述被转呼方的标识位于此列表中时,确定所述被转呼方是合法的被转呼方;
[0062] 所述呼叫服务器,用于从密钥管理服务器收到查询消息后,将所述被叫方设置的呼叫转移目标列表发送至所述密钥管理服务器。
[0063] 本系统的第二种实现方式中使用第二种查询方式并且应用于多次呼叫转移情况,呼叫转移过程涉及多个用户包括:主叫方,被叫方,以及多个被转呼方。按照多次呼叫转移的时间先后顺序被转呼方依次为:第一被转呼方,第二被转呼方,,,次终被转呼方,最终被转呼方,其中被叫方,第一被转呼方,第二被转呼方,,,次终被转呼方分别对应一呼叫服务器。
[0064] 作为多次呼叫转移中一次呼叫转移中被叫方所属呼叫服务器,用于向本次呼叫转移中的被转呼方发送呼叫请求消息;还用于收到密钥管理服务器发送的查询消息后,将本身执行的呼叫转移过程中的被叫方设置的呼叫转移目标列表发送至密钥管理服务器;
[0065] 所述最终被转呼方,用于在收到呼叫请求消息后向密钥管理服务器发送媒体密钥请求消息并携带最终被转呼方的标识;
[0066] 所述密钥管理服务器,用于从最终被转呼方收到媒体密钥请求消息后,向次终被叫方所属呼叫服务器发送查询消息并携带次终被转呼方的标识;还用于在从一呼叫服务器收到列表后,判断此呼叫服务器对应的被转呼方位于此列表后,按各次呼叫转移执行时间从后向前的顺序,向此呼叫服务器的前一呼叫服务器发送查询消息,并携带此前一呼叫服务器对应的被转呼方的标识;还用于收到被叫方所属呼叫服务器返回的被叫方设置的呼叫转移目标列表并判断第一被转呼方的标识位于此列表中时,确定所述最终被转呼方是合法的被转呼方。
[0067] 对应于上述系统,如图3所示,实现安全呼叫转移的方法包括:主叫方呼叫被叫方,所述被叫方触发签约的呼叫转移业务;密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息;所述被转呼方从所述密钥管理服务器获得媒体密钥;所述主叫方与所述被转呼方建立呼叫连接。
[0068] 本发明中,触发所述被叫方签约的呼叫转移业务的情况,是以下情况之一:无条件前转、无应答前转、寻呼不可及前转、用户忙前转、会话转移业务。
[0069] 本发明的方法中,由密钥管理服务器对被转呼方进行鉴权,保证呼叫转移的安全实现。本发明适用一次呼叫转移以及多次呼叫转移。
[0070] 下面通过多个实施例对本发明作详细的说明。
[0071] 实施例一
[0072] 本实施例一适用于两种呼叫转移的情况,一种为单次呼叫转移,另一种为多次呼叫转移。
[0073] 在单次呼叫转移情况时,密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:应用服务器在呼叫请求消息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转呼方;所述密钥管理服务器根据被转呼方发送的携带所述加密的绑定关系信息的消息,判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0074] 具体应用时,被叫方所属呼叫服务器向被转呼方发送呼叫请求消息时,在此呼叫请求消息中携带被叫方标识与被转呼方标识的加密绑定信息,所述被转呼方向所述密钥管理服务器发送媒体密钥请求时携带此被转呼方的标识及所述加密绑定信息,所述密钥管理服务器验证所述加密绑定消息中的被转呼方标识与所述被转呼方发送的媒体密钥请求中携带的被转呼方标识一致时,确定所述被转呼方是合法的被转呼方。
[0075] 被叫方所属呼叫服务器发送的加密绑定消息是指用此呼叫服务器与密钥管理服务器的共享密钥加密后的被叫方标识与被转呼方标识的绑定信息;密钥管理服务器收到被转呼方发送的此加密绑定消息后,用此共享密钥解密此绑定消息。
[0076] 如图4为单次呼叫转移中实现安全呼叫转移的方法示意图,用户A为主叫方,用户B为被叫方,用户C为用户B设置的呼叫转移目标即被转呼方,AS为被叫方所属呼叫服务器。
[0077] 步骤401,用户A向KMS发送票据请求,申请呼叫用户B所需要的票据。
[0078] 步骤402,KMS鉴定用户A并生成相应票据发送至用户A。
[0079] 步骤403,用户A向IMS网络发送呼叫请求消息,并此呼叫请求消息中携带票据(ticket),具体的,用户A将包含ticket的TRANSFER_INIT消息置于SIP INVITE消息中发给IMS网络。
[0080] 步骤404,IMS网络将收到的INVITE消息转发到被叫方所属的AS。
[0081] 步骤405~406,由于用户B使用无条件呼叫前转服务,AS通过IMS网络通知用户A该呼叫被前转。
[0082] 步骤407,AS根据用户B设定的前转号码,向IMS网络发送呼叫请求消息,在并此呼叫请求消息中携带用户B标识和用户C标识的加密绑定信息。此加密绑定消息是指用此AS与KMS的共享密钥Kas加密的用户B和用户C的绑定信息,即Eas(ID-B,ID-C);还携带此AS的标识(包括公共用户标识,如果此过程中使用通用认证机制GBA,还包括GBA标识即BTID)。具体的,AS将上述信息以及从用户A收到的票据包含在SIP INVITE消息中,通过IMS网络转发。
[0083] 步骤408,IMS网络将此INVITE消息转发至用户C。
[0084] 步骤409,用户C收到INVITE消息后,向KMS发送媒体密钥请求消息,并在此消息中包含用户C标识(包括公共用户标识,如果此过程中使用通用认证机制GBA,还包括GBA标识即BTID)以及从AS处收到的信息(包括加密绑定信息)以及呼叫转移指示。
[0085] 步骤410,KMS根据信息中包含的呼叫转移指示或AS的信息可知此呼叫为呼叫转移,根据AS的标识找到KMS与呼叫服务器的共享密钥Kas,解密消息中用Kas加密的绑定信息,获得ID-B和ID-C,判断此绑定信息中的用户C标识与媒体密钥请求消息中携带的用户C标识是否相同,相同时,表明用户C是合法被转用户,进一步解密ticket中的媒体密钥信息,用与用户C的共享密钥加密媒体密钥信息,将成功响应置于RESOLVE-RESP消息中;不相同时,向用户C返回失败响应,终止此次呼叫。
[0086] 步骤411,KMS将RESOLVE_RESP消息置于响应报文中返回给用户C。
[0087] 步骤412~415,用户C收到RESOLVE_RESP消息,获得KMS解密的ticket中包含的媒体密钥信息,生成TRANSFER_RESP消息,并将该消息包含在200Ok消息中通过IMS网络回复给用户A。
[0088] 步骤416,用户A和用户C建立起连接,交互安全媒体流
[0089] 通过以上流程,用户A和用户C可获得加密媒体流的密钥信息,从而进行端到端安全的加密媒体流通信。
[0090] 在多次转移呼叫的情况下,当所述被叫方满足触发条件时,所述被叫方所属应用服务器向所述被转呼方发送呼叫请求消息,所述消息中携带本次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
[0091] 具体应用中,在多次转移呼叫的每次转移呼叫过程中本次被叫方所属呼叫服务器向本次转移呼叫中的被转呼方所属呼叫服务器发送呼叫请求消息时,在此呼叫请求消息中携带本次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息;最终被转呼方向密钥管理服务器发送媒体密钥请求消息中携带最终被转呼标识以及历次呼叫转移中的加密绑定信息;密钥管理服务器验证所述媒体密钥请求消息中的最终被转呼标识与最后一次呼叫转移的加密绑定信息中的最终被转呼方的标识一致后,按照加密绑定信息生成的时间从后至前的顺序依次验证各加密绑定信息中被转呼方的标识且均验证成功时,确定所述最终被转呼方是合法的被转呼方。
[0092] 呼叫服务器发送的加密绑定消息是指用此呼叫服务器与密钥管理服务器的共享密钥加密后的被叫方标识与被转呼方标识的绑定信息;密钥管理服务器收到被转呼方发送的此加密绑定消息后,用此共享密钥解密此绑定消息。在实际应用时,各呼叫服务器使用的共享密钥可以相同也可以不同。
[0093] 实施例二
[0094] 实施例二的第一种实现方式中,KMS将呼叫转移过程中被叫方标识以及被转呼方标识发送至被叫方所属的AS,由AS对被转呼方的合法性进行判定后并通知至KMS。密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:所述应用服务器根据所述密钥管理服务器提供的所述被叫方与被转呼方的信息,判断所述被转呼方是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器。
[0095] 此第一种实现方式适用于两种呼叫转移的情况,一种为单次呼叫转移,另一种为多次呼叫转移。
[0096] 在单次呼叫转移情况中,被转呼方收到被叫方所属呼叫服务器发送的呼叫请求消息后,向所述密钥管理服务器发送媒体密钥请求消息并携带被转呼方的标识,所述密钥管理服务器向所述被叫方所属呼叫服务器发送查询消息,并在此查询消息中携带所述被叫方和所述被转呼方的标识,所述被叫方所属呼叫服务器判断所述被转呼方是所述被叫方设置的呼叫转移目标时将成功确认消息通知至所述密钥管理服务器,所述密钥管理服务器确定所述被转呼方是合法的被转呼方。
[0097] 如图5为单次呼叫转移中实现安全呼叫转移的方法示意图,用户A为主叫方,用户B为被叫方,用户C为用户B设置的呼叫转移目标即被转呼方,AS为被叫方所属呼叫服务器。
[0098] 步骤501~506与步骤401~406对应相同。
[0099] 步骤507,此步骤与步骤407的区别是,AS在INVITE消息中包含被叫方标识即ID-B以及本身的标识即ID-AS。
[0100] 步骤508,IMS网络将INVITE消息转发给被用户C。
[0101] 步骤509,用户C收到INVITE消息后,向KMS发送媒体密钥请求消息,并在此消息中包含用户C标识(包括公共用户标识,如果此过程中使用通用认证机制GBA,还包括GBA标识即BTID)以及从AS处收到的信息(包括加密绑定信息)以及呼叫转移指示。
[0102] 步骤510,KMS根据信息中包含的呼叫转移指示可知该呼叫为呼叫转移场景,根据AS标识向相应的AS发送查询请求,该查询请求中包含被叫方标识即ID-B和被转呼方标识即ID-C。
[0103] 步骤511,AS根据被叫方ID-B查询ID-C是否为用户B设置的呼叫转移目标时,如果是,向KMS返回“正确”消息,如果不是,向KMS返回“错误”消息。如果KMS收到“正确”反馈,则继续下一步骤;如收到“错误”反馈,则返回相应错误信息,终止流程。
[0104] 步骤512,KMS解密ticket中的媒体密钥信息,用与用户C的共享密钥加密媒体密钥信息,生成RESOLVE_RESP,将RESOLVE_RESP消息在响应报文中返回给用户C。
[0105] 步骤513~516,用户C收到RESOLVE_RESP消息,获得KMS解密的ticket中包含的媒体密钥信息,生成TRANSFER_RESP消息,并将该消息包含在200Ok消息中通过IMS网络回复给用户A。
[0106] 步骤517,用户A和用户C建立起连接,交互安全媒体流。
[0107] 通过以上过程,用户A和用户C可获得加密媒体流的密钥信息,从而进行端到端安全的加密媒体流通信。
[0108] 在多次转移呼叫的情况下,多次转移呼叫的每次转移呼叫过程中本次转移呼叫的被叫方所属呼叫服务器向本次呼叫转移的被转呼方发送呼叫请求消息,携带本次呼叫转移中被叫方标识以及之前历次呼叫转移过程中的被叫方标识;最终被转呼方向密钥管理服务器发送媒体密钥请求消息并携带最终被转呼方的标识以及历次呼叫转移过程中的被叫方标识;密钥管理服务器向次终被转呼方所属呼叫服务器发送查询消息,携带最终被转呼方的标识以及历次呼叫转移过程中被叫方标识,次终被转呼方所属呼叫服务器判定最终被转呼方是次终被转呼方设置的呼叫转移目标时,向次终被转呼方的上一被转呼方所属呼叫服务器发送查询消息,携带被叫方与本次被转呼方之间历次呼呼转移过程中所有被呼方标识;依此顺序执行;被叫方所属呼叫服务器收到查询消息并判定第一被转呼方是被叫方设置的呼叫转移目标时,通过各呼叫服务器将成功确认消息通知至密钥管理服务器后,密钥管理服务器确定所述最终被转呼方是合法的被转呼方。
[0109] 如图6为多次呼叫转移中实现安全呼叫转移的方法示意图,用户A为主叫方,用户B为被叫方,用户C为用户B设置的呼叫转移目标,用户D为用户C设置的呼叫转移目标,用户B用户C都使用无条件呼叫转移服务,AS1为用户B所属呼叫服务器,AS2为用户C所属呼叫服务器。
[0110] 步骤601~606与步骤401~406对应相同。
[0111] 步骤607,AS1向IMS发送呼叫请求消息,并在此呼叫请求消息中携带从用户A收到的票据以及用户B的标识即ID-B以及本身的标识即ID-AS1。具体的,AS将上述信息以及从用户A收到的票据包含在SIP INVITE消息中,通过IMS网络转发。
[0112] 步骤608,IMS网络将INVITE消息转发到AS2。
[0113] 步骤609~610,由于用户C使用无条件呼叫前转服务,AS2通过IMS网络通知用户B该呼叫被前转。
[0114] 步骤611,AS2向IMS发送呼叫请求消息,并在此呼叫请求消息中携带从AS1获知的信息以及用户C的标识即ID-C以及本身的标识即ID-AS2。具体的,AS将上述信息包含在SIP INVITE消息中,通过IMS网络转发。
[0115] 步骤612,IMS将从AS2收到的信息发给用户D。
[0116] 步骤613,用户D向KMS发送媒体密钥请求消息,并在此消息中包含用户D的标识(包括公共用户标识,如果此过程中使用通用认证机制GBA,还包括GBA标识即BTID)以及从AS2处收到的信息(包括加密绑定信息)以及呼叫转移指示。
[0117] 步骤614,KMS根据信息中包含的呼叫转移指示可知此呼叫为呼叫转移,根据AS2标识向AS2发送查询请求,该查询请求中至少包含ID-B,ID-C,ID-D和ID-AS1。
[0118] 步骤615,AS2根据用户C标识查询用户D是否是用户C设置的呼叫转移目标,如果是,则继续步骤615b,如果不是,执行步骤615a;
[0119] 步骤615a,AS2向KMS返回指示“错误”的查询反馈消息,KMS向相关设备返回相应错误信息,终止流程。
[0120] 步骤615b,AS2根据AS1的标识向AS1继续发送查询请求消息,请求消息中包含ID-B,ID-C。
[0121] 步骤616,AS1根据用户B的标识查询用户C是否是用户B设置的呼叫转移目标,如果是,则向AS2返回指示“正确”的查询反馈消息,如果不是,则向AS2返回指示“错误”的查询反馈消息。
[0122] 步骤617,AS2将查询结果转发给KMS。如果KMS收到“正确”反馈,则继续下一步骤;如收到“错误”反馈,则返回相应错误信息,终止流程。
[0123] 步骤618,KMS解密ticket中的媒体密钥信息,用与用户D的共享密钥加密媒体密钥信息,产生RESOLVE_RESP,将RESOLVE_RESP消息在报文中返回给用户D。
[0124] 步骤619~621,用户D收到RESOLVE_RESP消息,获得KMS解密的ticket中包含的媒体密钥信息,生成TRANSFER_RESP消息,并将该消息包含在200Ok消息中通过IMS网络回复给用户A。
[0125] 步骤622,用户A和用户D建立起连接,交互安全媒体流。
[0126] 通过以上过程,用户A和用户D可获得加密媒体流的密钥信息,从而进行端到端安全的加密媒体流通信。
[0127] 实施例二的第二种实现方式中,KMS将呼叫转移过程中被转呼方标识发送至AS进行查询,AS返回此被转呼方设置的呼叫转移目标列表,KMS根据此列表判断此被转呼方的合法性。密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息的过程包括:所述应用服务器根据所述密钥管理服务器提供的所述被叫方信息,返回所述被叫方呼叫转移用户标识列表;所述密钥管理服务器判断所述被转呼方是否为所述被叫方的合法被转呼方。
[0128] 此第一种实现方式适用于两种呼叫转移的情况,一种为单次呼叫转移,另一种为多次呼叫转移。
[0129] 在单次呼叫转移情况下,被转呼方收到所述被叫方所属呼叫服务器发送的呼叫请求消息后,向所述密钥管理服务器发送媒体密钥请求消息并携带被转呼方的标识,所述密钥管理服务器向所述被叫方所属呼叫服务器发送查询消息,并在此查询消息中携带所述被叫方标识,所述被叫方所属呼叫服务器将所述被叫方设置的呼叫转移目标列表发送至所述密钥管理服务器,所述密钥管理服务器检查所述被转呼方的标识位于此列表中时,确定所述被转呼方是合法的被转呼方。
[0130] 如图7为单次呼叫转移中实现安全呼叫转移的方法示意图,用户A为主叫方,用户B为被叫方,用户C为用户B设置的呼叫转移目标即被转呼方,AS为被叫方所属呼叫服务器。
[0131] 步骤701~709与步骤501~509对应相同。
[0132] 步骤710,KMS根据信息中包含的呼叫转移指示可知该呼叫为呼叫转移场景,向AS发送查询请求,该请求中包括被叫方标识即ID-B。
[0133] 步骤711,AS根据用户B标识即ID-B查询用户B设置的呼叫转移目标列表,并将此列表返回至KMS。
[0134] 步骤712,KMS判断用户C的标识是否在所述列表中,如果是,则继续下一步骤;否则,终止会话。
[0135] 步骤713,KMS解密ticket中的媒体密钥信息,用与用户C的共享密钥加密媒体密钥信息,产生RESOLVE_RESP,将RESOLVE_RESP消息在报文中返回给用户C。
[0136] 步骤714~715,用户C获得KMS解密的ticket中包含的媒体密钥信息,生成TRANSFER_RESP消息,并将该消息包含在200Ok消息中通过IMS网络回复给用户A。
[0137] 步骤716,用户A和用户C建立起连接,交互安全媒体流。
[0138] 通过以上过程,用户A和用户C可获得加密媒体流的密钥信息,从而进行端到端安全的加密媒体流通信。
[0139] 在多次转移呼叫的情况下,在多次转移呼叫下每次呼叫转移中被叫方所属呼叫服务器向本次呼叫转移的被转呼方所属呼叫服务器发送呼叫请求消息,最终被转呼方收到呼叫请求消息后向密钥管理服务器发送媒体密钥请求消息并携带最终被转呼方的标识,密钥管理服务器向次终被叫方所属呼叫服务器发送查询消息并携带次终被转呼方的标识,从次终被转呼方所属呼叫服务器收到次终被叫方设置的呼叫转移目标列表后,检查最终被转呼方的标识位于此列表中时,按各次呼叫转移执行时间从后向前的顺序,向次终被转呼方的前一被转呼方所属呼叫服务器发送查询消息并携带次终被转呼方的前一被转呼方的标识,根据返回的呼叫转移目标列表进行判断;依次类推;密钥管理服务器收到被叫方所属呼叫服务器返回的被叫方设置的呼叫转移目标列表并判断第一被转呼方的标识位于此列表中时确定所述最终被转呼方是合法的被转呼方。
[0140] 本发明中,呼叫服务器可以与密钥管理服务器KMS直接通信,也可以通过中间网元进行通信,例如通过引导服务功能(Bootstrapping ServiceFunction,简称BSF)服务器通信。
[0141] 本发明中,每个用户及AS可以和KMS通过GBA方式建立信任关系,通过密钥协商协议,每个用户及AS都和KMS建立共享密钥,如果GBA无法使用,用户可以使用其它认证方式和KMS获得共享密钥。具体实现属于本领域技术人员惯用技术手段,这里不再赘述。在本发明的所有场景安全解决方法流程中,用户终端A,B,C,AS与KMS的共享密钥分别为Ka,Kb,Kc,Kas,他们与KMS之间均已经建立安全通道,相应的GBA标识为BTIDa,BTIDb,BTIDc,BTIDas。
[0142] 以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
QQ群二维码
意见反馈